NAPI 技术在 Linux 网络驱动上的应用和完善（Part 1）

NAPI 是 Linux 上采用的一种提高网络处理效率的技术，它的核心概念就是不采用中断的方式读取数据，而代之以 POLL 的方法来轮询数据，类似于底半方式（bottom-half 的处理模式）；但是目前在 Linux 的 NAPI 工作效率比较差，本文在分析 NAPI 的同时，提供了一种高效的改善方式供大家参考。

 

1.      前言：

NAPI 是 Linux 上采用的一种提高网络处理效率的技术，它的核心概念就是不采用中断的方式读取数据，而代之以首先采用中断唤醒数据接收的服务程序，然后 POLL 的方法来轮询数据，（类似于底半（bottom-half）处理模式）；从我们在实验中所得到的数据来看，在随着网络的接收速度的增加，NIC 触发的中断能做到不断减少，目前 NAPI 技术已经在网卡驱动层和网络层得到了广泛的应用，驱动层次上已经有 E1000 系列网卡，RTL8139 系列网卡，3c50X 系列等主流的网络适配器都采用了这个技术，而在网络层次上，NAPI 技术已经完全被应用到了著名的 netif_rx 函数中间，并且提供了专门的 POLL 方法--process_backlog 来处理轮询的方法；根据实验数据表明采用NAPI技术可以大大改善短长度数据包接收的效率，减少中断触发的时间；由于 RTL8139CP 是一种应用比较广泛的网络适配器，所以本文以其为例，说明了NAPI技术在网络适配器上的应用和基本原理。

 

但是 NAPI 存在一些比较严重的缺陷：而对于上层的应用程序而言，系统不能在每个数据包接收到的时候都可以及时地去处理它，而且随着传输速度增加，累计的数据包将会耗费大量的内存，经过实验表明在 Linux 平台上这个问题会比在 FreeBSD 上要严重一些；另外采用 NAPI 所造成的另外一个问题是对于大的数据包处理比较困难，原因是大的数据包传送到网络层上的时候耗费的时间比短数据包长很多（即使是采用 DMA 方式），所以正如前面所说的那样，NAPI 技术适用于对高速率的短长度数据包的处理，在本文的末尾提出了 NAPI 的改善方法，和实验数据。

2.      使用 NAPI 先决条件：

驱动可以继续使用老的 2.4 内核的网络驱动程序接口，NAPI 的加入并不会导致向前兼容性的丧失，但是 NAPI 的使用至少要得到下面的保证：

A.       要使用 DMA 的环形输入队列（也就是 ring_dma，这个在 2.4 驱动中关于 Ethernet 的部分有详细的介绍），或者是有足够的内存空间缓存驱动获得的包。

B.        在发送/接收数据包产生中断的时候有能力关断 NIC 中断的事件处理，并且在关断 NIC 以后，并不影响数据包接收到网络设备的环形缓冲区（以下简称 rx-ring）处理队列中。

NAPI 对数据包到达的事件的处理采用轮询方法，在数据包达到的时候，NAPI 就会强制执行dev->poll 方法。而和不象以前的驱动那样为了减少包到达时间的处理延迟，通常采用中断的方法来进行。

应当注意的是，经过测试如果 DEC Tulip 系列（DE21x4x芯片）以及 National Semi 的部分网卡芯片，的测试表明如果把从前中断处理的部分都改换用设备的 POLL 方法去执行，那么会造成轻微的延迟，因此在进行 MII（介质无关）的操作上就需要一些小小的诀窍,详见 mii_check_media的函数处理流程，本文不做详细讨论。

C.        有防止 NIC 队列中排队的数据包冲突的能力。

当关断发送/接收事件中断的时候，NAPI 将在 POLL 中被调用处理，由于 POLL 方法的时候，NIC 中断已经不能通知包到达，那么这个时候在如果在完成轮询，并且中断打开以后，会马上有一个 NIC 中断产生，从而触发一次 POLL 事件，这种在中断关断时刻到达的包我们称为"rotting"；这样就会在 POLL 机制和 NIC 中断之间产生一个竞争，解决的方法就是利用网卡的接收状态位，继续接收环形队列缓冲 rx-ring 中的数据，直到没有数据接收以后，才使能中断。

3.      锁定和防冲突机制：

1.SMP 的保证机制：保证同时只有一个处理器调用网络设备的 POLL 方法，因为我们将在下面看到同时只有一个处理器可以对调用 netif_rx_schedule 挂在 POLL 队列中的 NIC 设备调用POLL 方法。

