[v4,0/6] napi tracking strategy

Message

Olivier Langlois Oct. 13, 2024, 6:28 p.m. UTC

the actual napi tracking strategy is inducing a non-negligeable overhead.
Everytime a multishot poll is triggered or any poll armed, if the napi is
enabled on the ring a lookup is performed to either add a new napi id into
the napi_list or its timeout value is updated.

For many scenarios, this is overkill as the napi id list will be pretty
much static most of the time. To address this common scenario, the concept of io_uring_napi_tracking_strategy has been created.
the tracking strategy can be specified when io_register_napi() is called.

To keep backward compatibility, the legacy strategy IO_URING_NAPI_TRACKING_DYNAMIC is assigned the value 0 so that existing code using io_uring napi busy polling continue working as before. If IO_URING_NAPI_TRACKING_STATIC is provided, io_napi_add() becomes a noop function and the responsability to update the napi devices list is given to the user by calling io_register_napi() with the opcode value of IO_URING_NAPI_STATIC_ADD_ID or IO_URING_NAPI_STATIC_DEL_ID.

the NAPI ids used by a process can be discovered by calling
getsockopt(fd, SOL_SOCKET, SO_INCOMING_NAPI_ID, &napi_id, &len)

the patch serie consist of very minor fixes followed by the core of the changes
to implement the new feature.

v4 changes:
- improve cover letter text
- rebase patch on for-6.13/io_uring
- create a prep-patch for the __io_napi_add refactoring change
- create a prep-patch for the Scope-Based Resource Management refactoring
- create a prep-patch for the __io_napi_do_busy_loop cleanup
- adress io_napi_add() code review comment

v3 changes:
- address minor comments in patch #3
- replace the double for loop hash macro with the single loop list macro to iterate the napi elements in patch #2
- add __cold attribute to common_tracking_show_fdinfo() and napi_show_fdinfo()

v2 changes:
- extract small changes from the core changes to ease minor fixes backport
- totally remove the io_napi_tracking_ops interface

Olivier Langlois (6):
  io_uring/napi: protect concurrent io_napi_entry timeout accesses
  io_uring/napi: fix io_napi_entry RCU accesses
  io_uring/napi: improve __io_napi_add
  io_uring/napi: Use lock guards
  io_uring/napi: clean up __io_napi_do_busy_loop
  io_uring/napi: add static napi tracking strategy

 include/linux/io_uring_types.h |   2 +-
 include/uapi/linux/io_uring.h  |  32 +++++-
 io_uring/fdinfo.c              |  54 +++++++---
 io_uring/napi.c                | 184 +++++++++++++++++++++++----------
 io_uring/napi.h                |   8 +-
 5 files changed, 207 insertions(+), 73 deletions(-)

Comments

Jens Axboe Nov. 4, 2024, 5:49 p.m. UTC | #1

On Sun, 13 Oct 2024 14:28:05 -0400, Olivier Langlois wrote:
> the actual napi tracking strategy is inducing a non-negligeable overhead.
> Everytime a multishot poll is triggered or any poll armed, if the napi is
> enabled on the ring a lookup is performed to either add a new napi id into
> the napi_list or its timeout value is updated.
> 
> For many scenarios, this is overkill as the napi id list will be pretty
> much static most of the time. To address this common scenario, the concept of io_uring_napi_tracking_strategy has been created.
> the tracking strategy can be specified when io_register_napi() is called.
> 
> [...]

Applied, thanks!

[1/6] io_uring/napi: protect concurrent io_napi_entry timeout accesses
      commit: d54db33e51090f68645fecb252a3ad22f28512cf
[2/6] io_uring/napi: fix io_napi_entry RCU accesses
      commit: 613dbde4863699fe88e601ddd7315f04c1aa3239
[3/6] io_uring/napi: improve __io_napi_add
      commit: e17bd6f1106d8c45e186a52d3ac0412f17e657c3
[4/6] io_uring/napi: Use lock guards
      commit: 6710c043c8e9d8fa9649fffd8855e3ad883bf001
[5/6] io_uring/napi: clean up __io_napi_do_busy_loop
      commit: c596060fbe5a1c094d46d8f7191a866879fe6672
[6/6] io_uring/napi: add static napi tracking strategy
      commit: cc909543d239912669b14250e796bbd877f8128a

Best regards,

Jens Axboe Nov. 4, 2024, 5:52 p.m. UTC | #2

On 11/4/24 10:49 AM, Jens Axboe wrote:
> 
> On Sun, 13 Oct 2024 14:28:05 -0400, Olivier Langlois wrote:
>> the actual napi tracking strategy is inducing a non-negligeable overhead.
>> Everytime a multishot poll is triggered or any poll armed, if the napi is
>> enabled on the ring a lookup is performed to either add a new napi id into
>> the napi_list or its timeout value is updated.
>>
>> For many scenarios, this is overkill as the napi id list will be pretty
>> much static most of the time. To address this common scenario, the concept of io_uring_napi_tracking_strategy has been created.
>> the tracking strategy can be specified when io_register_napi() is called.
>>
>> [...]
> 
> Applied, thanks!
> 
> [1/6] io_uring/napi: protect concurrent io_napi_entry timeout accesses
>       commit: d54db33e51090f68645fecb252a3ad22f28512cf
> [2/6] io_uring/napi: fix io_napi_entry RCU accesses
>       commit: 613dbde4863699fe88e601ddd7315f04c1aa3239
> [3/6] io_uring/napi: improve __io_napi_add
>       commit: e17bd6f1106d8c45e186a52d3ac0412f17e657c3
> [4/6] io_uring/napi: Use lock guards
>       commit: 6710c043c8e9d8fa9649fffd8855e3ad883bf001
> [5/6] io_uring/napi: clean up __io_napi_do_busy_loop
>       commit: c596060fbe5a1c094d46d8f7191a866879fe6672
> [6/6] io_uring/napi: add static napi tracking strategy
>       commit: cc909543d239912669b14250e796bbd877f8128a

Finally got around to this one, apologies for the delay. It looks really
nice at this point.

I'm assuming you have a liburing branch too, with the new register parts
documented, and probably helpers for setting it up? Would be nice to have
an addition to the napi test case as well, so this can get exercised as
part of the usual testing.