netdev - Re: [PATCH RFC bpf-next v2 0/5] Add the the capability to load HW RX checsum in eBPF programs

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]

Message-ID: <aNaNVl13LV_HWbP3@lore-desk>
Date: Fri, 26 Sep 2025 14:55:50 +0200
From: Lorenzo Bianconi <lorenzo@...nel.org>
To: Jakub Sitnicki <jakub@...udflare.com>
Cc: Jesper Dangaard Brouer <hawk@...nel.org>,
	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 Fri, Sep 26, 2025 at 01:45 PM +02, Jesper Dangaard Brouer wrote:
> > 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]).
> 
> Thanks for filling in the blanks, Jesper. That's the context that I was
> missing.
> 
> Lorenzo, this motivaton seems worth including in the cover letter.

ack, I will do.

Regards,
Lorenzo


Download attachment "signature.asc" of type "application/pgp-signature" (229 bytes)