Linux /proc/net/softnet_stat 的 softirq 统计与网络中断负载均衡

/proc/net/softnet_stat 每行第0列（从0开始）对应cpu的net_rx softirq触发次数，第1列是因backlog溢出导致的丢包数，二者共同反映软中断负载压力。

怎么看 softnet_stat 里哪一列对应 CPU 的 softirq 负载

直接看 /proc/net/softnet_stat 每行第 0 列（从 0 开始数）——它就是该 CPU 上 NET_RX softirq 的总执行次数。别被后面十几列迷惑，前两列才是关键：col 0 是收包软中断触发次数，col 1 是该 CPU 上因 backlog 溢出导致的丢包数（即 processed 不够快，队列满后丢弃的包）。

常见错误是拿第 2 列或第 9 列当“负载”，其实它们分别是「已处理但延迟过高的包数」和「被 ksoftirqd 接管的次数」，不能直接反映实时负载压力。

• cat /proc/net/softnet_stat 输出每行对应一个 CPU，行号 = CPU 编号
• 用 awk '{print $1}' /proc/net/softnet_stat 可快速汇总所有 CPU 的触发总数
• 如果某 CPU 的 col 1 持续非零，说明它的 NET_RX 处理不过来，不是中断没分摊好，就是该核本身太忙

为什么绑定了 RPS/RFS 还是看到单个 CPU softirq 飙高

RPS（Receive Packet Steering）和 RFS（Receive Flow Steering）只负责把软中断上下文「推」到目标 CPU 的 input_pkt_queue，但最终是否真由那个 CPU 执行，取决于 ksoftirqd/CPU 的唤醒时机和调度延迟。换句话说：RPS 决定“往哪送”，不保证“立刻被谁处理”。

典型现象是：RPS 配置生效了，/proc/net/softnet_stat 里多个 CPU 的 col 0 都在涨，但其中某个 CPU 的 col 1（drop）持续上升，同时 top -H 看到 ksoftirqd/0 占用率远高于其它核。

• 检查 /proc/sys/net/core/rps_sock_flow_entries 是否太小，导致 RFS 流表频繁淘汰，回退到默认 CPU
• 确认 /sys/class/net/eth0/queues/rx-0/rps_cpus 设置的是十六进制掩码，比如 ff 表示前 8 个 CPU 全开，写成 0xff 会失败且无提示
• RPS 不影响硬件中断亲和性（IRQ affinity），如果硬中断全打在 CPU 0，即使 RPS 分发，CPU 0 的 ksoftirqd/0 仍要处理所有软中断初始化工作，容易成为瓶颈

softnet_stat 里 col 9（ksoftirqd 唤醒次数）突然暴涨意味着什么

col 9 是该 CPU 上 ksoftirqd 被显式唤醒的次数，不是 softirq 执行次数。它暴涨通常说明：softirq 处理函数（如 net_rx_action）在一次调用中没能清空本地 backlog，被迫让出 CPU 并唤醒 ksoftirqd 继续干——本质是单次 softirq 循环被 net.core.netdev_budget 限制中断了。

这不是异常，但结合 col 1（drop）一起看就有问题：如果 col 9 高 + col 1 也高，说明预算不够、处理太慢、或者网卡帧太碎（小包多），导致反复唤醒 ksoftirqd 还清不完。

• 调大 net.core.netdev_budget（默认 300）可减少唤醒次数，但可能延长单次 softirq 占用时间，影响调度响应
• 小包场景下，开启 GRO（ethtool -K eth0 gro on）比调 budget 更有效，能合并入站包，降低 softirq 调用频次
• col 9 单独高而 col 1 为 0，大概率只是流量大+budget 保守，属正常现象

用 perf 抓 net_rx_action 样本时为什么看不到预期的 CPU 分布

因为 perf record -e irq:softirq_entry --Filter "vec == 3"（3 是 NET_RX 向量）抓到的是「进入 softirq 处理」的点，而 RPS/RFS 的分发逻辑发生在更早的硬中断下半部（NAPI poll 前），此时 perf 还没开始跟踪。所以你看到的 CPU 分布，其实是 NAPI poll 实际运行的位置，不等于 RPS 目标 CPU。

更糟的是，如果启用了 CONFIG_SOFTIRQ_ON_OWN_STACK（5.10+ 内核默认），net_rx_action 可能在任意 CPU 的 softirq stack 上运行，跟初始分发 CPU 完全脱钩。

• 想验证 RPS 是否生效，别依赖 perf 跟函数，直接对比 /proc/net/softnet_stat 各 CPU 的 col 0 增速差异
• 用 watch -n1 'cat /proc/interrupts | grep eth0' 确认硬中断是否真的分散了；RPS 再好，硬中断全挤在 CPU 0，软中断负载还是难均衡
• perf 抓 netif_receive_skb_core 或 __napi_poll 更贴近实际分发效果，但需内核调试符号支持

真实负载均衡的关键不在参数调多花哨，而在硬中断分布、budget 与包长的匹配、以及 col 1 是否为零——只要还有 drop，就说明当前路径存在不可绕过的瓶颈，调别的都只是缓释。