基于網絡處理器的流媒體應用架構模型（VPL）

李明哲，王勁林，陳 曉，陳 君

（1.中國科學院聲學研究所 國家網絡新媒體工程技術研究中心，北京100190；2.中國科學院大學 物理學院，北京100190）

網絡處理器（Network processor，NP）是為處理網絡應用而設計的專用處理器，近年來得到了廣泛應用［1－2］。網絡處理器不但具有良好的可編程性，也在網絡應用處理方面具有卓越的性能［3－4］。當代的網絡處理器大多使用多核架構，以突破單核處理的主頻和功耗瓶頸。這些核被做成片上系統（System－on－Chip，SoC），能夠降低處理延時，平滑分組延遲抖動。針對一些網絡處理應用中的常見操作，網絡處理器還利用各種協處理器實現硬件加速。網絡處理器平臺需要相應的軟件結構來組織底層的硬件資源，發揮硬件性能，同時又要求軟件平臺兼顧應用程序的開發效率。在解 決 開 發 效 率 方 面，OpenNP［5］，NP－Click［6］，NPPlatform［7］等模塊化方法和開發框架相繼被提出。然而這些工具在簡化程序設計的同時，帶來了運行效率的開銷。另外，這些框架的模塊化編譯工具往往只針對少數廠商和產品，缺少可移植性，遠遠無法解決網絡處理器硬件生態高度異構化的問題。作者認為，為簡化軟件開發過程而采用的軟件設計工具本身也不宜過分復雜，要有足夠的通用性，以適應各種各樣的平臺。本文面向流媒體類應用，致力于對網絡處理器平臺上通用的輕量級軟件架構的研究，以求在簡化應用開發過程的同時提升運行效率。

1 研究背景

1.1 多核組織模型

在多核平臺上開發應用時，需要合理地設計多核軟件架構，將數據處理任務分解后映射到各個核心上。不合理的多核架構會嚴重限制計算能力的發揮，甚至導致系統性能低于單核系統。網絡 分 組 處 理 應 用 主 要 有 RTC（Run－tocompletion）模型和流水線（Pipeline，PL）模型［8］兩種多核架構模型。RTC模型下，一個執行的進程或線程完成整個分組所有處理階段，中間沒有停頓和切換。在流水線模型下，一個分組的處理操作被分成多個不同的階段，每個階段只完成一部分數據處理工作，由專門的核上運行。執行各個階段的核心依次串聯起來構成一條邏輯上的流水線。

RTC模型適合于簡單的L2／L3的分組處理應用，這類應用的分組間幾乎沒有依賴關系，分組到達后在單個核上即時完成處理，然后不再訪問。然而當前的流媒體應用大都有復雜的處理邏輯，對數據在OSI模型的L4～L7層進行處理，往往是針對數據流而非基于分組，不適合RTC 模型。這里的數據流是指一批相互關聯和依賴并存在時間順序性的網絡分組，一般對應L4 層的一個連接或L5層的一個會話，具有較長的持續時間，下文中簡稱為流。

由于網絡應用通常具有順序性，能夠分解成多個依次承接的階段（Stage），如果采用PL 模型則會使得編程流程比較自然［7］。階段間負載均衡是PL模型所面臨的問題。一條流水線的吞吐率取決于吞吐率最低的那個階段。在單一流水線（Single pipeline，SPL）模型（圖1所示）下，每個階段被分配到一個處理器核心，工作量最大的階段會成為瓶頸。而在混合流水線（Hybrid pipeline，HPL）中，每個階段可在多個核心上并行運行，應根據各階段的負載大小分配相應的核數。

圖1 SPL與HPLFig.1 SPL and HPL

記C ＝｛1，2，…，nc｝為物理核心編號（core＿id）的集合，S ＝｛s1，s2，…，sns｝為階段的集合，函數τs（si）為取得階段si的執行時間，HPL 應根據各階段τs的不同按需分配核數，這一問題可表述為構造一個滿射MCS：C →S，使得瓶頸階段的吞吐率最大：

