Message-ID: <fdb8a364-a12d-4c1f-9591-9dac3e27b321@kernel.org>
Date: Fri, 26 Sep 2025 13:45:29 +0200
From: Jesper Dangaard Brouer <hawk@...nel.org>
To: Jakub Sitnicki <jakub@...udflare.com>,
 Lorenzo Bianconi <lorenzo@...nel.org>
Cc: Donald Hunter <donald.hunter@...il.com>, Jakub Kicinski
 <kuba@...nel.org>, "David S. Miller" <davem@...emloft.net>,
 Eric Dumazet <edumazet@...gle.com>, Paolo Abeni <pabeni@...hat.com>,
 Simon Horman <horms@...nel.org>, Alexei Starovoitov <ast@...nel.org>,
 Daniel Borkmann <daniel@...earbox.net>,
 John Fastabend <john.fastabend@...il.com>,
 Stanislav Fomichev <sdf@...ichev.me>, Andrew Lunn <andrew+netdev@...n.ch>,
 Tony Nguyen <anthony.l.nguyen@...el.com>,
 Przemek Kitszel <przemyslaw.kitszel@...el.com>,
 Alexander Lobakin <aleksander.lobakin@...el.com>,
 Andrii Nakryiko <andrii@...nel.org>, Martin KaFai Lau
 <martin.lau@...ux.dev>, Eduard Zingerman <eddyz87@...il.com>,
 Song Liu <song@...nel.org>, Yonghong Song <yonghong.song@...ux.dev>,
 KP Singh <kpsingh@...nel.org>, Hao Luo <haoluo@...gle.com>,
 Jiri Olsa <jolsa@...nel.org>, Shuah Khan <shuah@...nel.org>,
 Maciej Fijalkowski <maciej.fijalkowski@...el.com>, netdev@...r.kernel.org,
 bpf@...r.kernel.org, intel-wired-lan@...ts.osuosl.org,
 linux-kselftest@...r.kernel.org, kernel-team <kernel-team@...udflare.com>
Subject: Re: [PATCH RFC bpf-next v2 0/5] Add the the capability to load HW RX
 checsum in eBPF programs



On 25/09/2025 12.58, Jakub Sitnicki wrote:
> On Thu, Sep 25, 2025 at 12:39 PM +02, Lorenzo Bianconi wrote:
>>> On Thu, Sep 25, 2025 at 11:30 AM +02, Lorenzo Bianconi wrote:
>>>> Introduce bpf_xdp_metadata_rx_checksum() kfunc in order to load the HW
>>>> RX cheksum results in the eBPF program binded to the NIC.
>>>> Implement xmo_rx_checksum callback for veth and ice drivers.
>>>
>>> What are going to do with HW RX checksum once XDP prog can access it?
>>
>> I guess there are multiple use-cases for bpf_xdp_metadata_rx_checksum()
>> kfunc. The first the I have in mind is when packets are received by an af_xdp
>> application. In this case I think we currently do not have any way to check if
>> the packet checksum is correct, right?
>> I think Jesper has other use-cases in mind, I will let him comment
>> here.
> 
> Can you share more details on what the AF_XDP application would that
> info?

Today the AF_XDP application need to verify the packet checksum, as it
gets raw xdp_frame packets directly from hardware (no layer in-between
checked this).  Getting the RX-checksum validation from hardware info
will be very useful for AF_XDP, as it can avoid doing this in software.


> Regarding the use cases that Jesper is trying to unlock, as things stand
> we don't have a way, or an agreement on how to inject/propagate even the
> already existing NIC hints back into the network stack.
> 

This patchset have its own merits and shouldn't be connected with my
use-case of (optionally) including hardware offloads in the xdp_frame.
Sure, I obviously also want this RX-checksum added, but this patchset is
useful on it's own.

> Hence my question - why do we want to expose another NIC hint to XDP
> that we can't consume in any useful way yet?
> 

Well here *are* useful ways to use this RX-checksum info on its own.
See my explanation of the DDoS use-case here[1] in other email.

Cloudflare actually also have a concrete use-case for needing this.
Our XDP based Unimog[2] load-balancer (and DDoS) encapsulate all
packets when they are XDP_TX forwarded. The encap receiving NIC lacking
inner-packet checksum validation make us loose this hardware offload.
This would allow us to save some checksum validation or even just DDOS 
drop based on hardware checksum validation prior to encap (as in [1]).

--Jesper

  [1] 
https://lore.kernel.org/all/0608935c-1c1c-4374-a058-bc78d114c630@kernel.org/

  [2] https://blog.cloudflare.com/unimog-cloudflares-edge-load-balancer/

Powered by blists - more mailing lists