即使 rte_eth_rx_burst 没有 return 完整的突发，也会丢弃数据包

Question

我有一个奇怪的掉落问题，要理解我的问题，最好的方法是看一下这个简单的片段：

while( 1 )
{
    if( config->running == false ) {
        break;
    }
    num_of_pkt = rte_eth_rx_burst( config->port_id,
                                   config->queue_idx,
                                   buffers,
                                   MAX_BURST_DEQ_SIZE);
    if( unlikely( num_of_pkt == MAX_BURST_DEQ_SIZE ) ) {
        rx_ring_full = true; //probably not the best name
    }

    if( likely( num_of_pkt > 0 ) )
    {
        pk_captured += num_of_pkt;

        num_of_enq_pkt = rte_ring_sp_enqueue_bulk(config->incoming_pkts_ring,
                                               (void*)buffers,
                                               num_of_pkt,
                                               &rx_ring_free_space);
        //if num_of_enq_pkt == 0 free the mbufs..
     }
}

此循环正在从设备中检索数据包并将它们推入队列以供另一个 lcore 进一步处理。

当我运行使用 Mellanox 卡进行测试以 2.5M p/s 发送 20M (20878300) 个数据包时，循环似乎丢失了一些数据包并且 pk_captured 总是像 19M 或相似。

rx_ring_full 永远不会为真，这意味着 num_of_pkt 总是 < MAX_BURST_DEQ_SIZE，因此根据文档，我不会在硬件级别上掉线。此外，num_of_enq_pkt 永远不会为 0，这意味着所有数据包都已排队。

现在，如果我从那个片段中删除了 rte_ring_sp_enqueue_bulk 调用（并确保释放所有 mbuf），那么 pk_captured 总是正好等于我发送到的数据包数量网卡。

所以看起来（但我无法处理这个想法）rte_ring_sp_enqueue_bulk 有点太慢了，在一次调用 rte_eth_rx_burst 和另一次调用之间，由于 NIC 上的完整响铃，一些数据包被丢弃，但是，为什么 num_of_pkt（来自 rte_eth_rx_burst）总是小于 MAX_BURST_DEQ_SIZE（小得多），好像总是有足够的空间容纳数据包？

注意，MAX_BURST_DEQ_SIZE是512。

编辑 1：

也许此信息可能有所帮助：rte_eth_stats_get 似乎也可以看到丢包，或者更正确地说，没有报告丢包（imissed 和 ierrors 为 0）但 ipackets 的值等于我的计数器pk_captured（丢失的数据包是不是就这么消失了？？）

编辑 2：

根据 ethtools rx_crc_errors_phy 为零，所有数据包都在 PHY 级别接收（rx_packets_phy 已更新为正确的传输数据包数量）。

来自 rte_eth_stats 的 rx_nombuf 的值似乎包含垃圾（这是我们测试应用程序的打印）：

OUT(4)：端口 1 统计数据：ipkt:19439285，opkt：0，ierr：0，oerr：0，imiss：0，rxnobuf:2061021195718

对于20M数据包的传输，如您所见，rxnobuf是垃圾或者它有我不明白的含义。日志生成者：

  log("Port %"PRIu8" stats: ipkt:%"PRIu64",opkt:%"PRIu64",ierr:%"PRIu64",oerr:%"PRIu64",imiss:%"PRIu64", rxnobuf:%"PRIu64,
        config->port_id,
        stats.ipackets, stats.opackets,
        stats.ierrors, stats.oerrors,
        stats.imissed, stats.rx_nombuf);

统计数据来自 rte_eth_stats_get。

数据包不是即时生成的，而是从现有 PCAP 重放的。

编辑 3

在 Adriy 回答后（谢谢！）我已经包含了 Mellanox 卡的 xstats 输出，同时用较小的一组数据包重现了同样的问题，我可以看到 rx_mbuf_allocation_errors 得到了更新，但是它似乎包含垃圾：

OUT(4): rx_good_packets = 8094164
OUT(4): tx_good_packets = 0
OUT(4): rx_good_bytes = 4211543077
OUT(4): tx_good_bytes = 0
OUT(4): rx_missed_errors = 0
OUT(4): rx_errors = 0
OUT(4): tx_errors = 0
OUT(4): rx_mbuf_allocation_errors = 146536495542

那些计数器似乎也很有趣：

OUT(4): tx_errors_phy = 0
OUT(4): rx_out_of_buffer = 257156
OUT(4): tx_packets_phy = 9373
OUT(4): rx_packets_phy = 8351320

其中 rx_packets_phy 是我发送的数据包的确切数量，将 rx_out_of_buffer 与 rx_good_packets 相加我得到了确切的数量。所以看起来 mbufs 耗尽了，一些数据包被丢弃了。

我对原始代码进行了调整，现在我正在使用 link 从 RX 环复制 mbuf，它们立即释放内存，进一步处理由另一个副本完成核心。可悲的是，这并没有解决问题，事实证明，要解决这个问题，我必须禁用数据包处理并释放数据包副本（在另一个 lcore 上），这是没有意义的。

嗯，会做更多的调查，但至少 rx_mbuf_allocation_errors 似乎需要修复这里。

Answer 1

我想，调试 rx_nombuf 计数器是一种可行的方法。它可能看起来像垃圾，但实际上这个计数器并不反映丢弃数据包的数量（像 ierrors 或 imissed 那样），而是反映失败的 RX 尝试次数。

这是来自 MLX5 PMD 的片段：

uint16_t
mlx5_rx_burst(void *dpdk_rxq, struct rte_mbuf **pkts, uint16_t pkts_n)
{
    [...]
    while (pkts_n) {
        [...]
        rep = rte_mbuf_raw_alloc(rxq->mp);
        if (unlikely(rep == NULL)) {
            ++rxq->stats.rx_nombuf;
            if (!pkt) {
                /*
                 * no buffers before we even started,
                 * bail out silently.
                 */
                break;

因此，该问题的可能情况如下：

RX队列中有数据包。
相应的内存池中没有缓冲区。
应用程序轮询新数据包，即循环调用：num_of_pkt = rte_eth_rx_burst(...)
每次我们调用 rte_eth_rx_burst()，rx_nombuf 计数器都会增加。

也请看看rte_eth_xstats_get()。对于 MLX5 PMD，有一个硬件 rx_out_of_buffer 计数器，这可能证实了这一理论。

Answer 2

丢失数据包的解决方案是将环 API 从 bulk 更改为 burst。在 dpdk 中有 2 种模式环操作批量和突发。在批量出队模式下，如果请求的元素是 32 个，并且有 31 个元素 API returns 0.

我也遇到过类似的问题

即使 rte_eth_rx_burst 没有 return 完整的突发，也会丢弃数据包

Dropped packets even if rte_eth_rx_burst do not return a full burst

network-programming

dpdk