CN100451975C - 实现多核cpu进行报文联合处理的系统及方法 - Google Patents

Abstract

本发明公开了一种实现多核CPU进行报文联合处理的系统，包括多核CPU以及多个共享队列区，任一共享队列区与确定的两个CPU核连接，用于为所述两个CPU核提供共享报文队列：由共享队列区的报文发送CPU核写入该CPU核处理后的报文信息，共享队列区的报文接收CPU核根据写入顺序提取报文信息并进行处理。本发明还公开了一种实现多核CPU进行报文联合处理的方法，报文发送CPU核向共享队列区写入该CPU核处理后的报文信息，报文接收CPU核根据写入顺序提取报文信息并进行处理。通过本发明，避免了中断开销；不再局限于CPU核的硬件空间限制，提高了队列设计的灵活性，提高了吞吐量。

Description

实现多核CPU进行报文联合处理的系统及方法

技术领域

本发明涉及通信技术领域，特别是一种在通信数据处理设备中，实现多核CPU进行报文联合处理的系统及方法。

背景技术

由于多核CPU的每一个内核都能够运行独立的任务，提高处理的吞吐量和处理效率，因此日益广泛的应用于通信数据处理设备中。目前通信数据处理设备中多核CPU的工作方式有两种，包括流水线方式和并行方式对报文进行处理。对于流水线方式而言，每个CPU核完成报文处理的一部分，并在该部分处理完成后，将报文的控制权移交给下一个CPU核来继续处理，实现多核CPU对报文的联合处理，如图1所示，一个任务(Task)被分解为多段。

而对于并行方式来说，每个CPU可独立完成报文的全部处理，如图2所示，每个CPU完成一个Task的处理。

在流水线方式中，实行报文控制权转移主要有中断方式和轮询方式。

中断方式是指当前一个CPU核(称为第一CPU核)处理完报文后，向下一个CPU核(称为第二CPU核)发送一个处理器间中断(Inter-processorInterrupt，简称IPI)，第二CPU核根据IPI信号接收要处理的报文。在这种方式下，增加了第二CPU核的中断开销，特别是在大流量的情况下，频繁的中断开销会严重影响系统的性能；同时，中断信号只能起到通知第二CPU核接收报文的作用，并不能在信号中携带报文地址和报文处理结果等信息，因此，两个CPU核必须通过其他方式传递信息从而进行报文处理，如进程通信(Inter-Process Communication，简称IPC)。

轮询方式是指在硬件上采用的是入队出队的方式，比如在某些CPU核中，采用如消息环方式等硬件通信方式在CPU之间传递信息，当第一CPU核处理完成后，将报文相关的信息组成硬件要求的消息格式发送给第二CPU核，使消息进入第二CPU核的硬件消息队列中，第二CPU核通过读取相应的消息队列获取需要处理的报文。在这种方式下，消息格式受到硬件的限制，无法满足软件更新变化的要求；同时，硬件队列长度是固定的，当进入的消息达到硬件队列最大长度时，后续的消息将无法继续进入，导致报文处理失败。

可见，多核CPU在流水线方式下实现报文联合处理的现有技术方案都存在着不同的缺陷，如果能够提供一种即不受限于硬件，且能够避免中断带来的额外开销的灵活报文处理方案，将有助于提高报文处理的效率和成功率。

发明内容

本发明的目的是提供一种实现多核CPU进行报文联合处理的系统及方法，解决现有技术中多核CPU进行报文联合处理时存在的中断开销或者受到硬件限制的问题。

为实现上述目的，本发明的实施例提供了一种实现多核CPU进行报文联合处理的系统，包括多核CPU，还包括：

至少一个共享队列区，任一所述共享队列区与顺序进行报文处理的两个CPU核连接，用于为所述两个CPU核提供共享报文队列：由所述共享队列区的报文发送CPU核写入该CPU核处理后的报文信息，所述共享队列区的报文接收CPU核根据写入顺序提取所述报文信息并进行处理；

