[PATCH net-next v2 0/2] netdev: expose page pool order via netlink

[PATCH net-next v2 0/2] netdev: expose page pool order via netlink

[Dragos Tatulea]

This small series exposes io_uring's high order page configuration
via the page_pool netlink interface and updates the appropriate
selftest to check this value.

---
v2:
- Switched from exposing page_pool order to rx_buf_len via nl_fill of
  the io_uring memory provider.
- Updated selftest to check rx_buf_len.
- v1: https://lore.kernel.org/all/20260611161235.3807332-1-dtatulea@nvidia.com/
---
Dragos Tatulea (2):
  netdev: expose io_uring rx_page_order order via netlink
  io_uring/zcrx: selftests: verify rx_buf_len for large chunks

 Documentation/netlink/specs/netdev.yaml       |  9 ++++++-
 include/uapi/linux/netdev.h                   |  2 ++
 io_uring/zcrx.c                               |  8 ++++++
 tools/include/uapi/linux/netdev.h             |  2 ++
 .../selftests/drivers/net/hw/iou-zcrx.py      | 26 ++++++++++++++++++-
 5 files changed, 45 insertions(+), 2 deletions(-)

-- 
2.54.0

[PATCH net-next v2 1/2] netdev: expose io_uring rx_page_order order via netlink

[Dragos Tatulea]

This adds observability for the io_uring zcrx rx-buf-len configuration.

Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
Reviewed-by: Yael Chemla <ychemla@nvidia.com>
Reviewed-by: Tariq Toukan <tariqt@nvidia.com>
---
 Documentation/netlink/specs/netdev.yaml | 9 ++++++++-
 include/uapi/linux/netdev.h             | 2 ++
 io_uring/zcrx.c                         | 8 ++++++++
 tools/include/uapi/linux/netdev.h       | 2 ++
 4 files changed, 20 insertions(+), 1 deletion(-)

diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml
index 49862b666d7d..5f143da7458c 100644
--- a/Documentation/netlink/specs/netdev.yaml
+++ b/Documentation/netlink/specs/netdev.yaml
@@ -127,7 +127,14 @@ attribute-sets:
         enum: xsk-flags
   -
     name: io-uring-provider-info
-    attributes: []
+    attributes:
+      -
+        name: rx-buf-len
+        type: uint
+        doc: |
+          RX buffer length in bytes for this io_uring memory provider.
+          Reflects the rx_buf_len passed at io_uring zerocopy rx
+          registration time.
   -
     name: page-pool
     attributes:
diff --git a/include/uapi/linux/netdev.h b/include/uapi/linux/netdev.h
index 7df1056a35fd..2f3ab75e8cc0 100644
--- a/include/uapi/linux/netdev.h
+++ b/include/uapi/linux/netdev.h
@@ -97,6 +97,8 @@ enum {
 };
 
 enum {
+	NETDEV_A_IO_URING_PROVIDER_INFO_RX_BUF_LEN = 1,
+
 	__NETDEV_A_IO_URING_PROVIDER_INFO_MAX,
 	NETDEV_A_IO_URING_PROVIDER_INFO_MAX = (__NETDEV_A_IO_URING_PROVIDER_INFO_MAX - 1)
 };
