内核网络栈调优：中断、队列与 offload

先问一句：真的该调内核吗

这一节讲的是旋钮。但先说清什么时候不该动它们：

调内核参数的正确姿势是先有症状、再有假设、一次只改一处、改完看计数器。 照抄一份"优化脚本"是最糟的做法——你不知道它为什么好，也不知道它什么时候变坏。

收包侧：从中断到多核

L0 讲过收包路径：DMA → 硬中断 → NAPI 软中断 → 协议栈。这条路上有三个层次的"分发"：

网卡侧    RSS：硬件按包头哈希，分到多个接收队列       ← 最优，零 CPU 开销
中断侧    IRQ affinity：每个队列的中断绑到不同 CPU
软件侧    RPS/RFS：软件再分发一次（网卡不支持多队列时的补救）

RSS：让网卡自己分

ethtool -l bond0        # 支持几个队列 / 当前用了几个
ethtool -L bond0 combined 16    # 开到 16 个

Combined: 1 是那种"CPU0 打满、其它核闲着"故障的根因（L0 闯关就是这个）。 队列数取值经验：与要参与收包的 CPU 数匹配，不必开到硬件上限—— 开 63 个队列意味着 63 个中断源，反而增加调度开销。

中断亲和性：别让它们挤在一起

# 中断落在哪些 CPU 上
cat /proc/interrupts | grep -i mlx5_comp

# 单个中断的 CPU 掩码
cat /proc/irq/142/smp_affinity_list

驱动一般会自动摊开。手工绑的场合只有一个：NUMA 亲和—— 把网卡的中断绑到和它同 NUMA 的 CPU 上，避免跨 socket 访问内存。

# 网卡属于哪个 NUMA 节点
cat /sys/class/net/bond0/device/numa_node
# 那个节点有哪些 CPU
lscpu | grep NUMA

RPS / RFS：软件补救

网卡只有单队列时，可以在软中断里再做一次软件分发：

# 给 rx-0 队列指定可以分发到哪些 CPU（十六进制掩码）
echo ffff > /sys/class/net/eth0/queues/rx-0/rps_cpus
sysctl -w net.core.rps_sock_flow_entries=32768

队列深度与中断合并

两个最常用的旋钮，作用相反：

ethtool -g bond0        # ring 深度
ethtool -c bond0        # 中断合并参数

判断顺序很明确：

• rx_missed / rx_no_buffer 在涨 → 先加队列数（RSS），再考虑加深 ring
• %soft 高但没丢包 → 加大中断合并
• 要低延迟 → 反向调：rx-usecs 调小甚至关合并，ring 别太深

Offload：把活交给网卡

网卡能替内核干一部分活。用 ethtool -k 看当前状态：

ethtool -k bond0 | grep -E 'tcp-segmentation|generic|large-receive|checksum|scatter'

开 TSO/GSO/GRO 的收益很实在：包数减少一个数量级，CPU 开销随之下降。 这也是为什么 tcpdump 抓到的包会出现远超 MTU 的"巨型包"——那是 GRO 合并后的结果，不是线上真实的帧。

ethtool -K bond0 lro off

发包侧：qdisc 与 XPS

# 当前的排队规则与丢包统计
tc -s qdisc show dev bond0

默认的 fq_codel 对绝大多数场景是好选择——它自带 AQM，能治 bufferbloat（L0 讲过）。 需要动它的场合只有三类：限速、优先级（RoCE 的 DSCP 标记）、纯低延迟（pfifo_fast）。

发送侧也有对应 RSS 的机制，叫 XPS：让某个 CPU 发出的包固定走某个发送队列，避免锁竞争。

echo 0001 > /sys/class/net/eth0/queues/tx-0/xps_cpus

驱动通常自动配好，一般不用手动动。

socket 缓冲区

# 自动调节的三个值：min / default / max
sysctl net.ipv4.tcp_rmem net.ipv4.tcp_wmem
sysctl net.core.rmem_max net.core.wmem_max

默认值对同机房完全够用。 需要调大只有一个理由：BDP 超过了当前 max （L0 算过：跨地域 10 Gbps × 30 ms ≈ 37 MB，远超默认的几 MB）。

# 长肥管道才需要
sysctl -w net.core.rmem_max=67108864
sysctl -w net.ipv4.tcp_rmem="4096 87380 67108864"

调大的代价是每条连接可能占用更多内存，连接数多的机器要算总量。

一份有节制的检查清单

# 1. 多队列开够了吗（最高频的真问题）
ethtool -l bond0 | grep -A4 'Current'

# 2. 中断摊开了吗
cat /proc/interrupts | grep -c mlx5_comp

# 3. 软中断是否集中在单核
mpstat -P ALL 1 3 | awk '$NF!="idle" && $(NF-1)>20'

# 4. 丢包在哪一层
ethtool -S bond0 | grep -iE 'missed|no_buffer|drop'
cat /proc/net/softnet_stat | head -4

# 5. offload 状态是否符合场景（转发机器要确认 LRO 关闭）
ethtool -k bond0 | grep -E 'large-receive|generic-receive'

# 6. 只有跨地域场景才检查缓冲区上限
sysctl net.core.rmem_max

六条里前三条能解决绝大多数"内核侧"性能问题，剩下三条是场景性的。

检查点

这节课的落点

• 先有症状再调参：一次改一处、改完看计数器，别照抄优化脚本
• 收包分发三层：RSS（网卡，最优）→ 中断亲和（NUMA）→ RPS/RFS（补救）
• Combined: 1 是"单核 %soft 打满"的头号原因；队列数与参与收包的 CPU 数匹配即可
• 有 RSS 就别开 RPS，它要多做一次跨 CPU 投递
• ring 加深吸收突发、中断合并降 CPU，两者都以延迟为代价
• GRO 安全、LRO 危险：转发机器必须关 LRO；抓包看到巨型包是 GRO 合并的结果
• 默认 fq_codel 够用，动 qdisc 只为限速、优先级或极低延迟
• socket 缓冲只在 BDP 超限时才调，也就是跨地域长肥管道