CN101335644A - 网络处理器动态加载微码的方法 - Google Patents

Abstract

本发明公开了一种网络处理器动态加载微码的方法，该方法预先编译微码文件，所述微码文件中包括一个以上功能微码，所述每个功能微码对应特定的处理功能；网络处理器运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中。利用本发明，可以充分利用网络处理器的有限的指令空间，当设备的运行环境发生变化后，能够在设备运行过程中动态地更新网络处理器指令空间中的微码以提供相应的功能。

Description

网络处理器动态加载微码的方法

技术领域

本发明涉及网络通信技术，尤其涉及一种网络处理器动态加载微码的方法。

背景技术

在现在的网络通信领域中，伴随着移动多媒体子系统(IMS)、第三代(3G)通信技术的快速发展，基于IP的开放式下一代网络技术的出现，各种新协议、新业务层出不穷，网络规模膨胀性增长，用户对带宽需求的急速增加。这对设备提供商而言，提出了严峻的现实挑战，即：如何快速灵活的推出对新业务的支持，如何保证服务质量不被降低，如何提升产品的个性化水平等等。

传统的基于单CPU的软件架构的网络设备，虽然在快速推出新业务，支持新协议方面具有优势，但是其处理能力却很难满足网络的需求。而基于专用集成电路(ASIC)的网络设备，处理能力虽然高效，但却不具有支持新业务功能的可编程性。而网络处理器(NP，Programmable NetworkProcessor)的出现，则在速度和可编程性上给设计人员一种极好的选择。网络处理器具备完全的可编程能力，可以实现OSI网络协议栈2～7层的处理，支持对信元、分组数据流等多种协议数据类型的处理，其强大的处理能力可以实现高带宽的线速处理能力，其开放的高度集成的体系结构使得基于网络处理器的网络设备易于系统扩展。

IXP 1200网络处理器(由Intel公司推出的)是一种互联网交换架构的网络处理器，它由一个硬核(StrongARM)处理器、六个微引擎(ME，Microenginer)、存储器接口和高速总线接口组成。IXP1200的主要功能模块和体系结构的主要特征是：1)并行处理器结构，StrongARM处理器和6个微引擎均为精简指令集计算(RISC)处理器，并行工作；2)StrongARM处理器运行BSP、驱动程序、实时操作系统、路由表维护及上层应用程序，完成地址学习、转发表的生成与维护和网络管理等任务。3)6个微引擎是32位的可编程RISC，在微引擎的指令空间上运行有微码(Microcode)，通过运行微码可进行数据流输入/输出、打包/拆包、分类、快速查表、转发等实时处理，微引擎由StrongArm处理器负责初始化并加载微码执行。

虽然类似IXP1200这样的具有并行处理架构的网络处理器具有上述特点，但是在实际的使用过程中，还是有以下缺陷：

这种网络处理器的微引擎指令空间已经不能够满足业务发展的需要。IXP1200最初的版本中每个微引擎都具有各自独立的1K条微码指令空间，后来推出了2K条微码指令空间的IXP1200网络处理器版本。不过即使如此，在系统设计、编程开发方面仍然会由于微码指令空间狭小而造成不便。比如，在边缘路由器的设计中，需要支持的业务种类极为繁杂，如访问控制列表(ACL)业务，网络地址翻译(NAT)业务，服务质量(Qos)，路由图(Route-map)，多协议标签交换虚拟专用网(MPLS VPN)，IPv4，IPv6等等业务；还有在DSLAM网关设计中，IXP1200除了承担基本的路由转发，还要包括与用户认证相关的Bras功能的开发，在这些开发过程中，IXP 1200网络处理器的指令空间远远不能满足业务发展的需要。

目前，在开发过程中往往需要在一套微码中支持更多的业务功能，但微码空间又不允许。实际开局中，根据不同的应用场合，有些功能需要，有些功能并不需要，不需要的功能就浪费了有限的微码指令空间。为了解决由于网络处理器指令空间的限制对设备多业务功能支持的影响，现有的解决方法主要包括以下几种：

