From: Simon Horman <horms@kernel.org>
To: "Björn Töpel" <bjorn@kernel.org>
Cc: Alexander Duyck <alexanderduyck@fb.com>,
Jakub Kicinski <kuba@kernel.org>,
kernel-team@meta.com, Andrew Lunn <andrew+netdev@lunn.ch>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@google.com>,
Paolo Abeni <pabeni@redhat.com>, Shuah Khan <shuah@kernel.org>,
netdev@vger.kernel.org, linux-kernel@vger.kernel.org,
linux-kselftest@vger.kernel.org,
Daniel Borkmann <daniel@iogearbox.net>,
"Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>,
Mohsin Bashir <mohsin.bashr@gmail.com>,
Stanislav Fomichev <sdf@fomichev.me>,
Bobby Eshleman <bobbyeshleman@meta.com>,
Dimitri Daskalakis <daskald@meta.com>,
Weiming Shi <bestswngs@gmail.com>,
Maxime Chevallier <maxime.chevallier@bootlin.com>,
Jacob Keller <jacob.e.keller@intel.com>,
Breno Leitao <leitao@debian.org>, Tao Cui <cuitao@kylinos.cn>,
Pavel Begunkov <asml.silence@gmail.com>,
David Wei <dw@davidwei.uk>
Subject: Re: [PATCH net-next v4 0/5] fbnic: Support larger RX pages
Date: Wed, 30 Sep 2026 12:36:19 +0100 [thread overview]
Message-ID: <20260930113619.GX13925@horms.kernel.org> (raw)
In-Reply-To: <20260925104417.2325213-1-bjorn@kernel.org>
On Fri, Sep 25, 2026 at 12:44:07PM +0200, Björn Töpel wrote:
> Hi!
>
> This series adds support for large io_uring zero-copy RX buffers to
> fbnic.
>
> fbnic hardware consumes receive memory in 4 KiB device pages, while
> io_uring may expose a larger software buffer, such as 256 KiB. Track
> the device-page geometry per BDQ, represent each large buffer with
> consecutive descriptors, and decode completions to the corresponding
> offset within the buffer. HPQ keeps its existing PAGE_SIZE geometry.
>
> Larger buffers also reduce pressure on the memory provider. One
> provider allocation supplies multiple 4 KiB device pages, so the same
> amount of receive memory needs fewer net_iov objects and fewer
> allocation, refill, and recycle operations. Hardware descriptor use
> remains unchanged.
>
> Ring depth and buffer size must be validated together. An ethtool ring
> change can otherwise make an active memory-provider configuration
> invalid. Store RX ring depths in netdev_config, stage proposed values
> in cfg_pending, and validate the default and each RX queue before
> committing the change. Both netlink and ioctl use the same transaction
> helpers.
>
> The selftest requests a power-of-two buffer larger than twice the MTU,
> checks the reported buffer length, and verifies received data. It does
> not assume how packets are placed within the buffer.
>
> This series depends on the fbnic real-queue synchronization fix:
> https://lore.kernel.org/netdev/20260924191817.1843726-1-bjorn@kernel.org/
For the series:
Reviewed-by: Simon Horman <horms@kernel.org>
next prev parent reply other threads:[~2026-09-30 11:36 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-09-25 10:44 [PATCH net-next v4 0/5] fbnic: Support larger RX pages Björn Töpel
2026-09-25 10:44 ` [PATCH net-next v4 1/5] net: Add netdev_config helpers Björn Töpel
2026-09-30 16:44 ` Joe Damato
2026-09-25 10:44 ` [PATCH net-next v4 2/5] fbnic: Track BDQ device-page geometry per ring Björn Töpel
2026-09-30 17:08 ` Joe Damato
2026-09-25 10:44 ` [PATCH net-next v4 3/5] net: Revalidate queue config for ringparam changes Björn Töpel
2026-09-30 17:22 ` Joe Damato
2026-09-25 10:44 ` [PATCH net-next v4 4/5] fbnic: Support larger memory-provider RX pages Björn Töpel
2026-09-25 10:44 ` [PATCH net-next v4 5/5] selftests: drv-net: Request larger zcrx buffers Björn Töpel
2026-09-30 11:36 ` Simon Horman [this message]
2026-10-01 0:30 ` [PATCH net-next v4 0/5] fbnic: Support larger RX pages patchwork-bot+netdevbpf
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20260930113619.GX13925@horms.kernel.org \
--to=horms@kernel.org \
--cc=alexanderduyck@fb.com \
--cc=andrew+netdev@lunn.ch \
--cc=asml.silence@gmail.com \
--cc=bestswngs@gmail.com \
--cc=bjorn@kernel.org \
--cc=bobbyeshleman@meta.com \
--cc=cuitao@kylinos.cn \
--cc=daniel@iogearbox.net \
--cc=daskald@meta.com \
--cc=davem@davemloft.net \
--cc=dw@davidwei.uk \
--cc=edumazet@google.com \
--cc=jacob.e.keller@intel.com \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=leitao@debian.org \
--cc=linux-kernel@vger.kernel.org \
--cc=linux-kselftest@vger.kernel.org \
--cc=maxime.chevallier@bootlin.com \
--cc=mike.marciniszyn@gmail.com \
--cc=mohsin.bashr@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=sdf@fomichev.me \
--cc=shuah@kernel.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.