[PATCH v15 0/7] io_uring: add napi busy polling support

[PATCH v15 0/7] io_uring: add napi busy polling support

[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
-- 
2.39.1

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

[Stefan Roesch]

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 <shr@devkernel.io>
---
 net/core/dev.c | 23 ++++++++++++++++++-----
 1 file changed, 18 insertions(+), 5 deletions(-)

diff --git a/net/core/dev.c b/net/core/dev.c
index b3c13e041935..ae90265f4020 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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);
 
-- 
2.39.1

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

[kernel test robot]

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/202306090341.ShxjwRn1-lkp@intel.com/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/20230608163839.2891748-2-shr@devkernel.io
        # 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 <lkp@intel.com>
| Closes: https://lore.kernel.org/oe-kbuild-all/202306090341.ShxjwRn1-lkp@intel.com/

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	

-- 
0-DAY CI Kernel Test Service
https://github.com/intel/lkp-tests/wiki

[PATCH v15 2/7] net: add napi_busy_loop_rcu()

[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 <shr@devkernel.io>
---
 include/net/busy_poll.h |  4 ++++
 net/core/dev.c          | 11 +++++++++++
 2 files changed, 15 insertions(+)

diff --git a/include/net/busy_poll.h b/include/net/busy_poll.h
index f90f0021f5f2..622623f5740e 100644
--- a/include/net/busy_poll.h
+++ b/include/net/busy_poll.h
@@ -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)
 {
diff --git a/net/core/dev.c b/net/core/dev.c
index ae90265f4020..60fc54c4aa42 100644
--- a/net/core/dev.c
+++ b/net/core/dev.c
@@ -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)
-- 
2.39.1

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

[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 <shr@devkernel.io>
---
 io_uring/io_uring.c | 21 ---------------------
 io_uring/io_uring.h | 22 ++++++++++++++++++++++
 2 files changed, 22 insertions(+), 21 deletions(-)

diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index c99a7a0c3f21..6b1a1ac38061 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -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)
 {
diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h
index 9b8dfb3bb2b4..13f87accbdfe 100644
--- a/io_uring/io_uring.h
+++ b/io_uring/io_uring.h
@@ -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);
-- 
2.39.1

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

