專利名稱：網(wǎng)絡(luò)處理器動態(tài)加載微碼的方法
技術(shù)領(lǐng)域：
本發(fā)明涉及網(wǎng)絡(luò)通信技術(shù)，尤其涉及一種網(wǎng)絡(luò)處理器動態(tài)加栽微碼的方法。
背景技術(shù)：
在現(xiàn)在的網(wǎng)絡(luò)通信領(lǐng)域中，伴隨著移動多媒體子系統(tǒng)(IMS)、第三代 (3G)通信技術(shù)的快速發(fā)展，基于IP的開放式下一代網(wǎng)絡(luò)技術(shù)的出現(xiàn)，各 種新協(xié)議、新業(yè)務(wù)層出不窮，網(wǎng)絡(luò)規(guī)模膨脹性增長，用戶對帶寬需求的急速 增加。這對設(shè)備提供商而言，提出了嚴(yán)峻的現(xiàn)實(shí)挑戰(zhàn)，即如何快速靈活的 推出對新業(yè)務(wù)的支持，如何保證服務(wù)質(zhì)量不被降低，如何提升產(chǎn)品的個性化 水平等等。傳統(tǒng)的基于單CPU的軟件架構(gòu)的網(wǎng)絡(luò)設(shè)備，雖然在快速推出新業(yè)務(wù)， 支持新協(xié)議方面具有優(yōu)勢，但是其處理能力卻很難滿足網(wǎng)絡(luò)的需求。而基于 專用集成電路(ASIC)的網(wǎng)絡(luò)設(shè)備，處理能力雖然高效，但卻不具有支持 新業(yè)務(wù)功能的可編程性。而網(wǎng)絡(luò)處理器(NP ， Programmable Network Processor)的出現(xiàn)，則在速度和可編程性上給設(shè)計人員 一種極好的選擇。網(wǎng) 絡(luò)處理器具備完全的可編程能力，可以實(shí)現(xiàn)OSI網(wǎng)絡(luò)協(xié)議棧2 7層的處理， 支持對信元、分組數(shù)據(jù)流等多種協(xié)議數(shù)據(jù)類型的處理，其強(qiáng)大的處理能力可 以實(shí)現(xiàn)高帶寬的線速處理能力，其開放的高度集成的體系結(jié)構(gòu)使得基于網(wǎng)絡(luò) 處理器的網(wǎng)絡(luò)設(shè)備易于系統(tǒng)擴(kuò)展。IXP1200網(wǎng)絡(luò)處理器(由Intel公司推出的)是一種互聯(lián)網(wǎng)交換架構(gòu)的 網(wǎng)絡(luò)處理器，它由一個硬核(StrongARM)處理器、六個微引擎(ME， Microenginer)、存儲器接口和高速總線接口組成。IXP1200的主要功能模塊和體系結(jié)構(gòu)的主要特征是l)并行處理器結(jié)構(gòu)，StrongARM處理器和6 個微引擎均為精簡指令集計算(RISC)處理器，并行工作；2) StrongARM 處理器運(yùn)行BSP、驅(qū)動程序、實(shí)時操作系統(tǒng)、路由表維護(hù)及上層應(yīng)用程序， 完成地址學(xué)習(xí)、轉(zhuǎn)發(fā)表的生成與維護(hù)和網(wǎng)絡(luò)管理等任務(wù)。3) 6個微引擎是 32位的可編程RISC，在微引擎的指令空間上運(yùn)行有微碼(Microcode)，通 過運(yùn)行微碼可進(jìn)行數(shù)據(jù)流輸入/輸出、打包/拆包、分類、快速查表、轉(zhuǎn)發(fā)等 實(shí)時處理，微引擎由StrongArm處理器負(fù)責(zé)初始化并加載微碼執(zhí)行。雖然類似IXP1200這樣的具有并行處理架構(gòu)的網(wǎng)絡(luò)處理器具有上述特 點(diǎn)，但是在實(shí)際的使用過程中，還是有以下缺陷這種網(wǎng)絡(luò)處理器的微引擎指令空間已經(jīng)不能夠滿足業(yè)務(wù)發(fā)展的需要。 IXP1200最初的版本中每個微引擎都具有各自獨(dú)立的1K條微碼指令空間， 后來推出了 2K條微碼指令空間的IXP1200網(wǎng)絡(luò)處理器版本。不過即使如此， 在系統(tǒng)設(shè)計、編程開發(fā)方面仍然會由于微碼指令空間狹小而造成不便。比如， 在邊緣路由器的設(shè)計中，需要支持的業(yè)務(wù)種類極為繁雜，如訪問控制列表 (ACL)業(yè)務(wù)，網(wǎng)絡(luò)地址翻譯(NAT)業(yè)務(wù)，服務(wù)質(zhì)量(Qos),路由圖 (Route-map),多協(xié)議標(biāo)簽交換虛擬專用網(wǎng)(MPLS VPN) ， IPv4, IPv6 等等業(yè)務(wù)；還有在DSLAM網(wǎng)關(guān)設(shè)計中，IXP1200除了承擔(dān)基本的路由轉(zhuǎn)發(fā)， 還要包括與用戶認(rèn)證相關(guān)的Bras功能的開發(fā)，在這些開發(fā)過程中，IXP1200 網(wǎng)絡(luò)處理器的指令空間遠(yuǎn)遠(yuǎn)不能滿足業(yè)務(wù)發(fā)展的需要。目前，在開發(fā)過程中往往需要在一套微碼中支持更多的業(yè)務(wù)功能，但微 碼空間又不允許。實(shí)際開局中，根據(jù)不同的應(yīng)用場合，有些功能需要，有些 功能并不需要，不需要的功能就浪費(fèi)了有限的微碼指令空間。為了解決由于 網(wǎng)絡(luò)處理器指令空間的限制對設(shè)備多業(yè)務(wù)功能支持的影響，現(xiàn)有的解決方法 主要包括以下幾種(1)根據(jù)設(shè)備的開局功能需求，開發(fā)滿足該局點(diǎn)需求的微碼版本，刪 除掉該局點(diǎn)不需要的微碼代碼以節(jié)省微碼空間。這種方法的缺點(diǎn)是會導(dǎo)致開 發(fā)的微碼版本越來越多，越來越難以維護(hù)。(2) 開發(fā)多種業(yè)務(wù)流程的微碼版本并存在設(shè)備中，現(xiàn)場開局時如果現(xiàn) 場功能需求發(fā)生變化，則選用合適的微碼版本或者升級專門的微碼版本。但 是這種方法的缺點(diǎn)是在升級過程中由于設(shè)備重啟不得不中斷服務(wù)。(3) 采用多網(wǎng)絡(luò)處理器或者相應(yīng)的專門硬件進(jìn)行業(yè)務(wù)處理功能的分擔(dān)， 減輕單個網(wǎng)絡(luò)處理器的業(yè)務(wù)功能處理量，也相應(yīng)的減少了對網(wǎng)絡(luò)處理器指令 空間的要求。但是，這種方式顯然會提高硬件設(shè)計的成本。(4) 中國專利號為200610034573.1的專利文件中公開了 一種網(wǎng)絡(luò)處理 器動態(tài)加載微碼的方法，該方法在網(wǎng)絡(luò)處理器的指令空間中預(yù)留一段空間， 專門用于運(yùn)行存放于內(nèi)存中的非性能敏感性代碼，并且將這些非性能敏感性 代碼分割成能夠在預(yù)留空間中執(zhí)行的函數(shù)。但是，這種處理方法的缺點(diǎn)也是 顯而易見的具有網(wǎng)絡(luò)處理器開發(fā)經(jīng)驗(yàn)的開發(fā)人員都知道，網(wǎng)路處理器中的 微碼運(yùn)行是具有嚴(yán)格時序編排的，對其最大的要求就是要快速、高效的轉(zhuǎn)發(fā)、 查表、業(yè)務(wù)處理，微碼中真正與其轉(zhuǎn)發(fā)、業(yè)務(wù)處理能力不敏感的代碼極少， 對于網(wǎng)路處理器的微碼而言，不可能容忍在運(yùn)行過程中將某段代碼從內(nèi)存中 加載到預(yù)留空間中執(zhí)行后再進(jìn)入到普通業(yè)務(wù)流程，這將打亂微碼運(yùn)行的時 序，嚴(yán)重降低微碼的轉(zhuǎn)發(fā)性能，同時這種方法也不能夠節(jié)省空間，相反為了 實(shí)現(xiàn)這套加載機(jī)制，還要加入很多相關(guān)的機(jī)制實(shí)現(xiàn)代碼，預(yù)留的空間也是一 種變相的浪費(fèi)。另外，所謂的"非性能敏感性代碼"節(jié)省起來也沒有什么太大 的意義，而且這些"非性能敏感性代碼"如隊列的創(chuàng)建、各種業(yè)務(wù)表的創(chuàng)建還 往往只是在初始化時運(yùn)行一次，甚至更多的是由上層的控制CPU來代替完 成的。綜上所述，現(xiàn)有的技術(shù)手段并不能很好的解決下述技術(shù)問題最大限度 的利用好網(wǎng)絡(luò)處理器的有限的指令空間，讓有限的指令空間中盡量存放當(dāng)前 設(shè)備所需要提供的功能的微碼，當(dāng)設(shè)備的運(yùn)行環(huán)境發(fā)生變化后，能夠動態(tài)的 更新網(wǎng)絡(luò)處理器指令空間中的微碼以提供相應(yīng)的功能。發(fā)明內(nèi)容有鑒于此，本發(fā)明所要解決的技術(shù)問題在于提供一種網(wǎng)絡(luò)處理器動態(tài)加 載微碼的方法，從而可以充分利用網(wǎng)絡(luò)處理器的有限的指令空間，當(dāng)設(shè)備的 運(yùn)行環(huán)境發(fā)生變化后，能夠在設(shè)備運(yùn)行過程中動態(tài)地更新網(wǎng)絡(luò)處理器指令空 間中的微碼以提供相應(yīng)的功能。為了實(shí)現(xiàn)上述發(fā)明目的，本發(fā)明的主要技術(shù)方案為一種網(wǎng)絡(luò)處理器動態(tài)加載微碼的方法，該方法包括編譯微碼文件，所述微碼文件中包括一個以上功能微碼，所述每個功能 微碼對應(yīng)特定的處理功能；網(wǎng)絡(luò)處理器運(yùn)行過程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從所述微碼文件中 提取相應(yīng)微引擎對應(yīng)的功能微碼，加載到對應(yīng)的微引擎中。優(yōu)選的，所述網(wǎng)絡(luò)處理器運(yùn)行過程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從所 述微碼文件中提取相應(yīng)微引擎對應(yīng)的功能微碼，加載到對應(yīng)的微引擎中的具 體過程包括a、 判斷網(wǎng)絡(luò)處理器的微引擎中當(dāng)前運(yùn)行的微碼是否滿足當(dāng)前的業(yè)務(wù)要 求，若不能滿足時，進(jìn)入步驟b;b、 從所述微碼文件中提取符合當(dāng)前業(yè)務(wù)要求的功能微碼并組裝成新的 微碼加載組合；c、 停止當(dāng)前微引擎的運(yùn)行，重新初始化微引擎；d、 將新的微碼組合加載到對應(yīng)的微引擎中，并為微引擎重建隊列資源；e、 啟動微引擎。優(yōu)選的，所述微碼文件中包括微引擎的功能微碼的分配策略，每種分配 策略對應(yīng)一種業(yè)務(wù)要求；步驟b具體為按照所述當(dāng)前業(yè)務(wù)要求從所述微碼文件中讀取對應(yīng)的分 配策略，按照所述分配策略中記錄的功能微碼信息及其與微引擎的組合對應(yīng) 信息，從微碼文件中提取相應(yīng)的功能微碼，并組合成新的微碼組合；并在步驟d中按照所述分配策略中記錄的功能微碼與微引擎的組合對應(yīng)信息，將所 述微碼組合中的各個功能微碼加載到所述功能微碼對應(yīng)的微引擎中。優(yōu)選的，所迷微碼文件中包括微引擎chunk信息，用于描述每個微引擎的指令代碼段在微碼文件中的偏移地址以及大小信息；微引擎字符串表，其中包含了微引擎的功能微碼的分配策略；微引擎指令代碼段，其中存儲有具體的功能微碼的代碼；所述步驟b中，先按照所述當(dāng)前業(yè)務(wù)要求從所述微碼文件中讀取對應(yīng)的分配策略，再按照分配策略信息從所述微引擎chunk信息定位到對應(yīng)的微引擎指令代碼段，提取所定位的代碼段。優(yōu)選的，所述編譯微碼文件的具體方法為利用網(wǎng)絡(luò)處理器的微引擎編譯對應(yīng)的功能微碼，其中 一個微引擎對應(yīng)編譯一個具有特定功能的功能微碼，將編譯好的功能微碼設(shè)置在微碼文件中。優(yōu)選的， 一個微碼文件中最多包括與所迷網(wǎng)絡(luò)處理器微引擎數(shù)量相同的 功能微碼；在需要超過所述微引擎?zhèn)€數(shù)的功能微碼時，則進(jìn)一步編譯一個以 上的微碼文件。優(yōu)選的，所述功能微碼所占用的存儲空間小于或等于微引擎的存儲空間。優(yōu)選的，所述孩l碼文件的文件格式為.uof格式或.c格式。 本發(fā)明預(yù)先編譯含有多種功能微碼的微碼文件，并在設(shè)備運(yùn)行過程中， 根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從一 個或 一個以上微碼文件中提取相應(yīng)的微引擎 的功能微碼，動態(tài)組裝成一個新的微碼加載組合，然后將這個微碼加載組合 重新加載的微引擎中，即實(shí)現(xiàn)了所謂的"動態(tài)加載，，功能，可以實(shí)現(xiàn)在重新加 載過程不需要整個系統(tǒng)硬件重啟，而加載本身非?？?，因此新舊微碼處理流 程的幾乎無縫切換。這樣，在有限的微碼指令空間中，盡可能運(yùn)行與當(dāng)前業(yè) 務(wù)相關(guān)的代碼而去掉了與當(dāng)前業(yè)務(wù)無關(guān)的代碼，因此有效的提高了網(wǎng)絡(luò)處理 器的多業(yè)務(wù)的支持能力。


