小弟刚刚鸟枪换小炮。得到一台Intel(R) Core(TM)2 CPU 6400 @ 2.13GHz + PCI-E 4X 2.5GB的机器，以前看大家讨论多核，IRQ中断亲和的问题，心里头就发痒，现在终于有机会测试了！！！反复做了些测试，有一些值得思考的地方，将整个测试过程发上来（不包括性能改进方面的内容），与大家一起讨论（有点长，适合有耐心的TX看）：

一些个人结论性的东西可能有误，希望大家指点！！！


一、测试环境：

发包机(PC_A) -------- (eth1)Linux(eth2)---------收包机(PC_B)

内核版本：2.6.12
网卡驱动：Intel e1000e[Intel现在把pci-e的千兆网卡单独拿出来了。整了个e1000e]，ＮＡＰＩ模式;
发包工具：bwtest
Linux配置：网桥 + Netfilter；
数据包是单向发送64bytes小包。即PC_B不发包。

二、不开启IRQ中断均衡；
内核编译中，不开启此选项。

此时数据转发约166Mb(这是我发包机的上限了……)

从三次采样结果来看，所有负载都被放在了CPU0上面，CPU1基本上是在睡大觉。
同时，查看/proc/interrupt，也可以看到，CPU1上面没有中断。
结论：多核下不启用IRQ中断均衡功能是一种资源浪费。

三、开启IRQ中断均衡：
在内核编译中，启用该选项。

并没有去手动修改smp_affinity文件。在开机的时候，短暂的把eth2的中断也放到了CPU0后，立马自己学习，转到cpu1上面去了。实现了两张网卡，两个CPU，一人一个。哥俩好！！！
但是，这并不能让我高兴，因为问题才刚刚开始：

从三次采样结果来看，
１、ＣＰＵ总负载不降反升了，从50%%左右，上升到63%%左右了。[从ilde的百分比可以看出来]
２、CPU0的下来了（因为eth2的中断不需要它去处理了）；
３、CPU1的负载从0%%上升到了27%%左右。

为什么会有这种情况发生呢？此时猜测可以解释的就是：

为了进一步证明我的这个结论，我在Netfilter的raw表的PREROUTING中，丢弃所有数据：

当数据被丢弃时，从三次采样的结果来看，
１、ＣＰＵ１因为不再发送数据，又没有事情干了。它的空闲是%，所以，像网桥处理，软中断，肯定也没有它的份。再一次印证了刚才的想法（尽管它是错的）；
２、ＣＰＵ０负载也大幅的下降，这是因为。它不再处理连接跟踪那些东东了——再一次证明，Netfilter是一个很吃ＣＰＵ的东东。

那有没有可能：让一个ＣＰＵ来处理内核网格栈的功能，一个ＣＰＵ来专门处理网卡中断呢？？我突发奇想了！！！
即然现在net_rx_action软中断是运行在CPU0上的，那我调整中断亲和，把CPU0上的中断负载调整到CPU1上去，不就完美了么？？呵呵：

实验结果让我失望：
1、总CPU负载的确是下降了；
2、此时Cpu0变为空闲又变为%——软中断函数并没有像预期的那样，跑到Cpu0上面去；而是所有的东东又跑到Cpu1了，此时CPU1负载明显上升很多，net_rx_action好像是随着中断落到哪个ＣＰＵ上，它就跑到哪个ＣＰＵ上面去；
3、一个有趣的现像是：所有任务由Cpu0处理，总负载是50%%，所有任务由Cpu1处理，总负载下降很明显，这个原因没有仔细去考究了，难道是第二个核性能比个好？？？

因为通过上述实验，得到了“net_rx_action好像是随着中断落到哪个ＣＰＵ上，它就跑到哪个ＣＰＵ上面去”的结论，那么一开始的“net_rx_action这个软中断，只在一个ＣＰＵ上运行了，并没有实现多个ＣＰＵ的同时运行和调度”的结论就被推翻了！！那为什么会造成这种情况呢？？我陷入了沉思当中。

四、为什么会是这样呢？
通过查看代码，找到了原因（代码有删减）：

