CN101436989B

CN101436989B - 一种转发报文的方法及装置

Info

Publication number: CN101436989B
Application number: CN2008101862984A
Authority: CN
Inventors: 陈平平
Original assignee: Fujian Star Net Communication Co Ltd
Current assignee: Ruijie Networks Co Ltd; Fujian Star Net Communication Co Ltd
Priority date: 2008-12-26
Filing date: 2008-12-26
Publication date: 2010-10-27
Anticipated expiration: 2028-12-26
Also published as: CN101436989A

Abstract

本发明公开了一种转发报文的方法及装置，用以解决现有技术中存在的转发报文过程中处理系统效率低的问题。该方法通过包括多个核心处理器和至少一个接口的网络设备执行报文处理进程，在每个接口设置对应的数据结构模块，所述数据结构模块包括至少一个节点，以及初始设置时指向起始节点的至少一个报文处理滑动指针，该包括：每个核心处理器独立地轮询每个接口，获取轮询到的接口所述对应的数据结构模块中报文处理滑动指针指向的节点的状态，根据节点的状态与报文处理进程的对应关系，对所述接口的报文，执行获取的节点的状态对应的报文处理进程，其中，所述报文处理进程包括将所述报文处理滑动指针指向下一个节点。

Description

一种转发报文的方法及装置

技术领域

本发明涉及计算机及通信技术，尤其涉及一种转发报文的方法及装置。

背景技术

随着互联网技术的发展，网络设备中单核心处理器越来越满足不了高速网络应用对处理性能的需求，而多核心处理器凭借其并行计算的特性，逐渐在网络通信领域得到广泛应用。所谓多核处理器，是指在一个芯片上集成多个处理核心处理器(CORE)，通常是共享内存式结构。多核处理器具备相对独立的多个计算处理核心，可以并行地执行报文转发处理程序，报文转发性能得到较大幅度提高，从而提高了系统整体的吞吐率。

但是，由于处理器运行程序的随机性，每个处理核心处理一个报文的时间并不一定相等，可能造成输入序列中前面的报文，反而后到达输出序列，也就是所谓的报文乱序问题。为解决上述报文转发过程出现的报文乱序问题时，目前，现有技术主要有如下几种：

一、流水线模式

将整个报文转发处理过程划分成多个阶段(Stage)，每个CORE负责一个阶段，组成一条串行的报文处理流水线(PipeLine)。参见图1，以三个内核的处理器为例，具体过程如下：

将报文处理过程划分成3个阶段Stage0、Stage1、Stage2，例如Stage0为报文接收、Stage1为报文业务处理、Stage2为报文发送，其中CORE0负责Stage0阶段、CORE1负责Stage1阶段、CORE2负责Stage2阶段。输入的报文首先进入CORE0执行Stage0阶段的处理操作，CORE0执行完毕后将报文传递给CORE1继续执行Stage1阶段的处理操作，通常使用报文队列来实现报文传递，然后再传递给CORE2。

可以看出，由于每个报文都是按照顺序依次被CORE0、CORE1、CORE2处理，因此就不存在乱序的问题。该方案的主要缺陷在于：

1、如上述三个阶段，Stage0、Stage1、Stage2所需要的处理时间必须尽量相等，即每个阶段的负荷均衡，才能得到最大的并发度，否则所需处理时间最长的那个阶段将成为系统的瓶颈。但目前，报文处理流水线的阶段划分难以做到负荷均衡。

2、依然以上述三个阶段的划分为例，假如Stage0、Stage1、Stage2三个阶段划分基本已经均衡了，但是现在需要增加某项业务功能，导致Stage1的处理时间增长，必然导致Stage1成为瓶颈点。必须重新划分阶段，将Stage1的部分操作挪到Stage0或者Stage1，才能重新达到各阶段负荷均衡，而这对于功能及业务需要不断扩展和升级的系统来说，是无法接受，因此难以适应功能及业务的不断扩展和升级。

3、如上示例，如果现在将硬件平台由三个内核的处理器升级为4个内核的处理器，显然必须重新将报文处理流水线设计为4阶段流水线才能适应硬件架构的变更，这对于硬件平台经常变化的系统来说是不方便的，因此难以适应硬件环境的不断扩展和升级。