每一CPU核连接有一共享队列控制单元，所述共享队列控制单元包括队列状态识别模块，用于识别所述CPU核作为报文发送CPU核所对应的共享队列区的状态，还包括与队列状态识别模块连接的队列状态控制模块，用于相应控制所述CPU核以及所述CPU核作为报文接收CPU核所对应的共享队列区。

本发明的实施例还提供了一种实现多核CPU进行报文联合处理的方法，包括以下步骤：

报文发送CPU核识别共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列；所述报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息，报文接收CPU核根据写入顺序提取所述报文信息并进行处理；所述共享报文队列为所述报文发送CPU核和所述报文接收CPU核共享的报文队列。

由上述技术方案可知，本发明的实施例通过在报文发送CPU核和报文接收CPU核间设置共享队列区，采用队列轮询的方式，具有以下有益效果：

1、避免了中断开销，提高吞吐量；

2、共享队列区不再局限于CPU核的硬件空间限制，提高了队列设计的灵活性，并提高了吞吐量；

3、通过缓冲操作，进一步避免了对超出处理能力的报文的丢弃；

4、通过控制报文队列长度，进一步实现了报文吞吐量和时延之间的平衡。

下面通过附图和实施例，对本发明的技术方案做进一步的详细描述。

附图说明

图1为现有技术中多核CPU流水线工作方式下处理报文的示意图；

图2为现有技术中多核CPU并行方式下处理报文的示意图；

图3为本发明所提供的实现多核CPU进行报文联合处理的系统实施例1的框图；

图4为本发明所提供的实现多核CPU进行报文联合处理的系统实施例2的框图；

图5为本发明所提供的实现多核CPU进行报文联合处理的系统实施例3的框图；

图6为本发明所提供的实现多核CPU进行报文联合处理的方法实施例1的流程图；

图7为图6所示方法中，报文发送CPU核识别、控制共享队列区状态的一个实施例的流程图；

图8为图6所示方法中，报文发送CPU核识别、控制共享队列区状态的一个实施例的流程图；

图9为本发明所提供的实现多核CPU进行报文联合处理的方法实施例2的流程图。

具体实施方式

为了克服现有实现多核CPU进行报文联合处理技术中，中断方式或者轮询方式所导致的各种缺陷，本发明的实施例提供了一种实现多核CPU进行报文联合处理的系统和方法，下面分别加以说明。

参见图3，为本发明所提供的实现多核CPU进行报文联合处理的系统实施例1，包括用于报文联合处理的多核CPU，这里分别表述为CPU核A1，A2......A(n-1)和An，其中n≥2；还包括多个共享队列区，任一共享队列区与两个CPU核连接，因此共享队列区根据所连接的CPU核的不同，可以表示为B12，......，B1n，B2n......B(n-1)n。一般来说，在流水线方式下，每个CPU核负责处理报文的一部分，而且该处理具有一定的顺序，在本实施例中，是由A1、A2......An依次进行报文处理，因此，所包括的共享队列区为与顺序进行报文处理的两个CPU核A1、A2连接的共享队列区B12，与顺序进行报文处理的两个CPU核A2、A3连接的共享队列区B23......与顺序进行报文处理的两个CPU核A(n-1)、An连接的共享队列区B(n-1)n。可以看出，这种顺序可以根据实际需要灵活设置，比如按照A2、A1的顺序进行报文处理，则共享队列区为B21，并不影响本发明的技术方案。

在本实施例中，对于共享队列区B12而言，CPU核A1是其报文发送CPU核，CPU核A2是其报文接收CPU核；而对于共享队列区B23，CPU核A2是其报文发送CPU核，CPU核A3是其报文接收CPU核。可见，任何一个CPU核当其不是源CPU核和终CPU核时，都同时兼具报文发送、接收两种身份，分别对应着不同的共享队列区，比如CPU核A2同时对应着共享队列区B12和B23。

