Skip to contentSkip to conversation

io_uring: add napi busy polling support

PATCH In review Stefan Roesch 4 participants 20 messages Jun 8, 2023 – Feb 2, 2024

Subsystems (3)
Networking Network drivers io_uring
lore
Share & tools
lore

Stefan Roesch

author
#0 lore raw

v15 cover io_uring: add napi busy polling support

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. For faster access it also adds a hash table.

When a new napi id is added, the hash table is used to locate if the napi id has already been added. When processing the busy poll loop the list is used to process the individual elements.

io-uring allows specifying two parameters:
- busy poll timeout and
- prefer busy poll to call of io_napi_busy_loop()
This sets the above parameters for the ring. The settings are passed with a new structure io_uring_napi.

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. More detailled results are part of the commit message of the first patch.

Changes:
- V15:
- Combined _napi_busy_loop() and __napi_busy_loop() function
- Rephrased comment
- V14:
- Rephrased comment for napi_busy_loop_rcu() funnction
- Added new function _napi_busy_loop() to remove code duplication in napi_busy_loop() and napi_busy_loop_rcu()
- V13:
- split off __napi_busy_loop() from napi_busy_loop()
- introduce napi_busy_loop_no_lock()
- use napi_busy_loop_no_lock in io_napi_blocking_busy_loop
- V12:
- introduce io_napi_hash_find()
- use rcu for changes to the hash table
- use rcu for searching if a napi id is in the napi hash table
- use rcu hlist functions for adding and removing items from the hash table
- add stale entry detection in __io_napi_do_busy_loop and remove stale entries in io_napi_blocking_busy_loop() and io_napi_sqpoll_busy_loop()
- create io_napi_remove_stale() and __io_napi_remove_stale()
- __io_napi_do_busy_loop() takes additional loop_end_arg and does stale entry detection
- io_napi_multi_busy_loop is removed. Logic is moved to io_napi_blocking_busy_loop()
- io_napi_free uses rcu function to free
- io_napi_busy_loop no longer splices
- io_napi_sqpoll_busy_poll uses rcu
- V11:
- Fixed long comment lines and whitespace issues
- Refactor new code io_cqring_wait()
- Refactor io_napi_adjust_timeout() and remove adjust_timeout
- Rename io_napi_adjust_timeout to __io_napi_adjust_timeout
- Add new function io_napi_adjust_timeout
- Cleanup calls to list_is_singular() in io_napi_multi_busy_loop() and io_napi_blocking_busy_loop()
- Cleanup io_napi_busy_loop_should_end()
- Rename __io_napi_busy_loop to __io_napi_do_busy_loop()
- V10:
- Refreshed to io-uring/for-6.4
- Repeated performance measurements for 6.4 (same/similar results)
- V9:
- refreshed to io-uring/for-6.3
- folded patch 2 and 3 into patch 4
- fixed commit description for last 2 patches
- fixed some whitespace issues
- removed io_napi_busy_loop_on helper
- removed io_napi_setup_busy helper
- renamed io_napi_end_busy_loop to io_napi_busy_loop
- removed NAPI_LIST_HEAD macro
- split io_napi_blocking_busy_loop into two functions
- added io_napi function
- comment for sqpoll check
- V8:
- added new file napi.c and add napi functions to this file
- added NAPI_LIST_HEAD function so no ifdef is necessary
- added io_napi_init and io_napi_free function
- added io_napi_setup_busy loop helper function
- added io_napi_adjust_busy_loop helper function
- added io_napi_end_busy_loop helper function
- added io_napi_sqpoll_busy_poll helper function
- some of the definitions in napi.h are macros to avoid ifdef definitions in io_uring.c, poll.c and sqpoll.c
- changed signature of io_napi_add function
- changed size of hashtable to 16. The number of entries is limited by the number of nic queues.
- Removed ternary in io_napi_blocking_busy_loop
- Rewrote io_napi_blocking_busy_loop to make it more readable
- Split off 3 more patches
- V7:
- allow unregister with NULL value for arg parameter
- return -EOPNOTSUPP if CONFIG_NET_RX_BUSY_POLL is not enabled
- V6:
- Add a hash table on top of the list for faster access during the add operation. The linked list and the hash table use the same data structure
- V5:
- Refreshed to 6.1-rc6
- Use copy_from_user instead of memdup/kfree
- Removed the moving of napi_busy_poll_to
- Return -EINVAL if any of the reserved or padded fields are not 0.
- V4:
- Pass structure for napi config, instead of individual parameters
- 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

Stefan Roesch (7):
net: split off __napi_busy_poll from napi_busy_poll
net: add napi_busy_loop_rcu()
io-uring: move io_wait_queue definition to header file
io-uring: add napi busy poll support
io-uring: add sqpoll support for napi busy poll
io_uring: add register/unregister napi function
io_uring: add prefer busy poll to register and unregister napi api

 include/linux/io_uring_types.h |  11 ++
 include/net/busy_poll.h        |   4 +
 include/uapi/linux/io_uring.h  |  12 ++
 io_uring/Makefile              |   1 +
 io_uring/io_uring.c            |  41 ++--
 io_uring/io_uring.h            |  26 +++
 io_uring/napi.c                | 331 +++++++++++++++++++++++++++++++++
 io_uring/napi.h                | 104 +++++++++++
 io_uring/poll.c                |   2 +
 io_uring/sqpoll.c              |   4 +
 net/core/dev.c                 |  34 +++-
 11 files changed, 544 insertions(+), 26 deletions(-)
 create mode 100644 io_uring/napi.c
 create mode 100644 io_uring/napi.h

base-commit: f026be0e1e881e3395c3d5418ffc8c2a2203c3f3

Signature · 1 line
2.39.1
author
#1 lore raw

PATCH v15 1/7 net: split off __napi_busy_poll from napi_busy_poll

This splits off the key part of the napi_busy_poll function into its own function __napi_busy_poll. The new function has an additional rcu parameter. This new parameter can be used when the caller is already holding the rcu read lock.

This is done in preparation for an additional napi_busy_poll() function, that doesn't take the rcu_read_lock(). The new function is introduced in the next patch.

Signed-off-by Stefan Roesch <[email protected]>
---
 net/core/dev.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)
net/core/dev.c +18 -5
index b3c13e041935..ae90265f4020 100644
@@ -6179,9 +6179,10 @@ static void busy_poll_stop(struct napi_struct *napi, void *have_poll_lock, bool
 	local_bh_enable();
 }
 
