Linux网络协议栈接收（RX）报文处理流程是一个从硬件中断到应用层Socket的复杂过程，其核心在于通过软中断和NAPI机制在中断上下文和内核进程上下文之间取得平衡，以实现高吞吐量。整个过程可以概括为：硬件中断触发 -> 软中断调度 -> 协议栈逐层解析 -> 交付Socket队列。
以下将分阶段详细解析其源码级流程，并辅以关键数据结构和函数调用链说明。
一、 核心数据结构与处理模型
在深入流程前，需理解两个核心概念：
sk_buff(Socket Buffer)：贯穿整个网络栈的统一报文容器。它通过head,data,tail,end指针管理报文数据和各层协议头，并携带元数据（如网络设备dev、协议protocol、路由信息skb->rtable）。- NAPI (New API)：现代网卡驱动使用的混合中断与轮询机制。其核心是
struct napi_struct，它包含一个待处理报文队列(poll_list)和轮询函数(poll)。NAPI在高速流量下禁用中断，转为内核主动轮询，大幅减少中断开销。
二、 RX报文处理详细流程
阶段1：网卡接收与中断处理（硬中断上下文）
- DMA与描述符环：网卡通过DMA将接收到的数据帧直接写入内核预留的环形缓冲区(Ring Buffer)，并更新接收描述符（包含帧地址、长度、状态）。
- 硬件中断触发：当网卡收到帧、DMA完成或描述符环达到一定水位时，触发硬件中断（IRQ）。
- 中断处理函数：内核调用网卡驱动注册的中断处理函数（如
e1000_intr）。该函数的核心任务是：- 禁用该网卡进一步的中断，避免中断风暴。
- 调度NAPI轮询，将设备的
napi_struct加入到当前CPU的poll_list中。 - 触发软中断
NET_RX_SOFTIRQ，通知内核在稍后的软中断上下文中进行报文处理。
// 以E1000驱动为例的中断处理函数简化逻辑 static irqreturn_t e1000_intr(int irq, void *data) { struct net_device *netdev = data; struct e1000_adapter *adapter = netdev_priv(netdev); struct e1000_hw *hw = &adapter->hw; // 1. 读取中断原因寄存器，确认是接收中断 u32 icr = er32(ICR); if (!(icr & E1000_ICR_RXT0)) return IRQ_NONE; // 不是接收中断，直接返回 // 2. 禁用该网卡的中断，防止新的中断干扰 e1000_irq_disable(adapter); // 3. 调度NAPI轮询。`&adapter->napi`是设备的napi_struct if (likely(napi_schedule_prep(&adapter->napi))) { __napi_schedule(&adapter->napi); // 将napi加入当前CPU的poll_list } return IRQ_HANDLED; } // 此函数执行在中断上下文，必须快速返回。阶段2：软中断与NAPI轮询（软中断上下文）
硬件中断返回后，内核会在一个更安全、可延迟的软中断上下文中执行实际的报文处理。
- 软中断入口：内核执行
net_rx_action()函数来处理NET_RX_SOFTIRQ软中断。 - 轮询设备：
net_rx_action()循环遍历当前CPU的poll_list，对每个设备的NAPI结构调用其注册的poll()方法（如e1000_clean）。 - 从环缓冲区取包：驱动的
poll()函数执行以下操作：- 读取描述符环，确认哪些描述符已被DMA填充（即已收到包）。
- 为每个收到的数据帧分配一个新的
sk_buff（skb）结构。 - 将DMA缓冲区中的数据映射或拷贝到
skb中。 - 将
skb递交给上层网络栈，通常通过napi_gro_receive()或netif_receive_skb()函数。 - 清理并回收描述符，将其重新交给网卡用于下一次DMA。
- 预算与时间限制：
net_rx_action()有时间预算（netdev_budget）和时间限制。它会持续处理报文，直到处理数量超过预算或执行时间过长，以确保软中断不会独占CPU。未处理完的设备会留在poll_list中，等待下次软中断调用。
// net_rx_action 函数的核心逻辑简化 static void net_rx_action(struct softirq_action *h) { struct softnet_data *sd = &__get_cpu_var(softnet_data); unsigned long time_limit = jiffies + 2; // 时间限制 int budget = netdev_budget; // 默认预算300 LIST_HEAD(list); LIST_HEAD(repoll); // 将当前CPU的poll_list转移到本地list，避免并发问题 list_splice_init(&sd->poll_list, &list); while (!list_empty(&list)) { struct napi_struct *n; int work, weight; n = list_first_entry(&list, struct napi_struct, poll_list); weight = n->weight; work = 0; if (test_bit(NAPI_STATE_SCHED, &n->state)) { // 调用设备驱动的poll方法 work = n->poll(n, weight); // 例如 e1000_clean trace_napi_poll(n); } budget -= work; // 检查：1. poll函数消耗了全部权重(weight)？ 2. 预算超了？ 3. 时间到了？ if (work < weight || budget <= 0 || time_after(jiffies, time_limit)) { // 将未处理完的设备放入repoll列表 list_move_tail(&n->poll_list, &repoll); } else { // 该设备本轮处理完毕，从列表中移除 list_del_init(&n->poll_list); // 如果设备需要重新启用中断，则启用之 if (test_bit(NAPI_STATE_DISABLE, &n->state)) ____napi_complete(n); else napi_complete(n); } if (budget <= 0 || time_after(jiffies, time_limit)) break; } // 将需要重新轮询的设备重新加回sd->poll_list list_splice_tail(&repoll, &sd->poll_list); // 如果poll_list不为空，说明还有工作，再次触发软中断 if (!list_empty(&sd->poll_list)) __raise_softirq_irqoff(NET_RX_SOFTIRQ); }阶段3：协议栈分发与处理（进程上下文）
skb通过netif_receive_skb()或napi_gro_receive()（支持GRO卸载时）进入协议无关的接收路径。
- RPS处理：如果内核配置了RPS（Receive Packet Steering），可能会在此处将
skb转移到其他CPU的 backlog 队列，以实现负载均衡。 - 协议分发：
__netif_receive_skb_core()是核心分发函数。它主要做两件事：- 处理Tap设备：如果有Tap设备（如用于虚拟机或抓包）监听，会克隆一份
skb发送给它们。 - 协议类型分发：根据
skb->protocol字段（如ETH_P_IP、ETH_P_ARP），调用相应的协议处理函数。这是通过遍历ptype_all和ptype_base哈希表实现的。
- 处理Tap设备：如果有Tap设备（如用于虚拟机或抓包）监听，会克隆一份
// 协议分发核心逻辑示意 (net/core/dev.c) static int __netif_receive_skb_core(struct sk_buff *skb, bool pfmemalloc) { // ... 省略RPS、Tap处理等 ... // 获取二层协议类型 type = skb->protocol; // 遍历协议处理程序链表 list_for_each_entry_rcu(ptype, &ptype_base[ntohs(type) & PTYPE_HASH_MASK], list) { if (ptype->type == type && (ptype->dev == null_or_dev || ptype->dev == skb->dev)) { if (pt_prev) ret = deliver_skb(skb, pt_prev, orig_dev); // 交付给上一个协议处理程序 pt_prev = ptype; } } // ... 交付最后一个匹配的协议处理程序 ... } // 对于IP报文，`ptype->func` 指向 `ip_rcv()` 函数。网络层处理：以IP协议为例，
ip_rcv()函数接收skb。- 完整性检查：校验IP头部校验和、版本、长度等。
- 路由决策：调用
ip_rcv_finish()->ip_route_input_noref()。路由子系统根据目标IP地址决定报文去向：- 本机接收：目标IP是本机IP，报文上传给传输层。
- 转发：目标IP是其他主机，且本机开启了IP转发，报文进入转发路径。
- 丢弃：不符合任何条件。
- 本机接收路径：对于本机报文，调用
ip_local_deliver()。如果报文是分片，则在此进行重组（ip_defrag()）。最后，根据IP头中的协议字段（如IPPROTO_TCP,IPPROTO_UDP），调用ipprot->handler，即传输层入口函数（如tcp_v4_rcv()或udp_rcv()）。
传输层处理：以TCP为例，
tcp_v4_rcv()函数处理。- 查找对应的
struct sock（通过IP和端口号在哈希表中查找）。 - 进行复杂的TCP状态机处理（序列号、ACK、窗口管理等）。
- 将排好序、已确认的数据放入对应Socket的接收缓冲区（
sk->sk_receive_queue）。
- 查找对应的
阶段4：应用层读取
- 用户态进程调用
read(),recv()等系统调用。 - 内核的
sys_recv()陷入内核，最终调用到Socket对应的struct proto中的recvmsg方法（如tcp_recvmsg）。 tcp_recvmsg()从sock的接收队列（sk_receive_queue）中拷贝数据到用户态缓冲区。- 如果接收队列为空，且Socket是阻塞的，则进程将进入睡眠状态，等待数据到来。
三、 关键机制：GRO与RPS
- GRO (Generic Receive Offload)：在
napi_gro_receive()中，内核尝试将多个相似的数据包（如属于同一个TCP流）合并成一个大的skb，然后再提交给协议栈。这极大地减少了协议栈的处理开销，是提升吞吐量的关键技术。 - RPS (Receive Packet Steering)：纯软件实现的接收多队列。在
netif_receive_skb()中，根据数据包的哈希值（如四元组）选择一个目标CPU，将skb排入该CPU的softnet_data->input_pkt_queue。随后通过进程间中断(IPI)唤醒目标CPU的软中断来处理它。这可以将接收负载分摊到多个CPU核心，尤其对单队列网卡有益。
四、 流程图与总结
整个RX流程可以总结为下表所示的层级与上下文转换：
| 处理阶段 | 执行上下文 | 关键函数/动作 | 核心数据结构 |
|---|---|---|---|
| 硬件收包 | 硬件/DMA | 网卡DMA到Ring Buffer | 描述符环(Descriptor Ring) |
| 中断触发 | 硬中断 | e1000_intr() | struct net_device,struct napi_struct |
| 调度轮询 | 硬中断 | napi_schedule(), 触发NET_RX_SOFTIRQ | softnet_data->poll_list |
| NAPI轮询 | 软中断 | net_rx_action()-> 驱动poll()(如e1000_clean) | sk_buff |
| 协议分发 | 软中断 | netif_receive_skb()->__netif_receive_skb_core() | sk_buff(protocol字段) |
| 网络层 | 软中断 | ip_rcv()->ip_local_deliver() | sk_buff, 路由表 |
| 传输层 | 软中断 | tcp_v4_rcv()/udp_rcv() | struct sock,sk_receive_queue |
| Socket交付 | 进程上下文 | tcp_recvmsg()拷贝数据到用户空间 | 用户缓冲区 |
总结：Linux网络RX路径是一个精心设计的分层、异步流水线。它通过硬中断快速响应，通过NAPI和软中断批量处理来平衡延迟与吞吐量，通过协议分发器将报文准确送达各层处理函数，最终通过Socket接口服务于应用程序。理解sk_buff的生命周期和NAPI的调度机制是剖析此流程的关键。
参考来源
- linux网络报文接收发送浅析
- Linux 网络协议栈开发代码分析篇之数据收发（一） —— netif_receive_skb()函数
- Linux 网络协议栈如何收发数据包
- Linux 内核的网络协议栈
- Linux 内核的网络协议栈
- Linux网络协议栈：NAPI机制与处理流程分析（图解）
