1. 传统中断驱动收包模型
在深入 NAPI 轮询机制之前，必须先理解传统中断驱动收包模型的工作原理及其在高吞吐场景下的致命缺陷。中断机制是 CPU 与硬件设备通信的核心手段，但在高速网络环境下，不加节制的中断反而会成为性能瓶颈。
1.1 中断机制原理
中断（Interrupt）是一种硬件通知机制：当网卡接收到数据帧并完成 DMA 传输后，会通过中断线向 CPU 发送电信号，CPU 暂停当前任务，跳转到中断服务程序（ISR, Interrupt Service Routine）处理收包。整个过程分为上下半部：
- 上半部（Top Half）：在中断上下文中快速执行，通常只做最小必要操作，如标记中断状态、调度下半部。
- 下半部（Bottom Half）：在软中断或 tasklet 中执行实际收包处理，如将 sk_buff 送入协议栈。
关键指标： 传统中断模式下，每收到一个数据包就触发一次中断。在 10Gbps 网络下，64 字节小包可达 14.88 Mpps（百万包/秒），即每秒触发近 1500 万次中断。
1.2 中断风暴问题
中断风暴（Interrupt Storm）是指当网络流量超过 CPU 处理能力时，中断频率急剧升高，导致 CPU 几乎全部时间都在处理中断上下文切换，无法执行用户态应用程序或协议栈逻辑。典型表现：
- CPU 软中断占用率接近 100%，但收包吞吐量反而下降。
- 系统响应延迟急剧增加，甚至触发看门狗超时。
- 丢包率飙升，因为网卡 RX ring 被填满后新包被丢弃。
实际案例： 某数据中心服务器在 40Gbps 流量下，传统中断模式导致 CPU 0 软中断占用率达到 98%，实际有效收包吞吐量仅 12Gbps，丢包率超过 30%。启用 NAPI 后，CPU 占用率降至 35%，吞吐量达到 38Gbps。
| 指标 | 正常状态 | 中断风暴状态 |
|---|---|---|
| 中断频率 | ~14.88 Mpps | >20 Mpps（含重传） |
| CPU 软中断占用 | 40% - 60% | 95% - 100% |
| 有效收包吞吐量 | 9.8 Gbps | 3 - 5 Gbps |
| 丢包率 | <0.01% | 15% - 40% |
| 应用层延迟 | 10 - 50 μs | 500 μs - 10 ms |
1.3 高吞吐场景下的性能瓶颈
传统中断驱动模型在高吞吐场景下存在三个根本性性能瓶颈：
- 上下文切换开销：每次中断都涉及 CPU 从用户态/内核态切换到中断上下文，保存/恢复寄存器、栈等状态。单次切换约 1-5 μs，14.88 Mpps 下仅切换开销就达 15-75 μs/包，远超实际处理时间。
- 缓存污染：中断处理会刷新 CPU 的 L1/L2 缓存，导致之前正在执行的应用程序数据被逐出。频繁中断使缓存命中率从 95% 以上降至 30% 以下。
- 中断亲和性不均：默认情况下所有中断可能路由到同一个 CPU 核心，造成单核瓶颈，其他核心空闲。
1.4 传统中断模型的局限性总结
传统中断驱动收包模型在低速网络（百兆/千兆）时代是合理的设计，但在万兆及更高速度下暴露出严重缺陷。下表总结了其核心局限性：
| 维度 | 具体问题 | 影响程度 |
|---|---|---|
| 中断频率 | 每包一次中断，14.88 Mpps 时 CPU 无法承受 | 致命 |
| 上下文切换 | 每次中断 1-5 μs 切换开销，占 CPU 时间 15%+ | 严重 |
| 缓存效率 | 频繁中断导致缓存抖动，命中率下降 60%+ | 严重 |
| 可扩展性 | 单核瓶颈，多核利用率低 | 中等 |
| 延迟抖动 | 中断风暴时延迟从 μs 级飙升到 ms 级 | 严重 |
| 丢包率 | RX ring 溢出导致大量丢包 | 致命 |
核心结论： 传统中断驱动模型无法满足现代高速网络（10Gbps/25Gbps/40Gbps/100Gbps）的收包需求。必须引入轮询（Polling）或混合中断-轮询机制来降低中断频率、减少上下文切换、提高缓存利用率。这正是 NAPI 轮询机制要解决的核心问题。