Linux 上传入网络包的延迟 - 如何分析？

Posted 2023-03-29

【中文标题】Linux 上传入网络包的延迟 - 如何分析？

【英文标题】：Delay of incoming network package on Linux - How to analyse?

【发布时间】：2021-10-26 14:46:57

【问题描述】：

问题是：有时 tcpdump 发现 UDP 数据包的接收被推迟到下一个传入的 UDP 数据包，尽管网络分流设备显示它通过电缆没有延迟。

场景：我在 Linux 上的 profinet 堆栈（位于用户空间）有一个循环连接，它每 4 毫秒（通过原始套接字）接收和发送 Profinet 协议数据包。根据该协议，大约每 30 毫秒它还会在 UDP 套接字上的另一个线程中接收 UDP 数据包并立即回复它们。大约 10% 的 CPU 负载。有时，接收到的 UDP 数据包似乎卡在网络驱动程序中。 2 秒后，下一个 UDP 数据包进来，丢失的 UDP 数据包和下一个都被接收。没有丢包。

我的测量：

我使用tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap 将UDP 流量记录到RAM 磁盘文件中。 同时我使用网络分流设备记录流量。

问题：

如何找出延迟的来源（或者是已知的影响）？ （2. 时间戳（tcpdump 为每个数据包设置的）告诉我什么？我的意思是，它指的是哪个 OSI 层，换句话说：它是什么时候使用的？）

拓扑：“带有 Linux 和 eth0 的嵌入式设备” tap-device PLC。程序“tcpdump”正在嵌入式设备上运行。 Tap 设备正在收听电缆。实际的 Profinet 连接是在 PLC 和嵌入式设备之间。一台 PC 连接在 Tap 设备上以记录它正在收听的内容。

Wireshark（通过 Tap 和 tcpdump）：参见 here（tcpdump.pcap 中的数据包编号 3189）

【问题讨论】：

您似乎在描述一个“腐烂的数据包”问题，在轮询到中断模式之间转换时，一些实现 NAPI 的以太网设备驱动程序中存在这种问题。见***.com/questions/23574203/… 和elixir.bootlin.com/linux/v2.6.16.11/source/Documentation/…

@sawdust 在那段时间里（当可能的“腐烂的 UDP 数据包”通过电缆到达，2 秒后下一个 UDP 数据包到达并解决它时）从原始套接字读取了很多 Profinet 数据包在并行线程中。所以我猜想以太网驱动程序实际上正在完成它的工作而没有睡太多（并且缺少东西）。

附加信息：使用 --time-stamp-precision=nano 记录 tcpdump 仍然显示有问题的 UDP 数据包有 2 秒的延迟（这是下一个 UDP 数据包进来的时间）跨度>

这是什么内核版本？什么驱动和设备？ “在那段时间......读取了很多 Profinet 数据包” -- 不要依赖用户空间活动来猜测驱动程序何时处理中断！事实上，这可能是触发问题的数据包突发。此外，EMAC 硬件无法区分 UDP 和 Profinet 帧。由于 RX 在数据包突发后变为空闲，因此会发生腐烂数据包。尝试 ping 该主机以查看是否会影响 2 秒延迟。据我了解，Profinet 是基于 UDP 构建的，因此您不太可能看到 UDP 堆栈问题。

内核是“5.4.61-rt37-lf-5.4.y+g20de6d5a36a4”和“dmesg|grep net”输出：“001: audit: initializing netlink subsys (disabled), 003: libphy ：fec_enet_mii_bus：已探测，000：fec 30be0000.ethernet eth0：已注册的 PHC 设备 0，000：fsl_dpa：FSL DPAA 以太网驱动程序，000：tsn 通用网络链接模块 v1 初始化...，001：Atheros 8031 以太网 30be0000.ethernet-1： 00: 附加 PHY 驱动程序 [Atheros 8031 以太网] (mii_bus:phy_addr=30be0000.ethernet-1:00, irq=POLL)"

【参考方案1】：

这是飞思卡尔快速以太网驱动程序 (fec_main.c) 中的一个错误，NXP 现在通过其强大的支持修复了它。

实际答案（对于“如何找出延迟从何而来？”的问题）是：必须构建一个启用内核跟踪的 Linux，使用内核跟踪修补驱动程序代码，然后使用开发者 Linux 工具 trace-cmd。这是一件非常复杂的事情，但我很高兴它现在得到了修复：

trace-cmd record -o /tmp/trace.dat -p function -l fec_enet_interrupt -l fec_enet_rx_napi -e 'fec:fec_rx_tp' tcpdump -i eth0 --time-stamp-precision=nano --time-stamp-type=adapter_unsynced -w /tmp/tcpdump.pcap