任何一个共享队列区都同时对应着两个CPU核，为这两个CPU核提供共享报文队列，由所述共享队列区的报文发送CPU核写入该CPU核处理后的报文信息，所述共享队列区的报文接收CPU核根据写入顺序提取所述报文信息并进行处理。比如，在本实施例中，共享队列区B12对应着CPU核A1和A2，由CPU核A1写入其处理后的报文信息，由CPU核A2根据写入顺序提取所述报文信息并进行处理。

在通信设备中进行报文处理，其所利用的CPU核以及各个CPU核的处理关系对本领域技术人员而言是明确并可以加以设置的，因此，管理人员可以启用或者设置相应的共享队列区。

通过本实施例1所提供的技术方案，顺序进行报文处理的两个CPU核共同维护一个双方都可以访问的报文接收队列，则前一CPU核处理完成后，无需发出中断信号，减少了因中断而产生的开销。同时，共同维护的报文接收队列是一种软件队列方式，可以在内存中或者其他存储器中根据需要设置或者指定，与传统的CPU核硬件队列相比，设计上具有相当大的灵活性；进一步的，基于软件的队列不再受到CPU核硬件空间的限制，可以进行调整；而且，在采用流水线方式的报文处理中，由于每个CPU完成报文处理的不同部分，每个报文在不同CPU上的处理时间可能不相同，所以采用队列方式进行报文的传递，除了可以降低报文传递的开销之外，还可以吸收短暂的突发流量，解决两个CPU在报文处理速度上的差异，提高设备的吞吐量。

为了对所述共享报文队列状态进行控制，较佳的技术方案是每一CPU核还连接有一共享队列控制单元，所述共享队列控制单元包括队列状态识别模块，用于识别所述CPU核作为报文发送CPU核所对应的共享队列区的状态，还包括与队列状态识别模块连接的队列状态控制模块，用于相应控制所述CPU核作为报文接收CPU核所对应的共享队列区。参见图4，为本发明所提供的实现多核CPU进行报文联合处理的系统实施例2，包括用于报文联合处理的多核CPU，具体为CPU核A1、A2和A3，按照A1-A2-A3的顺序分别处理报文的一部分。还包括共享队列区B12、B23，共享队列区B12与CPU核A1、A2连接，为CPU核A1、A2提供共享报文队列；共享队列区B23与CPU核A2、A3连接，为CPU核A2、A3提供共享报文队列。

在本实施例中，每一CPU核A1、A2和A3还分别连接有一共享队列控制单元C1、C2和C3，每一共享队列控制单元包括队列状态识别模块，用于识别所述CPU核作为报文发送CPU核所对应的共享队列区的状态，还包括与队列状态识别模块连接的队列状态控制模块，用于相应控制所述CPU核以及所述CPU核作为报文接收CPU核所对应的共享队列区。以共享队列控制单元C1为例，包括队列状态识别模块C11和队列状态控制模块C12，由于在本实施例中CPU核A1是第一个对报文进行处理的CPU核，不存在作为报文接收CPU核的情况，因此队列状态控制模块C12仅对所述CPU核A1进行相应控制；对于共享队列控制单元C2，则需要同时控制CPU核A2以及共享队列区B12；对于共享队列控制单元C3，由于在本实施例中CPU核A3是最后一个对报文进行处理的CPU核，不存在作为报文发送CPU核的情况，因此不会起到控制作用。

在本实施例中，共享队列控制单元C1、C2和C3与CPU核可以为内部连接，即通过软件方式设置在CPU核的内部，也可以为外部连接，即增加与CPU核连接的功能块；无论采取哪一种连接方式，都并不影响本发明的技术方案。如本实施例所示，就为外部连接的情况。

对CPU核以及CPU核作为报文接收CPU核所对应的共享队列区的控制可以包括很多方式，本发明提供了以下几种处理方案，但本领域技术人员应当了解，所例举的处理方案并非对本发明技术方案的限制：

所述队列状态控制模块可以包括一缓冲模块，用于在所述CPU核作为报文发送CPU核所对应的共享队列区已满的情况下，指令所述CPU核不再发送处理后的报文信息，并指令所述CPU核对其作为报文接收CPU核所对应的共享队列区缓冲处理后的报文信息。通过缓冲模块，可以避免所述共享报文队列已满所导致的后续报文丢弃，也避免了继续发送导致的网络拥堵。

