PING for review. PS: This example application bug has propagated into Grout, and a bug report has been registered there [2].
[2]: https://github.com/DPDK/grout/issues/756 Venlig hilsen / Kind regards, -Morten Brørup > From: Morten Brørup > Sent: Tuesday, 15 September 2026 14.40 > > +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/f43632ac7321385233ab6a11f0989aa6223dc > 61b/lib/mbuf/rte_mbuf_core.h#L74-L79