上述模型假定τs在運行時不發生變化，實際上并不嚴格成立，并且τs的測量并不容易。即使問題能夠被求解，這種以核為粒度的計算資源分配難以做到精確。

1.2 流調度策略

流媒體應用的數據處理常常作用于流而非分組，軟件設計應考慮流到計算資源的映射。記F為被處理的數據流的集合，R＋為正實數集，映射MCF：C×R＋→F＋｛f0｝給出了任意時刻一個核所處理的數據流，其中f0表示“無此數據流”，即MCF（c，t）＝f0意味著核c在t時刻空閑，若c非空閑則MCF（c，t）∈F。在下文中，如無歧義，將省略表示時間的參數t。一種可行的流映射策略是：對于每個階段，將每個數據流固定交給該階段的單一核進行處理，這種方式避免了階段內并行訪問同一數據流造成的訪問沖突，且具有良好的Cache親和性（Cache affinity），下文中稱為AF策略。另一種策略對流和核的關系不做任何限制，稱為NAF（Cache non－affinity）策略。

考慮兩種策略的Cache特性：對于一個有二級緩存的處理器，一般L1Cache為單核獨享，L2 Cache為核間共享。平均內存訪問時間tA取決于訪存次數兩級Cache命中率h1和h2，及訪問兩級Cache和DRAM 的時間tL1，tL2和tL3，有：

對于AF和NAF兩種策略，其Cache命中率可估算為［8］：

式中：Φ1和Φ2分別為前兩級Cache容量；Wf為單個流的工作集（內存訪問范圍）大小，為應用程序特性；流并發數nf體現了負載的大小。

一些數據流處理應用會要求并行程序滿足“階段互斥性”，即不允許分配給同一階段的多個核心同時訪問同一個數據流：

另一些應用甚至會提出更強的“流互斥性”要求，即不允許任意兩個核心同時訪問同一個數據流：

采用自旋鎖等機制可以實現流互斥性要求，從而必定也能實現階段互斥性。然而對于AF策略，即使沒有鎖的包含，也能自動實現階段互斥性。

2 VPL模型

如前文所述，HPL 模型存在諸多缺陷：流水線階段的相對負載難以確定，致使流水線拓撲設計缺乏可靠的依據；計算資源的分配是以核為粒度的靜態分配，難以實現精確的按需分配，且不能適應負載的動態變化。此外，計算資源到數據流的映射與到流水線的映射緊密耦合，讓應用開發變得復雜。本節提出虛擬流水線模型（Virtual pipeline，VPL）以解決這些問題。

圖2 為VPL 模型的結構，它包含邏輯流水線、映射器（mapper）和物理核心3 個組成要素。邏輯流水線只代表軟件上的處理流程，其中每一個階段都是一組代碼指令，而不是硬件單元。VPL同時支持多條邏輯流水線相互獨立地運作，在性能允許的情況下，可任意擴展流水線條數。這里不同的邏輯流水線對應不同的處理流程，通常代表不同的應用程序模塊或組件。多個只包含單一邏輯流水線的應用程序可合并為一個包含多個邏輯流水線的應用程序。如圖2中Sx和Sy是兩條邏輯流水線，其中Sx包含Sx0～Sx3四個階段，Sy包含Sy0～Sy2三個階段。映射器以數據結構的形式存在，負責數據處理任務到計算資源上的分配。

圖2 VPL構成要素Fig.2 Composition of VPL

流水線的每一個階段都按照事件驅動編程模型［12－13］進行設計。事件驅動編程模型也叫消息驅動模型，在這種模型下應用程序的主流程循環地執行讀取消息－處理消息操作，因此程序可看作由事件（消息）分發器和各種事件對應的事件處理器構成。事件分發器查看事件類型（下文中記作type＿id），將該事件調度到相應的事件處理器，而事件處理器則執行數據處理操作。對于數據流處理應用，事件包括網絡包到達事件和其他應用邏輯事件，如模塊間消息和定時器超時事件等。事件以消息的方式到達各個流水線階段，一個分組在遍歷一條流水線的過程中，依次以消息方式驅動各個階段的處理。消息傳遞都要經過VPL 的映射器調度分發。階段向映射器主動地提交和申請消息，映射器按照一定的原則將已提交的消息分發給申請消息的核心。核心根據消息類型type＿id確定對應的流水線和流水線階段，并定位到對應的事件處理器，最終調用該事件處理器完成數據處理操作，如算法1所示。

