Re: [dpdk-users] .hw_strip_crc weird behavior with small UDP packets

[Julien Castets <castets.j@gmail.com>]

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