能让接收速度更快一些吗？ 我们现在来思考一下如何提高 NAPI 效率的问题，在说到效率这个问题之前我们先看一下在Linux 的文档中 NAPI_HOWTO.txt 中提供一个模型用来构造自己 NIC 的 POLL 方法，不过和 8139 有一些不一样，其中 NIC 设备描述中有一个 dirty_rx 字段是在 8139CP 中没有使用到的。 dirty_rx 就是已经开辟了 sk_buff 缓冲区指针和已经提交到 NIC 的 rx_ring 参与接收的缓冲，但是还没有完成传输的缓冲区和已经完成传输的缓冲区的数量总和，与之相类似的是 cur_rx 这个表示的是下一个参与传输的缓冲区指针，我们在 NAPI_HOWTO.txt 的举例中可以看到这个字段的一些具体使用方式： /*cur_rx为下一个需要参与传输的缓冲区指针，如果cur_rx指针大于dirty_rx那么表示已经有在rx-ring中开辟的rx-ring中的每个传输缓冲已经被耗尽了，这个时候需要调用refill_rx_ring 把一些已经向网络层提交了数据的rx-ring接收单元开辟新的缓冲区，增加dirty_rx的数值，为下一次数据接收做准备，*/ if (tp->cur_rx - tp->dirty_rx > RX_RING_SIZE/2 tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) refill_rx_ring(dev); /*如果已经当前的cur_rx和dirty_rx之间相差不超过总的rx_ring接收单元的一半，而且剩下的一半中间有空的传输单元，那么我们不必担心了，因为还有足够的缓冲区可以使用（凭经验推断的），就可以退出当前的程序，等待下一次软中断调用POLL来处理在这之间收到的数据，（NAPI_HOWTO.txt中是重新启动时钟计数，这样做是在没有使能NIC中断处理的情况下）*/ if (tp->rx_buffers[tp->dirty_rx % RX_RING_SIZE].skb == NULL) restart_timer(); /*如果执行到这里了，那表示有几种情况可能发生，第一当前的cur_rx和dirty_rx之间相差不超过总的rx_ring接收单元的一半，调用refill_rx_ring后dirty_rx并未增加，（也许在rx-ring中大量的单元收到数据没有得到网络层函数的处理），结果dirty_rx没有增加，而且也没有空闲的单元来接收新到的数据，这样就要重新调用netif_rx_schedule 来唤醒软中断，调用设备的POLL方法，采集在rx-ring的数据。*/ else netif_rx_schedule(dev); /* we are back on the poll list */ 在 RTL-8169 的驱动程序中就使用了 dirty_rx 这个字段，但是在 8139CP 中并未使用，其实这个并非 8139CP 驱动不成熟的表现，大家阅读 NAPI_HOWTO.txt 中可以知道，现在 8139CP 中并未严格按照 NAPI 所提出的要求去做，如果大家有兴趣的话，可以比较一下 8139CP 和 RTL-8169 这两个驱动之间的不同，大家会发现虽然两者都没有在 NIC 中断处理中去完成数据从驱动层向网络层上的转发，而都放在了软中断之中完成，但是在 8139 中利用了自己的一些独特的硬件特性，使 NIC 在利用关断中断接收数据的同时利用数据包到达位（RxOK）通知到达事件，然后采用 POLL 方法把数据从 NIC 直接转发到上层；而 RTL8169 还需要借助 softnet_data 结构中的 input_pkt_queue（套接字缓冲（sk_buff）输入队列）来完成从 NIC 中断到软中断之间的 sk_buff 数据调度；这样对于 8139CP 来说最大的好处就是不要了 dirty_rx 字段和 cur_rx 字段来让 POLL 方法以及 NIC 中断知道当前的传输单元的状况，还包括不需要不时定期的调用 refill_rx_ring 来刷新 rx-ring 获得空闲的传输单元；说到坏处我想就是重写了一个 POLL 方法，完全不能借用 /net/core/dev.c 中的 process_backlog 来作为自己的POLL方法，不过这个代价值得。 说了这么多，似乎都和提高效率没有关系，其实正好相反，通过这些了解我们对 softnet_data中的一些字段的意思应该更加清晰了，下面所叙述的，提高效率的方法就是在 8139CP 的基础上借用了 NAPI_ HOWTO.txt 中的一些方法，从实际上的使用效果来看，在某些应用场合之下比 Linux的 8139CP 的确是有了一定的提高，我们首先看看在 Linux2.6.6 的内核使用 8139CP 在x86(PIII-900Mhz)平台上的数据包接收处理情况：比较表如下： Psize Ipps Tput Rxint Done ---------------------------------------------------- 60 490000 254560 21 10 128 358750 259946 27 11 256 334454 450034 34 18 512 234550 556670 201239 193455 1024 119061 995645 884526 882300 1440 74568 995645 995645 987154 上表中表示： "Pszie"表示包的大小 "Ipps" 每秒钟系统可以接收的包数量 "Tput" 每次POLL超过 1M 个数据包的总量 "Rxint" 接收中断数量 "Done" 载入 rx-ring 内数据所需要的 POLL 次数，这个数值也表示了我们需要清除 rx-ring 的次数。 从上表可以看出，8139CP 中当接收速率达到 490K packets/s 的时候仅仅只有 21 个中断产生，只需要 10 次 POLL 就可以完成数据从 rx_ring 的接收，然而对于大数据包低速率的情况，接收中断就会急剧增加，直到最后每个数据包都需要一次 POLL 的方法来进行处理，最后的结果就是每个中断都需要一次 POLL 的方法，最后造成效率的急剧下降，以至于系统的效率就会大大降低，所以 NAPI 适用于大量的数据包而且尽可能是小的数据包，但是对于大的数据包，而且低速率的，反而会造成系统速度的下降。 如果要改善这种情况，我们可以考虑采用以下的方法，我们在 MIPS，Xsacle 和 SA1100 平台上进行一系列的测试取得了良好的效果： 1． 完全取消 NIC 中断，使用 RXOK 位置控制接收中断。 2． 采用定时器中断 timer_list 的控制句柄，根据硬件平台设定一个合适的间隔周期（间隔周期依据平台不同而异），对 rx-ring 直接进行 POLL 轮询，我们在 MIPS 和 Xscale 上直接使用了中断向量 0--irq0 作为对 rx-ring 进行轮询的 top-half（注意我们在上述两个平台上选择的 HZ 数值是 1000,而通常这个数值是 100，并且重新编写了 Wall-time 的记数程序，让 Wall-Time 的记数还是以 10MS 为间隔），当然也可以根据自己的平台和应用程序的状况选择合适的定时时间。 3． 借助 softnet_data 中的 input_pkt_queue 队列，在时钟中断 bottom-half 中完成 POLL 方法之后，并不直接把数据传输到网络层进行处理，而是把 sk_buff 挂在 input_pkt_queue队列上，唤醒软中断在过后处理，当然可以想象，这样需要付出一定的内存代价，而且实时性能也要差一些。 4． 使用 dirty_rx 字段和 refill_rx_ring 函数，在调用完 POLL 方法以后，而且网络层程序比较空闲的时候为一些 rx-ring 中的单元建立新缓冲挂在环形缓冲队列上，这样可以在新的数据包达到的时候节省时间，操作系统不必要手忙脚乱地开辟新的空间去应付新来的数据。 5． 最后请注意：我们上层的应用程序是以网络数据转发为主的，并没有在应用层面上有很多后台进程的复杂的应用，上述的 1 到 4 点中所做的显而易见是以牺牲系统效率整体效率而单独改善了网络数据的处理。 我们再来看改善的 8139CP 驱动程序使用 8139CP 在 x86(PIII-900Mhz) 平台上的接收情况： Psize Ipps Tput Rxint Done ---------------------------------------------------- 60 553500 354560 17 7 128 453000 350400 19 10 256 390050 324500 28 13 512 305600 456670 203 455 1024 123440 340020 772951 123005 1440 64568 344567 822394 130000 从上图来看，数据传输的效率和波动性有很明显的改善，在高速率和低速率的时候所需要的POLL 次数的差距以前的 8139CP 驱动程序那么显著了，这样的而且最大的包接收能力也提高到了 553K/s，我们在 MIPS 系列以及 Xscale 系列平台上最大的包接收能力可以提高大约 15%-25%。 最后使用 NAPI 并不是改善网络效率的唯一途径，只能算是权益之策，根本的解决途径还是在于上层应用程序能够独占网络设备，或者是提供大量的缓冲资源，如果这样，根据我们的实验数据表明可以提高 100%-150% 以上的接收效率。
[1] [2] 下一页
（出处：http://www.sheup.com）
上一页 [1] [2]