如何测试Linux网络接口TSO/GSO 分段卸载功能验证

P粉602998670

发布时间：2025-08-20 10:21:01

614人浏览过

来源于php中文网

原创

tso/gso可通过ethtool命令查看和配置，并通过iperf3与tcpdump抓包验证其是否生效。1. 使用ethtool -k 检查网卡当前卸载功能状态，关注tso、gso、sg和tx-checksumming字段。2. 通过sudo ethtool -k tso on/gso on开启功能，或off关闭。3. 使用iperf3建立高吞吐连接，同时用tcpdump在发送端抓包，若tso/gso开启，抓包显示大包（如65535字节）；关闭则显示mtu大小包。4. 对比开启与关闭状态下的吞吐量和cpu利用率，验证性能差异。5. 接收端抓包始终显示mtu大小帧，证明分段发生在发送端网卡。

如何测试Linux网络接口TSO/GSO 分段卸载功能验证

测试Linux网络接口的TSO/GSO（TCP/Generic Segmentation Offload）分段卸载功能，核心在于利用

ethtool

命令查看和调整网卡的能力，并通过实际的网络流量工具如

iperf3

配合

tcpdump

进行抓包分析，来观察其对数据包大小和系统性能的影响。这不仅仅是看一个开关状态，更要理解它在数据传输路径上的实际作用。

解决方案：要验证TSO/GSO是否生效，我们通常会采取以下步骤：

检查网卡当前状态：使用
```
ethtool -k 
```
命令查看特定网络接口的卸载（offload）功能状态。例如，
```
ethtool -k eth0
```
。关注输出中
```
tso
```
、
```
gso
```
、
```
sg
```
（scatter-gather）以及
```
tx-checksumming
```
等字段，它们通常显示为
```
[fixed]
```
（硬件支持且开启）或
```
[off]
```
（关闭）或
```
[on]
```
（开启）。
理解
ethtool
输出：
```
tso
```
和
```
gso
```
是我们要关注的核心。
```
sg
```
（scatter-gather）是前提，它允许网卡从多个内存区域读取数据，组成一个大包发送。
```
tx-checksumming
```
是发送校验和卸载，也与性能相关。
生成测试流量：使用
```
iperf3
```
工具在两台Linux机器之间建立高吞吐量连接。例如，在服务器端运行
```
iperf3 -s
```
，在客户端运行
```
iperf3 -c  -t 30
```
（持续30秒）。
抓包分析：在发送端（
```
iperf3 -c
```
的机器）的网络接口上使用
```
tcpdump
```
进行抓包。关键在于观察数据包的长度。当TSO/GSO生效时，尽管实际在网络上传输的仍是MTU大小的帧，但在发送主机接口上用
```
tcpdump
```
抓取到的数据包，其长度会远大于MTU（例如，可能显示为65535字节，这是TCP的最大段长度），因为
```
tcpdump
```
是在分段操作发生之前捕获的。如果TSO/GSO关闭，
```
tcpdump
```
则会显示大量MTU大小（通常是1500字节）的数据包。
性能对比：在TSO/GSO开启和关闭两种状态下，分别运行
```
iperf3
```
并记录其吞吐量数据。同时，可以使用
```
top
```
或
```
mpstat
```
等工具观察发送端的CPU利用率。通常，开启TSO/GSO能显著降低CPU在网络栈上的开销，提升吞吐量。

TSO/GSO究竟是什么，它对网络性能有何影响？

在我看来，TSO和GSO这俩玩意儿，说白了，就是为了让CPU能少干点活，把一些原本它要做的繁琐工作甩给网卡或者内核更高效的机制去处理。这在处理高并发、大数据量传输的场景下，简直是性能优化的利器。

TSO (TCP Segmentation Offload)：顾名思义，它主要是针对TCP协议的。通常情况下，如果应用程序要发送一个很大的数据块（比如几万字节），TCP/IP协议栈在将数据交给网卡之前，需要把这个大块数据分割成一个个符合网络MTU（最大传输单元，以太网通常是1500字节）大小的TCP段。这个分割过程，包括计算每个段的TCP头部、校验和等，都是CPU的活儿。TSO的出现，就是让这个分割任务从CPU转移到支持TSO的网卡硬件上。这样，CPU只需要将一个巨大的TCP数据块（可以高达64KB甚至更多）连同其头部信息一次性扔给网卡，网卡自己会负责将其切割成符合MTU的小包，并加上正确的TCP/IP头部和校验和再发送出去。这极大地减少了CPU处理每个小包的开销，降低了CPU利用率，提高了整体的吞吐量。

