4、NAPI与新式中断处理：传统中断与轮询的缺陷、NAPI机制原理、poll回调实现、软中断与硬中断协同、多队列网卡（RSS/RPS）基础

在Linux网络子系统的演进历程中，中断处理模型经历了从“纯中断驱动”到“中断+内核线程”，再到“NAPI（New API）”的深刻变革。早期网卡驱动依赖传统中断机制，每当数据包到达便触发一次硬件中断，CPU被迫频繁切换上下文去处理高频率、小粒度的I/O事件。随着网络带宽从百兆提升到万兆乃至更高，传统中断模式在高PPS（每秒数据包数）场景下暴露出严重的性能瓶颈——中断风暴导致CPU空转、缓存抖动和吞吐量骤降。本章将深入剖析传统中断与轮询的固有缺陷，系统讲解NAPI机制的设计哲学、poll回调的实现要点、软中断与硬中断的协同分工，并延伸至多队列网卡（RSS/RPS）的基础原理，帮助读者建立从硬件中断到协议栈收包路径的完整认知。

4.1 传统中断与轮询的缺陷

4.1.1 核心原理：中断开销与轮询延迟的矛盾

传统网卡驱动采用“每包中断”模式：网卡每接收一个数据帧，就通过PCIe总线向CPU发送一个中断请求。CPU收到中断后，保存当前执行上下文，跳转到中断处理程序（ISR），将数据从网卡FIFO拷贝到内核缓冲区，然后恢复上下文继续执行。这种模式在低速率网络（如10/100Mbps）下表现良好，因为中断频率低，CPU有充足时间处理其他任务。然而，当网络速率提升到1Gbps甚至10Gbps时，数据包到达间隔缩短至微秒甚至纳秒级，中断频率急剧上升。每次中断的固定开销（上下文切换、缓存失效、中断控制器仲裁）成为主要瓶颈。实测表明，在1Gbps线速下，64字节小包每秒可达148万PPS，若每包触发一次中断，CPU将几乎完全陷入中断处理，无法执行用户态应用。

轮询（Polling）模式则相反：驱动定期检查网卡接收描述符环，批量收集数据包。轮询消除了中断开销，但引入了新的问题——CPU必须持续占用一个核心进行忙等，即使网络空闲时也在空转，浪费CPU资源。此外，轮询延迟取决于轮询间隔，间隔过短则浪费CPU，间隔过长则增加网络延迟。传统驱动在“中断”和“轮询”之间二选一，无法根据网络负载动态调整，导致低负载时中断频繁、高负载时轮询浪费。

4.1.2 判断方法：识别中断风暴与CPU瓶颈

在实际运维中，可通过以下指标判断系统是否遭受中断风暴：

• /proc/interrupts：查看网卡中断号对应的CPU计数，若某个CPU的中断计数每秒增长超过10万次，则存在中断风暴风险。
• mpstat -I CPU：观察%irq和%soft指标，若%irq持续超过30%，说明硬中断处理已占用大量CPU。
• perf top：若热点函数集中在handle_irq、__do_softirq或网卡驱动ISR中，则中断处理成为瓶颈。

传统轮询模式的缺陷则表现为：CPU空转率（%idle）低但网络吞吐未提升，且延迟抖动明显。通过sar -n DEV 1观察rxpck/s与CPU利用率的关系，若PPS很高但CPU利用率已饱和，且吞吐量未达线速，则需考虑切换至NAPI。

4.1.3 案例拆解：百兆升级千兆后的性能崩塌

某金融交易系统将网卡从百兆升级至千兆后，业务反馈交易延迟从2ms飙升至50ms。通过cat /proc/interrupts发现eth0中断集中在CPU0，每秒中断次数高达28万次。CPU0的%irq占用达到65%，而其他CPU空闲。进一步使用perf record -g采样，发现热点集中在e1000_intr和net_rx_action。根因是驱动仍使用传统每包中断模式，且未启用NAPI。解决方案：升级驱动至支持NAPI的版本，并设置ethtool -L eth0 combined 4启用多队列，同时配置RPS将软中断分散到多个CPU。优化后，CPU0中断降至4万次/秒，延迟恢复至3ms以内。