所述队列状态控制模块可以包括一队列调整模块，用于根据所述CPU核作为报文发送CPU核所对应的共享队列区的状态，调整所述CPU核作为报文接收CPU核所对应的共享队列区的长度。通过队列调整模块，实现了在所述共享报文队列已满之前就加以控制，而不是消极等待队列全满时才被动的进行控制。同时，有效的控制报文的队列长度，能够克服较长队列缓冲所带来的时间延迟，从而在高吞吐量和低时延之间进行合理的平衡。

所述队列状态控制模块包括一置位模块，用于在所述CPU核作为某一共享队列区的报文发送CPU核且所述共享队列区已满的情况下，标识所述CPU核作为报文接收CPU核所对应的共享队列区为满。通过置位模块，实现了逐层连续反映，在任意共享报文队列已满时，源头CPU核就可以获知并进行控制。

参见图5，为本发明所提供的实现多核CPU进行报文联合处理的系统实施例3，包括用于报文联合处理的多核CPU，具体为CPU核A1、A2和A3，按照A1-A2-A3的顺序分别处理报文的一部分。还包括共享队列区B12、B23，共享队列区B12与CPU核A1、A2连接，为CPU核A1、A2提供共享报文队列；共享队列区B23与CPU核A2、A3连接，为CPU核A2、A3提供共享报文队列。每一CPU核A1、A2和A3还分别连接有一共享队列控制单元C1、C2和C3。

在本实施例中，任一共享队列控制单元包括队列状态识别模块，用于识别所述CPU核作为报文发送CPU核所对应的共享队列区的状态，还包括与队列状态识别模块连接的队列状态控制模块，用于相应控制所述CPU核以及所述CPU核作为报文接收CPU核所对应的共享队列区。而对于任一队列状态控制模块，又分别包括缓冲模块、队列调整模块和置位模块。具体的，共享队列控制单元C1包括队列状态识别模块C11和与之连接的队列状态控制模块C12，队列状态控制模块C12中包括缓冲模块C121、队列调整模块C122和置位模块C123；共享队列控制单元C2包括队列状态识别模块C21和与之连接的队列状态控制模块C22，队列状态控制模块C22中包括缓冲模块C221、队列调整模块C222和置位模块C223；共享队列控制单元C3包括队列状态识别模块C31和与之连接的队列状态控制模块C32，队列状态控制模块C32中包括缓冲模块C321、队列调整模块C322和置位模块C323。

显然，实施例3所提供的技术方案，不仅能够减少中断产生的开销，提高队列设计的灵活性和吞吐量，同时能够避免队列已满时后续报文的丢弃，以及通过主动队列控制的方式，实现队列拥塞的控制，在吞吐量和时延之间达到平衡。

本发明还提供了一种实现多核CPU进行报文联合处理的方法，包括报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息，报文接收CPU核根据写入顺序提取所述报文信息并进行处理；所述共享报文队列为所述报文发送CPU核和所述报文接收CPU核共享的报文队列。

可以看出，维护一个报文发送CPU核和报文接收CPU核都可以访问的报文接收队列进行报文处理，无需发出中断信号，减少了因中断而产生的开销；同时，共同维护的报文接收队列是一种软件队列方式，可以在内存中或者其他存储器中根据需要设置或者指定，与传统的CPU核硬件队列相比，设计上具有相当大的灵活性；进一步的，基于软件的队列不再受到CPU核硬件空间的限制，可以进行调整；而且，在采用流水线方式的报文处理中，由于每个CPU完成报文处理的不同部分，每个报文在不同CPU上的处理时间可能不相同，所以采用队列方式进行报文的传递，除了可以降低报文传递的开销之外，还可以吸收短暂的突发流量，解决两个CPU在报文处理速度上的差异，提高设备的吞吐量。

为了对所述共享报文队列状态进行控制，所述报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息之前，还包括所述报文发送CPU核识别所述共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列的步骤。

