基于網(wǎng)絡(luò)處理器的流媒體應(yīng)用架構(gòu)模型（VPL）

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

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

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

1 研究背景

1.1 多核組織模型

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

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

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

圖1 SPL與HPLFig.1 SPL and HPL

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

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

1.2 流調(diào)度策略

流媒體應(yīng)用的數(shù)據(jù)處理常常作用于流而非分組，軟件設(shè)計應(yīng)考慮流到計算資源的映射。記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ù)流固定交給該階段的單一核進(jìn)行處理，這種方式避免了階段內(nèi)并行訪問同一數(shù)據(jù)流造成的訪問沖突，且具有良好的Cache親和性（Cache affinity），下文中稱為AF策略。另一種策略對流和核的關(guān)系不做任何限制，稱為NAF（Cache non－affinity）策略。

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

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

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

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

另一些應(yīng)用甚至?xí)岢龈鼜?qiáng)的“流互斥性”要求，即不允許任意兩個核心同時訪問同一個數(shù)據(jù)流：

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

2 VPL模型

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

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

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

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

算法1 VPL Core

1.procedure COREROUTINE

2.while True do

／／申請到消息

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

／／確定對應(yīng)流水線ρ

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

／／確定對應(yīng)的階段s

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

／／確定相應(yīng)的事件處理器

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

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

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

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

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

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

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

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

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

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

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

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

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

對于NAF策略，可以有：

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

當(dāng)Wfnf＞Φ2時，有：

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

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

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

3 應(yīng)用實例

基 于 VPL 模 型，在 Cavium OCTEON CN5860處理器［14］上實現(xiàn)了一個用于廣播電視網(wǎng)絡(luò)［15］的流媒體網(wǎng)關(guān)系統(tǒng)HiliMG［16］。作者之前的工作［17］主要討論了HiliMG 的業(yè)務(wù)功能和應(yīng)用總體架構(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)絡(luò)協(xié)議棧的功能，對到達(dá)的IP網(wǎng)絡(luò)數(shù)據(jù)包進(jìn)行解析，對下一階段輸出HTTP 數(shù)據(jù)流；Transcoder對HTTP 報文頭部和分塊傳輸編碼進(jìn)行提取，過濾HTTP 層元數(shù)據(jù)，得到MPEG2 TS流，再按照IPQAM 的輸入格式進(jìn)行封裝重組；Delay階段對載荷數(shù)據(jù)進(jìn)行延遲緩沖；Output從Delay中獲得數(shù)據(jù)，按照一定的策略執(zhí)行平穩(wěn)地發(fā)送。四個階段以事件驅(qū)動的方式實現(xiàn)，其中Input 將單個網(wǎng)絡(luò)包的到達(dá)作為驅(qū)動事件，Transcoder和Delay依次將上一個階段的輸出作為驅(qū)動事件。最后一個階段則以周期性的定時器超時作為驅(qū)動事件。這一流水線被映射到CN5860的12個核心上，其余4個核心負(fù)責(zé)業(yè)務(wù)邏輯。

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

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

4 實驗測試

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

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

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

為評估流到核的映射MCG，ρ′實現(xiàn)了式（11）和式（12）所示的AF策略和NAF策略，并在不同負(fù)載壓力下測試二者對應(yīng)的CPU 利用率。本組實驗固定使用8個核運(yùn)行ρ′，變化數(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é)果可知，在低負(fù)載狀態(tài)下，AF策略由于對Cache友好，能夠使得處理時間有所降低。但是隨著負(fù)載的升高，數(shù)據(jù)工作集的增大，二者的差距迅速縮小至忽略不計。流媒體網(wǎng)關(guān)只有在負(fù)載高、資源緊張的狀態(tài)下才有性能優(yōu)化的需求，因此AF 策略的Cache親和性不足以表現(xiàn)出相對于NAF 策略的性能優(yōu)勢。考慮到AF 策略對流的均衡映射有嚴(yán)格的要求，實施上有相當(dāng)?shù)碾y度，此應(yīng)用程序采用NAF策略更為合理。

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

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

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

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

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

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

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

5 結(jié)束語

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

［1］宋毅.數(shù)據(jù)復(fù)制轉(zhuǎn)發(fā)平滑引擎的多核網(wǎng)絡(luò)軟件框架技術(shù)研究［D］.北京：中國科學(xué)院大學(xué)物理學(xué)院，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)絡(luò)處理器的軟件平臺關(guān)鍵技術(shù)研究［D］.西安：西北工業(yè)大學(xué)計算機(jī)學(xué)院，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］.北京：中國科學(xué)院研究生院，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)絡(luò)數(shù)據(jù)流調(diào)度技術(shù)研究［D］.合肥：中國科學(xué)技術(shù)大學(xué)信息科技學(xué)院，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.