From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5117846C5F; Thu, 31 Jul 2025 13:31:42 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 0F5A9402E6; Thu, 31 Jul 2025 13:31:42 +0200 (CEST) Received: from mail-pj1-f41.google.com (mail-pj1-f41.google.com [209.85.216.41]) by mails.dpdk.org (Postfix) with ESMTP id 2FD39402AB for ; Thu, 31 Jul 2025 13:31:40 +0200 (CEST) Received: by mail-pj1-f41.google.com with SMTP id 98e67ed59e1d1-31ef50d8d57so612892a91.0 for ; Thu, 31 Jul 2025 04:31:40 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=bytedance.com; s=google; t=1753961499; x=1754566299; darn=dpdk.org; h=cc:to:subject:message-id:date:references:in-reply-to:mime-version :from:from:to:cc:subject:date:message-id:reply-to; bh=fVR37GBOhhSd83j6V14EKFdEetw4YPyUfcZYUVVou5M=; b=AXqFbWODndXuiNS1fwOTz0tkbgmN6i9LZNxgzWoO84cqpfOqI4/om5x6f0FggaDcwq IXhg9Mv/hIk73Nn6lweJwvpx6UaDRngPhct2Y9hg5HwmsQ5GSmDEjZ+c1DdKt7vmoEL/ gisSANLyyJ/PU+SGq8BNWC/nvuSnN+mM1ZixG8Cel7YOPWOBD/uPmdfrAIOJi3XPyZWL OXyUvMC49VhVOgyzcWaHdYDZo3Kmrk2O108QYTyaTms5i0pEs3aENkYmi/qGAZnvRsMQ QnMe+yHXspbBk9cQUdZjHy/IlaXbLMbW16TNhnFPuQ5mpCQ+LeKAffvEOs72rfTzJvpR PuRQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20230601; t=1753961499; x=1754566299; h=cc:to:subject:message-id:date:references:in-reply-to:mime-version :from:x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=fVR37GBOhhSd83j6V14EKFdEetw4YPyUfcZYUVVou5M=; b=ewj02bXhnNmUrgbL+veWrVX7UEpuZxLE9+5YP8512baYUf8iPJsZkKqgKXr3pQlob9 tY5FXwg25RawD7sH672beBLghGltqKcxPr1XFjK51EZMWySsxhWsz1m2a06EsAPGkdhe Qy8vt/i2nW/Ae5lH1/1dZLygPcFLLET8SX8EDGJfMbIpZt9QGKebPSEByG3F4rI1v14j uBZvKdGArGsRXEmcB+qi/rSCONR0pOhq6DIdT05p7FEPyzvxAdNGu6Bzf5u5JsJQGcnC WP+0BBiWfXuzDUPApTzhVhHinEd6e6DInRFk3GnUwRmYXKiTqPLkahMe2lGVVjBH2YOz IgCQ== X-Gm-Message-State: AOJu0Ywpj+rBTWRrEqrOsZd1U5KX8W/g8TlYn78RpBbVmCYZnE5ofedh CZwTixNWDTSmST8ii203uBuFxww+rHBpDqEA7NibiWsGe9GTI9d9gjOEUkWMjwe98/o81aWMaej 9TqwfLcTeI8FQhSk70ijVjeqvithL+fxqIqLDViyDAQ== X-Gm-Gg: ASbGncsqlQB4zvtab2A071nqiJt5ruUgM/VDGRsiFEK2DVM0dPUNLewriBg20DKn9rz khXrelRx+67MQFIptzbKYNcSZBTnEdATwqLK1sPHLvyWgnMeSWS1W4bzdcru3psbtrSGCsyWrhV 0IVYYgePkJHkIAYF/86JPOyv8/7WDH5WSiVQIGd3tHQOuu+W+bqCS1X2aHspk4ecZn7gxpBKh9d OTbJS4qxuzHi+tvUgwQ X-Google-Smtp-Source: AGHT+IEThAmo4RWBqtzY7eNj9OxrBpke/hyEaZhTWv7xyVfpiCFCir+ZNVLkf06zzyzWgFcKvZF8ijuS3Iq7EkbDaJE= X-Received: by 2002:a17:90b:55c8:b0:311:f05b:869b with SMTP id 98e67ed59e1d1-31f5de58622mr9377645a91.30.1753961499142; Thu, 31 Jul 2025 04:31:39 -0700 (PDT) Received: from 44278815321 named unknown by gmailapi.google.com with HTTPREST; Thu, 31 Jul 2025 04:31:38 -0700 Received: from 44278815321 named unknown by gmailapi.google.com with HTTPREST; Thu, 31 Jul 2025 04:31:38 -0700 From: Su Sai Mime-Version: 1.0 In-Reply-To: <18bc89bd254340f0b15653be473b0979@huawei.com> References: <2b98417ad1da4df2ac4e577b9c3938ae@huawei.com> <18bc89bd254340f0b15653be473b0979@huawei.com> Date: Thu, 31 Jul 2025 04:31:38 -0700 X-Gm-Features: Ac12FXzKjyOqqBpU6nmuYmLiS7lUg4vawhT0mzzbOQS_ZCrk999-NLmXIQ5mYfM Message-ID: Subject: Re: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments To: Marat Khalili , "jasvinder.singh@intel.com" Cc: "dev@dpdk.org" Content-Type: multipart/alternative; boundary="0000000000001b5118063b37fcb4" X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org --0000000000001b5118063b37fcb4 Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hi Marat Khalili, Thanks for your comments. We found small TCP checksum errors pkts online, then were traced to issues within the rte_raw_cksum_mbuf function. This error can be reproduced as follows: 1. In the client ECS with an MTU of 1500, initiate traffic using the command "iperf3 -c {dst ip} -b 1m -M 125 -t 8000". 2. In the destination ECS, the InCsumErrors statistic can be viewed using the command "netstat -st | grep -i csum". The erroneous packets can also be confirmed via the tcpdump command. The following is a detailed description of a captured erroneous packet. The hex stream of the packet is as follows: 00163e0b6bd2eeffffffffff0800450000a50d7a40004006b94bc0a8f91dc0a8f91ed5d2145= 146f9d990e10d6a2d8010020040a200000101080a95ac86ba091145d3ffffffffffffffffff= fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff= fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff= ffffffffffffffffffffffffffffffffffffffffffffffffff This is a packet in the format of eth + ipv4 + tcp + payload. The process leading to the error is as follows: 1. Due to the small MSS, TSO fragmentation was triggered, generating 3 mbufs. 2. The data_len of the first mbuf is 66 bytes, containing the Ethernet header, IPv4 header, and TCP header. 3. The data_len of the second mbuf is 61 bytes. 4. The data_len of the third mbuf is 52 bytes. 5. When calculating the checksum of the TCP header for such an mbuf chain using the rte_raw_cksum_mbuf function, the tmp value obtained during the calculation of the third mbuf is 0x19FFE6. 6. After applying rte_bswap16, tmp becomes 0xE6FF, with 0x19 discarded. This results in an incorrect final checksum. Meanwhile, we have also found that when enable jumbo frame, the payload becomes longer. In the process of rte_raw_cksum_mbuf handling an mbuf chain=EF=BC=8Cdue to the relatively large value of tmp, overflow will occur= in the accumulated sum. From: "Marat Khalili" Date: Thu, Jul 31, 2025, 19:04 Subject: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments To: "=E8=8B=8F=E8=B5=9B", "jasvinder.singh@intel.co= m"< jasvinder.singh@intel.com> Cc: "dev@dpdk.org" Sorry, sent the previous email too quickly. > -----Original Message----- > From: Marat Khalili > Sent: Thursday 31 July 2025 11:52 > To: '=E8=8B=8F=E8=B5=9B' ; jasvinder.singh@intel.= com > Cc: dev@dpdk.org > Subject: RE: [PATCH] net/cksum: compute raw cksum for several segments > > +static inline uint16_t > > +__rte_raw_cksum_reduce_u64(uint64_t sum) > > +{ > > + uint32_t tmp; > > + > > + tmp =3D __rte_raw_cksum_reduce((uint32_t)sum); > > + tmp +=3D __rte_raw_cksum_reduce((uint32_t)(sum >> 32)); > > What if this addition overflows? Realized it cannot actually overflow, my bad (maybe still needs a comment). Now this function looks good to me as well. > > + return __rte_raw_cksum_reduce(tmp); > > +} --0000000000001b5118063b37fcb4 Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hi Marat Khalili= ,

