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

本文档的Copyleft归wwwlkk所有，使用GPL发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。 E-mail: HYPERLINK mailto:wwwlkk@126.com wwwlkk@126.com 来源: /?businessaid=6un=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个： 当网卡接收到一个数据包，并通过DMA方式写入内存，此时网卡会向前移动rdh，并发送网卡中断。 网卡发送完数据包，并移动tdh，当tdh移动次数达到一定数量，或者tdh等于tdt的时候会发生网卡中断。 如果不发送也不接收数据包，网卡也会定时产生中断，比如一秒一次。 以上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部分)： 《在多核系统上网络数据转发实验和一点思考》 /Linux%C4%DA%BA%CB%CE%CA%CC%E2/4921.html