3、传统中断处理模型：中断风暴问题、单核瓶颈、吞吐量限制
在深入 NAPI 与中断亲和性协同配置之前，必须理解传统中断处理模型（即纯中断驱动模型）的固有缺陷。该模型在早期 Linux 内核及低吞吐量场景下工作良好，但随着网络速率从 1Gbps 向 10Gbps、25Gbps 乃至更高演进，其架构瓶颈逐渐暴露，成为性能杀手。
3.1 传统中断处理模型的工作流程
传统模型下，每个数据包到达网卡（NIC）时，都会触发一次硬件中断（IRQ）。CPU 收到中断后，暂停当前任务，保存上下文，进入中断服务程序（ISR）。ISR 在中断上下文中完成数据包的接收、协议栈处理，最后返回被中断的任务。整个过程是“每包一中断”的串行模式。
核心特征： 中断频率 = 数据包到达频率。对于 10Gbps 网络，64 字节小包每秒可达约 1488 万包，即每秒触发 1488 万次中断。
3.2 中断风暴问题
中断风暴（Interrupt Storm）是指系统在短时间内接收到远超 CPU 处理能力的中断请求，导致 CPU 几乎将所有时间都用于处理中断，而无法执行用户态任务或协议栈处理。这是传统模型在高吞吐网络下的典型灾难场景。
| 网络速率 | 64 字节小包 PPS | 中断频率（传统模型） | CPU 单核处理能力 | 是否触发风暴 |
|---|---|---|---|---|
| 1 Gbps | ~1.49 Mpps | 1.49 MHz | ~2-3 M 中断/秒 | 勉强可处理 |
| 10 Gbps | ~14.88 Mpps | 14.88 MHz | ~2-3 M 中断/秒 | 严重风暴 |
| 25 Gbps | ~37.2 Mpps | 37.2 MHz | ~2-3 M 中断/秒 | 完全不可用 |
中断风暴的连锁反应： 当 CPU 被中断淹没时，不仅网络吞吐量急剧下降，还会导致磁盘 I/O、定时器、进程调度等其他子系统因得不到 CPU 时间而出现“软锁”或“看门狗超时”，最终系统可能完全挂死。
3.3 单核瓶颈
传统中断模型通常将所有中断路由到单个 CPU 核心（通常是 CPU 0）。即使系统拥有多核处理器，所有网络处理负载也集中在单一核心上，形成严重的单核瓶颈。
- 中断亲和性未配置： 默认情况下，所有网卡中断映射到 CPU 0，导致该核心 100% 忙于中断处理，而其他核心空闲。
- 缓存局部性差： 单核处理所有数据包，无法利用多核的 L2/L3 缓存并行优势，频繁的上下文切换导致缓存污染。
- 协议栈处理串行化： 即使数据包属于不同流，也必须排队等待同一核心处理，无法实现流级并行。
3.4 吞吐量限制
传统中断模型对系统吞吐量的限制体现在多个层面，最终导致有效吞吐量远低于链路带宽。
| 限制因素 | 具体表现 | 量化影响 |
|---|---|---|
| 中断处理开销 | 每次中断需保存/恢复上下文，执行 ISR 入口/出口代码 | 每中断约 1-3 μs 开销，10 Gbps 下纯中断开销占满单核 |
| 缓存抖动 | 频繁中断导致 CPU 缓存（L1/L2）被不断刷新 | 缓存命中率下降 30%-50%，内存访问延迟增加 |
| 协议栈处理延迟 | 数据包在中断上下文中处理，无法利用批量处理优化 | 每个包独立处理，无法分摊协议栈固定开销 |
| 锁竞争 | 多队列网卡若未正确配置，多个中断可能竞争同一锁 | 自旋锁等待导致 CPU 空转，吞吐量进一步下降 |
性能数据对比： 在 10 Gbps 网络环境下，传统中断模型的实际有效吞吐量通常只能达到 2-4 Gbps，而链路利用率不足 40%。剩余带宽全部消耗在中断处理和上下文切换上。
3.5 传统模型的适用场景与局限性总结
传统中断处理模型并非一无是处，在特定场景下仍有其价值，但在现代高速网络环境中已无法胜任。
- 适用场景： 低速率网络（< 1 Gbps）、数据包到达率低、对延迟不敏感、CPU 资源充裕。
- 不适用场景： 10 Gbps 及以上高速网络、小包密集流量（如 NFV、DPVS）、对吞吐量和 CPU 效率有严格要求的系统。
- 根本矛盾： 中断频率与数据包到达率成正比，而 CPU 处理中断的能力存在物理上限。当包速率超过 CPU 中断处理能力时，系统必然崩溃。