[发明专利]一种微引擎的分配方法和装置

说明书

技术领域

本发明涉及通信技术领域，特别涉及一种微引擎的分配方法和装置。

背景技术

在硬件转发路径上，当转发模块之间的处理速度不一致时，可以通过反压机制解决这一问题。反压机制简单说就是上游处理速度快过下游处理速度时，下游对上游反压，使上游处理速度变慢，最后达到上下游处理速度相当的一个平衡状态。反压的方向与数据流的方向相反，但是在进行反压时经常会出现转发丢包的现象。

网络处理器(Network Processor，NP)是一种可编程器件，它特定的用于处理通信领域的各种任务，例如：包处理、协议分析、路由查找、声音/数据的汇聚、防火墙或服务质量(Quality of Service，QoS)。它通常由若干个微处理器(Micro Engine，ME)和一些硬件协处理器组成。每个微处理器都是可编程、多线程的。网络处理器按处理机制可以分为流水线式和并行处理式。

网络处理器中，每个微处理器有一定的指令空间，通过软件来控制处理流程。在实现过程中，由于任务分配不同，对于微引擎的分配也可能会采用流水线式和并行处理式同时存在的模式，比如几个ME串行独立进行某些任务的处理，几个ME并行执行相同的任务，如图1所示。由于软件的实现方式不同，并行处理的几组ME完成的处理任务(如图1中的ME3x和ME4x)，对于报文转发而言，可以是同等重要的，也可以是有主有次的。例如某种软件实现中，将ME3x作为三层转发的实现模块，ME4x作为二层转发的实现模块。这种情况下，对于三层转发报文，ME4x的利用率很低，而对于二层转发的报文，ME3x的利用率就会很低。

现有技术中，网络处理器的转发模型固定，启动时为ME加载固定的代码。在多微引擎的网络处理器中，网络处理器启动以后，微引擎的分配是固定的，例如：微引擎ME11～ME1n用于报文的接收、微引擎ME21～ME2n用于二层转发业务、微引擎ME31～ME3n用于三层转发业务，其他微引擎用于调度、发送等。如果需要更改微引擎的分配，则需要重新编译，分配新的转发模型。

在网络处理器中，由于业务日趋复杂，对指令的需求也不断增大。而微引擎的指令空间有限，因此微引擎个数的分配会直接影响到业务的转发效率。

例如：假设分配给用于转发的ME个数为8个，三层IPv4(Internet Protocolversion 4，因特网协议版本4)转发需要4个ME可以达到线速，二层IPv4转发需要5个ME可以达到线速，由于资源的限制，并且优先为三层IPv4转发分配ME，则只能为二层IPv4转发分配4个ME。

但是，在实际网络中，一台路由器设备通常是二三层业务混跑的，因此业务流量是不固定的，有可能某一时刻经过该路由器设备的二层业务流量很大，而三层业务流量却很少，因此会导致分配给三层业务的ME浪费，而分配给二层业务的ME却还不够。而另一时刻又可能会出现三层业务偏多、二层业务偏少的情况。

现有技术可以通过网络工程师使用命令手动调整微引擎的分配。但是这种方法需要工程师时刻了解实际的业务流量情况，在由于NP性能不够导致丢包时不能快速地感知并响应。

发明内容

本发明实施例提供一种微引擎的分配方法和装置，以实现根据当前各业务的流量，动态为各业务模块分配ME。

为达到上述目的，本发明实施例一方面提供一种微引擎的分配方法，包括：

确定由于网络处理器NP中第一业务模块占用的微引擎ME数量不够导致转发模块出现反压丢包；

根据当前各业务模块的流量和当前各业务模块所允许的最大流量确定需要重新为所述各业务模块分配ME，并根据所述当前各业务模块的流量确定需要为所述各业务模块重新分配的ME的个数；

根据确定的个数为所述各业务模块重新分配ME。

另一方面，本发明实施例还提供一种微引擎的分配装置，包括：

第一确定模块，用于确定由于网络处理器NP中第一业务模块占用的微引擎ME数量不够导致转发模块出现反压丢包；

第二确定模块，用于根据当前各业务模块的流量和当前各业务模块所允许的最大流量确定需要重新为所述各业务模块分配ME，并根据所述当前各业务模块的流量确定需要为所述各业务模块重新分配的ME的个数；

分配模块，用于根据所述第二确定模块确定的个数为所述各业务模块重新分配ME。