diff --git a/io_uring/zcrx.c b/io_uring/zcrx.c
index 19837e0b5e91..c7b167c2d4e4 100644
--- a/io_uring/zcrx.c
+++ b/io_uring/zcrx.c
@@ -1156,6 +1156,7 @@ static void io_pp_zc_destroy(struct page_pool *pp)
 static int io_pp_nl_fill(void *mp_priv, struct sk_buff *rsp,
 			 struct netdev_rx_queue *rxq)
 {
+	struct io_zcrx_ifq *ifq = mp_priv;
 	struct nlattr *nest;
 	int type;
 
@@ -1163,6 +1164,13 @@ static int io_pp_nl_fill(void *mp_priv, struct sk_buff *rsp,
 	nest = nla_nest_start(rsp, type);
 	if (!nest)
 		return -EMSGSIZE;
+
+	if (nla_put_uint(rsp, NETDEV_A_IO_URING_PROVIDER_INFO_RX_BUF_LEN,
+			 1ULL << ifq->niov_shift)) {
+		nla_nest_cancel(rsp, nest);
+		return -EMSGSIZE;
+	}
+
 	nla_nest_end(rsp, nest);
 
 	return 0;
diff --git a/tools/include/uapi/linux/netdev.h b/tools/include/uapi/linux/netdev.h
index 7df1056a35fd..2f3ab75e8cc0 100644
--- a/tools/include/uapi/linux/netdev.h
+++ b/tools/include/uapi/linux/netdev.h
@@ -97,6 +97,8 @@ enum {
 };
 
 enum {
+	NETDEV_A_IO_URING_PROVIDER_INFO_RX_BUF_LEN = 1,
+
 	__NETDEV_A_IO_URING_PROVIDER_INFO_MAX,
 	NETDEV_A_IO_URING_PROVIDER_INFO_MAX = (__NETDEV_A_IO_URING_PROVIDER_INFO_MAX - 1)
 };
-- 
2.54.0

[PATCH net-next v2 2/2] io_uring/zcrx: selftests: verify rx_buf_len for large chunks

[Dragos Tatulea]

Check the newly added rx_buf_len page_pool field for io_uring
in the existing large-chunks test after the receiver is up.

Signed-off-by: Dragos Tatulea <dtatulea@nvidia.com>
---
 .../selftests/drivers/net/hw/iou-zcrx.py      | 26 ++++++++++++++++++-
 1 file changed, 25 insertions(+), 1 deletion(-)

diff --git a/tools/testing/selftests/drivers/net/hw/iou-zcrx.py b/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
index d72b76ba0835..b7a225fe4bea 100755
--- a/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
+++ b/tools/testing/selftests/drivers/net/hw/iou-zcrx.py
@@ -2,6 +2,7 @@
 # SPDX-License-Identifier: GPL-2.0
 
 import re
+import resource
 import time
 from os import path
 from lib.py import ksft_run, ksft_exit, KsftSkipEx, ksft_variants, KsftNamedVariant
@@ -41,6 +42,23 @@ def set_flow_rule_rss(cfg, rss_ctx_id):
     return int(values)
 
 
+def check_iou_rx_buf_len(cfg, expected_rx_buf_len):
+    """Check the io-uring memory provider exposes the expected rx_buf_len."""
+    q = cfg.netnl.queue_get({'ifindex': cfg.ifindex, 'type': 'rx', 'id': cfg.target})
+    napi_id = q['napi-id']
+    pools = cfg.netnl.page_pool_get({}, dump=True)
+    pools = [p for p in pools if p.get('napi-id') == napi_id
+             and 'io-uring' in p]
+    if len(pools) != 1:
+        raise Exception(f"Expected 1 io-uring page pool, found {len(pools)}")
+    rx_buf_len = pools[0]['io-uring'].get('rx-buf-len')
+    if rx_buf_len is None:
+        raise KsftSkipEx("io-uring 'rx-buf-len' attribute not supported")
+    if rx_buf_len != expected_rx_buf_len:
+        raise Exception(f'Expected io-uring rx-buf-len {expected_rx_buf_len}, '
+                        f'got {rx_buf_len}')
+
+
 def single(cfg):
     channels = cfg.ethnl.channels_get({'header': {'dev-index': cfg.ifindex}})
     channels = channels['combined-count']
@@ -156,7 +174,10 @@ def test_zcrx_large_chunks(cfg) -> None:
             defer(lambda: open(hp_file, 'w', encoding='utf-8').write(str(nr_hugepages)))
 
     single(cfg)
-    rx_cmd = f"{cfg.bin_local} -s -p {cfg.port} -i {cfg.ifname} -q {cfg.target} -x 2"
+    page_size = resource.getpagesize()
+    nr_pages = 2
+    rx_buf_len = nr_pages * page_size
+    rx_cmd = f"{cfg.bin_local} -s -p {cfg.port} -i {cfg.ifname} -q {cfg.target} -x {nr_pages}"
     tx_cmd = f"{cfg.bin_remote} -c -h {cfg.addr_v['6']} -p {cfg.port} -l 12840"
 
     probe = cmd(rx_cmd + " -d", fail=False)
@@ -166,6 +187,9 @@ def test_zcrx_large_chunks(cfg) -> None:
     mp_clear_wait(cfg)
     with bkg(rx_cmd, exit_wait=True):
         wait_port_listen(cfg.port, proto="tcp")
+
+        check_iou_rx_buf_len(cfg, rx_buf_len)
+
         cmd(tx_cmd, host=cfg.remote)
 
 
-- 
2.54.0

Re: [PATCH net-next v2 1/2] netdev: expose io_uring rx_page_order order via netlink

[Pavel Begunkov]

On 6/12/26 22:17, Dragos Tatulea wrote:
> This adds observability for the io_uring zcrx rx-buf-len configuration.

It might be nicer to look it up in the queue, e.g. rxq->mp_params,
and make it a queue attribute instead of zcrx specific one. In either
case, no objections.

Acked-by: Pavel Begunkov <asml.silence@gmail.com>

-- 
Pavel Begunkov

Re: [PATCH net-next v2 1/2] netdev: expose io_uring rx_page_order order via netlink

[Dragos Tatulea]

On 13.06.26 11:53, Pavel Begunkov wrote:
> On 6/12/26 22:17, Dragos Tatulea wrote:
>> This adds observability for the io_uring zcrx rx-buf-len configuration.
> 
> It might be nicer to look it up in the queue, e.g. rxq->mp_params,
> and make it a queue attribute instead of zcrx specific one. In either
> case, no objections.
> 
In io_pp_nl_fill() or in page_pool_nl_fill() as it was done in v1 for order?

Thanks,
Dragos

Re: [PATCH net-next v2 1/2] netdev: expose io_uring rx_page_order order via netlink

[Jakub Kicinski]

On Sat, 13 Jun 2026 16:09:03 +0200 Dragos Tatulea wrote:
> On 13.06.26 11:53, Pavel Begunkov wrote:
> > On 6/12/26 22:17, Dragos Tatulea wrote:  
> >> This adds observability for the io_uring zcrx rx-buf-len configuration.  
> > 
> > It might be nicer to look it up in the queue, e.g. rxq->mp_params,
> > and make it a queue attribute instead of zcrx specific one. In either
> > case, no objections.
>   
> In io_pp_nl_fill() or in page_pool_nl_fill() as it was done in v1 for order?

It's fine. We decided to make the "page size" a memory provider
property, now we're going back to making it a queue level param? 
Like my RFC had that everyone hated so much? Sigh.