4.1.4 常见误区与总结

4.2 NAPI机制原理

4.2.1 核心原理：中断与轮询的融合

NAPI的核心思想是“中断唤醒，轮询收包”。其工作流程分为两个阶段：

1. 中断触发阶段：网卡收到第一个数据包时，仍触发硬件中断。驱动ISR中不直接处理数据，而是将网卡的NAPI状态设置为“已调度”，并挂载到当前CPU的软中断队列，然后关闭网卡中断（或屏蔽RX中断）。
2. 轮询收包阶段：软中断（NET_RX_SOFTIRQ）被唤醒后，调用驱动注册的poll回调函数。该回调以“预算”（budget）为上限，批量从网卡接收描述符环中取出数据包，送入协议栈。当预算耗尽或网卡无包时，重新开启中断，等待下一轮触发。

这种设计使得网络负载低时，中断频率低，延迟小；网络负载高时，中断被关闭，驱动以轮询方式批量收包，避免了中断风暴。NAPI的关键参数包括：budget（每次poll最多处理的包数，默认300）、weight（驱动每次poll的配额，通常与队列数相关）。

4.2.2 操作流程：从ISR到poll回调的完整路径

// 驱动ISR（简化示例）
static irqreturn_t ixgbe_msix_clean(int irq, void *data) {
    struct ixgbe_q_vector *q_vector = data;
    if (!napi_schedule_prep(&q_vector->napi))
        return IRQ_HANDLED;
    // 关闭该队列的硬件中断
    ixgbe_irq_disable(q_vector);
    // 调度NAPI软中断
    __napi_schedule(&q_vector->napi);
    return IRQ_HANDLED;
}

// poll回调（简化示例）
static int ixgbe_poll(struct napi_struct *napi, int budget) {
    struct ixgbe_q_vector *q_vector = container_of(napi, struct ixgbe_q_vector, napi);
    int work_done = 0;
    // 从RX环形队列批量收包
    work_done = ixgbe_clean_rx_ring(q_vector, budget);
    if (work_done < budget) {
        // 收包完毕，重新开启中断
        napi_complete_done(napi, work_done);
        ixgbe_irq_enable(q_vector);
    }
    return work_done;
}

驱动注册NAPI的初始化代码通常位于probe函数中：netif_napi_add(netdev, &q_vector->napi, ixgbe_poll, 64);。其中64为weight，表示每次poll最多处理64个包。若网卡支持多队列，每个队列对应一个NAPI实例，可并行处理。

4.2.3 案例拆解：NAPI参数调优实战

某CDN节点使用Intel X710网卡，业务为大量小文件传输，PPS高达80万。默认配置下，CPU软中断（%soft）达到40%，吞吐量仅达到线速的60%。通过ethtool -l eth0确认已启用4个队列，但每个队列的NAPI weight为默认64。调整策略：

• 将weight提升至128，增加每次poll的收包量，减少poll调用次数。
• 设置budget为600（通过/proc/sys/net/core/busy_poll或驱动模块参数），允许单次软中断处理更多包。
• 启用busy_poll功能（sysctl -w net.core.busy_poll=50），在用户态socket读取时主动轮询，减少延迟。

调整后，%soft降至25%，吞吐量提升至线速的85%。注意，weight过大会导致单次poll占用CPU时间过长，影响其他任务，需根据实际负载平衡。

4.2.4 常见误区与总结

4.3 软中断与硬中断协同

4.3.1 核心原理：分工与优先级

Linux网络收包路径中，硬中断（Hard IRQ）负责快速响应硬件事件，完成最小必要工作（如调度NAPI），然后立即返回。软中断（Soft IRQ）在硬中断返回后，由内核在安全上下文（如do_softirq）中执行，处理实际的数据包接收、协议栈解析等耗时操作。这种分工保证了硬中断的实时性，同时避免在中断上下文执行复杂逻辑导致系统不稳定。

软中断的优先级低于硬中断但高于用户态进程。当软中断被触发时，内核会在当前CPU上执行net_rx_action，该函数遍历所有挂起的NAPI实例，调用其poll回调。软中断的执行时机包括：硬中断返回路径、ksoftirqd内核线程（当软中断过多时）、以及显式调用local_bh_enable时。