二、流分类处理模式

参见图2，使用一个前置的报文流分类单元，可以是软件或者硬件，将不同流的报文分发到不同CORE处理，保证同一流的报文被分发到同一CORE处理。该方案由于保证了同一流的报文始终由同一个CORE处理，因此避免了同一流的报文乱序问题，基本满足现有网络应用的保序需求。该方案的最大缺陷在于不同流的负荷差别可能很大，会造成有些CORE比较空闲，而有些CORE则负荷繁重。

三、按序号排序

参见图3，报文接收单元为每个报文分配一个唯一的序号，并分发到各个CORE执行转发处理，处理完毕后再按照序号对报文排序，最后由报文排序单元将报文依次发送出去。

报文排序单元所采用的排序方法常见的是应用滑动窗口原理：报文处理单元处理完毕后，将报文按序号缓存在滑动窗口中，若序号超出了滑动窗口的缓存范围，则丢弃报文；之后报文排序单元根据序号从滑动窗口中获取报文，按顺序发送出去。

该方案的缺点在于：

1、接收单元需要为每个报文分配序列号，并附加在报文描述块中。这个工作若硬件实现，则该方案的应用环境就受到硬件环境的限制，无法具备较好的通用性；而若采用软件实现，则该序号生成软件模块可能成为性能瓶颈点。

2、该方案需要单独的报文排序处理单元，占用较多的系统资源，而且往往会成为性能的瓶颈点，导致系统整体性能并未得到提升。

当然现有技术中，还有些将上述三种方法进行组合和改进的方法，例如申请号200610172243.9以及申请号200710077513.2的这两篇专利中所描述的保证报文顺序的方法就是将上述第二种和第三种方法进行了结合和改进，基本处理步骤如下：

首先在转发多条数据流的报文时，为接收到的每个报文分配一个序列号，只需保证同一流的各个报文之间的序号唯一性，并以轮询方式将接收到的报文分配到多个CORE单元。然后为每个数据流设置一个当前发送序列号，最后在每个CORE转发报文时，先找到待转发报文所属数据流的当前发送序列号，并对当前发送序列号进行加锁，比较所述当前发送序列号和待转发报文的序列号是否相等，如果相等，则转发报文，更新所述当前发送序列号，对所述当前发送序列号解锁。

可以看出，上述方法相对于上述第二种技术方案，其不再强制将同一流的报文全部分配到同一个CORE处理，而可以将其分配到任意CORE处理，解决了各个CORE之间的负载均衡问题；而相对于上述第三种技术方案，其省却了独立的报文排序发送单元，而将其分散到了报文转发处理单元，提高了并行性能，避免了报文排序单元成为系统的瓶颈点。但是，该技术方案仍然需要前置一个具备序列号生成器的接收单元，同样存在上述第三种方案中的第一个缺点。

另外，该技术方案必须为每个数据流配备报文缓存用的滑动窗口，也就是说每条数据流都需要消耗相当数量的内存资源，当流的数量巨大时，比如上百万条流时，内存资源的消耗将是巨大的，系统性能会因此受到影响。

发明内容

有鉴于此，本发明实施例提供一种转发报文的的方法，用以解决现有技术中存在的转发报文过程中处理系统效率低的问题。

本发明实施例提供的一种转发报文的方法，通过包括多个核心处理器和至少一个接口的网络设备执行报文处理进程，在每个接口设置对应的数据结构模块，所述数据结构模块包括至少一个节点，以及初始设置时指向起始节点的至少一个报文处理滑动指针，该方法包括：

每个核心处理器独立地轮询每个接口，获取轮询到的接口对应的数据结构模块中报文处理滑动指针指向的节点的状态；

根据节点的状态与报文处理进程的对应关系，对所述接口的报文，执行获取的节点的状态对应的报文处理进程，其中，当报文处理滑动指针为报文接收滑动指针，且所述报文接收滑动指针指向的节点的状态为空闲时，对所述接口的报文，进行接收以及业务处理；当报文处理滑动指针为报文分发滑动指针，且所述报文分发滑动指针指向的节点的状态为报文已处理时，对所述接口的报文，进行分发处理。

本发明实施例提供的一种转发报文的装置，包括：

