概述

　　对于网络的行为，可以简单划分为 3 条路径：1) 发送路径，2) 转发路径，3) 接收路径，而网络性能的优化则可基于这 3 条路径来考虑。由于数据包的转发一般是具备路由功能的设备所关注，在本文中没有叙述，读者如果有兴趣，可以自行学习(在 Linux 内核中，分别使用了基于哈希的路由查找和基于动态 TrIE 的路由查找算法)。本文集中于发送路径和接收路径上的优化方法分析，其中的 NAPI 本质上是接收路径上的优化，但因为它在 Linux 的内核出现时间较早，而它也是后续出现的各种优化方法的基础，所以将其单独分析。

　　最为基本的 NAPI

　　NAPI

　　NAPI 的核心在于：在一个繁忙网络，每次有网络数据包到达时，不需要都引发中断，因为高频率的中断可能会影响系统的整体效率，假象一个场景，我们此时使用标准的 100M 网卡，可能实际达到的接收速率为 80MBits/s，而此时数据包平均长度为 1500Bytes，则每秒产生的中断数目为：

　　80M bits/s / (8 Bits/Byte * 1500 Byte) = 6667 个中断 /s

　　每秒 6667 个中断，对于系统是个很大的压力，此时其实可以转为使用轮询 (polling) 来处理，而不是中断;但轮询在网络流量较小的时没有效率，因此低流量时，基于中断的方式则比较合适，这就是 NAPI 出现的原因，在低流量时候使用中断接收数据包，而在高流量时候则使用基于轮询的方式接收。

　　现在内核中 NIC 基本上已经全部支持 NAPI 功能，由前面的叙述可知，NAPI 适合处理高速率数据包的处理，而带来的好处则是：

　　中断缓和 (Interrupt mitigation)，由上面的例子可以看到，在高流量下，网卡产生的中断可能达到每秒几千次，而如果每次中断都需要系统来处理，是一个很大的压力，而 NAPI 使用轮询时是禁止了网卡的接收中断的，这样会减小系统处理中断的压力

　　数据包节流 (Packet throttling)，NAPI 之前的 Linux NIC 驱动总在接收到数据包之后产生一个 IRQ，接着在中断服务例程里将这个 skb 加入本地的 softnet，然后触发本地 NET_RX_SOFTIRQ 软中断后续处理。如果包速过高，因为 IRQ 的优先级高于 SoftIRQ，导致系统的大部分资源都在响应中断，但 softnet 的队列大小有限，接收到的超额数据包也只能丢掉，所以这时这个模型是在用宝贵的系统资源做无用功。而 NAPI 则在这样的情况下，直接把包丢掉，不会继续将需要丢掉的数据包扔给内核去处理，这样，网卡将需要丢掉的数据包尽可能的早丢弃掉，内核将不可见需要丢掉的数据包，这样也减少了内核的压力

　　对 NAPI 的使用，一般包括以下的几个步骤：

　　在中断处理函数中，先禁止接收中断，且告诉网络子系统，将以轮询方式快速收包，其中禁止接收中断完全由硬件功能决定，而告诉内核将以轮询方式处理包则是使用函数 netif_rx_schedule()，也可以使用下面的方式，其中的 netif_rx_SChedule_prep 是为了判定现在是否已经进入了轮询模式 :：

　　清单 1、将网卡预定为轮询模式

　　void netif_rx_schedule(struct net_device *dev); 或者 if (netif_rx_schedule_prep(dev)) __netif_rx_SChedule(dev);

　　在驱动中创建轮询函数，它的工作是从网卡获取数据包并将其送入到网络子系统。