DPDK getting too many rx_crc_errors on one port

0
votes

what may cause rx_crc_erros in DPDK ports? is it a software thing ? or a hardware thing related to the port or the traffic coming from the other end ?

DPDK Version: 19.02 PMD: I40E

This Port is running on customer Network, worth mentioning that this is the only port (out of 4) having this behaviour, so this may be a router/traffic thing but I couldnt verify that

used dpdk-proc-info to get this data enter image description here

could not do any additional activity as this is running on customer site

1
dpdk
please share more details like DPDK version, PMD in use, how packets are sent to DPDK port, and what is statics for xstats using dpdk-proc-info. did you cross-check if the same problem pops up with Linux drivers? I will not mark this as insufficient data. willw ait for your udpates. - Vipin Varghese
@VipinVarghese Updated ... please let me know in case i missed anything. Thanks - Charbel Semaan
thank you for the DPDK information. Can you get the Linux information via ethtool for reference? - Vipin Varghese
I have explained possible causes and corrections. Did you check any of those ? - Vipin Varghese
@VipinVarghese thanks your points makes perfect sense ... will check and update ASAP - Charbel Semaan

1 Answers

0
votes

DPDK I40E PMD has only option to enable or disable CRC on the port. Hence the assumption of DPDK I40E PMD is causing CRC error on 1 port out of 4 can be ruled out fully.

The `RX packets are validated by ASIC per port for CRC and then DMA to mbuf for packet buffer. The PMD copies the descirptor states to mbuf struct (one among them is CRC). The packet descriptor indicates the CRC result of the packet buffer to the driver (Kernel/DPDK-PMD). So the CRC error on a given port can arise due to the following reasons as

  • the port connected to ASIC is faulty (very rare case)
  • the SFP+ is not properly connected (possible).
  • the SFP+ is not the recommended one (possible).
  • the traffic coming from the other end is sending CRC packets as faulty.

One needs to isolate the issue by

  1. binding the port to Linux Driver i40e and checking the statistics via ethtool -S [port].
  2. Check SFP+ for compatibility on the faulty port by swapping with a working one.
  3. re-seat the SFP+ again.
  4. swap the data cables between working and faulty port. Then check if the error is present or not.

If all the above 4 cases the error only comes on the fault port, then indeed the NIC card has only 3 working ports among 4. The NIC card needs replacements or one should ignore the faulty port altogether. Hence this is not a DPDK PMD or library issue.