我在用iperf3 版本 3.5在 RHEL 8.0 下测试 10 Gbps 点对点以太网连接UDP。我将源网卡和目标网卡上的 MTU 都设置为1500。
我援引iperf3如下：
Server:
iperf3 -s -V --udp-counters-64bit --forceflush
Client:
iperf3 -u -V -b 0 --udp-counters-64bit -t 30 -c 192.168.0.1 --forceflush -l 1472
选择 1472 字节的 UDP 有效载荷大小是为了使以太网有效载荷大小恰好等于1500。我已与tcpdump我没有遇到帧碎片问题。
iperf3关于报告5.8 Gbps吞吐量。当我将 MTU 增加到9000（即巨型帧），报告的吞吐量跃升至约9.4 Gbps.（我假设iperf3报告有效载荷速率（即可用数据的速率，不包括报头）。
仅 MTU 无法解释这一点。以下是我预期的 MTU 理论有效载荷速率1500：
| 框架部分 | 大小（字节） |
|---|---|
| 以太网前言 | 7 |
| 以太网起始帧定界符 | 1 |
| 以太网头 | 14 |
| IP 报头 | 20 |
| UDP 报头 | 8 |
| UDP 负载 | 1472 |
| 以太网尾部（帧校验序列） | 4 |
| 帧间间隙 | 12 |
| 全部的 | 1538 |
有效载荷帧的分数：1472/1538 = 0.957087
因此，在 MTU 为1500，我预计理论有效载荷率为9.57087 Gbps。
如果 MTU 提高到9000，则 UDP 有效负载大小为 8972 字节，总大小为 9038 字节。按照上述方法计算，理论有效负载速率为9.92698 Gbps。
因此，MTU 根本无法反映实际测量的有效载荷速率5.8 Gbps。
在 MTU 中1500案件 （5.8 Gbps),iperf3报告了以下 CPU 使用率统计数据：
CPU Utilization: local/sender 99.7% (6.8%u/92.9%s), remote/receiver 58.1% (5.8%u/52.3%s)
在 MTU 中9000案件 （9.4 Gbps),iperf3报告了以下 CPU 使用率统计数据：
CPU Utilization: local/sender 99.8% (7.2%u/92.5%s), remote/receiver 56.7% (5.6%u/51.1%s)
还有什么原因可能导致 UDP 吞吐量大幅损失？