数据结构模块，包括至少一个节点，以及初始设置时指向起始节点的至少一个报文处理滑动指针，所述节点用于挂接报文，所述报文处理滑动指针在报文处理进程中移动；

获取单元，用于获取轮询到的接口对应的数据结构模块中报文处理滑动指针指向的节点的状态；

处理单元，用于根据节点的状态与报文处理进程的对应关系，对所述轮询到的接口收到的报文，执行获取的节点的状态对应的报文处理进程，其中，所述处理单元包括：接收及业务处理子单元，用于当报文接收滑动指针指向的节点的状态为空闲时，对所述接口的报文，进行接收以及业务处理；分发处理子单元，用于当报文分发滑动指针指向的节点的状态为报文已处理时，对所述接口的报文，进行分发处理。

本发明实施例中处理系统中每个CORE独立地轮询每个接口，根据轮询到的接口对应的数据结构模块中报文处理滑动指针指向的节点的状态，对该接口收到的报文进行对应处理进程，这样，多个CORE并行地根据报文状态执行对应的报文处理进程，提高了处理系统的效率；并且，初始设置时将报文处理滑动指针都指向起始节点，在执行报文处理进程中将指针顺序向后移，保证了报文转发的顺序。

附图说明

图1是现有技术中采用流水线模式实现转发报文的方法示意图；

图2是现有技术中采用流分类处理模式实现转发报文的方法示意图；

图3是现有技术中采用按序号排序实现转发报文的方法示意图；

图4是本发明实施例转发报文的方法示意图；

图5是本发明实施例轮询接收并执行业务处理的流程图；

图6是本发明实施例轮询分发处理的流程图；

图7是本发明实施例转发报文的方法的流程图；

图8是本发明实施例数据结构模块的结构图；

图9是本发明实施例利用数据结构模块接收并执行业务处理的流程图；

图10是本发明实施例利用数据结构模块分发处理的流程图；

图11(a)是本发明实施例报文处理滑动窗口中各个节点的第一状态图；

图11(b)是本发明实施例报文处理滑动窗口中各个节点的第二状态图；

图11(c)是本发明实施例报文处理滑动窗口中各个节点的第三状态图；

图12本发明实施例转发报文的方法的具体流程图；

图13本发明实施例转发报文的装置的结构图。

具体实施方式

一个网络设备通常包含一个或多个报文收发接口，网络设备的多个接口都可以同时接收报文，每个接口可能是入接口，也可能是出接口。图4为本发明实施例中处理系统对网络设备接收到的报文进行转发的流程，其中，处理系统包括两个，或三个----等等多个CORE，具体过程如下：

步骤401：以轮询的方式依次查询网络设备的各个入接口，接收报文并执行业务处理。

步骤402：以轮询的方式依次检测网络设备的各个入接口，当检测有已转发处理完的报文时，将该报文通过对应的出接口进行分发处理。

在本发明实施例中，上述两个步骤是独立的，多个CORE可以轮询一遍各个接口进行接收报文并执行业务处理后，然后轮询一遍各个接口进行报文的分发处理；也可以轮询多遍各个接口进行接收报文并执行业务处理后，然后轮询一遍各个接口进行报文的分发处理；还可以轮询多遍各个接口进行接收报文并执行业务处理后，然后轮询多遍各个接口进行报文的分发处理；当然也可以轮询一遍各个接口进行接收报文并执行业务处理后，然后轮询多遍各个接口进行报文的分发处理。

其中，步骤401中的具体的轮询执行过程参见图5：

步骤501：选取查询的起始的入接口。

步骤502：查询入接口是否有报文进入，即入接口是否接收到报文，如果有执行步骤503；如果没有则执行步骤504。

步骤503：接收报文并执行业务处理。

步骤504：判断该网络设备的所有接口是否被查询一次，如有没有，则执行步骤505，如果是，则该流程结束。

步骤505：选取下一个入接口，转入步骤502。

步骤402的中具体轮询执行步骤参见图6：

步骤601：选取查询的起始的入接口。

步骤602：查询入接口是否有已业务处理完的报文，如果有执行步骤603；如果没有则执行步骤604。

步骤603：对该业务处理完的报文进行分发操作。

