From mboxrd@z Thu Jan 1 00:00:00 1970 Received: from smtp.kernel.org (aws-us-west-2-korg-mail-alma10-1.taild15c8.ts.net [100.103.45.18]) (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 BAC9A39CCFF; Tue, 14 Jul 2026 17:08:54 +0000 (UTC) Authentication-Results: smtp.subspace.kernel.org; arc=none smtp.client-ip=100.103.45.18 ARC-Seal:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784048936; cv=none; b=rGckSu5q01QXqhnO9VLzMKVP7e7iUwGTrF17IK1qKemu8HcSCppENfpv4NI5fyeUY3YQzwyr7B7tGeQuRs11nYFYS9Nvu5NKU8OV4Bu8ThA3wkCUY9P1zCwSXgMSUy2s4XrBWc0sxPvtJsNg/Iwk3njGtxYGyLfot0cQUdZBQps= ARC-Message-Signature:i=1; a=rsa-sha256; d=subspace.kernel.org; s=arc-20240116; t=1784048936; c=relaxed/simple; bh=pXbKaqo3/BQgyZxsoqQbZAzKiU+B4SdXcj/pETX3txI=; h=Date:From:To:Cc:Subject:Message-ID:References:MIME-Version: Content-Type:Content-Disposition:In-Reply-To; b=a+Ys538H4xyAq5SRNo+7ZDdI7kIJLRPO7Qpi0f3uJXB9HSFR5WOUFrlA/o6WaY+eDIQkuv2VjUGC7OZSs5OJGmPbVStW9odnOxGomBjc4d+UURqTETU7XKklFg3wGU4QgdQKmnRJ41OPE+BRl90RdX6vXf8hmdcRm7Pwz9YJag8= ARC-Authentication-Results:i=1; smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b=byVwXbtL; arc=none smtp.client-ip=100.103.45.18 Authentication-Results: smtp.subspace.kernel.org; dkim=pass (2048-bit key) header.d=kernel.org header.i=@kernel.org header.b="byVwXbtL" Received: by smtp.kernel.org (Postfix) with ESMTPSA id AB86C1F000E9; Tue, 14 Jul 2026 17:08:53 +0000 (UTC) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=kernel.org; s=k20260515; t=1784048934; bh=Kh2P97NR23r0bPnBVfJUq5G6C7YiA7uuewthu/bIN7I=; h=Date:From:To:Cc:Subject:References:In-Reply-To; b=byVwXbtL6pok60WoSXAQqDT9TWgMfVeTqOGTrFMFwA6AltQP5sZCa7aNR3xUn08rn 98GWpxt2dYNmGN3CJfXbCsFPoQPyYPMQI3kXe6SG80ABed69gGNkY5Rp2sd/Lt2Awv p705lkbKrb86dy2CiTMLuTug1WxXpWM//OVfutelgu9l8QdbINaOd00urKNlK09LaY WVTNVNF88fHrRfCN7D+T5MpHamui9ymXS5/O9MsHoSNXn0GiIT+fAuFqoG9QVKh6l/ OPEf8UexSOkk1UttwLnKuzJutIP/3N35XinvooYC6gdBZqJYcBqsUWKs419va0ZZgA RZQu0vRoP673g== Date: Tue, 14 Jul 2026 19:08:51 +0200 From: Lorenzo Bianconi To: Stanislav Fomichev Cc: Vladimir Vdovin , Donald Hunter , Jakub Kicinski , "David S . Miller" , Eric Dumazet , Paolo Abeni , Simon Horman , Alexei Starovoitov , Daniel Borkmann , Jesper Dangaard Brouer , 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 , Jakub Sitnicki , Aleksandr Loktionov , netdev@vger.kernel.org, bpf@vger.kernel.org, intel-wired-lan@lists.osuosl.org, linux-kselftest@vger.kernel.org Subject: Re: [PATCH bpf-next v4 1/6] netlink: specs: Add XDP RX checksum capability to XDP metadata specs Message-ID: References: <20260708203410.45121-1-deliran@verdict.gg> <20260708203410.45121-2-deliran@verdict.gg> 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="KHFfhBMWGk3EjgnD" Content-Disposition: inline In-Reply-To: --KHFfhBMWGk3EjgnD Content-Type: text/plain; charset=us-ascii Content-Disposition: inline Content-Transfer-Encoding: quoted-printable > On 07/08, Vladimir Vdovin wrote: > > From: Lorenzo Bianconi > >=20 > > Introduce XDP RX checksum capability to XDP metadata specs. XDP RX > > checksum will be use by devices capable of exposing receive checksum > > result via bpf_xdp_metadata_rx_checksum(). > > Moreover, introduce xmo_rx_checksum netdev callback in order to allow > > the eBPF program bound to the device to retrieve the RX checksum result > > computed by the hw NIC and reported via DMA descriptors. > >=20 > > Signed-off-by: Lorenzo Bianconi > > Signed-off-by: Vladimir Vdovin > > --- > > Documentation/netlink/specs/netdev.yaml | 5 ++++ > > include/net/xdp.h | 18 ++++++++++++++ > > include/uapi/linux/netdev.h | 3 +++ > > net/core/xdp.c | 32 +++++++++++++++++++++++++ > > tools/include/uapi/linux/netdev.h | 3 +++ > > 5 files changed, 61 insertions(+) > >=20 > > diff --git a/Documentation/netlink/specs/netdev.yaml b/Documentation/ne= tlink/specs/netdev.yaml > > index 5f143da7458c..6d0d90d3a614 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 tag via > > bpf_xdp_metadata_rx_vlan_tag(). > > + - > > + name: checksum > > + doc: | > > + Device is capable of exposing receive checksum result via > > + bpf_xdp_metadata_rx_checksum(). > > - > > type: flags > > name: xsk-flags > > diff --git a/include/net/xdp.h b/include/net/xdp.h > > index aa742f413c35..e255ff786131 100644 > > --- a/include/net/xdp.h > > +++ b/include/net/xdp.h > > @@ -586,6 +586,10 @@ void xdp_attachment_setup(struct xdp_attachment_in= fo *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) > > =20 > > enum xdp_rx_metadata { > > #define XDP_METADATA_KFUNC(name, _, __, ___) name, > > @@ -643,12 +647,26 @@ enum xdp_rss_hash_type { > > XDP_RSS_TYPE_L4_IPV6_SCTP_EX =3D XDP_RSS_TYPE_L4_IPV6_SCTP | XDP_RSS_= L3_DYNHDR, > > }; >=20 > [..] > =20 > > +/* Please note the driver is required to invalidate the checksum if th= e NIC > > + * reports CHECKSUM_UNNECESSARY or CHECKSUM_COMPLETE and the eBPF prog= ram > > + * modifies the packet since it can change some fields validated by the > > + * checksum. > > + */ >=20 > Sorry, a bit confused about this part. IIUC this is in response to this > discussion https://lore.kernel.org/bpf/aaLYfWnuuf_ne72u@lore-desk/ ? >=20 > Looking at a few drivers: > - bnxt (bnxt_rx_pkt) does UNNECESSARY - ok > - mlx5 (mlx5e_handle_csum) does UNNECESSARY and skips COMPLETE if there is > bpf prog attached > - fbnic (fbnic_rx_csum) - can do COMPLETE even with xdp attached? > - gve (gve_rx) - can do COMPLETE even with xdp attached? >=20 > So none of the drivers invalidate anything (and nether the bpf machinery)= , some > choose to (correctly?) not report COMPLETE when there is XDP. So was the > discussion about documenting this and giving some guidance? This probably > belongs to that `DOC: skb checksums` section of include/linux/skbuff.h? Hi Stanislav, re-reading the previous upstream discussion, I guess we should just documen= t the expected driver behaviour (invalidate the cksum for both COMPLETE and UNNECESSARY cases when the XDP program running on the NIC returns XDP_PASS)= and add a given kselftest for it. Agree? >=20 > Also, can you add your new rx_checksum to > Documentation/networking/xdp-rx-metadata.rst's list of supported kfuncs? ack, I will do it in the next iteration. Regards, Lorenzo --KHFfhBMWGk3EjgnD Content-Type: application/pgp-signature; name=signature.asc -----BEGIN PGP SIGNATURE----- iHUEABYKAB0WIQTquNwa3Txd3rGGn7Y6cBh0uS2trAUCalZtIwAKCRA6cBh0uS2t rGL6AQCi2BM+G5ULVwlhiTQ9mResmshhs2Y13j4jDPNLyIsVpAEAnHqdZsYDNeis roaeeQ5EZov1q2vIZr/DExysvRJVBAg= =iMpE -----END PGP SIGNATURE----- --KHFfhBMWGk3EjgnD--