算法1 VPL Core

1.procedure COREROUTINE

2.while True do

／／申請到消息

3. msg←mapper.getMsg（core＿id）

／／確定對應流水線ρ

4. ρ←mapper.getPipeLine（msg.type＿id）

／／確定對應的階段s

5. s←ρ.getStage（msg.type＿id）

／／確定相應的事件處理器

6. h←s.getHandler（msg.type＿id）

／／調用事件處理器

7. h.process（msg）

8.end while

9.end procedure

2.1 VPL階段映射

與HPL模型不同，VPL 的流水線設計和計算資源映射被隔離開來，兩者相互獨立，于是負責實現數據處理功能的開發者不再需要關注每個階段核的數量，而將這一工作由映射器解決，映射器按照一定的策略給流水線的階段分配執行核心。記P 為系統同時運行的邏輯流水線的集合，P 中的任一流水線ρ 可視為ρ 中各階段構成的集合，記S 為各流水線所有階段的集合，即S ＝則流水線階段到核的映射可用MSC：S →｛Ci｜Ci?C｝表述。

圖3描述了階段映射的原理。雖然每個核都能訪問所有階段對應的代碼，但映射器通過控制消息的分發方式來控制每個核心實際能夠調用的事件處理器的集合，從而實現各種MSC設計。因此，映射器可以實現為消息隊列和映射規則表。

為實現階段間負載均衡，一個簡單的策略是將每個階段都映射到全部核心上：

圖3 VPL消息傳遞Fig.3 Message path in VPL

顯然，在這種策略下，只要有尚未完成處理的數據就不會出現空閑的核心，這樣就確保了階段間計算資源的按需分配，避免了上文所述的HPL 階段間負載不均衡問題。如果不考慮映射器本身的開銷，式（8）所示的MSC設計能夠體現出相對于HPL的性能優勢。此外，有的應用可能需要將不同的邏輯流水線在物理上隔離開，以免在異常情況下互相影響。這種情況下不能采用式（8），需要將劃分為個不相交子集分別分配給各邏輯流水線，P 中每個流水線ρ 分配到的C 的子集記作Cρ，那么可按照以下原則設計MSC：

如此，可實現流水線內各階段的均衡性。而流水線間的計算資源分配體現為對C 進行合理的子集劃分，資源分配的依據常常是某些服務質量指標，而不是負載的均衡性，本文不對其進行討論。

2.2 VPL數據流映射

映射器除了負責邏輯執行階段的計算資源分配外，也負責數據流的計算資源分配，這是通過“流組”的概念實現的。VPL 的映射器按照一定策略將所有數據流集合F 劃分成若干子集，每個子集稱作一個流組。劃分流組的依據可以是數據流的某些協議字段的哈希值，此時，記H 為用于流組劃分的哈希函數，G 為H 的計算結果取值空間，H（f）為數據流f對應的哈希值，則對于G 中的任意哈希值g，｛f ∈F｜H（f）＝g｝構成一個流組，稱g 為該流組的組編號（grp＿id）。

為了將計算資源分配給流組，VPL 策略需要配置一個映射MCG：C →｛Gi｜Gi?G｝為每一個物理核心分配G 的一個子集，MCG滿足：

以確保所有的流組都至少被劃分給了一個核心對其進行處理，于是MCG決定了數據流及其計算核心的對應關系。

