《多cpu下基于e1000e驱动的数据包以及网卡中断流程分析》由会员分享，可在线阅读，更多相关《多cpu下基于e1000e驱动的数据包以及网卡中断流程分析（4页珍藏版）》请在金锄头文库上搜索。
1、 多 CPU+e1000e+中断 1 /4本文档的 Copyleft 归 wwwlkk 所有，使用 GPL 发布，可以自由拷贝、转载，转载时请保持文档的完整性，严禁用于任何商业用途。 E-mail: 来源: http:/ CPU 下基于 e1000e 驱动的数据包以及网卡中断流程分析图 1 e1000e 网卡收包环和发包环控制收包环说明：next_to_clean 和 next_to_use 是内核读写的；rdt 是内核写，网卡只读；rdh 是网卡写，内核只读；next_to_clean 和 rdh 之间的是已经接收到数据包的内存；rdh 和 rdt 之间是还未接收到数据包的内存；next_t
2、o_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、果不发送也不接收数据包，网卡也会定时产生中断，比如一秒一次。以上 3 个时机产生相同的中断信号，所以会调用相同的中断处理例程。说明：这里对时机的总结是通过实验获得，不是很精确，但是基本上是正确的。网卡只是产生网卡中断，但是网卡不能决定由哪个 CPU 来响应中断。在多 CPU 体系下，由中断控制器来决定由哪个 CPU 响应中断。图 2 是 linux-2.6.35 在没有使用 RPS 下的数据包接收和发生流程。在这种模式下，当有一个 CPU 在处理数据包时，其它 CPU 就不会再处理数据包了，虽然中断控制器会选择不同的 CPU 来响应网卡中断，但 CPU 不是并发的处理数据包，而是串行的处理数据
4、 多 CPU+e1000e+中断 2 /4包。图 3，图 4 是开启 RPS 后的流程。 多 CPU+e1000e+中断 3 /4图 2 数据包接收和发生流程图 3，图 4 是开启 RPS 后的流程。图 3 开启 RPS 后的流程-1 多 CPU+e1000e+中断 4 /4图 4 开启 RPS 后的流程-2未开启 RPS 的情况下，针对一个网卡的数据包处理总是串行的，但是当有 2 个或者 2 个以上的网卡时，通过配置可以很好的提高性能：eth0 由 CPU0 响应中断，eth1 由 CPU1 响应中断，这样整体上就达到了负载均衡。开启 RPS 的情况：只要有多个流，且通过流计算出的哈希值是均衡分布的，那么就可以达到负载均衡。注意到 RPS 只对接收过程进行分流，并没对 skb 释放过程分流，所以在释放发生完的数据包的时候，会频繁刷新 CPU 缓存，从以上过程可以看出，由谁发送的数据包，就由谁来释放数据包更合理。这个结论同样适合于无 RPS 的情况。结论：由谁发送的数据包，就由谁来释放更合理。附录：独孤九贱的这篇测试文章，可以验证本文结论(除 RPS 部分)：在多核系统上网络数据转发实验和一点思考http:/www.linux-
