linux 网络设备 --- NAPI

NAPI 的全称是 New API，它是 Linux 内核网络子系统中用于优化数据包接收性能的一套编程接口和机制，目的是解决传统中断驱动收包模式下的 “中断风暴” 问题。

 

它的命名逻辑很直接：相对于 Linux 早期的旧版网络收包 API，这套新的 “中断 + 轮询” 混合模式的接口被称为 New API，后续简称为 NAPI 并沿用至今。

 

NAPI 解决的是网络设备高速收包场景下的中断风暴，这种中断风暴由传统中断驱动式收包机制的固有缺陷导致。

 

1. 传统中断驱动收包的问题根源

 

在传统机制中，网络设备（网卡）的工作逻辑是：

 

• 每收到一个数据包，就会向 CPU 触发一次硬件中断；
• CPU 响应中断后，会调用中断处理函数，完成数据包的拷贝、协议栈交付等操作。

 

当网络带宽很高（如千兆 / 万兆网卡）且数据包很小时（如小包攻击、海量小报文业务），会出现每秒数万甚至数十万次的中断请求：

 

• CPU 会被频繁的中断抢占，陷入 “响应中断 → 处理收包 → 再响应中断” 的循环；
• 大量的 CPU 时间消耗在中断上下文切换（保存现场、恢复现场）上，而非实际的数据包处理；
• 严重时，CPU 被中断完全占满，其他进程（包括内核进程）无法正常执行，导致系统性能急剧下降，这就是中断风暴。

 

2. NAPI 如何解决中断风暴

 

NAPI 采用 “中断触发 + 轮询处理” 的混合模式，核心思路是 “一次中断，批量处理多个数据包”，彻底避免小包场景下的高频中断：

 

1. 首次触发中断
    
   网卡收到第一个数据包时，依然触发硬件中断，通知 CPU 有数据到达。
2. 关闭中断，切换到轮询模式
    
   CPU 响应中断后，在中断处理函数中做两件事：
   • 关闭网卡的收包中断，防止后续数据包继续触发中断；
   • 将该网卡的 NAPI 实例加入到内核轮询队列。
    
3. 批量轮询处理数据包
    
   内核软中断（NET_RX_SOFTIRQ）会调度 NAPI 的 poll 函数，批量读取网卡缓冲区中的所有待处理数据包，直到缓冲区为空。
4. 恢复中断，等待下一批数据
    
   当数据包处理完毕后，NAPI 重新启用网卡的收包中断，回到等待状态，等待下一批数据包到达后重复上述流程。

 

3. 关键优势：针对小包场景的优化

 

NAPI 对小包、高并发场景的优化效果尤为明显：

 

• 传统机制：1000 个小包 → 触发 1000 次中断 → 1000 次上下文切换；
• NAPI 机制：1000 个小包 → 触发 1 次中断 → 1 次上下文切换 + 1 次批量轮询处理。

 

这种模式直接将中断次数从 “数据包数量级” 降到 “批次数量级”，从根源上杜绝了中断风暴的产生。