network-programming - 即使 rte_eth_rx_burst 没有返回完整的突发，也会丢弃数据包

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 总是正好等于我发送到 NIC 的数据包数量。

所以看起来(但我无法处理这个想法)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 对副本进行。可悲的是，这并没有解决问题，事实证明，要解决这个问题，我必须禁用数据包处理并释放数据包副本(在另一个 lcore 上)，这是没有意义的。

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

Answer 1

我想，调试rx_nombuf 计数器是一种可行的方法。它可能看起来像垃圾，但实际上这个计数器并不反射(reflect)丢弃数据包的数量(如 ierrors 或 imissed do)，而是反射(reflect)失败的 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;

因此，该问题的合理场景如下:

1. RX队列中有数据包。
2. 相应的内存池中没有缓冲区。

3. 应用程序轮询新数据包，即循环调用:num_of_pkt = rte_eth_rx_burst(...)

4. 每次调用 rte_eth_rx_burst() 时，rx_nombuf 计数器都会增加。

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