📚 课程目录第3章网卡驱动与NAPI机制

3. 网卡驱动与NAPI机制：中断与轮询的协同

在Linux网络协议栈中，网卡驱动与NAPI（New API）机制是数据包进入系统的第一道关卡。传统的中断驱动模式在高吞吐量场景下会导致严重的中断风暴，而NAPI通过中断与轮询的协同，在低负载时保持低延迟，在高负载时降低CPU开销。本章将深入分析NAPI的工作原理，并以Intel ixgbe驱动为例，拆解驱动层接收数据包的入口函数。

3.1 从传统中断到NAPI：为什么需要协同？

传统网卡驱动在每次收到数据包时都会触发硬件中断，CPU立即暂停当前任务去处理。这种模式在千兆网络下尚可接受，但在万兆甚至更高带宽下，每秒数百万个数据包会触发同等数量的中断，导致CPU几乎100%用于中断处理，无法执行用户态应用——这就是中断风暴。

特性	传统中断模式	NAPI模式
触发方式	每个数据包触发一次中断	中断唤醒 + 轮询批量收包
高负载行为	中断风暴，CPU过载	关闭中断，轮询收包，降低开销
低负载延迟	低（立即响应）	低（中断立即唤醒）
CPU利用率	高（频繁上下文切换）	低（批量处理，减少切换）
适用场景	低吞吐、延迟敏感	高吞吐、通用场景

  核心思想：NAPI在数据包到达时先通过中断快速唤醒驱动，然后立即关闭中断并切换到轮询模式，一次性从硬件队列中取出多个数据包。当队列为空时，重新开启中断，等待下一个数据包到达。

3.2 NAPI轮询与中断的协同工作流程

NAPI的协同机制可以概括为三个阶段：中断触发 → 轮询注册 → 批量收包 → 重新开启中断。下图展示了完整的生命周期：

性能关键指标：NAPI的轮询预算（budget）和权重（weight）决定了每次轮询最多处理多少个数据包。默认budget为300，weight为64。如果驱动在轮询中消耗完budget，内核会将其加入轮询列表尾部，等待下一次调度。

3.3 驱动层接收入口：ixgbe_clean_rx_irq 深度分析

ixgbe是Intel 10GbE网卡的官方驱动，其接收路径的核心函数是ixgbe_clean_rx_irq。该函数在NAPI的轮询上下文中被调用，负责从硬件描述符队列中取出数据包，并传递给上层协议栈。以下是该函数的简化流程：

获取描述符队列：从rx_ring中读取下一个待处理的硬件描述符。
检查描述符状态：通过描述符的status字段判断数据包是否已由DMA写入内存。
构建sk_buff：分配或复用sk_buff结构体，并将DMA缓冲区中的数据映射到skb中。
卸载校验和：根据硬件提供的校验和状态，设置skb的ip_summed字段。
调用napi_gro_receive：将skb送入GRO（Generic Receive Offload）处理，然后递交给协议栈。
更新描述符：将处理完成的描述符归还给硬件，以便硬件继续写入新数据。

// ixgbe_clean_rx_irq 核心逻辑（简化版）
static int ixgbe_clean_rx_irq(struct ixgbe_q_vector *q_vector,
                               struct ixgbe_ring *rx_ring,
                               int budget)
{
    unsigned int total_rx_packets = 0, total_rx_bytes = 0;
    struct sk_buff *skb;
    union ixgbe_adv_rx_desc *rx_desc;

    // 1. 循环处理描述符，直到用完budget或队列为空
    while (likely(total_rx_packets < budget)) {
        rx_desc = IXGBE_RX_DESC(rx_ring, rx_ring->next_to_clean);

        // 2. 检查描述符是否已由硬件写入（DD位）
        if (!ixgbe_test_staterr(rx_desc, IXGBE_RXD_STAT_DD))
            break;  // 硬件尚未完成DMA，退出轮询

        // 3. 硬件预取数据，减少缓存未命中
        dma_rmb();

        // 4. 构建skb（从页池或预分配缓冲区）
        skb = ixgbe_fetch_rx_buffer(rx_ring, rx_desc);
        if (unlikely(!skb))
            break;

        // 5. 卸载硬件校验和
        ixgbe_rx_checksum(rx_ring, rx_desc, skb);

        // 6. 设置skb其他字段（协议、VLAN等）
        ixgbe_process_skb_fields(rx_ring, rx_desc, skb);

        // 7. 将skb送入GRO/协议栈
        napi_gro_receive(&q_vector->napi, skb);

        // 8. 统计计数
        total_rx_packets++;
        total_rx_bytes += skb->len;

        // 9. 清理描述符，归还给硬件
        ixgbe_put_rx_buffer(rx_ring, rx_desc);
        rx_ring->next_to_clean =
            (rx_ring->next_to_clean + 1) & rx_ring->count;
    }

    // 10. 更新硬件寄存器，通知硬件已消费描述符
    ixgbe_release_rx_desc(rx_ring, rx_ring->next_to_clean);

    return total_rx_packets;
}

常见丢包点：在ixgbe_clean_rx_irq中，如果ixgbe_fetch_rx_buffer分配skb失败（内存不足），该数据包会被直接丢弃，驱动会递增rx_ring->rx_stats.alloc_rx_buff_failed计数器。这是驱动层最常见的丢包原因之一。

3.4 NAPI与驱动层的交互架构

为了更直观地理解NAPI与驱动层的协作关系，下图展示了从硬件中断到skb递交给协议栈的完整架构：

3.5 NAPI调度与轮询预算管理

NAPI的调度由内核的net_rx_action函数在软中断（softirq）上下文中执行。驱动通过napi_schedule将NAPI结构体加入CPU的轮询列表。以下是调度与预算管理的关键参数：

参数	默认值	作用	修改接口
budget	300	每次`net_rx_action`允许处理的最大数据包数	`/proc/sys/net/core/netdev_budget`
weight	64	单个NAPI实例每次poll允许处理的最大数据包数	驱动初始化时设置（如`netif_napi_add`）
gro_flush_timeout	1 (jiffies)	GRO超时时间，防止小包被过度延迟	`/sys/class/net/ethX/gro_flush_timeout`

  调优建议：在高吞吐场景下，如果发现CPU的softirq占用过高，可以适当降低netdev_budget或增加weight，以平衡收包延迟与CPU开销。对于万兆网卡，建议将weight设置为128或256。

3.6 驱动层丢点排查清单

在驱动与NAPI层，数据包可能因以下原因被丢弃。排查时可通过ethtool -S ethX查看驱动统计计数器：

rx_no_buffer_count：驱动无法分配skb或DMA缓冲区，通常由内存压力或描述符耗尽导致。
rx_missed_errors：硬件FIFO溢出，网卡内部缓冲区不足，通常由中断处理不及时导致。
rx_fifo_errors：DMA描述符环满，硬件无法写入新数据。
alloc_rx_buff_failed：驱动在ixgbe_alloc_rx_buffers中分配页缓冲区失败。
napi_poll_in_process：NAPI轮询尚未完成时新中断到达，但中断已被关闭，不会造成丢包。