Linux网络协议栈之数据包处理过程 [转]

转贴于 http://blog.csdn.net/wangxing1018/archive/2009/05/29/4224129.aspx

感谢作者辛勤劳动

1 前言

本来是想翻译  这篇文章的。但在查阅相关的资料时，发现需要补充一些技术细节，才使得我这种菜鸟理解更加深刻，所以综合了上面两篇文档，在加上自己的裁减和罗嗦，就有了下面的文字。我不知道这是否侵犯了作者权益。如果有的话，请告知，我会及时删除这篇拼凑起来的文档。

引用作者 Harald Welte 的话：我毫无疑问不是内核导师级人物，也许此文档的信息是错误的。所以不要对此期望太高了，我也感激你们的批评和指正。

这篇文档是基于 x86 体系结构和转发 IP 分组的。

 

 

 

数据包在 Linux 内核链路层路径

2 接收分组 2.1 接收中断

如果网卡收到一个和自己 MAC 地址匹配或链路层广播的以太网帧，它就会产生一个中断。此网卡的驱动程序会处理此中断：

• 从 DMA/PIO 或其他得到分组数据，写到内存里去；

•   接着，会分配一个新的套接字缓冲区 skb ，并调用与协议无关的、网络设备均支持的通用网络接收处理函数 netif_rx(skb) 。 netif_rx() 函数让内核准备进一步处理 skb 。

• 然后， skb 会进入到达队列以便 CPU 处理（对于多核 CPU 而言，每个 CPU 维护一个队列）。如果 FIFO 队列已满，就会丢弃此分组。在 skb 排队后，调用 __cpu_raise_softirq() 标记 NET_RX_SOFTIRQ 软中断，等待 CPU 执行。

•   至此， netif_rx() 函数调用结束，返回调用者状况信息（成功还是失败等）。此时，中断上下文进程完成任务，数据分组继续被上层协议栈处理。

2.2 softirq 和 bottom half

内核 2.4 以后，整个协议栈不再使用 bottom half （下半文，没找到好的翻译），而是被软中断 softirq 取代。软中断 softirq 优势明显，可以同时在多个 CPU 上执行；而 bottom half 一次只能在一个 CPU 上执行，即在多个 CPU 执行时严格保持串行。

中断服务程序往往都是在 CPU 关中断的条件下执行的，以避免中断嵌套而使控制复杂化。但是 CPU 关中断的时间不能太长，否则容易丢失中断信号。为此， Linux 将中断服务程序一分为二，各称作“ Top Half ”和“ Bottom Half ”。前者通常对时间要求较为严格，必须在中断请求发生后立即或至少在一定的时间限制内完成。因此为了保证这种处理能原子地完成， Top Half 通常是在 CPU 关中断的条件下执行的。具体地说， Top Half 的范围包括：从在 IDT 中登记的中断入口函数一直到驱动程序注册在中断服务队列中的 ISR 。而 Bottom Half 则是 Top Half 根据需要来调度执行的，这些操作允许延迟到稍后执行，它的时间要求并不严格，因此它通常是在 CPU 开中断的条件下执行的，比如网络底层操作就是这样，由于某些原因，中断并没有立刻响应，而是先记录下来，等到可以处理这些中断的时候就一块处理了。但是， Linux 的这种 Bottom Half （以下简称 BH ）机制有两个缺点，也即：（ 1 ）在任意一时刻，系统只能有一个 CPU 可以执行 Bottom Half 代码，以防止两个或多个 CPU 同时来执行 Bottom Half 函数而相互干扰。因此 BH 代码的执行是严格“串行化”的。（ 2 ） BH 函数不允许嵌套。这两个缺点在单 CPU 系统中是无关紧要的，但在 SMP 系统中却是非常致命的。因为 BH 机制的严格串行化执行显然没有充分利用 SMP 系统的多 CPU 特点。为此， Linux2.4 内核在 BH 机制的基础上进行了扩展，这就是所谓的“软中断请求”（ softirq ）机制。 Linux 的 softirq 机制是与 SMP 紧密不可分的。为此，整个 softirq 机制的设计与实现中自始自终都贯彻了一个思想：“谁触发，谁执行 ”（ Who marks ， Who runs ），也即触发软中断的那个 CPU 负责执行它所触发的软中断，而且每个 CPU 都由它自己的软中断触发与控制机制。这个设计思想也使得 softirq 机制充分利用了 SMP 系统的性能和特点。

2.3 NET_RX_SOFTIRQ 网络接收软中断

这两篇文档描述的各不相同，侧重不一。在这里，只好取重避轻。

这一阶段会根据协议的不同来处理数据分组。 CPU 开始处理软中断 do_softirq() ，，接着 net_rx_action() 处理前面标记的 NET_RX_SOFTIRQ ，把出对列的 skb 送入相应列表处理（根据协议不同到不同的列表）。比如， IP 分组交给 ip_rcv() 处理， ARP 分组交给 arp_rcv() 处理等。

 

 

2.4 处理 IPv4 分组

下面以 IPv4 为例，讲解 IPv4 分组在高层的处理。

 

 

linux 内核协议栈之网络层

ip_rcv() 函数验证 IP 分组，比如目的地址是否本机地址，校验和是否正确等。若正确，则交给 netfilter 的 NF_IP_PRE_ROUTING 钩子（关于netfilter细节可以参考  ）；否则，丢弃。到了 ip_rcv_finish() 函数，数据包就要根据 skb 结构的目的或路由信息各奔东西了。

•   ip_local_deliver() 处理到本机的数据分组；

• ip_forward() 处理需要转发的数据分组；

• ip_mr_input() 转发组播数据包

至此，数据分组的接受和处理工作就告一段落了，至于于此相对的数据分组的发送，我就贴个图吧，具体细节可参考 

 

 

dev_queue_xmit() 处理发送分组

 

附一张 Linux 2.4 核的 netfilter 框架下分组的走向图：

 

来自链接：    

这篇文档描述了网络分组在 linux 内核 2.4 协议栈的处理过程。