DPDK-dev Archive on lore.kernel.org
 help / color / mirror / Atom feed
From: "Morten Brørup" <mb@smartsharesystems.com>
To: <dev@dpdk.org>, "Maxime Coquelin" <maxime.coquelin@redhat.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	"David Marchand" <david.marchand@redhat.com>
Cc: <stable@dpdk.org>,
	"Harrison Caldicott" <harrison@itsfubar.com.au>,
	"Robin Jarry" <rjarry@redhat.com>
Subject: RE: [PATCH] examples/l3fwd: fix check of unchecked IP checksum
Date: Fri, 16 Oct 2026 09:30:42 +0200	[thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35F65AB5@smartserver.smartshare.dk> (raw)
In-Reply-To: 20260915105822.988106-1-mb@smartsharesystems.com

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@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@dpdk.org
> >
> > Signed-off-by: Morten Brørup <mb@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


  parent reply	other threads:[~2026-10-16  7:30 UTC|newest]

Thread overview: 7+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-09-15 10:58 [PATCH] examples/l3fwd: fix check of unchecked IP checksum Morten Brørup
2026-09-15 12:39 ` Morten Brørup
2026-10-16  7:30 ` Morten Brørup [this message]
2026-10-24 10:10 ` [PATCH v2] examples/l3fwd: fix RFC 1812 checks Morten Brørup
2026-10-24 10:36 ` [PATCH v3] " Morten Brørup
2026-10-24 10:49 ` [PATCH v4] " Morten Brørup
2026-10-24 12:35 ` [PATCH v5] " Morten Brørup

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=98CBD80474FA8B44BF855DF32C47DC35F65AB5@smartserver.smartshare.dk \
    --to=mb@smartsharesystems.com \
    --cc=david.marchand@redhat.com \
    --cc=dev@dpdk.org \
    --cc=harrison@itsfubar.com.au \
    --cc=maxime.coquelin@redhat.com \
    --cc=rjarry@redhat.com \
    --cc=stable@dpdk.org \
    --cc=stephen@networkplumber.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox