+TO: Maxime, Harrison (info might be related to my question about virtio offload)
> From: Morten Brørup [mailto:[email protected]] > Sent: Tuesday, 15 September 2026 12.58 > > If the PMD didn't check the IP header checksum, the > offload value is RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN, > not RTE_MBUF_F_RX_IP_CKSUM_NONE. > > Fixes: 4b01cabfb09b ("examples/l3fwd: add option to relax Rx offload") > Cc: [email protected] > > Signed-off-by: Morten Brørup <[email protected]> > --- > examples/l3fwd/l3fwd.h | 2 +- > 1 file changed, 1 insertion(+), 1 deletion(-) > > diff --git a/examples/l3fwd/l3fwd.h b/examples/l3fwd/l3fwd.h > index 349fc37c79..331d17602d 100644 > --- a/examples/l3fwd/l3fwd.h > +++ b/examples/l3fwd/l3fwd.h > @@ -171,7 +171,7 @@ is_valid_ipv4_pkt(struct rte_ipv4_hdr *pkt, > uint32_t link_len, uint64_t ol_flags > > /* 2. The IP checksum must be correct. */ > /* if this is not checked in H/W, check it. */ > - if ((ol_flags & RTE_MBUF_F_RX_IP_CKSUM_MASK) == > RTE_MBUF_F_RX_IP_CKSUM_NONE) { > + if ((ol_flags & RTE_MBUF_F_RX_IP_CKSUM_MASK) == > RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN) { > uint16_t actual_cksum, expected_cksum; > actual_cksum = pkt->hdr_checksum; > pkt->hdr_checksum = 0; > -- > 2.43.0 Simple AI from CI says: > **Incorrect fix for the stated problem** > > The patch description states "If the PMD didn't check the IP header > checksum, the offload value is RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN, not > RTE_MBUF_F_RX_IP_CKSUM_NONE." > > However, according to the mbuf documentation: > - `RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN` (value 0) means the PMD reports no > checksum information at all > - `RTE_MBUF_F_RX_IP_CKSUM_NONE` means checksum is not offloaded but can > be software calculated > - `RTE_MBUF_F_RX_IP_CKSUM_BAD` means hardware reported checksum is bad > - `RTE_MBUF_F_RX_IP_CKSUM_GOOD` means hardware verified checksum is > good > > The original code checking for `RTE_MBUF_F_RX_IP_CKSUM_NONE` is > semantically more correct for "software must verify the checksum" than > `RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN`. When the value is `UNKNOWN`, the PMD > provides no information about whether it checked or not, so software > verification is prudent. But when it's explicitly `NONE`, software > checksum is definitely required. That is *not* how I interpret the enum values. The documentation says [1]: - RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN: no information about the RX IP checksum - RTE_MBUF_F_RX_IP_CKSUM_BAD: the IP checksum in the packet is wrong - RTE_MBUF_F_RX_IP_CKSUM_GOOD: the IP checksum in the packet is valid - RTE_MBUF_F_RX_IP_CKSUM_NONE: the IP checksum is not correct in the packet data, but the integrity of the IP header is verified I.e. UNKNOWN means that the PMD provided no information about the checksum. (Maybe it did not even look at the checksum.) The ol_flags field contains UNKNOWN (value 0) when RTE_ETH_RX_OFFLOAD_CHECKSUM was not requested. And this is exactly what the patch this patch fixes did: It cleared RTE_ETH_RX_OFFLOAD_CHECKSUM when the PMD didn't offer this capability. Whereas NONE means that the packet is good, but the checksum field in the packet has not been set by the sender (and may contain garbage). So it is absolutely wrong to verify the checksum field's value, when the ol_flags enum says that it is unset (and may contain garbage). My patch fixes that. [1]: https://github.com/DPDK/dpdk/blob/f43632ac7321385233ab6a11f0989aa6223dc61b/lib/mbuf/rte_mbuf_core.h#L74-L79
