On Mon, 23 Feb 2026 18:11:54 +0100 Lorenzo Bianconi wrote: > > Off the top of my head drivers prefer reporting UNNECESSARY when they > > have both, and reserve COMPLETE for cases where L4 could not be found > > or is incorrect. Why don't we report both? We're using 3 args, we still > > have 3 to go. We could turn ip_summed into a bitmap and have explicit > > output args for both level and csum complete value? > > Ack, thx for the explanation. Just for sake of understanding, is there > any NIC capable of reporting both csum_value and csum for the same packet > in the DMA descriptor? Or is this change needed to be future-proof?
Both nfp and fbnic definitely can. Off the top of my head - mlx5 also can, but I haven't double checked. > > One more thing I'd like us to at least have a plan for at this stage > > is how to deal with COMPLETE + modified packet + XDP_PASS. > > Right now some drivers discard COMPLETE when XDP is attached since > > they can't be sure if XDP modifies the packet. Other drivers don't > > and we end up with bad csum splat. Do we have a recommendation on > > the correct behavior? If not - should we have a kfunc to adjust / > > discard csum complete explicitly? > > At the moment there is no way to store the csum value we got running > bpf_xdp_metadata_rx_checksum() in order to be consumed during > xdp_buff/xdp_frame to skb conversion (this info can just be consumed in the > ebpf program bound to the NIC) but I think the scope here is much narrower than the xdp_buf to xdp_frame to skb conversion. We are just pass information between the program and driver which owns xdp_buff. Very similar to your new xmo. We could either tell the driver to discard the csum complete or even add a helper to "adjust" the the csum value. Similar to the helper we have to adjust the csum in TC / skb context. > I guess the issue you pointed out can be solved in the verifier > during program load time. What do you think? It could, but at the verifier level we'd probably have to be fairly coarse-grained. Any write to the packet data would mean csum complete cannot be trusted, that's not too hard. But also any tail call / fentry? I'm not really up to date on the latest in program chaining in BPF but I think a lot of real-life deployments would use either chaining or fentry. So in practice it may be a lot of complexity for having csum complete always disabled w/ XDP, in practice. Up to you. I'm totally okay to just say** that drivers should never report csum complete with XDP (until appropriate API is built). Perhaps this will force those who care about XDP+csum_complete to tell us what their requirements are? [**] "just say" == document and add driver kselftest that validates it