如圖3所示，當某數據流的一個階段向其他階段發消息時，指定這條流的grp＿id和消息類型type＿id。映射器按照MCG將grp＿id轉換成一批核號core＿id，進而將該事件消息調度給正確的核。核心獲得消息后，根據type＿id確定對應的邏輯流水線（pl＿id）與階段（stage＿id），最終由目標階段完成階段內消息分發。

VPL 流映射可以采用前文中提到的AF 策略或NAF策略。對于AF策略，為使物理核間負載均衡，需要保證流組到物理核心的分配是均勻的，可如此設計：

易證明本策略滿足流互斥性，且可行的流水線映射只能采用式（8）。由于數據流的生滅是動態的過程，AF 策略需要隨時掌握各個流組的負載狀況，有一定的實施難度。

對于NAF策略，可以有：

顯然，這一策略無需考慮數據流的分配問題，物理核心的負載自動做到了均衡。需要注意的是，這里的AF和NAF策略分別為1.2節AF和NAF的特例。

當Wfnf＞Φ2時，有：

易知當Wfnf＞Φ1nc時，δtA關于流數nf的微分，這意味著AF的優勢將隨著負載增大而縮小。當負載增大到Wfnf＝Φ2時，這一差距已經縮小至。如果Φ1nc?Φ2，AF 的優勢已經不明顯。當負載Wfnf＞Φ2時，AF的優勢將更加微弱。

考慮到AF策略很難做到核間負載的完全均衡，需分析在負載不均衡的情況下兩個策略的性能。本文用L（f）表示數據流f 造成的負載（CPU 開銷），如果系統中只有碼率相同的恒定碼率（CBR）數據流，那么認為每個數據流的負載L（f）是相同的。用K 表示核間的負載不均衡程度，定義為壓力最大的核的負載相對于平均負載的比值，即：

粗略假設CPU 利用率主要取決于訪存時間和訪存次數，那么對于最忙碌的核，其CPU 利用率正比于KtA。AF策略難以避免K 大于1，會削弱其性能上的優勢。這樣AF 相對于NAF 在CPU 利用率上存在優勢，當且僅當當Wfnf＞Φ1nc時，根據式（2）～（5）可知，需K ＜方能體現AF 的優勢，這里當K 超過這一臨界值時，AF策略最忙碌的核的CPU 利用率反而會超過NAF策略，成為系統瓶頸，限制了整體的并發性能。

3 應用實例

基 于 VPL 模 型，在 Cavium OCTEON CN5860處理器［14］上實現了一個用于廣播電視網絡［15］的流媒體網關系統HiliMG［16］。作者之前的工作［17］主要討論了HiliMG 的業務功能和應用總體架構，本文則考慮數據處理功能模塊的架構設計。

HiliMG 連接IP廣 域 網 和IPQAM 設 備［18］，將HTTP 分塊傳輸編碼數據流轉換為IPQAM設備所支持的傳輸格式。上述功能實現為一個四個階段的流水線ρ，如圖4所示。其中Input階段實現了網絡協議棧的功能，對到達的IP網絡數據包進行解析，對下一階段輸出HTTP 數據流；Transcoder對HTTP 報文頭部和分塊傳輸編碼進行提取，過濾HTTP 層元數據，得到MPEG2 TS流，再按照IPQAM 的輸入格式進行封裝重組；Delay階段對載荷數據進行延遲緩沖；Output從Delay中獲得數據，按照一定的策略執行平穩地發送。四個階段以事件驅動的方式實現，其中Input 將單個網絡包的到達作為驅動事件，Transcoder和Delay依次將上一個階段的輸出作為驅動事件。最后一個階段則以周期性的定時器超時作為驅動事件。這一流水線被映射到CN5860的12個核心上，其余4個核心負責業務邏輯。

圖4 HiliMG 流水線Fig.4 HiliMG’s pipeline