(1)根据设备的开局功能需求，开发满足该局点需求的微码版本，删除掉该局点不需要的微码代码以节省微码空间。这种方法的缺点是会导致开发的微码版本越来越多，越来越难以维护。

(2)开发多种业务流程的微码版本并存在设备中，现场开局时如果现场功能需求发生变化，则选用合适的微码版本或者升级专门的微码版本。但是这种方法的缺点是在升级过程中由于设备重启不得不中断服务。

(3)采用多网络处理器或者相应的专门硬件进行业务处理功能的分担，减轻单个网络处理器的业务功能处理量，也相应的减少了对网络处理器指令空间的要求。但是，这种方式显然会提高硬件设计的成本。

(4)中国专利号为200610034573.1的专利文件中公开了一种网络处理器动态加载微码的方法，该方法在网络处理器的指令空间中预留一段空间，专门用于运行存放于内存中的非性能敏感性代码，并且将这些非性能敏感性代码分割成能够在预留空间中执行的函数。但是，这种处理方法的缺点也是显而易见的：具有网络处理器开发经验的开发人员都知道，网路处理器中的微码运行是具有严格时序编排的，对其最大的要求就是要快速、高效的转发、查表、业务处理，微码中真正与其转发、业务处理能力不敏感的代码极少，对于网路处理器的微码而言，不可能容忍在运行过程中将某段代码从内存中加载到预留空间中执行后再进入到普通业务流程，这将打乱微码运行的时序，严重降低微码的转发性能，同时这种方法也不能够节省空间，相反为了实现这套加载机制，还要加入很多相关的机制实现代码，预留的空间也是一种变相的浪费。另外，所谓的“非性能敏感性代码”节省起来也没有什么太大的意义，而且这些“非性能敏感性代码”如队列的创建、各种业务表的创建还往往只是在初始化时运行一次，甚至更多的是由上层的控制CPU来代替完成的。

综上所述，现有的技术手段并不能很好的解决下述技术问题：最大限度的利用好网络处理器的有限的指令空间，让有限的指令空间中尽量存放当前设备所需要提供的功能的微码，当设备的运行环境发生变化后，能够动态的更新网络处理器指令空间中的微码以提供相应的功能。

发明内容

有鉴于此，本发明所要解决的技术问题在于提供一种网络处理器动态加载微码的方法，从而可以充分利用网络处理器的有限的指令空间，当设备的运行环境发生变化后，能够在设备运行过程中动态地更新网络处理器指令空间中的微码以提供相应的功能。

为了实现上述发明目的，本发明的主要技术方案为：

一种网络处理器动态加载微码的方法，该方法包括：

编译微码文件，所述微码文件中包括一个以上功能微码，所述每个功能微码对应特定的处理功能；

网络处理器运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中。

优选的，所述网络处理器运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中的具体过程包括：

a、判断网络处理器的微引擎中当前运行的微码是否满足当前的业务要求，若不能满足时，进入步骤b；

b、从所述微码文件中提取符合当前业务要求的功能微码并组装成新的微码加载组合；

c、停止当前微引擎的运行，重新初始化微引擎；

d、将新的微码组合加载到对应的微引擎中，并为微引擎重建队列资源；

e、启动微引擎。

优选的，所述微码文件中包括微引擎的功能微码的分配策略，每种分配策略对应一种业务要求；

步骤b具体为：按照所述当前业务要求从所述微码文件中读取对应的分配策略，按照所述分配策略中记录的功能微码信息及其与微引擎的组合对应信息，从微码文件中提取相应的功能微码，并组合成新的微码组合；并在步骤d中按照所述分配策略中记录的功能微码与微引擎的组合对应信息，将所述微码组合中的各个功能微码加载到所述功能微码对应的微引擎中。

