On 25/09/2025 11.30, Lorenzo Bianconi wrote:
+/**
- bpf_xdp_metadata_rx_checksum - Read XDP frame RX checksum.
- @ctx: XDP context pointer.
- @ip_summed: Return value pointer indicating checksum result.
- @cksum_meta: Return value pointer indicating checksum result metadata.
- 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``
- ``XDP_CHECKSUM_PARTIAL``
- 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`` and
- ``XDP_CHECKSUM_PARTIAL``.
It is very important that we explain the meaning of XDP_CHECKSUM_NONE. As I hinted in other email, this also covers the non-existing FAIL case.
If the hardware detects a wrong or failed checksum, the code still returns CHECKSUM_NONE. This is where we could consider adding a CHECKSUM_FAIL return value instead. The driver will also return CHECKSUM_NONE for the cases where it cannot parse the packet, and therefor naturally cannot calculate the checksum (given it doesn't know the protocol).
Thus, for CHECKSUM_NONE we don't know if this is because of bad checksum or hardware don't know this packet type. The philosophy is that hardware might be wrong and cannot know of newer protocols, so it is safer to let software handle recalculation of checksum for all negative cases.
Thus, if we want to use this in a (XDP) DDoS filter, then we need to combine RX-hash info about if hardware saw this as an L4 packet or not (see XDP_RSS_L4 / enum xdp_rss_hash_type). If hardware saw this as e.g. XDP_RSS_L4_TCP (or XDP_RSS_L4_UDP) and rx-csum is CHECKSUM_NONE, then we know this was a wrong/failed checksum (given this hardware knows howto csum TCP).
What do people think: Do we leave it as an exercise to the BPF-developer to deduct hardware detected a wrong/failed checksum, as that is possible as described above. Or do we introduce a CHECKSUM_FAILED?
An argument for sticking with CHECKSUM_NONE, is that it will make it much easier to add driver support, as we don't need to deal with any logic changes in the existing code.
- Return:
- Returns 0 on success or ``-errno`` on error.
- ``-EOPNOTSUPP`` : means device driver does not implement kfunc
- ``-ENODATA`` : means no RX-timestamp available for this frame
- */
+__bpf_kfunc int bpf_xdp_metadata_rx_checksum(const struct xdp_md *ctx,
u8 *ip_summed, u32 *cksum_meta)+{
- return -EOPNOTSUPP;
+}