CN5860處理器的POW 協處理器模塊為VPL映射器的實現提供了支持。POW 協處理器協助軟件完成了消息在多核間的調度和傳遞，它提供了16個“消息組”，每一個處理核心都被配置成與若干個組相關聯，主動收取發往這些消息組的事件消息。消息組機制實現了上文中流組的概念。考慮流到核的映射FCG，HiliMG 在開發過程中先后實現了式（11）和式（12）所示的AF 和NAF策略，下文中將對兩種策略進行評估。對于NAF策略，需要考慮流處理的臨界區保護問題。一般在多線程環境下的解決方案是給每一條流分配一個互斥鎖，保護其所有的處理操作。POW的tag切換機制能夠有效地降低互斥鎖帶來的互斥和同步開銷。POW 將IP流的五元組信息輸入一個哈希函數，具有相同輸出值的流的集合被作為一個流束（注意該處理器的流束概念與上文中提到的“流組”無關）。每個消息都被賦予一個屬性值，稱為tag。數據包到達消息的tag值被賦予所在流束的Hash值，應用程序制造的消息的tag值可任意決定。POW 確保有相同tag值的兩個消息不會被兩個核同時收取和處理。假設消息msg1和msg2的tag值都是t，當msg1被某核c獲取后，msg2會被阻塞在POW，其他核只能收到tag值非t的消息。直到msg1所觸發的操作被核c執行完，c轉而申請下一個消息，稱此時發生tag切換，msg2才可以被POW 釋放出。根據這一機制，只要應用程序保證t所對應的數據流只收到tag值為t的消息，則即使不加鎖也能自動地實現流處理操作的原子性。然而，HiliMG 的數據流為業務層數據流，其生命期可對應多個TCP 連接，輸入的數據包tag值可能會發生變化，為保證程序的可靠性還是需要互斥鎖，盡管如此，tag切換機制還是使得互斥開銷大大降低了。

4 實驗測試

以HiliMG 為基礎，在CN5860 處理器上對VPL的流水線映射策略和數據流映射策略進行了性能測試實驗。為方便實驗操作，Input階段并非真正從廣域網中獲取數據，而是在本地構造HTTP分塊傳輸編碼數據流。Delay 和Output階段被合并成Transmitter階段，于是形成一個新的流水線ρ′，如圖5所示。

圖5 測試流水線Fig.5 Pipeline for experiment

為比較HPL和VPL 的相對效率，本文分別按照HPL和VPL的方式對ρ′進行了實現，并比較其吞吐率，測試結果如圖6所示。實驗中，控制HPL三個階段中兩個階段的核數，變化第三個階段的核數，如圖例中“HPL2∶3∶x”樣式的標記表示固定ρ′前兩個階段所用的核數分別為2 和3，變化剩下那個階段的核數，而對于HPL 的每一種結構，保持VPL的總核數與之相同。由圖6可知，在核數較少的情況下，由于HPL 階段計算資源分配的粒度較大，難以做到均勻分配，吞吐率明顯低于負載均衡的VPL模式。在HPL3∶2∶1的情形下，VPL 的吞吐率高出了95%，而兩者最接近的情形是HPL3∶4∶4，此時VPL 也有13%的性能提升。

為評估流到核的映射MCG，ρ′實現了式（11）和式（12）所示的AF策略和NAF策略，并在不同負載壓力下測試二者對應的CPU 利用率。本組實驗固定使用8個核運行ρ′，變化數據流的數量，測量平均每個數據流的Generator和Transcoder階段所占用的CPU 利用率。數據流均為靜態建立的長數據流，保持相同的碼率（3.75 Mbit／s），這樣只需保持每個流組上的數據流數目相同即可為確保流到核直接的均衡分配。測量結果如圖7、圖8所示。由結果可知，在低負載狀態下，AF策略由于對Cache友好，能夠使得處理時間有所降低。但是隨著負載的升高，數據工作集的增大，二者的差距迅速縮小至忽略不計。流媒體網關只有在負載高、資源緊張的狀態下才有性能優化的需求，因此AF 策略的Cache親和性不足以表現出相對于NAF 策略的性能優勢。考慮到AF 策略對流的均衡映射有嚴格的要求，實施上有相當的難度，此應用程序采用NAF策略更為合理。

圖6 流水線映射測試實驗結果Fig.6 Pipeline mapping experiment