优选的，所述微码文件中包括：

微引擎chunk信息，用于描述每个微引擎的指令代码段在微码文件中的偏移地址以及大小信息；

微引擎字符串表，其中包含了微引擎的功能微码的分配策略；

微引擎指令代码段，其中存储有具体的功能微码的代码；

所述步骤b中，先按照所述当前业务要求从所述微码文件中读取对应的分配策略，再按照分配策略信息从所述微引擎chunk信息定位到对应的微引擎指令代码段，提取所定位的代码段。

优选的，所述编译微码文件的具体方法为：利用网络处理器的微引擎编译对应的功能微码，其中一个微引擎对应编译一个具有特定功能的功能微码，将编译好的功能微码设置在微码文件中。

优选的，一个微码文件中最多包括与所述网络处理器微引擎数量相同的功能微码；在需要超过所述微引擎个数的功能微码时，则进一步编译一个以上的微码文件。

优选的，所述功能微码所占用的存储空间小于或等于微引擎的存储空间。

优选的，所述微码文件的文件格式为.uof格式或.c格式。

本发明预先编译含有多种功能微码的微码文件，并在设备运行过程中，根据当前业务的启用情况，从一个或一个以上微码文件中提取相应的微引擎的功能微码，动态组装成一个新的微码加载组合，然后将这个微码加载组合重新加载的微引擎中，即实现了所谓的“动态加载”功能，可以实现在重新加载过程不需要整个系统硬件重启，而加载本身非常快，因此新旧微码处理流程的几乎无缝切换。这样，在有限的微码指令空间中，尽可能运行与当前业务相关的代码而去掉了与当前业务无关的代码，因此有效的提高了网络处理器的多业务的支持能力。

附图说明

图1为本发明所述微码文件的结构示意图；

图2为本发明实施例所述的第一种微引擎工作组合的示意图；

图3为本发明所述利用微码文件动态加载微码的一种具体实施流程图；

图4为本发明实施例所述的第二种微引擎工作组合的示意图；

图5为本发明实施例所述的第三种微引擎工作组合的示意图；

图6为本发明实施例所述的第四种微引擎工作组合的示意图。

具体实施方式

下面通过具体实施例和附图对本发明做进一步详细说明。

本发明的核心技术方案为一种网络处理器动态加载微码的方法，该方法需要编译微码文件，该微码文件中包括一个以上功能微码，所述每个功能微码对应特定的处理功能；在网络处理器的运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中。

本发明所述的一个功能微码就是一个可以执行特定功能的微码代码，该微码代码被加载到网络处理器的微引擎中，该微引擎启动后就可以运行其内部的微码代码执行特定的功能流程，以对数据进行特定的处理。

本发明适用于并行架构的网络处理器，例如Intel的XP1200、IXP425、IXP2400等。由于IXP1200是并行架构网络处理器中最具有代表性的一种，因此本文中若无特别强调，均默认以IXP1200为例进行说明。

本发明首先要编译微码文件，在实现上通常利用Intel的开发工具Workbench编译微码文件，开发人员需要手工在项目工程设置中设置每个微引擎的功能微码即.list文件，每个.list文件表示一个特定功能的微引擎所运行的微码代码，比如可以分为具有接收(Rx)功能的功能微码rx.list、具有IPV4功能的功能微码ipv4.list、具有发送(Tx)功能的功能微码tx.list等。经过编译后，生成微码文件(.uof)。图1为本发明所述微码文件的结构示意图。参见图1，该微码的文件结构类似于coff、或者pe等通用的文件结构，该微码文件的结构也是分为文件头和文件体，具体包括：

UOF文件标识头101，用于表示当前文件为特定的微码文件，文件标识为0xC2C6，其中还包括该微码文件是否为调试版本，当前微码文件适用的处理器的版本范围等信息。

微引擎chunk信息102，用于描述每个微引擎的指令代码段在本文件中的偏移地址以及大小信息。

