net_rx单核飙升且远超其他cpu是网卡收包路径堵塞的明确信号，需结合硬中断分布、多队列支持、rps配置等综合排查。
直接看 /proc/softirqs，重点关注 NET_RX 列——它就是网卡软中断的核心指标，数值飙升且集中在单个 CPU，基本等于网卡收包路径已堵死。
怎么看 /proc/softirqs 里网卡软中断是否异常
执行 cat /proc/softirqs 后，别扫全表，只盯三行末尾数字：
-
NET_RX：每列数字代表该 CPU 处理的网络接收软中断次数。若某列（如 CPU0）是其他列的 5–10 倍（例如 820 万 vs 其他核 20–50 万），说明软中断没摊开，NET_RX就是瓶颈源头 -
TIMER：若它同步暴涨，大概率是NET_RX处理太慢，导致内核定时器回调积压，掩盖了真实问题 -
SCHED：异常升高往往伴随NET_RX高峰，说明调度器被软中断反复抢占，业务线程得不到 CPU
注意：/proc/softirqs 是累计值，要判断是否“正在发生”，得用 watch -n 1 'grep NET_RX /proc/softirqs' 看秒级增长速率。单次差值超 5 万/秒就值得介入。
为什么 NET_RX 高 ≠ 网卡真忙，而可能是硬中断绑定失当
软中断本身不产生，它只是硬中断的“下游搬运工”。NET_RX 单核飙高，90% 情况是硬中断全打在同一个 CPU 上，软中断只能跟着跑。验证步骤如下：
- 查网卡硬中断分布：
grep eth0 /proc/interrupts（把eth0换成你的接口名），观察各 CPU 列数值是否严重倾斜 - 确认网卡是否支持多队列：
ls /sys/class/net/eth0/device/msi_irqs/ 2>/dev/null | wc -l，输出数应 ≥ 物理 CPU 核数；若为 0 或 1，说明是单队列网卡或驱动未启用 MSI-X - 检查 RPS 是否开启：
cat /proc/sys/net/core/rps_cpu_mask，为空或全 0 表示关闭，软中断无法跨核迁移
常见错误：以为调大 net.core.netdev_budget（默认 300）就能缓解，其实只是让单次软中断处理更多包，反而延长了抢占时间，加剧抖动。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
如何快速定位是哪个网卡设备在刷 NET_RX
/proc/softirqs 不带设备名，需结合硬中断映射反推：
- 先找出网卡对应的所有 IRQ 编号：
grep -E "eth|enp|ens" /proc/interrupts | awk '{print $1}' | tr -d ':' - 对每个 IRQ 号，查其软中断归属：
grep NET_RX /proc/softirqs输出行号与 IRQ 编号无直接对应，但可交叉比对——若/proc/interrupts中 IRQ 42、43、44 全属eth0，而/proc/softirqs的NET_RX行各列增长主力又和这三行硬中断分布高度一致，即可锁定 - 更准的方法是用
perf抓堆栈：perf record -e irq:softirq_entry --filter "vec == 3" -C 0 -g -- sleep 5（vec == 3是NET_RX的内核编号），然后perf report | grep net_rx_action，看调用来源是否集中于某接口
别依赖 top 的 %si：它只是所有软中断的加总占比，NET_RX 占 95% 还是 5%，%si 数值可能完全一样。
调整后怎么确认 NET_RX 真正摊开了
改完 RPS 掩码、RPS 队列或硬中断 affinity 后，不能只看平均值下降，要验证分布质量：
- 运行
watch -n 1 'grep NET_RX /proc/softirqs'，等 30 秒，记录每列增量，计算标准差 / 均值比值；比值 - 同时跑
cat /proc/interrupts | grep eth0，确保硬中断分布也同步改善，否则软中断摊开只是“假动作” - 如果业务延迟敏感，还要补测：
perf record -e 'syscalls:sys_enter_nanosleep' -C 0 -- sleep 10，看nanosleep被__do_softirq打断的频率是否明显下降
最易被忽略的一点：虚拟化环境中，/proc/softirqs 显示的 NET_RX 可能来自 virtio-net 前端，此时真正瓶颈在 QEMU 线程或 vhost 内核线程，得去宿主机查对应 tap/veth 设备的中断，而非 guest 里的 eth0。
