On 07/21, Jakub Kicinski wrote:
On Tue, 21 Jul 2026 16:03:37 -0700 Stanislav Fomichev wrote:
quoted
quoted
quoted
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?
quoted
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.
quoted
- 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)