最准方法是查看/sys/class/net/eth0/queues/下rx-/tx-目录数量：仅rx-0和tx-0为单队列；存在rx-0、rx-1、tx-0、tx-1等即为多队列；ls /sys/class/net/eth0/queues/ | grep -E '^rx-|^tx-' | wc -l输出大于2表明已启用多队列。
怎么确认网卡当前是单队列还是多队列
直接看 /sys/class/net/ 下有没有多个 rx-* 和 tx-* 目录是最准的。单队列只会存在 rx-0 和 tx-0；多队列则有 rx-0、rx-1、rx-2 等。
执行这条命令就能快速判断：
ls /sys/class/net/eth0/queues/ | grep -E '^rx-|^tx-' | wc -l
输出大于 2（即至少含 rx-0 + tx-0），说明已启用多队列。若只输出 2，但你预期是多队列，那大概率是硬件 RSS 没开或驱动未加载多队列支持。
-
ethtool -l eth0查看「Combined」最大值和当前值：若最大值 >1 但当前为 1，说明硬件支持但未启用 -
cat /proc/interrupts | grep eth0看中断行数 —— 每个rx-*队列通常对应一个独立中断号（如eth0-rx-0、eth0-rx-1） - 虚拟机中常被降级为单队列，即使宿主机开了 RSS，也要检查 virtio-net 或 vhost 配置是否启用 multi-queue
如何验证 RSS 是否真正生效并均匀分流
RSS 是硬件行为，但容易“看起来开了，实际没分”。关键要看流量是否真的散列到不同队列，而不是全挤在 rx-0。
先用 ethtool -S eth0 提取各队列收包计数：
ethtool -S eth0 | grep rx_packets_
输出类似 rx_packets_0: 124891、rx_packets_1: 92304……如果只有 _0 有数字，其余全为 0，说明 RSS 没起作用。
Zynq‑7000 / Zynq UltraScale+ 硬件调试技能。适用于 Xilinx Zynq（Cortex‑A9/A53 + FPGA）Linux 环境，调试 I2C、I2S、UART、GPIO 等外设。包括设备树配置、内核驱动、用户空间调试工具、交叉编译和常见问题排查，支持 PetaLinux 开发。
- 检查哈希键：
ethtool -x eth0查看当前 RSS hash key，空或过短（如全 0）会导致哈希退化，所有流映射到同一队列 - 重设哈希键（需 root）：
ethtool -X eth0 hkey <32-byte-hex-string>，推荐用内核默认生成的 key（见/sys/class/net/eth0/device/rx_hash_key） - 某些网卡需显式启用四元组哈希：
ethtool -N eth0 rxflow-hash tcp4 sdfn（s=src,d=dst,f=flags,n=next-layer-protocol） - 注意：部分老驱动（如 e1000e）默认禁用 RSS，需加内核参数
options e1000e RSS=1并 reload 模块
为什么 RPS 设置了却没效果
RPS 不是开关一按就灵，它依赖两个前提：软中断必须能调度、且目标 CPU 不能被绑死或离线。
常见失效原因：
-
/sys/class/net/eth0/queues/rx-0/rps_cpus写入的掩码位数超过当前在线 CPU 数（比如写f却只有 2 个 CPU 在线），内核会静默忽略 - 系统启用了
irqbalance，它可能动态迁移中断，导致 RPS 的 CPU 映射与实际中断处理 CPU 错位 —— 建议停掉：systemctl stop irqbalance - RPS 只在没有硬件 RSS 或队列数不足时才真正介入；如果 RSS 已把包分到 8 个队列，RPS 就基本不干活了
- 检查
/proc/sys/net/core/rps_sock_flow_entries是否太小：低于cpu_count * 4096会导致流表频繁驱逐，RFS 失效进而拖累 RPS 效果
验证 RPS 是否触发：跑压力时用 perf record -e skb:consume_skb -a sleep 5，然后 perf script | awk '{print $3}' | sort | uniq -c | sort -nr，看软中断是否出现在你指定的多个 CPU 上。
RFS 配置后反而延迟升高？这几个点必须核对
RFS 的目标是让同一流回到上次处理它的 CPU，但它会引入额外查表和重定向开销。如果配置不当，延迟反而上升。
-
/sys/class/net/eth0/queues/rx-0/rps_flow_cnt必须 ≥ 实际并发流数 × 1.2；设太小（如 256）在万级连接场景下会高频冲突，查表退化为线性扫描 -
/proc/sys/net/core/netdev_rfs_threshold控制 RFS 触发阈值，默认 32 —— 意味着只有该队列每秒收包超 32 个才启用 RFS；高吞吐场景建议调大到 256 或 1024 - RFS 依赖进程绑定：若你的服务进程用
taskset -c 0-3 ./server绑定了 CPU，但 RPS 把包分到了 CPU 4–7，RFS 就无法匹配“上次处理该流的 CPU”，直接 fallback 到普通 RPS 路径 - NUMA 节点跨访代价高：确保 RFS 流表容量（
rps_flow_cnt）和 RPS CPU 掩码都限定在同一个 NUMA node 内，避免远端内存访问
最易被忽略的一点：RFS 只对 TCP socket 生效，UDP 流量完全不走这套逻辑 —— 如果你压测的是 UDP，调 RFS 没任何意义。
