From nobody Sat Dec 27 07:13:56 2025 Received: from mgamail.intel.com (mgamail.intel.com [134.134.136.20]) (using TLSv1.2 with cipher ECDHE-RSA-AES256-GCM-SHA384 (256/256 bits)) (No client certificate requested) by smtp.subspace.kernel.org (Postfix) with ESMTPS id E9CD116400; Sat, 23 Dec 2023 02:58:46 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; dmarc=pass (p=none dis=none) header.from=intel.com Authentication-Results: smtp.subspace.kernel.org; spf=pass smtp.mailfrom=intel.com Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=intel.com header.i=@intel.com header.b="E8YzQdRO" DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=intel.com; i=@intel.com; q=dns/txt; s=Intel; t=1703300326; x=1734836326; h=from:to:cc:subject:date:message-id:in-reply-to: references:mime-version:content-transfer-encoding; bh=Mr6Snaw/+lFcIGo7rqhsa9beABjxqH7MK8K28PCFbjs=; b=E8YzQdRODWNdLGvhde1qgktOtyoNZLw+xHoQK6/nIQC7mp40JUwTXcy3 pghQFpg1X0taAlLylZ5+MNp1jP6HT/hMfez8WPmVTEwqdC1w6YX+sKrwd hUJhdeRdnaL7ECmahe8yQh45fAEQ5pkrZ6ZrIB323uNxn6iz8uIwvk77k Ay68VGeGHDpNdXdnz2QApJJjmol8a6j7By9mEQ1Kf14xAJiu8QZz/EWHT a7n293c+o1Q033vZKRknVrpcvx8ELBR8HxXKqeTysppjEhcETwv4S6Lqz NHnahaiTxm8hqIuxa4AhK7OU3zQ46zp8FsZBBOcbcbdxu4csd9HN5hnzr Q==; X-IronPort-AV: E=McAfee;i="6600,9927,10932"; a="386610857" X-IronPort-AV: E=Sophos;i="6.04,298,1695711600"; d="scan'208";a="386610857" Received: from orviesa001.jf.intel.com ([10.64.159.141]) by orsmga101.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 22 Dec 2023 18:58:46 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="6.04,298,1695711600"; d="scan'208";a="25537489" Received: from newjersey.igk.intel.com ([10.102.20.203]) by orviesa001.jf.intel.com with ESMTP; 22 Dec 2023 18:58:43 -0800 From: Alexander Lobakin To: "David S. Miller" , Eric Dumazet , Jakub Kicinski , Paolo Abeni Cc: Alexander Lobakin , Maciej Fijalkowski , Michal Kubiak , Larysa Zaremba , Alexei Starovoitov , Daniel Borkmann , Willem de Bruijn , intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org, linux-kernel@vger.kernel.org Subject: [PATCH RFC net-next 11/34] xdp: allow attaching already registered memory model to xdp_rxq_info Date: Sat, 23 Dec 2023 03:55:31 +0100 Message-ID: <20231223025554.2316836-12-aleksander.lobakin@intel.com> X-Mailer: git-send-email 2.43.0 In-Reply-To: <20231223025554.2316836-1-aleksander.lobakin@intel.com> References: <20231223025554.2316836-1-aleksander.lobakin@intel.com> Precedence: bulk X-Mailing-List: linux-kernel@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Content-Type: text/plain; charset="utf-8" One may need to register memory model separately from xdp_rxq_info. One simple example may be XDP test run code, but in general, it might be useful when memory model registering is managed by one layer and then XDP RxQ info by a different one. Allow such scenarios by adding a simple helper which "attaches" an already registered memory model to the desired xdp_rxq_info. As this is mostly needed for Page Pool, add a special function to do that for a &page_pool pointer. Signed-off-by: Alexander Lobakin --- include/net/xdp.h | 14 ++++++++++++++ net/bpf/test_run.c | 4 ++-- net/core/xdp.c | 12 ++++++++++++ 3 files changed, 28 insertions(+), 2 deletions(-) diff --git a/include/net/xdp.h b/include/net/xdp.h index 197808df1ee1..909c0bc50517 100644 --- a/include/net/xdp.h +++ b/include/net/xdp.h @@ -356,6 +356,20 @@ void xdp_rxq_info_unreg_mem_model(struct xdp_rxq_info = *xdp_rxq); int xdp_reg_mem_model(struct xdp_mem_info *mem, enum xdp_mem_type type, void *allocator); void xdp_unreg_mem_model(struct xdp_mem_info *mem); +void xdp_rxq_info_attach_page_pool(struct xdp_rxq_info *xdp_rxq, + const struct page_pool *pool); + +static inline void +xdp_rxq_info_attach_mem_model(struct xdp_rxq_info *xdp_rxq, + const struct xdp_mem_info *mem) +{ + xdp_rxq->mem =3D *mem; +} + +static inline void xdp_rxq_info_detach_mem_model(struct xdp_rxq_info *xdp_= rxq) +{ + xdp_rxq->mem =3D (struct xdp_mem_info){ }; +} =20 /* Drivers not supporting XDP metadata can use this helper, which * rejects any room expansion for metadata as a result. diff --git a/net/bpf/test_run.c b/net/bpf/test_run.c index dfd919374017..b612b28ebeac 100644 --- a/net/bpf/test_run.c +++ b/net/bpf/test_run.c @@ -194,8 +194,7 @@ static int xdp_test_run_setup(struct xdp_test_data *xdp= , struct xdp_buff *orig_c * xdp_mem_info pointing to our page_pool */ xdp_rxq_info_reg(&xdp->rxq, orig_ctx->rxq->dev, 0, 0); - xdp->rxq.mem.type =3D MEM_TYPE_PAGE_POOL; - xdp->rxq.mem.id =3D pp->xdp_mem_id; + xdp_rxq_info_attach_page_pool(&xdp->rxq, xdp->pp); xdp->dev =3D orig_ctx->rxq->dev; xdp->orig_ctx =3D orig_ctx; =20 @@ -212,6 +211,7 @@ static int xdp_test_run_setup(struct xdp_test_data *xdp= , struct xdp_buff *orig_c =20 static void xdp_test_run_teardown(struct xdp_test_data *xdp) { + xdp_rxq_info_detach_mem_model(&xdp->rxq); xdp_unreg_mem_model(&xdp->mem); page_pool_destroy(xdp->pp); kfree(xdp->frames); diff --git a/net/core/xdp.c b/net/core/xdp.c index 4869c1c2d8f3..03ebdb21ea62 100644 --- a/net/core/xdp.c +++ b/net/core/xdp.c @@ -368,6 +368,18 @@ int xdp_rxq_info_reg_mem_model(struct xdp_rxq_info *xd= p_rxq, =20 EXPORT_SYMBOL_GPL(xdp_rxq_info_reg_mem_model); =20 +void xdp_rxq_info_attach_page_pool(struct xdp_rxq_info *xdp_rxq, + const struct page_pool *pool) +{ + struct xdp_mem_info mem =3D { + .type =3D MEM_TYPE_PAGE_POOL, + .id =3D pool->xdp_mem_id, + }; + + xdp_rxq_info_attach_mem_model(xdp_rxq, &mem); +} +EXPORT_SYMBOL_GPL(xdp_rxq_info_attach_page_pool); + /* XDP RX runs under NAPI protection, and in different delivery error * scenarios (e.g. queue full), it is possible to return the xdp_frame * while still leveraging this protection. The @napi_direct boolean --=20 2.43.0