1. NAPI机制概述：NAPI的诞生背景、与传统中断收包的区别、NAPI的核心设计思想

1.1 诞生背景：中断风暴与高吞吐瓶颈

在Linux内核早期版本中，网络收包完全依赖传统中断驱动模型。每当网卡接收到一个数据包，就会触发一次硬件中断（IRQ），CPU立即暂停当前任务，执行中断服务程序（ISR）将数据从网卡拷贝到内核缓冲区。这种模型在低速网络（如10/100 Mbps）下工作良好，但随着千兆以太网（Gigabit Ethernet）的普及，问题急剧恶化：

• 中断风暴（Interrupt Storm）：当网络流量达到线速（如1 Gbps满载），网卡每秒可能产生数万甚至数十万个中断。CPU被频繁打断，大量时间消耗在中断上下文切换和ISR执行上，导致系统吞吐量不升反降。
• 缓存污染：每次中断都会刷新CPU的指令缓存（I-Cache）和数据缓存（D-Cache），中断处理完成后恢复用户态进程时又需要重新加载缓存，严重影响性能。
• 接收活锁（Receive Livelock）：在极端情况下，CPU忙于处理中断和软中断，导致用户态进程完全得不到CPU时间片，系统看似“活着”但实际无法处理任何应用层请求。

1.2 传统中断收包 vs. NAPI收包

下表从多个维度对比传统中断收包模型与NAPI收包模型的核心差异：

1.3 NAPI核心设计思想：轮询与中断结合

NAPI（New API）的核心设计思想是“中断唤醒，轮询收包”。它并非完全抛弃中断，而是将中断和轮询有机融合，在低流量时保持中断的低延迟优势，在高流量时切换到轮询的高吞吐模式。其关键机制包括：

1. 中断使能/禁用切换：当第一个数据包到达时，网卡触发硬件中断。NAPI的中断处理程序立即关闭该网卡的中断，并将网卡注册到内核的轮询列表（poll_list）中。
2. 轮询收包（Polling）：内核在软中断上下文（NET_RX_SOFTIRQ）中遍历poll_list，调用网卡驱动的poll()回调函数，批量从网卡接收队列中取出数据包，送入协议栈处理。
3. 退出条件与中断重开：当poll()函数完成一次轮询后，如果接收队列已空（无更多包），则从poll_list中移除该网卡，并重新使能中断，等待下一个数据包触发中断。
4. 预算机制（Budget）：为防止轮询独占CPU，NAPI引入预算（budget）和权重（weight）参数。每次poll()最多处理weight个包，整个软中断轮询周期最多处理budget个包（默认300）。超过预算则退出轮询，等待下一次软中断触发。

下图展示了NAPI从中断触发到轮询收包再到中断重开的完整生命周期：

1.4 NAPI的预算与权重机制

NAPI通过预算（budget）和权重（weight）两个参数实现公平调度，防止单个网卡或单个轮询周期垄断CPU：

• weight（权重）：每个网卡驱动在注册NAPI时指定的单次poll()最大收包数。典型值为64。如果一次poll()处理了weight个包后队列仍有数据，则返回budget_consumed == weight，表示需要继续轮询。
• budget（预算）：整个软中断（NET_RX_SOFTIRQ）单次触发中允许处理的总包数上限。默认值为300。内核遍历poll_list时，累计所有网卡处理的包数不能超过budget。

1.5 NAPI与传统中断的架构对比

下图从软件架构层面对比传统中断收包与NAPI收包的数据流差异：

1.6 NAPI的演进与现状

NAPI自Linux 2.4.20引入以来，经历了多次重要改进：

• Linux 2.6.x：NAPI成为默认收包模型，所有主流网卡驱动（e1000、tg3、bnx2等）均支持。
• Linux 3.x：引入多队列NAPI，支持RSS（Receive Side Scaling）和XPS（Transmit Packet Steering），每个CPU核独立轮询自己的队列。
• Linux 4.x～5.x：NAPI与XDP（eXpress Data Path）结合，在NAPI轮询阶段直接执行BPF程序，实现超高吞吐的早期包处理。
• Linux 6.x+：NAPI支持忙轮询（Busy Polling）模式，允许用户态进程主动轮询NAPI队列，进一步降低延迟。