[PATCH] examples/l3fwd: fix check of unchecked IP checksum

Morten Brørup mb at smartsharesystems.com
Fri Oct 16 09:30:42 CEST 2026


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:mb at smartsharesystems.com]
> > 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: stable at dpdk.org
> >
> > Signed-off-by: Morten Brørup <mb at smartsharesystems.com>
> > ---
> >  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



More information about the dev mailing list