步骤604：判断该网络设备的所有接口是否被查询一次，如有没有，则执行步骤605，如果是，则该流程结束。

步骤605：选取下一个入接口，转入步骤602。

由上述可知，从不同接口进来的报文基本上没有相互关联性，因此只需要保证同一个接口收到的报文按顺序转发，就可以满足报文转发过程中的报文保序的要求。因此，本发明实施例在网络设备的报文进来的接口上也就是入接口设定保序机制，将报文分发到各个输出接口也就是出接口时严格按照报文接收时的顺序执行，保证了在同一个接口上接收到的报文按照顺序分发到各自的出接口，从而实现报文能按照顺序进行转发。

本发明实施例中，在对网络设备的入接口设定保序机制时，需对网络设备的每个入接口设置对应的数据结构模块，该数据结构模块包括一个或多个节点，以及一个或多个报文处理滑动指针。这里，可以包括两个报文处理滑动指针，分别为报文接收滑动指针和报文分发滑动指针。在初始状态时，报文接收滑动指针和报文分发滑动指针指向该数据结构模块中的起始节点。

在每个入接口设置对应的数据结构模块后，还需设置数据结构模块中节点的状态与报文处理进程的对应关系，当节点的状态为空闲时，可以对该接口的报文，进行接收以及业务处理；当节点的状态为报文已处理时，可以对该接口的报文，进行分发处理。

根据上述设定的保序机制，系统转发报文过程如图7所示：

步骤701：每个CORE轮询每个接口，获取轮询到的接口对应的数据结构模块中报文处理滑动指针指向的节点的状态。

这里，可以获取轮询到的接口对应的数据结构模块中报文接收滑动指针指向的节点的状态，或者，获取轮询到的接口对应的数据结构模块中报文分发滑动指针指向的节点的状态。

步骤702：根据节点的状态与报文处理进程的对应关系，对轮询到的接口的报文，执行与获取到的节点的状态对应的报文处理进程。其中，报文处理进程包括将对应的报文处理滑动指针指向下一个节点。

这里，当报文接收滑动指针指向的节点的状态为空闲时，首先将从该接口进入的报文挂接到报文接收滑动指针指向的节点，也就是将该接口接收到的报文挂接到报文接收滑动指针指向的节点，然后将该节点的状态从空闲修改为报文已接收，将报文接收滑动指针指向下一个节点，最后对该节点挂接的报文进行业务处理，并将该节点的状态从报文已接收修改为报文已处理。

当报文分发滑动指针指向的节点的状态为报文已处理时，首先将该节点挂接的报文，从出接口进行分发，然后将该节点的状态从报文已处理修改为空闲，以及将报文分发滑动指针指向下一个节点。

本发明实施例中，数据结构模块可以为报文处理滑动窗口(Packet ProcessWindow)，参见图8，包括：一个或多个滑动窗口节点(Item)810，报文接收滑动指针(rx_ptr)820、报文分发滑动指针820(dispatch_ptr)。其中，Item810的个数可以固定，也可以根据系统负荷及系统可用资源动态调整，多个Item可以采用环形排列。

Item810：用于挂接报文，该Item包括两个变量：报文链指针(pkt_head)和滑动窗口节点状态(status)。其中pkt_head用于指向在该接口所接收到的报文。当Item810处于EMPTY状态时，该指针为空，初始设置时可以将所有Item的状态均置为EMPTY；而当节点处于RECVED或者PROCESSED状态时，该指针指向一个报文链，也可以是单个报文。Status用于表示该Item810的状态，为了实现报文的有序转发，每个节点设定了三个状态，空闲(EMPTY)、报文已接收(RECVED)、报文已处理(PROCESSED)，并且节点的状态与报文处理进程具有一一对应关系，具体参见表1。

rx_ptr820：用于指向要进行报文接收的Item，初始状态时，可以指向报文处理滑动窗口中的第一个节点。

dispatch_ptr830：用于指向要进行报文分发的Item，初始状态时，可以指向报文处理滑动窗口中的第一个节点。

当对网络设备的每个入接口设置对应的报文处理滑动窗口后，从一个入接口进入报文后，根据rx_ptr指向的Item的状态，对轮询到的接口的报文，进行接收以及业务处理的具体流程参见图9：

