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>,
	Chenbo Xia <chenbox@nvidia.com>
Cc: "Morten Brørup" <mb@smartsharesystems.com>, stable@dpdk.org
Subject: [PATCH v3] net/vhost: fix SW checksum when zero
Date: Sun, 18 Oct 2026 09:20:37 +0000	[thread overview]
Message-ID: <20261018092037.3143058-1-mb@smartsharesystems.com> (raw)
In-Reply-To: <20261017165952.3139535-1-mb@smartsharesystems.com>

There is a special rule for UDP, where a checksum of zero is as 0xffff
instead of zero.

Identifying packet types requires masking with the mask, not the value,
before comparing to the value.
Identifying by masking with the L4 UDP packet type value (0x00000200)
instead of the L4 packet type mask caused other L4 packet types to match;
specifically IP fragments, IGMP packets, and certain non-fragments.
This meant that some non-UDP packets followed the special UDP checksum
rule, which they should not.

Updated to mask the packet type with the L4 packet type mask and then
compare to the L4 UDP packet type value, so only UDP packets follow the
special UDP checksum rule.

Furthermore, according to the mbuf documentation, Tx checksum offload
requires that "ol_flags" is set, and only mentions "packet_type" for Rx,
so use "ol_flags" instead of "packet_type" for checking the packet type
at Tx.

Furthermore, writing the checksum needs room for 2 bytes, not 1 byte.

Note:
Using "if (unlikely(cksum == 0) && PTYPE_MATCH)" to advise the optimizer
about the need to evaluate PTYPE_MATCH being unlikely.
The probability of cksum being zero is only 1/65536, so it's better to
branch early.

Fixes: 8ba1723783b2 ("net/vhost: perform SW checksum in Tx path")
Fixes: 8f1750f42e2d ("net/vhost: perform SW checksum in Rx path")
Cc: stable@dpdk.org

Signed-off-by: Morten Brørup <mb@smartsharesystems.com>
---
v3:
* Writing the checksum needs room for 2 bytes, not 1 byte.
v2:
* Use ol_flags instead of packet_type for Tx.
* Added note about the use of unlikely().
---
 drivers/net/vhost/rte_eth_vhost.c | 9 +++++----
 1 file changed, 5 insertions(+), 4 deletions(-)

diff --git a/drivers/net/vhost/rte_eth_vhost.c b/drivers/net/vhost/rte_eth_vhost.c
index f6ef997455..9ffc844356 100644
--- a/drivers/net/vhost/rte_eth_vhost.c
+++ b/drivers/net/vhost/rte_eth_vhost.c
@@ -346,10 +346,11 @@ vhost_dev_tx_sw_csum(struct rte_mbuf *mbuf)
 
 	csum = ~csum;
 	/* See RFC768 */
-	if (unlikely((mbuf->packet_type & RTE_PTYPE_L4_UDP) && csum == 0))
+	if (unlikely(csum == 0) &&
+			(mbuf->ol_flags & RTE_MBUF_F_TX_L4_MASK) == RTE_MBUF_F_TX_UDP_CKSUM)
 		csum = 0xffff;
 
-	if (rte_pktmbuf_data_len(mbuf) >= csum_offset + 1)
+	if (rte_pktmbuf_data_len(mbuf) >= csum_offset + sizeof(uint16_t))
 		*rte_pktmbuf_mtod_offset(mbuf, uint16_t *, csum_offset) = csum;
 
 	mbuf->ol_flags &= ~RTE_MBUF_F_TX_L4_MASK;
@@ -389,10 +390,10 @@ vhost_dev_rx_sw_csum(struct rte_mbuf *mbuf)
 
 	csum = ~csum;
 	/* See RFC768 */
-	if (unlikely((ptype & RTE_PTYPE_L4_UDP) && csum == 0))
+	if (unlikely(csum == 0) && (ptype & RTE_PTYPE_L4_MASK) == RTE_PTYPE_L4_UDP)
 		csum = 0xffff;
 
-	if (rte_pktmbuf_data_len(mbuf) >= csum_offset + 1)
+	if (rte_pktmbuf_data_len(mbuf) >= csum_offset + sizeof(uint16_t))
 		*rte_pktmbuf_mtod_offset(mbuf, uint16_t *, csum_offset) = csum;
 
 	mbuf->ol_flags &= ~RTE_MBUF_F_RX_L4_CKSUM_MASK;
-- 
2.43.0


  parent reply	other threads:[~2026-10-18  9:20 UTC|newest]

Thread overview: 6+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2026-10-17 16:59 [PATCH] net/vhost: fix SW checksum when zero Morten Brørup
2026-10-17 18:21 ` [PATCH v2] " Morten Brørup
2026-10-18  9:20 ` Morten Brørup [this message]
2026-10-19 20:12   ` [PATCH v3] " Maxime Coquelin
2026-10-20  9:01     ` Morten Brørup
2026-10-20 11:19   ` Maxime Coquelin

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=20261018092037.3143058-1-mb@smartsharesystems.com \
    --to=mb@smartsharesystems.com \
    --cc=chenbox@nvidia.com \
    --cc=dev@dpdk.org \
    --cc=maxime.coquelin@redhat.com \
    --cc=stable@dpdk.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