Offload flow APR GC

下面我给你一个 精确、可落地、可以快速判断：

到底是：
（1）网卡 Offload（GRO/LRO/TSO/RXCSUM/TXCSUM）问题？
（2）Flow 流量过大（队列/CPU软中断高）？
（3）ARP GC 或邻居缓存问题？

并且告诉你 如何判断、如何复现、如何定位、如何排除。

你贴的命令：

ethtool --offload flannel.1 rx off tx off
ethtool --offload cni0 rx off tx off
ethtool --offload eno3 rx off tx off

这是企图关闭 offload 来验证，但这样做 很容易误判，因为 Linux 网络的瓶颈可能来自多层。

我下面按你的需求给你一个 精准判断流程。

---

✅ 一、判断是否“网卡 Offload”导致网络问题

Offload 可能导致的问题：

• GRO/LRO 合并导致延迟（尤其 VXLAN / flannel）

• RX/TX checksum offload 兼容性问题

• TSO 大包导致 CPU softirq 增高

• 某些虚拟网卡（flannel.1 / cni0）反而不能 Offload

要判断是不是 Offload 的锅，看这几个信号：

---

① dmesg / kernel log 出现 checksum / GRO / LRO 错误

执行：

dmesg -T | egrep -i "checksum|gro|lro|rx error|tx error|skb"

如果 Offload 出问题，会看到：

• skb checksum error

• hw csum failure

• rx csum incorrect

• netif_receive_skb_general: drop

• gro: packet malformed

出现这些就说明 Offload 的兼容性有问题 → 就该关。

---

② ethtool -S 查看网卡硬件错误

ethtool -S eno3 | egrep "err|drop|fail"

关注：

• rx_errors

• tx_errors

• rx_crc_errors

• rx_no_buffer_count

• rx_missed_errors

• rx_length_errors

• rx_over_errors

如果 Offload 出问题，错误计数会持续增加。

---

③ perf top 看 softirq 是否异常集中在 GRO/TSO

perf top

如果看到：

net_rx_action
napi_gro_receive
tcp_tso_segs
skb_gro_receive

这些异常升高 → GRO/TSO 过大包合并导致 CPU 卡死。

尤其典型于：flannel + 高 QPS + 大包。

---

④ 用 ethtool 关闭后问题消失 → 基本确认是 Offload

按你贴的命令：

ethtool --offload eno3 rx off tx off
ethtool --offload flannel.1 rx off tx off
ethtool --offload cni0 rx off tx off

如果关掉后：

• ping 延迟下降

• curl/业务延迟下降

• softirq 下降

• rx_errors 不再递增

→ 确认是 Offload 的锅。

---

❗如果关闭 Offload 后仍然卡 → 问题不在 Offload

就进入下两个判断：Flow 还是 ARP GC。

---

✅ 二、判断是否 Flow（流量 / QPS / CPU 软中断）问题

判断 Flow 的方法比 Offload 更直接：

---

① softirq（ksoftirqd）是否满 CPU

top -H -p `pidof ksoftirqd/0`

或：

mpstat -P ALL 1

如果看到：

• 某个 CPU 的 %soft >= 50%

• ksoftirqd 占用很高

→ Flow 过大，网卡队列打满。

---

② /proc/net/softnet_stat 是否丢包

cat /proc/net/softnet_stat

每一行对应 CPU，格式：

cpu0: xxx yyy zzz ...

关键字段：

• 第 1 个字段：flow 队列满了（netdev budget exhausted）

• 第 2 个字段：RX dropped（硬件没来得及处理）

• 第 3 个字段：软中断丢包

如果某 CPU 某项累计增长：

→ 流量瓶颈 / RPS/RFS 不足 / bind irq imbalance。

---

③ 观察 RX/TX ring buffer 是否满（Flow 畸高）

ethtool -g eno3

如果 ring buffer 很小而流量很大 → 很容易丢包。

---

④ sar 看网络收发速率逼近网卡上限

sar -n DEV 1

如果接近：

• 1Gbps → 950Mbps 上下

• 10Gbps → 9.5Gbps 上下

则 Flow 过载。

---

⚠ 结论：

如果 softirq 高、softnet_stat 增长、sar 显示流量接近带宽 → 是 Flow 过载，不是 Offload 或 ARP。

---

✅ 三、判断是否 ARP GC（邻居缓存）问题

这个问题常发生在 大量 Pod 的 flannel/cni0 网段中。

典型表现：

• ping flannel 网段偶发丢包

• curl 某服务间歇性超时

• dmesg 出现：

  neighbour table overflow
  ARP cache full
  

---

① 查看 neighbor 缓存是否溢出

ip -s neigh

如果看到：

• FAILED 很多

• INCOMPLETE 很多

→ ARP 缓存不足。

---

② 查看是否出现 overflow 错误

dmesg | grep -i "neigh\|arp"

出现：

neighbour table overflow

→ 确定是 ARP GC。

---

③ 查看 neigh table 大小是否被打满

sysctl -a | grep neigh | grep gc

一般参数：

net.ipv4.neigh.default.gc_thresh1
net.ipv4.neigh.default.gc_thresh2
net.ipv4.neigh.default.gc_thresh3

如果阈值偏小（例如 flannel 网段 1000+ Pod）→ neighbor 缓存经常溢出。

---

📌 如何区分 Flow vs Offload vs ARP？

现象	Offload 问题	Flow 过载	ARP GC
ping 丢包	✔ 有可能	✔ 有可能	✔ 经常
curl 慢	✔（大包合并问题）	✔（软中断高）	✔（CACHE MISS）
rx_errors 增长	✔ 多	✖ 少	✖
softirq 飙高	✔（GRO爆）	✔（队列满）	✖
softnet_stat 增长	✖	✔	✖
dmesg 出现 checksum error	✔	✖	✖
dmesg 出现 neighbour overflow	✖	✖	✔
关闭 offload 后改善	✔ 必然	✖ 无效	✖

你只要按这个表看，就能精准判断根因。

---

🟦 最终如何快速判断？

执行这一套：

1. dmesg | egrep "checksum|gro|lro"
2. ethtool -S eno3 | egrep "err|drop"
3. cat /proc/net/softnet_stat
4. top -H -p $(pidof ksoftirqd/*)
5. ip -s neigh
6. dmesg | grep -i neighbor
7. sar -n DEV 1

然后用上面表格对照。

---

📣 如果你愿意，我可以帮你做 自动诊断脚本：

bash diagnose_network.sh

自动：

• 判断是否 Offload 导致

• 是否 Flow 过载

• 是否 ARP GC 溢出

• 是否软中断瓶颈

• 是否 ring buffer 太小

并输出清晰诊断结果。

你需要这个吗？