[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 <shr@devkernel.io>
Suggested-by: Olivier Langlois <olivier@trillion01.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
---
 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

diff --git a/include/linux/io_uring_types.h b/include/linux/io_uring_types.h
index f04ce513fadb..71068f67ca30 100644
--- a/include/linux/io_uring_types.h
+++ b/include/linux/io_uring_types.h
@@ -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
diff --git a/io_uring/Makefile b/io_uring/Makefile
index 8cc8e5387a75..2efe7c5f07ba 100644
--- a/io_uring/Makefile
+++ b/io_uring/Makefile
@@ -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
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 6b1a1ac38061..6378089aa385 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -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);
diff --git a/io_uring/io_uring.h b/io_uring/io_uring.h
index 13f87accbdfe..7417e1214da4 100644
--- a/io_uring/io_uring.h
+++ b/io_uring/io_uring.h
@@ -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)
diff --git a/io_uring/napi.c b/io_uring/napi.c
new file mode 100644
index 000000000000..1112cc39153c
--- /dev/null
+++ b/io_uring/napi.c
@@ -0,0 +1,255 @@
+// SPDX-License-Identifier: GPL-2.0
+
+#include "io_uring.h"
+#include "napi.h"
+
+#ifdef CONFIG_NET_RX_BUSY_POLL
+
+/* Timeout for cleanout of stale entries. */
+#define NAPI_TIMEOUT		(60 * SEC_CONVERSION)
+
+struct io_napi_entry {
+	unsigned int		napi_id;
+	struct list_head	list;
+
+	unsigned long		timeout;
+	struct hlist_node	node;
+
+	struct rcu_head		rcu;
+};
+
+static struct io_napi_entry *io_napi_hash_find(struct hlist_head *hash_list,
+					       unsigned int napi_id)
+{
+	struct io_napi_entry *e;
+
+	hlist_for_each_entry_rcu(e, hash_list, node) {
+		if (e->napi_id != napi_id)
+			continue;
+		e->timeout = jiffies + NAPI_TIMEOUT;
+		return e;
+	}
+
+	return NULL;
+}
+
+void __io_napi_add(struct io_ring_ctx *ctx, struct socket *sock)
+{
+	struct hlist_head *hash_list;
+	unsigned int napi_id;
+	struct sock *sk;
+	struct io_napi_entry *e;
+
+	sk = sock->sk;
+	if (!sk)
+		return;
+
+	napi_id = READ_ONCE(sk->sk_napi_id);
+
+	/* Non-NAPI IDs can be rejected. */
+	if (napi_id < MIN_NAPI_ID)
+		return;
+
+	hash_list = &ctx->napi_ht[hash_min(napi_id, HASH_BITS(ctx->napi_ht))];
+
+	rcu_read_lock();
+	e = io_napi_hash_find(hash_list, napi_id);
+	if (e) {
+		e->timeout = jiffies + NAPI_TIMEOUT;
+		rcu_read_unlock();
+		return;
+	}
+	rcu_read_unlock();
+
+	e = kmalloc(sizeof(*e), GFP_NOWAIT);
+	if (!e)
+		return;
+
+	e->napi_id = napi_id;
+	e->timeout = jiffies + NAPI_TIMEOUT;
+
+	spin_lock(&ctx->napi_lock);
+	if (unlikely(io_napi_hash_find(hash_list, napi_id))) {
+		spin_unlock(&ctx->napi_lock);
+		kfree(e);
+		return;
+	}
+
+	hlist_add_tail_rcu(&e->node, hash_list);
+	list_add_tail(&e->list, &ctx->napi_list);
+	spin_unlock(&ctx->napi_lock);
+}
+
+static void __io_napi_remove_stale(struct io_ring_ctx *ctx)
+{
+	struct io_napi_entry *e;
+	unsigned int i;
+
+	spin_lock(&ctx->napi_lock);
+	hash_for_each(ctx->napi_ht, i, e, node) {
+		if (time_after(jiffies, e->timeout)) {
+			list_del(&e->list);
+			hash_del_rcu(&e->node);
+			kfree_rcu(e, rcu);
+		}
+	}
+	spin_unlock(&ctx->napi_lock);
+}
+
+static inline void io_napi_remove_stale(struct io_ring_ctx *ctx, bool is_stale)
+{
+	if (is_stale)
+		__io_napi_remove_stale(ctx);
+}
+
+static inline bool io_napi_busy_loop_timeout(unsigned long start_time,
+					     unsigned long bp_usec)
+{
+	if (bp_usec) {
+		unsigned long end_time = start_time + bp_usec;
+		unsigned long now = busy_loop_current_time();
+
+		return time_after(now, end_time);
+	}
+
+	return true;
+}
+
+static bool io_napi_busy_loop_should_end(void *data,
+					 unsigned long start_time)
+{
+	struct io_wait_queue *iowq = data;
+
+	if (signal_pending(current))
+		return true;
+	if (io_should_wake(iowq))
+		return true;
+	if (io_napi_busy_loop_timeout(start_time, iowq->napi_busy_poll_to))
+		return true;
+
+	return false;
+}
+
+static bool __io_napi_do_busy_loop(struct io_ring_ctx *ctx,
+				   void *loop_end_arg)
+{
+	struct io_napi_entry *e;
+	bool (*loop_end)(void *, unsigned long) = NULL;
+	bool is_stale = false;
+
+	if (loop_end_arg)
+		loop_end = io_napi_busy_loop_should_end;
+
+	list_for_each_entry_rcu(e, &ctx->napi_list, list) {
+		napi_busy_loop_rcu(e->napi_id, loop_end, loop_end_arg,
+				   ctx->napi_prefer_busy_poll, BUSY_POLL_BUDGET);
+
+		if (time_after(jiffies, e->timeout))
+			is_stale = true;
+	}
+
+	return is_stale;
+}
+
+static void io_napi_blocking_busy_loop(struct io_ring_ctx *ctx,
+				       struct io_wait_queue *iowq)
+{
+	unsigned long start_time = busy_loop_current_time();
+	void *loop_end_arg = NULL;
+	bool is_stale = false;
+
+	/* Singular lists use a different napi loop end check function and are
+	 * only executed once.
+	 */
+	if (list_is_singular(&ctx->napi_list))
+		loop_end_arg = iowq;
+
+	rcu_read_lock();
+	do {
+		is_stale = __io_napi_do_busy_loop(ctx, loop_end_arg);
+	} while (!io_napi_busy_loop_should_end(iowq, start_time) && !loop_end_arg);
+	rcu_read_unlock();
+
+	io_napi_remove_stale(ctx, is_stale);
+}
+
+/*
+ * io_napi_init() - Init napi settings
+ * @ctx: pointer to io-uring context structure
+ *
+ * Init napi settings in the io-uring context.
+ */
+void io_napi_init(struct io_ring_ctx *ctx)
+{
+	INIT_LIST_HEAD(&ctx->napi_list);
+	spin_lock_init(&ctx->napi_lock);
+	ctx->napi_prefer_busy_poll = false;
+	ctx->napi_busy_poll_to = READ_ONCE(sysctl_net_busy_poll);
+}
+
+/*
+ * io_napi_free() - Deallocate napi
+ * @ctx: pointer to io-uring context structure
+ *
+ * Free the napi list and the hash table in the io-uring context.
+ */
+void io_napi_free(struct io_ring_ctx *ctx)
+{
+	struct io_napi_entry *e;
+	LIST_HEAD(napi_list);
+	unsigned int i;
+
+	spin_lock(&ctx->napi_lock);
+	hash_for_each(ctx->napi_ht, i, e, node) {
+		hash_del_rcu(&e->node);
+		kfree_rcu(e, rcu);
+	}
+	spin_unlock(&ctx->napi_lock);
+}
+
+/*
+ * __io_napi_adjust_timeout() - Add napi id to the busy poll list
+ * @ctx: pointer to io-uring context structure
+ * @iowq: pointer to io wait queue
+ * @ts: pointer to timespec or NULL
+ *
+ * Adjust the busy loop timeout according to timespec and busy poll timeout.
+ */
+void __io_napi_adjust_timeout(struct io_ring_ctx *ctx, struct io_wait_queue *iowq,
+			      struct timespec64 *ts)
+{
+	unsigned int poll_to = READ_ONCE(ctx->napi_busy_poll_to);
+
+	if (ts) {
+		struct timespec64 poll_to_ts = ns_to_timespec64(1000 * (s64)poll_to);
+
+		if (timespec64_compare(ts, &poll_to_ts) > 0) {
+			*ts = timespec64_sub(*ts, poll_to_ts);
+		} else {
+			u64 to = timespec64_to_ns(ts);
+
+			do_div(to, 1000);
+			ts->tv_sec = 0;
+			ts->tv_nsec = 0;
+		}
+	}
+
+	iowq->napi_busy_poll_to = poll_to;
+}
+
+/*
+ * __io_napi_busy_loop() - execute busy poll loop
+ * @ctx: pointer to io-uring context structure
+ * @iowq: pointer to io wait queue
+ *
+ * Execute the busy poll loop and merge the spliced off list.
+ */
+void __io_napi_busy_loop(struct io_ring_ctx *ctx, struct io_wait_queue *iowq)
+{
+	iowq->napi_prefer_busy_poll = READ_ONCE(ctx->napi_prefer_busy_poll);
+
+	if (!(ctx->flags & IORING_SETUP_SQPOLL) && iowq->napi_busy_poll_to)
+		io_napi_blocking_busy_loop(ctx, iowq);
+}
+
+#endif
diff --git a/io_uring/napi.h b/io_uring/napi.h
new file mode 100644
index 000000000000..be8aa8ee32d9
--- /dev/null
+++ b/io_uring/napi.h
@@ -0,0 +1,89 @@
+/* SPDX-License-Identifier: GPL-2.0 */
+
+#ifndef IOU_NAPI_H
+#define IOU_NAPI_H
+
+#include <linux/kernel.h>
+#include <linux/io_uring.h>
+#include <net/busy_poll.h>
+
+#ifdef CONFIG_NET_RX_BUSY_POLL
+
+void io_napi_init(struct io_ring_ctx *ctx);
+void io_napi_free(struct io_ring_ctx *ctx);
+
+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);
+
+static inline bool io_napi(struct io_ring_ctx *ctx)
+{
+	return !list_empty(&ctx->napi_list);
+}
+
+static inline void io_napi_adjust_timeout(struct io_ring_ctx *ctx,
+					  struct io_wait_queue *iowq,
+					  struct timespec64 *ts)
+{
+	if (!io_napi(ctx))
+		return;
+	__io_napi_adjust_timeout(ctx, iowq, ts);
+}
+
+static inline void io_napi_busy_loop(struct io_ring_ctx *ctx,
+				     struct io_wait_queue *iowq)
+{
+	if (!io_napi(ctx))
+		return;
+	__io_napi_busy_loop(ctx, iowq);
+}
+
+/*
+ * io_napi_add() - Add napi id to the busy poll list
+ * @req: pointer to io_kiocb request
+ *
+ * Add the napi id of the socket to the napi busy poll list and hash table.
+ */
+static inline void io_napi_add(struct io_kiocb *req)
+{
+	struct io_ring_ctx *ctx = req->ctx;
+	struct socket *sock;
+
+	if (!READ_ONCE(ctx->napi_busy_poll_to))
+		return;
+
+	sock = sock_from_file(req->file);
+	if (sock)
+		__io_napi_add(ctx, sock);
+}
+
+#else
+
+static inline void io_napi_init(struct io_ring_ctx *ctx)
+{
+}
+static inline void io_napi_free(struct io_ring_ctx *ctx)
+{
+}
+static inline bool io_napi(struct io_ring_ctx *ctx)
+{
+	return false;
+}
+static inline void io_napi_add(struct io_kiocb *req)
+{
+}
+static inline void io_napi_adjust_timeout(struct io_ring_ctx *ctx,
+					  struct io_wait_queue *iowq,
+					  struct timespec64 *ts)
+{
+}
+static inline void io_napi_busy_loop(struct io_ring_ctx *ctx,
+				     struct io_wait_queue *iowq)
+{
+}
+
+#endif /* CONFIG_NET_RX_BUSY_POLL */
+
+#endif
diff --git a/io_uring/poll.c b/io_uring/poll.c
index c90e47dc1e29..0284849793bb 100644
--- a/io_uring/poll.c
+++ b/io_uring/poll.c
@@ -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) {
 		/*
-- 
2.39.1

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

[Stefan Roesch]

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

Signed-off-by: Stefan Roesch <shr@devkernel.io>
Suggested-by: Olivier Langlois <olivier@trillion01.com>
---
 io_uring/napi.c   | 24 ++++++++++++++++++++++++
 io_uring/napi.h   |  6 +++++-
 io_uring/sqpoll.c |  4 ++++
 3 files changed, 33 insertions(+), 1 deletion(-)

diff --git a/io_uring/napi.c b/io_uring/napi.c
index 1112cc39153c..3e578df36cc5 100644
--- a/io_uring/napi.c
+++ b/io_uring/napi.c
@@ -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
diff --git a/io_uring/napi.h b/io_uring/napi.h
index be8aa8ee32d9..b6d6243fc7fe 100644
--- a/io_uring/napi.h
+++ b/io_uring/napi.h
@@ -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
diff --git a/io_uring/sqpoll.c b/io_uring/sqpoll.c
index 9db4bc1f521a..0c8d53ef134a 100644
--- a/io_uring/sqpoll.c
+++ b/io_uring/sqpoll.c
@@ -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)
-- 
2.39.1

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

[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 <shr@devkernel.io>
Acked-by: Jakub Kicinski <kuba@kernel.org>
---
 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(+)

diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index f222d263bc55..cac3d55e002b 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -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
  */
diff --git a/io_uring/io_uring.c b/io_uring/io_uring.c
index 6378089aa385..958bbedddaa0 100644
--- a/io_uring/io_uring.c
+++ b/io_uring/io_uring.c
@@ -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;
diff --git a/io_uring/napi.c b/io_uring/napi.c
index 3e578df36cc5..b1a3ed9d1c2e 100644
--- a/io_uring/napi.c
+++ b/io_uring/napi.c
@@ -207,6 +207,54 @@ void io_napi_free(struct io_ring_ctx *ctx)
 	spin_unlock(&ctx->napi_lock);
 }
 
