网络的速度一直在进步，同时CPU的速度却几乎停了下来转而向多CPU/Core/Thread方向发展，Linux网络子系统要想跟上网络的发展速度，必须将其内部的接收和发送流程尽可能的并行化。
对于从本地发出的数据包，如果发送数据包的应用程序是多线程的，那么其发送过程本身就已经是多线程的了，这部分无须做太多工作。对于数据包的转发的和接收就完全是另一种情形了：在哪个CPU上响应的中断，就在哪个CPU上做后续的处理。
如果IO-APIC支持将中断RR（轮转）发送到所有的允许响应NIC（网卡）中断的CPU上，那么这个情况多少会缓解，但是会引入包乱序的问题，乱序对于TCP来说，可是非常的糟糕，所以这并不是一个好的解决办法。
如果网卡支持多个接收队列，并且每个接收队列都有一个对应的中断，那么我们可以将这些中断分散绑定到CPU上，获得较好的Throughput（吞吐量）。但是接收队列的数量和CPU/Core/Thread的数量很难达到匹配，并且即使匹配，也可能不容易做到按权重分配，而且每个NIC的做法可能还不一致，导致配置非通用。
目前Linux在这方面的工作是，不过还有要走，估计进入2.6.23是没什么希望了，所以我别出心裁的想出了通过暂缓无RPS之痛，经过几轮迭代之后，终于稳定。奈何，Linux社区仍然认为RPS才是“人间正道”，所以我的多队列版IFB并未并入，我也终止了用tasklet替代我实现多队列版IFB用的内核线程的工作。等RPS正是进入Linux，我将重启IFB的并行优化，计划是通过每个CPU/Core/Thread绑定一个tasklet来实现。
我上面给出的多队列版IFB的补丁已经稳定，如有需要，敬请使用，也算我没白忙一场！
阅读(2160) | 评论(0) | 转发(0) |
