Re: [PATCH bpf-next v3 1/5] netlink: specs: Add XDP RX checksum capability to XDP metadata specs
From: Jakub Kicinski <kuba@kernel.org>
Date: 2026-02-19 17:13:47
Also in:
bpf, intel-wired-lan, linux-kselftest
On Thu, 19 Feb 2026 12:04:56 +0100 Lorenzo Bianconi wrote:
quoted
On Tue, 17 Feb 2026 09:33:56 +0100 Lorenzo Bianconi wrote:quoted
+ * In case of success, ``ip_summed`` is set to the RX checksum result. Possible + * values are: + * ``XDP_CHECKSUM_NONE`` + * ``XDP_CHECKSUM_UNNECESSARY`` + * ``XDP_CHECKSUM_COMPLETE`` + * + * In case of success, ``cksum_meta`` contains the hw computed checksum value + * for ``XDP_CHECKSUM_COMPLETE`` or the ``csum_level`` for + * ``XDP_CHECKSUM_UNNECESSARY``. It is set to 0 for ``XDP_CHECKSUM_NONE``It's fairly common for NICs to report both csum complete and unnecessary. Which one should the driver return in that case?Do you mean what is value for cksum_meta if we do not report csum_level for XDP_CHECKSUM_UNNECESSARY/CHECKSUM_UNNECESSARY use-case? (as suggested by Stanislav).
More fundamentally whether the API is right.
My original idea is: - if the hw reports CHECKSUM_COMPLETE: - ip_summed = XDP_CHECKSUM_COMPLETE - cksum_meta contains the checksum computed by the hw - if the hw reports CHECKSUM_UNNECESSARY - ip_summed = XDP_CHECKSUM_UNNECESSARY - cksum_meta = csum_level <-- Stanislav suggests to drop this one - if the hw reports CHECKSUM_NONE - ip_summed = XDP_CHECKSUM_NONE - cksum_meta = 0
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? 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?