Performance linux中发送和接收tcp/udp数据包的延迟源

linux 2.6中发送/接收TCP/UDP数据包过程中的延迟源是什么

我想知道“乒乓”延迟测试中的延迟源

有一些关于以太网延迟的很好的论文，但它们只涉及到有线和交换机中的延迟源（相当粗略，只针对特定的交换机）

数据包后面有哪些处理步骤

对普通ping（icmp）进行深度延迟分析的论文也会很有用

---

我依赖社区：）

尽管它已经很老了，但本指南详细介绍了linux网络堆栈

如果通读这些内容，您应该能够发现可以通过内核添加延迟的地方

---

e、 g.如果在内核中临时缓冲了一个帧

简短回答：对于内核中的确切延迟，您应该使用perf probe和perf script

更多详细信息： 让我们看看下面的例子。首先，我们想看看TCP乒乓测试使用了哪些函数（我使用的是netperf）

在接收流上：

在传输流上：

让我们跟踪传输流的一些函数（它很长，所以我将显示TCP流中的主要函数）。我们可以使用perf probe对每个函数的入口和出口点进行采样：

perf probe --add sock_sendmsg='sock_sendmsg'
perf probe --add sock_sendmsg_exit='sock_sendmsg%return'
perf probe --add inet_sendmsg='inet_sendmsg'
perf probe --add inet_sendmsg_exit='inet_sendmsg%return'
perf probe --add tcp_sendmsg_exit='tcp_sendmsg%return'
perf probe --add tcp_sendmsg='tcp_sendmsg'
perf probe --add tcp_sendmsg_locked='tcp_sendmsg_locked'
perf probe --add tcp_sendmsg_locked_exit='tcp_sendmsg_locked%return'
perf probe --add sk_stream_alloc_skb='sk_stream_alloc_skb'
perf probe --add sk_stream_alloc_skb_exit='sk_stream_alloc_skb%return'
perf probe --add tcp_push_exit='tcp_push%return'
perf probe --add tcp_push='tcp_push'
perf probe --add tcp_send_mss='tcp_send_mss'
perf probe --add tcp_send_mss_exit='tcp_send_mss%return'
perf probe --add __tcp_push_pending_frames='__tcp_push_pending_frames'
perf probe --add __tcp_push_pending_frames_exit='__tcp_push_pending_frames%return'
perf probe --add tcp_write_xmit_exit='tcp_write_xmit%return'
perf probe --add tcp_transmit_skb_exit='tcp_transmit_skb%return'
perf probe --add tcp_transmit_skb='tcp_transmit_skb'

不，我们可以记录这些：

perf record -e probe:* -aR taskset -c 7 netperf -t TCP_RR -l 5 -T 7,7

并为延迟报告运行性能脚本：

perf script -F time,event --ns

输出（1次迭代）：

现在很容易看出延迟是在哪里度过的。例如，我们可以注意到，在sock_sendmsg（）调用和inet_sendmsg（）调用之间有1504纳秒（ns）或1.504微秒（us）的延迟。另外，我们可以看到sk_stream_alloc_skb需要957ns。总的来说，整个过程（从sock_sendmsg入口到出口）需要约24.5us。请记住，这不是你在NETPRF中看到的，因为数据包实际上是在流中间某个地方传输的。 您可以使用相同的方法跟踪内核中的任何代码段

希望这有帮助

---

p.S.这是在内核4.14而不是2.6上完成的。我不确定当时perf是如何开发的，所以它可能无法正常工作。

谢谢！现在可以使用现代内核了。你是怎么弄到火焰图的？据我所知，经典的flamegraph使用“sum”，它不是在绝对时间线上绘制函数，而是在多次执行中绘制时间百分比，并在评测模式下与perf一起使用。那么，您使用绝对时间线绘制了类似flamegraph的

perf script

输出？我将如何在图中看到访问硬件的延迟（驱动程序应在hw/dma队列中创建描述符，并通过端口/pio/mmio向网络控制器发送新描述符的信号）？[1]这些火焰图是使用以下（优秀）手册创建的：。它基于性能，需要记录数据才能工作。我总是从它们开始性能调试，因为它们完美地说明了运行时发生的事情。剩下的调试（perf probe、record和script）在下一次迭代中完成，而不是使用相同的数据。[2]关于硬件访问，每个驱动程序都有自己的驱动程序。对于mlx5驱动程序发送，这是：。

525987.403094082:                   probe:sock_sendmsg:
525987.403095586:                   probe:inet_sendmsg:
525987.403096192:                    probe:tcp_sendmsg:
525987.403098203:             probe:tcp_sendmsg_locked:
525987.403099296:                   probe:tcp_send_mss:
525987.403100002:              probe:tcp_send_mss_exit:
525987.403100740:            probe:sk_stream_alloc_skb:
525987.403101697:       probe:sk_stream_alloc_skb_exit:
525987.403103079:                       probe:tcp_push:
525987.403104284:      probe:__tcp_push_pending_frames:
525987.403105575:               probe:tcp_transmit_skb:
525987.403110178:               probe:tcp_transmit_skb:
525987.403111640:          probe:tcp_transmit_skb_exit:
525987.403112876:          probe:tcp_transmit_skb_exit:
525987.403114351:            probe:tcp_write_xmit_exit:
525987.403114768: probe:__tcp_push_pending_frames_exit:
525987.403115191:                  probe:tcp_push_exit:
525987.403115718:        probe:tcp_sendmsg_locked_exit:
525987.403117576:               probe:tcp_sendmsg_exit:
525987.403118082:              probe:inet_sendmsg_exit:
525987.403118568:              probe:sock_sendmsg_exit: