From mboxrd@z Thu Jan 1 00:00:00 1970 Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.remote-ip=100.103.45.18 ARC-Seal: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; cv=none; t=1794768958; b=RZF0E5v9qm8ounCxvA81egqNhBJGE1Ti+9g8THK7NMsn8lx228rjHeJfPTKmO7S7sJhl gpwsRY2b6mXwtXCCtcfO5xipKA0Dhe+UjjRytpTrhnbjGsqQ84YckuWyPI2/UAWmgGzVE lAWrRbE6DxMR50SthjMXN1/jiY8SnL4IwEm+Ui12LKkjHIv7p0rupjSQYBeyk0DPDOXN9 Bey/16ho+oYmiXn1tdQcMJGZ7HpIWvZ22H5meBc+Yg1XYY94rEWbSSo3BW4fHB8L3HhEb 90ojNhEvPYvKN1c6yJzXCvLNv3/xjLArreMtk8SFykSohPeNluf4JxXx7PQlJHzrGcA== ARC-Message-Signature: i=1; d=subspace.kernel.org; s=arc20261015; a=rsa-sha256; c=relaxed/relaxed; t=1794768958; h=Received:DKIM-Signature:From:To:Cc:Subject:In-Reply-To:References: Date:Message-ID:MIME-Version:Content-Type:Content-Transfer-Encoding; bh=zyXslw9VshoP0Dt+hSCQbWwSxcGhI3BWVVf2b5NPS+g=; b=rZIx8Pu9Q/WhfPRyoVyEYOhdAqD3qjPWL9++ZH0kvqNX3YcVFcO44Yk9gDmhgKVGc58Q qWkVAgbTNU3Nmlkz9LdqMepRNOMD1iaLk1oXlX9QZH6V+k+ocVF7GswY5rEcaHRlNzKce WLjyvA3dxLOieqq7Qu5fz7iG2/scKiPG//2I/gLb5De1k+uAevaVPN/7w6uAiUqLS5W/l WEbjiSjfg/7ycqRm1tTSH7kxzuXjoOze30agluEpiF1Xh+MyGuOZYQP2bNBNOwO5FXc4/ tbhvQBjkasKE0nn7FLci4ll6o0Rv0oikux9W0SN2j7LdqHx5jDJf6E1SGrYvV5SWQ/w== ARC-Authentication-Results: i=1; smtp.subspace.kernel.org; dkim=pass header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=fJ+vqeSl; arc=none smtp.remote-ip=100.103.45.18 Received: from smtp.kernel.org (quasi.space.kernel.org [100.103.45.18]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature ECDSA (prime256v1)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id 8F6CB606A31A; Sun, 15 Nov 2026 18:55:58 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.a=rsa-sha256 header.s=k20260515 header.b=fJ+vqeSl Received: by smtp.kernel.org (Postfix) with ESMTPSA id 708D61F000C4; Sun, 15 Nov 2026 18:55:57 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1794768958; bh=zyXslw9VshoP0Dt+hSCQbWwSxcGhI3BWVVf2b5NPS+g=; h=From:To:Cc:Subject:In-Reply-To:References:Date; b=fJ+vqeSlkhrBkQxZvX/Lxn09eGioyBRenoJ34ugy0G+/njudzKIqL/wqu8vvvN9Av Jthdkut6dozLF5eLQTi2o2XbpLRc3OxrGEmBjqULmZMZk9e6GmM8UKPLHSMLEUEZQT 18HtuzmhqbbbQrmhlKYbMhJfsTq3uhIx5ksae9Pq8bV1XrdIYQ/SZLPWm7Xt9qpJZ0 I4CneqOuGhjFbRvGp2R8sdnWt/M3tDLeZxVodVojrTQGH+kuBLdV45r0FrhKUsurHH lK7XnIRt9FalYffxGd54cxd2GVXt6aGE4iofQnOOsTxD/s4lJEftWdxkVb1dYXMUS/ GgAm86xzyWIiA== From: =?utf-8?B?QmrDtnJuIFTDtnBlbA==?= To: Mina Almasry Cc: Magnus Karlsson , Maciej Fijalkowski , Stanislav Fomichev , "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni , Simon Horman , Jonathan Corbet , Shuah Khan , Randy Dunlap , Alexander Duyck , kernel-team@meta.com, Andrew Lunn , Jesper Dangaard Brouer , Ilias Apalodimas , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Pavel Begunkov , Jens Axboe , Andrii Nakryiko , Eduard Zingerman , Kumar Kartikeya Dwivedi , Martin KaFai Lau , Song Liu , Yonghong Song , Jiri Olsa , Emil Tsalapatis , Ihor Solodrai , netdev@vger.kernel.org, bpf@vger.kernel.org, io-uring@vger.kernel.org, "Mike Marciniszyn (Meta)" , Weiming Shi , Nikolay Aleksandrov , David Wei , Alexander Lobakin , linux-doc@vger.kernel.org, linux-kernel@vger.kernel.org, Stuart Clark Subject: Re: [PATCH net-next v1 04/11] xsk: Allocate UMEM chunks through page_pool In-Reply-To: References: <20261110102039.1002605-1-bjorn@kernel.org> <20261110102039.1002605-5-bjorn@kernel.org> Date: Sun, 15 Nov 2026 19:55:55 +0100 Message-ID: <87v75xj550.fsf@all.your.base.are.belong.to.us> X-Mailing-List: netdev@vger.kernel.org List-Id: List-Post: List-Help: List-Subscribe: List-Unsubscribe: List-Owner: Precedence: list MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Transfer-Encoding: quoted-printable Mina Almasry writes: > On Tue, Nov 10, 2026 at 2:21=E2=80=AFAM Bj=C3=B6rn T=C3=B6pel wrote: >> diff --git a/include/net/xdp.h b/include/net/xdp.h >> index 1105bb9e3292..5ab7802ac4e1 100644 >> --- a/include/net/xdp.h >> +++ b/include/net/xdp.h >> @@ -368,7 +368,7 @@ static inline bool xdp_buff_add_frag(struct xdp_buff= *xdp, netmem_ref netmem, >> >> if (unlikely(netmem_is_pfmemalloc(netmem))) >> xdp_buff_set_frag_pfmemalloc(xdp); >> - if (unlikely(netmem_is_net_iov(netmem))) >> + if (unlikely(netmem_is_net_iov(netmem) && !netmem_address(netmem= ))) >> xdp_buff_set_frag_unreadable(xdp); >> > > > netmem_is_net_iov() check became redundant. Hmm, not quite... netmem_address() is also NULL for a highmem page without a mapping, and the stack reads those through kmap, so they aren't unreadable. The net_iov test keeps them out. I'll add a comment. >> diff --git a/net/xdp/xsk_pp.c b/net/xdp/xsk_pp.c >> new file mode 100644 >> index 000000000000..fdd55265a6cd >> --- /dev/null >> +++ b/net/xdp/xsk_pp.c >> @@ -0,0 +1,246 @@ >> +// SPDX-License-Identifier: GPL-2.0 >> +/* AF_XDP UMEM as a page pool memory provider >> + * >> + * Each aligned UMEM chunk is a readable net_iov with one owner at a ti= me: >> + * >> + * userspace --FILL--> page pool --release--> reuse --alloc--> page p= ool >> + * ^ | >> + * +-----RX ring-------+ >> + */ >> + >> +#include >> +#include >> +#include >> + >> +#include "xsk.h" >> +#include "xsk_queue.h" >> + >> +enum xsk_pp_chunk { >> + XSK_PP_USER, /* owned by userspace */ >> + XSK_PP_POOL, /* owned by a page pool */ >> + XSK_PP_REUSE, /* on the reuse stack */ >> +}; > > maybe should be xsk_mp_chunk. > > But also, why is this 3? Usually the mp's track allocated and free. I > assume PP_REUSE is actually free, but I'm curious why it matters to > your mp whether the pool or the userspace holds the memory (or whether > the net stack holds it. Can't it hold it?) REUSE is free, yes. USER and POOL are both allocated, but userspace gives chunks back by writing addresses to FILL, and it can write any address, also one of a chunk the kernel still owns. Taking that entry would hand the device the same chunk twice. So the provider only takes FILL entries for chunks in USER, and drops the rest. io_uring zcrx checks the same with user_refs, and devmem with the socket's token xarray. The stack can't hold a chunk, see my reply on patch 3. >> + >> +struct xsk_pp { > > maybe xsk_mp? this is a memory provider right? Yes, I'll rename it to xsk_mp, the enum too. Bj=C3=B6rn