【问题标题】:Preventing DPDK packet loss in L2 forwarding防止 L2 转发中的 DPDK 丢包
【发布时间】: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              
====================================================

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

【问题讨论】:

    标签: networking dpdk


    【解决方案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 队列已满,因为底层设备无法按照您提供的速率发送数据包。

    可能发生的情况很少:

    1. 您的 RX 端口速度大于 TX 端口速度(很可能不是您的情况)。

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

    3. 由于流量控制,您的 NIC 正在暂停传输,因此您有这些丢包(很可能是您的情况)。

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

    ethtool -A eth0 tx off rx off
    

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

    【讨论】:

    • 感谢您的建议。但我的情况比你所怀疑的要简单得多。对我来说,原因是某些数据包在标头中没有目的地,修复此问题后没有数据包丢失。但是,我在使用 L2 转发进行压力测试时遇到了您猜测的情况。
    猜你喜欢
    • 1970-01-01
    • 2021-12-06
    • 1970-01-01
    • 1970-01-01
    • 2011-07-23
    • 2012-08-18
    • 2018-06-22
    • 1970-01-01
    相关资源
    最近更新 更多