1. NAPI概述：背景、动机与核心思想
NAPI（New API）是Linux内核为解决传统中断驱动网络在高吞吐场景下的性能瓶颈而设计的一套数据包处理框架。它并非一个独立的驱动模型，而是一组回调接口与调度策略，允许网卡驱动在中断与轮询之间动态切换，从而在低负载时保持低延迟、在高负载时避免中断风暴。
1.1 传统中断方式的瓶颈
在NAPI出现之前，Linux网络驱动几乎完全依赖每包中断模式：网卡每收到一个数据包，就向CPU触发一次硬件中断。这种模式在低速网络（如10/100 Mbps）下工作良好，但当链路速率提升到1 Gbps甚至更高时，中断方式暴露出严重问题。
| 瓶颈维度 | 具体表现 | 量化影响 |
|---|---|---|
| 中断风暴 | 高吞吐时每秒中断次数可达数万到数十万次 | CPU被中断处理完全占满，用户态进程无法调度 |
| 缓存污染 | 每次中断都刷新L1/L2缓存，中断返回后重新加载 | 有效CPU周期利用率下降30%~50% |
| 上下文切换开销 | 中断上下文与进程上下文频繁切换 | 单包处理延迟增加数微秒 |
| 公平性缺失 | 高优先级中断可能饿死低优先级软中断 | 协议栈处理出现长尾延迟 |
1.2 NAPI的核心思想：轮询与中断结合
NAPI的核心设计原则是：中断用于唤醒，轮询用于收包。具体来说，驱动在初始化时注册一个轮询函数（poll callback），网卡收到第一个数据包时仍然触发中断，但中断处理程序立即关闭该网卡的中断使能，并将设备的NAPI实例加入CPU的轮询列表。随后，内核在软中断上下文中反复调用该设备的poll函数，批量收取所有已到达的数据包，直到收完或达到预算配额。当收包完成后，驱动重新开启中断，等待下一个数据包。
1.3 NAPI在Linux内核中的位置
NAPI位于Linux网络子系统的驱动层与协议栈层之间，属于软中断（SoftIRQ）处理路径的一部分。其核心数据结构struct napi_struct嵌入在网卡驱动的私有数据结构中，通过netif_napi_add()注册到内核。内核的软中断处理函数net_rx_action()遍历当前CPU的NAPI轮询列表，依次调用各设备的poll回调。
1.4 NAPI的关键数据结构
驱动开发者需要理解的核心数据结构是struct napi_struct，它包含以下关键字段：
| 字段 | 类型 | 作用 |
|---|---|---|
poll_list |
struct list_head |
链接到CPU的轮询链表，由net_rx_action()遍历 |
poll |
poll_func * |
驱动实现的轮询回调，接收预算参数，返回已处理包数 |
weight |
int |
单次轮询最大处理包数，通常为64 |
state |
unsigned long |
状态标志位，如NAPI_STATE_SCHED表示已调度 |
dev_list |
struct list_head |
关联的net_device链表（多队列网卡使用） |
weight参数通常设置为网卡接收描述符队列长度的一半或固定值64。过大的weight会导致单次轮询占用CPU时间过长，增加其他设备的收包延迟；过小的weight则无法充分利用批量收包的优势。
1.5 NAPI的演进与现状
NAPI自Linux 2.4.20引入以来，经历了多次重要改进：
- Linux 2.6.x：引入
netif_rx()与netif_receive_skb()分离，NAPI成为默认收包路径。 - Linux 3.x：支持多队列网卡的RPS（Receive Packet Steering），NAPI与CPU绑定更加灵活。
- Linux 4.x：引入
napi_busy_loop忙轮询模式，进一步降低延迟敏感场景的抖动。 - Linux 5.x+：NAPI与XDP（eXpress Data Path）协同工作，支持在驱动层直接处理数据包。
目前，几乎所有主流网卡驱动（如igb、ixgbe、mlx5、bnxt_en等）都使用NAPI作为标准收包接口。NAPI的设计思想也被其他操作系统（如FreeBSD的iflib、Windows的RSS）借鉴。