报文接收CPU核根据写入顺序提取所述报文信息可以包括：报文接收CPU核查询所述共享报文队列是否为空，是则循环执行查询操作，否则按照入队顺序提取所述报文信息。这相当于采用了轮询处理的框架，无需中断。

参见图6，为本发明所提供方法的实施例1，包括以下步骤：

步骤1、报文发送CPU核处理报文信息；

在本步骤中，报文发送CPU在完成自身对报文的处理之后，将报文信息封装成预设的消息结构，以保证下一CPU核能够识别，例如：

struct pkt_message

{

   ulong*packet；

   ulong*pretreat；

   ulong*parameter；

}

步骤2、报文发送CPU核识别所述共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列；

步骤3、报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息；

步骤4、报文接收CPU核查询所述共享报文队列是否为空，是则重新执行步骤4，否则执行步骤5；

步骤5、报文接收CPU核按照入队顺序提取所述报文信息。

在本实施例1中，步骤2可以采用如下两种方式进行处理：

参见图7，为步骤2一个实施例的流程图，具体为：

步骤201、报文发送CPU核识别所述共享报文队列是否已满，是则执行步骤202；否则直接执行步骤3；

步骤202、对所述处理后的报文信息进行缓冲；

步骤203、查询所述共享报文队列状态是否变更，是则对所缓冲的报文执行步骤3，否则重新执行步骤203。

由于报文发送CPU可以根据报文接收队列的长度和缓冲的报文个数判断报文接收CPU核可能发送的拥塞，所以可以不是等队列全满、丢弃到来时进行被动的控制，而是利用队列负荷门限判定机制，通过主动队列控制判断下游CPU的负载并采用相应的动作来预防可能发生的拥塞。参见图8，为步骤2另一个实施例的流程图，具体为：

步骤211、报文发送CPU核识别所述共享报文队列长度1，小于预设的最小门限值1min时表明无拥塞发生，执行步骤3；大于预设的最小门限值1min且小于预设的最大门限值1max时，执行步骤212，大于预设的最大门限值1max时，执行步骤213；

步骤212、缩短所述CPU核作为报文接收CPU核所对应的共享报文队列的长度，并执行步骤3；之所以要减少作为报文接收CPU核所对应的共享报文队列的长度，是为了对源CPU核的拥塞策略产生影响；

步骤213、表明所述共享报文队列已满，对所述处理后的报文信息进行缓冲，以通过缓冲来避免网络拥塞；

步骤214、查询所述共享报文队列状态是否变更，是则对所缓冲的报文执行步骤3，否则重新执行步骤214。

在共享报文队列已满的情况下，还可以包括标识所述CPU核作为报文接收CPU核所对应的共享报文队列为满的步骤，从而顺序实现对源CPU的通知。

参见图9，为为本发明所提供方法的实施例2，包括以下步骤：

步骤21、报文发送CPU核处理报文信息；

步骤22、报文发送CPU核识别所述共享报文队列长度1，小于预设的最小门限值1min时表明无拥塞发生，执行步骤27；大于预设的最小门限值1min且小于预设的最大门限值1max时，执行步骤23，大于预设的最大门限值1max时，执行步骤24；

步骤23、缩短所述CPU核作为报文接收CPU核所对应的共享报文队列的长度，并执行步骤27；

步骤24、表明所述共享报文队列已满，对所述处理后的报文信息进行缓冲；

步骤25、标识所述CPU核作为报文接收CPU核所对应的共享报文队列为满；

步骤26、查询所述共享报文队列状态是否变更，是则对所缓冲的报文执行步骤27，否则重新执行步骤26；

步骤27、报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息；

步骤28、报文接收CPU核查询所述共享报文队列是否为空，是则重新执行步骤28，否则执行步骤29；

步骤29、按照入队顺序提取所述报文信息。

最后应说明的是：以上实施例仅用以说明本发明的技术方案而非对其进行限制，尽管参照较佳实施例对本发明进行了详细的说明，本领域的普通技术人员应当理解：其依然可以对本发明的技术方案进行修改或者等同替换，而这些修改或者等同替换亦不能使修改后的技术方案脱离本发明技术方案的精神和范围。

