rte_eth_tx_burst突然停止发送数据包

Question

我的应用程序使用的是DPDK 21.11。经过一段时间后，API rte_eth_tx_burst停止发送任何数据包。

用于10 drv SFP+ 1572 drv=vfio的以太网控制器SFP+

MAX_RETRY_COUNT_RTE_ETH_TX_BURST 3


 do
            {
                num_sent_pkt = rte_eth_tx_burst(eth_port_id, queue_id, &mbuf[mbuf_idx], pkt_count);
                pkt_count -= num_sent_pkt;
                retry_count++;
            } while(pkt_count && (retry_count != MAX_RETRY_COUNT_RTE_ETH_TX_BURST));

为了调试，我尝试使用遥测技术打印出xstats。然而，我没有看到任何错误。

--> /ethdev/xstats,1
{"/ethdev/xstats": {"rx_good_packets": 97727, "tx_good_packets": 157902622, "rx_good_bytes": 6459916, "tx_good_bytes": 229590348448, "rx_missed_errors": 0, "rx_errors": 0, "tx_errors": 0, "rx_mbuf_allocation_errors": 0, "rx_unicast_packets": 95827, "rx_multicast_packets": 1901, "rx_broadcast_packets": 0, "rx_dropped_packets": 0, "rx_unknown_protocol_packets": 97728, "rx_size_error_packets": 0, "tx_unicast_packets": 157902621, "tx_multicast_packets": 0, "tx_broadcast_packets": 1, "tx_dropped_packets": 0, "tx_link_down_dropped": 0, "rx_crc_errors": 0, "rx_illegal_byte_errors": 0, "rx_error_bytes": 0, "mac_local_errors": 0, "mac_remote_errors": 0, "rx_length_errors": 0, "tx_xon_packets": 0, "rx_xon_packets": 0, "tx_xoff_packets": 0, "rx_xoff_packets": 0, "rx_size_64_packets": 967, "rx_size_65_to_127_packets": 96697, "rx_size_128_to_255_packets": 0, "rx_size_256_to_511_packets": 64, "rx_size_512_to_1023_packets": 0, "rx_size_1024_to_1522_packets": 0, "rx_size_1523_to_max_packets": 0, "rx_undersized_errors": 0, "rx_oversize_errors": 0, "rx_mac_short_dropped": 0, "rx_fragmented_errors": 0, "rx_jabber_errors": 0, "tx_size_64_packets": 0, "tx_size_65_to_127_packets": 46, "tx_size_128_to_255_packets": 0, "tx_size_256_to_511_packets": 0, "tx_size_512_to_1023_packets": 0, "tx_size_1024_to_1522_packets": 157902576, "tx_size_1523_to_max_packets": 0, "rx_flow_director_atr_match_packets": 0, "rx_flow_director_sb_match_packets": 13, "tx_low_power_idle_status": 0, "rx_low_power_idle_status": 0, "tx_low_power_idle_count": 0, "rx_low_power_idle_count": 0, "rx_priority0_xon_packets": 0, "rx_priority1_xon_packets": 0, "rx_priority2_xon_packets": 0, "rx_priority3_xon_packets": 0, "rx_priority4_xon_packets": 0, "rx_priority5_xon_packets": 0, "rx_priority6_xon_packets": 0, "rx_priority7_xon_packets": 0, "rx_priority0_xoff_packets": 0, "rx_priority1_xoff_packets": 0, "rx_priority2_xoff_packets": 0, "rx_priority3_xoff_packets": 0, "rx_priority4_xoff_packets": 0, "rx_priority5_xoff_packets": 0, "rx_priority6_xoff_packets": 0, "rx_priority7_xoff_packets": 0, "tx_priority0_xon_packets": 0, "tx_priority1_xon_packets": 0, "tx_priority2_xon_packets": 0, "tx_priority3_xon_packets": 0, "tx_priority4_xon_packets": 0, "tx_priority5_xon_packets": 0, "tx_priority6_xon_packets": 0, "tx_priority7_xon_packets": 0, "tx_priority0_xoff_packets": 0, "tx_priority1_xoff_packets": 0, "tx_priority2_xoff_packets": 0, "tx_priority3_xoff_packets": 0, "tx_priority4_xoff_packets": 0, "tx_priority5_xoff_packets": 0, "tx_priority6_xoff_packets": 0, "tx_priority7_xoff_packets": 0, "tx_priority0_xon_to_xoff_packets": 0, "tx_priority1_xon_to_xoff_packets": 0, "tx_priority2_xon_to_xoff_packets": 0, "tx_priority3_xon_to_xoff_packets": 0, "tx_priority4_xon_to_xoff_packets": 0, "tx_priority5_xon_to_xoff_packets": 0, "tx_priority6_xon_to_xoff_packets": 0, "tx_priority7_xon_to_xoff_packets": 0}}

我配置了RX= 128和TX= 512。

我假设有一些漏漏，有没有办法知道是否是由于没有漏货？我应该查一下哪个柜台“？

