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

[Stanislav Fomichev <sdf.kernel@gmail.com>]

On 07/21, Jakub Kicinski wrote:
> 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 ?

True :-/ I guess one more case to document?

> > 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?

No strong opinion on this, it seems easier to report the same to both
xdp and bpf (at least initially)