+/*
+ * io_napi_register() - Register napi with io-uring
+ * @ctx: pointer to io-uring context structure
+ * @arg: pointer to io_uring_napi structure
+ *
+ * Register napi in the io-uring context.
+ */
+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,
+	};
+	struct io_uring_napi napi;
+
+	if (copy_from_user(&napi, arg, sizeof(napi)))
+		return -EFAULT;
+	if (napi.pad || napi.resv)
+		return -EINVAL;
+
+	WRITE_ONCE(ctx->napi_busy_poll_to, napi.busy_poll_to);
+
+	if (copy_to_user(arg, &curr, sizeof(curr)))
+		return -EFAULT;
+
+	return 0;
+}
+
+/*
+ * io_napi_unregister() - Unregister napi with io-uring
+ * @ctx: pointer to io-uring context structure
+ * @arg: pointer to io_uring_napi structure
+ *
+ * Unregister napi. If arg has been specified copy the busy poll timeout and
+ * prefer busy poll setting to the passed in structure.
+ */
+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,
+	};
+
+	if (arg && copy_to_user(arg, &curr, sizeof(curr)))
+		return -EFAULT;
+
+	WRITE_ONCE(ctx->napi_busy_poll_to, 0);
+	return 0;
+}
+
 /*
  * __io_napi_adjust_timeout() - Add napi id to the busy poll list
  * @ctx: pointer to io-uring context structure
diff --git a/io_uring/napi.h b/io_uring/napi.h
index b6d6243fc7fe..6fc0393d0dbe 100644
--- a/io_uring/napi.h
+++ b/io_uring/napi.h
@@ -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;
-- 
2.39.1

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

[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 <shr@devkernel.io>
Acked-by: Jakub Kicinski <kuba@kernel.org>
---
 include/uapi/linux/io_uring.h |  3 ++-
 io_uring/napi.c               | 10 +++++++---
 2 files changed, 9 insertions(+), 4 deletions(-)

diff --git a/include/uapi/linux/io_uring.h b/include/uapi/linux/io_uring.h
index cac3d55e002b..02122894056b 100644
--- a/include/uapi/linux/io_uring.h
+++ b/include/uapi/linux/io_uring.h
@@ -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;
 };
 
diff --git a/io_uring/napi.c b/io_uring/napi.c
index b1a3ed9d1c2e..8ec016899539 100644
--- a/io_uring/napi.c
+++ b/io_uring/napi.c
@@ -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;
 }
 
-- 
2.39.1

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

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?

On Thu, 2023-06-08 at 09:38 -0700, 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. 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

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Jens Axboe]

On 1/30/24 2:20 PM, Olivier Langlois wrote:
> 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?

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

-- 
Jens Axboe

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Tue, 2024-01-30 at 15:59 -0700, Jens Axboe wrote:
> On 1/30/24 2:20 PM, Olivier Langlois wrote:
> > 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?
> 
> 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
> 
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!

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Tue, 2024-01-30 at 15:59 -0700, Jens Axboe wrote:
> On 1/30/24 2:20 PM, Olivier Langlois wrote:
> > 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?
> 
> 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
> 

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 <olivier@trillion01.com>

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Jens Axboe]

On 1/31/24 10:22 AM, Olivier Langlois wrote:
> On Tue, 2024-01-30 at 15:59 -0700, Jens Axboe wrote:
>> On 1/30/24 2:20 PM, Olivier Langlois wrote:
>>> 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?
>>
>> 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
>>
> 
> 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

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.

-- 
Jens Axboe

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
> 
> 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.

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Wed, 2024-01-31 at 12:59 -0500, Olivier Langlois wrote:
> On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
> > 
> > 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.
> 
> 
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...

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Jens Axboe]

On 1/31/24 12:56 PM, Olivier Langlois wrote:
> On Wed, 2024-01-31 at 12:59 -0500, Olivier Langlois wrote:
>> On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
>>>
>>> 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.
>>
>>
> 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...

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.

-- 
Jens Axboe

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Wed, 2024-01-31 at 13:52 -0700, Jens Axboe wrote:
> 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,

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Olivier Langlois]

On Wed, 2024-01-31 at 13:52 -0700, Jens Axboe wrote:
> On 1/31/24 12:56 PM, Olivier Langlois wrote:
> > On Wed, 2024-01-31 at 12:59 -0500, Olivier Langlois wrote:
> > > On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
> > > > 
> > > > 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.
> > > 
> > > 
> > 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...
> 
> 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...

Re: [PATCH v15 0/7] io_uring: add napi busy polling support

[Jens Axboe]

On 2/2/24 1:20 PM, Olivier Langlois wrote:
> On Wed, 2024-01-31 at 13:52 -0700, Jens Axboe wrote:
>> On 1/31/24 12:56 PM, Olivier Langlois wrote:
>>> On Wed, 2024-01-31 at 12:59 -0500, Olivier Langlois wrote:
>>>> On Wed, 2024-01-31 at 10:32 -0700, Jens Axboe wrote:
>>>>>
>>>>> 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.
>>>>
>>>>
>>> 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...
>>
>> 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...

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...

-- 
Jens Axboe