-void napi_busy_loop(unsigned int napi_id,
-		    bool (*loop_end)(void *, unsigned long),
-		    void *loop_end_arg, bool prefer_busy_poll, u16 budget)
+void __napi_busy_loop(unsigned int napi_id,
+		      bool (*loop_end)(void *, unsigned long),
+		      void *loop_end_arg, bool prefer_busy_poll, u16 budget,
+		      bool rcu)
 {
 	unsigned long start_time = loop_end ? busy_loop_current_time() : 0;
 	int (*napi_poll)(struct napi_struct *napi, int budget);

@@ -6191,7 +6192,8 @@ void napi_busy_loop(unsigned int napi_id,
 restart:
 	napi_poll = NULL;
 
-	rcu_read_lock();
+	if (!rcu)
+		rcu_read_lock();
 
 	napi = napi_by_id(napi_id);
 	if (!napi)

@@ -6237,6 +6239,8 @@ void napi_busy_loop(unsigned int napi_id,
 			break;
 
 		if (unlikely(need_resched())) {
+			if (rcu)
+				break;
 			if (napi_poll)
 				busy_poll_stop(napi, have_poll_lock, prefer_busy_poll, budget);
 			preempt_enable();

@@ -6252,7 +6256,16 @@ void napi_busy_loop(unsigned int napi_id,
 		busy_poll_stop(napi, have_poll_lock, prefer_busy_poll, budget);
 	preempt_enable();
 out:
-	rcu_read_unlock();
+	if (!rcu)
+		rcu_read_unlock();
+}
+
+void napi_busy_loop(unsigned int napi_id,
+		    bool (*loop_end)(void *, unsigned long),
+		    void *loop_end_arg, bool prefer_busy_poll, u16 budget)
+{
+	__napi_busy_loop(napi_id, loop_end, loop_end_arg, prefer_busy_poll,
+			 budget, false);
 }
 EXPORT_SYMBOL(napi_busy_loop);
Signature · 1 line
2.39.1
build bot
#2 lore raw

Re: [PATCH v15 1/7] net: split off __napi_busy_poll from napi_busy_poll

kernel test robot noticed the following build warnings:

Hi Stefan,

kernel test robot noticed the following build warnings:

[auto build test WARNING on f026be0e1e881e3395c3d5418ffc8c2a2203c3f3]

url:    https://github.com/intel-lab-lkp/linux/commits/Stefan-Roesch/net-split-off-__napi_busy_poll-from-napi_busy_poll/20230609-010104
base:   f026be0e1e881e3395c3d5418ffc8c2a2203c3f3
patch link:    https://lore.kernel.org/r/20230608163839.2891748-2-shr%40devkernel.io
patch subject: [PATCH v15 1/7] net: split off __napi_busy_poll from napi_busy_poll
config: alpha-allyesconfig (https://download.01.org/0day-ci/archive/20230609/[email protected]/config)
compiler: alpha-linux-gcc (GCC) 12.3.0

reproduce (this is a W=1 build):
mkdir -p ~/bin
wget https://raw.githubusercontent.com/intel/lkp-tests/master/sbin/make.cross -O ~/bin/make.cross chmod +x ~/bin/make.cross
git checkout f026be0e1e881e3395c3d5418ffc8c2a2203c3f3
b4 shazam https://lore.kernel.org/r/[email protected]
# save the config file
mkdir build_dir && cp config build_dir/.config
COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=alpha olddefconfig COMPILER_INSTALL_PATH=$HOME/0day COMPILER=gcc-12.3.0 ~/bin/make.cross W=1 O=build_dir ARCH=alpha SHELL=/bin/bash net/core/

If you fix the issue in a separate patch/commit (i.e. not just a new version of the same patch/commit), kindly add following tags
| Reported-by: kernel test robot <[email protected]>
| Closes: https://lore.kernel.org/oe-kbuild-all/[email protected]/

All warnings (new ones prefixed by >>):

>> net/core/dev.c:6182:6: warning: no previous prototype for '__napi_busy_loop' [-Wmissing-prototypes]

6182 | void __napi_busy_loop(unsigned int napi_id,
| ^~~~~~~~~~~~~~~~

vim +/__napi_busy_loop +6182 net/core/dev.c

6181

> 6182	void __napi_busy_loop(unsigned int napi_id,
  6183			      bool (*loop_end)(void *, unsigned long),
  6184			      void *loop_end_arg, bool prefer_busy_poll, u16 budget,
  6185			      bool rcu)

6186 {
6187 unsigned long start_time = loop_end ? busy_loop_current_time() : 0;
6188 int (*napi_poll)(struct napi_struct *napi, int budget);
6189 void *have_poll_lock = NULL;
6190 struct napi_struct *napi;
6191
6192 restart:
6193 napi_poll = NULL;
6194
6195 if (!rcu)
6196 rcu_read_lock();
6197
6198 napi = napi_by_id(napi_id);
6199 if (!napi)
6200 goto out;
6201
6202 preempt_disable();
6203 for (;;) {
6204 int work = 0;
6205
6206 local_bh_disable();
6207 if (!napi_poll) {
6208 unsigned long val = READ_ONCE(napi->state);
6209
6210 /* If multiple threads are competing for this napi,
6211 * we avoid dirtying napi->state as much as we can.
6212 */
6213 if (val & (NAPIF_STATE_DISABLE | NAPIF_STATE_SCHED |
6214 NAPIF_STATE_IN_BUSY_POLL)) {
6215 if (prefer_busy_poll)
6216 set_bit(NAPI_STATE_PREFER_BUSY_POLL, &napi->state);
6217 goto count;
6218 }
6219 if (cmpxchg(&napi->state, val,
6220 val | NAPIF_STATE_IN_BUSY_POLL |
6221 NAPIF_STATE_SCHED) != val) {
6222 if (prefer_busy_poll)
6223 set_bit(NAPI_STATE_PREFER_BUSY_POLL, &napi->state);
6224 goto count;
6225 }
6226 have_poll_lock = netpoll_poll_lock(napi);
6227 napi_poll = napi->poll;
6228 }
6229 work = napi_poll(napi, budget);
6230 trace_napi_poll(napi, work, budget);
6231 gro_normal_list(napi);
6232 count:
6233 if (work > 0)
6234 __NET_ADD_STATS(dev_net(napi->dev),
6235 LINUX_MIB_BUSYPOLLRXPACKETS, work);
6236 local_bh_enable();
6237
6238 if (!loop_end || loop_end(loop_end_arg, start_time))
6239 break;
6240
6241 if (unlikely(need_resched())) {
6242 if (rcu)
6243 break;
6244 if (napi_poll)
6245 busy_poll_stop(napi, have_poll_lock, prefer_busy_poll, budget);
6246 preempt_enable();
6247 rcu_read_unlock();
6248 cond_resched();
6249 if (loop_end(loop_end_arg, start_time))
6250 return;
6251 goto restart;
6252 }
6253 cpu_relax();
6254 }
6255 if (napi_poll)
6256 busy_poll_stop(napi, have_poll_lock, prefer_busy_poll, budget);
6257 preempt_enable();
6258 out:
6259 if (!rcu)
6260 rcu_read_unlock();
6261 }
6262

Signature · 2 lines
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki
author
#3 lore raw

PATCH v15 2/7 net: add napi_busy_loop_rcu()

In reply to Stefan Roesch

This adds the napi_busy_loop_rcu() function. This function assumes that the calling function is already holding the rcu read lock and napi_busy_loop() does not need to take the rcu read lock.

Signed-off-by Stefan Roesch <[email protected]>
---
 include/net/busy_poll.h |  4 ++++
 net/core/dev.c          | 11 +++++++++++
 2 files changed, 15 insertions(+)
include/net/busy_poll.h +4 -0
index f90f0021f5f2..622623f5740e 100644
@@ -47,6 +47,10 @@ void napi_busy_loop(unsigned int napi_id,
 		    bool (*loop_end)(void *, unsigned long),
 		    void *loop_end_arg, bool prefer_busy_poll, u16 budget);
 
+void napi_busy_loop_rcu(unsigned int napi_id,
+			bool (*loop_end)(void *, unsigned long),
+			void *loop_end_arg, bool prefer_busy_poll, u16 budget);
+
 #else /* CONFIG_NET_RX_BUSY_POLL */
 static inline unsigned long net_busy_loop_on(void)
 {
net/core/dev.c +11 -0
index ae90265f4020..60fc54c4aa42 100644
@@ -6260,6 +6260,17 @@ void __napi_busy_loop(unsigned int napi_id,
 		rcu_read_unlock();
 }
 
+/* Warning: can exit without calling need_resched(). */
+void napi_busy_loop_rcu(unsigned int napi_id,
+			bool (*loop_end)(void *, unsigned long),
+			void *loop_end_arg, bool prefer_busy_poll, u16 budget)
+{
+	WARN_ON_ONCE(!rcu_read_lock_held());
+
+	__napi_busy_loop(napi_id, loop_end, loop_end_arg, prefer_busy_poll,
+			 budget, true);
+}
+
 void napi_busy_loop(unsigned int napi_id,
 		    bool (*loop_end)(void *, unsigned long),
 		    void *loop_end_arg, bool prefer_busy_poll, u16 budget)
Signature · 1 line
2.39.1
author
#4 lore raw

PATCH v15 3/7 io-uring: move io_wait_queue definition to header file

In reply to Stefan Roesch

This moves the definition of the io_wait_queue structure to the header file so it can be also used from other files.

Signed-off-by Stefan Roesch <[email protected]>
---
 io_uring/io_uring.c | 21 ---------------------
 io_uring/io_uring.h | 22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 21 deletions(-)
io_uring/io_uring.c +0 -21
index c99a7a0c3f21..6b1a1ac38061 100644
@@ -2499,33 +2499,12 @@ int io_submit_sqes(struct io_ring_ctx *ctx, unsigned int nr)
 	return ret;
 }
 
-struct io_wait_queue {
-	struct wait_queue_entry wq;
-	struct io_ring_ctx *ctx;
-	unsigned cq_tail;
-	unsigned nr_timeouts;
-	ktime_t timeout;
-};
-
 static inline bool io_has_work(struct io_ring_ctx *ctx)
 {
 	return test_bit(IO_CHECK_CQ_OVERFLOW_BIT, &ctx->check_cq) ||
 	       !llist_empty(&ctx->work_llist);
 }
 
-static inline bool io_should_wake(struct io_wait_queue *iowq)
-{
-	struct io_ring_ctx *ctx = iowq->ctx;
-	int dist = READ_ONCE(ctx->rings->cq.tail) - (int) iowq->cq_tail;
-
-	/*
-	 * Wake up if we have enough events, or if a timeout occurred since we
-	 * started waiting. For timeouts, we always want to return to userspace,
-	 * regardless of event count.
-	 */
-	return dist >= 0 || atomic_read(&ctx->cq_timeouts) != iowq->nr_timeouts;
-}
-
 static int io_wake_function(struct wait_queue_entry *curr, unsigned int mode,
 			    int wake_flags, void *key)
 {
io_uring/io_uring.h +22 -0
index 9b8dfb3bb2b4..13f87accbdfe 100644
@@ -41,6 +41,28 @@ enum {
 	IOU_STOP_MULTISHOT	= -ECANCELED,
 };
 
+struct io_wait_queue {
+	struct wait_queue_entry wq;
+	struct io_ring_ctx *ctx;
+	unsigned cq_tail;
+	unsigned nr_timeouts;
+	ktime_t timeout;
+
+};
+
+static inline bool io_should_wake(struct io_wait_queue *iowq)
+{
+	struct io_ring_ctx *ctx = iowq->ctx;
+	int dist = READ_ONCE(ctx->rings->cq.tail) - (int) iowq->cq_tail;
+
+	/*
+	 * Wake up if we have enough events, or if a timeout occurred since we
+	 * started waiting. For timeouts, we always want to return to userspace,
+	 * regardless of event count.
+	 */
+	return dist >= 0 || atomic_read(&ctx->cq_timeouts) != iowq->nr_timeouts;
+}
+
 struct io_uring_cqe *__io_get_cqe(struct io_ring_ctx *ctx, bool overflow);
 bool io_req_cqe_overflow(struct io_kiocb *req);
 int io_run_task_work_sig(struct io_ring_ctx *ctx);
Signature · 1 line
2.39.1
author
#5 lore raw

PATCH v15 4/7 io-uring: add napi busy poll support

In reply to Stefan Roesch

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. The list is synchronized by the new napi_lock spin lock. The current default napi busy polling time is stored in napi_busy_poll_to. If napi busy polling is not enabled, the value is 0.

In addition there is also a hash table. The hash table store the napi id and the pointer to the above list nodes. The hash table is used to speed up the lookup to the list elements. The hash table is synchronized with rcu.

The NAPI_TIMEOUT is stored as a timeout to make sure that the time a napi entry is stored in the napi list is limited.

The busy poll timeout is also stored as part of the io_wait_queue. This is necessary as for sq polling the poll interval needs to be adjusted and the napi callback allows only to pass in one value.

This has been tested with two simple programs from the liburing library
repository: the napi client and the napi server program. The client sends a request, which has a timestamp in its payload and the server replies with the same payload. The client calculates the roundtrip time and stores it to calculate the results.

The client is running on host1 and the server is running on host 2 (in the same rack). The measured times below are roundtrip times. They are average times over 5 runs each. Each run measures 1 million roundtrips.

no rx coal rx coal: frames=88,usecs=33
Default 57us 56us

client_poll=100us 47us 46us

server_poll=100us 51us 46us

client_poll=100us+ 40us 40us
server_poll=100us

client_poll=100us+ 41us 39us
server_poll=100us+
prefer napi busy poll on client

client_poll=100us+ 41us 39us
server_poll=100us+
prefer napi busy poll on server

client_poll=100us+ 41us 39us
server_poll=100us+
prefer napi busy poll on client + server

Signed-off-by Stefan Roesch <[email protected]>
Suggested-by Olivier Langlois <[email protected]>
Acked-by Jakub Kicinski <[email protected]>
---
 include/linux/io_uring_types.h |  11 ++
 io_uring/Makefile              |   1 +
 io_uring/io_uring.c            |   8 ++
 io_uring/io_uring.h            |   4 +
 io_uring/napi.c                | 255 +++++++++++++++++++++++++++++++++
 io_uring/napi.h                |  89 ++++++++++++
 io_uring/poll.c                |   2 +
 7 files changed, 370 insertions(+)
 create mode 100644 io_uring/napi.c
 create mode 100644 io_uring/napi.h
include/linux/io_uring_types.h +11 -0
index f04ce513fadb..71068f67ca30 100644
@@ -2,6 +2,7 @@
 #define IO_URING_TYPES_H
 
 #include <linux/blkdev.h>
+#include <linux/hashtable.h>
 #include <linux/task_work.h>
 #include <linux/bitmap.h>
 #include <linux/llist.h>

@@ -287,6 +288,16 @@ struct io_ring_ctx {
 	struct xarray		personalities;
 	u32			pers_next;
 
+#ifdef CONFIG_NET_RX_BUSY_POLL
+	struct list_head	napi_list;	/* track busy poll napi_id */
+	spinlock_t		napi_lock;	/* napi_list lock */
+
+	DECLARE_HASHTABLE(napi_ht, 4);
+	/* napi busy poll default timeout */
+	unsigned int		napi_busy_poll_to;
+	bool			napi_prefer_busy_poll;
+#endif
+
 	struct {
 		/*
 		 * We cache a range of free CQEs we can use, once exhausted it
io_uring/Makefile +1 -0
index 8cc8e5387a75..2efe7c5f07ba 100644
@@ -9,3 +9,4 @@ obj-$(CONFIG_IO_URING)		+= io_uring.o xattr.o nop.o fs.o splice.o \
 					sqpoll.o fdinfo.o tctx.o poll.o \
 					cancel.o kbuf.o rsrc.o rw.o opdef.o notif.o
 obj-$(CONFIG_IO_WQ)		+= io-wq.o
+obj-$(CONFIG_NET_RX_BUSY_POLL) += napi.o
io_uring/io_uring.c +8 -0
index 6b1a1ac38061..6378089aa385 100644
@@ -91,6 +91,7 @@
 #include "rsrc.h"
 #include "cancel.h"
 #include "net.h"
+#include "napi.h"
 #include "notif.h"
 
 #include "timeout.h"

@@ -337,6 +338,8 @@ static __cold struct io_ring_ctx *io_ring_ctx_alloc(struct io_uring_params *p)
 	INIT_WQ_LIST(&ctx->locked_free_list);
 	INIT_DELAYED_WORK(&ctx->fallback_work, io_fallback_req_func);
 	INIT_WQ_LIST(&ctx->submit_state.compl_reqs);
+	io_napi_init(ctx);
+
 	return ctx;
 err:
 	kfree(ctx->dummy_ubuf);

@@ -2602,9 +2605,13 @@ static int io_cqring_wait(struct io_ring_ctx *ctx, int min_events,
 
 		if (get_timespec64(&ts, uts))
 			return -EFAULT;
+
 		iowq.timeout = ktime_add_ns(timespec64_to_ktime(ts), ktime_get_ns());
+		io_napi_adjust_timeout(ctx, &iowq, &ts);
 	}
 
+	io_napi_busy_loop(ctx, &iowq);
+
 	trace_io_uring_cqring_wait(ctx, min_events);
 	do {
 		unsigned long check_cq;

@@ -2923,6 +2930,7 @@ static __cold void io_ring_ctx_free(struct io_ring_ctx *ctx)
 	io_req_caches_free(ctx);
 	if (ctx->hash_map)
 		io_wq_put_hash(ctx->hash_map);
+	io_napi_free(ctx);
 	kfree(ctx->cancel_table.hbs);
 	kfree(ctx->cancel_table_locked.hbs);
 	kfree(ctx->dummy_ubuf);
io_uring/io_uring.h +4 -0
index 13f87accbdfe..7417e1214da4 100644
@@ -48,6 +48,10 @@ struct io_wait_queue {
 	unsigned nr_timeouts;
 	ktime_t timeout;
 
+#ifdef CONFIG_NET_RX_BUSY_POLL
+	unsigned int napi_busy_poll_to;
+	bool napi_prefer_busy_poll;
+#endif
 };
 
 static inline bool io_should_wake(struct io_wait_queue *iowq)
io_uring/napi.c new file +255 -0

255 lines not on this page · raw message

io_uring/napi.h new file +89 -0

89 lines not on this page · raw message

io_uring/poll.c +2 -0
index c90e47dc1e29..0284849793bb 100644
@@ -15,6 +15,7 @@
 
 #include "io_uring.h"
 #include "refs.h"
+#include "napi.h"
 #include "opdef.h"
 #include "kbuf.h"
 #include "poll.h"

@@ -631,6 +632,7 @@ static int __io_arm_poll_handler(struct io_kiocb *req,
 		__io_poll_execute(req, mask);
 		return 0;
 	}
+	io_napi_add(req);
 
 	if (ipt->owning) {
 		/*
Signature · 1 line
2.39.1
author
#6 lore raw

PATCH v15 5/7 io-uring: add sqpoll support for napi busy poll

In reply to Stefan Roesch

This adds the sqpoll support to the io-uring napi.

Signed-off-by Stefan Roesch <[email protected]>
Suggested-by Olivier Langlois <[email protected]>
---
 io_uring/napi.c   | 24 ++++++++++++++++++++++++
 io_uring/napi.h   |  6 +++++-
 io_uring/sqpoll.c |  4 ++++
 3 files changed, 33 insertions(+), 1 deletion(-)
io_uring/napi.c +24 -0
index 1112cc39153c..3e578df36cc5 100644
@@ -252,4 +252,28 @@ void __io_napi_busy_loop(struct io_ring_ctx *ctx, struct io_wait_queue *iowq)
 		io_napi_blocking_busy_loop(ctx, iowq);
 }
 
+/*
+ * io_napi_sqpoll_busy_poll() - busy poll loop for sqpoll
+ * @ctx: pointer to io-uring context structure
+ *
+ * Splice of the napi list and execute the napi busy poll loop.
+ */
+int io_napi_sqpoll_busy_poll(struct io_ring_ctx *ctx)
+{
+	LIST_HEAD(napi_list);
+	bool is_stale = false;
+
+	if (!READ_ONCE(ctx->napi_busy_poll_to))
+		return 0;
+	if (list_empty_careful(&ctx->napi_list))
+		return 0;
+
+	rcu_read_lock();
+	is_stale = __io_napi_do_busy_loop(ctx, NULL);
+	rcu_read_unlock();
+
+	io_napi_remove_stale(ctx, is_stale);
+	return 1;
+}
+
 #endif
io_uring/napi.h +5 -1
index be8aa8ee32d9..b6d6243fc7fe 100644
@@ -17,6 +17,7 @@ void __io_napi_add(struct io_ring_ctx *ctx, struct socket *sock);
 void __io_napi_adjust_timeout(struct io_ring_ctx *ctx,
 		struct io_wait_queue *iowq, struct timespec64 *ts);
 void __io_napi_busy_loop(struct io_ring_ctx *ctx, struct io_wait_queue *iowq);
+int io_napi_sqpoll_busy_poll(struct io_ring_ctx *ctx);
 
 static inline bool io_napi(struct io_ring_ctx *ctx)
 {

@@ -83,7 +84,10 @@ static inline void io_napi_busy_loop(struct io_ring_ctx *ctx,
 				     struct io_wait_queue *iowq)
 {
 }
-
+static inline int io_napi_sqpoll_busy_poll(struct io_ring_ctx *ctx)
+{
+	return 0;
+}
 #endif /* CONFIG_NET_RX_BUSY_POLL */
 
 #endif
io_uring/sqpoll.c +4 -0
index 9db4bc1f521a..0c8d53ef134a 100644
@@ -15,6 +15,7 @@
 #include <uapi/linux/io_uring.h>
 
 #include "io_uring.h"
+#include "napi.h"
 #include "sqpoll.h"
 
 #define IORING_SQPOLL_CAP_ENTRIES_VALUE 8

@@ -193,6 +194,9 @@ static int __io_sq_thread(struct io_ring_ctx *ctx, bool cap_entries)
 			ret = io_submit_sqes(ctx, to_submit);
 		mutex_unlock(&ctx->uring_lock);
 
+		if (io_napi(ctx))
+			ret += io_napi_sqpoll_busy_poll(ctx);
+
 		if (to_submit && wq_has_sleeper(&ctx->sqo_sq_wait))
 			wake_up(&ctx->sqo_sq_wait);
 		if (creds)
Signature · 1 line
2.39.1
author
#7 lore raw

PATCH v15 6/7 io_uring: add register/unregister napi function

In reply to Stefan Roesch

This adds an api to register and unregister the napi for io-uring. If the arg value is specified when unregistering, the current napi setting for the busy poll timeout is copied into the user structure. If this is not required, NULL can be passed as the arg value.

Signed-off-by Stefan Roesch <[email protected]>
Acked-by Jakub Kicinski <[email protected]>
---
 include/uapi/linux/io_uring.h | 11 ++++++++
 io_uring/io_uring.c           | 12 +++++++++
 io_uring/napi.c               | 48 +++++++++++++++++++++++++++++++++++
 io_uring/napi.h               | 11 ++++++++
 4 files changed, 82 insertions(+)
include/uapi/linux/io_uring.h +11 -0
index f222d263bc55..cac3d55e002b 100644
@@ -535,6 +535,10 @@ enum {
 	/* register a range of fixed file slots for automatic slot allocation */
 	IORING_REGISTER_FILE_ALLOC_RANGE	= 25,
 
+	/* set/clear busy poll settings */
+	IORING_REGISTER_NAPI			= 26,
+	IORING_UNREGISTER_NAPI			= 27,
+
 	/* this goes last */
 	IORING_REGISTER_LAST,
 

@@ -661,6 +665,13 @@ struct io_uring_buf_reg {
 	__u64	resv[3];
 };
 
+/* argument for IORING_(UN)REGISTER_NAPI */
+struct io_uring_napi {
+	__u32	busy_poll_to;
+	__u32	pad;
+	__u64	resv;
+};
+
 /*
  * io_uring_restriction->opcode values
  */
io_uring/io_uring.c +12 -0
index 6378089aa385..958bbedddaa0 100644
@@ -4496,6 +4496,18 @@ static int __io_uring_register(struct io_ring_ctx *ctx, unsigned opcode,
 			break;
 		ret = io_register_file_alloc_range(ctx, arg);
 		break;
+	case IORING_REGISTER_NAPI:
+		ret = -EINVAL;
+		if (!arg || nr_args != 1)
+			break;
+		ret = io_register_napi(ctx, arg);
+		break;
+	case IORING_UNREGISTER_NAPI:
+		ret = -EINVAL;
+		if (nr_args != 1)
+			break;
+		ret = io_unregister_napi(ctx, arg);
+		break;
 	default:
 		ret = -EINVAL;
 		break;
io_uring/napi.c +48 -0

54 lines not on this page · raw message

io_uring/napi.h +11 -0
index b6d6243fc7fe..6fc0393d0dbe 100644
@@ -12,6 +12,9 @@
 void io_napi_init(struct io_ring_ctx *ctx);
 void io_napi_free(struct io_ring_ctx *ctx);
 
+int io_register_napi(struct io_ring_ctx *ctx, void __user *arg);
+int io_unregister_napi(struct io_ring_ctx *ctx, void __user *arg);
+
 void __io_napi_add(struct io_ring_ctx *ctx, struct socket *sock);
 
 void __io_napi_adjust_timeout(struct io_ring_ctx *ctx,

@@ -68,6 +71,14 @@ static inline void io_napi_init(struct io_ring_ctx *ctx)
 static inline void io_napi_free(struct io_ring_ctx *ctx)
 {
 }
+static inline int io_register_napi(struct io_ring_ctx *ctx, void __user *arg)
+{
+	return -EOPNOTSUPP;
+}
+static inline int io_unregister_napi(struct io_ring_ctx *ctx, void __user *arg)
+{
+	return -EOPNOTSUPP;
+}
 static inline bool io_napi(struct io_ring_ctx *ctx)
 {
 	return false;
Signature · 1 line
2.39.1
author
#8 lore raw

PATCH v15 7/7 io_uring: add prefer busy poll to register and unregister napi api

In reply to Stefan Roesch

This adds the napi prefer busy poll setting to the register and unregister napi api. When napi is unregistered and arg is specified, both napi settings: busy poll timeout and the prefer busy poll setting are copied into the user structure.

Signed-off-by Stefan Roesch <[email protected]>
Acked-by Jakub Kicinski <[email protected]>
---
 include/uapi/linux/io_uring.h |  3 ++-
 io_uring/napi.c               | 10 +++++++---
 2 files changed, 9 insertions(+), 4 deletions(-)
include/uapi/linux/io_uring.h +2 -1
index cac3d55e002b..02122894056b 100644
@@ -668,7 +668,8 @@ struct io_uring_buf_reg {
 /* argument for IORING_(UN)REGISTER_NAPI */
 struct io_uring_napi {
 	__u32	busy_poll_to;
-	__u32	pad;
+	__u8	prefer_busy_poll;
+	__u8	pad[3];
 	__u64	resv;
 };
io_uring/napi.c +7 -3
index b1a3ed9d1c2e..8ec016899539 100644
@@ -217,16 +217,18 @@ void io_napi_free(struct io_ring_ctx *ctx)
 int io_register_napi(struct io_ring_ctx *ctx, void __user *arg)
 {
 	const struct io_uring_napi curr = {
-		.busy_poll_to = ctx->napi_busy_poll_to,
+		.busy_poll_to 	  = ctx->napi_busy_poll_to,
+		.prefer_busy_poll = ctx->napi_prefer_busy_poll
 	};
 	struct io_uring_napi napi;
 
 	if (copy_from_user(&napi, arg, sizeof(napi)))
 		return -EFAULT;
-	if (napi.pad || napi.resv)
+	if (napi.pad[0] || napi.pad[1] || napi.pad[2] || napi.resv)
 		return -EINVAL;
 
 	WRITE_ONCE(ctx->napi_busy_poll_to, napi.busy_poll_to);
+	WRITE_ONCE(ctx->napi_prefer_busy_poll, !!napi.prefer_busy_poll);
 
 	if (copy_to_user(arg, &curr, sizeof(curr)))
 		return -EFAULT;

@@ -245,13 +247,15 @@ int io_register_napi(struct io_ring_ctx *ctx, void __user *arg)
 int io_unregister_napi(struct io_ring_ctx *ctx, void __user *arg)
 {
 	const struct io_uring_napi curr = {
-		.busy_poll_to = ctx->napi_busy_poll_to,
+		.busy_poll_to 	  = ctx->napi_busy_poll_to,
+		.prefer_busy_poll = ctx->napi_prefer_busy_poll
 	};
 
 	if (arg && copy_to_user(arg, &curr, sizeof(curr)))
 		return -EFAULT;
 
 	WRITE_ONCE(ctx->napi_busy_poll_to, 0);
+	WRITE_ONCE(ctx->napi_prefer_busy_poll, false);
 	return 0;
 }
Signature · 1 line
2.39.1
#9 lore raw
In reply to Stefan Roesch

Hi,

I was wondering what did happen to this patch submission...

It seems like Stefan did put a lot of effort in addressing every reported issue for several weeks/months...

and then nothing... as if this patch has never been reviewed by anyone...

has it been decided to not integrate NAPI busy looping in io_uring privately finally?

Quoted 156 lines · Stefan Roesch

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. For faster access it also adds a hash table.

When a new napi id is added, the hash table is used to locate if the napi id has already been added. When processing the busy poll loop the list is used to process the individual elements.

io-uring allows specifying two parameters:
- busy poll timeout and
- prefer busy poll to call of io_napi_busy_loop()
This sets the above parameters for the ring. The settings are passed with a new structure io_uring_napi.

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. More detailled results are part of the commit message of the first patch.

Changes:
- V15:
  - Combined _napi_busy_loop() and __napi_busy_loop() function
  - Rephrased comment
- V14:
  - Rephrased comment for napi_busy_loop_rcu() funnction
  - Added new function _napi_busy_loop() to remove code duplication in napi_busy_loop() and napi_busy_loop_rcu()
- V13:
  - split off __napi_busy_loop() from napi_busy_loop()
  - introduce napi_busy_loop_no_lock()
  - use napi_busy_loop_no_lock in io_napi_blocking_busy_loop
- V12:
  - introduce io_napi_hash_find()
  - use rcu for changes to the hash table
  - use rcu for searching if a napi id is in the napi hash table
  - use rcu hlist functions for adding and removing items from the hash
    table
  - add stale entry detection in __io_napi_do_busy_loop and remove stale
    entries in io_napi_blocking_busy_loop() and io_napi_sqpoll_busy_loop()
  - create io_napi_remove_stale() and __io_napi_remove_stale()
  - __io_napi_do_busy_loop() takes additional loop_end_arg and does stale
    entry detection
  - io_napi_multi_busy_loop is removed. Logic is moved to io_napi_blocking_busy_loop()
  - io_napi_free uses rcu function to free
  - io_napi_busy_loop no longer splices
  - io_napi_sqpoll_busy_poll uses rcu
- V11:
  - Fixed long comment lines and whitespace issues
  - Refactor new code io_cqring_wait()
  - Refactor io_napi_adjust_timeout() and remove adjust_timeout
  - Rename io_napi_adjust_timeout to __io_napi_adjust_timeout
  - Add new function io_napi_adjust_timeout
  - Cleanup calls to list_is_singular() in io_napi_multi_busy_loop() and io_napi_blocking_busy_loop()
  - Cleanup io_napi_busy_loop_should_end()
  - Rename __io_napi_busy_loop to __io_napi_do_busy_loop()
- V10:
  - Refreshed to io-uring/for-6.4
  - Repeated performance measurements for 6.4 (same/similar results)
- V9:
  - refreshed to io-uring/for-6.3
  - folded patch 2 and 3 into patch 4
  - fixed commit description for last 2 patches
  - fixed some whitespace issues
  - removed io_napi_busy_loop_on helper
  - removed io_napi_setup_busy helper
  - renamed io_napi_end_busy_loop to io_napi_busy_loop
  - removed NAPI_LIST_HEAD macro
  - split io_napi_blocking_busy_loop into two functions
  - added io_napi function
  - comment for sqpoll check
- V8:
  - added new file napi.c and add napi functions to this file
  - added NAPI_LIST_HEAD function so no ifdef is necessary
  - added io_napi_init and io_napi_free function
  - added io_napi_setup_busy loop helper function
  - added io_napi_adjust_busy_loop helper function
  - added io_napi_end_busy_loop helper function
  - added io_napi_sqpoll_busy_poll helper function
  - some of the definitions in napi.h are macros to avoid ifdef definitions in io_uring.c, poll.c and sqpoll.c
  - changed signature of io_napi_add function
  - changed size of hashtable to 16. The number of entries is limited by the number of nic queues.
  - Removed ternary in io_napi_blocking_busy_loop
  - Rewrote io_napi_blocking_busy_loop to make it more readable
  - Split off 3 more patches
- V7:
  - allow unregister with NULL value for arg parameter
  - return -EOPNOTSUPP if CONFIG_NET_RX_BUSY_POLL is not enabled
- V6:
  - Add a hash table on top of the list for faster access during the add operation. The linked list and the hash table use the same data structure
- V5:
  - Refreshed to 6.1-rc6
  - Use copy_from_user instead of memdup/kfree
  - Removed the moving of napi_busy_poll_to
  - Return -EINVAL if any of the reserved or padded fields are not 0.
- V4:
  - Pass structure for napi config, instead of individual parameters
- 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

Stefan Roesch (7):
  net: split off __napi_busy_poll from napi_busy_poll
  net: add napi_busy_loop_rcu()
  io-uring: move io_wait_queue definition to header file
  io-uring: add napi busy poll support
  io-uring: add sqpoll support for napi busy poll
  io_uring: add register/unregister napi function
  io_uring: add prefer busy poll to register and unregister napi api

 include/linux/io_uring_types.h |  11 ++
 include/net/busy_poll.h        |   4 +
 include/uapi/linux/io_uring.h  |  12 ++
 io_uring/Makefile              |   1 +
 io_uring/io_uring.c            |  41 ++--
 io_uring/io_uring.h            |  26 +++
 io_uring/napi.c                | 331
+++++++++++++++++++++++++++++++++
 io_uring/napi.h                | 104 +++++++++++
 io_uring/poll.c                |   2 +
 io_uring/sqpoll.c              |   4 +
 net/core/dev.c                 |  34 +++-

 11 files changed, 544 insertions(+), 26 deletions(-)

 create mode 100644 io_uring/napi.c
 create mode 100644 io_uring/napi.h

base-commit: f026be0e1e881e3395c3d5418ffc8c2a2203c3f3

maintainer
#10 lore raw
Quoted 4 lines · Olivier Langlois

Hi,

I was wondering what did happen to this patch submission...

Quoted 8 lines

It seems like Stefan did put a lot of effort in addressing every reported issue for several weeks/months...

and then nothing... as if this patch has never been reviewed by anyone...

has it been decided to not integrate NAPI busy looping in io_uring privately finally?

It's really just waiting for testing, I want to ensure it's working as we want it to before committing. But the production bits I wanted to test on have been dragging out, hence I have not made any moves towards merging this for upstream just yet.

FWIW, I have been maintaining the patchset, you can find the current series here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-napi

Signature · 1 line
Jens Axboe
#11 lore raw
Quoted 21 lines · Jens Axboe
Quoted 4 lines · Olivier Langlois

Hi,

I was wondering what did happen to this patch submission...

Quoted 8 lines

It seems like Stefan did put a lot of effort in addressing every reported issue for several weeks/months...

and then nothing... as if this patch has never been reviewed by anyone...

has it been decided to not integrate NAPI busy looping in io_uring privately finally?

It's really just waiting for testing, I want to ensure it's working as
we want it to before committing. But the production bits I wanted to test on have been dragging out, hence I have not made any moves towards
merging this for upstream just yet.

Quoted 5 lines

FWIW, I have been maintaining the patchset, you can find the current series here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-napi

Hi Jens,

ok thx for the update... Since I am a big user of the io_uring napi busy polling, testing the official patchset is definitely something that I can do to help...

I should be able to report back the result of my testing in few days!

Tested-by
#12 lore raw
In reply to Jens Axboe
Quoted 21 lines · Jens Axboe
Quoted 4 lines · Olivier Langlois

Hi,

I was wondering what did happen to this patch submission...

Quoted 8 lines

It seems like Stefan did put a lot of effort in addressing every reported issue for several weeks/months...

and then nothing... as if this patch has never been reviewed by anyone...

has it been decided to not integrate NAPI busy looping in io_uring privately finally?

It's really just waiting for testing, I want to ensure it's working as
we want it to before committing. But the production bits I wanted to test on have been dragging out, hence I have not made any moves towards
merging this for upstream just yet.

Quoted 5 lines

FWIW, I have been maintaining the patchset, you can find the current series here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-napi

test setup:
-----------
- kernel 6.7.2 with Jens patchset applied (It did almost work as-is except for modifs in io_uring/register.c that was in io_uring/io_uring.c in 6.7.2)
- liburing 2.5 patched with Stefan patch after having carefully make sure that IORING_REGISTER_NAPI,IORING_UNREGISTER_NAPI values match the ones found in the kernel. (It was originally 26,27 and it is now 27,28)
- 3 threads each having their own private io_uring ring.

thread 1:
- use SQ_POLL kernel thread
- reads data stream from 15-20 TCP connections
- enable NAPI busy polling by calling io_uring_register_napi()

[2024-01-31 08:59:55] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 3(fd 43), napi_id:31 [2024-01-31 08:59:55] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 8(fd 38), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 10(fd 36), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 14(fd 32), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 12(fd 34), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 2(fd 44), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 16(fd 30), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 9(fd 37), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 20(fd 26), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 1(fd 45), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 6(fd 40), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 13(fd 33), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 22(fd 22), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 7(fd 39), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 18(fd 28), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 19(fd 27), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1028 LWS_CALLBACK_CLIENT_ESTABLISHED client 23(fd 21), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 4(fd 42), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 5(fd 41), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 21(fd 24), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 17(fd 29), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 15(fd 31), napi_id:28 [2024-01-31 08:59:57] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 11(fd 35), napi_id:30 [2024-01-31 09:00:14] INFO WSBASE/client_established 1031 LWS_CALLBACK_CLIENT_ESTABLISHED client 24(fd 25), napi_id:30

thread 2:
- No SQ_POLL
- reads data stream from 1 TCP socket
- enable NAPI busy polling by calling io_uring_register_napi()

[2024-01-31 09:01:45] INFO WSBASE/client_established 1031 LWS_CALLBACK_CLIENT_ESTABLISHED client 25(fd 23), napi_id:31

thread 3:
- No SQ_POLL
- No NAPI busy polling
- read data stream from 1 TCP socket

Outcome:
--------

I did not measure latency to make sure that NAPI polling was effective but I did ensure the stability of running the patchset by letting the program run for 5+ hours non stop without experiencing any glitches

Tested-by Olivier Langlois <[email protected]>
maintainer
#13 lore raw
Quoted 105 lines · Olivier Langlois
Quoted 21 lines · Jens Axboe
Quoted 4 lines · Olivier Langlois

Hi,

I was wondering what did happen to this patch submission...

Quoted 8 lines

It seems like Stefan did put a lot of effort in addressing every reported issue for several weeks/months...

and then nothing... as if this patch has never been reviewed by anyone...

has it been decided to not integrate NAPI busy looping in io_uring privately finally?

It's really just waiting for testing, I want to ensure it's working as
we want it to before committing. But the production bits I wanted to test on have been dragging out, hence I have not made any moves towards
merging this for upstream just yet.

Quoted 5 lines

FWIW, I have been maintaining the patchset, you can find the current series here:

https://git.kernel.dk/cgit/linux/log/?h=io_uring-napi

test setup:
-----------
- kernel 6.7.2 with Jens patchset applied (It did almost work as-is except for modifs in io_uring/register.c that was in io_uring/io_uring.c in 6.7.2)
- liburing 2.5 patched with Stefan patch after having carefully make sure that IORING_REGISTER_NAPI,IORING_UNREGISTER_NAPI values match the ones found in the kernel. (It was originally 26,27 and it is now 27,28)
- 3 threads each having their own private io_uring ring.

thread 1:
- use SQ_POLL kernel thread
- reads data stream from 15-20 TCP connections
- enable NAPI busy polling by calling io_uring_register_napi()

[2024-01-31 08:59:55] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 3(fd 43), napi_id:31 [2024-01-31 08:59:55] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 8(fd 38), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 10(fd 36), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 14(fd 32), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 12(fd 34), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 2(fd 44), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 16(fd 30), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 9(fd 37), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 20(fd 26), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 1(fd 45), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 6(fd 40), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 13(fd 33), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 22(fd 22), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 7(fd 39), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 18(fd 28), napi_id:28 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 19(fd 27), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1028 LWS_CALLBACK_CLIENT_ESTABLISHED client 23(fd 21), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 4(fd 42), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 5(fd 41), napi_id:25 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 21(fd 24), napi_id:31 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 17(fd 29), napi_id:30 [2024-01-31 08:59:56] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 15(fd 31), napi_id:28 [2024-01-31 08:59:57] INFO WSBASE/client_established 1010 LWS_CALLBACK_CLIENT_ESTABLISHED client 11(fd 35), napi_id:30 [2024-01-31 09:00:14] INFO WSBASE/client_established 1031 LWS_CALLBACK_CLIENT_ESTABLISHED client 24(fd 25), napi_id:30

thread 2:
- No SQ_POLL
- reads data stream from 1 TCP socket
- enable NAPI busy polling by calling io_uring_register_napi()

[2024-01-31 09:01:45] INFO WSBASE/client_established 1031 LWS_CALLBACK_CLIENT_ESTABLISHED client 25(fd 23), napi_id:31

thread 3:
- No SQ_POLL
- No NAPI busy polling
- read data stream from 1 TCP socket

Quoted 6 lines

Outcome:
--------

I did not measure latency to make sure that NAPI polling was effective but I did ensure the stability of running the patchset by letting the program run for 5+ hours non stop without experiencing any glitches

Thanks for testing!

Any chance that you could run some tests with and without NAPI that help validate that it actually works? That part is what I'm most interested in, not too worried about the stability of it as I have scrutinized it pretty close already.

Signature · 1 line
Jens Axboe
#14 lore raw
Quoted 11 lines · Jens Axboe

Thanks for testing!

Any chance that you could run some tests with and without NAPI that help
validate that it actually works? That part is what I'm most interested
in, not too worried about the stability of it as I have scrutinized it
pretty close already.

There is maybe a test that I can perform. The data that I receive is timestamped. I have a small test program that checks the age of the updates on their reception...

I would expect that it should be possible to perceive the busy polling effect by comparing the average update age with and without the feature enabled...

A word of warning... The service that my client is connecting to has relocated recently. I used to have an RTT of about 8mSec with it to about 400-500 mSec today...

because of the huge RTT, I am unsure that the test is going to be conclusive at all...

However, I am also in the process of relocating my client closer to the service. If you can wait a week or so, I should able to do that test with a RTT < 1 mSec...

Beside that, I could redo the same test that Stefan did with the ping client/server setup but would that test add any value to the current collective knowledge?

I'll do the update age test when I restart my client and I'll report back the result but my expectations aren't very high that it is going to be conclusive due to the huge RTT.

#15 lore raw
Quoted 35 lines · Olivier Langlois
Quoted 11 lines · Jens Axboe

Thanks for testing!

Any chance that you could run some tests with and without NAPI that help
validate that it actually works? That part is what I'm most interested
in, not too worried about the stability of it as I have scrutinized it
pretty close already.

There is maybe a test that I can perform. The data that I receive is timestamped. I have a small test program that checks the age of the updates on their reception...

I would expect that it should be possible to perceive the busy polling
effect by comparing the average update age with and without the feature
enabled...

A word of warning... The service that my client is connecting to has relocated recently. I used to have an RTT of about 8mSec with it to about 400-500 mSec today...

because of the huge RTT, I am unsure that the test is going to be conclusive at all...

However, I am also in the process of relocating my client closer to the
service. If you can wait a week or so, I should able to do that test with a RTT < 1 mSec...

Quoted 9 lines

Beside that, I could redo the same test that Stefan did with the ping client/server setup but would that test add any value to the current collective knowledge?

I'll do the update age test when I restart my client and I'll report back the result but my expectations aren't very high that it is going to be conclusive due to the huge RTT.

As I expected, the busy polling difference in the update age test is so small compared to the RTT that the result is inconclusive, IMHO...

The number of collected updates to build the stats is 500.

System clocks are assumed to be synchronized and the RTT is the difference between the local time and the update timestamp. Actually, it may be more accurate to say that the displayed RTT values are in fact TT...

latency NO napi busy poll:
[2024-01-31 11:28:34] INFO Main/processCollectedData rtt min/avg/max/mdev = 74.509/76.752/115.969/3.110 ms

latency napi busy poll:
[2024-01-31 11:33:05] INFO Main/processCollectedData rtt min/avg/max/mdev = 75.347/76.740/134.588/1.648 ms

I'll redo the test once my RTT is closer to 1mSec. The relative gain should be more impressive...

maintainer
#16 lore raw
Quoted 59 lines · Olivier Langlois
Quoted 35 lines · Olivier Langlois
Quoted 11 lines · Jens Axboe

Thanks for testing!

Any chance that you could run some tests with and without NAPI that help
validate that it actually works? That part is what I'm most interested
in, not too worried about the stability of it as I have scrutinized it
pretty close already.

There is maybe a test that I can perform. The data that I receive is timestamped. I have a small test program that checks the age of the updates on their reception...

I would expect that it should be possible to perceive the busy polling
effect by comparing the average update age with and without the feature
enabled...

A word of warning... The service that my client is connecting to has relocated recently. I used to have an RTT of about 8mSec with it to about 400-500 mSec today...

because of the huge RTT, I am unsure that the test is going to be conclusive at all...

However, I am also in the process of relocating my client closer to the
service. If you can wait a week or so, I should able to do that test with a RTT < 1 mSec...

Quoted 9 lines

Beside that, I could redo the same test that Stefan did with the ping client/server setup but would that test add any value to the current collective knowledge?

I'll do the update age test when I restart my client and I'll report back the result but my expectations aren't very high that it is going to be conclusive due to the huge RTT.

As I expected, the busy polling difference in the update age test is so small compared to the RTT that the result is inconclusive, IMHO...

The number of collected updates to build the stats is 500.

System clocks are assumed to be synchronized and the RTT is the difference between the local time and the update timestamp. Actually, it may be more accurate to say that the displayed RTT values are in fact TT...

latency NO napi busy poll:
[2024-01-31 11:28:34] INFO Main/processCollectedData rtt min/avg/max/mdev = 74.509/76.752/115.969/3.110 ms

Quoted 6 lines

latency napi busy poll:
[2024-01-31 11:33:05] INFO Main/processCollectedData rtt min/avg/max/mdev = 75.347/76.740/134.588/1.648 ms

I'll redo the test once my RTT is closer to 1mSec. The relative gain should be more impressive...

Also happy to try and run it here, if you can share it? If not I have some other stuff I can try as well, with netbench.

Signature · 1 line
Jens Axboe
#17 lore raw
Quoted 3 lines · Jens Axboe

Also happy to try and run it here, if you can share it? If not I have some other stuff I can try as well, with netbench.

No, it is not an option... It is a small test driver app running on top of an unpublished closed source 500,000+ lines of code applicative framework...

but do not worry... I am pretty sure to have access to a much better testing setup before the end of the week...

I'll report back more significative results with my test very soon...

Greetings,

#18 lore raw
In reply to Jens Axboe
Quoted 78 lines · Jens Axboe
Quoted 77 lines · Olivier Langlois
Quoted 49 lines · Olivier Langlois
Quoted 13 lines · Jens Axboe

Thanks for testing!

Any chance that you could run some tests with and without NAPI that
help
validate that it actually works? That part is what I'm most interested
in, not too worried about the stability of it as I have scrutinized
it
pretty close already.

There is maybe a test that I can perform. The data that I receive is
timestamped. I have a small test program that checks the age of the
updates on their reception...

I would expect that it should be possible to perceive the busy polling
effect by comparing the average update age with and without the feature
enabled...

A word of warning... The service that my client is connecting to has
relocated recently. I used to have an RTT of about 8mSec with it to
about 400-500 mSec today...

because of the huge RTT, I am unsure that the test is going to be conclusive at all...

However, I am also in the process of relocating my client closer to
the
service. If you can wait a week or so, I should able to do that test
with a RTT < 1 mSec...

Beside that, I could redo the same test that Stefan did with the ping
client/server setup but would that test add any value to the current
collective knowledge?

Quoted 7 lines

I'll do the update age test when I restart my client and I'll report
back the result but my expectations aren't very high that it is going
to be conclusive due to the huge RTT.

As I expected, the busy polling difference in the update age test is so
small compared to the RTT that the result is inconclusive, IMHO...

The number of collected updates to build the stats is 500.

System clocks are assumed to be synchronized and the RTT is the difference between the local time and the update timestamp. Actually, it may be more accurate to say that the displayed RTT values
are in fact TT...

latency NO napi busy poll:
[2024-01-31 11:28:34] INFO Main/processCollectedData rtt min/avg/max/mdev = 74.509/76.752/115.969/3.110 ms

latency napi busy poll:
[2024-01-31 11:33:05] INFO Main/processCollectedData rtt min/avg/max/mdev = 75.347/76.740/134.588/1.648 ms

Quoted 7 lines
Quoted 3 lines

I'll redo the test once my RTT is closer to 1mSec. The relative gain
should be more impressive...

Also happy to try and run it here, if you can share it? If not I have some other stuff I can try as well, with netbench.

I have redone my test with a fixed liburing lib that actually enable io_uring NAPI busy polling correctly and I have slightly more convincing result:

latency NO napi busy poll (kernel v7.2.3):
[2024-02-02 11:42:41] INFO Main/processCollectedData rtt min/avg/max/mdev = 73.089/75.142/107.169/2.954 ms

latency napi busy poll (kernel v7.2.3):
[2024-02-02 11:48:18] INFO Main/processCollectedData rtt min/avg/max/mdev = 72.862/73.878/124.536/1.288 ms

FYI, I said that I could redo the test once I relocate my client to have a RTT < 1ms...

I might not be able to do that. I might settle for an AWS VPS instead of a bare metal setup and when you are running the kernel on a VPS, AFAIK, the virtual Ethernet driver does not have NAPI...

maintainer
#19 lore raw
Quoted 98 lines · Olivier Langlois
Quoted 78 lines · Jens Axboe
Quoted 77 lines · Olivier Langlois
Quoted 49 lines · Olivier Langlois
Quoted 13 lines · Jens Axboe

Thanks for testing!

Any chance that you could run some tests with and without NAPI that
help
validate that it actually works? That part is what I'm most interested
in, not too worried about the stability of it as I have scrutinized
it
pretty close already.

There is maybe a test that I can perform. The data that I receive is
timestamped. I have a small test program that checks the age of the
updates on their reception...

I would expect that it should be possible to perceive the busy polling
effect by comparing the average update age with and without the feature
enabled...

A word of warning... The service that my client is connecting to has
relocated recently. I used to have an RTT of about 8mSec with it to
about 400-500 mSec today...

because of the huge RTT, I am unsure that the test is going to be conclusive at all...

However, I am also in the process of relocating my client closer to
the
service. If you can wait a week or so, I should able to do that test
with a RTT < 1 mSec...

Beside that, I could redo the same test that Stefan did with the ping
client/server setup but would that test add any value to the current
collective knowledge?

Quoted 7 lines

I'll do the update age test when I restart my client and I'll report
back the result but my expectations aren't very high that it is going
to be conclusive due to the huge RTT.

As I expected, the busy polling difference in the update age test is so
small compared to the RTT that the result is inconclusive, IMHO...

The number of collected updates to build the stats is 500.

System clocks are assumed to be synchronized and the RTT is the difference between the local time and the update timestamp. Actually, it may be more accurate to say that the displayed RTT values
are in fact TT...

latency NO napi busy poll:
[2024-01-31 11:28:34] INFO Main/processCollectedData rtt min/avg/max/mdev = 74.509/76.752/115.969/3.110 ms

latency napi busy poll:
[2024-01-31 11:33:05] INFO Main/processCollectedData rtt min/avg/max/mdev = 75.347/76.740/134.588/1.648 ms

Quoted 7 lines
Quoted 3 lines

I'll redo the test once my RTT is closer to 1mSec. The relative gain
should be more impressive...

Also happy to try and run it here, if you can share it? If not I have some other stuff I can try as well, with netbench.

I have redone my test with a fixed liburing lib that actually enable io_uring NAPI busy polling correctly and I have slightly more convincing result:

latency NO napi busy poll (kernel v7.2.3):
[2024-02-02 11:42:41] INFO Main/processCollectedData rtt min/avg/max/mdev = 73.089/75.142/107.169/2.954 ms

latency napi busy poll (kernel v7.2.3):
[2024-02-02 11:48:18] INFO Main/processCollectedData rtt min/avg/max/mdev = 72.862/73.878/124.536/1.288 ms

Quoted 6 lines

FYI, I said that I could redo the test once I relocate my client to have a RTT < 1ms...

I might not be able to do that. I might settle for an AWS VPS instead of a bare metal setup and when you are running the kernel on a VPS, AFAIK, the virtual Ethernet driver does not have NAPI...

I'm going to try some local 10g testing here, I don't think the above says a whole lot as we're dealing with tens of msecs here. But if significant and stable, does look like an improvement. If NAPI works how it should, then sub msec ping/pong replies should show a significant improvement. I'll report back once I get to it...

Signature · 1 line
Jens Axboe