Thanks for your comments.

We found smal= l TCP checksum errors pkts online, then were traced to issues within the rt= e_raw_cksum_mbuf function.

<= /div>
=
This error can be reproduced as = follows:
1. In the client ECS wi= th an MTU of 1500, initiate traffic using the command "iperf3 -c {dst = ip} -b 1m -M 125 -t 8000".=C2=A0
2. In the destination ECS, the InCsumErrors statistic can be viewed u= sing the command "netstat -st | grep -i csum". The erroneous pack= ets can also be confirmed via the tcpdump=C2=A0command.

The= following is a detailed description of a captured erroneous packet. The he= x stream of the packet is as follows:
00163e0b6bd2eeffffffffff0800450000a50d7a40004006b94bc0a8f91dc0a8f91ed= 5d2145146f9d990e10d6a2d8010020040a200000101080a95ac86ba091145d3ffffffffffff= fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff= fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff= ffffffffffffffffffffffffffffffffffffffffffffffffffffffff

Th= is is a packet in the format of eth + ipv4 + tcp=C2=A0+ payload.

The process leading to the error is as follows:
1. Due to the small MSS, TSO fragmentation was trig= gered, generating 3 mbufs.
2. Th= e data_len of the first mbuf is 66 bytes, containing the Ethernet header, I= Pv4 header, and TCP header.
3. T= he data_len of the second mbuf is 61 bytes.
4. The data_len of the third mbuf is 52 bytes.
5. When calculating the checksum of the TCP head= er for such an mbuf chain using the rte_raw_cksum_mbuf function, the tmp va= lue obtained during the calculation of the third mbuf is 0x19FFE6.
6. After applying rte_bswap16, tmp becom= es 0xE6FF, with 0x19 discarded. This results in an incorrect final checksum= .

Meanwhile, we have also found that when=C2=A0enable=C2= =A0jumbo frame, the payload becomes longer. In the process of rte_raw_cksum= _mbuf handling an mbuf chain=EF=BC=8Cdue to the relatively large value of t= mp, overflow will occur in the accumulated sum.

From: "Marat Khalili"<marat.kh= alili@huawei.com>
Date: Thu, Jul 31, 2025, 19:04
Subject: [External] RE: [PATCH] net/ck= sum: compute raw cksum for several segments
To: "=E8=8B=8F=E8=B5=9B"<<= a href=3D"mailto:susai.ss@bytedance.com" style=3D"white-space:pre-wrap;word= -break:break-word;text-decoration:none;color:inherit" class=3D"quote-head-m= eta-mailto">susai.ss@bytedance.com>, "jasvinder.singh@in= tel.com"<jasvinder.singh@intel.com&g= t;
Cc: = "dev@dpd= k.org"<dev@dpdk.org>
<= /div>