本文档的Copyleft归wwwlkk所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。
E-mail:
多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的情况。
结论：由谁发送的数据包，就由谁来释放更合理。
