DPDK丢包？

Posted 2023-04-15

【中文标题】DPDK丢包？

【英文标题】：DPDK packet drop?

【发布时间】：2021-12-06 00:40:04

【问题描述】：

我正在尝试调试使用 DPDK 时与丢包相关的问题。在没有 DPDK 的情况下使用应用程序时，没有发现任何问题。

解释： 我有一个进程 A 从进程 B（来自不同的服务器）接收数据包。

初始问题： 在进程 A 中启用 DPDK 时，前几秒钟，数据包流正常，但几分钟后进程 A 停止接收任何数据包。 这可能是什么原因？我已确认进程 B 正在发送数据包。

要调试这个： 我在我的应用程序中启用了 pdump 功能，以便我可以使用 dpdk-pdump 进行数据包捕获。 在调试时，我看到，当我使用 dpdk-proc-info 检查时，服务器正在接收数据包

[root@QVr740-6 app]# ./dpdk-proc-info   -- --stats -p 0x1
EAL: Cannot find resource for device
EAL: No legacy callbacks, legacy socket not created

  ######################## NIC statistics for port 0  ########################
  **RX-packets: 11595973**    RX-errors:  0           RX-bytes:  17231595358
  RX-nombuf:  0
  TX-packets: 0           TX-errors:  0           TX-bytes:  22

  ############################################################################

但是，当我尝试抓包时：

[root@QVr740-6 app]# ./dpdk-pdump -l 42,44,46  --   --pdump 'device_id=0000:18:00.1,queue=*,rx-dev=/home/cu1/nmurshed/capture.pcap'
EAL: Detected 56 lcore(s)
EAL: Detected 2 NUMA nodes
EAL: Multi-process socket /var/run/dpdk/rte/mp_socket_69588_2a3baabe32a56
EAL: Selected IOVA mode 'PA'
EAL: Probing VFIO support...
EAL: Probe PCI driver: net_i40e (8086:1572) device: 0000:18:00.1 (socket 0)
EAL: Probe PCI driver: net_i40e (8086:1572) device: 0000:18:00.2 (socket 0)
EAL: Cannot find resource for device
EAL: No legacy callbacks, legacy socket not created
Port 2 MAC: 02 70 63 61 70 01
 core (42), capture for (1) tuples
 - port 0 device (0000:18:00.1) queue 65535
^C

Signal 2 received, preparing to exit...
##### PDUMP DEBUG STATS #####
 -packets dequeued:                     0
 -packets transmitted to vdev:          0
 -packets freed:                        0

如何找出这些数据包丢弃的位置？ 我确实确认 dpdk-pdump 在没有看到问题时可以工作。

任何提示都会很有价值，因为我一直在扯头发。

编辑：

我错过了一些统计数据。我看到问题发生时 Rx-missed_errors 以惊人的速度不断增加。

Wed Oct 20 18:47:46 PDT 2021
rx_missed_errors: 0
Wed Oct 20 18:47:47 PDT 2021
rx_missed_errors: 0
Wed Oct 20 18:47:48 PDT 2021
rx_missed_errors: 0
Wed Oct 20 18:47:49 PDT 2021
rx_missed_errors: 8216
Wed Oct 20 18:47:50 PDT 2021
rx_missed_errors: 32384
Wed Oct 20 18:47:51 PDT 2021
rx_missed_errors: 56510
Wed Oct 20 18:47:52 PDT 2021
rx_missed_errors: 80636
Wed Oct 20 18:47:53 PDT 2021
rx_missed_errors: 104762
Wed Oct 20 18:47:54 PDT 2021
rx_missed_errors: 128882
Wed Oct 20 18:47:55 PDT 2021
rx_missed_errors: 152960
Wed Oct 20 18:47:56 PDT 2021
rx_missed_errors: 177086
Wed Oct 20 18:47:57 PDT 2021```

I increased the rx/tx desc in  rte_eth_rx_queue_setup which delays the problem. Somehow, my application is not freeing the rx_desc.

Question.. is each packet received == 1 rx_desc?
Is it possible that my application takes too long time to process packet ? or is it like I am not freeing them ?

【问题讨论】：

你说没有dpdk包流是什么意思，没有dpdk谁在接收包？

我的意思是..我有办法在没有 DPDK 的情况下构建进程 A..所以 dpdk 不在图片中。

@numrshed 请为 DPDK 添加编译标志（静态或共享）模式、进程 A 中 DPDK API 调用的 sn-p 以及用于 rte_eal_init 的参数。从当前问题解释you are referring to packet drop as process B (pdump) not receiving packets。这是正确的理解吗？

嗨@vipin，我错过了 rx_missed_errors 计数器...最初计数器为 0..然后它开始增加..这解释了下降 Wed Oct 20 18:47:48 PDT 2021 rx_missed_errors: 0 2021 年 10 月 20 日星期三 18:47:49 PDT rx_missed_errors：8216 10 月 20 日星期三 18:47:50 PDT 2021 rx_missed_errors：32384 10 月 20 日星期三 18:47:51 PDT 2021 rx_missed_errors：56510 10 月 20 日星期三 18:47:50 PDT : 80636 10 月 20 日星期三 18:47:53 PDT 2021 rx_missed_errors: 104762

是的，正确..我的应用程序本身没有收到数据包..我现在认为这是由于 rx_missed_errors..增加 rx_desc 会增加问题发生所需的时间..但我猜测需要根本原因为什么 fd 还不够......关于在我的应用程序中寻找什么的任何提示都会有所帮助

【参考方案1】：

DPDK 计数器 rx_missed_errors 推断在 NIC 上接收到的这些数据包未处理。而Rx-no-mbuf 代表计数器显示由于缺少 MBUF 缓冲区而不是 DMA 到 CPU 内存的数据包。因此错误主要出现在Spending too much time processing the packets 或recursive processing on the same MBUF array after rx_burst 的应用程序逻辑中。

[EDIT-1] 基于几次调试尝试和指针，问题是由应用程序逻辑引起的。总结如下

对于传入的 ARP 请求，处理数据包并在同一 MBUF 和 rte_pktmbuf_free 上发送 ARP 回复，我们在 rte_Eth_tx_burst 之后立即调用 - 已修复问题 对于 IP 数据包，IP 标头和 UDP 标头针对所需数据包进行处理，并在传输前对 MBUF 进行必要的更改。 - 对于某些条件（数据包计数），逻辑进入更长的循环，从而停止函数退出。

注意：

修复以上 2 个问题似乎可以解决问题。 使用 DPDK-Pktgen 生成自定义数据包可以缩小特定代码区域。

【讨论】：

非常感谢@Vipin 的帮助。和你聊天真是太好了。我从没想过，你会付出这么多时间。非常感谢您分享所有知识。没有你的帮助，不可能做到这一点

乐于帮助和分享，祝您的项目 Niyaz

即使在修复了代码循环之后，问题仍然存在。我得到以下错误而不是循环，然后我认为数据包被搞砸了.. i40e_dev_alarm_handler(): ICR0: 恶意编程检测到 i40e_handle_mdd_event()：TX 队列 1 上的恶意驱动程序检测事件 0x02 PF 编号 0x01 VF 编号 0x00 设备 0000:18:00.1 i40e_handle_mdd_event()：在 PF 上检测到 TX 驱动程序问题

@nimurshed，Maclicious 驱动程序是发送 (TX) 不正确的数据包描述符的结果。这不是 RX 的结果

好的..所以问题可能仍然存在于读取传入数据包时弄乱缓冲区的地方..但有一件事已经解决，我现在总是收到数据包。