From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-1.web.codeaurora.org [10.30.226.201]) (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 69E8635293D; Thu, 12 Feb 2026 16:51:22 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=10.30.226.201 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770915082; cv=none; b=USBLiHKotrJFFTVvesNQjVFaRPvcKSDOnFQzpS9PhpF80jWpbWvKymVyrr2Q4YW2w9VPd1WhAKzV+7VvIKROEjzml2rxzSX61iET6o/dt79MiIC3iU1MI0ypjyGkutItX6IaYK4fv5eeC3d7bweldDAtexLQflz6SkO+I35Qww4= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1770915082; c=relaxed/simple; bh=XdxVG+YXGaMS3AWMGOWVYDuXvjuKlsGk0gHHkVYXoBE=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=XHmyzQpriZbfgKw+7KZsf8A8lIE2AFSae8xeUI/INNmENgZxXJE9F5xoplBV74naRYgLJWN3RoXSLSYUQIRqPxlIG/2q0iAO7C4iV2m7AvWMX0jmwP9T7miabhB+rgMsjS4m4q4LtxW3dNZSrpIaWOdR2STx4Tr/XgbhODVM0qk= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=g301/aHx; arc=none smtp.client-ip=10.30.226.201 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="g301/aHx" Received: by smtp.kernel.org (Postfix) with ESMTPSA id 8DE26C4CEF7; Thu, 12 Feb 2026 16:51:21 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/simple; d=kernel.org; s=k20201202; t=1770915082; bh=XdxVG+YXGaMS3AWMGOWVYDuXvjuKlsGk0gHHkVYXoBE=; h=Date:From:To:Cc:Subject:References:In-Reply-To:From; b=g301/aHxOBg/tZoPaoIo39YQf6X3yf/bDbcpa60KjMq6uJblkjbFxXdfsoMG8aTBn nlwV7lbuECo+Mv9r5Kk484RzEJleTWEL0UWNOeOomzwDmP1ZcORj3OW2batpf6uiFA FMhVTI5BQs4yfi6qfcJmiINE42oRNQfLcZBxaFclppUqy/bQn1aafFpob6bcLbBzEr ZkZHWziHAccDsvfcp7A85qp34HZJxItkFXVKl9KzYf2sQ4dXSG2DjYkn6XNd3V6Jsj 5SgHidUP7eTxjL/wKPAV7aos/RXsrc8CJ9uYaP2Tpp/uVBzWPv7Um3Yf7zIgfR1INM 0w2O4FVC4LexA== Date: Thu, 12 Feb 2026 17:51:19 +0100 From: Lorenzo Bianconi To: Stanislav Fomichev Cc: Lorenzo Bianconi , Jesper Dangaard Brouer , Donald Hunter , Jakub Kicinski , "David S. Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , John Fastabend , Stanislav Fomichev , Andrew Lunn , Tony Nguyen , Przemek Kitszel , Alexander Lobakin , Andrii Nakryiko , Martin KaFai Lau , Eduard Zingerman , Song Liu , Yonghong Song , KP Singh , Hao Luo , Jiri Olsa , Shuah Khan , Maciej Fijalkowski , netdev@vger.kernel.org, bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH RFC bpf-next v2 1/5] netlink: specs: Add XDP RX checksum capability to XDP metadata specs Message-ID: References: <20250925-bpf-xdp-meta-rxcksum-v2-0-6b3fe987ce91@kernel.org> <20250925-bpf-xdp-meta-rxcksum-v2-1-6b3fe987ce91@kernel.org> Precedence: bulk X-Mailing-List: netdev@vger.kernel.org List-Id: List-Subscribe: List-Unsubscribe: MIME-Version: 1.0 Content-Type: multipart/signed; micalg=pgp-sha512; protocol="application/pgp-signature"; boundary="8qT/NFgXfwBYc55E" Content-Disposition: inline In-Reply-To: --8qT/NFgXfwBYc55E Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On 02/10, Lorenzo Bianconi wrote: > > > On 09/26, Jesper Dangaard Brouer wrote: > > > >=20 > > > >=20 > > > > On 26/09/2025 06.20, Stanislav Fomichev wrote: > > > > > On 09/25, Lorenzo Bianconi wrote: > > > > > > Introduce XDP RX checksum capability to XDP metadata specs. XDP= RX > > > > > > checksum will be use by devices capable of exposing receive che= cksum > > > > > > result via bpf_xdp_metadata_rx_checksum(). > > > > > > Moreover, introduce xmo_rx_checksum netdev callback in order al= low the > > > > > > eBPF program bounded to the device to retrieve the RX checksum = result > > > > > > computed by the hw NIC. > > > > > >=20 > > > > > > Signed-off-by: Lorenzo Bianconi > > > > > > --- > > > > > > Documentation/netlink/specs/netdev.yaml | 5 +++++ > > > > > > include/net/xdp.h | 14 ++++++++++++++ > > > > > > net/core/xdp.c | 29 ++++++++++++++++= +++++++++++++ > > > > > > 3 files changed, 48 insertions(+) > > > > > >=20 > > > > > > diff --git a/Documentation/netlink/specs/netdev.yaml b/Document= ation/netlink/specs/netdev.yaml > > > > > > index e00d3fa1c152d7165e9485d6d383a2cc9cef7cfd..00699bf4a7fdb67= c6b9ee3548098b0c933fd39a4 100644 > > > > > > --- a/Documentation/netlink/specs/netdev.yaml > > > > > > +++ b/Documentation/netlink/specs/netdev.yaml > > > > > > @@ -61,6 +61,11 @@ definitions: > > > > > > doc: | > > > > > > Device is capable of exposing receive packet VLAN t= ag via > > > > > > bpf_xdp_metadata_rx_vlan_tag(). > > > > > > + - > > > > > > + name: checksum > > > > > > + doc: | > > > > > > + Device is capable of exposing receive checksum resul= t via > > > > > > + bpf_xdp_metadata_rx_checksum(). > > > > > > - > > > > > > type: flags > > > > > > name: xsk-flags > > > > > > diff --git a/include/net/xdp.h b/include/net/xdp.h > > > > > > index aa742f413c358575396530879af4570dc3fc18de..9ab9ac10ae2074b= 70618a9d4f32544d8b9a30b63 100644 > > > > > > --- a/include/net/xdp.h > > > > > > +++ b/include/net/xdp.h > > > > > > @@ -586,6 +586,10 @@ void xdp_attachment_setup(struct xdp_attac= hment_info *info, > > > > > > NETDEV_XDP_RX_METADATA_VLAN_TAG, \ > > > > > > bpf_xdp_metadata_rx_vlan_tag, \ > > > > > > xmo_rx_vlan_tag) \ > > > > > > + XDP_METADATA_KFUNC(XDP_METADATA_KFUNC_RX_CHECKSUM, \ > > > > > > + NETDEV_XDP_RX_METADATA_CHECKSUM, \ > > > > > > + bpf_xdp_metadata_rx_checksum, \ > > > > > > + xmo_rx_checksum) > > > > > > enum xdp_rx_metadata { > > > > > > #define XDP_METADATA_KFUNC(name, _, __, ___) name, > > > > > > @@ -643,12 +647,22 @@ enum xdp_rss_hash_type { > > > > > > XDP_RSS_TYPE_L4_IPV6_SCTP_EX =3D XDP_RSS_TYPE_L4_IPV6_SCTP |= XDP_RSS_L3_DYNHDR, > > > > > > }; > > > > > > +enum xdp_checksum { > > > > > > + XDP_CHECKSUM_NONE =3D CHECKSUM_NONE, > > > > > > + XDP_CHECKSUM_UNNECESSARY =3D CHECKSUM_UNNECESSARY, > > > > > > + XDP_CHECKSUM_COMPLETE =3D CHECKSUM_COMPLETE, > > > > > > + XDP_CHECKSUM_PARTIAL =3D CHECKSUM_PARTIAL, > > > > > > +}; > > > > >=20 > > > > > Btw, might be worth mentioning, awhile ago we had settled on a sm= aller set of > > > > > exposed types: > > > > >=20 > > > > > https://lore.kernel.org/netdev/20230811161509.19722-13-larysa.zar= emba@intel.com/ > > > > >=20 > > > > > Maybe go through the previous postings and check if the arguments= are > > > > > still relevant? (or explain why we want more checksum now) > > > >=20 > > > > IHMO the linked proposal reduced the types too much. > > >=20 > > > IIRC, PARTIAL was removed because it's mostly (or only) a TX feature? > > > So no real need to expose it as an rx hint. And I think empty xdp_csu= m_status > > > in that proposal might have indicated NONE? > >=20 > > Sorry for the (very) late reply. According to [0] CHECKSUM_PARTIAL can = be used > > even on Rx side, right? >=20 > So is this for virtio (which I don't think you need)? Or something else? I forgot to mention before CHECKSUM_PARTIAL is used for the veth use-case when the packet is coming from the networking stack. > Can we start with the "easy" cases of UNNECESSARY/COMPLETE/NONE? I'm not = even > sure we need to expose the csum_level (start with level=3D0 and handle > encap if/when there is a real usecase). With kfuncs we should be able to > change/extend the API when needed. ack, I am fine to drop csum_level for the moment but I am not sure if it ca= n be useful for the use-case described by Jesper. @Jesper: any input on it? Regards, Lorenzo >=20 > (for PARTIAL, not even sure what the BPF prog is supposed to do with it) --8qT/NFgXfwBYc55E Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCaY4FBwAKCRA6cBh0uS2t rLgyAQDNKqpoeLWazkdUXhQHQ1Jjc9nNvo0J0et1ZcPKGvP2RgD/aGy9hpI/I7tJ HHNGMx9dyMNBjMP6TKwbgmwxuYvj9As= =RLM+ -----END PGP SIGNATURE----- --8qT/NFgXfwBYc55E--