DPDK patches and discussions
 help / color / mirror / Atom feed
From: fengchengwen <fengchengwen@huawei.com>
To: Mingjin Ye <mingjinx.ye@intel.com>, <dev@dpdk.org>,
	Stephen Hemminger <stephen@networkplumber.org>
Cc: <stable@dpdk.org>, Aman Singh <aman.deep.singh@intel.com>
Subject: Re: [PATCH 1/2] app/testpmd: revert L4 protocol retrieval from L3 header
Date: Tue, 18 Nov 2025 08:16:12 +0800	[thread overview]
Message-ID: <2ab451a3-accd-41a7-bde3-60a61cb478c0@huawei.com> (raw)
In-Reply-To: <20251105024724.830304-2-mingjinx.ye@intel.com>

On 11/5/2025 10:47 AM, Mingjin Ye wrote:
> This reverts commit 496159613ffc7b6ba592432a1ba4d1a38f6935de.
> 
> When the TX IP checksum offload feature is enabled, it may result in
> internal UDP checksum errors in VXLAN tunnel packets.
> 
> Fixes: 496159613ffc ("app/testpmd: fix L4 protocol retrieval from L3 header")
> Cc: stable@dpdk.org
> 
> Signed-off-by: Mingjin Ye <mingjinx.ye@intel.com>
> ---
>  app/test-pmd/csumonly.c | 39 +++++++++++++++++++++++----------------
>  1 file changed, 23 insertions(+), 16 deletions(-)
> 
> diff --git a/app/test-pmd/csumonly.c b/app/test-pmd/csumonly.c
> index a6e872e5a4..d355dbd8c0 100644
> --- a/app/test-pmd/csumonly.c
> +++ b/app/test-pmd/csumonly.c
> @@ -525,8 +525,20 @@ get_tunnel_ol_flags_by_ptype(uint32_t ptype)
>  	}
>  }
>  
> +static void
> +parse_inner_l4_proto(void *outer_l3_hdr,
> +			struct testpmd_offload_info *info)
> +{
> +	struct rte_ipv4_hdr *ipv4_hdr = outer_l3_hdr;
> +	struct rte_ipv6_hdr *ipv6_hdr = outer_l3_hdr;
> +	if (info->ethertype == _htons(RTE_ETHER_TYPE_IPV4))
> +		info->l4_proto = ipv4_hdr->next_proto_id;
> +	else
> +		info->l4_proto = ipv6_hdr->proto;

this function get L4 proto direct from header which can't handle inner IPv6 with option.

> +}
> +
>  static uint8_t
> -parse_l4_proto(const struct rte_mbuf *m, uint32_t off, uint32_t ptype, bool parse_inner)
> +parse_l4_proto(const struct rte_mbuf *m, uint32_t off, uint32_t ptype)
>  {
>  	int frag = 0, ret;
>  
> @@ -545,19 +557,16 @@ parse_l4_proto(const struct rte_mbuf *m, uint32_t off, uint32_t ptype, bool pars
>  		if (unlikely(ip6h == NULL))
>  			return 0;
>  
> -		if (!parse_inner && (ptype & RTE_PTYPE_L3_MASK) != RTE_PTYPE_L3_IPV6_EXT)
> -			return ip6h->proto;
> -
> -		if (parse_inner && (ptype & RTE_PTYPE_INNER_L3_MASK) != RTE_PTYPE_INNER_L3_IPV6_EXT)
> -			return ip6h->proto;
> +		if ((ptype & RTE_PTYPE_INNER_L3_MASK) ==
> +				RTE_PTYPE_INNER_L3_IPV6_EXT) {
> +			ret = rte_net_skip_ip6_ext(ip6h->proto, m, &off, &frag);
> +			if (ret < 0)
> +				return 0;

this logic has problem: parse_l4_proto was used to prase outer L4 if in tunnel case, but it depend on
whether inner is L3_IPV6_EXT.

> +			return ret;
> +		}
>  
> -		off += sizeof(struct rte_ipv6_hdr);
> -		ret = rte_net_skip_ip6_ext(ip6h->proto, m, &off, &frag);
> -		if (ret < 0)
> -			return 0;
> -		return ret;
> +		return ip6h->proto;
>  	}
> -
>  	return 0;
>  }
>  
> @@ -696,7 +705,7 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>  		info.l4_len = hdr_lens.l4_len;
>  		info.ethertype = get_ethertype_by_ptype(eth_hdr,
>  					ptype & RTE_PTYPE_L3_MASK);
> -		info.l4_proto = parse_l4_proto(m, info.l2_len, ptype, false);
> +		info.l4_proto = parse_l4_proto(m, info.l2_len, ptype);
>  
>  		l3_hdr = (char *)eth_hdr + info.l2_len;
>  		/* check if it's a supported tunnel */
> @@ -714,11 +723,9 @@ pkt_burst_checksum_forward(struct fwd_stream *fs)
>  		}
>  		/* update l3_hdr and outer_l3_hdr if a tunnel was parsed */
>  		if (info.is_tunnel) {
> -			uint16_t l3_off = info.outer_l2_len +  info.outer_l3_len + info.l2_len;
> -
>  			outer_l3_hdr = l3_hdr;
>  			l3_hdr = (char *)l3_hdr + info.outer_l3_len + info.l2_len;
> -			info.l4_proto = parse_l4_proto(m, l3_off, ptype, true);
> +			parse_inner_l4_proto(l3_hdr, &info);
>  		}
>  		/* step 2: depending on user command line configuration,
>  		 * recompute checksum either in software or flag the


  parent reply	other threads:[~2025-11-18  0:16 UTC|newest]

Thread overview: 9+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2025-11-05  2:47 [PATCH 0/2] " Mingjin Ye
2025-11-05  2:47 ` [PATCH 1/2] app/testpmd: revert " Mingjin Ye
2025-11-10  9:56   ` fengchengwen
2025-11-12  9:01     ` Ye, MingjinX
2025-11-13 12:20       ` fengchengwen
2025-11-17  8:07         ` fengchengwen
2025-11-18  0:16   ` fengchengwen [this message]
2025-11-05  2:47 ` [PATCH 2/2] app/testpmd: fix the IPv6 extension offset Mingjin Ye
2025-11-18  0:22   ` fengchengwen

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=2ab451a3-accd-41a7-bde3-60a61cb478c0@huawei.com \
    --to=fengchengwen@huawei.com \
    --cc=aman.deep.singh@intel.com \
    --cc=dev@dpdk.org \
    --cc=mingjinx.ye@intel.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;
as well as URLs for NNTP newsgroup(s).