Claims (10)

1、一种实现多核CPU进行报文联合处理的系统，包括用于报文联合处理的多核CPU，其特征在于还包括：

至少一个共享队列区，任一所述共享队列区与顺序进行报文处理的两个CPU核连接，用于为所述两个CPU核提供共享报文队列：由所述共享队列区的报文发送CPU核写入该CPU核处理后的报文信息，所述共享队列区的报文接收CPU核根据写入顺序提取所述报文信息并进行处理；

每一CPU核连接有一共享队列控制单元，所述共享队列控制单元包括队列状态识别模块，用于识别所述CPU核作为报文发送CPU核所对应的共享队列区的状态，还包括与队列状态识别模块连接的队列状态控制模块，用于相应控制所述CPU核以及所述CPU核作为报文接收CPU核所对应的共享队列区。

2、根据权利要求1所述的系统，其特征在于所述队列状态控制模块包括一缓冲模块，用于在所述CPU核作为报文发送CPU核所对应的共享队列区已满的情况下，指令所述CPU核不再发送处理后的报文信息，并指令所述CPU核对其作为报文接收CPU核所对应的共享队列区缓冲处理后的报文信息。

3、根据权利要求1所述的系统，其特征在于所述队列状态控制模块包括一队列调整模块，用于根据所述CPU核作为报文发送CPU核所对应的共享队列区的状态，调整所述CPU核作为报文接收CPU核所对应的共享队列区的长度。

4、根据权利要求1所述的系统，其特征在于所述队列状态控制模块包括一置位模块，用于在所述CPU核作为某一共享队列区的报文发送CPU核且所述共享队列区已满的情况下，标识所述CPU核作为报文接收CPU核所对应的共享队列区为满。

5、根据权利要求2-4任一所述的系统，其特征在于共享队列控制单元与所述CPU核为内部连接或者外部连接，所述内部连接为该共享队列控制单元通过软件方式设置在所述CPU核内部达到与所述CPU核连接；该外部连接为所述共享队列控制单元设置在所述CPU核外部通过功能块与所述CPU核连接。

6、一种实现多核CPU进行报文联合处理的方法，其特征在于包括以下步骤：

报文发送CPU核识别共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列；所述报文发送CPU核向共享报文队列写入该CPU核处理后的报文信息，报文接收CPU核根据写入顺序提取所述报文信息并进行处理；所述共享报文队列为所述报文发送CPU核和所述报文接收CPU核共享的报文队列。

7、根据权利要求6所述的方法，其特征在于报文发送CPU核识别所述共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列具体为：报文发送CPU核识别所述共享报文队列是否已满，是则对所述处理后的报文信息进行缓冲，直至所述共享报文队列状态变更；否则直接写入该CPU核处理后的报文信息。

8、根据权利要求6所述的方法，其特征在于报文发送CPU核识别所述共享报文队列状态，并相应控制所述CPU核作为报文接收CPU核所对应的共享报文队列具体为：

当所述共享报文队列长度小于预设的最小门限值时，直接写入该CPU核处理后的报文信息；

当所述共享报文队列长度大于预设的最小门限值且小于预设的最大门限值时，直接写入该CPU核处理后的报文信息，同时缩短所述CPU核作为报文接收CPU核所对应的共享报文队列的长度；

当所述共享报文队列长度大于预设的最大门限值时，所述共享报文队列已满，则对所述处理后的报文信息进行缓冲，直至所述共享报文队列状态变更。

9、根据权利要求7或8所述的方法，其特征在于当所述报文发送CPU核识别所述共享报文队列已满时，还包括标识所述CPU核作为报文接收CPU核所对应的共享报文队列为满的步骤。

10、根据权利要求6所述的方法，其特征在于报文接收CPU核根据写入顺序提取所述报文信息包括：

报文接收CPU核查询所述共享报文队列是否为空，是则循环执行查询操作，否则按照入队顺序提取所述报文信息。

Images