更多信息调试参考不会导致一个死胡同。在代码之后，NIC卡似乎没有在描述符上设置完成状态。当调用rte_eth_tx_burst时，下一个函数内部调用i40e_xmit_pkts -> i40e_xmit_cleanup

发生此问题时，以下条件将导致NIC发送数据包失败。

    if ((txd[desc_to_clean_to].cmd_type_offset_bsz &
            rte_cpu_to_le_64(I40E_TXD_QW1_DTYPE_MASK)) !=
            rte_cpu_to_le_64(I40E_TX_DESC_DTYPE_DESC_DONE)) {
        PMD_TX_LOG(DEBUG, "TX descriptor %4u is not done "
               "(port=%d queue=%d)", desc_to_clean_to,
               txq->port_id, txq->queue_id);
        return -1;
    }

如果我注释掉“返回-1”(当然不是修复，并将导致其他问题) ..but，我可以看到流量是长期稳定的。我跟踪所有的mbuf从开始的交通，直到问题被击中，没有问题，至少在mbuf，我可以看到。

描述符将以h/w为单位设置I40E_TX_DESC_DTYPE_DESC_DONE。我能看到那个密码吗？它是x710驱动程序代码的一部分吗？

我仍然怀疑我自己的代码，因为问题是存在的，即使是在网卡被更换后。但是，我的代码如何影响NIC卡不修改描述符的完成状态呢？任何建议都会很有帮助。

UPDATE发现有两个核心使用相同的TX queueID发送数据包。

1. 数据处理和TX核
2. ARP req/response by Data RX core

这会导致一些潜在的腐败？找到一些关于这个的信息：http://mails.dpdk.org/archives/dev/2014-January/001077.html

在为ARP消息创建单独的队列后，2+hours将不再出现问题

Answer 1

编辑-2错误被缩小到multiple threads are using same portid-queueid pair which causes the stalls in the NIC from XMIT。早些时候，调试并没有聚焦于慢速路径(ARP回复)，因此这一点被忽略了。

基于有限的调试机会和消息中的更新，这些更新包括

1. 内部TX代码更新refcnt 2(即refcnt是3)。
2. 一旦收到答复，refcnt就会减少2
3. 角的情况，现在RHEL上的
4. 角的情况已经解决了，而

操作系统都有问题，所以是软件而不是os

1. 更新了NIC固件，现在所有平台在运行几个小时后都会一致显示错误。

< code >G 212

注意：

因此，所有指针都会导致代码和角的大小写处理空白，因为testpmd\l2fwd\l3fwd不显示用DPDK库或platform.

• Since进行错误的情况--代码库不是共享的，只有依赖于更新的选项。

因此，经过广泛的调试和分析，问题的根本原因不是DPDK、NIC或平台，而是使用的代码中的空白。

如果代码的目的是在MAX_RETRY_COUNT_RTE_ETH_TX_BURST中尝试所有的pkt_count数据包，那么当前的代码片段需要进行一些修改。让我解释一下

mbuf是一个有效的数据包数组，它表示要发送给TX的当前索引，表示在当前attempt.

• num_sent_pkt中发送的数据包数量，表示发送给NIC的实际数据包，(physical).

• retry_count是重试的局部变量保持计数。

有两个角落的情况需要处理(不在当前代码段中共享)

如果超出了

1. ，而在num_sent_pkt is not equal to actual TX循环结束时，则需要释放未传输的MBUF；如果存在带ref_cnt greater than 1的MBUF(特别是多播或广播或数据包复制)，则
2. 也需要一种免费的机制。

一个可能的代码片段可以是：

MAX_RETRY_COUNT_RTE_ETH_TX_BURST 3
retry_count = 0;
mbuf_idx = 0;
pkt_count = try_sent; /* try_sent intended send*/

/* if there are any mbuf with ref_cnt > 1, we need separate logic to handle those */

do {
  num_sent_pkt = rte_eth_tx_burst(eth_port_id, queue_id, &mbuf[mbuf_idx], pkt_count);

  pkt_count -= num_sent_pkt;
  mbuf_idx += num_sent_pkt;
  
  retry_count++;
} while((pkt_count) && (retry_count < MAX_RETRY_COUNT_RTE_ETH_TX_BURST));

/* to prevent the leak for unsent packet*/
if (pkt_count) {
    rte_pktmbuf_free_bulk(&mbuf[mbuf_idx], pkt_count);
}

注意:识别mbuf泄漏的最简单方法是运行DPDK辅助进程process来检查mbuf空闲计数。

编辑- 1基于调试，已经确定最近确实大于1。累积这样的角落情况导致备忘录耗尽。

日志：

dump mbuf at 0x2b67803c0, iova=0x2b6780440, buf_len=9344
pkt_len=1454, ol_flags=0x180, nb_segs=1, port=0, ptype=0x291
segment at 0x2b67803c0, data=0x2b67804b8, len=1454, off=120, refcnt=3