谢作者辛勤劳动
1 前言
本来是想翻译《 The journey of a packet through the linux 2.4network stack 》 这篇文章的。但在查阅相关的资料时，发现需要补充一些技术细节，才使得我这种菜鸟理解更加深刻，所以综合了上面两篇文档，在加上自己的裁减和罗嗦，就有了下面的文字。我不知道这是否侵犯了作者权益。如果有的话，请告知，我会及时删除这篇拼凑起来的文档。
引用作者 HaraldWelte 的话：我毫无疑问不是内核导师级人物，也许此文档的信息是错误的。所以不要对此期望太高了，我也感激你们的批评和指正。
这篇文档是基于 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.2softirq 和 bottom half
内核 2.4 以后，整个协议栈不再使用 bottomhalf （下半文，没找到好的翻译），而是被软中断 softirq 取代。软中断 softirq 优势明显，可以同时在多个 CPU 上执行；而 bottomhalf 一次只能在一个 CPU 上执行，即在多个 CPU 执行时严格保持串行。
中断服务程序往往都是在 CPU 关中断的条件下执行的，以避免中断嵌套而使控制复杂化。但是 CPU 关中断的时间不能太长，否则容易丢失中断信号。为此， Linux 将中断服务程序一分为二，各称作“ TopHalf ”和“ BottomHalf ”。前者通常对时间要求较为严格，必须在中断请求发生后立即或至少在一定的时间限制内完成。因此为了保证这种处理能原子地完成， TopHalf 通常是在 CPU 关中断的条件下执行的。具体地说， TopHalf 的范围包括：从在 IDT 中登记的中断入口函数一直到驱动程序注册在中断服务队列中的 ISR 。而 BottomHalf 则是 TopHalf 根据需要来调度执行的，这些操作允许延迟到稍后执行，它的时间要求并不严格，因此它通常是在 CPU 开中断的条件下执行的，比如网络底层操作就是这样，由于某些原因，中断并没有立刻响应，而是先记录下来，等到可以处理这些中断的时候就一块处理了。但是， Linux 的这种 BottomHalf （以下简称 BH ）机制有两个缺点，也即：（ 1 ）在任意一时刻，系统只能有一个 CPU 可以执行 BottomHalf 代码，以防止两个或多个 CPU 同时来执行 BottomHalf 函数而相互干扰。因此 BH 代码的执行是严格“串行化”的。（ 2 ） BH 函数不允许嵌套。这两个缺点在单 CPU 系统中是无关紧要的，但在 SMP 系统中却是非常致命的。因为 BH 机制的严格串行化执行显然没有充分利用 SMP 系统的多 CPU 特点。为此， Linux2.4 内核在 BH 机制的基础上进行了扩展，这就是所谓的“软中断请求”（ softirq ）机制。 Linux 的 softirq 机制是与 SMP 紧密不可分的。为此，整个 softirq 机制的设计与实现中自始自终都贯彻了一个思想：“谁触发，谁执行 ”（ Whomarks ， Whoruns ），也即触发软中断的那个 CPU 负责执行它所触发的软中断，而且每个 CPU 都由它自己的软中断触发与控制机制。这个设计思想也使得 softirq 机制充分利用了 SMP 系统的性能和特点。
2.3NET_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细节可以参考 Hackingthe Linux Kernel NetworkStack ）；否则，丢弃。到了 ip_rcv_finish() 函数，数据包就要根据 skb 结构的目的或路由信息各奔东西了。
- ip_local_deliver() 处理到本机的数据分组；
- ip_forward() 处理需要转发的数据分组；
- ip_mr_input() 转发组播数据包
至此，数据分组的接受和处理工作就告一段落了，至于于此相对的数据分组的发送，我就贴个图吧，具体细节可参考 The Linux® Networking Architecture: Design andImplementation of Network Protocols in the LinuxKernel Prentice Hall August 01, 2004
dev_queue_xmit() 处理发送分组
附一张 Linux2.4 核的 netfilter 框架下分组的走向图：
来自链接：
http://ftp.gnumonks.org/pub/doc/packet-journey-2.4.html
http://m.linuxjournal.com/article/4852
这篇文档描述了网络分组在 linux 内核 2.4 协议栈的处理过程。