Netdev List
 help / color / mirror / Atom feed
From: Jesper Dangaard Brouer <hawk@kernel.org>
To: Lorenzo Bianconi <lorenzo@kernel.org>,
	Vladimir Vdovin <deliran@verdict.gg>
Cc: sdf@fomichev.me, kuba@kernel.org, andrii@kernel.org,
	ast@kernel.org, daniel@iogearbox.net, john.fastabend@gmail.com,
	martin.lau@linux.dev, sdf.kernel@gmail.com, bpf@vger.kernel.org,
	netdev@vger.kernel.org, "David S. Miller" <davem@davemloft.net>,
	Alexander Lobakin <aleksander.lobakin@intel.com>,
	Eric Dumazet <edumazet@google.com>,
	kernel-team <kernel-team@cloudflare.com>
Subject: Re: [RFC PATCH bpf-next v1 0/7] xdp: RX checksum metadata hint and checksum assertion over redirect
Date: Sat, 4 Jul 2026 18:41:03 +0200	[thread overview]
Message-ID: <1d5521eb-84fc-4417-a3f5-6366694d160a@kernel.org> (raw)
In-Reply-To: <akZ7QPfn83OUx5Vm@lore-desk>



On 02/07/2026 16.52, Lorenzo Bianconi wrote:
[...]
>>
>> 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 ;)
>

Yes, I'm very interested in this use-case of transferring HW offload
info when XDP_REDIRECT'ing into CPUMAP or veth.  In my patchset[1] I've
added rx_hash, rx_vlan_tag, and rx_timestamp, but not csum as it was not
available.  My short term use-case is: RX-hash as setting it earlier
allows the GRO engine to hash flows (see dev_gro_receive[2]), plus it
carries info on packet protocol type TCP/UDP IPv4/IPv6.

- [1] 
https://lore.kernel.org/all/175146824674.1421237.18351246421763677468.stgit@firesoul/#r
- [2] https://elixir.bootlin.com/linux/v7.1.2/source/net/core/gro.c#L477

The long term[3] vision behind the patchset is that xdp_frame becomes
the "mini-SKB" that carries enough offload info to avoid allocating SKBs
in the driver.  The ICE driver is very close to this vision. See [4]
where it calls xdp_build_skb_from_buff() and later fills out SKB fields
with HW offloads (ice_process_skb_fields).

What I'm asking is that we generalize this idea of transferring or
storing HW offloads, that are relevant to the SKB.  My patchset makes
info avail to both xdp_buff and xdp_frame by storing data[5] in the
packet top headroom (extending xdp_frame). And like your patch[6] use
xdp_buff_flags to tell with is active. You patch only needed a single
flag as you only handle CHECKSUM_UNNECESSARY, but Lorenzo's patch also
have CHECKSUM_COMPLETE, for which we need to store a csum.

I cannot remember if it was Kuba or Eric that suggested (at netdevconf)
that instead of using a fixed struct, that I should use the same scheme
as SKB extensions.  We could call it SKB core-extensions, to signal the
possibility to move existing SKB member into this area.

--Jesper

- [3] 
https://lore.kernel.org/all/fbb026f9-54cf-49ba-b0dc-0df0f54c6961@kernel.org/
- [4] 
https://elixir.bootlin.com/linux/v7.1.2/source/drivers/net/ethernet/intel/ice/ice_txrx.c#L1044-L1060
- [5] 
https://lore.kernel.org/all/175146829944.1421237.13943404585579626611.stgit@firesoul/
- [6] https://lore.kernel.org/all/20260630191510.81402-1-deliran@verdict.gg/

      reply	other threads:[~2026-07-04 16:41 UTC|newest]

Thread overview: 13+ 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
2026-07-04 16:41         ` Jesper Dangaard Brouer [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=1d5521eb-84fc-4417-a3f5-6366694d160a@kernel.org \
    --to=hawk@kernel.org \
    --cc=aleksander.lobakin@intel.com \
    --cc=andrii@kernel.org \
    --cc=ast@kernel.org \
    --cc=bpf@vger.kernel.org \
    --cc=daniel@iogearbox.net \
    --cc=davem@davemloft.net \
    --cc=deliran@verdict.gg \
    --cc=edumazet@google.com \
    --cc=john.fastabend@gmail.com \
    --cc=kernel-team@cloudflare.com \
    --cc=kuba@kernel.org \
    --cc=lorenzo@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