2. 传统中断收包模型：硬件中断(IRQ)流程、中断风暴问题、高PPS场景下的性能瓶颈
在NAPI和中断合并技术普及之前，Linux内核处理网络数据包完全依赖传统中断驱动模型。该模型设计简单、响应迅速，但在高速网络场景下暴露出严重的性能缺陷。理解这一模型是掌握后续NAPI优化技术的基础。
2.1 硬件中断(IRQ)收包流程
传统收包流程以“每包必中断”为核心理念。当网卡接收到一个数据包时，会通过PCIe总线向CPU发送一个硬件中断信号，CPU暂停当前任务，转而执行中断服务程序(ISR)。
关键流程步骤：
- 数据到达：网络数据帧从物理介质到达网卡RX FIFO。
- DMA传输：网卡通过DMA将数据帧拷贝到主内存中的Ring Buffer。
- 中断触发：网卡断言IRQ引脚（或发送MSI-X消息），通知CPU。
- 中断响应：CPU保存当前上下文，跳转到中断向量表对应的ISR入口。
- ISR执行：在中断上下文中，ISR读取网卡状态寄存器，将sk_buff送入协议栈。
- 软中断触发：ISR通常触发NET_RX_SOFTIRQ软中断，将后续处理交给软中断上下文。
- 协议栈处理：软中断中完成IP层、TCP/UDP层处理，最终将数据交付给socket。
2.2 中断风暴问题
中断风暴（Interrupt Storm）是指当网络数据包到达速率超过CPU处理能力时，中断请求持续淹没CPU，导致系统陷入“中断-处理-中断”的死循环，用户态进程几乎得不到CPU时间片。
中断风暴的典型症状：
- CPU软中断占用率（si）持续超过80%，甚至接近100%。
- 系统吞吐量不升反降，增加发包速率反而导致收包速率下降。
- 用户态应用响应延迟急剧增加，出现大量调度延迟。
- 中断亲和性失衡，单个CPU核心被中断淹没，其他核心空闲。
2.3 高PPS场景下的性能瓶颈分析
在每秒百万级数据包（Mpps）的高PPS场景下，传统中断模型面临以下系统性瓶颈：
| 瓶颈维度 | 具体表现 | 量化影响 |
|---|---|---|
| 中断上下文切换开销 | 每次中断需要保存/恢复寄存器、TLB刷新、Cache污染 | 单次中断开销约 1-5μs，1Mpps时CPU纯中断开销达 1000-5000μs |
| Cache抖动 | 中断处理频繁切换代码路径，L1/L2 Cache命中率骤降 | Cache miss率从5%升至40%以上 |
| 锁竞争 | 多队列网卡在多核间分发中断，导致协议栈锁争用 | spinlock自旋时间占比超过30% |
| 内存分配压力 | 每个数据包需要分配sk_buff，频繁的slab分配/释放 | 分配延迟增加，内存碎片化加剧 |
| 中断亲和性不均 | 默认中断路由到CPU0，单核成为瓶颈 | CPU0软中断占用100%，其他核心空闲 |
性能调优启示：传统中断模型在PPS超过 50,000 时开始出现明显性能拐点。当PPS达到 200,000 以上时，系统吞吐量不再随发包速率线性增长，反而出现下降。这正是NAPI和中断合并技术要解决的核心问题——减少中断次数，将收包模式从“中断驱动”转变为“轮询驱动”。
2.4 传统中断模型的局限性总结
传统中断收包模型的设计哲学是“低延迟优先”，但在高吞吐场景下，这种设计反而成为性能瓶颈。核心矛盾在于：
- 中断频率与CPU开销的矛盾：每包中断导致CPU上下文切换开销与数据包速率成正比，无法扩展。
- 实时性与批处理能力的矛盾：中断模型追求单个包的快速响应，但放弃了批量处理带来的效率提升。
- 单核处理与多核并行的矛盾：中断亲和性配置不当会导致单核过载，而多核间负载均衡又引入新的同步开销。