多CPU下基于e1000e驱动的数据包以及网卡中断流程分析.doc

http://wenku.baidu.com/link?url=mMKDH_fKmUXN7L6rANIFHjoHdKCYBLlDrqoYB1daDTEkNFk9Bt9xlJtS_4BKBj6w22WDrUWO3PNjf6UpYxwMfkX206E9qVBtg3RgYe4ScOG

本文档的Copyleft归wwwlkk所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。

E-mail:

来源:http://passport.baidu.com/?business&aid=6&un=wwwlkk#7

多CPU下基于e1000e驱动的数据包以及网卡中断流程分析

图1 e1000e网卡收包环和发包环控制

收包环说明：

next_to_clean和next_to_use是内核读写的；

rdt是内核写，网卡只读；

rdh是网卡写，内核只读；

next_to_clean和rdh之间的是已经接收到数据包的内存；

rdh和rdt之间是还未接收到数据包的内存；

next_to_use后的是还未使用的区域。

发包环说明：

next_to_clean和next_to_use是内核读写的；

tdt是内核写，网卡只读；

tdh是网卡写，内核只读；

next_to_clean和tdh之间的是已经发送的数据包，可以被释放；

rdh和rdt之间是发送的数据包；

next_to_use后的是还未使用的区域。

 

网卡产生中断的时机，一共3个：

1）  当网卡接收到一个数据包，并通过DMA方式写入内存，此时网卡会向前移动rdh，并发送网卡中断。

2）  网卡发送完数据包，并移动tdh，当tdh移动次数达到一定数量，或者tdh等于tdt的时候会发生网卡中断。

3）  如果不发送也不接收数据包，网卡也会定时产生中断，比如一秒一次。

以上3个时机产生相同的中断信号，所以会调用相同的中断处理例程。

说明：这里对时机的总结是通过实验获得，不是很精确，但是基本上是正确的。

 

网卡只是产生网卡中断，但是网卡不能决定由哪个CPU来响应中断。在多CPU体系下，由中断控制器来决定由哪个CPU响应中断。

图2是linux-2.6.35在没有使用RPS下的数据包接收和发生流程。

在这种模式下，当有一个CPU在处理数据包时，其它CPU就不会再处理数据包了，虽然中断控制器会选择不同的CPU来响应网卡中断，但CPU不是并发的处理数据包，而是串行的处理数据包。

图3，图4是开启RPS后的流程。

图2数据包接收和发生流程

 

 

图3，图4是开启RPS后的流程。

图3开启RPS后的流程-1

图4开启RPS后的流程-2

 

未开启RPS的情况下，针对一个网卡的数据包处理总是串行的，但是当有2个或者2个以上的网卡时，通过配置可以很好的提高性能：eth0由CPU0响应中断，eth1由CPU1响应中断，这样整体上就达到了负载均衡。

开启RPS的情况：只要有多个流，且通过流计算出的哈希值是均衡分布的，那么就可以达到负载均衡。

 

注意到RPS只对接收过程进行分流，并没对skb释放过程分流，所以在释放发生完的数据包的时候，会频繁刷新CPU缓存，从以上过程可以看出，由谁发送的数据包，就由谁来释放数据包更合理。这个结论同样适合于无RPS的情况。

 

结论：由谁发送的数据包，就由谁来释放更合理。

 

附录：

独孤九贱的这篇测试文章，可以验证本文结论(除RPS部分)：

《在多核系统上网络数据转发实验和一点思考》

http://www.linux-ask.com/Linux%C4%DA%BA%CB%CE%CA%CC%E2/4921.html