步骤901：对该入接口对应的报文处理滑动窗口加锁。

步骤902：判断加锁是否成功，当加锁成功则执行步骤903，当加锁不成功，则该入接口的接收以及业务处理流程结束，进入下一个入接口的报文接收以及业务处理。

状态	描述
状态	描述	EMPTY	Item处于空闲状态，没有报文挂接到该Item，也就是说上述pkt_head指针是空的，可以进行报文接收及业务处理。
RECVED	已经在对应接口接收到报文，并挂接到该Item，即pkt_head指向所接收到的报文，但是这些报文还没有经过转发处理，因此还不能分发到出接口。	EMPTY	Item处于空闲状态，没有报文挂接到该Item，也就是说上述pkt_head指针是空的，可以进行报文接收及业务处理。
RECVED		PROCESSED	该Item下的报文已经经过报文转发处理，可以将其分发到相应的出接口了，即进行报文分发处理。

表1

步骤903：判断该接口的rx_ptr是否为EMPTY，是，则执行步骤904，否则，该入接口的接收以及业务处理流程结束，进入下一个入接口的报文接收以及业务处理。

步骤904：将从该接口进入的报文挂接到该入接口对应的报文处理滑动窗口的rx_ptr所指的Item，并将该Item的状态修改为RECVED。

步骤905：将rx_ptr向后移动一个位置，使其指向下一个Item，准备给下一次报文接收时使用。

步骤906：对该报文处理滑动窗口解锁。

步骤907：对这些报文执行业务及业务处理。处理完毕后，并不立即分发到出接口，而是将对应的Item状态修改为PROCESSED。

其中，步骤901中加锁方式可以为试探式加锁，所谓试探方式的加锁，就是当没有其它CORE加锁时，该加锁操作返回成功，否则返回失败。也就是说，当加锁失败时，表示当前有其它CORE正在处理该接口的报文，因此就可以略过该接口，而直接处理下一个接口，避免CORE在执行加锁操作时盲目等待，这样可以提高CORE之间的并行性，进而提高系统性能。

在上述对一个入接口的报文进行转发处理后，根据dispatch_ptr指向的Item的状态，对该接口的报文，进行报文分发处理的具体流程如下，参见图10：

步骤1001：对该入接口对应的报文处理滑动窗口加锁。

步骤1002：判断加锁是否成功，当加锁成功则执行步骤1003，当加锁不成功，则该入接口的报文分发处理流程结束，进入下一个入接口的报文分发处理。

步骤1003：查询该接口对应的报文处理滑动窗口的dispatch_ptr所指向的Item的状态。

步骤1004：当该Item的状态为PROCESSED时，执行步骤1005；否则，执行步骤1007。

步骤1005：将该Item挂接的报文分发到对应的出接口，并将该将该Item的状态修改为EMPTY。

步骤1006：将dispatch_ptr向后移动一个位置，使其指向下一个的Item，从而准备给下一次报文分发时使用。

步骤1007：对该报文处理滑动窗口解锁。

同样，步骤1001中加锁方式可以为试探式加锁。

下面，以处理系统有三个CORE即包括CORE0、CORE1和CORE2为例，进行具体的描述。

本实施中，接口的报文处理滑动窗口处于初始阶段，即其各个Item均处于EMPTY状态，且其rx_ptr和dispatch_ptr均指向报文处理滑动窗口的第一个Item。此时报文处理滑动窗口的状态图11(a)所示，该报文处理滑动窗口的Item分别命名为I0、I1、I2，且Item采用环形顺序排列，即首尾相连。处理系统中每个CORE采用轮询的方式进行接收和业务处理，以及分发处理，具体过程如下，参见图12：

步骤1201：轮询到当前接口后，当该报文处理滑动窗口的rx_ptr指向的Item的状态为EMPTY时，将从当前接口进入的报文挂接到该Item。

这里，若CORE0轮询到该接口后，且rx_ptr指向的Item的状态为空，则将从该接口进入的报文挂接到该Item，I0，rx_ptr向后移动一位，随后CORE1轮询到该接口，则将从该接口进入的报文挂接到I1，rx_ptr继续向后移动一位，CORE2轮询到该接口后，则将从该接口进入的报文挂接到I2，同样，rx_ptr继续向后移动一位，为下一次轮询该接口做好准备。并将该三个Item的状态改为RECVED。如图11(b)所示。