圖1為本發(fā)明所述微碼文件的結(jié)構(gòu)示意圖；圖2為本發(fā)明實(shí)施例所述的第 一 種微引擎工作組合的示意圖；圖3為本發(fā)明所述利用微碼文件動態(tài)加載微碼的一種具體實(shí)施流程圖；圖4為本發(fā)明實(shí)施例所述的第二種微引擎工作組合的示意圖；圖5為本發(fā)明實(shí)施例所述的第三種微引擎工作組合的示意圖；圖6為本發(fā)明實(shí)施例所述的第四種微引擎工作組合的示意圖。
具體實(shí)施方式
下面通過具體實(shí)施例和附圖對本發(fā)明做進(jìn)一步詳細(xì)說明。 本發(fā)明的核心技術(shù)方案為 一種網(wǎng)絡(luò)處理器動態(tài)加載微碼的方法，該方法 需要編譯微碼文件，該微碼文件中包括一個以上功能微碼，所述每個功能微碼對應(yīng)特定的處理功能；在網(wǎng)絡(luò)處理器的運(yùn)行過程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用 情況，從所述微碼文件中提取相應(yīng)微引擎對應(yīng)的功能微碼，加載到對應(yīng)的微 引擎中。本發(fā)明所述的 一 個功能微碼就是一 個可以執(zhí)行特定功能的微碼代碼，該 微碼代碼被加載到網(wǎng)絡(luò)處理器的微引擎中，該微引擎啟動后就可以運(yùn)行其內(nèi) 部的微碼代碼執(zhí)行特定的功能流程，以對數(shù)據(jù)進(jìn)行特定的處理。本發(fā)明適用于并行架構(gòu)的網(wǎng)絡(luò)處理器，例如Intel的XP1200、 IXP425、 IXP2400等。由于IXP1200是并行架構(gòu)網(wǎng)絡(luò)處理器中最具有代表性的一種， 因此本文中若無特別強(qiáng)調(diào)，均默認(rèn)以IXP1200為例進(jìn)行說明。本發(fā)明首先要編譯微碼文件，在實(shí)現(xiàn)上通常利用Intel的開發(fā)工具 Workbench編譯微碼文件，開發(fā)人員需要手工在項(xiàng)目工程設(shè)置中設(shè)置每個微 引擎的功能微碼即.list文件，每個.list文件表示一個特定功能的微引擎所運(yùn) 行的微碼代碼，比如可以分為具有接收(Rx)功能的功能微碼rx.list、具有 IPV4功能的功能微碼ipv4.1ist、具有發(fā)送(Tx)功能的功能微碼tx.list等。 經(jīng)過編譯后，生成微碼文件(.uof)。圖1為本發(fā)明所述微碼文件的結(jié)構(gòu)示意圖。參見圖1，該微碼的文件結(jié)構(gòu)類似于coff、或者pe等通用的文件結(jié)構(gòu)， 該微碼文件的結(jié)構(gòu)也是分為文件頭和文件體，具體包括UOF文件標(biāo)識頭101，用于表示當(dāng)前文件為特定的微碼文件，文件標(biāo)識 為0xC2C6，其中還包括該微碼文件是否為調(diào)試版本，當(dāng)前微碼文件適用的 處理器的版本范圍等信息。微引擎chimk信息102,用于描述每個微引擎的指令代碼段在本文件中 的偏移地址以及大小信息。微引擎字符串表103,其中包含了微引擎的功能微碼的分配策略，這是 由Workbench編譯時決定的。另外，該微引擎字符串表103還包括了微碼程 序中申請導(dǎo)入變量的字符串名等。微引擎指令代碼段104,其中存儲有具體的功能微碼的代碼，每個微引 擎具體執(zhí)行的微指令均是通過前面的chunk信息定位到該微引擎指令代碼段 的，這里的代碼內(nèi)容將加載到微引擎的指令空間中運(yùn)行。本發(fā)明在微碼文件中，設(shè)定了每個微引擎的功能微碼即功能文件(.list )， 并且在微引擎字符串表103中設(shè)置了分配策略信息，所述每種分配策略對應(yīng) 一種業(yè)務(wù)要求，分配策略中包括該業(yè)務(wù)要求的所需業(yè)務(wù)流程的各個功能微碼 信息及其與微引擎的組合對應(yīng)信息。比如，IXP1200網(wǎng)絡(luò)處理器中具有六個微引擎，分別為微引擎0、微引 擎1、微引擎2、微引擎3、微引擎4以及微引擎5。微引擎0和1如果設(shè)置 為rx.list,則表示微引擎0和1將運(yùn)行接收功能；微引擎2，3設(shè)置為ipv4.1ist， 則表示這兩個微引擎負(fù)責(zé)報文的IPv4處理；微引擎4， 5設(shè)置為tx.list，則 這兩個引擎用來進(jìn)行數(shù)據(jù)報文的發(fā)送(tx)處理。微碼文件在加載過程中， 網(wǎng)絡(luò)處理器StrongArm上運(yùn)行的驅(qū)動程序會首先完成微引擎硬件的初始化， 然后在加載微碼文件到微引擎的過程中，從微碼文件的文件體的"微引擎字 符串表，，中獲得功能微碼的分配策略表，然后加載Rx功能體微碼指令到微引 擎0和1中，加載IPv4功能的微碼指令到微引擎2和3中，加載Tx功能的 微碼指令到微引擎4和5中，最后形成如圖2所示的微引擎工作組合，其中輸入的數(shù)據(jù)經(jīng)過所述微引擎的接收、IPV1處理、以及發(fā)送處理后輸出。通過上述實(shí)例可以看出，本發(fā)明利用Workbench編譯出的微碼文件中由 編程人員設(shè)定了微引擎和.list微碼的加載關(guān)系，并記錄到編譯后的微碼文件 微引擎字符串表103中的分配策略中。每種業(yè)務(wù)根據(jù)實(shí)際處理需求都對應(yīng)有 具體的分配策略，該分配策略中記錄有功能微碼信息及其與微引擎的組合對 應(yīng)信息，例如對于某種業(yè)務(wù)，需要釆用的微引擎和功能微碼的組合關(guān)系是什 么，即什么微引擎加載什么功能微碼。網(wǎng)絡(luò)處理器的驅(qū)動層在加載微碼的過 程中，將根據(jù)微引擎字符串表103記錄的功能微碼分配策略表，為每個微引 擎加載對應(yīng)的功能微碼，從而實(shí)現(xiàn)對應(yīng)的業(yè)務(wù)功能。同時，由于所述分配策 略內(nèi)置于所述微碼文件，所以技術(shù)人員可以很容易地修改或自定義分配策 略，以適應(yīng)越來越豐富的業(yè)務(wù)需求。另外，本發(fā)明可以在微碼文件中可放置一個以上的功能微碼的代碼，以 適應(yīng)更多的業(yè)務(wù)需求。例如，可以利用微引擎O編譯rx.list代碼，利用微引 擎1編譯ipv4.1ist代碼，利用微引擎2編譯tx.list代碼，這三段代碼可以設(shè) 置在所述代碼段104中，并且可以通過分配策略設(shè)置不同的組合方式，從而 可以根據(jù)不同的組合方式從代碼段104中提取對應(yīng)的代碼組成對應(yīng)的微碼 加載組合。本發(fā)明中，可以將編譯出來的微碼文件看作是多個功能微碼(.list)的容器。在編譯微碼文件時，利用網(wǎng)絡(luò)處理器的微引擎編譯對應(yīng)的功能微碼，其中一個微引擎對應(yīng)編譯一個具有特定功能的功能微碼。因此， 一個微碼文件中最多可以擁有與微引擎?zhèn)€數(shù)相同數(shù)量的功能微碼，例如IXP1200有6個微引擎，因此最多可以擁有6個不同功能單元的功能微碼，而IXP2400相應(yīng)就有8個。如果需要獲得超過微引擎實(shí)際個數(shù)的功能微碼，例如IXP 1200上希望超過有6個功能單元的微碼，則可以進(jìn)一步編譯一個以上的微碼文件。例如使用Workbench將微碼文件編譯成.c文件，微碼文件在.c文件中是以數(shù)組的形式提供，那么只需要提供n個.c文件，就可以擁有n*6這么多個功能微碼。當(dāng)然也可以不采用.c文件格式，直接采用uof文件格式也可以同樣達(dá)到該效果。圖3為本發(fā)明所述利用微碼文件動態(tài)加載微碼的一種具體實(shí)施流程圖。參見圖3,該流程在不需要重啟整個系統(tǒng)硬件的情況下就可以實(shí)現(xiàn)不同業(yè)務(wù) 對應(yīng)微碼的動態(tài)加載，具體包括步驟301、根據(jù)操作人員對當(dāng)前設(shè)備的功能配置，由StrongArm上的驅(qū) 動層判斷網(wǎng)絡(luò)處理器的微引擎中當(dāng)前運(yùn)行的微碼是否滿足當(dāng)前的業(yè)務(wù)要求， 在不能滿足時進(jìn)入步驟302;在能夠滿足時返回步驟301。步驟302、驅(qū)動層從所述微碼文件中提取符合當(dāng)前業(yè)務(wù)要求的功能微碼 并組裝成新的微碼加載組合。具體為按照所述當(dāng)前業(yè)務(wù)要求從所述微碼文 件中讀取對應(yīng)的分配策略，按照該分配策略中記錄的功能微碼信息及其與微 引擎的組合對應(yīng)信息，從微碼文件中提取相應(yīng)的功能微碼，并組合成新的微 碼組合。步驟303、驅(qū)動層停止當(dāng)前微引擎的運(yùn)行，重新初始化微引擎； 步驟304、將所述新的微碼組合加載到對應(yīng)的微引擎中，即按照所述 分配策略中記錄的功能微碼與微引擎的組合對應(yīng)信息，將所述微碼組合中的 各個功能微碼加載到該功能微碼對應(yīng)的微引擎中；并為微引擎重建各種隊列 資源。步驟305、重新啟動微引擎的運(yùn)行，則微引擎按照新的微碼加載組合的 功能流程進(jìn)行數(shù)據(jù)包的處理。下面以接入路由器為例，通過一個具體的實(shí)施例來進(jìn)一步說明本發(fā)明的 方案。在接入路由器的功能需求中，接入路由器需要完成報文的接收、分類、 ACL、 NAT、 IPv4轉(zhuǎn)發(fā)，MPLS轉(zhuǎn)發(fā)、組播、以及發(fā)送等功能，在IXP1200 每個微引擎有限的2K條指令存儲空間內(nèi)實(shí)現(xiàn)這么多業(yè)務(wù)功能顯然是不現(xiàn)實(shí) 也是不可能的。因此采用本發(fā)明所提出的微碼動態(tài)加載機(jī)制，首先進(jìn)行微引 擎功能微碼的編譯，根據(jù)業(yè)務(wù)應(yīng)用的頻率和微碼空間，可以編譯出如下六種 功能微碼Rx功能微碼(rx.list):實(shí)現(xiàn)報文的接收，分類和普通的IPv4轉(zhuǎn)發(fā)處理。 ACL功能微碼(acl.list):實(shí)現(xiàn)報文的訪問控制列表功能。 NAT功能微碼(nat.list):實(shí)現(xiàn)報文的網(wǎng)絡(luò)地址翻譯功能。 MPLS功能微碼(mpls.list):實(shí)現(xiàn)報文的標(biāo)簽轉(zhuǎn)發(fā)功能。 組播(Multicast)功能微碼(multicast.list):實(shí)現(xiàn)報文的組播轉(zhuǎn)發(fā)功能。 Tx功能微碼(tx.list):實(shí)現(xiàn)報文的發(fā)送隊列調(diào)度，封包，發(fā)送功能。 上述每個功能微碼即list代碼都不超過2K條。在編譯微碼文件時，利 用網(wǎng)絡(luò)處理器的微引擎編譯對應(yīng)的功能微碼，其中 一個微引擎對應(yīng)編譯一個 具有特定功能的功能微碼，例如此處設(shè)定微引擎O對應(yīng)編譯rx.list,微引擎 1對應(yīng)編譯acl.list，微引擎2對應(yīng)編譯nat.list,微引擎3對應(yīng)編譯mpls.list, 微引擎4對應(yīng)編譯multicast.list,微引擎5對應(yīng)編譯tx.list，將編譯好的功能 微碼設(shè)置在微碼文件中。這樣編譯出來的微碼文件中就含有了上述的6個功 能list的代碼，因此微碼的功能list容器中就有了這6種功能list代碼。在系統(tǒng)啟動完畢后，可以采用默認(rèn)加載策略進(jìn)行加載。默認(rèn)的加載策略 如下，微引擎O、 1、 2和3加載rx.list代碼，微引擎4和5加載tx.list代碼， 這樣經(jīng)過組合后，系統(tǒng)微碼可以進(jìn)行基本的IPv4轉(zhuǎn)發(fā)處理流程，如附圖4 所示，其中Ingress表示輸入，Egress表示輸出。當(dāng)設(shè)備上由網(wǎng)絡(luò)維護(hù)人員啟用了 MPLS功能后，StrongArm上的驅(qū)動層 發(fā)現(xiàn)當(dāng)前運(yùn)行在微引擎中的功能list為rx.list和tx.list，其業(yè)務(wù)流程不支持 MPLS功能，同時發(fā)現(xiàn)微碼文件中存在支持MPLS轉(zhuǎn)發(fā)功能的mpls.list功能 體，因此從微碼文件中取出rx.list, mpls.list, tx.list重新組合稱為一套新的 微碼業(yè)務(wù)流程，可以選擇的如下的分配策略微引擎O、 l加載rx.list,微引 擎2、 3加載mpls.list,微引擎4、 5加載tx.list,這樣形成的微碼轉(zhuǎn)發(fā)流程 如附圖4所示，從而可以進(jìn)行MPLS的處理流程，滿足當(dāng)前的業(yè)務(wù)需要。當(dāng)設(shè)備上網(wǎng)絡(luò)管理人員又啟用了組播功能后，StrongArm則又重新進(jìn)行 微碼的組裝，可以選擇如下的分配策略微引擎O、 l加載rx.list,微引擎2 加載mpls.list,微引擎3加載multicast.list,微引擎4、 5加載tx.list,新的微碼轉(zhuǎn)發(fā)流程如圖5所示，從而可以進(jìn)行組播處理流程。通過上述實(shí)例可以清楚地了解到，微碼動態(tài)加載機(jī)制的關(guān)鍵是放棄了由 編譯本身帶來的微引擎的功能分配策略，本發(fā)明中采用了自定義的分配策略，僅僅將微碼文件定義為一個功能微碼的容器，這樣根據(jù)代碼的耦合度和 功能代碼的實(shí)際大小，事先開發(fā)出不超過微引擎存儲空間的各種功能微碼， 在實(shí)際使用過程中，根據(jù)設(shè)備的功能啟用情況，從功能微碼容器中抽取合適 的功能代碼重新組合成新的微碼流程。微碼動態(tài)加載的另 一 個顯著優(yōu)點(diǎn)就是 避免的設(shè)備的重新啟動，由于重新加載微碼只發(fā)生在設(shè)備驅(qū)動層，上層的業(yè) 務(wù)處理不受影響。以上所述，僅為本發(fā)明較佳的具體實(shí)施方式
，但本發(fā)明的保護(hù)范圍并不 局限于此，任何熟悉該技術(shù)的人在本發(fā)明所揭露的技術(shù)范圍內(nèi)，可輕易想到 的變化或替換，都應(yīng)涵蓋在本發(fā)明的保護(hù)范圍之內(nèi)。
權(quán)利要求
1、一種網(wǎng)絡(luò)處理器動態(tài)加載微碼的方法，其特征在于，編譯微碼文件，所述微碼文件中包括一個以上功能微碼，所述每個功能微碼對應(yīng)特定的處理功能；網(wǎng)絡(luò)處理器運(yùn)行過程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從所述微碼文件中提取相應(yīng)微引擎對應(yīng)的功能微碼，加載到對應(yīng)的微引擎中。
2、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述網(wǎng)絡(luò)處理器運(yùn)行過 程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從所述微碼文件中提取相應(yīng)微引擎對應(yīng)的 功能微碼，加載到對應(yīng)的微引擎中的具體過程包括a 、判斷網(wǎng)絡(luò)處理器的微引擎中當(dāng)前運(yùn)行的微碼是否滿足當(dāng)前的業(yè)務(wù)要 求，若不能滿足時，進(jìn)入步驟b;b、 從所述微碼文件中提取符合當(dāng)前業(yè)務(wù)要求的功能微碼并組裝成新的 微碼加載組合；c、 停止當(dāng)前微引擎的運(yùn)行，重新初始化微引擎；d、 將新的微碼組合加載到對應(yīng)的微引擎中，并為微引擎重建隊列資源；e、 啟動微引擎。
3、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述微碼文件中包括微 引擎的功能微碼的分配策略，每種分配策略對應(yīng)一種業(yè)務(wù)要求；步驟b具體為4姿照所述當(dāng)前業(yè)務(wù)要求從所述微碼文件中讀取對應(yīng)的分 配策略，按照所述分配策略中記錄的功能微碼信息及其與微引擎的組合對應(yīng) 信息，從微碼文件中提取相應(yīng)的功能微碼，并組合成新的微碼組合；并在步 驟d中按照所述分配策略中記錄的功能微碼與微引擎的組合對應(yīng)信息，將所 述微碼組合中的各個功能微碼加載到所述功能微碼對應(yīng)的微引擎中。
4、 根據(jù)權(quán)利要求2所述的方法，其特征在于，所述微碼文件中包括 微引擎chunk信息，用于描述每個微引擎的指令代碼段在微碼文件中的偏移地址以及大小信息；微引擎字符串表，其中包含了微引擎的功能微碼的分配策略；微引擎指令代碼段，其中存儲有具體的功能微碼的代碼；所述步驟b中，先按照所述當(dāng)前業(yè)務(wù)要求從所述微碼文件中讀取對應(yīng)的分配策略，再按照分配策略信息從所述微引擎chunk信息定位到對應(yīng)的微引擎指令代碼段，提取所定位的代碼段。
5、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述編譯微碼文件的具 體方法為利用網(wǎng)絡(luò)處理器的微引擎編譯對應(yīng)的功能微碼，其中一個微引擎 對應(yīng)編譯一個具有特定功能的功能微碼，將編譯好的功能微碼設(shè)置在微碼文 件中。
6、 根據(jù)權(quán)利要求5所述的方法，其特征在于， 一個微碼文件中最多包 括與所述網(wǎng)絡(luò)處理器微引擎數(shù)量相同的功能微碼；在需要超過所述微引擎?zhèn)€ 數(shù)的功能微碼時，則進(jìn)一 步編譯一個以上的微碼文件。
7、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述功能微碼所占用的 存儲空間小于或等于微引擎的存儲空間。
8、 根據(jù)權(quán)利要求1所述的方法，其特征在于，所述微碼文件的文件格 式為.uof才各式或.c才各式。
全文摘要
本發(fā)明公開了一種網(wǎng)絡(luò)處理器動態(tài)加載微碼的方法，該方法預(yù)先編譯微碼文件，所述微碼文件中包括一個以上功能微碼，所述每個功能微碼對應(yīng)特定的處理功能；網(wǎng)絡(luò)處理器運(yùn)行過程中，根據(jù)當(dāng)前業(yè)務(wù)的啟用情況，從所述微碼文件中提取相應(yīng)微引擎對應(yīng)的功能微碼，加載到對應(yīng)的微引擎中。利用本發(fā)明，可以充分利用網(wǎng)絡(luò)處理器的有限的指令空間，當(dāng)設(shè)備的運(yùn)行環(huán)境發(fā)生變化后，能夠在設(shè)備運(yùn)行過程中動態(tài)地更新網(wǎng)絡(luò)處理器指令空間中的微碼以提供相應(yīng)的功能。
文檔編號H04L12/02GK101335644SQ200810126280
公開日2008年12月31日 申請日期2008年7月30日 優(yōu)先權(quán)日2008年7月30日
發(fā)明者任祖軍, 晨 吳, 翱 李, 超 王, 薇 董 申請人:中興通訊股份有限公司