Re: [RFC v1 17/22] netdev: add support for setting rx-buf-len per queue
From: Mina Almasry <hidden>
Date: 2025-07-28 23:10:51
Also in:
io-uring
On Mon, Jul 28, 2025 at 4:03 AM Pavel Begunkov [off-list ref] wrote:
quoted hunk ↗ jump to hunk
From: Jakub Kicinski <kuba@kernel.org> Zero-copy APIs increase the cost of buffer management. They also extend this cost to user space applications which may be used to dealing with much larger buffers. Allow setting rx-buf-len per queue, devices with HW-GRO support can commonly fill buffers up to 32k (or rather 64k - 1 but that's not a power of 2..) The implementation adds a new option to the netdev netlink, rather than ethtool. The NIC-wide setting lives in ethtool ringparams so one could argue that we should be extending the ethtool API. OTOH netdev API is where we already have queue-get, and it's how zero-copy applications bind memory providers. Signed-off-by: Jakub Kicinski <kuba@kernel.org> Signed-off-by: Pavel Begunkov <asml.silence@gmail.com> --- Documentation/netlink/specs/netdev.yaml | 15 ++++ include/net/netdev_queues.h | 5 ++ include/net/netlink.h | 19 +++++ include/uapi/linux/netdev.h | 2 + net/core/netdev-genl-gen.c | 15 ++++ net/core/netdev-genl-gen.h | 1 + net/core/netdev-genl.c | 92 +++++++++++++++++++++++++ net/core/netdev_config.c | 16 +++++ tools/include/uapi/linux/netdev.h | 2 + 9 files changed, 167 insertions(+)diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/netlink/specs/netdev.yaml index c0ef6d0d7786..5dd1eb5909cd 100644 --- a/Documentation/netlink/specs/netdev.yaml +++ b/Documentation/netlink/specs/netdev.yaml@@ -324,6 +324,10 @@ attribute-sets: doc: XSK information for this queue, if any. type: nest nested-attributes: xsk-info + - + name: rx-buf-len + doc: Per-queue configuration of ETHTOOL_A_RINGS_RX_BUF_LEN. + type: u32 - name: qstats doc: |@@ -755,6 +759,17 @@ operations: reply: attributes: - id + - + name: queue-set + doc: Set per-queue configurable options. + attribute-set: queue + do: + request: + attributes: + - ifindex + - type + - id + - rx-buf-len kernel-family: headers: [ "net/netdev_netlink.h"]diff --git a/include/net/netdev_queues.h b/include/net/netdev_queues.h index f75313fc78ba..cfd2d59861e1 100644 --- a/include/net/netdev_queues.h +++ b/include/net/netdev_queues.h@@ -38,6 +38,7 @@ struct netdev_config { /* Same semantics as fields in struct netdev_config */ struct netdev_queue_config { + u32 rx_buf_len; }; /* See the netdev.yaml spec for definition of each statistic */@@ -140,6 +141,8 @@ void netdev_stat_queue_sum(struct net_device *netdev, /** * struct netdev_queue_mgmt_ops - netdev ops for queue management * + * @supported_ring_params: ring params supported per queue (ETHTOOL_RING_USE_*). + *
I don't see this used anywhere. But more generally, I'm a bit concerned about protecting drivers that don't support configuring one particular queue config. I think likely supported_ring_params needs to be moved earlier to the patch which adds per queue netdev_configs to the queue API, and probably as part of that patch core needs to make sure it's never asking a driver that doesn't support changing a netdev_queue_config to do so? Some thought may be given to moving the entire configuration story outside of queue_mem_alloc/free queue_start/stop altogether to new ndos where core can easily check if the ndo is supported otherwise per-queue config is not supported. Otherwise core needs to be careful never to attempt a config that is not supported? -- Thanks, Mina