mbox series

[RFC,v3,0/3] io_uring: add napi busy polling support

Message ID 20221115070900.1788837-1-shr@devkernel.io (mailing list archive)
Headers show
Series io_uring: add napi busy polling support | expand

Message

Stefan Roesch Nov. 15, 2022, 7:08 a.m. UTC
This adds the napi busy polling support in io_uring.c. It adds a new
napi_list to the io_ring_ctx structure. This list contains the list of
napi_id's that are currently enabled for busy polling. This list is
used to determine which napi id's enabled busy polling.

To set the new napi busy poll timeout, a new io-uring api has been
added. It sets the napi busy poll timeout for the corresponding ring.

There is also a corresponding liburing patch series, which enables this
feature. The name of the series is "liburing: add add api for napi busy
poll timeout". It also contains two programs to test the this.

Testing has shown that the round-trip times are reduced to 38us from
55us by enabling napi busy polling with a busy poll timeout of 100us.


Changes:
- V3:
  - Refreshed to 6.1-rc5
  - Added a new io-uring api for the prefer napi busy poll api and wire
    it to io_napi_busy_loop().
  - Removed the unregister (implemented as register)
  - Added more performance results to the first commit message.
- V2:
  - Add missing defines if CONFIG_NET_RX_BUSY_POLL is not defined
  - Changes signature of function io_napi_add_list to static inline
    if CONFIG_NET_RX_BUSY_POLL is not defined
  - define some functions as static


Signed-off-by: Stefan Roesch <shr@devkernel.io>

Stefan Roesch (3):
  io_uring: add napi busy polling support
  io_uring: add api to set napi busy poll timeout.
  io_uring: add api to set napi prefer busy poll

 include/linux/io_uring_types.h |   8 +
 include/uapi/linux/io_uring.h  |   4 +
 io_uring/io_uring.c            | 278 +++++++++++++++++++++++++++++++++
 io_uring/napi.h                |  22 +++
 io_uring/poll.c                |   3 +
 io_uring/sqpoll.c              |  10 ++
 6 files changed, 325 insertions(+)
 create mode 100644 io_uring/napi.h


base-commit: 094226ad94f471a9f19e8f8e7140a09c2625abaa

Comments

Jakub Kicinski Nov. 16, 2022, 6:31 p.m. UTC | #1
On Mon, 14 Nov 2022 23:08:57 -0800 Stefan Roesch wrote:
> This adds the napi busy polling support in io_uring.c. It adds a new
> napi_list to the io_ring_ctx structure. This list contains the list of
> napi_id's that are currently enabled for busy polling. This list is
> used to determine which napi id's enabled busy polling.
> 
> To set the new napi busy poll timeout, a new io-uring api has been
> added. It sets the napi busy poll timeout for the corresponding ring.
> 
> There is also a corresponding liburing patch series, which enables this
> feature. The name of the series is "liburing: add add api for napi busy
> poll timeout". It also contains two programs to test the this.
> 
> Testing has shown that the round-trip times are reduced to 38us from
> 55us by enabling napi busy polling with a busy poll timeout of 100us.

Acked-by: Jakub Kicinski <kuba@kernel.org>

Thanks!
Jens Axboe Nov. 16, 2022, 6:44 p.m. UTC | #2
On 11/16/22 11:31 AM, Jakub Kicinski wrote:
> On Mon, 14 Nov 2022 23:08:57 -0800 Stefan Roesch wrote:
>> This adds the napi busy polling support in io_uring.c. It adds a new
>> napi_list to the io_ring_ctx structure. This list contains the list of
>> napi_id's that are currently enabled for busy polling. This list is
>> used to determine which napi id's enabled busy polling.
>>
>> To set the new napi busy poll timeout, a new io-uring api has been
>> added. It sets the napi busy poll timeout for the corresponding ring.
>>
>> There is also a corresponding liburing patch series, which enables this
>> feature. The name of the series is "liburing: add add api for napi busy
>> poll timeout". It also contains two programs to test the this.
>>
>> Testing has shown that the round-trip times are reduced to 38us from
>> 55us by enabling napi busy polling with a busy poll timeout of 100us.
> 
> Acked-by: Jakub Kicinski <kuba@kernel.org>
> 
> Thanks!

Thanks Jakub! Question on the need for patch 3, which I think came about
because of comments from you. Can you expand on why we need both an
enable and timeout setting? Are there cases where timeout == 0 and
enabled == true make sense?
Jakub Kicinski Nov. 16, 2022, 8:09 p.m. UTC | #3
On Wed, 16 Nov 2022 11:44:38 -0700 Jens Axboe wrote:
> Thanks Jakub! Question on the need for patch 3, which I think came about
> because of comments from you. Can you expand on why we need both an
> enable and timeout setting? Are there cases where timeout == 0 and
> enabled == true make sense?

The enable is for the "prefer busy poll" mode, rather that just busy
polling.

The prefer busy poll mode disables interrupts and arms a (hopefully
long enough) fail safe timer, and expects user to come back and busy
poll before the timer fires. The timer length is set thru sysfs params
for NAPI/queue.

Because the Rx traffic is fully async and not in control of the local
app, this gives the local app the ability to postpone the Rx IRQ.
No interruptions means lower response latency. 
With the expectation that the app will read/"busy poll" next batch of
packets once its done servicing the previous batch.

We don't have to implement this bit from the start, "normal" busy poll
is already functional with patches 1 and 2.
Jens Axboe Nov. 16, 2022, 8:12 p.m. UTC | #4
On 11/16/22 1:09 PM, Jakub Kicinski wrote:
> On Wed, 16 Nov 2022 11:44:38 -0700 Jens Axboe wrote:
>> Thanks Jakub! Question on the need for patch 3, which I think came about
>> because of comments from you. Can you expand on why we need both an
>> enable and timeout setting? Are there cases where timeout == 0 and
>> enabled == true make sense?
> 
> The enable is for the "prefer busy poll" mode, rather that just busy
> polling.
> 
> The prefer busy poll mode disables interrupts and arms a (hopefully
> long enough) fail safe timer, and expects user to come back and busy
> poll before the timer fires. The timer length is set thru sysfs params
> for NAPI/queue.
> 
> Because the Rx traffic is fully async and not in control of the local
> app, this gives the local app the ability to postpone the Rx IRQ.
> No interruptions means lower response latency. 
> With the expectation that the app will read/"busy poll" next batch of
> packets once its done servicing the previous batch.
> 
> We don't have to implement this bit from the start, "normal" busy poll
> is already functional with patches 1 and 2.

Gotcha, ok makes sense to me. I'm fine with the patchset, just want
a few adjustments on the API side as per previous email. I think
Stefan is respinning with that, then we can get it queued up.