nmcli无法查看万兆网卡硬件中断分配，需结合/proc/interrupts定位irq编号、cpu分布及smp_affinity_list亲和性设置交叉验证，并辅以/proc/softirqs和trace-cmd分析软中断与单次handler耗时。
直接看 /proc/interrupts 就能拿到原始中断分配详情，但光扫一眼数字没用——得结合设备名、CPU列分布、亲和性设置三者交叉验证，否则容易把 NAPI 轮询误判成“中断消失”，或把 irqbalance 自动调整当成“配置失效”。
查网卡对应 IRQ 编号和触发分布
先定位你要分析的万兆网卡（比如 enp5s0f0 或 mlx5_0），再找它实际占用的 IRQ 行：
-
grep -i "enp5s0f0\|mlx5_0" /proc/interrupts—— 输出类似128: 1245678 902345 0 0 PCI-MSI 1245296-edge enp5s0f0，说明 IRQ 128 是该网卡主中断 - 注意最后一列是否含
PCI-MSI、IR-PCI-MSI或IO-APIC：前者多见于现代万兆卡，后者常见于老设备；虚拟化里看到IR-前缀，说明 IRQ 编号已与物理引脚解耦，不能按编号猜硬件 - 数值为 0 不代表没工作：如果执行过
ethtool -C enp5s0f0 rx off，中断计数归零但流量照常，此时真正在干活的是软中断（NET_RX）
确认中断绑定到哪些 CPU 核心
别碰 smp_affinity（十六进制掩码），优先读 smp_affinity_list——它输出十进制 CPU 编号，人眼可读且跨架构安全：
-
cat /proc/irq/128/smp_affinity_list→ 输出0,1表示只绑在 CPU0 和 CPU1 上 - 如果输出为空或报
No such file，说明该 IRQ 由固件锁定（如某些 BMC 或 RAID 卡），不可手动调整 - 对比
/proc/irq/128/effective_affinity：若它和smp_affinity_list不一致，八成是irqbalance在后台覆盖你的设置，此时需sudo systemctl stop irqbalance - NUMA 架构下，优先绑定到与网卡直连的 CPU 节点：用
lspci -vv -s $(ethtool -i enp5s0f0 | grep bus-info | awk '{print $2}') | grep NUMA查节点号，再选同节点 CPU
区分硬中断和软中断的负载归属
/proc/interrupts 只统计硬件 IRQ 触发次数，而真正吃 CPU 的往往是下半部处理——这得看 /proc/softirqs：
-
cat /proc/softirqs | grep NET_RX→ 如果 CPU0 的值是 CPU1–CPU3 总和的 5 倍以上，说明网络包全压在单核上，ksoftirqd/0 忙死，其他核闲着 -
watch -n 1 'cat /proc/softirqs | grep NET_RX'配合mpstat -P ALL 1，若某核%soft持续 >20%，且NET_RX列同步飙升，就是软中断瓶颈，不是硬件中断太多 -
ethtool -S enp5s0f0 | grep -E "(rx_packets|rx_interrupts)"：若rx_interrupts远大于rx_packets（比如 10:1），说明 NAPI 没生效，网卡在“包包中断”，得调 RSS 队列数或关 GRO
抓单次中断 handler 耗时而非只看总数
/proc/interrupts 和 /proc/softirqs 都只给总量，卡顿或抖动必须看单次 handler 从入口到出口的真实耗时：
- 先确认内核支持：
grep CONFIG_IRQSOFF_TRACER /boot/config-$(uname -r)返回y或m才能用 - 抓 5 秒：
trace-cmd record -e irq:irq_handler_entry -e irq:irq_handler_exit -T 5 - 分析时盯
delta字段（单位纳秒），超过100μs就该怀疑驱动在中断上下文里干了重活（比如 memcpy 大块数据） - 别用
perf record -e irq:*：它不保证入口/出口事件配对，算不出真实 delta，精度也不够
最易被忽略的点是：中断计数暴涨但无对应进程运行，大概率不是负载高，而是硬件异常（网卡丢包重试、PCIe 设备误报）或驱动 bug；而计数为 0 却业务正常，大概率是启用了 NAPI 或轮询模式——这两类反直觉现象，必须靠 /proc/softirqs 和 trace-cmd 交叉验证才能看清。