若CORE1先轮询到该接口，则将从该接口进入的报文挂接到I0，其次，CORE2轮询到该接口，则将从该接口进入的报文挂接到I1，最后，CORE0轮询到该接口，则将从该接口进入的报文挂接到I2。

这里，若报文处理滑动窗口只包括两个Item，I0和I1，那么当CORE0和CORE1已经将从该接口进入的报文分别挂接到I0，I1，此时I0和I1状态为RECVED，那么CORE2轮询到此接口后，则rx_pt指向的I0的状态为RECVED，因此说明该报文处理滑动窗口接收到的报文已满，CORE2转向下一个接口进行接收及业务处理。

步骤1202：每个CORE对接收到的报文进行业务处理。这里，若CORE0将接收到的报文挂接到I0，则CORE0对I0挂接的报文进行处理，CORE1将接收到的报文挂接到I1，则CORE1对I1挂接的报文进行处理，CORE2将接收到的报文挂接到I2，则CORE2对I2挂接的报文进行处理；若CORE1将接收到的报文挂接到I0，则CORE1对I0挂接的报文进行处理，CORE0将接收到的报文挂接到I1，则CORE0对I1挂接的报文进行处理，CORE2将接收到的报文挂接到I2，则CORE2对I2挂接的报文进行处理。本实施例中，CORE0对挂接到I0的报文进行处理，CORE1对挂接到I1的报文进行处理，CORE2对挂接到I2的报文进行处理。

每个CORE对接收到的报文进行业务处理占用的资源比较多，并且，每个CORE进行业务处理的快慢也不一致，因此，本发明实施例中，当状态为EMPTY的节点挂接报文后，就将rx_ptr向后移动一位，这样，多个CORE可以并行地对该接口的多个报文进行业务处理，从而提高处理系统的效率。

步骤1203：当每个CORE对报文处理完毕后，将该CORE对应的Item的状态改为PROCESSED。这里，当CORE1、CORE2都已经完成了报文的转发处理操作，而CORE0还未完成时，CORE1、CORE2对应的Item的状态改为PROCESSED，而CORE0对应的Item的状态仍为RECVED。本实施例中，即I1、I2状态都已经被修改为PROCESSED，I0状态还处于RECVED。如图11(c)所示。

步骤1204：判断所有接口是否被查询，如果是，执行步骤1205；如果不是，则将下一个接口作为当前接口，转入步骤1201。

这里，步骤1203中，CORE1、CORE2都已经完成了当前接口的报文的业务处理操作，则CORE1、CORE2可以继续对下一个接口的报文进行接收及转发处理。

若在此期间，CORE0完成了对图11(c)中I0挂接的数据的业务处理，则I0状态修改为PROCESSED，而CORE0也参与到对其他接口的报文的接收及转发处理了。

步骤1205：按顺序检测接口的报文处理滑动窗口的dispatch_ptr指向的Item的状态，若当前接口的Item的状态为PROCESSED，则执行步骤1206；若该Item的状态为RECVED或EMPTY，则执行步骤1207。

这里，轮询一遍网络设备的入接口后，若CORE1、CORE2已经完成了所有接口的报文的业务处理操作，CORE0还处于对一个接口的一组报文的业务处理中时，则CORE1、CORE2可以依次检测每个接口的报文处理滑动窗口的dispatch_ptr指向的Item的状态。在检测当前接口的报文处理滑动窗口的dispatch_ptr指向的Item的状态时，若Item的状态为PROCESSED，则执行步骤1206；若该Item的状态为RECVED或EMPTY，则执行步骤1207。

以图11(c)为例，当前接口中，CORE0还处于对I0挂接的报文的业务处理中，CORE1检测dispatch_ptr指向的I0的状态为RECVED，因此，不执行分发处理，跳过该接口，进入下一个接口的报文分发处理了，即执行步骤1207。这里，尽管此时I1、I2的状态均为PROCESSED，但dispatch_ptr指向的是I0，这样，I1、I2虽然完成业务处理操作，但是其分发操作仍在I0之后，从而保证了该当前接口中，报文转发的顺序。

