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


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