4.3.2 判断方法：观察软中断分布与CPU亲和性

使用cat /proc/softirqs查看NET_RX软中断在各CPU上的计数。若计数集中在单个CPU，说明存在软中断不均衡问题。此时可配置RPS（Receive Packet Steering）或调整中断亲和性（irqbalance或手动设置/proc/irq/<irq_num>/smp_affinity）。

硬中断与软中断的协同还涉及“中断线程化”选项（threaded IRQ），将硬中断处理转换为内核线程，降低实时性要求，但增加调度延迟。对于网络驱动，通常不建议启用线程化，因为NAPI已提供足够的异步处理能力。

4.3.3 案例拆解：多队列下的软中断均衡

某云主机使用virtio-net驱动，8个vCPU，但/proc/softirqs显示NET_RX软中断全部集中在CPU0。原因是virtio-net默认只使用一个队列，且未启用RPS。解决方案：

1. 启用多队列：ethtool -L eth0 combined 4（需宿主机支持）。
2. 配置RPS：将/sys/class/net/eth0/queues/rx-0/rps_cpus设置为ff（允许所有CPU处理）。
3. 调整RFS（Receive Flow Steering）以保持流亲和性：echo 32768 > /proc/sys/net/core/rps_sock_flow_entries。

优化后，软中断分散到4个CPU，PPS提升2.3倍，延迟降低40%。

4.3.4 常见误区与总结

4.4 多队列网卡（RSS/RPS）基础

4.4.1 核心原理：硬件分发与软件分发

RSS（Receive Side Scaling）是网卡硬件特性，通过哈希计算（如Toeplitz哈希）将数据包的五元组（源/目的IP、端口、协议）映射到不同的RX队列。每个RX队列绑定到独立的CPU中断，从而实现多CPU并行收包。RSS的关键参数包括：哈希密钥（ethtool -x eth0查看）、哈希字段（ethtool -n eth0配置）、间接表（Indirection Table，决定哈希值到队列的映射）。

RPS（Receive Packet Steering）是软件层面的补充，当网卡不支持多队列或队列数少于CPU数时，RPS在软中断阶段将数据包分发到其他CPU的接收队列。RPS使用相同的哈希逻辑，但通过IPI（处理器间中断）将包转发到目标CPU。RFS（Receive Flow Steering）进一步考虑应用所在CPU，确保同一流的数据包由同一CPU处理，提升缓存命中率。

4.4.2 操作流程：配置RSS与RPS

# 查看当前队列数
ethtool -l eth0
# 设置队列数（需驱动支持）
ethtool -L eth0 combined 4
# 查看RSS哈希配置
ethtool -x eth0
# 设置RSS哈希密钥（可选）
ethtool -X eth0 hkey 01:23:45:67:89:ab:cd:ef:...
# 启用RPS（将rx-0队列的CPU掩码设为0-3号CPU）
echo f > /sys/class/net/eth0/queues/rx-0/rps_cpus
# 启用RFS
echo 32768 > /proc/sys/net/core/rps_sock_flow_entries

配置RSS时需注意：队列数不应超过CPU核心数，否则中断处理可能竞争同一CPU。RPS的CPU掩码应排除处理硬中断的CPU，避免重复负载。

4.4.3 案例拆解：RSS+RPS组合优化Web服务器

某Web服务器使用Intel I350网卡（支持4队列），CPU为8核。初始配置仅启用2个队列，且未配置RPS。压测显示PPS为30万时CPU0软中断饱和。优化步骤：

• 启用4个队列：ethtool -L eth0 combined 4。
• 将4个队列的中断分别绑定到CPU0-3（通过set_irq_affinity脚本）。
• 配置RPS：将rx-0到rx-3的rps_cpus均设为f0（允许CPU4-7处理软中断）。
• 启用RFS以保持流亲和性。

优化后，PPS提升至80万，CPU利用率均衡在60%左右，延迟P99从15ms降至4ms。注意，RPS的IPI开销在高PPS时不可忽视，若网卡支持更多队列，优先使用RSS。

4.4.4 常见误区与总结