步骤1206：将dispatch_ptr指向的Item挂接的报文进行分发处理，分发处理完后，将该Item的状态改为EMPTY，并将dispatch_ptr指向下一个Item。

这里，CORE1或CORE2将当前接口的dispatch_ptr指向的Item对应挂接的报文进行分发处理，分发处理完后，将该Item的状态改为EMPTY，并将dispatch_ptr指向下一个Item。若在此期间，CORE0完成了对图11中I0挂接的数据的业务处理，则I0状态修改为PROCESSED，而CORE0也可以以轮询的方式进入分发处理过程。这样每个CORE都在执行报文处理进程，没有空闲等待的过程，大大提高了CORE的效率。

步骤1207：判断所有接口是否被查询，如果不是，将下一个接口作为当前接口，转入步骤1205，如果是，本次报文分发过程结束，进入下一次的接收和转发处理的过程，即进入步骤1201。

上述实施例中，三个CORE轮询一遍各个接口进行报文的接收和业务处理后，就轮询一遍各个接口进行报文的分发处理。这里，也可以三个CORE轮询多遍各个接口进行报文的接收和业务处理，也就是重复多次步骤1201～1204，当所有节点都接收到报文后，才轮询各个接口进行报文的分发处理，即执行步骤1205～1207。

当然上述实施例中，三个CORE还可以对一个接口进行报文的接收和业务处理后，直接进行报文的分发处理，然后再按照设定的顺序，对下一个接口进行报文的接收和业务处理，以及报文的分发处理。

如图13所示，本发明实施例提供的一种转发报文的装置，包括：数据结构模块100，获取单元200和处理单元300，其中，

数据结构模块100，包括至少一个节点，以及初始设置时指向起始节点的至少一个报文处理滑动指针，所述节点用于挂接报文，所述报文处理滑动指针在报文处理进程中移动。

获取单元200，用于获取轮询到的接口对应的数据结构模块中报文处理滑动指针指向的节点的状态。

处理单元300，用于根据节点的状态与报文处理进程的对应关系，对所述接口的报文，执行与获取的节点的状态对应的报文处理进程。

进一步，所述报文处理滑动指针包括报文接收滑动指针和报文分发滑动指针，则，获取单元200包括：第一获取子单元210和第二获取子单元220。

第一获取子单元210，用于获取轮询到的接口对应的数据结构模块中报文接收滑动指针指向的节点的状态。

第二获取子单元220，用于获取轮询到的接口对应的数据结构模块中报文分发滑动指针指向的节点的状态。

所述节点的状态包括：空闲、报文已接收或报文已处理，则处理单元300包括：接收及业务处理子单元310和分发处理子单元320。

接收及业务处理子单元310，用于当所述第一获取子单元210获取的节点的状态为空闲时，对所述接口的报文，进行接收以及业务处理。

分发处理子单元320，用于当所述第二获取子单元220获取的节点的状态报文已处理时，对所述接口的报文，进行分发处理。

接收及业务处理子单元310将从所述接口接收到的报文挂接到报文接收滑动指针指向的节点后，将所述节点的状态从空闲修改为报文已接收，将所述报文接收滑动指针指向下一个节点，并对所述节点挂接的报文进行业务处理，以及将所述节点的状态从报文已接收修改为报文已处理。

分发处理子单元320将所述报文分发滑动指针指向的节点挂接的报文，从出接口进行分发，并将所述节点的状态修改为空闲，将所述报文分发滑动指针指向下一个节点。

综上所述，本发明实施例报文转发的过程中，分成接收及业务处理，以及分发处理这两个独立的阶段，这两个阶段可以相互独立地并行运行，能较好地适应多核处理器的并行特性。本发明实施例中，每个接口对应一个数据结构模块，该数据结构模块包括至少一个节点，各个节点相互独立，可以被并行处理，因此，能很好的地适应多核处理器并行特性，提高并行系统的效率，同时，仅在每个接口处设定报文接收滑动窗口数据结构，不会大量占用系统资源，简洁而高效。并且本发明实施例所述的报文转发的方法可以由纯软件实现，不依赖于任何硬件环境，具备很强的通用性。在本发明实施例中，包括两个报文处理滑动指针，分别为报文接收滑动指针和报文分发滑动指针，初始设置时，它们均指向起始节点，从而在转发报文的过程，当报文接收滑动指针指向的节点的状态为空闲时，执行接收以及业务处理，并将报文接收滑动指针指向下一个节点，这样可以按照顺序依次接收报文；当报文分发滑动指针指向的节点的状态为报文已处理时，执行分发处理，并将报文分发滑动指针指向下一个节点，这样可以按照顺序依次分发报文，从而先接收的报文先分发，保证报文的顺序。因此，本发明实施例所述的报文转发的方法不但可以解决并行系统转发报文过程中的报文保序问题，并且提高了处理系统的效率。

