[1/2] app/testpmd: revert L4 protocol retrieval from L3 header
Checks
Commit Message
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(-)
Comments
Hi Mingjin,
Could you please detail the step of testcase? we will try to reproduce it and
see how to solve it.
Thanks.
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>
Hi Chengwen,
Please refer to Bugzilla for more information.
Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1813
Thanks~
> -----Original Message-----
> From: fengchengwen <fengchengwen@huawei.com>
> Sent: Monday, November 10, 2025 5:56 PM
> To: Ye, MingjinX <mingjinx.ye@intel.com>; dev@dpdk.org
> Cc: stable@dpdk.org; Singh, Aman Deep <aman.deep.singh@intel.com>
> Subject: Re: [PATCH 1/2] app/testpmd: revert L4 protocol retrieval from L3
> header
>
> Hi Mingjin,
>
> Could you please detail the step of testcase? we will try to reproduce it and
> see how to solve it.
>
> Thanks.
>
> 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>
Hi Mingjin,
We have reproduce this bug in our platform, and trying to fix the solution.
Thanks
On 11/12/2025 5:01 PM, Ye, MingjinX wrote:
> Hi Chengwen,
>
> Please refer to Bugzilla for more information.
> Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1813
>
> Thanks~
>
>> -----Original Message-----
>> From: fengchengwen <fengchengwen@huawei.com>
>> Sent: Monday, November 10, 2025 5:56 PM
>> To: Ye, MingjinX <mingjinx.ye@intel.com>; dev@dpdk.org
>> Cc: stable@dpdk.org; Singh, Aman Deep <aman.deep.singh@intel.com>
>> Subject: Re: [PATCH 1/2] app/testpmd: revert L4 protocol retrieval from L3
>> header
>>
>> Hi Mingjin,
>>
>> Could you please detail the step of testcase? we will try to reproduce it and
>> see how to solve it.
>>
>> Thanks.
>>
>> 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>
>
Hi Mingjin,
I send a bugfix patch [1] to this problem, and also cc to you, could you help test it?
[1] https://patchwork.dpdk.org/project/dpdk/patch/20251117075046.11624-1-fengchengwen@huawei.com/
Thanks
On 11/13/2025 8:20 PM, fengchengwen wrote:
> Hi Mingjin,
>
> We have reproduce this bug in our platform, and trying to fix the solution.
>
> Thanks
>
> On 11/12/2025 5:01 PM, Ye, MingjinX wrote:
>> Hi Chengwen,
>>
>> Please refer to Bugzilla for more information.
>> Bugzilla: https://bugs.dpdk.org/show_bug.cgi?id=1813
>>
>> Thanks~
>>
>>> -----Original Message-----
>>> From: fengchengwen <fengchengwen@huawei.com>
>>> Sent: Monday, November 10, 2025 5:56 PM
>>> To: Ye, MingjinX <mingjinx.ye@intel.com>; dev@dpdk.org
>>> Cc: stable@dpdk.org; Singh, Aman Deep <aman.deep.singh@intel.com>
>>> Subject: Re: [PATCH 1/2] app/testpmd: revert L4 protocol retrieval from L3
>>> header
>>>
>>> Hi Mingjin,
>>>
>>> Could you please detail the step of testcase? we will try to reproduce it and
>>> see how to solve it.
>>>
>>> Thanks.
>>>
>>> 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>
>>
>
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
@@ -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;
+}
+
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;
+ 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