微引擎字符串表103，其中包含了微引擎的功能微码的分配策略，这是由Workbench编译时决定的。另外，该微引擎字符串表103还包括了微码程序中申请导入变量的字符串名等。

微引擎指令代码段104，其中存储有具体的功能微码的代码，每个微引擎具体执行的微指令均是通过前面的chunk信息定位到该微引擎指令代码段的，这里的代码内容将加载到微引擎的指令空间中运行。

本发明在微码文件中，设定了每个微引擎的功能微码即功能文件(.list)，并且在微引擎字符串表103中设置了分配策略信息，所述每种分配策略对应一种业务要求，分配策略中包括该业务要求的所需业务流程的各个功能微码信息及其与微引擎的组合对应信息。

比如，IXP1200网络处理器中具有六个微引擎，分别为微引擎0、微引擎1、微引擎2、微引擎3、微引擎4以及微引擎5。微引擎0和1如果设置为rx.list，则表示微引擎0和1将运行接收功能；微引擎2，3设置为ipv4.list，则表示这两个微引擎负责报文的IPv4处理；微引擎4，5设置为tx.list，则这两个引擎用来进行数据报文的发送(tx)处理。微码文件在加载过程中，网络处理器StrongArm上运行的驱动程序会首先完成微引擎硬件的初始化，然后在加载微码文件到微引擎的过程中，从微码文件的文件体的“微引擎字符串表”中获得功能微码的分配策略表，然后加载Rx功能体微码指令到微引擎0和1中，加载IPv4功能的微码指令到微引擎2和3中，加载Tx功能的微码指令到微引擎4和5中，最后形成如图2所示的微引擎工作组合，其中输入的数据经过所述微引擎的接收、IPV1处理、以及发送处理后输出。

通过上述实例可以看出，本发明利用Workbench编译出的微码文件中由编程人员设定了微引擎和.list微码的加载关系，并记录到编译后的微码文件微引擎字符串表103中的分配策略中。每种业务根据实际处理需求都对应有具体的分配策略，该分配策略中记录有功能微码信息及其与微引擎的组合对应信息，例如对于某种业务，需要采用的微引擎和功能微码的组合关系是什么，即什么微引擎加载什么功能微码。网络处理器的驱动层在加载微码的过程中，将根据微引擎字符串表103记录的功能微码分配策略表，为每个微引擎加载对应的功能微码，从而实现对应的业务功能。同时，由于所述分配策略内置于所述微码文件，所以技术人员可以很容易地修改或自定义分配策略，以适应越来越丰富的业务需求。

另外，本发明可以在微码文件中可放置一个以上的功能微码的代码，以适应更多的业务需求。例如，可以利用微引擎0编译rx.list代码，利用微引擎1编译ipv4.list代码，利用微引擎2编译tx.list代码，这三段代码可以设置在所述代码段104中，并且可以通过分配策略设置不同的组合方式，从而可以根据不同的组合方式从代码段104中提取对应的代码组成对应的微码加载组合。

本发明中，可以将编译出来的微码文件看作是多个功能微码(.list)的容器。在编译微码文件时，利用网络处理器的微引擎编译对应的功能微码，其中一个微引擎对应编译一个具有特定功能的功能微码。因此，一个微码文件中最多可以拥有与微引擎个数相同数量的功能微码，例如IXP1200有6个微引擎，因此最多可以拥有6个不同功能单元的功能微码，而IXP2400相应就有8个。如果需要获得超过微引擎实际个数的功能微码，例如IXP1200上希望超过有6个功能单元的微码，则可以进一步编译一个以上的微码文件。例如使用Workbench将微码文件编译成.c文件，微码文件在.c文件中是以数组的形式提供，那么只需要提供n个.c文件，就可以拥有n*6这么多个功能微码。当然也可以不采用.c文件格式，直接采用uof文件格式也可以同样达到该效果。

