<div dir="ltr">Hi,<br><br>Yes, that should be considered as an expected behaviour. <div>The PMD will reduce 4 bytes from pkt_len when KEEP_CRC is configured. In that case the  user should check the CRC after the pkt_data in the mbuf to read its value.<br>2.Try allowing the NIC to receive packets with bad FCS by enabling this capability using ethtool (general NIC feature, applies to all frameworks)<br>"ethtool -K ens2f0 rx-all on" </div><div><br></div><div>Regards,</div><div>Erez</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">On Thu, 14 Jul 2022 at 16:52, Pfau, Johannes (ITIV) <<a href="mailto:johannes.pfau@kit.edu">johannes.pfau@kit.edu</a>> wrote:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">Hi all,<br>
<br>
We're currently developing a low-cost DAQ system to record high-bandwidth<br>
data from FPGA systems. We're using DPDK with Mellanox Connect-X5 cards, the<br>
drivers and DPDK installed from the standard RHEL 8 repositories. We capture<br>
raw ethernet (no L3) on 1:1 links to the FPGA devices to avoid all possible<br>
overhead. So far this setup works great, we can handle 100 Gbit/s of traffic<br>
even on a single core, but we can also distribute packets to multiple cores<br>
depending on the ether type if required.<br>
<br>
To save a few more bits in the transmission, we'd like to avoid encoding<br>
packet counters into the data stream. In that case we have to make sure we<br>
never miss any packets in recording though, even if the FCS is invalid.<br>
There are two aspects involved, leading to two questions:<br>
<br>
First, we need to store the CRC as well so that we can detect the invalid<br>
packets later on in offline processing. Using RTE_ETH_RX_OFFLOAD_KEEP_CRC is<br>
working fine, but it first confused me a lot: Both rte_pktmbuf_pkt_len and<br>
rte_pktmbuf_data_len still report the length without CRC. If I just read 4<br>
bytes more than announced in these functions, I can read the correct CRC. Is<br>
it intentional that the 4 CRC bytes are not included in these counts?<br>
<br>
Second, and this is a larger issue: We also need to receive packets with<br>
invalid FCS. We don't really have a an idea how to actually inject packets<br>
with invalid FCS for testing, but from the documentation I assume the mlx5<br>
driver in default setup would drop invalid packets? There was an mailing<br>
list discussing this for intel NICS<br>
(<a href="https://mails.dpdk.org/archives/users/2021-June/005651.html" rel="noreferrer" target="_blank">https://mails.dpdk.org/archives/users/2021-June/005651.html</a>), but I<br>
couldn't find anything for mlx5. Does anybody know if the mlx5 driver also<br>
offers an option to keep invalid packets?<br>
<br>
Best regards,<br>
Johannes<br>
<br>
-- <br>
Karlsruhe Institute of Technology (KIT)<br>
Institut für Technik der Informationsverarbeitung (ITIV)<br>
<br>
M.Sc. Johannes Pfau<br>
Research Associate<br>
<br>
Engesserstr. 5<br>
Building 30.10, Room 218.1<br>
76131 Karlsruhe, Germany<br>
<br>
Phone: +49 721 608-41939<br>
E-mail: <a href="mailto:johannes.pfau@kit.edu" target="_blank">johannes.pfau@kit.edu</a> <br>
<br>
<br>
Registered office:<br>
Kaiserstraße 12, 76131 Karlsruhe, Germany<br>
<br>
<br>
KIT – The Research University in the Helmholtz Association<br>
<br>
</blockquote></div>