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

Question

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

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

我的测量：

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

问题：

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

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

Wireshark（通过 Tap 和 tcpdump）：请参阅此处（tcpdump.pcap 中的数据包编号 3189）

Answer 1

这是飞思卡尔快速以太网驱动程序 (fec_main.c) 中的一个错误，恩智浦现已通过其出色的支持修复了该错误。

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

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