nmcli不提供中断监控能力，仅用于网络连接管理；排查多队列网卡单核中断瓶颈需先用nmcli确认网卡状态与驱动，再结合/proc/interrupts、ethtool、irqtop及sysfs等工具诊断中断分布与RSS/RPS配置。
nmcli 本身不提供中断分布监控能力，它专注网络连接管理（如启停接口、配置IP、绑定bond等），无法读取 /proc/interrupts 或设置 IRQ affinity。排查多队列网卡的单核中断瓶颈，需结合 nmcli 确认网卡状态与队列配置，再用底层工具观测中断行为。
先用 nmcli 确认网卡是否启用多队列
多队列是中断分散的前提。若 nmcli 显示网卡未激活或驱动未加载，后续中断优化无从谈起：
- 运行 nmcli device status 查看目标网卡（如 ens33）是否为 connected 状态
- 执行 nmcli device show ens33 | grep -i driver 确认驱动类型（如 i40e、ixgbe、mlx5_core —— 这些支持多队列；virtio_net 则需额外启用）
- 若需查看队列数，nmcli 不直接暴露该信息，但可配合：
ethtool -l ens33（查当前 RX/TX 队列数量）
ethtool -L ens33 rx 8 tx 8（如需启用 8 队列，需驱动支持且未被禁用）
用 /proc/interrupts + watch 快速定位中断倾斜
这是最直接判断“是否单核瓶颈”的方式。nmcli 不参与此步，但你可在同一终端中快速切换：
Zynq Linux Hardware Debug
下载
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 先查网卡对应中断号：cat /proc/interrupts | grep ens33（替换为实际名），记录开头数字（如 47、48、49…）
- 动态观察增长是否集中：watch -n1 'cat /proc/interrupts | grep ens33'
重点看 CPU0 列数值是否远高于其他列（例如 CPU0: 125K，CPU1: 800，CPU2: 650…） - 若所有中断号都只在 CPU0 上计数飙升，说明多队列虽存在，但中断未分散 —— 这正是单核软中断（si）过高的根源
配合 irqtop 提升多核中断可视化效率
当 CPU 核数 ≥ 32 时，/proc/interrupts 原生输出难以阅读。irqtop 是专为此设计的实时中断监控工具：
- 安装（常见于 EPEL 或源码编译）：sudo dnf install irqtop（Rocky/AlmaLinux）或从 GitHub 构建
- 运行 sudo irqtop，界面按中断频率实时排序，右侧明确标注每个 IRQ 绑定的 CPU 列表（如 “CPU(s): 1,3,5”）
- 重点关注 “Device” 列含网卡名（如 “eth0-rx-0”、“ens33-TxRx-4”）的行 —— 若它们全显示 “CPU(s): 0”，即确认未做亲和性绑定
验证 RSS 与 RPS 是否协同生效
仅开多队列 + 设 IRQ affinity 还不够。RSS（硬件哈希分发）决定数据包进哪个 RX 队列，RPS（软件模拟 RSS）在无硬件多队列时兜底。检查是否启用：
- RSS 检查：ethtool -x ens33 查看接收哈希表是否非空（Empty 表示未启用）
- RPS 检查：cat /sys/class/net/ens33/queues/rx-0/rps_cpus（对每个 rx-N 队列）
输出如 “0000000f” 表示允许 CPU0–3 处理该队列软中断；若全为 0，则 RPS 关闭，即使 IRQ 分散，softirq 仍可能回退到单核 - 建议开启 RPS（尤其虚拟化环境）：echo f > /sys/class/net/ens33/queues/rx-0/rps_cpus（按需扩展掩码）
不复杂但容易忽略：nmcli 是网络“开关”和“配线员”，而中断分布是“交通流控”，得靠 /proc/interrupts、irqtop、ethtool 和 sysfs 协同诊断。定位到单核瓶颈后，再用 echo 写 smp_affinity_list 才真正解决问题。
