Linux怎么查看具体的网卡中断绑定情况

先说个核心判断：排查网卡中断绑定，直接看 /proc/irq/*/smp_affinity_list 就够了，别被 top 或 mpstat 给出的单核高负载表象迷惑——那些工具只告诉你哪个核在忙，却说不清这个核究竟绑定了哪个中断。

怎么快速定位网卡对应的 IRQ 编号

网卡的中断号不是蒙出来的，得从 /proc/interrupts 里捞。操作其实不复杂：

• 先用 nmcli device status 或 ip -br link show 确认当前的真实网卡名，比如 enp1s0f0 或 ens33。
• 接着跑 grep -i "enp1s0f0" /proc/interrupts，把名字换成你自己的。输出大概长这样：
  42: 1234567 0 0 0 890123 0 0 0 IR-PCI-MSI 32768-edge enp1s0f0-rx-0
  第一列的 42 就是 IRQ 编号。如果末尾带 -rx- 或 -tx- 后缀，说明已经启用了多队列，每个后缀对应一个独立的中断。
• 万一 grep 没找到结果，试试用驱动名来搜：先 ethtool -i enp1s0f0 | grep driver 得到驱动名（比如 i40e 或 mlx5_core），再 grep i40e /proc/interrupts。

怎么确认当前 IRQ 绑定到了哪些 CPU

拿到 IRQ 编号后，有两个文件必须同时查，缺一不可：

• cat /proc/irq/42/smp_affinity_list：显示的是你“写进去”的亲和性配置，输出是十进制的 CPU 编号列表。比如 0,2,4,6 表示这个中断允许跑在这 4 个核上；如果只输出 0，那就是硬绑死在 CPU 0——单核瓶颈的直接证据。
• cat /proc/irq/42/effective_affinity：显示内核“实际执行”的绑定情况。如果它和 smp_affinity_list 不一致，十有八九是 irqbalance 在后台偷偷动手脚。
• 顺手检查一下 systemctl is-active irqbalance，如果是 active，操作前务必 sudo systemctl stop irqbalance。

为什么改了 smp_affinity_list 却没生效

这个问题很典型。通常不是权限或路径搞错了，而是下面三个细节被忽略了：

• 目标 CPU 被内核隔离了：运行 cat /proc/cmdline，如果看到 isolcpus=1,2，就别往 CPU 1 或 2 上写绑定了，否则写入会静默失败甚至触发警告。
• 误用了 smp_affinity（十六进制掩码）：x86 是 64 位，ARM 可能更宽，掩码长度错一位就容易全绑到 CPU 0。相比之下，smp_affinity_list 是人眼可读的十进制列表，安全得多。
• 驱动不响应 smp_affinity_list：某些驱动（比如 mlx5_core）只认 smp_affinity，但写之前必须先确认位宽。稳妥的做法是先试 smp_affinity_list，失败再查驱动文档。

网卡没开多队列时，看中断绑定意义不大

如果 ethtool -l enp1s0f0 显示 Combined: 1，说明硬件只开了 1 个接收队列。这种情况下，再怎么调整 smp_affinity_list，也只有一个 IRQ 号可绑，所有网络包最后还是压在同一个中断上下文里。

真正该做的不是调绑定，而是：

• 先启用多队列：sudo ethtool -l enp1s0f0 combined 4（通常设为 CPU 核数一半或匹配 NUMA 节点）。
• 再确认网卡是否支持 RPS：ls /sys/class/net/enp1s0f0/queues/rx-*，看到多个 rx-* 目录才算队列激活。
• 最后才是对每个 rx-0、rx-1 对应的 IRQ 分别绑定到不同的 CPU 上。

中断绑定不是万能开关。它是多队列、NUMA 对齐、以及 irqbalance 停用三者协同的结果。漏掉任意一环，你看到的都只是假象。