所有问题有核心在于，softnet_data是一个pre_cpu变量，net_rx_action被某个ＣＰＵ执行时，它只会遍历属于自己的网络设备队列。如上面的实验中，当eth1只会出现在cpu０的网络设备队列，eth2只会出现在CPU1的队列中。
遗憾的是，我的测试中，数据发送是单向的，所以，eth2没有接收数据。所以，所有的网络栈的工作，就理所当然地落到了CPU0上面来了。
那为什么，“当eth1只会出现在cpu０的网络设备队列，eth2只会出现在CPU1的队列中”，也就是随着硬件中断落到哪个CPU上，它就会在哪个CPU响应呢？？？这需要看poll_list这个网络设备队列的添加的实现过程了。
这个过程，都是在网卡中断函数中，它会调用：
netif_rx_schedule

所以，每个网络设备中断，会把产生中断的网络设备（也就是自己）放到响应中断的那个ＣＰＵ的softnet_data的队列上去。这就是原因所在了。
对于上面的实验，当一个网卡一个CPU时：eth1产生中断，把自己放到cpu0 的队列，eth2产生中断，把自己放到cpu1的队列，因为数据发送是单向的，当cpu1进入net_rx_action时，它的设备列表中显然不会有eth1，所以它也就没有了处理后续处理工作的机会，而所有的革命重任都落到了cpu0上。这就是前面实验中，为什么虽然硬中断已经实现一人处理一个，但是cpu0的负载很高，而cpu1的负载很低的原因了。

五、后一个实验
为了证明以上的推断，将测试数据包方向改为双向发送。这样，eth2也会产生接收中断，会把eth2的接收帧放到CPU1的队列上去。就能够实现两个net_rx_action并行——cpu0的队列中包含eth1，cpu1的队列中包含eth2……

１、cpu0的负载下降了，从2%%的空闲到10%%左右。这跟我的测试环境有关——数据包改为双向后，发包机的性能下降，它发送的数据帧从166Mb/s降到了100Mb/s。
２、可以看到CPU1负载明显地上升了，从70%%多的空闲到20%%左右，很明显，它此时也要运行net_rx_action，处理从收包机过来的接收到的数据帧，并处理网桥，Netfilter……等网络栈的工能。

六：初步结论
1、多核下，IRQ的负载均衡应该开启；
2、中断亲和内核自己可以通过调度算法解决，自己定义也可以；
3、中断实现多核并行后，内核协议栈的并行工作，包括网桥、ipv4、防火墙……的多核并行，跟硬中断落到哪个CPU上，也有直接关系。

在实践中，可能会遇到CPU数量大于/小于/等于网卡的情况，也有可能出现上/下行流量极不对称的情况，但是以上实验对于多核下调整内核的性能，还是很有意义的！

2。软中断的问题。其实，只要硬中断绑定到了特定的CPU上，那么网络协议栈也就是在这个CPU上处理。
因为本地CPU的硬中断处理完成后，会触发本地软中断NET_RX_SOFTIRQ。
——我与你结论相同，但是原因却不同：你仔细看我贴子的后一部份，并不是因为谁触发了NET_RX_SOFTIRQ而造成的。而是因为pre_cpu变量中设备队列的关系！你说这个，我个人认为：触发的时候，仅仅是挂起软中断，也就是设置了一个位图标志而已。它并不能决定，谁触发，即调用_netif_rx_schedule来进一步调用__raise_softirq_irqoff(NET_RX_SOFTIRQ);
而是调用了list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);的原因。
这样：实际上软中断net_rx_action会在多个并行在CPU上，它的并行与否，与产生数据接收的网卡的硬中断无关，但是即使有两个net_rx_action同时被两个cpu执行，因为其中一个cpu设备队列中，没有与之对应的接收数据帧的网络设备（因为中断时没有安装进队列来）。也会很快退出。此例中，cpu1中，没有eth1。所以，它即使进入了net_rx_action，也会很快退出。
当然，这个结论很有可能是错的，我还没有进一步证实，因为对软中断的调度这块，的确以前没有深入学习过。

对于conntrack，主要是我觉得并行效果不好的原因，主要是锁的问题。因为正反向tuple都在一个hash表中，所以不能像路由查询一样，采用多个锁。

——我现在发现，单个CPU效果都很差，并行的话，我就更加没有考虑到了，呵呵。空了我先找找单CPU的时候，效率差的原因再说。非常希望这一部份能与你进一步交流。  

文章来源CU社区：关于LINUX上中断在各个CPU之间的负载平衡问题