2. 网络核心层（net core）调用设备驱动程序使用循环方式发送数据包，在设备驱动层接收数据包的时候完全无锁的接收，而网络核心层则同样要保证每次只有一个处理器可以使用软中断处理接收队列。

3. 在多个处理器对 NIC 的 rx-ring 访问的时刻只能发生在对循环队列调用关闭（close）和挂起（suspend）方法的时候（在这个时刻会试图清除接收循环队列）

4. 数据同步的问题（对于接收循环队列来说），驱动程序是不需要考虑的网络层上的程序已经把这些事情做完了。

5. 如果没有把全部的部分交给 POLL 方法处理，那么 NIC 中断仍然需要使能，接收链路状态发生变化和发送完成中断仍然和以前的处理步骤一样，这样处理的假设是接收中断是设备负载最大的的情况，当然并不能说这样一定正确。

4.      NAPI 提供的重要函数和数据结构和函数：

4.1.    核心数据结构：

struct softnet_data 结构内的字段就是 NIC 和网络层之间处理队列,这个结构是全局的，它从 NIC中断和 POLL 方法之间传递数据信息。其中包含的字段有：

 

 

struct softnet_data

{

       int throttle; /*为 1 表示当前队列的数据包被禁止*/

       int cng_level; /*表示当前处理器的数据包处理拥塞程度*/

       int avg_blog; /*某个处理器的平均拥塞度*/

       struct sk_buff_head input_pkt_queue; /*接收缓冲区的sk_buff队列*/

       struct list_head poll_list; /*POLL设备队列头*/

       struct net_device output_queue; /*网络设备发送队列的队列头*/

       struct sk_buff completion_queue; /*完成发送的数据包等待释放的队列*/

struct net_device backlog_dev; /*表示当前参与POLL处理的网络设备*/

};

4.2.    核心 API:

1． netif_rx_schedule(dev)

这个函数被中断服务程序调用，将设备的 POLL 方法添加到网络层次的 POLL 处理队列中去，排队并且准备接收数据包，在使用之前需要调用 netif_rx_reschedule_prep，并且返回的数为 1，并且触发一个 NET_RX_SOFTIRQ 的软中断通知网络层接收数据包。

2. netif_rx_schedule_prep(dev)

确定设备处于运行，而且设备还没有被添加到网络层的 POLL 处理队列中，在调用 netif_rx_schedule之前会调用这个函数。

3． netif_rx_complete(dev)

把当前指定的设备从 POLL 队列中清除，通常被设备的 POLL 方法调用，注意如果在 POLL 队列处于工作状态的时候是不能把指定设备清除的，否则将会出错。

5.      如何在8139CP使用NAPI：

从 POLL 方法的本质意义上来说就在于尽量减少中断的数目，特别在于大量的小长度的数据包的时候，减少中断，以达到不要让整个操作系统花费太多的时间在中断现场的保护和恢复上，以便把赢得的时间用来在我网络层上的处理数据的传输，例如在下面介绍的 8139CP 中断的处理过程中，目的就在于尽快把产生中断的设备挂在 poll_list，并且关闭接收中断，最后直接调用设备的POLL方法来处理数据包的接收,直到收到数据包收无可收，或者是达到一个时间片内的调度完成。

 

5.1.    RTL8139C+ 的数据接收环形缓冲队列：

RTL8139C+ 的接收方式是一种全新的缓冲方式，能显著的降低CPU接收数据造成的花费，适合大型的服务器使用，适合 IP,TCP,UDP 等多种方式的数据下载，以及连接 IEEE802.1P，802.1Q，VLAN等网络形式；在 8139CP 中分别有 64 个连续的接收/发送描述符单元，对应三个不同的环形缓冲队列--一个是高优先级传输描述符队列，一个是普通优先级传输符描述队列，一个是接收符描述队列，每个环形缓冲队列右 64 个4个双字的连续描述符组成，每个描述符有 4 个连续的双字组成，每个描述符的开始地址在 256 个字节的位置对齐，接收数据之前，软件需要预先分配一个 DMA 缓冲区，一般对于传输而言，缓冲区最大为 8Kbyte 并且把物理地址链接在描述符的 DMA 地址描述单元，另外还有两个双字的单元表示对应的 DMA 缓冲区的接收状态。

 

在 /driver/net/8139CP.C 中对于环形缓冲队列描述符的数据单元如下表示：

struct cp_desc {
    u32 opts1;/*缓冲区状态控制符，包含缓冲区大小，缓冲区传输启动位*/
    u32 opts2;/*专门用于VLAN部分*/
     u64 addr; /*缓冲区的DMA地址*/
 };