1. 课程导论：传统中断收包模型的性能瓶颈，NAPI机制的设计初衷与核心思想，NAPI在Linux内核网络子系统中的位置

1.1 传统中断收包模型及其性能瓶颈

在Linux网络子系统的早期实现中，网络设备驱动主要依赖传统中断驱动模型来通知CPU有新数据包到达。每当网卡（NIC）接收一个数据包，硬件会触发一个中断信号，CPU立即暂停当前任务，保存上下文，跳转到中断服务例程（ISR）处理数据包。这种模型在低速网络环境下工作良好，但在高速网络（如千兆、万兆以太网）下暴露出严重的性能问题。

下表总结了传统中断模型在高速网络下的主要瓶颈：

下图展示了传统中断收包模型的数据流路径，清晰呈现了每次数据包到达时CPU必须经历的完整中断处理流程：

1.2 NAPI机制的设计初衷与核心思想

NAPI（New API）是Linux内核为解决传统中断模型在高吞吐场景下的性能瓶颈而引入的混合中断-轮询收包框架。其设计初衷可以概括为：在低流量时保持中断的低延迟优势，在高流量时自动切换为轮询模式以消除中断风暴。

NAPI的核心思想包含以下三个关键点：

1. 中断关闭与轮询切换：当网卡中断频率超过预设阈值时，驱动关闭该网卡的中断，并将设备注册到CPU的轮询列表中，由内核在软中断上下文中批量轮询收包。
2. 批量收包（Budget机制）：每次轮询周期内，驱动最多处理budget个数据包（默认300），防止单次轮询占用CPU过久，保证系统公平性。
3. 中断重新开启：当轮询队列为空（即没有待处理数据包）时，驱动重新开启网卡中断，恢复低延迟收包模式。

下表对比了传统中断模型与NAPI模型的关键差异：

下图展示了NAPI机制的核心状态机，清晰呈现了中断模式与轮询模式之间的切换逻辑：

1.3 NAPI在Linux内核网络子系统中的位置

要理解NAPI的架构位置，需要先了解Linux内核网络子系统的分层结构。NAPI位于网络设备驱动层与网络协议栈之间，是驱动层向上层协议栈递交数据包的核心通道。

下图展示了NAPI在Linux内核网络子系统中的完整位置与交互关系：

从架构角度看，NAPI框架主要涉及以下内核核心组件：

• napi_struct结构体：每个支持NAPI的设备或虚拟网卡都需要注册一个napi_struct实例，包含轮询回调函数指针poll、budget配额、设备状态标志等关键字段。
• net_rx_action软中断：NAPI的轮询逻辑在NET_RX_SOFTIRQ软中断上下文中执行，由net_rx_action函数遍历当前CPU的轮询列表，依次调用各设备的poll回调。
• budget机制：内核通过netdev_budget参数（默认300）控制单次软中断处理的数据包总数，防止CPU被网络收包独占。
• gro（Generic Receive Offload）集成：NAPI与GRO紧密配合，在轮询收包的同时完成数据包聚合，进一步减少协议栈处理开销。

struct napi_struct {
    struct list_head    poll_list;      /* 轮询链表节点 */
    unsigned long       state;          /* NAPI状态标志 */
    int                 weight;         /* 单次poll最大处理包数 */
    int                 (*poll)(struct napi_struct *, int); /* 轮询回调 */
    struct net_device   *dev;           /* 关联的网络设备 */
    struct list_head    dev_list;       /* 设备链表节点 */
    // ... 其他字段
};

下表总结了NAPI框架中各核心组件的职责与交互关系：