GSO (Generic Segmentation Offload)：你可以把它理解为TSO的泛化版本。TSO只管TCP，而GSO则能处理更多类型的协议，比如UDP、GRE等。GSO的机制略有不同，它不一定完全依赖网卡硬件。如果网卡不支持TSO，或者是在虚拟化环境中（比如虚拟机内部的虚拟网卡），GSO可以在内核层面进行大包的聚合和分发。也就是说，应用程序仍然可以发送大块数据给内核，内核会以大包的形式在内部传输，直到数据即将离开物理网卡或者需要被虚拟化层处理时，才进行最终的分段。这同样能减少内核处理每个小包的上下文切换和中断次数，提升效率。

对网络性能的影响：

积极影响：
- 降低CPU利用率：这是最直接的收益。CPU从繁重的分段和校验和计算中解放出来，可以去处理更重要的应用逻辑。对于高IOPS或高带宽需求的服务器尤其明显。
- 提升吞吐量：减少了每个数据包的CPU开销，意味着在相同时间内可以处理更多的数据，从而提高网络的实际传输速率。
- 减少中断：每发送一个MTU大小的包，可能就需要一次中断。TSO/GSO将大包一次性处理，显著减少了中断次数，进一步降低了系统开销。
潜在挑战：
- 故障排查难度：当TSO/GSO开启时，
```
tcpdump
```
  在发送端捕获到的是大包，这可能会让人误以为网络中传输的就是大包，从而在排查MTU问题时产生困惑。你需要清楚，实际在物理线路上走的还是MTU大小的帧。
- 兼容性问题：虽然现在很少见了，但某些老旧的或有缺陷的网卡驱动、网络设备（如防火墙、路由器）可能对超大分段的处理不佳，导致性能下降甚至丢包。不过这在现代网络环境中已不常见。

在我看来，TSO/GSO是现代高性能网络栈的基石之一，理解并善用它，对于优化网络服务性能至关重要。

如何通过ethtool命令管理TSO/GSO状态？

ethtool

是Linux下管理和查询网络接口硬件设置的瑞士军刀。它能让你深入了解网卡的各种卸载功能，当然也包括TSO和GSO。管理这些功能的状态，主要就是通过

ethtool

的

-k

和

-k

参数。

首先，要查看一个网络接口（比如

eth0

）的当前卸载功能状态，你可以运行：

ethtool -k eth0

执行后，你会看到一长串的输出，里面包含了各种卸载功能的开启/关闭状态。我们需要重点关注这几项：

```
tcp-segmentation-offload: on [fixed]
```
或
```
off
```
：这就是TSO的状态。
```
[fixed]
```
表示硬件支持并已开启。

generic-segmentation-offload: on [fixed]

或

off

：这是GSO的状态。

```
scatter-gather: on [fixed]
```
或
```
off
```
：这是SG（散列-收集）功能，通常是TSO/GSO的基础。
```
tx-checksumming: on [fixed]
```
或
```
off
```
：发送校验和卸载，也常与TSO/GSO协同工作。

[fixed]

意味着这个功能是硬件支持的，并且通常是默认开启的。如果显示

on

但没有

[fixed]

，可能表示是软件层面的开启。

接下来，如果你需要修改这些状态（通常是为了测试目的，比如关闭它们来观察性能变化），你可以使用

-k

参数。

要关闭TSO：

Civitai

AI艺术分享平台！海量SD资源和开源模型。

下载

sudo ethtool -K eth0 tso off

要开启TSO：

sudo ethtool -K eth0 tso on

同样地，对于GSO：要关闭GSO：

sudo ethtool -K eth0 gso off

要开启GSO：

sudo ethtool -K eth0 gso on

请注意，这些命令修改的状态通常是临时的，即系统重启后会恢复到默认设置。如果你想让这些设置持久化，你需要根据你的Linux发行版和网络配置方式来操作：

对于Systemd/NetworkManager环境：可能需要在
```
networkd
```
配置（如
```
/etc/systemd/network/*.network
```
）或
```
NetworkManager
```
的连接配置中添加相应的
```
ethtool
```
命令或参数。
对于旧的
ifupdown
系统（如Debian/Ubuntu）：可以在
```
/etc/network/interfaces
```
文件中对应接口的配置段落中添加
```
post-up ethtool -K eth0 tso off
```
这样的行。

对于CentOS/RHEL的
ifcfg
文件：可以在

/etc/sysconfig/network-scripts/ifcfg-

