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.
