From: Stanislav Fomichev <sdf.kernel@gmail.com>
To: "Björn Töpel" <bjorn@kernel.org>
Cc: Magnus Karlsson <magnus.karlsson@intel.com>,
Maciej Fijalkowski <maciej.fijalkowski@intel.com>,
Stanislav Fomichev <sdf@fomichev.me>,
"David S. Miller" <davem@davemloft.net>,
Eric Dumazet <edumazet@kernel.org>,
Jakub Kicinski <kuba@kernel.org>,
Paolo Abeni <pabeni@redhat.com>, Simon Horman <horms@kernel.org>,
Jonathan Corbet <corbet@lwn.net>,
Shuah Khan <skhan@linuxfoundation.org>,
Randy Dunlap <rdunlap@infradead.org>,
Alexander Duyck <alexanderduyck@fb.com>,
kernel-team@meta.com, Andrew Lunn <andrew+netdev@lunn.ch>,
Jesper Dangaard Brouer <hawk@kernel.org>,
Ilias Apalodimas <ilias.apalodimas@linaro.org>,
Alexei Starovoitov <ast@kernel.org>,
Daniel Borkmann <daniel@iogearbox.net>,
John Fastabend <john.fastabend@gmail.com>,
Pavel Begunkov <asml.silence@gmail.com>,
Jens Axboe <axboe@kernel.dk>,
Andrii Nakryiko <andrii@kernel.org>,
Eduard Zingerman <eddyz87@gmail.com>,
Kumar Kartikeya Dwivedi <memxor@gmail.com>,
Martin KaFai Lau <martin.lau@linux.dev>,
Song Liu <song@kernel.org>,
Yonghong Song <yonghong.song@linux.dev>,
Jiri Olsa <jolsa@kernel.org>,
Emil Tsalapatis <emil@etsalapatis.com>,
Ihor Solodrai <ihor.solodrai@linux.dev>,
netdev@vger.kernel.org, bpf@vger.kernel.org,
io-uring@vger.kernel.org,
"Mike Marciniszyn (Meta)" <mike.marciniszyn@gmail.com>,
Weiming Shi <bestswngs@gmail.com>,
Nikolay Aleksandrov <razor@blackwall.org>,
David Wei <dw@davidwei.uk>,
Alexander Lobakin <aleksander.lobakin@intel.com>,
linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org,
Mina Almasry <almasrymina@google.com>
Subject: Re: [RFC net-next 05/15] page_pool: Extend memory provider operations
Date: Mon, 5 Oct 2026 09:51:15 -0700 [thread overview]
Message-ID: <asPUZ8DPllHd6Yu9@devvm7509.cco0.facebook.com> (raw)
In-Reply-To: <20261002190018.696925-6-bjorn@kernel.org>
On 10/02, Björn Töpel wrote:
> The current memory providers give memory that the CPU cannot read,
> and they can always refill. An AF_XDP provider is different. The CPU
> can read its memory, it has only the buffers that userspace puts in
> the FILL ring, and its buffers go back to userspace instead of being
> freed. It needs four things from page_pool:
>
> - A CPU address for each net_iov. A provider can set the address of
> the first net_iov in its net_iov_area and the size each net_iov
> covers. netmem_address() then computes the address without a call
> into the provider; drivers call it for every packet. A
> net_iov_area without an address stays unreadable.
> page_pool_is_unreadable() is false for a readable provider.
>
> - A way to say that the refill is not done. The new refill_done
> callback tells the driver whether it may stop refilling. A
> provider that still has buffers returns false, and the driver
> keeps NAPI scheduled.
>
> - A way to give up a buffer without freeing it. Add a batched call
> that ends page_pool ownership of buffers that leave through the
> provider, for example to userspace. It clears the page_pool link,
> so a later page pool can take the buffer. Add the matching batched
> call that sets the link, and a DMA sync helper for drivers that
> post a buffer again directly.
>
> - No buffer splitting, because a split buffer has several owners.
> Add MP_CAP_FRAG. page_pool refuses fragment allocation from a
> provider without it.
>
> devmem and io_uring set MP_CAP_FRAG and keep their fragment
> behaviour. Their refill paths now use the batched call that sets the
> link.
>
> Signed-off-by: Björn Töpel <bjorn@kernel.org>
> ---
> include/net/netmem.h | 31 ++++++++++-
> include/net/page_pool/helpers.h | 62 +++++++++++++++++++++-
> include/net/page_pool/memory_provider.h | 28 +++++-----
> io_uring/zcrx.c | 4 +-
> net/core/devmem.c | 7 ++-
> net/core/page_pool.c | 68 ++++++++++++++++++++-----
> 6 files changed, 165 insertions(+), 35 deletions(-)
>
> diff --git a/include/net/netmem.h b/include/net/netmem.h
> index cc97611632dc..e6dff0b01581 100644
> --- a/include/net/netmem.h
> +++ b/include/net/netmem.h
> @@ -105,6 +105,12 @@ struct net_iov_area {
>
[..]
> /* Offset into the dma-buf where this chunk starts. */
> unsigned long base_virtual;
Will send a patch to drop this one, don't think we use it anymore..
[..]
> + /* CPU address of the first net_iov's memory, or NULL when the CPU
> + * cannot read the area. Each net_iov covers 1 << @niov_shift bytes.
> + */
> + void *vaddr;
Who is setting this? Somewhere in another patch? Can we keep it here?
> + u8 niov_shift;
If we need niov_shift at area level, let's move the one from binding here?
Then the existing callers can do binding->area.niov_shift.
> };
>
> static inline struct net_iov_area *net_iov_owner(const struct net_iov *niov)
> @@ -117,6 +123,23 @@ static inline unsigned int net_iov_idx(const struct net_iov *niov)
> return niov - net_iov_owner(niov)->niovs;
> }
>
> +static inline bool net_iov_is_readable(const struct net_iov *niov)
> +{
> + return net_iov_owner(niov)->vaddr;
> +}
> +
> +static inline void *net_iov_address(const struct net_iov *niov)
> +{
> + const struct net_iov_area *area = net_iov_owner(niov);
> + unsigned long off;
> +
> + if (!area->vaddr)
> + return NULL;
> +
> + off = (unsigned long)net_iov_idx(niov) << area->niov_shift;
> + return area->vaddr + off;
Or, alternatively, store dma_base in area and do:
return niov->dma_addr - area.dma_base + vadd ?
next prev parent reply other threads:[~2026-10-05 16:51 UTC|newest]
Thread overview: 36+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-10-02 19:00 [RFC net-next 00/15] xsk: Zero copy through page-pool memory providers Björn Töpel
2026-10-02 19:00 ` [RFC net-next 01/15] xdp: Size zero-copy skb heads by their contents Björn Töpel
2026-10-02 19:00 ` [RFC net-next 02/15] eth: fbnic: Report the logical XDP RX queue Björn Töpel
2026-10-02 19:00 ` [RFC net-next 03/15] net: Add memory provider capabilities Björn Töpel
2026-10-03 4:13 ` Mina Almasry
2026-10-09 14:54 ` Björn Töpel
2026-10-03 19:02 ` sashiko-bot
2026-10-12 18:54 ` Björn Töpel
2026-10-05 16:26 ` Stanislav Fomichev
2026-10-12 13:34 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 04/15] net: Let memory providers set RX buffer headroom Björn Töpel
2026-10-05 16:52 ` Stanislav Fomichev
2026-10-12 13:35 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 05/15] page_pool: Extend memory provider operations Björn Töpel
2026-10-05 16:51 ` Stanislav Fomichev [this message]
2026-10-12 13:53 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 06/15] xdp: Track non-page netmem in receive buffers Björn Töpel
2026-10-05 17:01 ` Stanislav Fomichev
2026-10-12 14:12 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 07/15] xsk: Keep the DMA mapping in the buffer pool Björn Töpel
2026-10-02 19:00 ` [RFC net-next 08/15] xsk: Handle a detached FILL ring in RX wakeup Björn Töpel
2026-10-02 19:00 ` [RFC net-next 09/15] xsk: Add a page-pool memory provider for UMEM Björn Töpel
2026-10-05 17:38 ` Stanislav Fomichev
2026-10-12 14:14 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 10/15] xsk: Add RX helpers for page-pool drivers Björn Töpel
2026-10-02 19:00 ` [RFC net-next 11/15] xdp: Copy provider buffers on pass and redirect Björn Töpel
2026-10-03 19:02 ` sashiko-bot
2026-10-12 18:55 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 12/15] xsk: Receive provider UMEM without copying Björn Töpel
2026-10-02 19:00 ` [RFC net-next 13/15] eth: fbnic: Support AF_XDP zero-copy receive Björn Töpel
2026-10-03 19:02 ` sashiko-bot
2026-10-12 18:56 ` Björn Töpel
2026-10-05 17:51 ` Stanislav Fomichev
2026-10-12 14:16 ` Björn Töpel
2026-10-02 19:00 ` [RFC net-next 14/15] eth: fbnic: Support AF_XDP zero-copy transmit Björn Töpel
2026-10-02 19:00 ` [RFC net-next 15/15] Documentation: xsk: Document page-pool zero copy Björn Töpel
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=asPUZ8DPllHd6Yu9@devvm7509.cco0.facebook.com \
--to=sdf.kernel@gmail.com \
--cc=aleksander.lobakin@intel.com \
--cc=alexanderduyck@fb.com \
--cc=almasrymina@google.com \
--cc=andrew+netdev@lunn.ch \
--cc=andrii@kernel.org \
--cc=asml.silence@gmail.com \
--cc=ast@kernel.org \
--cc=axboe@kernel.dk \
--cc=bestswngs@gmail.com \
--cc=bjorn@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=corbet@lwn.net \
--cc=daniel@iogearbox.net \
--cc=davem@davemloft.net \
--cc=dw@davidwei.uk \
--cc=eddyz87@gmail.com \
--cc=edumazet@kernel.org \
--cc=emil@etsalapatis.com \
--cc=hawk@kernel.org \
--cc=horms@kernel.org \
--cc=ihor.solodrai@linux.dev \
--cc=ilias.apalodimas@linaro.org \
--cc=io-uring@vger.kernel.org \
--cc=john.fastabend@gmail.com \
--cc=jolsa@kernel.org \
--cc=kernel-team@meta.com \
--cc=kuba@kernel.org \
--cc=linux-doc@vger.kernel.org \
--cc=linux-kernel@vger.kernel.org \
--cc=maciej.fijalkowski@intel.com \
--cc=magnus.karlsson@intel.com \
--cc=martin.lau@linux.dev \
--cc=memxor@gmail.com \
--cc=mike.marciniszyn@gmail.com \
--cc=netdev@vger.kernel.org \
--cc=pabeni@redhat.com \
--cc=razor@blackwall.org \
--cc=rdunlap@infradead.org \
--cc=sdf@fomichev.me \
--cc=skhan@linuxfoundation.org \
--cc=song@kernel.org \
--cc=yonghong.song@linux.dev \
/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.