3、Linux网络驱动架构：net_device结构、NAPI、sk_buff、中断与轮询机制

Linux网络驱动是操作系统与物理网络设备之间的核心桥梁，其架构设计直接决定了数据收发的效率、延迟与CPU占用率。对于PHY芯片调试而言，理解驱动架构是定位问题的基础——无论是链路协商失败、丢包率异常，还是中断风暴，最终都要回归到对net_device、sk_buff、NAPI调度以及中断/轮询机制的正确理解上。本章将从这四个核心维度展开，结合PHY芯片调试的实际场景，剖析Linux网络驱动的运行骨架。

上图展示了Linux网络驱动中四个核心组件的关系：net_device作为驱动与协议栈之间的统一接口，sk_buff承载实际数据，NAPI负责高效收包调度，而中断与轮询机制则决定了CPU如何感知和处理网络事件。下面逐一深入剖析。

3.1 net_device结构：驱动与协议栈的“身份证”

核心原理

struct net_device是Linux网络驱动中最重要的数据结构，它抽象了所有网络设备（包括物理网卡、虚拟接口、VLAN子接口等）的通用属性。每个注册到内核的网络设备都对应一个net_device实例，其中包含了设备名称、MAC地址、MTU、特性标志（features）、操作函数集（netdev_ops）、ethtool操作集（ethtool_ops）以及PHY设备指针（phydev）等关键字段。

对于PHY芯片调试而言，net_device中的phydev字段是连接MAC层与PHY层的桥梁。通过phydev，驱动可以访问PHY的寄存器空间，读取链路状态、协商速率、配置中断等。此外，net_device的features字段决定了硬件卸载能力（如TSO、GSO、RXCSUM），这些特性直接影响数据路径的性能表现。

判断方法或操作流程

在实际调试中，我们通常通过以下方式检查net_device的状态：

1. 使用ip link show查看设备名称、MAC、MTU、状态（UP/DOWN）以及features标志。
2. 使用ethtool eth0查看当前速率、双工模式、自动协商状态，这些信息直接来自phydev的寄存器读取。
3. 使用ethtool -S eth0查看驱动统计信息（如tx_packets、rx_errors），这些计数器通常由驱动在netdev_ops的ndo_get_stats64回调中填充。

案例拆解：PHY链路协商失败时的net_device排查

假设某嵌入式设备使用RTL8211F PHY，上电后ip link show eth0显示NO-CARRIER，且ethtool eth0显示Speed: Unknown!。此时排查路径如下：

• 首先确认net_device的phydev是否成功绑定：检查内核日志中是否有mdio_bus探测成功的记录，以及PHY地址是否正确（常见为0x01或0x03）。
• 使用mdio-tools或驱动调试接口直接读取PHY的BMCR（寄存器0）和BMSR（寄存器1），确认PHY是否处于复位状态或掉电模式。
• 检查net_device的features是否包含NETIF_F_GRO等标志，若硬件不支持而误开启，可能导致收包异常。

常见误区与总结

一个常见误区是混淆net_device与netdev_ops的关系。net_device是“数据”，而netdev_ops是“操作”。修改PHY寄存器时，应通过phydev的drv指针调用PHY驱动提供的phy_read/write函数，而不是直接操作net_device的字段。另外，net_device的irq字段在NAPI模式下通常被设置为0或-1，表示不使用传统中断，而是依赖轮询。

3.2 sk_buff：数据包在内核中的“集装箱”

核心原理

struct sk_buff（简称skb）是Linux网络子系统中最核心的数据结构，它承载了从网卡接收或待发送的数据包。skb的设计极为精巧，通过head、data、tail、end四个指针管理数据缓冲区，支持在数据包头部添加/移除协议头（如以太网头、IP头）而无需拷贝整个数据包。

对于PHY调试，skb的len字段表示数据包总长度，protocol字段标识上层协议（如ETH_P_IP），而dev字段指向接收该包的net_device。在收包路径中，驱动从DMA缓冲区将数据拷贝到skb中，然后通过NAPI将skb上送协议栈。

操作流程：skb的分配与释放

// 收包路径中的skb分配（驱动层）
struct sk_buff *skb = netdev_alloc_skb(dev, length + NET_IP_ALIGN);
if (!skb) {
    netdev_err(dev, "skb allocation failed\n");
    return -ENOMEM;
}
skb_reserve(skb, NET_IP_ALIGN);  // 对齐IP头
skb_put(skb, length);            // 增加数据长度
skb->protocol = eth_type_trans(skb, dev);  // 解析以太网头
napi_gro_receive(&rx_ring->napi, skb);     // 交给NAPI

在调试PHY相关问题时，我们经常需要检查skb的len是否与预期一致。例如，当PHY协商为1000Mbps全双工时，接收到的帧长度应为1518字节（含CRC），若实际收到小于64字节的 runt 帧，则说明PHY或MAC的FIFO配置可能存在问题。

案例拆解：通过skb分析PHY收包异常

某客户反馈设备在千兆模式下丢包率高达5%。通过ethtool -S eth0发现rx_crc_errors和rx_frame_errors计数持续增长。进一步抓取skb信息：

• 使用perf probe在napi_gro_receive处添加探针，打印skb的len和protocol。
• 发现部分skb的len为1518，但protocol为0x0000（非预期），说明以太网头解析异常。
• 检查PHY的RTL8211F寄存器，发现RTL8211F_RCR（接收配置寄存器）的RX_ERR位被置位，表明PHY检测到接收错误。

