在多核系统上网络数据转发实验和一点思考
小弟刚刚鸟枪换小炮。得到一台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中断均衡；
内核编译中，不开启此选项。
Cpu(s): 0.0%% user, 0.5%% system, 0.0%% nice, 50.3%% idle
Cpu0 : 1.0%% user, 0.0%% system, 0.0%% nice, 1.0%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 50.8%% idle
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 1.0%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle
Cpu(s): 0.5%% user, 0.0%% system, 0.0%% nice, 50.8%% idle
Cpu0 : 0.0%% user, 1.0%% system, 0.0%% nice, 2.0%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle
复制代码
此时数据转发约166Mb(这是我发包机的上限了……)
从三次采样结果来看，所有负载都被放在了CPU0上面，CPU1基本上是在睡大觉。
同时，查看/proc/interrupt，也可以看到，CPU1上面没有中断。
结论：多核下不启用IRQ中断均衡功能是一种资源浪费。
三、开启IRQ中断均衡：
在内核编译中，启用该选项。
[root@SkyNet ~]# cat /proc/interrupts
CPU0 CPU1
74: 154789 1 PCI-MSI eth1
82: 16393 2102221 PCI-MSI eth2
复制代码
并没有去手动修改smp_affinity文件。在开机的时候，短暂的把eth2的中断也放到了CPU0后，立马自己学习，转到cpu1上面去了。实现了两张网卡，两个CPU，一人一个。哥俩好！！！
但是，这并不能让我高兴，因为问题才刚刚开始：
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 38.5%% idle
Cpu0 : 1.0%% user, 1.0%% system, 0.0%% nice, 2.0%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 73.7%% idle
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 37.2%% idle
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 2.1%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 72.4%% idle
Cpu(s): 0.5%% user, 0.5%% system, 0.0%% nice, 38.2%% idle
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 3.0%% idle
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 73.7%% idle
复制代码
从三次采样结果来看，
１、ＣＰＵ总负载不降反升了，从50%%左右，上升到63%%左右了。[从ilde的百分比可以看出来]
２、CPU0的下来了（因为eth2的中断不需要它去处理了）；
３、CPU1的负载从0%%上升到了27%%左右。
为什么会有这种情况发生呢？此时猜测唯一可以解释的就是：
“CPU1此时只分担到了发送数据帧的中断工作，网络内核栈的工作，从net_rx_action开始，包括网桥、Netfilter、队列调度等等工作，全部集中到了CPU0上，网络栈的工作，并没有实现负载均衡，换句话说，net_rx_action这个软中断，只在一个ＣＰＵ上运行了，并没有实现多个ＣＰＵ的同时运行和调度(通过后面的实验和ShadowStar同学 的指点，最后这一句的结论是错的，我最后会说明)”
复制代码
为了进一步证明我的这个结论，我在Netfilter的raw表的PREROUTING中，丢弃所有数据：
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 78.6%% idle, 0.0%% x, 2.1%% y
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 57.0%% idle, 0.0%% x, 5.4%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle, 0.0%% x, 0.0%% y
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 78.1%% idle, 0.0%% x, 2.7%% y
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 55.3%% idle, 0.0%% x, 5.3%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle, 0.0%% x, 0.0%% y
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 80.1%% idle, 0.0%% x, 2.2%% y
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 60.6%% idle, 0.0%% x, 4.3%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle, 0.0%% x, 0.0%% y
复制代码
当数据被丢弃时，从三次采样的结果来看，
１、ＣＰＵ１因为不再发送数据，又没有事情干了。它的空闲是100%%，所以，像网桥处理，软中断，肯定也没有它的份。再一次印证了刚才的想法（尽管它是错的）；
２、ＣＰＵ０负载也大幅的下降，这是因为。它不再处理连接跟踪那些东东了——再一次证明，Netfilter是一个很吃ＣＰＵ的东东。
那有没有可能：让一个ＣＰＵ来处理内核网格栈的功能，一个ＣＰＵ来专门处理网卡中断呢？？我突发奇想了！！！
即然现在net_rx_action软中断是运行在CPU0上的，那我调整中断亲和，把CPU0上的中断负载调整到CPU1上去，不就完美了么？？呵呵：
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 59.0%% idle, 0.0%% x, 0.5%% y
Cpu0 : 0.0%% user, 1.1%% system, 0.0%% nice, 98.9%% idle, 0.0%% x, 0.0%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 18.1%% idle, 0.0%% x, 1.1%% y
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 59.6%% idle, 0.0%% x, 0.5%% y
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle, 0.0%% x, 0.0%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 18.1%% idle, 0.0%% x, 1.1%% y
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 59.6%% idle, 0.0%% x, 0.5%% y
Cpu0 : 0.0%% user, 0.0%% system, 0.0%% nice, 100.0%% idle, 0.0%% x, 0.0%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 20.2%% idle, 0.0%% x, 1.1%% y
复制代码
实验结果让我失望：
1、总CPU负载的确是下降了；
2、此时Cpu0变为空闲又变为100%%——软中断函数并没有像预期的那样，跑到Cpu0上面去；而是所有的东东又跑到Cpu1了，此时CPU1负载明显上升很多，net_rx_action好像是随着中断落到哪个ＣＰＵ上，它就跑到哪个ＣＰＵ上面去；
3、一个有趣的现像是：所有任务由Cpu0处理，总负载是50%%，所有任务由Cpu1处理，总负载下降很明显，这个原因没有仔细去考究了，难道是第二个核性能比第一个好？？？
因为通过上述实验，得到了“net_rx_action好像是随着中断落到哪个ＣＰＵ上，它就跑到哪个ＣＰＵ上面去”的结论，那么一开始的“net_rx_action这个软中断，只在一个ＣＰＵ上运行了，并没有实现多个ＣＰＵ的同时运行和调度”的结论就被推翻了！！那为什么会造成这种情况呢？？我陷入了沉思当中。
四、为什么会是这样呢？
通过查看代码，找到了原因（代码有删减）：
static void net_rx_action(struct softirq_action *h)
{
struct softnet_data *queue = &__get_cpu_var(softnet_data);
while (!list_empty(&queue->poll_list)) {
struct net_device *dev;
dev = list_entry(queue->poll_list.next,
struct net_device, poll_list);
netpoll_poll_lock(dev);
if (dev->quota <= 0 || dev->poll(dev, &budget)) {
list_del(&dev->poll_list);
list_add_tail(&dev->poll_list, &queue->poll_list);
if (dev->quota < 0)
dev->quota += dev->weight;
else
dev->quota = dev->weight;
} else {
}
}
out:
local_irq_enable();
return;
softnet_break:
__get_cpu_var(netdev_rx_stat).time_squeeze++;
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
goto out;
}
复制代码
所有问题有核心在于，softnet_data是一个pre_cpu变量，net_rx_action被某个ＣＰＵ执行时，它只会遍历属于自己的网络设备队列。如上面的实验中，当eth1只会出现在cpu０的网络设备队列，eth2只会出现在CPU1的队列中。
遗憾的是，我的测试中，数据发送是单向的，所以，eth2没有接收数据。所以，所有的网络栈的工作，就理所当然地落到了CPU0上面来了。
那为什么，“当eth1只会出现在cpu０的网络设备队列，eth2只会出现在CPU1的队列中”，也就是随着硬件中断落到哪个CPU上，它就会在哪个CPU响应呢？？？这需要看poll_list这个网络设备队列的添加的实现过程了。
这个过程，都是在网卡中断函数中，它会调用：
netif_rx_schedule
static inline void netif_rx_schedule(struct net_device *dev)
{
if (netif_rx_schedule_prep(dev))
__netif_rx_schedule(dev);
}
复制代码
static inline void __netif_rx_schedule(struct net_device *dev)
{
unsigned long flags;
local_irq_save(flags);
dev_hold(dev);
list_add_tail(&dev->poll_list, &__get_cpu_var(softnet_data).poll_list);
if (dev->quota < 0)
dev->quota += dev->weight;
else
dev->quota = dev->weight;
__raise_softirq_irqoff(NET_RX_SOFTIRQ);
local_irq_restore(flags);
}
复制代码
所以，每个网络设备中断，会把产生中断的网络设备（也就是自己）放到响应中断的那个ＣＰＵ的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……
Cpu(s): 0.5%% user, 0.5%% system, 0.0%% nice, 16.6%% idle, 0.0%% x, 1.6%% y
Cpu0 : 1.1%% user, 0.0%% system, 0.0%% nice, 11.6%% idle, 0.0%% x, 0.0%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 21.9%% idle, 0.0%% x, 2.1%% y
Cpu(s): 0.0%% user, 0.0%% system, 0.0%% nice, 16.8%% idle, 0.0%% x, 2.1%% y
Cpu0 : 0.0%% user, 1.1%% system, 0.0%% nice, 10.5%% idle, 0.0%% x, 2.1%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 22.1%% idle, 0.0%% x, 2.1%% y
Cpu(s): 0.5%% user, 0.5%% system, 0.0%% nice, 15.1%% idle, 0.0%% x, 2.1%% y
Cpu0 : 1.0%% user, 0.0%% system, 0.0%% nice, 11.5%% idle, 0.0%% x, 1.0%% y
Cpu1 : 0.0%% user, 0.0%% system, 0.0%% nice, 19.8%% idle, 0.0%% x, 3.1%% y
复制代码
１、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的时候，效率差的原因再说。非常希望这一部份能与你进一步交流。