從圖7、圖8可以看出，應用程序的工作集隨著流數的上升迅速增大到導致緩存不能容納。這是由流媒體類應用的特點決定的。作為流媒體應用的代表，流媒體網關不僅僅處理報文包頭，還要大量訪問載荷內容以進行轉碼操作，這類應用的內存訪問空間局部性比較弱，對Cache的親和性不夠好。這一結果提示我們研究應用程序特性與流映射策略的關系。本文對Transcoder用基于DFA 的方法［19］進行了另外一種實現。在該方法中，運行在CPU 上的軟件基本上不會訪問載荷數據，載荷數據由DFA 的硬件協處理器進行掃描，將局部性限制在更小的范圍內。在此基礎上測試Transcoder階段的CPU 利用率，其中20%的數據流由基于DFA 的Transcoder進行處理（由于OCTEON CN5860平臺上DFA 單元的吞吐率較低，難以讓更多的數據流由DFA 進行處理），其余數據流仍按照原有方式進行處理，結果如圖9所示，圖中顯示的是兩種處理方式的平均CPU 利用率。此時AF與NAF之間一直存在著較為明顯的性能差距，AF的優勢得以體現。

圖7 數據流映射實驗－1GeneratorFig.7 Flow mapping experiment－1Generator

圖8 數據流映射實驗－2TranscoderFig.8 Flow mapping experiment－2Transcoder

圖9 數據流映射實驗－3DFA TranscoderFig.9 Flow mapping experiment－3DFA Transcoder

另外，本文對Generator也進行了簡化，使其不再填寫TS包結構，減少了內存訪問范圍。在此基礎上測量該階段的CPU 利用率，結果如圖10所示。與圖7相比，在高負載情況下AF 相對于NAF有了略微明顯的優勢。

圖10 數據流映射實驗－4簡化的GeneratorFig.10 Flow mapping experiment－4simplified generator

為了對比在負載不均衡情況下AF 和NAF的性能，本文將第二個核上數據流轉移到第一個核上，使得第一個核成為瓶頸，通過調節瓶頸核上的數據流數目來控制AF策略的K 值。用AF策略下運行簡化的Generator處理64條數據流，測試第一個核的CPU 利用率，結果如圖11 所示。

圖中也顯示了用NAF 策略處理64 條數據流時第一個核的CPU 利用率作為對比。隨著K 值增加，瓶頸核上的負載壓力隨之增大，削弱并最終抵消了AF 策略Cache親和性帶來的優勢。在K超過1.02時，AF 瓶頸核上的CPU 利用率超過了NAF策略。這種情形下，只有將負載均衡程度K 控制在低于1.02以下時使用AF 策略才可能有優勢，否則應選用NAF。

圖11 數據流映射實驗－5不均衡情形Fig.11 Flow mapping Eexperiment－5imbalance

綜合上述實驗可知：流處理應用程序是否采用AF類的策略取決于多種因素，包括應用程序的內存訪問特性，負載量的大小，以及能否有效實現核間負載均衡等，一般情況下NAF 策略比較簡單有效，應予以采用。

5 結束語

VPL將功能邏輯設計和計算資源分配相分離，具有很強的靈活性，方便了應用開發過程。VPL模型能夠克服HPL 在負載均衡上的不足，以細小的粒度實現多核負載的平衡。對HiliMG的測試結果表明了VPL在性能上（相比于HPL）的優勢。本文對AF 和NAF 兩種數據流映射策略的性能進行了理論分析，并在 Cavium OCTEON 處理器上進行了實驗測試，結果均表明，Cache親和性策略能夠帶來一定程序的性能提升，但其相對的優勢與負載狀況和應用特性緊密相關，在負載高、內存訪問局部性弱的條件下，AF 所帶來的性能提升可能非常有限，因此在工程實踐中應考慮更容易做到負載均衡的NAF 策略。本文對流映射的Cache性能分析忽略了內存總線競爭的影響，下一步將對總線競爭進行建模，以評估它對VPL映射策略的影響。

