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

[Jakub Sitnicki <jakub@cloudflare.com>]

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.