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

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

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

1 研究背景

1.1 多核組織模型

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

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

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

圖1 SPL與HPLFig.1 SPL and HPL

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

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

1.2 流調(diào)度策略

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

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

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

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

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

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

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

2 VPL模型

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

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

圖2 VPL構(gòu)成要素Fig.2 Composition of VPL

流水線的每一個階段都按照事件驅(qū)動編程模型［12－13］進行設(shè)計。事件驅(qū)動編程模型也叫消息驅(qū)動模型，在這種模型下應用程序的主流程循環(huán)地執(zhí)行讀取消息－處理消息操作，因此程序可看作由事件（消息）分發(fā)器和各種事件對應的事件處理器構(gòu)成。事件分發(fā)器查看事件類型（下文中記作type＿id），將該事件調(diào)度到相應的事件處理器，而事件處理器則執(zhí)行數(shù)據(jù)處理操作。對于數(shù)據(jù)流處理應用，事件包括網(wǎng)絡包到達事件和其他應用邏輯事件，如模塊間消息和定時器超時事件等。事件以消息的方式到達各個流水線階段，一個分組在遍歷一條流水線的過程中，依次以消息方式驅(qū)動各個階段的處理。消息傳遞都要經(jīng)過VPL 的映射器調(diào)度分發(fā)。階段向映射器主動地提交和申請消息，映射器按照一定的原則將已提交的消息分發(fā)給申請消息的核心。核心根據(jù)消息類型type＿id確定對應的流水線和流水線階段，并定位到對應的事件處理器，最終調(diào)用該事件處理器完成數(shù)據(jù)處理操作，如算法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）

／／調(diào)用事件處理器

7. h.process（msg）

8.end while

9.end procedure

2.1 VPL階段映射

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

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

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

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

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

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

2.2 VPL數(shù)據(jù)流映射

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

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

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

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

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

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

對于NAF策略，可以有：

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

當Wfnf＞Φ2時，有：

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

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

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

3 應用實例

基 于 VPL 模 型，在 Cavium OCTEON CN5860處理器［14］上實現(xiàn)了一個用于廣播電視網(wǎng)絡［15］的流媒體網(wǎng)關(guān)系統(tǒng)HiliMG［16］。作者之前的工作［17］主要討論了HiliMG 的業(yè)務功能和應用總體架構(gòu)，本文則考慮數(shù)據(jù)處理功能模塊的架構(gòu)設(shè)計。

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

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

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

4 實驗測試

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

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

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

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

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

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

圖7 數(shù)據(jù)流映射實驗－1GeneratorFig.7 Flow mapping experiment－1Generator

圖8 數(shù)據(jù)流映射實驗－2TranscoderFig.8 Flow mapping experiment－2Transcoder

圖9 數(shù)據(jù)流映射實驗－3DFA TranscoderFig.9 Flow mapping experiment－3DFA Transcoder

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

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

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

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

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

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

5 結(jié)束語

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

［1］宋毅.數(shù)據(jù)復制轉(zhuǎn)發(fā)平滑引擎的多核網(wǎng)絡軟件框架技術(shù)研究［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］閆守孟.面向網(wǎng)絡處理器的軟件平臺關(guān)鍵技術(shù)研究［D］.西安：西北工業(yè)大學計算機學院，2005.Yan Shou－meng.Key technologies study on network processors＇software platform［D］.Xi＇an：School of Computer Science，Northwestern Polytechnical University，2005.

［8］賀鵬程.面向流的多核分組處理與傳輸技術(shù)研究［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，F(xiàn)arrens 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］郭秀巖.面向多核的多層次實時網(wǎng)絡數(shù)據(jù)流調(diào)度技術(shù)研究［D］.合肥：中國科學技術(shù)大學信息科技學院，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.