最终定位为PHY的SGMII接口信号完整性不足，导致CRC错误。通过调整PCB走线或降低PHY的驱动电流（通过寄存器0x1C的TX_DRIVER位）解决。

常见误区

不要试图在中断上下文直接调用kfree_skb释放skb，而应使用dev_kfree_skb_any或延迟到NAPI的poll函数中处理。此外，skb的data指针在协议栈处理过程中会不断移动（如剥离以太网头），驱动层不应长期持有skb的data指针。

3.3 NAPI：中断与轮询的优雅融合

核心原理

NAPI（New API）是Linux内核为应对高网络负载而设计的收包机制。其核心思想是：在低负载时使用中断通知CPU收包；当中断频率过高（即负载增大）时，自动切换为轮询模式，关闭中断，通过poll回调批量收取数据包。这种机制有效避免了中断风暴，降低了CPU占用率。

NAPI的核心数据结构是struct napi_struct，包含poll_list（挂入软中断队列）、state（状态标志）、weight（单次poll最大处理包数）以及poll回调函数。驱动在初始化时调用netif_napi_add注册NAPI实例，并在收包中断中调用napi_schedule触发调度。

判断方法：NAPI是否生效

可以通过以下方式判断NAPI是否正常工作：

1. 查看/proc/net/softnet_stat，其中第2列（processed）和第3列（dropped）可以反映NAPI处理情况。
2. 使用cat /proc/interrupts观察网卡中断计数。若中断次数在流量增大时不再线性增长，说明NAPI已切换至轮询模式。
3. 在驱动代码中打印napi_schedule的调用次数，确认中断下半部是否正确触发。

案例拆解：中断风暴导致CPU软中断占用100%

某ARM平台在100Mbps流量下CPU软中断占用率高达100%，系统响应缓慢。通过top命令发现ksoftirqd进程占用CPU 90%以上。排查过程：

• 检查/proc/interrupts，发现网卡中断次数每秒超过10万次，确认中断风暴。
• 查看驱动代码，发现中断处理函数中未正确调用napi_schedule，而是直接处理数据包，导致每次中断只处理一个包。
• 修复方案：在中断处理函数中仅调用napi_schedule，将实际收包逻辑移至poll回调中，并设置合理的weight值（通常为64）。

修复后，中断次数降至每秒约2000次，CPU软中断占用率降至15%。

常见误区

一个常见误区是在poll回调中调用netif_rx而非napi_gro_receive。前者会将skb放入CPU的backlog队列，绕过了NAPI的批量处理优势，导致性能下降。正确做法是使用napi_gro_receive，它支持GRO（Generic Receive Offload）合并小包，进一步提升吞吐量。

3.4 中断与轮询机制：PHY事件的通知路径

核心原理

PHY芯片通过中断引脚（如RTL8211F的INTR引脚）向SoC报告链路状态变化、协商完成、远程唤醒等事件。Linux内核中，PHY中断有两种处理方式：

• 传统中断方式：PHY中断引脚连接到SoC的GPIO，驱动通过request_irq注册中断处理函数，在中断中读取PHY状态寄存器并调用phy_mac_interrupt通知MAC层。
• 轮询方式：当PHY不支持中断或中断引脚未连接时，内核通过定时器（如phy_poll）周期性读取PHY状态寄存器，检测链路变化。

在NAPI框架下，PHY中断通常与网络设备的中断共享或独立。当PHY检测到链路断开时，中断处理函数会调用phy_change回调，最终触发netif_carrier_off通知协议栈链路不可用。

操作流程：PHY中断的注册与处理

// PHY驱动中断处理示例
static irqreturn_t phy_interrupt(int irq, void *phy_dat)
{
    struct phy_device *phydev = phy_dat;
    // 读取PHY状态寄存器，确认中断源
    phy_read(phydev, MII_PHY_IMR);
    // 处理链路变化
    if (phydev->state == PHY_RUNNING) {
        phy_check_link_status(phydev);
    }
    // 重新使能中断
    phy_write(phydev, MII_PHY_IMR, PHY_INTERRUPT_ENABLED);
    return IRQ_HANDLED;
}

案例拆解：PHY中断丢失导致链路状态不更新

某设备在插拔网线后，ip link状态未及时更新，需要手动ifconfig eth0 down/up才能恢复。分析发现PHY中断引脚未正确配置：

• 检查设备树，发现PHY节点的interrupt-parent和interrupts属性未设置，导致内核无法注册PHY中断。
• 硬件上PHY的INTR引脚连接到SoC的GPIO17，但GPIO复用配置错误，被设置为普通输入而非中断模式。
• 修复设备树，添加interrupt-parent = &gpio1;和interrupts = <17 IRQ_TYPE_EDGE_FALLING>;，并修正GPIO复用。

修复后，插拔网线时链路状态即时更新，无需手动干预。

常见误区与总结

在调试PHY中断时，务必确认PHY的中断输出极性（高电平有效还是低电平有效）与SoC的GPIO触发条件匹配。RTL8211F默认中断输出为低电平有效，若配置为上升沿触发，将导致中断永远无法触发。此外，PHY中断服务函数中应避免耗时操作（如MDIO读写），否则会阻塞中断上下文，影响系统实时性。