On Mon, 20 Jul 2026 12:32:55 -0700 Stanislav Fomichev wrote: > > > (although for gve I might be wrong, there is also gve_rx_skb_csum that > > > only > > > does UNNECESSARY). > > > > > > I'd wait for Jakub to chime in, but it feels like we should just document > > > what we currently do as a recommended approach: for the drivers > > > that support COMPLETE, do not report it when the bpf program is attached. > > > Both NONE and UNNECESSARY are ok. > > > > I am not completely sure the UNNECESSARY case is different from the COMPLETE > > one. What are we supposed to do if the driver reports UNNECESSARY and the > > ebpf > > program modifies some fields covered by the rx-checksum? > > 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? > > > Also, did you run this test on real HW? NIPA now has HW tests, maybe it > > > makes sense to route this series via net-next to get the real coverage? > > > > What about splitting this series and have two different series: > > - bpf-next: add xdp rx kfunc and related selftest > > - net-next: add kselftest for the driver expected behaviour. > > > > What do you think? > > I'd post everything to net-next to get the HW coverage. Once you get all > the acks we can ask the maintainers' guidance. +1, and please add proper tests for the real drivers exercising the kfunc with traffic (would be good to try to send a non-TCP/UDP frame to try to cajole the driver into using COMPLETE).
