Linux网卡中断绑定查看方法

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

如何快速定位网卡对应的 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 停用三者协同的结果。缺少任意一环，你所看到的都只是假象。