Re: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments

[Su Sai <susai.ss@bytedance.com>]

[-- Attachment #1: Type: text/plain, Size: 3063 bytes --]

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:
00163e0b6bd2eeffffffffff0800450000a50d7a40004006b94bc0a8f91dc0a8f91ed5d2145146f9d990e10d6a2d8010020040a200000101080a95ac86ba091145d3ffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff

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，due to the relatively large value of tmp, overflow will occur in the
accumulated sum.

From: "Marat Khalili"<marat.khalili@huawei.com>
Date: Thu, Jul 31, 2025, 19:04
Subject: [External] RE: [PATCH] net/cksum: compute raw cksum for several
segments
To: "苏赛"<susai.ss@bytedance.com>, "jasvinder.singh@intel.com"<
jasvinder.singh@intel.com>
Cc: "dev@dpdk.org"<dev@dpdk.org>

Sorry, sent the previous email too quickly.



> -----Original Message-----

> From: Marat Khalili

> Sent: Thursday 31 July 2025 11:52

> To: '苏赛' <susai.ss@bytedance.com>; 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 = __rte_raw_cksum_reduce((uint32_t)sum);

> > +        tmp += __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);

> > +}

[-- Attachment #2: Type: text/html, Size: 10044 bytes --]