图3为本发明所述利用微码文件动态加载微码的一种具体实施流程图。参见图3，该流程在不需要重启整个系统硬件的情况下就可以实现不同业务对应微码的动态加载，具体包括：

步骤301、根据操作人员对当前设备的功能配置，由StrongArm上的驱动层判断网络处理器的微引擎中当前运行的微码是否满足当前的业务要求，在不能满足时进入步骤302；在能够满足时返回步骤301。

步骤302、驱动层从所述微码文件中提取符合当前业务要求的功能微码并组装成新的微码加载组合。具体为：按照所述当前业务要求从所述微码文件中读取对应的分配策略，按照该分配策略中记录的功能微码信息及其与微引擎的组合对应信息，从微码文件中提取相应的功能微码，并组合成新的微码组合。

步骤303、驱动层停止当前微引擎的运行，重新初始化微引擎；

步骤304、将所述新的微码组合加载到对应的微引擎中，即：按照所述分配策略中记录的功能微码与微引擎的组合对应信息，将所述微码组合中的各个功能微码加载到该功能微码对应的微引擎中；并为微引擎重建各种队列资源。

步骤305、重新启动微引擎的运行，则微引擎按照新的微码加载组合的功能流程进行数据包的处理。

下面以接入路由器为例，通过一个具体的实施例来进一步说明本发明的方案。

在接入路由器的功能需求中，接入路由器需要完成报文的接收、分类、ACL、NAT、IPv4转发，MPLS转发、组播、以及发送等功能，在IXP1200每个微引擎有限的2K条指令存储空间内实现这么多业务功能显然是不现实也是不可能的。因此采用本发明所提出的微码动态加载机制，首先进行微引擎功能微码的编译，根据业务应用的频率和微码空间，可以编译出如下六种功能微码：

Rx功能微码(rx.list)：实现报文的接收，分类和普通的IPv4转发处理。

ACL功能微码(acl.list)：实现报文的访问控制列表功能。

NAT功能微码(nat.list)：实现报文的网络地址翻译功能。

MPLS功能微码(mpls.list)：实现报文的标签转发功能。

组播(Multicast)功能微码(multicast.list)：实现报文的组播转发功能。

Tx功能微码(tx.list)：实现报文的发送队列调度，封包，发送功能。

上述每个功能微码即list代码都不超过2K条。在编译微码文件时，利用网络处理器的微引擎编译对应的功能微码，其中一个微引擎对应编译一个具有特定功能的功能微码，例如此处设定微引擎0对应编译rx.list，微引擎1对应编译acl.list，微引擎2对应编译nat.list，微引擎3对应编译mpls.list，微引擎4对应编译multicast.list，微引擎5对应编译tx.list，将编译好的功能微码设置在微码文件中。这样编译出来的微码文件中就含有了上述的6个功能list的代码，因此微码的功能list容器中就有了这6种功能list代码。

在系统启动完毕后，可以采用默认加载策略进行加载。默认的加载策略如下，微引擎0、1、2和3加载rx.list代码，微引擎4和5加载tx.list代码，这样经过组合后，系统微码可以进行基本的IPv4转发处理流程，如附图4所示，其中Ingress表示输入，Egress表示输出。

当设备上由网络维护人员启用了MPLS功能后，StrongArm上的驱动层发现当前运行在微引擎中的功能list为rx.list和tx.list，其业务流程不支持MPLS功能，同时发现微码文件中存在支持MPLS转发功能的mpls.list功能体，因此从微码文件中取出rx.list，mpls.list，tx.list重新组合称为一套新的微码业务流程，可以选择的如下的分配策略：微引擎0、1加载rx.list，微引擎2、3加载mpls.list，微引擎4、5加载tx.list，这样形成的微码转发流程如附图4所示，从而可以进行MPLS的处理流程，满足当前的业务需要。

