<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40">
<head>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8">
<meta name="Generator" content="Microsoft Word 15 (filtered medium)">
<style><!--
/* Font Definitions */
@font-face
        {font-family:"Cambria Math";
        panose-1:2 4 5 3 5 4 6 3 2 4;}
@font-face
        {font-family:DengXian;
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Calibri;
        panose-1:2 15 5 2 2 2 4 3 2 4;}
@font-face
        {font-family:"\@DengXian";
        panose-1:2 1 6 0 3 1 1 1 1 1;}
@font-face
        {font-family:Consolas;
        panose-1:2 11 6 9 2 2 4 3 2 4;}
/* Style Definitions */
p.MsoNormal, li.MsoNormal, div.MsoNormal
        {margin:0cm;
        font-size:11.0pt;
        font-family:"Calibri",sans-serif;}
span.EmailStyle26
        {mso-style-type:personal-reply;
        font-family:"Calibri",sans-serif;
        color:windowtext;}
.MsoChpDefault
        {mso-style-type:export-only;
        font-size:10.0pt;}
@page WordSection1
        {size:612.0pt 792.0pt;
        margin:72.0pt 72.0pt 72.0pt 72.0pt;}
div.WordSection1
        {page:WordSection1;}
--></style><!--[if gte mso 9]><xml>
<o:shapedefaults v:ext="edit" spidmax="1026" />
</xml><![endif]--><!--[if gte mso 9]><xml>
<o:shapelayout v:ext="edit">
<o:idmap v:ext="edit" data="1" />
</o:shapelayout></xml><![endif]-->
</head>
<body lang="EN-US" link="blue" vlink="purple" style="word-wrap:break-word">
<div class="WordSection1">
<p class="MsoNormal">> -----Original Message-----<br>
> From: Su Sai <susai.ss@bytedance.com><o:p></o:p></p>
<p class="MsoNormal">> Sent: Thursday 31 July 2025 12:32<o:p></o:p></p>
<p class="MsoNormal">> To: Marat Khalili <marat.khalili@huawei.com>; jasvinder.singh@intel.com<o:p></o:p></p>
<p class="MsoNormal">> Cc: dev@dpdk.org<o:p></o:p></p>
<p class="MsoNormal">> Subject: Re: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> Hi Marat Khalili,<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> Thanks for your comments.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> We found small TCP checksum errors pkts online, then were traced to issues within the rte_raw_cksum_mbuf function.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> This error can be reproduced as follows:<o:p></o:p></p>
<p class="MsoNormal">> 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".
<o:p></o:p></p>
<p class="MsoNormal">> 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.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> The following is a detailed description of a captured erroneous packet. The hex stream of the packet is as follows:<o:p></o:p></p>
<p class="MsoNormal">> 00163e0b6bd2eeffffffffff0800450000a50d7a40004006b94bc0a8f91dc0a8f91ed5d2145146f9d990e10d6a2d8010020040a200000101080a95ac86ba091145d3ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> This is a packet in the format of eth + ipv4 + tcp + payload.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> The process leading to the error is as follows:<o:p></o:p></p>
<p class="MsoNormal">> 1. Due to the small MSS, TSO fragmentation was triggered, generating 3 mbufs.<o:p></o:p></p>
<p class="MsoNormal">> 2. The data_len of the first mbuf is 66 bytes, containing the Ethernet header, IPv4 header, and TCP header.<o:p></o:p></p>
<p class="MsoNormal">> 3. The data_len of the second mbuf is 61 bytes.<o:p></o:p></p>
<p class="MsoNormal">> 4. The data_len of the third mbuf is 52 bytes.<o:p></o:p></p>
<p class="MsoNormal">> 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.<o:p></o:p></p>
<p class="MsoNormal">> 6. After applying rte_bswap16, tmp becomes 0xE6FF, with 0x19 discarded. This results in an incorrect final checksum.<o:p></o:p></p>
<p class="MsoNormal">> <o:p></o:p></p>
<p class="MsoNormal">> 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<span lang="ZH-CN" style="font-family:DengXian">,</span>due to the relatively large value
 of tmp, overflow will occur in the accumulated sum.<o:p></o:p></p>
<p class="MsoNormal"><o:p> </o:p></p>
<p class="MsoNormal">Thanks for the detailed description. I think both the bug and the fix are valid. Adding automated tests reproducing scenarios you described to app/test would help a lot, but I don’t know if you have cycles for this (I heard that AI is moderately
 good in generating test cases these days). I will ack your patch and let’s see what others say.<o:p></o:p></p>
</div>
</body>
</html>