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

[Lorenzo Bianconi <lorenzo@kernel.org>]

[-- Attachment #1: Type: text/plain, Size: 2786 bytes --]

> 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


[-- Attachment #2: signature.asc --]
[-- Type: application/pgp-signature, Size: 228 bytes --]