防止 L2 转发中的 DPDK 丢包

Posted 2023-02-16

【中文标题】防止 L2 转发中的 DPDK 丢包

【英文标题】：Preventing DPDK packet loss in L2 forwarding

【发布时间】：2017-12-14 19:11:09

【问题描述】：

您好，我已经为 DPDK 实现了 pingpong。 客户端发送数据包，服务器接收数据包然后返回。

服务端部分的实现类似于DPDK官网的L2转发示例。

在进行 L2 转发时，我注意到在将数据包从接收队列转发到传输队列时存在数据包丢失。

我的问题是……有没有办法让丢包为零？

我找不到解决方案，因为 DPDK 网站的示例应用程序都有丢包。

丢包由下面的回调函数统计

rte_eth_tx_buffer_set_err_callback(tx_buffer[portid], rte_eth_tx_buffer_count_callback, &port_statistics[portid].dropped);

这是我从 L2 转发得到的结果

Port statistics ====================================
Statistics for port 0 ------------------------------
Packets sent:                   384126              
Packets received:               379889              
Packets dropped:                  4237              
Aggregate statistics ===============================
Total packets sent:             384126              
Total packets received:         379889              
Total packets dropped:            4237              
====================================================

由于我的实现只是乒乓球并且实现非常简单，因此我认为在我的情况下不应该有任何丢包。

【参考方案1】：

当函数rte_eth_tx_burst() 无法将数据包传输到目标端口时，rte_eth_tx_buffer_flush() 中的Packets dropped 计数器正在增加。

rte_eth_tx_burst() 函数只是调用你的tx_pkt_burst() PMD 回调，所以如果没有关于你的底层 PMD 的信息，很难说它为什么会失败。所以下面的部分是相当多的猜测......

所以一般来说，rte_eth_tx_burst() 会失败，因为 TX 队列已满。 TX 队列已满，因为底层设备无法按照您提供的速率发送数据包。

可能发生的情况很少：

您的 RX 端口速度大于 TX 端口速度（很可能不是您的情况）。

您的 RX 和 TX 端口具有相同的速度，但是您在应用中添加了一些额外的数据包，因此它们不再适合（可能是您的情况）。

由于流量控制，您的 NIC 正在暂停传输，因此您有这些丢包（很可能是您的情况）。

所以，如果我的猜测是正确的，只需在您的客户端使用 ethtool 禁用以太网流量控制：

ethtool -A eth0 tx off rx off

如果我的猜测不正确，那么在您的服务器端使用rte_eth_stats_get() 和rte_eth_xstats_get() 挖掘PMD 计数器，看看发生了什么。

【讨论】：

感谢您的建议。但我的情况比你所怀疑的要简单得多。对我来说，原因是某些数据包在标头中没有目的地，修复此问题后没有数据包丢失。但是，我在使用 L2 转发进行压力测试时遇到了您猜测的情况。