📚 课程目录第4章网络协议栈入口

4. 网络协议栈入口：netif_receive_skb() 函数流程

当网络设备驱动通过 NAPI 或中断将 sk_buff 递交给内核网络栈时，netif_receive_skb() 是协议栈的正式入口点。该函数负责将数据包从驱动层移交到协议层，并触发后续的协议分发与处理流程。理解这一入口函数的执行路径，是调试网络数据通路延迟、丢包以及驱动兼容性问题的关键。

4.1 netif_receive_skb() 函数流程

netif_receive_skb() 是内核网络子系统中一个轻量级的封装函数，其主要职责是进行基本的合法性检查，并快速将数据包导向核心处理函数。其典型调用栈如下：

驱动 NAPI poll() 回调
  └─> napi_gro_receive() / napi_skb_finish()
       └─> netif_receive_skb(skb)
            └─> __netif_receive_skb(skb)
                 └─> __netif_receive_skb_core(skb, ...)

  调试要点： 在 Android 内核中，netif_receive_skb() 之前通常会经过 GRO（Generic Receive Offload）处理。如果驱动未正确实现 NAPI 或 GRO，可能导致 netif_receive_skb() 被频繁调用，增加 CPU 开销。使用 tracepoint:net/netif_receive_skb 可以捕获入口处的 skb 信息。

netif_receive_skb() 的核心逻辑包含以下步骤：

空指针与校验和检查：验证 skb 不为 NULL，并检查硬件校验和状态（CHECKSUM_UNNECESSARY 等）。
时间戳收集：如果启用了网络时间戳功能，在此处记录接收时间。
调用核心处理：直接调用 __netif_receive_skb()，该函数会进一步处理 VLAN、桥接等逻辑，最终进入 __netif_receive_skb_core()。

性能提示： 在 Android 低内存场景下，netif_receive_skb() 中应避免不必要的 skb 克隆或共享操作。驱动应确保 skb 在进入此函数前已准备好，以减少入口处的额外开销。

4.2 __netif_receive_skb_core() 核心处理

__netif_receive_skb_core() 是网络协议栈中数据包分发的核心枢纽。该函数运行在软中断（softirq）上下文中，负责将 skb 传递给所有注册的协议处理程序。其处理流程可概括为以下几个关键阶段：

阶段	处理逻辑	关键函数/操作
1. 预处理	处理 VLAN 头部、设置 skb->protocol	vlan_do_receive(), eth_type_trans()
2. 桥接/网桥检查	检查 skb 是否应被桥接转发	br_handle_frame_hook
3. 协议分发	遍历 ptype_all 和 ptype_base 哈希表	deliver_skb()
4. 原始套接字	将数据包投递到原始套接字（AF_PACKET）	ptype_all 链表处理

调试陷阱： 在 Android 内核中，如果 __netif_receive_skb_core() 中发生长时间循环或死锁，会导致软中断被阻塞，进而引发网络中断丢失或 watchdog 超时。使用 ftrace 跟踪 net:netif_receive_skb 和 net:netif_rx 事件，可以定位分发阶段的延迟。

该函数的核心代码路径如下：

static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc)
{
    struct packet_type *ptype, *pt_prev;
    int ret = NET_RX_DROP;

    // 1. 处理 VLAN 标签
    if (skb->vlan_proto)
        vlan_do_receive(&skb);

    // 2. 设置网络层协议类型
    skb->protocol = eth_type_trans(skb, skb->dev);

    // 3. 遍历 ptype_all (原始套接字)
    list_for_each_entry_rcu(ptype, &ptype_all, list) {
        if (!ptype->dev || ptype->dev == skb->dev)
            deliver_skb(skb, ptype, pt_prev);
    }

    // 4. 根据 skb->protocol 查找 ptype_base 哈希表
    ptype = rcu_dereference(ptype_base[ntohs(skb->protocol) & PTYPE_HASH_MASK]);
    while (ptype) {
        if (ptype->type == skb->protocol &&
            (!ptype->dev || ptype->dev == skb->dev))
            deliver_skb(skb, ptype, pt_prev);
        ptype = ptype->next;
    }

    return ret;
}

4.3 协议分发表 (packet_type)

协议分发表是内核实现网络协议多路复用的核心数据结构。它基于 struct packet_type 结构体，将不同的网络协议（如 IP、ARP、IPv6）与对应的处理函数关联起来。内核维护了两个全局链表/哈希表：

ptype_all：全局链表，用于接收所有网络数据包的协议处理程序。典型使用者包括 tcpdump、AF_PACKET 原始套接字。该链表中的处理程序会收到每个进入的数据包。
ptype_base：哈希表（大小为 16），以 skb->protocol（以太网类型）为键进行哈希。每个桶中维护一个链表，存储对应协议类型的处理程序。例如，ETH_P_IP (0x0800) 对应 IP 协议栈的入口 ip_rcv()。

数据结构	类型	作用域	典型注册者
ptype_all	链表	全局	AF_PACKET (SOCK_RAW), 抓包工具
ptype_base	哈希表 (16桶)	全局	ip_rcv, arp_rcv, ipv6_rcv 等

struct packet_type 的核心字段如下：

struct packet_type {
    __be16          type;       // 以太网协议类型 (如 ETH_P_IP)
    struct net_device *dev;     // 绑定的网络设备 (NULL 表示所有设备)
    int             (*func)(struct sk_buff *, struct net_device *,
                            struct packet_type *, struct net_device *);
    void            *af_packet_priv;
    struct list_head list;      // 链表节点
};

  调试技巧： 在 Android 内核中，可以使用 cat /proc/net/ptype 查看当前系统中所有注册的 packet_type 条目。这有助于确认某个协议处理程序是否已正确注册。例如，如果 ip_rcv 未出现在 ETH_P_IP 条目中，IP 数据包将无法被处理。

4.4 协议分发与驱动数据通路的关联

在 Android 内核网络栈中，驱动数据通路的优化与协议分发入口紧密相关。以下是几个关键的优化关联点：

NAPI 与 GRO 协同：驱动通过 NAPI 批量接收数据包，GRO 在驱动层合并相同流的数据包，减少 netif_receive_skb() 的调用次数，从而降低协议分发阶段的锁竞争和 CPU 开销。
RPS (Receive Packet Steering)：在 __netif_receive_skb_core() 之前，RPS 可以将数据包分发到不同的 CPU 核心进行处理，但需要确保 ptype_all 和 ptype_base 的访问是 RCU 安全的。
XDP (eXpress Data Path)：XDP 在驱动层更早的位置（甚至在分配 skb 之前）处理数据包，绕过整个协议栈入口。如果 XDP 返回 XDP_PASS，数据包才会进入 netif_receive_skb()。

优化建议： 在调试驱动数据通路时，建议在 netif_receive_skb() 入口处添加 tracepoint 或使用 perf 统计该函数的调用频率。如果发现每秒调用次数过高（例如超过 10 万次），应考虑启用 GRO 或调整 NAPI 的权重（netdev_budget）来合并数据包。

通过深入理解 netif_receive_skb() 到 __netif_receive_skb_core() 的完整流程，以及协议分发表的工作原理，开发者可以精准定位数据包从驱动到协议栈的瓶颈，从而在 Android 内核中实现高效的网络数据通路优化。