文件中添加

ETHTOOL_OPTS="-K ${DEVICE} tso off"

。

或者最简单粗暴但不太推荐的方式：将这些
```
ethtool
```
命令添加到
```
/etc/rc.local
```
（如果存在且启用）或通过
```
systemd
```
服务在系统启动时执行。

我个人在生产环境中很少去主动关闭TSO/GSO，因为它们通常是性能的正面因素。除非遇到非常特殊的网络问题，怀疑是卸载功能导致的，才会去尝试关闭它们进行排查。

在实际网络流量中，如何验证TSO/GSO是否生效？

验证TSO/GSO是否真正生效，光看

ethtool

的开关状态是不够的，我们还得看实际的数据流。这里面有一个非常关键但又容易让人困惑的地方：

tcpdump

在发送端抓包时，看到的数据包大小会因为TSO/GSO的开启而“膨胀”。

核心验证逻辑：如果TSO/GSO功能开启，Linux内核在发送数据时，会将一个非常大的数据块（比如64KB）直接交给网卡处理。此时，如果你在发送端的网卡接口上用

tcpdump

抓包，你将看到这些大尺寸的“逻辑包”（例如，TCP包长度显示为65535字节）。这表明内核已经将大包交给了网卡，由网卡来完成后续的分段工作。相反，如果TSO/GSO功能关闭，内核会自己将数据分割成MTU大小（通常是1500字节）的帧，然后才交给网卡。此时，

tcpdump

在发送端抓到的包，其长度就不会超过MTU。

具体验证步骤：

准备测试环境：
- 两台Linux机器，确保它们之间有良好的网络连接。
- 安装
```
iperf3
```
  和
```
tcpdump
```
  工具。
- 确定要测试的网络接口名称（例如
```
eth0
```
  ）。
基准测试（TSO/GSO关闭）：
- 在发送端关闭TSO/GSO：
```
sudo ethtool -K eth0 tso off gso off
```
- 在发送端启动
  tcpdump
  抓包：
```
sudo tcpdump -i eth0 -n -s 0 -w /tmp/tso_off.pcap host <接收端IP> and tcp port 
# 例如：sudo tcpdump -i eth0 -n -s 0 -w /tmp/tso_off.pcap host 192.168.1.10 and tcp port 5201
```
```
-s 0
```
  表示抓取完整数据包，
```
-n
```
  表示不解析主机名和端口名，提高效率。
- 在接收端启动
  iperf3
  服务器：
```
iperf3 -s
```
- 在发送端启动
  iperf3
  客户端：
```
iperf3 -c <接收端IP> -P 1 -t 10 # -P 1表示单线程，-t 10表示运行10秒
```
- 停止
  tcpdump
  （Ctrl+C），并使用
```
wireshark
```
  或
```
tshark
```
  分析
```
/tmp/tso_off.pcap
```
  。你会发现绝大多数TCP数据包的长度都在MTU附近（比如1460字节的TCP数据 + 40字节的TCP/IP头部 = 1500字节）。
功能验证（TSO/GSO开启）：
- 在发送端开启TSO/GSO：
```
sudo ethtool -K eth0 tso on gso on
```
- 重复抓包和
  iperf3
  测试：
```
sudo tcpdump -i eth0 -n -s 0 -w /tmp/tso_on.pcap host <接收端IP> and tcp port 
iperf3 -c <接收端IP> -P 1 -t 10
```
- 停止
  tcpdump
  ，分析
```
/tmp/tso_on.pcap
```
  。你会惊奇地发现，
```
tcpdump
```
  抓到的TCP数据包长度会非常大，比如65535字节（这是TCP的理论最大段长度），或者其他几千、几万字节的大包。这正是TSO/GSO生效的直接证据。

额外验证：

性能对比：对比两次
```
iperf3
```
测试的吞吐量数据。通常，开启TSO/GSO后的吞吐量会更高。
CPU利用率：在两次测试过程中，使用
```
top
```
或
```
mpstat -P ALL 1
```
观察发送端的CPU利用率。开启TSO/GSO后，尤其是在
```
iperf3
```
这种高吞吐量场景下，CPU的
```
sy
```
（系统）和
```
us
```
（用户）利用率通常会有显著下降。
接收端抓包：如果你在接收端也进行
```
tcpdump
```
抓包，你会发现无论发送端TSO/GSO是否开启，接收端收到的数据包都是MTU大小的帧。这进一步证明了TSO/GSO是在发送端进行的操作，网卡在发送前已经完成了分段。