From: Lorenzo Bianconi <lorenzo@kernel.org>
To: Vladimir Vdovin <deliran@verdict.gg>
Cc: sdf@fomichev.me, kuba@kernel.org, andrii@kernel.org,
ast@kernel.org, daniel@iogearbox.net, hawk@kernel.org,
john.fastabend@gmail.com, martin.lau@linux.dev,
sdf.kernel@gmail.com, bpf@vger.kernel.org,
netdev@vger.kernel.org
Subject: Re: [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect
Date: Thu, 2 Jul 2026 16:52:48 +0200 [thread overview]
Message-ID: <akZ7QPfn83OUx5Vm@lore-desk> (raw)
In-Reply-To: <20260701171057.4330-1-deliran@verdict.gg>
[-- Attachment #1: Type: text/plain, Size: 3002 bytes --]
> Hi Lorenzo,
Hi Vladimir,
>
> Sorry -- I blindly missed your earlier RX-checksum series before I posted
> mine, thanks Stanislav for the pointer.
No worries. My series is just adding a new kfunc to report the rx-csum result
to an ebpf program running on the NIC. It does not take into account the
XDP_REDIRECT use-case. This is orthogonal and we can work on it later.
>
> To answer your question: yes, I'm happy to take on the driver selftest
> Jakub asked for.
Cool, thx :)
>
> As for my own series, the read side clearly overlaps yours and you own it,
> so I'll drop my bpf_xdp_metadata_rx_csum() hint and its driver bits.
>
> What's left that is genuinely separate is the "assertion" half -- a non-dev-bound
> bpf_xdp_assert_rx_csum() that preserves the HW verdict across a
> cpumap/redirect: it sets a flag on the xdp_buff that rides into the
> xdp_frame and becomes skb->ip_summed = CHECKSUM_UNNECESSARY in
> __xdp_build_skb_from_frame().
>
> Should I resend that as a small standalone series (v2, assert-only)?
> It also looks like a PoC that you and Jakub discussed on v3 [1].
I think we should address the 'CHECKSUM_COMPLETE' use case for it, let's work
on the problem later, even Jesper is interested in it ;)
>
> A few things I'd like to confirm before writing the test:
>
> 1. API for v4. In the v3 discussion you agreed to rework the API to report
> both COMPLETE and UNNECESSARY (+ csum_level), per Jakub. Do you plan to
> send that in v4, or should the driver selftest target the current v3
> signature (enum xdp_checksum + cksum_meta)? I'd rather write the test
> against the API you intend to keep.
IIRC I addressed the request (the code is in [0]). What is missing is just the
self-test.
>
> 2. Documented behavior. The selftest is meant to "check the documented
> expectation", so which rule should it assert -- "a driver must never
> report CHECKSUM_COMPLETE while an XDP program is attached", or that the
> driver downgrades/repairs COMPLETE on the XDP_PASS path? I'll write the
> doc paragraph and the test to match whatever we settle on.
ack
>
> 3. Drivers. Your series adds veth and ice; I don't see mlx5e -- was that
> intentional (left to the driver maintainers)? I had an mlx5e
> implementation in my v1 and I'm happy to contribute it to your series if
> it's useful.
My series does not intend to address all the drivers :)
>
> For the test itself I was thinking of extending
> tools/testing/selftests/drivers/net/hw/xdp_metadata.py, gated on the new
> "checksum" xdp-rx-metadata feature, with good-csum / bad-csum / modify +
> XDP_PASS cases. Does that match what you and Jakub had in mind?
That was my idea too.
Regards,
Lorenzo
>
> [1] https://lore.kernel.org/bpf/20260217-bpf-xdp-meta-rxcksum-v3-0-30024c50ba71@kernel.org/
>
> Thanks,
> Vladimir
[0] https://github.com/LorenzoBianconi/net-next/commits/b4/bpf-xdp-meta-rxcksum/
[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]
prev parent reply other threads:[~2026-07-02 14:52 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2026-06-30 19:15 [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 1/7] xdp: let XDP programs assert the RX checksum " Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 2/7] selftests/bpf: add test for bpf_xdp_assert_rx_csum over cpumap Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 3/7] xdp: add bpf_xdp_metadata_rx_csum() RX metadata kfunc Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 4/7] net/mlx5e: support the rx_csum XDP metadata hint Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 5/7] ice: " Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 6/7] veth: " Vladimir Vdovin
2026-06-30 19:15 ` [RFC PATCH bpf-next v1 7/7] selftests/bpf: cover bpf_xdp_metadata_rx_csum in xdp_metadata Vladimir Vdovin
2026-06-30 21:18 ` [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect Stanislav Fomichev
2026-06-30 22:16 ` Lorenzo Bianconi
2026-07-01 17:10 ` Vladimir Vdovin
2026-07-02 14:52 ` Lorenzo Bianconi [this message]
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=akZ7QPfn83OUx5Vm@lore-desk \
--to=lorenzo@kernel.org \
--cc=andrii@kernel.org \
--cc=ast@kernel.org \
--cc=bpf@vger.kernel.org \
--cc=daniel@iogearbox.net \
--cc=deliran@verdict.gg \
--cc=hawk@kernel.org \
--cc=john.fastabend@gmail.com \
--cc=kuba@kernel.org \
--cc=martin.lau@linux.dev \
--cc=netdev@vger.kernel.org \
--cc=sdf.kernel@gmail.com \
--cc=sdf@fomichev.me \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox