关闭TSO后吞吐下降是因为内核转为软件分段，CPU开销增大，且GSO fallback导致额外封装、cache miss和延迟；需按顺序关闭TSO和GSO，并确认相关内核参数与队列限制。
为什么 ethtool -K tso off 会导致吞吐下降
关闭 TCP 分段卸载（TSO）后，内核必须在协议栈中完成 TCP 段的分片和 IP 封装，这会显著增加 CPU 开销，尤其在高吞吐、大包场景下。关键在于：TSO 关闭后，generic-segmentation-offload（GSO）路径仍可能被触发，但此时已无硬件配合，反而因额外封装和 skb 分割引入延迟与 cache miss。
如何确认 GSO 是否仍在生效并造成干扰
用 ethtool -k 查看当前卸载状态，重点检查：generic-segmentation-offload 和 tcp-segmentation-offload 两项是否均为 off；若前者为 on 而后者为 off，说明 GSO 正在强制 fallback 到软件分段，这是性能下降的典型诱因。
-
ethtool -k eth0 | grep -E "(generic|tcp)-segmentation"—— 必须两者都 off 才算干净回滚 - 抓包验证：
tcpdump -i eth0 'tcp[tcpflags] & (tcp-syn|tcp-fin|tcp-rst) != 0'观察是否有异常的超小 MSS 分段或重传激增 -
cat /proc/net/snmp | grep -A1 Tcp中TCPSegsOut增速若远高于应用发包速率，说明 GSO fallback 导致重复分段
安全关闭 GSO 的正确顺序
不能只关 TSO——GSO 是上层通用机制，TSO 只是其一个后端。直接关 GSO 可能影响 UDP GSO（如 VXLAN）、SCTP 等，需按依赖层级操作：
