正确进行多内核之间的应用划分（一）

　　随着网络带宽及对高层服务需求的增加，多内核产品将是满足当今分组处理需求的唯一解决方案。多内核的流行无疑对嵌入式网络市场形成了巨大冲击，不过尘埃落定后，人们开始清醒地认识到，在做出如何对多内核进行应用划分的决策之前，还需要对许多重要的架构细节进行仔细检查。在本文的第一部分里，作者介绍了处理器的应用背景，控制平面和数据平面的划分，以及多内核划分和相关的I/O连接等。

　　多内核处理器应用背景

　　目前用于网络设备的多内核处理器通常瞄准的是企业级接入路由器，不过即将上市的新型多内核处理器可以提供比2层和3层路由多得多的功能。许多高层业务，比如4-7层的业务，将会被网络公司加入，目的是在过去已经部署到网络中的一些设备中增加一些特殊的功能，实现产品的差异化，从而使网络方案多样化所导致的运营成本得到降低。目前市场上的许多系统都是在单内核处理器上运行它们的控制平面和数据平面以及所有的附加业务。

　　然而，单内核已经达到系统功率预算所确定的频率极限，这是一个利用晶体管技术不易解决的问题。于是，下一代系统对更高性能和更广泛的差异化业务的需求使得这些系统成为多内核设备的理想选择，从而在不超过由系统所在地区和最终用户经济实力所确定的功率预算条件下，帮助系统提供商提高系统性能，并增加新的业务。多内核处理器只需通过简单地降低内核频率以便使用更一般的晶体管技术即可提供优异的每瓦性能，并进而节省裸片面积，降低静态和动态功耗。

　　在多内核之间划分控制平面和数据平面

　　于是，在设计一个完整方案时，首先需要做出的应用决策之一就是如何在多内核之间划分控制平面、数据平面和业务。目前的多内核器件工作频率可从600MHz到2GHz，核的数量从2个到16个，而某些特殊处理器的内核数量甚至更多。必须确定一个特定应用的控制平面是否可以运行在多个内核上，如果可以，需要多少内核才能提供所需的控制平面性能。如果控制平面是多内核不友好的以至于无法在多内核上运行，那么这些内核的速度将由应用控制平面所需的性能水平来决定，这是一个迅速消除一些低速多内核处理器的标准。

　　另外，如果控制平面软件可以扩展到多内核上去，那么在没有能够从应用程序本身提取内核数量的底层操作系统条件下能这样做吗？由于许多控制平面的任务不能扩展到不对称多处理(AMP模式)工作的多内核上，这种提取工作通常只能由支持对称多处理(SMP)的操作系统来实现。但是事实证明，当内核数量超过2个后，性能的提高就不怎么令人满意了：宝贵的CPU周期被浪费在SMP协调任务上，而效率随着内核数量的增加变得更低。高出很多倍的控制平面处理需求可以促进应用程序在具有更高速度的多内核器件上运行，允许控制平面保持在单个内核上，或者(最多)是双内核上，同时满足应用的控制平面的性能需求。

　　数据平面的代码就是分组处理代码，很容易在并行工作的多内核上运行。这种代码在多内核上的划分比较容易，因为多内核运行分组处理数据路径代码的同一例程，分组数据可以并行处理。有两种主要应用模式可用于多内核上的分组处理。第一种模式采用了严格的流关系，可确保处理彼此之间没有直接关联、因此没有共享状态的分组数据的多内核之间具有有限的甚至是零同步。为了能够同时使用多个内核，并让预处理器执行算术运算，这种方案要求作出相对低级别的决策。

　　在第二种模式中采用了一个比较简单的调度算法，这意味着可以采用多个内核来同时处理同一数据流中的分组数据。分组排序和共享数据结构的锁定必须在硬件或软件层实现，以确保分组排序得到保护，共享内容得到至少少许的更新(有时还要按正确的顺序)。因为共享数据结构上的等待将产生空闲内核周期，因此优化这些代码(以及某些类型的硬件卸载)有助于减少更新共享数据结构时的性能损失。通过将内核移至下一个分组同时让硬件保持排好的队列，次序恢复的目标硬件卸载功能还可以释放一些内核周期。

　　多内核划分和I/O连接

　　这些新型的多内核在I/O方面提出了有趣的挑战。许多时候，将特定的I/O接口静态连接到特定的内核是无法接受的。对多内核上资源共享的需求会影响到具体的应用划分。在接入路由器应用中，许多I/O将接收分组数据并提供给内核进行处理，这就像目前的许多方式一样，将数据智能地分配到想往公共I/O发送数据的多内核上。目前许多方案都包含一些有助于分组数据分配的硬件加速分组解析和准入分类功能，但即便是一个很简单的方法都需要采用一个或更多的内核来运行代码，以确定将输入进来的数据发往何处。有时候，当某个内核被用作分配机制时，软件在处理器之间的移植可能更加容易，但这个内核可能成为不仅是器件本身、甚至是整个系统的性能瓶颈(设想一下用于服务10Gb/s以太网链路的单内核，却只能进行分类以及向其他内核分配数据，其结果便不难而知！)

　　如上所述，内核频率将不断下降而低于处理需求(还可能伴随着I/O速度的不断增加)，因此重要的是要确保分组数据分发机制不能成为瓶颈，而且要有足够的灵活性来确定每个分组的初始目的地。输出内核需要能够将分组下传给I/O，并继续向前传送，而不必去协调复接分组分割机制中的I/O使用。这需要一定水平的I/O虚拟化功能，并且这些功能必须用硬件实现。