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" Date: Thu, Jul 31, 2025, 19:04 Subject: [External] RE: [PATCH] net/cksum: compute raw cksum for several segments To: "苏赛", "jasvinder.singh@intel.com"< 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: '苏赛' ; 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); > > +}