It turns out the problem comes from a Cisco bug, not from DPDK.
First, I did some miscalculations, making me think the issue came from DPDK ? and it wasn't. > * in case 1, why data_len = 60 and not 56, since hw_strip_crc=1? And > why the CRC is present at the end? (C6 63 C2 CF) data_len is 60 because the minimal Ethernet frame size is 64 bytes and not 60, so after stripping the CRC by the hardware, the size is reduced by 4. Which is normal. The last four bytes don't correspond to the CRC though and should be 0 (explained below). > * case 2 seems totally normal: the CRC is not present Yes, that's normal > * for case 3, from what I understand, if hw_strip_crc is set to 0 the > ixgbe ddriver should remove the CRC > (http://dpdk.org/browse/dpdk/tree/drivers/net/ixgbe/ixgbe_rxtx.c#n1399). > Why pkt len is 60 here? And why is the CRC present at the end (F5 8D > CB 7C)? Exactly the same case than case 1. data_len is normal (but here the CRC is stripped by the driver and not by the hardware), and as in case 1, the last four bytes should be 0 but aren't. > * case 4 seems ok, the CRC is absent, as it has been removed by the driver Yes, that's normal. The problem is my network topology: my NAT software receives traffic from a Cisco Nexus 9000 which is buggy. When the Nexus untags a packet of 64 bytes (the minimal Ethernet size), it adds an extra four bytes padding before the CRC ? which is expected. However, those bytes should always be zeros, but here they are random, hence my checksum issue. Sorry for the noise, -- Julien Castets