［1］宋毅.數據復制轉發平滑引擎的多核網絡軟件框架技術研究［D］.北京：中國科學院大學物理學院，2013.Song Yi.The research of multicore network software framework of data copying relaying and smoothing engine［D］.Beijing：School of Physics，University of Chinese Academy of Sciences，2013.

［2］Bae K，Ok S，Son H，et al.An Efficient Interworking Architecture of a Network Processor for Layer 7 Packet Processing［M］.Communication and Networking：Springer，2012：136－146.

［3］Meng J，Chen X，Chen Z，et al.Towards High－performance Ipsec on Cavium Octeon Platform［M］.Berlin：Trusted Systems，Spriger Berlin Heidelberg，2011：37－46.

［4］Li M，Zhang W，Chen X，et al.Performance evaluation of an ip－san initiator based on multi－core network processors［C］∥International Conference on Computer Technology and Development，3rd（ICCTD 2011），ASME Press，2011：1－5.

［5］Lee K.OpenNP：ageneric programming model for network processors［D］.Lancashire：Lancaster University，2006.

［6］Plishker W，Keutzer K.NP－Click：a productive software development approach for network processors［J］.IEEEE Micro，2004，24（5）：45－54.

［7］閆守孟.面向網絡處理器的軟件平臺關鍵技術研究［D］.西安：西北工業大學計算機學院，2005.Yan Shou－meng.Key technologies study on network processors＇software platform［D］.Xi＇an：School of Computer Science，Northwestern Polytechnical University，2005.

［8］賀鵬程.面向流的多核分組處理與傳輸技術研究［D］.北京：中國科學院研究生院，2010.He Peng－cheng.Studying flow based packet scheduling and transimission on multi－core processor［D］.Beijing：Graduate University of Chinese Academy of Sciences，2010.

［9］Guo D，Liao G，Bhuyan L，et al.A scalable multithreaded L7－filter design for multi－core servers［C］∥Proceedings of the 4th ACM／IEEE Symposium on Architectures for Networking and Communications Systems.New York，USA：ACM Press，2008：60.

［10］Ahuja V，Farrens M，Ghosal D.Cache－aware affinitization on commodity multicores for high－speed network flows［C］∥Proceedings of the Eighth ACM／IEEE Symposium on Architectures for Networking and Communications Systems，ACM，2012：39－48.

［11］Cho J Y，Jin H W，Lee M，et al.On the core affinity and file upload performance of hadoop［C］∥Proceedings of the 2013International Workshop on Data－Intensive Scalable Computing Systems.New York，USA：ACM Press，2013：25－30.

［12］Gaud F，Geneves S，Lachaize R，et al.Efficient workstealing for multicore event－driven systems［C］∥2010IEEE 30th International Conference on Distributed Computing Systems，Genova，2010：516－525.

［13］Haller P，Odersky M.Scala actors：unifying threadbased and event－based programming［J］.Theoretical Computer Science，2009，410（2／3）：202－220.

［14］Cavium networks［EB／OL］.［2014－03－07］.http：／／www.cavium.com／

［15］Breznick A.A switch in time：the role of switched digital video in easing the looming bandwidth crisis in cable［J］.Communications Magazine，IEEE，2008，46（7）：96－102.

［16］HiliMG［EB／OL］.［2014－03－07］.http：／／www.hiliway.com／zh／products／hilimg.html

［17］Li J，Chen J，Li M，et al.A multi－core architecture for video streaming［J］.Applied Mechanics and Materials，2013，411：960－965.

［18］郭秀巖.面向多核的多層次實時網絡數據流調度技術研究［D］.合肥：中國科學技術大學信息科技學院，2011.Guo Xiu－yan.The research of multi－level real－time network stream scheduling on multicore network processor［D］.Hefei：School of Information Science and Technology，University of Science and Technology of China，2011.

［19］Zhou Y.Hardware acceleration for power efficient deep packet inspection［D］.Dublin：Dublin City University，2012.