当设备上网络管理人员又启用了组播功能后，StrongArm则又重新进行微码的组装，可以选择如下的分配策略：微引擎0、1加载rx.list，微引擎2加载mpls.list，微引擎3加载multicast.list，微引擎4、5加载tx.list，新的微码转发流程如图5所示，从而可以进行组播处理流程。

通过上述实例可以清楚地了解到，微码动态加载机制的关键是放弃了由编译本身带来的微引擎的功能分配策略，本发明中采用了自定义的分配策略，仅仅将微码文件定义为一个功能微码的容器，这样根据代码的耦合度和功能代码的实际大小，事先开发出不超过微引擎存储空间的各种功能微码，在实际使用过程中，根据设备的功能启用情况，从功能微码容器中抽取合适的功能代码重新组合成新的微码流程。微码动态加载的另一个显著优点就是避免的设备的重新启动，由于重新加载微码只发生在设备驱动层，上层的业务处理不受影响。

以上所述，仅为本发明较佳的具体实施方式，但本发明的保护范围并不局限于此，任何熟悉该技术的人在本发明所揭露的技术范围内，可轻易想到的变化或替换，都应涵盖在本发明的保护范围之内。

Claims (8)

1、一种网络处理器动态加载微码的方法，其特征在于，

编译微码文件，所述微码文件中包括一个以上功能微码，所述每个功能微码对应特定的处理功能；

网络处理器运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中。

2、根据权利要求1所述的方法，其特征在于，所述网络处理器运行过程中，根据当前业务的启用情况，从所述微码文件中提取相应微引擎对应的功能微码，加载到对应的微引擎中的具体过程包括：

a、判断网络处理器的微引擎中当前运行的微码是否满足当前的业务要求，若不能满足时，进入步骤b；

b、从所述微码文件中提取符合当前业务要求的功能微码并组装成新的微码加载组合；

c、停止当前微引擎的运行，重新初始化微引擎；

d、将新的微码组合加载到对应的微引擎中，并为微引擎重建队列资源；

e、启动微引擎。

3、根据权利要求2所述的方法，其特征在于，所述微码文件中包括微引擎的功能微码的分配策略，每种分配策略对应一种业务要求；

步骤b具体为：按照所述当前业务要求从所述微码文件中读取对应的分配策略，按照所述分配策略中记录的功能微码信息及其与微引擎的组合对应信息，从微码文件中提取相应的功能微码，并组合成新的微码组合；并在步骤d中按照所述分配策略中记录的功能微码与微引擎的组合对应信息，将所述微码组合中的各个功能微码加载到所述功能微码对应的微引擎中。

4、根据权利要求2所述的方法，其特征在于，所述微码文件中包括：

微引擎chunk信息，用于描述每个微引擎的指令代码段在微码文件中的偏移地址以及大小信息；

微引擎字符串表，其中包含了微引擎的功能微码的分配策略；

微引擎指令代码段，其中存储有具体的功能微码的代码；

所述步骤b中，先按照所述当前业务要求从所述微码文件中读取对应的分配策略，再按照分配策略信息从所述微引擎chunk信息定位到对应的微引擎指令代码段，提取所定位的代码段。

5、根据权利要求1所述的方法，其特征在于，所述编译微码文件的具体方法为：利用网络处理器的微引擎编译对应的功能微码，其中一个微引擎对应编译一个具有特定功能的功能微码，将编译好的功能微码设置在微码文件中。

6、根据权利要求5所述的方法，其特征在于，一个微码文件中最多包括与所述网络处理器微引擎数量相同的功能微码；在需要超过所述微引擎个数的功能微码时，则进一步编译一个以上的微码文件。

7、根据权利要求1所述的方法，其特征在于，所述功能微码所占用的存储空间小于或等于微引擎的存储空间。

8、根据权利要求1所述的方法，其特征在于，所述微码文件的文件格式为.uof格式或.c格式。

Images