> I didn't take time to review the full explanation and code. > > Please could you review? > > https://inbox.dpdk.org/dev/cafqeoki8w8wayuy1ousn+qmgg1c2v7pjljeh608m894tplo...@mail.gmail.com/ >
I can suggest my condition to get a wrong checksum, which does not go into the details of how it was observed in the wild: Function rte_raw_cksum_mbuf may produce incorrect result when multiple segments are present in the checksummed range, and some of them have odd checksummed length. More precisely, if any segment except the last one begins at an odd offset from the start, and arithmetic sum of its 16-bit words overflows, the part that has overflown will be lost. Cases when there is only one segment, or all of the segment sizes and checksum offsets are even, are not affected.
