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

NAPI 是 Linux 上采用的一种提高网络处理效率的技术，它的核心概念就是不采用中断的方式读取数据，而代之以 POLL 的方法来轮询数据，类似于底半方式（bottom-half 的处理模式）；但是目前在 Linux 的 NAPI 工作效率比较差，本文在分析 NAPI 的同时，提供了一种高效的改善方式供大家参考。 　　前言： 　　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 的改善方法，和实验数据。 　　使用 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 接收事件寄存器响应机制： 　　 COR 机制：当用户程序读状态/事件寄存器，读完成的时候寄存器和NIC的rx-ring中表示的状态队列将被清零，natsemi 和 sunbmac 的 NIC 会这样做，在这种情况下，必须把 NIC 所有以前的中断响应的处理部分都移动到 POLL 方法中去。 　　 COW 机制：用户程序写状态寄存器的时候，必须对要写的位先写 1 清 0，如下面要介绍的 8139CP 就是这样的类型，大多数的 NIC 都属于这种类型，而且这种类型对 NAPI 响应得最好，它只需要把接收的数据包处理部分放置在 POLL 方法中，而接收事件的状态处理部分放在原先的中断控制程序中,我们等下将要介绍的 8139CP 类型网卡就是属于这种类型。 　　C． 有防止 NIC 队列中排队