Re: [Intel-wired-lan] [PATCH bpf-next v5 8/8] selftests: net: add test for XDP_PASS skb checksum invalidation

[Jakub Kicinski <kuba@kernel.org>]

On Tue, 21 Jul 2026 16:03:37 -0700 Stanislav Fomichev wrote:
> > > For unnecessary, I think the safe expectation is that the bpf program
> > > will update the value of the checksum in the packet if it touches the data?  
> > 
> > Documenting as expected behavior which no driver currently follows 
> > is a bit silly. I thought the ask was to sketch out the plan of
> > explicitly updating/invalidating the checksum even if we don't
> > implement it today?  
> 
> This is about current drivers that only report UNNECESSARY with xdp: the xdp
> prog has to maintain in-packet checksum if it changes the payload. I think
> it's a fair assumption?

What about decap? If we decap the header that device validated 
as UNNECESSARY there's no possibility of maintaining the checksum
(by which IIUC you mean correcting it in along the payload changes).

I think we'd need some API to "decrement the csum level" ?
Or some heuristic in the drivers to decrement if the head moved
by at least len(IP+UDP) into the packet ?

> In terms of documentation, here is what I have on my side, lmk if that makes
> sense, roughly:
> 
> - TODAY
>   - some drivers (correctly) disable reporting COMPLETE when XDP is attached
>     - the xdp program has to modify the packet checksum value if it
>       changes the payload
>   - some drivers (incorrectly?) report COMPLETE for xdp-to-skb path -> unsafe,
>     needs to be fixed
>     - updating the payload doesn't update skb->csum, so the safest
>       option right now is to only do UNNECESSARY with xdp for all drivers

Yes, that sounds fair.

>   - the hw test needs to make sure that the csum is either
>     NONE or UNNECESSARY, and will error out on COMPLETE

Driver can report COMPLETE to XDP, just not to the stack.
I think we can use a tracepoint (bpftrace) or attach in TCP
to check the skb state?

> - TOMORROW
>   - if we want to properly support COMPLETE, we need a new set of kfuncs
>     to update skb->csum value in the skb
> 
> Does that make sense?