/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更贴近实际分发效果，但需内核调试符号支持
col 1 是否为零——只要还有 drop，就说明当前路径存在不可绕过的瓶颈，调别的都只是缓释。 