显然，本领域的技术人员可以对本发明进行各种改动和变型而不脱离本发明的精神和范围。这样，倘若本发明的这些修改和变型属于本发明权利要求及其等同技术的范围之内，则本发明也意图包含这些改动和变型在内。

Claims

1.一种转发报文的方法，通过包括多个核心处理器和至少一个接口的网络设备执行报文处理进程，其特征在于，在每个接口设置对应的数据结构模块，所述数据结构模块包括至少一个节点，以及初始设置时指向起始节点的至少一个报文处理滑动指针，该方法包括：

根据节点的状态与报文处理进程的对应关系，对所述接口的报文，执行与获取的节点的状态对应的报文处理进程，其中，当报文处理滑动指针为报文接收滑动指针，且所述报文接收滑动指针指向的节点的状态为空闲时，对所述接口的报文，进行接收以及业务处理；当报文处理滑动指针为报文分发滑动指针，且所述报文分发滑动指针指向的节点的状态为报文已处理时，对所述接口的报文，进行分发处理。

2.根据权利要求1所述的方法，其特征在于，所述节点的状态包括：

空闲、报文已接收或报文已处理。

3.根据权利要求1所述的方法，其特征在于，所述对所述接口的报文，进行接收以及业务处理包括：

将从所述接口接收到的报文挂接到报文接收滑动指针指向的节点，并将所述节点的状态从空闲修改为报文已接收，将所述报文接收滑动指针指向下一个节点；

对所述节点接挂的报文进行业务处理，并将所述节点的状态从报文已接收修改为报文已处理。

4.根据权利要求1所述的方法，其特征在于，所述对所述接口的报文，进行分发处理包括：

将所述数据结构模块的报文分发滑动指针指向的节点挂接的报文，从出接口进行分发；

将所述节点的状态从报文已处理修改为空闲，以及将所述报文分发滑动指针指向下一个节点。

5.一种转发报文的装置，其特征在于，包括：

处理单元，用于根据节点的状态与报文处理进程的对应关系，对所述接口的报文，执行与获取到的节点的状态对应的报文处理进程，其中，所述处理单元包括：

接收及业务处理子单元，用于当报文接收滑动指针指向的节点的状态为空闲时，对所述接口的报文，进行接收以及业务处理；

分发处理子单元，用于当报文分发滑动指针指向的节点的状态为报文已处理时，对所述接口的报文，进行分发处理。

6.根据权利要求5所述的装置，其特征在于，所述报文处理滑动指针包括报文接收滑动指针和报文分发滑动指针，所述获取单元包括：

第一获取单元，用于获取轮询到的接口对应的数据结构模块中报文接收滑动指针指向的节点的状态；

第二获取单元，用于获取轮询到的接口对应的数据结构模块中报文分发滑动指针指向的节点的状态。

7.根据权利要求5所述的装置，其特征在于，所述接收及业务处理子单元包括：

接收模块，用于将从所述接口接收到的报文挂接到报文接收滑动指针指向的节点；

第一修改模块，用于将所述节点的状态从空闲修改为报文已接收，并将所述报文接收滑动指针指向下一个节点；

业务处理模块，用于对所述节点挂接的报文进行业务处理，以及将所述节点的状态从报文已接收修改为报文已处理。

8.根据权利要求5所述的装置，其特征在于，所述分发处理子单元包括：

处理模块，用于将所述报文分发滑动指针指向的节点挂接的报文，从出接口进行分发；

第二修改模块，用于将所述节点的状态修改为空闲，将所述报文分发滑动指针指向下一个节点。