4. 中断处理函数编写：上半部(硬中断)与下半部(tasklet/softirq)分工

网络设备中断处理是驱动性能的核心瓶颈。Linux 内核将中断处理拆分为 上半部（硬中断） 和 下半部（软中断/tasklet），以平衡实时性与吞吐量。本章深入剖析分工原则、代码实现与性能权衡。

4.1 上半部（硬中断处理程序）

上半部在关闭本地 CPU 中断（或特定中断线）的上下文中执行，必须快速返回。典型职责包括：

• 确认中断：读取中断状态寄存器，清除中断标志位。
• 保存关键数据：从硬件 FIFO 读取数据到内存缓冲区。
• 调度下半部：标记软中断或唤醒 tasklet/kthread。
• 返回 IRQ_HANDLED：通知内核中断已被处理。

// 典型上半部处理函数示例
static irqreturn_t netdev_irq_handler(int irq, void *dev_id)
{
    struct net_device *dev = (struct net_device *)dev_id;
    struct my_priv *priv = netdev_priv(dev);

    // 1. 读取中断状态寄存器
    u32 status = readl(priv->ioaddr + INT_STATUS);

    // 2. 清除中断标志（写1清除）
    writel(status, priv->ioaddr + INT_STATUS);

    // 3. 检查是否为接收中断
    if (status & RX_INT_MASK) {
        // 保存接收状态，供下半部使用
        priv->rx_status = status;
        // 调度 NAPI 软中断（下半部）
        napi_schedule(&priv->napi);
    }

    // 4. 检查是否为发送完成中断
    if (status & TX_INT_MASK) {
        // 唤醒发送完成处理（下半部）
        tasklet_schedule(&priv->tx_tasklet);
    }

    return IRQ_HANDLED;
}

4.2 下半部机制对比：Softirq vs Tasklet

Linux 提供多种下半部机制，网络驱动最常用的是 Softirq（NAPI 核心）和 Tasklet（基于 Softirq 的封装）。

4.3 下半部实现：Tasklet 示例

Tasklet 适用于不需要严格并行、代码逻辑相对简单的场景。以下展示发送完成处理的典型实现：

// 发送完成 tasklet 处理函数
static void tx_complete_tasklet(unsigned long data)
{
    struct net_device *dev = (struct net_device *)data;
    struct my_priv *priv = netdev_priv(dev);
    struct netdev_queue *txq = netdev_get_tx_queue(dev, 0);

    // 1. 读取发送完成描述符
    while (priv->tx_complete_count > 0) {
        // 释放 DMA 缓冲区
        dma_unmap_single(&dev->dev, priv->tx_desc[priv->tx_clean_idx].dma,
                         priv->tx_desc[priv->tx_clean_idx].len, DMA_TO_DEVICE);
        // 释放 skb
        dev_kfree_skb(priv->tx_skb[priv->tx_clean_idx]);
        priv->tx_clean_idx = (priv->tx_clean_idx + 1) % TX_RING_SIZE;
        priv->tx_complete_count--;
    }

    // 2. 唤醒发送队列（如果之前被停止）
    netif_tx_wake_queue(txq);
}

// 初始化 tasklet
tasklet_init(&priv->tx_tasklet, tx_complete_tasklet, (unsigned long)dev);

4.4 上半部与下半部协作流程

下图展示一次网络接收中断的完整处理路径：

4.5 分工性能权衡

合理划分上下半部直接影响网络吞吐和 CPU 利用率。以下为常见权衡点：

• 上半部过长：增加中断延迟，可能导致高优先级中断丢失（如时钟中断）。
• 下半部过重：软中断执行时间过长会阻塞用户态进程调度，降低交互体验。
• 过度拆分：频繁的上下半部切换增加上下文切换开销，降低 cache 命中率。

4.6 代码组织与调试技巧