2、Linux网络栈概述：数据包从网卡到应用层的路径、中断与轮询的权衡
理解数据包从物理网卡到达用户态应用的全路径，是配置NAPI与中断亲和性的前提。本章将拆解Linux网络栈的核心层次，并分析中断驱动与轮询驱动两种模型的设计权衡。
2.1 数据包接收全路径：从网卡到Socket
一个网络数据包从硬件到达应用层，需要经过以下关键阶段：
- 硬件接收：网卡（NIC）通过DMA将数据包写入主存中的Ring Buffer。
- 中断通知：网卡触发硬件中断（IRQ），通知CPU有新的数据包到达。
- 中断处理（上半部）：中断处理程序快速记录设备状态，并调度软中断（SoftIRQ）。
- 软中断处理（下半部）：执行
net_rx_action，从Ring Buffer中取出数据包构造sk_buff。 - 协议栈处理：数据包依次经过链路层（bridge）、网络层（IP/Netfilter）、传输层（TCP/UDP）。
- Socket排队：数据包被放入对应Socket的接收队列。
- 用户态读取：应用通过
read()、recv()或epoll唤醒，从内核拷贝数据到用户空间。
关键指标：在10Gbps线速下，每秒钟可能产生超过1400万个数据包（64字节小包）。这意味着内核必须在微秒级内完成每个数据包的处理，否则将发生丢包。
2.2 中断与轮询：两种驱动模型的权衡
Linux网络驱动历史上经历了从纯中断到中断+轮询混合的演进。核心矛盾在于：高吞吐场景下，中断本身会成为瓶颈。
| 特性 | 纯中断模式 (传统) | NAPI (中断+轮询) |
|---|---|---|
| 触发方式 | 每个数据包触发一次硬件中断 | 首个数据包触发中断，后续进入轮询 |
| CPU开销 | 高（频繁上下文切换、Cache污染） | 低（批量处理，减少中断次数） |
| 小包吞吐 | 差（中断风暴导致活锁） | 优（批量收包，分摊中断开销） |
| 延迟 | 低（数据包到达立即响应） | 略高（需等待轮询周期） |
| 适用场景 | 低吞吐、延迟敏感 | 高吞吐、通用场景 |
NAPI核心思想：在数据包到达速率较低时，使用中断获得最低延迟；当速率升高时，自动切换为轮询模式，避免中断风暴。这种自适应机制是现代高速网卡驱动的标配。
2.3 中断风暴与活锁问题
在纯中断模式下，当网络流量激增时，CPU可能陷入“中断→处理一个包→再中断”的死循环，导致：
- 用户态进程饿死：CPU时间全部被中断处理程序占用。
- Cache抖动：频繁中断导致L1/L2 Cache命中率急剧下降。
- 吞吐量归零：系统虽然100%忙碌，但实际收包速率反而下降。
NAPI通过以下机制解决活锁：
- 中断关闭：进入轮询后，驱动关闭该设备的硬件中断。
- 批量收包：在单次轮询中从Ring Buffer取出多个数据包（预算控制）。
- 退出条件：当收包数量达到预算（如
netdev_budget，默认300）或Ring Buffer为空时，重新开启中断。
2.4 NAPI的关键参数与调优方向
NAPI的行为由内核参数控制，理解这些参数是后续配置亲和性的基础：
| 参数 | 默认值 | 作用 | 调优建议 |
|---|---|---|---|
netdev_budget |
300 | 单次轮询最大收包数 | 高吞吐场景可增至600-1200 |
netdev_budget_usecs |
2000 (µs) | 单次轮询最大耗时 | 延迟敏感场景可降低至500 |
gro_flush_timeout |
0 (关闭) | GRO合并超时时间 | 高延迟链路可设为10000ns |
rps_flow_cnt |
0 (关闭) | RPS流表大小 | 多队列场景建议设为4096 |
调优警告：盲目增大
netdev_budget 可能导致单次轮询耗时过长，增加其他设备的网络延迟。建议配合 netdev_budget_usecs 做双重限制，优先保证CPU时间片的公平分配。
2.5 本章小结
数据包从网卡到应用层的路径涉及硬件DMA、中断处理、软中断、协议栈和Socket排队等多个阶段。NAPI通过中断+轮询的混合模型，在高吞吐场景下避免了中断风暴和活锁问题。理解这条路径上的每个瓶颈点，是后续配置中断亲和性、优化CPU缓存局部性的前提。