4. NAPI 数据结构：napi_struct 结构体详解、poll 函数指针、设备与 NAPI 的绑定关系

NAPI 机制的核心数据结构是 napi_struct，它连接了网络设备、中断处理与轮询收包逻辑。理解该结构体的字段含义、poll 函数指针的注册机制以及设备与 NAPI 实例的绑定关系，是进行中断合并参数调优的基础。

4.1 napi_struct 结构体核心字段

napi_struct 定义在 <linux/netdevice.h> 中，每个 NAPI 实例代表一个可被轮询的收包队列。其关键字段如下表所示：

4.2 poll 函数指针：驱动注册的收包回调

poll 函数指针是 NAPI 机制的灵魂。驱动在初始化 NAPI 实例时，必须注册一个符合 poll_func 签名的回调函数。该函数在软中断上下文（ksoftirqd）中被调用，负责从硬件队列中批量收取报文并上送协议栈。

函数签名：

int (*poll)(struct napi_struct *napi, int budget);

• napi：指向当前 NAPI 实例的指针，驱动可通过 napi->dev 获取设备信息。
• budget：本次轮询允许处理的最大报文数，由软中断调度时传入，通常等于 napi->weight。
• 返回值：实际处理的报文数量。若返回值等于 budget，表示仍有剩余报文待处理，NAPI 保持调度状态；若小于 budget，表示队列已空，驱动应调用 napi_complete() 退出轮询并重新开启中断。

典型驱动实现流程：

1. 从硬件描述符环中读取已接收的报文。
2. 调用 napi_gro_receive() 或 netif_receive_skb() 将 skb 送入协议栈。
3. 统计处理数量，若达到 budget 则返回 budget；否则返回实际处理数。
4. 若返回小于 budget，调用 napi_complete() 并重新使能硬件中断。

4.3 设备与 NAPI 的绑定关系

网络设备与 NAPI 实例的绑定通过 netif_napi_add() 函数在驱动初始化时建立。绑定关系决定了中断触发后，哪个 NAPI 实例被调度。

绑定流程：

• 驱动在探测（probe）阶段为每个 RX 队列或队列组分配一个 napi_struct 实例。
• 调用 netif_napi_add(dev, &napi, poll_func, weight) 将 NAPI 实例注册到设备 dev 上。
• 设备的中断处理函数（ISR）中，调用 napi_schedule(&napi) 将 NAPI 实例加入当前 CPU 的 poll_list，并触发软中断。

多队列场景下的绑定关系：

4.4 NAPI 数据结构与调度关系图

下图展示了 napi_struct 与网络设备、中断处理、软中断调度之间的核心关系：

4.5 多队列绑定与中断合并的协同

在支持 RSS（Receive Side Scaling）的多队列网卡中，每个 RX 队列拥有独立的 NAPI 实例和中断。中断合并参数（如 ethtool -C eth0 rx-usecs 100）控制每个队列的中断产生频率，而 NAPI 的 weight 控制单次轮询的收包量。两者协同工作：

• 中断合并（coalescing）：延迟中断触发，积累更多报文后一次性通知 CPU，减少中断次数。
• NAPI 轮询：中断触发后，NAPI 在软中断中批量收包，直到队列为空或达到 weight 上限。
• 调优平衡：增大 rx-usecs 可提升吞吐但增加延迟；增大 weight 可减少软中断调度次数但增加单次 CPU 占用。