内核驱动性能数据的解读在将一款千兆/万兆 PCIe 网卡驱动移植到新的 ARM64 BSP 平台后测试组发来报告在 10Gbps 网卡上运行 iperf3 测试双向吞吐量卡死在 2.1Gbps再也打不上去了。研发团队最初怀疑是硬件 PHY 芯片信号衰减或 PCIe Gen3 x2 的 Lane 带宽不足甚至准备修改 PCB 走线。但深入内核排查后发现硬件物理带宽完全正常真正的瓶颈出在 BSP 默认的中断分配策略上——网卡所有的 RX 硬件中断都被毫无保留地压在了 CPU0 一个核心上导致 CPU0 的NET_RX软中断softirq利用率达到了 100%而其余 7 个 CPU 核心却在完全打瞌睡。在 Linux 内核驱动开发与 BSP 移植过程中看懂性能数据不能只盯着 iperf3 或 fio 输出的最后那个吞吐量数字必须深入内核底层将 CPU 中断亲和性、NUMA 节点与 RX/TX Ring Buffer 调度指标结合起来交叉解读。1. 单核软中断饱和与网卡丢包现象运行iperf3 -c 192.168.1.100 -P 8进行多线程压力测试时网卡的接收吞吐量极其低迷。首先使用 Linux 性能观测工具mpstat观察各 CPU 核心的负载分布mpstat -P ALL 1输出展现了极度的不均衡02:15:10 PM CPU %usr %sys %iowait %irq %soft %idle 02:15:11 PM all 2.10 4.50 0.00 1.20 11.80 80.40 02:15:11 PM 0 0.00 12.00 0.00 8.00 80.00 0.00 # CPU0 软中断 (%soft) 直接爆表 02:15:11 PM 1 1.00 2.00 0.00 0.00 0.00 97.00 02:15:11 PM 2 0.00 1.00 0.00 0.00 0.00 99.00 ...进一步检查ethtool统计数据与物理中断分布ethtool -S eth0 | grep -E rx_dropped|rx_fifo_errors|rx_no_buffer捕获到大量的内核空间丢包rx_dropped: 1482910 rx_fifo_errors: 0 rx_no_buffer_count: 84210 # 网卡 Ring Buffer 已经被塞满NAPI 来不及消费rx_fifo_errors为 0 说明硬件 PHY 没丢包而rx_no_buffer_count高涨说明 CPU0 上的 NAPI 轮询线程来不及处理接收到的 skb 报文硬件 Ring Buffer 被直接撑爆。2. Linux 内核网络驱动中断与 NAPI 轮询数据流要彻底解决单核瓶颈必须理解 Linux 内核从硬件中断到 NAPI 软中断的响应链路。如果驱动只注册了一个单硬件接收队列或者未配置smp_affinity所有流量都会收拢到单核。多队列网卡必须搭配 RSSReceive Side Scaling与中断亲和性绑定才能释放全核处理能力。3. 中断亲和性绑定与多队列调度脚本在 BSP 移植后必须通过自动化脚本动态绑定网卡的 MSI-X 中断向量到不同的 CPU 核心。以下是驱动基准测试前必须执行的 Bash 优化脚本#!/bin/bash # autoirq_balance.sh - 动态绑定网卡中断至多核 CPU INTERFACEeth0 # 1. 禁用系统默认的 irqbalance 服务防止其破坏手动绑定 systemctl stop irqbalance 2/dev/null # 2. 获取该网卡对应的所有 MSI-X 中断号 IRQS$(grep ${INTERFACE} /proc/interrupts | awk -F: {print $1} | tr -d ) if [ -z $IRQS ]; then echo [ERROR] No interrupts found for interface ${INTERFACE} exit 1 fi CPU_ID0 MAX_CPUS$(nproc) echo Setting IRQ affinity for ${INTERFACE}... for IRQ in $IRQS; do # 计算 CPU 掩码 (Bitmask) # CPU0 - 0x1, CPU1 - 0x2, CPU2 - 0x4, CPU3 - 0x8 MASK$(printf %x $((1 CPU_ID))) # 将掩码写入 Linux 内核中断亲和性节点 if [ -f /proc/irq/${IRQ}/smp_affinity ]; then echo ${MASK} /proc/irq/${IRQ}/smp_affinity echo Bound IRQ ${IRQ} to CPU${CPU_ID} (Mask: 0x${MASK}) fi # 轮询递增 CPU 核心 ID CPU_ID$(( (CPU_ID 1) % MAX_CPUS )) done # 3. 增大内核 Socket 接收缓冲区与 NAPI 轮询预算 sysctl -w net.core.netdev_max_backlog10000 sysctl -w net.core.dev_weight64脚本执行后再次查看/proc/interrupts原本堆积在 CPU0 的中断会被均匀分摊到 CPU0~CPU7 上。4. 使用 Perf 定位驱动内部函数耗时在消除单核中断瓶颈后如果吞吐量仍未达标需要使用 Linux 内核级perf工具定位驱动 C 语言代码中的 CPU 耗时大户。在测试持续运行期间抓取内核空间采样perf record -a -g -e cycles -- sleep 10 perf report --stdio --dsosmy_net_driver导出的 Symbol 耗时报告# Overhead Command Shared Object Symbol # ........ ............... ................ ..................................... 42.15% ksoftirqd/2 my_net_driver.ko [k] my_driver_alloc_rx_skb 28.10% ksoftirqd/2 my_net_driver.ko [k] my_driver_clean_rx_ring 12.40% ksoftirqd/2 [kernel.kallsyms] [k] dev_gro_receive报告暴露出驱动内部my_driver_alloc_rx_skb占用了高达 42% 的 CPU 周期。查看驱动源码发现开发人员在每次 NAPI 轮询回收报文时都在使用netdev_alloc_skb()动态分配新的 Socket Buffer。优化手段修改驱动代码引入 SKB Page Pool 机制内核net_page_poolAPI复用预先分配好的 DMA Page 物理页避免每次收包都经历昂贵的内存分配与 TLB Flush 过程。5. BSP 驱动基准测试数据解读 Checklist在为 BSP 移植项目出具最终的驱动性能测试报告前必须逐项核对以下指标口径区分 Line Rate 与 Payload Throughputiperf3 测出的是 TCP/UDP 应用层 Payload 吞吐率。必须加上 14 字节以太网头、20 字节 IP 头与 20 字节 TCP 头以及 12 字节 Interpacket Gap换算出真实的 L1 物理链路速率。确认 GRO/LRO 卸载状态通过ethtool -k eth0检查generic-receive-offload(GRO) 是否开启。GRO 开启时内核会将多个小 TCP 包合并为 64KB 大包处理大幅降低 CPU 开销。测试时必须明确标注该状态。核查 PCIe TLP Payload 尺寸使用lspci -vvv -s pci_address查看DevCtl中的MaxPayload与MaxReadReq。如果 BSP 板卡默认将 MaxPayload 设为 128 字节而非 256/512 字节PCIe 总线头开销会导致实际吞吐下降 15% 以上。绑定 NUMA 本地内存节点对于多 Socket 的 ARM64 服务器级 BSP必须将 PCIe 网卡所在 PCIe Controller 的 NUMA Node与 iperf3 绑定的 CPU 核心控制在同一个 NUMA Domain 内严禁跨 NUMA 节点访问 DRAM。读懂性能指标背后的内核机制BSP 移植测试才不会走弯路。
