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

在转载其它文章前，先总结一下自已理解的NAPI及netif_rx处理过程。

为什么要用NAPI，因为随着网卡数据传输速率的提高，10M、100M到1G，传统的处理方式是每收到一个数据包就产生一次中断，当速率为1G时，每秒内产生的中断数足以将CPU拖垮。

引入NAPI的目的就是在高速传输时，极大的降低中断数量，也就是说采用POLL轮循的方式处理数据包。

NAPI的实现包括两个部分：

1。Linux内核，在netif_rx可以看到，其将每个对列的backlog_dev加入到poll_list，其做法与NAPI一样

2。NIC驱动层，可以采用旧的基于中断的方式，也可以使用NAPI将NIC对应的dev加入到poll list,后者不再调用netif_rx（若是VLAN包，去除VLAN头后会进netif_rx处理）

-------------------------------------------------------------------------------------------

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.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的函数处理流程，本文不做详细讨论。

在下面显示的例子表示了在 8139 中如何把处理过程放在 dev 的 poll 方法中，把所有的原来中断应该处理的过程放在了 POLL 方法里面，篇幅起见，我们只介绍接收的 POLL 方法。

在下面的 8139CP 驱动程序介绍中表明了可以把在中断程序中所做的任何事情放在 POLL 方法中去做，当然不同的 NIC 在中断中所要处理的状态和事件是不一样的。

对于所有的 NIC 设备，以下两种类型的 NIC 接收事件寄存器响应机制：

1. COR 机制：当用户程序读状态/事件寄存器，读完成的时候寄存器和NIC的rx-ring中表示的状态队列将被清零，natsemi 和 sunbmac 的 NIC 会这样做，在这种情况下，必须把 NIC 所有以前的中断响应的处理部分都移动到 POLL 方法中去。
2. COW 机制：用户程序写状态寄存器的时候，必须对要写的位先写 1 清 0，如下面要介绍的 8139CP 就是这样的类型，大多数的 NIC 都属于这种类型，而且这种类型对 NAPI 响应得最好，它只需要把接收的数据包处理部分放置在 POLL 方法中，而接收事件的状态处理部分放在原先的中断控制程序中,我们等下将要介绍的 8139CP 类型网卡就是属于这种类型。

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

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

回页首

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

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

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

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

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

下面的部分将详细介绍在接收事件中调用设备的 POLL 方法。

回页首

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处理的网络设备*/
};


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 队列处于工作状态的时候是不能把指定设备清除的，否则将会出错。

 

 

其余内容参考原文