厲俊男 楊翔瑞 孫志剛

(國防科技大學計算機學院 長沙 410072) (lijunnan@nudt.edu.cn)

公有云在共享基礎設施為多租戶提供計算、存儲等服務的同時，還需要部署各種類型的網(wǎng)絡功能以實現(xiàn)租戶之間的網(wǎng)絡隔離、服務質量保證以及安全防護功能.因此，公有云必須具有靈活部署網(wǎng)絡功能的能力，可以將其總結為2方面的需求：1)公有云將每個租戶部署在特定的虛擬網(wǎng)絡環(huán)境中，需要靈活地部署多種類型的網(wǎng)絡功能以實現(xiàn)租戶間的性能隔離，并保證租戶所需的網(wǎng)絡服務質量[1];2)云服務提供商需要為租戶提供動態(tài)部署網(wǎng)絡功能的能力，方便租戶獲取公有云網(wǎng)絡的狀態(tài)信息，例如網(wǎng)絡的拓撲信息、鏈路流量分布、交換機實時隊列長度等[2-3].

傳統(tǒng)的網(wǎng)絡功能通?；趯Ｓ糜布崿F(xiàn)，靈活性較差，無法滿足快速部署網(wǎng)絡功能的需求[4].為此，目前主流云服務商，如微軟、亞馬遜，主要采用軟件實現(xiàn)各類網(wǎng)絡功能，以獲得最大的靈活性[1,5-6].然而軟件實現(xiàn)的網(wǎng)絡功能存在2方面不足：1)處理性能有限，通常需要多個CPU核并行處理才能達到10 Gbps速率[1,7]，難以滿足40 Gbps甚至更高速率[8]的處理需求；2)軟件處理的延時具有較大不確定性，延時從幾十微秒到幾毫秒不等[9]，這對許多低延遲應用而言是難以接受的[10].

為了在保證靈活性的同時提升處理性能，最近一些研究提出了基于圖形處理器(GPU)[11]、網(wǎng)絡處理器(NP)[12]或FPGA[1,13]的實現(xiàn)方法.由于FPGA具有更高的能耗比和功能定制能力，獲得了更高的關注，并在數(shù)據(jù)中心中得到應用.例如，微軟、百度和亞馬遜等云服務提供商[14-16]已經(jīng)在他們的數(shù)據(jù)中心部署了FPGA，用于加速內部和第三方工作負載，以及實現(xiàn)定制的網(wǎng)絡服務.

基于FPGA的網(wǎng)絡功能實現(xiàn)方式面臨的主要問題是硬件編程困難，與GPU和NP等基于軟件的編程方式相比，開發(fā)周期更長.為了簡化硬件開發(fā)，近年來基于高級語言在FPGA上開發(fā)網(wǎng)絡功能得到廣泛研究[1,17-18]，包括使用高級語言(如CC++)編程的高級綜合工具(HLS)[19-20]，或直接使用特定域語言(domain-specific language)(如P4)[21]，描述網(wǎng)絡處理功能[22]，并通過編譯器將其映射到FPGA邏輯[23-24].然而，上述研究還難以達到實用的效果，主要是因為高級語言并不涉及寄存器級描述，而且高級綜合工具仍無法很好地解決數(shù)據(jù)相關問題(例如讀寫依賴).此外，由高級語言編譯產(chǎn)生的硬件代碼還存在資源開銷大、處理性能低等不足[25].

我們認為，除了使用高級語言編程以外，基于模塊化的分組處理流水線設計，通過模塊復用同樣可以簡化FPGA開發(fā)的復雜性，縮短開發(fā)周期.為此，我們提出了可重構流水線模型——DrawerPipe.該模型將網(wǎng)絡功能實現(xiàn)架構抽象為5個標準的“抽屜”，不同的“抽屜”可以根據(jù)需要裝載不同的處理模塊，然后通過組合這些處理模塊實現(xiàn)各種網(wǎng)絡功能.

與公有云數(shù)據(jù)中心需要實現(xiàn)五花八門的應用加速不同，需要在公有云中部署的網(wǎng)絡功能類型，以及這些功能分解出來的分組處理類型是有限的.這些處理類型主要包括分組解析、精確查表、帶掩碼查表、各種策略執(zhí)行以及輸出調度等.因此，基于“抽屜化”的流水線架構設計，通過在“抽屜”中填充和組合分組處理模塊，能夠有效地降低FPGA設計的復雜性，縮短開發(fā)和測試周期.

本文對基于FPGA的網(wǎng)絡功能實現(xiàn)模型進行了深入研究，主要創(chuàng)新點包括：

1) 對數(shù)據(jù)中心常見網(wǎng)絡功能的處理流程分析發(fā)現(xiàn)，網(wǎng)絡功能的處理流程均可以映射到解析、分類、功能相關處理、報文修改和輸出調度5個階段.本文在此基礎上提出了DrawerPipe流水線模型，只需在流水線的5個“抽屜”中裝載處理模塊，即可實現(xiàn)特定的網(wǎng)絡功能.

2) 針對模塊的可重用需求，為“抽屜”之間的信息交互設計了一種可編程接口——DrawerMPI.DrawerMPI采用“強語法，弱語義”的信息交換模型，通過語義適配模塊將相鄰“抽屜”里的模塊解耦，使得第三方模塊的開發(fā)不再依賴于上下游模塊的接口定義.

3) 基于DrawerPipe模型，在NetMagic平臺上實現(xiàn)了自定義轉發(fā)、分組聚合等網(wǎng)絡功能，驗證了DrawerPipe架構、DrawerMPI的有效性.實驗結果初步證明基于DrawerPipe，可在FPGA上按需實現(xiàn)各類網(wǎng)絡功能，適合用于網(wǎng)絡功能的快速部署.

1 研究背景

1.1 網(wǎng)絡功能動態(tài)部署的需求

公有云除了部署必要的基礎網(wǎng)絡功能外，還要根據(jù)租戶的需求，動態(tài)部署不同類型的網(wǎng)絡功能，以滿足租戶對各自虛擬網(wǎng)絡的管理.例如，租戶需要部署網(wǎng)絡功能以增強對自身虛擬網(wǎng)絡狀態(tài)的可視性，包括網(wǎng)絡拓撲信息、交換機實時隊列長度等.如圖1(a)所示，在交換機上部署測量功能[26]，能夠將交換機實時隊列長度反饋回應用程序，方便租戶了解虛擬機之間的網(wǎng)絡鏈路擁塞程度，從而能夠執(zhí)行更優(yōu)的任務分派策略.除此之外，公有云還需要部署多種自定義網(wǎng)絡功能，以實現(xiàn)租戶特定的分組處理需求[3].例如，由于IP組播缺乏可靠的數(shù)據(jù)包傳播、流量控制和可擴展性，數(shù)據(jù)中心本身沒有開啟組播協(xié)議[27].但租戶的一些分布式計算或系統(tǒng)備份任務[28-29]需要同步數(shù)據(jù)，即將各自的狀態(tài)、數(shù)據(jù)信息組播或者廣播給該租戶的其他虛擬機.如果采用單播方式實現(xiàn)組播功能，需要復制多份相同的數(shù)據(jù)包送給目標虛擬機，會占用額外的鏈路帶寬.圖1(b)展示了在交換機端部署自定義轉發(fā)功能，能夠節(jié)省發(fā)送帶寬.另外，一些網(wǎng)頁搜索服務通常采用分派-聚集模型[30]，即向多個服務器發(fā)送查詢請求，再將返回的響應信息聚合得到最終的查詢結果；或者分布式計算架構采用映射-歸約(map-reduce)模型.如果在主機端實現(xiàn)聚合或歸約功能，則可能出現(xiàn)incast問題[30]，即多個響應報文同時返回給請求主機導致鏈路擁塞.圖1(c)展示了在交換機側部署數(shù)據(jù)聚合功能，可以有效地緩解incast所導致的鏈路擁塞.

Fig. 1 Three specific network functions in datacenter圖1 數(shù)據(jù)中心的3種特殊網(wǎng)絡功能

1.2 相關研究

在FPGA上部署網(wǎng)絡功能可以解決軟件實現(xiàn)網(wǎng)絡功能處理性能低、處理延時高的不足.但由于租戶對網(wǎng)絡功能的需求隨著自身所部署的應用類型、計算任務發(fā)生變化，要求FPGA具備靈活快速部署網(wǎng)絡功能的能力.

為了避免新網(wǎng)絡功能開發(fā)與測試周期長的不足，不少的工作[1,7,13,25]借鑒Click[31]路由器模塊化設計的思想，并通過共享硬件模塊使開發(fā)者使用已有的模塊重新組合所需的分組處理邏輯.但不同分組處理流水線在功能劃分、模塊接口定義上存在差異，導致不同模塊間無法直接互聯(lián)，仍需要一種統(tǒng)一的可重構流水線模型.為此，相關研究[32-33]提出了基于FPGA的可重構流水線模型，即將流水線分解為不同的處理階段，通過在每一處理階段加載不同的功能模塊重構新的網(wǎng)絡功能.

目前的可重構流水線模型分為動態(tài)可重構[32]和靜態(tài)可重構[33]2種方式.動態(tài)可重構是預先在FPGA上實現(xiàn)多種基本功能模塊，然后根據(jù)分組處理需求，動態(tài)編排數(shù)據(jù)包經(jīng)過模塊的次序，獲得所需的分組處理邏輯.這種方式極大地提升了FPGA的靈活性，只需要重新編排模塊順序即可實現(xiàn)新的網(wǎng)絡功能.但由于FPGA資源有限，能夠同時在FPGA上加載的模塊數(shù)量較少，因此只能支持少量的網(wǎng)絡功能.

靜態(tài)可重構首先是連接所需的硬件模塊，再綜合生成分組處理邏輯.靜態(tài)可重構流水線模型設計的關鍵是解決不同流水線間模塊重用問題.例如FAST[33]，按照分組處理功能劃分為5級，每一級采用統(tǒng)一的接口規(guī)范，解決了因模塊接口定義差異導致的模塊重用問題.但FAST采用類似OpenFlow1.0的大流表匹配方案(288-bit多維匹配)，而非多級流表匹配方式，存在可擴展性差等不足.

2 網(wǎng)絡功能處理流程分析

我們對數(shù)據(jù)中心常部署的11種網(wǎng)絡功能[34]的分組處理流程進行了分析研究，如表1所示.通過分析我們得到的主要結論如下：網(wǎng)絡功能可以分解為5個處理階段(2.1節(jié))，以及各處理階段的功能模塊可以在不同網(wǎng)絡功能之間重用(2.2節(jié)).

Table 1 Five Processing-Stage Abstraction of Network Functions Commonly Deployed in Data Center表1 數(shù)據(jù)中心常部署網(wǎng)絡功能的5個階段

2.1 網(wǎng)絡功能的5個處理階段

對11種網(wǎng)絡功能分析研究發(fā)現(xiàn)，網(wǎng)絡功能可以被抽象成一系列有序處理動作的組合，而且絕大部分網(wǎng)絡功能具有相似的處理流程.例如，大多數(shù)網(wǎng)絡功能在處理數(shù)據(jù)包之前都需要執(zhí)行報文解析功能，以提取后續(xù)查表所需的關鍵字.

我們將這些網(wǎng)絡映射到報文解析、報文分類、功能相關處理、報文修改和輸出調度5個階段.其中，報文解析階段判別報文類型并提取關鍵字.解析模塊可以依據(jù)網(wǎng)絡分層結構設計，例如二層解析、三層解析.報文解析的另一個功能是分析報文頭和報文體，其中報文頭用于查表操作，報文體則存放在報文緩存區(qū)；報文分類階段依據(jù)關鍵字實現(xiàn)報文分類，或者實現(xiàn)報文過濾功能.報文分類算法可以依據(jù)查表算法設計，例如基于Hash的精確匹配，基于決策樹、分解算法、元組空間搜索的多維匹配；功能相關處理階段實現(xiàn)特定的分組處理功能.例如，在1.1節(jié)提及的網(wǎng)絡測量功能、自定義轉發(fā)功能和數(shù)據(jù)聚合功能；報文修改階段實現(xiàn)封裝解封裝操作、標簽替換功能.由于報文封裝可能超過最大傳輸單元，例如隧道協(xié)議[37]，報文重組層還實現(xiàn)報文分片功能，以及在對端網(wǎng)絡設備實現(xiàn)分片重組功能；輸出調度階段實現(xiàn)報文的轉發(fā)功能、QoS流調度功能、整流限速功能，以及深度報文檢測功能.當然，還可以獲取輸出隊列長度，顯示地通告通信主機鏈路擁塞程度.

2.2 處理模塊的復用

實現(xiàn)上述5個處理階段中的邏輯稱為模塊，例如L2解析模塊、加解密模塊等.通過分析，我們發(fā)現(xiàn)這些模塊具有2種特性：

1) 可枚舉性

分組處理的動作有限，需要的模塊類型也有限，其數(shù)量基本上隨著網(wǎng)絡功能的增加而線性增加.目前，網(wǎng)絡功能的數(shù)目相對有限，因此模塊的類型是可以枚舉的，例如在上述11類網(wǎng)絡功能中，每階段的模塊數(shù)目大致為1～3個.

2) 穩(wěn)定性

通信協(xié)議的變化頻率相對較低，模塊的生存期比較長.因此一旦模塊完成設計測試，其內部的處理邏輯可以保持相對穩(wěn)定.例如L3解析模塊，只有在L3協(xié)議發(fā)生變化時才需要修改具體解析的處理邏輯.

處理模塊具有可枚舉性和穩(wěn)定性，可在實現(xiàn)不同網(wǎng)絡功能時復用，能夠降低網(wǎng)絡功能開發(fā)的復雜性，并縮短開發(fā)與測試周期.然而，在不同的網(wǎng)絡功能實現(xiàn)中復用硬件模塊，也存在一定的挑戰(zhàn).

1) 模塊內在的差異性.由于不同模塊內部處理邏輯的復雜性不同，自身實現(xiàn)所需要的資源，以及對外部存儲器訪存的需求存在較大差異.例如L2解析器只需要提取源、目的MAC地址，資源開銷?。欢铋L前綴查表邏輯需要大量的硬件資源開銷.

2) 模塊間傳遞的信息存在差異.不同流水線的模塊在設計時難以統(tǒng)一接口的語法語義，導致不同模塊在不修改的情況下很難直接互聯(lián).例如，接口信號數(shù)量、位寬不同的2個模塊無法直接連接.

3 DrawerPipe模型

3.1 設計思想

DrawerPipe的設計思路是利用FPGA的特點，解決模塊復用面臨的2個挑戰(zhàn)：

1) FPGA芯片由大量同構的可編程邏輯塊組成，而FPGA開發(fā)工具的作用是將用戶編寫的邏輯映射到這些邏輯塊中.因此，不同功能模塊間邏輯資源的分配是在代碼綜合過程中實現(xiàn)的.這種方式與ASIC或CPU實現(xiàn)相比，具有2個優(yōu)點：①模塊之間的資源是預分配的，在分配時所有模塊共享FPGA的所有資源，比RMT需要將邏輯映射到固定的32級流水線上更簡單.②一旦分配成功，其處理性能是可預測的，而且訪問外部存儲器完全由有限狀態(tài)機控制，沒有cache層次，因此性能是有保證的.

2) FPGA設計方法對各階段處理模塊所占用的資源大小并沒有約束，便于實現(xiàn)粗粒度流水線.例如，適合網(wǎng)絡功能處理特點的5級流水線.在模塊內部屏蔽大量的實現(xiàn)細節(jié)，與RMT的32級流水線相比，大大簡化了上下級流水線之間信息交換的復雜性，便于設計相對統(tǒng)一的信息交換規(guī)范.

3.2 DrawerPipe流水線結構

DrawerPipe根據(jù)網(wǎng)絡功能處理的流程，將流水線抽象為5個標準的“抽屜”，通過執(zhí)行裝載在“抽屜”中的硬件代碼，可以實現(xiàn)相應的網(wǎng)絡功能.其中，“抽屜”的特點主要有：

1) “抽屜”具有良好的彈性.由于FPGA的可編程性，不同“抽屜”之間可以共享FPGA資源.因此，在“抽屜”中安裝的模塊其資源占用具有較大的彈性.

2) “抽屜”之間具有并行性.由于FPGA的并行處理能力，不同“抽屜”之間能夠并行執(zhí)行.而且“抽屜”各自獨占內部的存儲資源，避免“抽屜”之間的依賴關系.

3) “抽屜”之間具有良好的可移植性.規(guī)格相同的“抽屜”之間可以相互替換.對模塊而言，接口定義相同的模塊之間也可以相互替換.

因此，DrawerPipe可以根據(jù)需求在不同的“抽屜”裝載不同的功能模塊，并通過組合這些功能模塊實現(xiàn)各種網(wǎng)絡功能.這種可重構流水線模型與可編程流水線模型不同.圖2對比了DrawerPipe模型與RMT,ClickNP兩種可編程流水線模型.ClickNP流水線中的模塊均由高級語言編譯生成，模塊的接口定義與實現(xiàn)的網(wǎng)絡功能相關，即模塊之間具有耦合性.雖然高級語言代碼可以復用，但編譯生成的底層模塊因為接口的耦合性無法直接重用.例如，二層解析與三層解析模塊可能都提取了目的MAC地址，但放置在flit[1]中位置不一定相同.RMT雖然具有統(tǒng)一的模塊接口，但均勻分配流水級資源存在資源浪費；使用VLIW實現(xiàn)分組處理需要消耗大量的邏輯資源，并不適合在FPGA上實現(xiàn).DrawerPipe則是在5個“抽屜”中裝載不同的硬件模塊實現(xiàn)所需的網(wǎng)絡功能.這些“抽屜”具有相同的外部接口，功能模塊直接加載在任意一個“抽屜”中.

Fig. 2 Comparation among different pipeline models圖2 不同的流水線模型對比

Fig. 3 DrawerPipe model圖3 DrawerPipe模型

DrawerPipe的5級“抽屜”流水線模型，由報文解析、報文分類、功能相關處理、報文修改、輸出調度組成，如圖3所示.同時，為了避免報文體經(jīng)過所有模塊造成模塊存儲資源的浪費，我們還設計了單獨的報文緩存模塊用于存儲報文.功能模塊間使用Metadata作為信息交互，Metadata采用標準的語法定義(即具有確定的數(shù)據(jù)位寬)，而非采用統(tǒng)一的語義(即定義Metadata中每一位數(shù)據(jù)所代表的含義).這種功能無關的抽象能夠解除模塊間由接口信號定義而綁定的耦合性，將在第4節(jié)中詳細介紹.

3.3 可重構模塊庫

可重構功能模塊庫能夠為DrawerPipe提供分組處理的功能模塊.每一階段均有其對應的功能模塊庫，方便用戶從中挑選合適的模塊，并將它們重組成所需的分組處理邏輯.例如，為了實現(xiàn)二層交換與ACL過濾功能，我們需要在解析階段加載四層解析器L4 Parser，用于提取報文的五元組信息，并分離報文頭與報文負載.與此同時，將報文負載存儲在報文緩存模塊中；而將報文頭以及解析器提取的關鍵字段組成報文控制塊Metadata，送給報文分類模塊.在報文分類階段加載基于BV的報文分類算法[45]，實現(xiàn)ACL過濾功能.在功能相關處理階段加載二層交換功能，實現(xiàn)源MAC地址學習、目的MAC地址查表轉發(fā)功能.然后在報文修改模塊將報文重組，最后經(jīng)輸出調度模塊從網(wǎng)絡設備的端口輸出.

可重構模塊庫支持功能模塊的復用是利用DrawerPipe“抽屜”化設計的特性，即規(guī)格相同的“抽屜”之間可以直接相互替換.對模塊而言，相同“規(guī)格”的定義更加寬松，只需要具有定義相同的模塊接口，而不需要統(tǒng)一模塊的“尺寸”(即硬件資源開銷).這是因為FPGA具有可重構能力，能夠按照模塊的大小重新分配資源，而非采用均勻的資源分配方式.在DrawerPipe中，我們設計了標準的“抽屜”接口——DrawerMPI(第4節(jié))，以保證模塊間接口的一致性.

4 DrawerMPI設計

目前，模塊的設計是功能相關的，即模塊的接口定義與模塊所實現(xiàn)的分組處理功能相關.而模塊的接口信號定義直接影響模塊之間能否重組.進一步分析，模塊的接口信號定義類似于自然語言，也可以將其分成語法與語義2部分.模塊接口的語法是指接口信號的位寬以及輸入輸出接口信號的數(shù)量；而模塊接口的語義則是指信號所代表的含義.因此，協(xié)議相關的模塊接口設計導致處理不同協(xié)議的模塊之間在語法或者語義上存在差異，無法直接重組來構建新的分組處理流水線.

本文提出了DrawerMPI(DrawerPipe module programmable interface)，一種功能無關的可編程模塊接口，用于解除模塊間由接口信號定義而綁定的耦合性.功能無關是指DrawerMPI采用語法一致的模塊接口(4.1節(jié))，包括輸入輸出接口數(shù)量、信號位寬，并利用語義轉化模塊(4.2節(jié))實現(xiàn)模塊接口間的語義適配.DrawerMPI還具有編程能力，通過配置接口信號語義的轉化規(guī)則，實現(xiàn)不同模塊接口之間的適配.因此，對網(wǎng)絡功能開發(fā)者而言，不需要關心上下游模塊所實現(xiàn)的功能類型(或模塊接口定義)，只需通過配置語義轉化模塊即可實現(xiàn)模塊信號格式的轉化.

4.1 DrawerMPI語法設計

模塊間能夠互連的基本條件是模塊接口的語法相同，包括接口數(shù)量、位寬.為此，DrawerMPI采用語法一致的模塊，即使用固定位寬的報文控制塊Metadata作為模塊間通信的消息，如圖3(b)所示.Metadata作為模塊間交互消息的好處是位寬恒定，保證了所有模塊具有相同的接口.DrawerPipe所使用的Metadata位寬為132 b，其中包括header tag共4 b，分別是MHT(metadata header tag)用于標識Metadata首部，MET(metadata end tag)標識Metadata尾部，PHT(packet header tag)標識報文首部，PET(packet end tag)標識報文尾部，隨后的128 b是具體的報文控制塊內容.另外，DrawerPipe使用報文控制塊連接模塊，即上游模塊只需要往下游模塊隊列中寫控制塊信息，而下游模塊只需要從隊列中讀取控制塊信息，從而能夠保證所有模塊都具有單輸入、單輸出接口的特性，便于模塊重組.

對報文控制塊進一步分析，我們發(fā)現(xiàn)模塊間對通信內容可以分為3種類型的消息，即平臺相關消息、通用報文頭字段消息、模塊間中間狀態(tài)交互消息(后兩者與網(wǎng)絡功能實現(xiàn)的平臺無關).其中，平臺相關消息是指平臺自身提供的內容，包括報文輸入端口、輸出端口、報文時間戳等信息.通用報文頭字段消息是指由解析模塊提取的關鍵字信息，可以用于后續(xù)查表操作.由于關鍵字具有固定格式，在不同的語義環(huán)境下可以通過轉化進行適配(4.2節(jié)).模塊間中間狀態(tài)交互消息是指協(xié)同工作的模塊間所傳遞的中間狀態(tài)消息.例如，源MAC地址學習與目的MAC地址轉發(fā)功能分離的2個模塊，在源MAC地址學習到新的MAC-Port映射關系后需要將該信息(中間狀態(tài)信息)告訴目的MAC地址轉發(fā)模塊.在需要相互協(xié)同的模塊設計之初，開發(fā)者已定義好中間狀態(tài)通信格式，具有統(tǒng)一的語義，無需第三方加以轉化.針對上述3種類型消息，DrawerMPI所定義的Metadata采用平臺相關消息層、通用報文頭字段消息層、模塊間中間狀態(tài)交互消息層3層消息模型.

4.2 DrawerMPI語義轉化模塊設計

雖然模塊具有相同語法的接口，即采用統(tǒng)一位寬的Metadata作為模塊間，但通信消息仍存在語義不一致導致模塊間不兼容的情況.例如，不同解析模塊提取的目的MAC地址在Metadata中的位置不盡相同.先前的可重構流水線，例如FAST[33]，采用統(tǒng)一語義的接口設計模式，即事先確定好Metadata信號每一位所代表的含義，以避免模塊間語義的沖突.但我們在模塊開發(fā)中發(fā)現(xiàn)，如果采用多流表匹配而非FAST的大流表匹配方式，不同流表之間存在中間狀態(tài)的交互.例如，IP查表后產(chǎn)生下一跳地址，再根據(jù)下一跳地址查詢目的MAC地址.而采用語義統(tǒng)一的Metadata不利于第三方功能模塊的開發(fā).例如，開發(fā)一種新的協(xié)議解析，我們需要先申請一片未使用的Metadta區(qū)域，并將該區(qū)域的定義通告給其他所有的開發(fā)者，這樣會導致Metadata消息越發(fā)復雜.另外，統(tǒng)一語義的模塊接口設計，還要求開發(fā)者事先了解Metadata的語義定義，已獲取自己所需的關鍵字信息.并在不同模塊所定義的Metadata存在語義沖突時，模塊間無法共用.例如，負載均衡模塊，QoS管理模塊分別將某一相同字段定義為根據(jù)5-tuple計算的Hash值和ToS，則導致這2個模塊無法在同一流水線中共存，如圖4所示：

Fig 4 Different modules have semantic conflict in Metadata圖4 不同功能模塊在自定義區(qū)域存在語義沖突

我們在4.1節(jié)中對報文控制塊進行了詳細的分析，將其分為3類消息，其中只需要對通用報文頭關鍵字段消息進行語義適配.因此，DrawerMPI在模塊間增加語義轉化模塊，能夠將上游模塊所輸出的控制塊格式轉化為下游模塊輸入的控制塊格式.如圖3(c)所示，語義轉化模塊是動態(tài)可配置的，根據(jù)相鄰模塊接口信號的語義，生成相應的格式轉化命令并配置語義轉化模塊，實現(xiàn)控制塊的適配功能.

語義轉化模塊使用多路選擇器(在verilog中采用case語句實現(xiàn)多路選擇器)完成Metadata格式轉化功能，如圖3(c)所示.我們發(fā)現(xiàn)所支持的Metadata格式轉化粒度越細(例如，支持1 b的syn_tag語義轉化)，靈活性越高，但消耗的硬件資源也越多.為了在靈活性與資源開銷得到較好的折中，我們選擇8 b作為最小拼接單元.算法1描述了語義轉化模塊處理流程.

算法1. 模塊間接口語義轉化算法.

① procedureMetadataAdapter(Metadata,SelectCode)

②units←Segment(Metadata,8)；

③ fori=0 to 15 do

④fieldIndex←SelectCode[i]；

⑤unitsNew←units[fieldIndex]；

⑥ end for

⑦Metadata←Assemble(unitsNew)；

⑧ end procedure

為了增加模塊接口語義描述的可讀性，本文使采用XML描述模塊接口的信號定義，并設計了編譯器用于生成模塊間語義轉化規(guī)則.算法2描述了語義轉發(fā)規(guī)則的生成算法.

算法2. 接口語義轉化規(guī)則生成算法.

① procedureGenSelectCode(xmlPreModule,xmlNextModule)

②itemsPreModule←GetItems(xmlPreModule)；

③itemsNextModule←GetItems(xmlNextModule)；

④ for (nameNext,offsetNext) initemsNextModule

do

⑤ for (namePre,offsetPre) initemsPreModule

do

⑥ if (nameNext==namePre) then

⑦SelectCode[offsetNext8]←

offsetPre8；

⑧ end if

⑨ end for

⑩ end for

5 實驗與測試

為了評估該模型的有效性、性能與資源開銷，我們基于DrawerPipe模型在Netmagic[46](Altera FPGA， Arria Ⅱ)平臺上實現(xiàn)了1.1節(jié)中提到的2種網(wǎng)絡功能，即自定義轉發(fā)、數(shù)據(jù)聚合功能.測試的網(wǎng)絡拓撲如圖1(b)(c)所示，由一臺基于FPGA的網(wǎng)絡設備通過網(wǎng)線連接多臺外部主機，并在FPGA上實現(xiàn)了最基本的2層轉發(fā)功能實現(xiàn)主機間的通信.由于NetMagic端口數(shù)量有限(4個千兆電口、4個千兆光口)，本實驗中使用電口組成了4臺主機互聯(lián)的簡單拓撲.

我們利用Quartus 13.0(Altera綜合工具)綜合所編寫的硬件代碼，得到這2種網(wǎng)絡功能所使用的一些關鍵功能模塊及模塊信息，包括模塊的最大吞吐率、處理延時、硬件存儲、邏輯資源開銷等，如表2所示:

Table 2 Key Processing Modules Used by Two Network Functions Based on Altera Arria Ⅱ表2 基于Altera Arria Ⅱ構建2種功能網(wǎng)絡功能所使用的關鍵功能模塊

Notes：Fmaxmeans the maximal frequency;Nmeans the number of resources;Pmeans the percentage of utilization of per resource.

從表2可以發(fā)現(xiàn)DrawerPipe的模塊化設計可以很大程度提高代碼的重用，并簡化新網(wǎng)絡功能的構建.例如，這2種網(wǎng)絡功能均使用了L4_Parser，以及基于BV的報文分類算法.

5.1 性能測試

5.1.1 自定義轉發(fā)功能

我們基于DrawerPipe實現(xiàn)了自定義轉發(fā)功能，所加載的模塊依次為表2中的L4解析、基于BV的報文分類、自定義轉發(fā)、報文修改、按端口轉發(fā)的輸出調度模塊.其中，L4解析模塊解析和提取五元組；報文分類模塊根據(jù)五元組分類，識別需要多播的報文；功能相關模塊根據(jù)分類結果查找目標主機簇地址，并構建相應的Metadata；為支持多播，需要在報文修改模塊中根據(jù)Metadata重組并復制報文；最后輸出調度模塊根據(jù)端口轉發(fā)報文.

為了驗證基于DrawerPipe實現(xiàn)自定義轉發(fā)功能的有效性，我們對比了加載自定義轉發(fā)功能與未加載該功能2種通信方式.其中在未加載自定義轉發(fā)功能時，測試主機需要與通信對端主機簇建立一對一連接.而基于DrawerPipe實現(xiàn)自定義轉發(fā)功能，可以認為只需要與虛擬的主機簇地址建立一條連接.

在實驗測試中，我們通過一臺主機向多臺主機發(fā)送相同數(shù)據(jù).但受Netmagic端口數(shù)量的限制，最多測試1 to 4的情況.如圖5所示，我們測試了傳輸不同大小數(shù)據(jù)所需的傳輸時間，即流完成時間(flow completion time, FCT).由于傳輸不同大小數(shù)據(jù)的流完成時間相差較大，我們采用歸一化流完成時間(normalized FCT)指標來比較2種實現(xiàn)方式.其中，歸一化流完成時間是指以部署自定義轉發(fā)功能所需的流完成時間作為參考基數(shù)，即為“1”，其他測試結果為該流完成時間的倍數(shù).分析實驗結果可以發(fā)現(xiàn)，在傳輸?shù)臄?shù)據(jù)流較小時(≤10 KB)，單播與自定義轉發(fā)2種方式傳輸時間相差較小.這是因為主機整體所需要發(fā)送的報文數(shù)量較少(<10個)，流完成時間中的絕大部分為傳輸延時.而在傳輸?shù)臄?shù)據(jù)流量較大時(≥1 MB)，自定義傳輸方式能節(jié)省大量的傳輸時間，并且隨著通信對端主機數(shù)量的增多，縮短的流完成時間也越多.

Fig. 5 FCT of custom forwarding with different data size圖5 自定義轉發(fā)功能在不同流大小下的傳輸時間

另外，為了驗證基于DrawerPipe實現(xiàn)自定義轉發(fā)功能的處理性能，我們將其與2臺主機間之間互聯(lián)(1 to 1 without custom forwarding)做了對比，兩者在傳輸不同大小數(shù)據(jù)的流完成時間相當，說明基于DrawerPipe實現(xiàn)的自定義轉發(fā)網(wǎng)絡功能處理延時較低，并支持端口的線速處理.

5.1.2 數(shù)據(jù)聚合功能

數(shù)據(jù)聚合屬于網(wǎng)內處理(in-network processing)功能.這類網(wǎng)絡功能大多與具體的應用類型相關，對分組的處理往往涉及自定義算法.本實驗選擇了其中一種相對簡單又具代表性的數(shù)據(jù)聚合功能，即將報文序列相同的報文聚合.這一網(wǎng)絡功能可應用于數(shù)據(jù)中心某一虛擬機同時向多個服務發(fā)送的查詢請求的場景，能夠最快地獲取服務響應.我們基于DrawerPipe實現(xiàn)該網(wǎng)絡功能，只需要在自定義轉發(fā)處理流水線中將自定義轉發(fā)模塊替換為數(shù)據(jù)聚合模塊.報文分類模塊的功能變?yōu)樽R別需要聚合的報文，只需要通過外部控制器配置規(guī)則即可.

Fig. 6 FCT of data aggregations with different data size圖6 數(shù)據(jù)聚合功能在不同流大小的傳輸時間

數(shù)據(jù)聚合功能的測試方式是多臺主機同時向同一臺主機發(fā)送數(shù)據(jù)報文，并在所有傳輸報文中攜帶特定的數(shù)據(jù)序列號(位于UDP報文負載中).可以預測到部署數(shù)據(jù)聚合功能的交換機會將不同主機所發(fā)送的相同序列號報文聚合，即每一個序號只有最新達到交換機的報文才會被送給目標主機.

為了驗證網(wǎng)絡功能的有效性，我們比較了部署數(shù)據(jù)聚合功能與傳統(tǒng)未部署聚合功能在傳輸不同大小數(shù)據(jù)下的流完成時間，如圖6所示.實驗結果顯示，在傳輸較小數(shù)據(jù)流時(≤10 KB)，未部署數(shù)據(jù)聚合功能的流完成時間只是稍大；而在傳輸?shù)臄?shù)據(jù)增大時(100 KB～1 MB)，流完成時間急劇上升.這是因為多臺主機同時發(fā)送報文，交換機的隊列溢出而發(fā)生丟包(即incast問題[30])，導致主機需要重傳丟失的報文.在通信數(shù)據(jù)更大時，多個主機通過平分帶寬避免擁塞，而流完成時間與通信主機數(shù)量相關.

同樣，我們將其與2臺主機間之間互聯(lián)(1 to 1 without data aggregation)做了對比，以驗證基于DrawerPipe實現(xiàn)自定義轉發(fā)功能的處理性能.如圖6所示，兩者在不同數(shù)據(jù)大小下流完成時間相當，說明基于DrawerPipe實現(xiàn)的數(shù)據(jù)聚合功能處理延時較低，并同樣支持端口的線速處理.

5.2 資源開銷分析

我們利用Quartus 13.0(Altera綜合工具)測試了DrawerPipe同時實現(xiàn)的2種功能網(wǎng)絡功能所需的硬件資源開銷，包括功能模塊、Metadata Adapter以及平臺相關資源開銷3部分，如表3所示.平臺相關部分大概占用了一半的硬件資源(35.8%～59.1%)，功能模塊的資源開銷相對較小(11.9%～20.9%)，Metadata Adapter的資源開銷也相對較少(2.6%～3.5%).

Table 3 Resource Usage Comparation Based on Altera Arria Ⅱ表3 基于Altera Arria Ⅱ硬件資源開銷對比

Notes：Nmeans the number of resources;Pmeans the percentage

of utilization of per resource.

6 總 結

本文提出了可重構分組處理流水線模型——DrawerPipe.DrawerPipe將網(wǎng)絡功能抽象成通用的五級流水線模型，每一級實現(xiàn)某一類分組處理功能.通過為每一級流水線加載一個或者多個類似的功能模塊快速重構所需的分組處理邏輯.采用模塊重組的方式不僅具有良好的處理性能與高效的資源利用率，同時避免重新開發(fā)分組處理流水線，節(jié)省開發(fā)時間和成本.此外，本文還設計了一種功能無關的可編程模塊接口模型——DrawerMPI.DrawerMPI采用語法一致的接口信號定義，而放寬對接口語義的定義，有利于提高模塊復用.最后，我們?yōu)槊恳患壛魉€設置相應的功能模塊庫，方便用戶從每一級模塊庫中選擇并重構所需的處理邏輯.

下一步我們將研究基于DrawerPipe的可編程模型，即用戶可以通過高級語言描述分支流水線架構，經(jīng)編譯器解析后從功能模塊庫中選擇并組合適當?shù)墓δ苣K，從而更方便軟件工程師參與FPGA的開發(fā).

[1]Li Bojie, Tan Kun, Luo Layong, et al. Clicknp: Highly flexible and high-performance network processing with reconfigurable hardware[C]Proc of the 2016 Conf on ACM SIGCOMM. New York: ACM, 2016: 1-14

[2]Costa P, Migliavacca M, Pietzuch P, et al. NaaS: Network-as-a-service in the cloud[C]Proc of the USENIX Conf on Hot Topics in Management of Internet, Cloud, and Enterprise Networks and Services. Berkelely, CA: USENIX Association, 2012: 1-6

[3]Benson T, Akella A, Shaikh A, et al. CloudNaaS: A cloud networking platform for enterprise applications[C]Proc of the 2nd ACM Symp on Cloud Computing. New York: ACM, 2011: 8-16

[4]Sherry J, Hasan S, Scott C, et al. Making middleboxes someone else’s problem: Network processing as a cloud service[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 13-24

[5]Li Jie, Humphrey M, Van Ingen C, et al. eScience in the cloud: A MODIS satellite data reprojection and reduction pipeline in the windows Azure platform[C]Proc of the Int Symp on Parallel & Distributed Processing. Piscataway, NJ: IEEE, 2010: 367-376

[6]Koponen T, Amidon K, Balland P, et al. Network virtualization in multi-tenant datacenters[C]Proc of the 11th USENIX Conf on Networked Systems Design and Implementation. Berkelely, CA: USENIX Association, 2014: 203-216

[7]Martins J, Ahmed M, Raiciu C, et al. ClickOS and the art of network function virtualization[C]Proc of the 11th USENIX Conf on Networked Systems Design and Implementation. Berkelely, CA: USENIX Association, 2014: 459-473

[8]Bando M, Chao H J. FlashTrie: Hash-based prefix-compressed trie for IP route lookup beyond 100 Gbps[C]Proc of the 2010 IEEE Int Conf on Computer Communications(IEEE INFOCOM). Piscataway, NJ: IEEE, 2010: 821-829

[9]Gandhi R, Liu H H, Hu Y C, et al. Duet: Cloud scale load balancing with hardware and software[J]. ACM SIGCOMM Computer Communication Review, 2015, 45(4): 27-38

[10]Hong C Y, Caesar M, Godfrey P. Finishing flows quickly with preemptive scheduling[J]. ACM SIGCOMM Computer Communication Review, 2012, 42(4): 127-138

[11]Han S, Jang K, Park K S, et al. PacketShader: a GPU-accelerated software router[J]. ACM SIGCOMM Computer Communication Review, 2010, 40(4): 195-206

[12]Song Haoyu. Protocol-oblivious forwarding: Unleash the power of SDN through a future-proof forwarding plane[C]Proc of the 2nd ACM SIGCOMM Workshop on Hot Topics in Software Defined Networking. New York: ACM, 2013: 127-132

[13]Rubow E, Mcgeer R, Mogul J, et al. Chimpp: A click-based programming and simulation environment for reconfigurable networking hardware[C]Proc of the Symp on Architecture for Networking & Communications Systems (ANCS). Piscataway, NJ: IEEE, 2010: 421-430

[14]Caulfield A M, Chung E S, Putnam A, et al. A cloud-scale acceleration architecture[C]Proc of the 49th Annual IEEEACM Int Symp on Microarchitecture (MICRO). Piscataway, NJ: IEEE, 2016: 75-87

[15]Jackson K R, Ramakrishnan L, Muriki K, et al. Performance analysis of high performance computing applications on the Amazon Web services cloud[C]Proc of the 2nd Int Conf on Cloud Computing Technology and Science. Piscataway, NJ: IEEE, 2011: 159-168

[16]Ouyang Jian, Lin Shiding, Qi Wei, et al. SDA: Software-defined accelerator for large-scale DNN systems[C]Proc of the 26th Hot Chips Symp (HCS). Piscataway, NJ: IEEE, 2014: 1-23

[17]Xilinx. SDNet development environment[EBOL]. [2017-12-04]. http:www.xilinx.comproductsdesign-toolssoftware-zonesdnet.html

[18]Sultana N, Galea S, Greaves D, et al. Emu: Rapid prototyping of networking services[C]Proc of the 2017 USENIX Annual Technical Conf. Berkelely, CA: USENIX Association, 2017: 459-471

[19]Intel. Intel FPGA SDK for OpenCL[EBOL]. [2017-12-04]. https:www.altera.com.cncontentdamaltera-wwwglobalen_USpdfsliteraturehbopencl-sdkaocl_programming_guide.pdf

[20]Dang V, Skadron K. Acceleration of frequent itemset mining on FPGA using SDAccel and Vivado HLS[C]Proc of the 28th Int Conf on Application-Specific Systems, Architectures and Processors (ASAP). Piscataway, NJ: IEEE, 2017: 195-200

[21]Bosshart P, Daly D, Gibb G, et al. P4: Programming protocol-independent packet processors[J]. ACM SIGCOMM Computer Communication Review, 2014, 44(3): 87-95

[22]Wang H, Soulé R, Dang H T, et al. P4FPGA: A rapid prototyping framework for P4[C]Proc of the Symp on SDN Research. New York: ACM, 2017: 122-135

[23]Bosshart P, Gibb G, Kim H S, et al. Forwarding metamorphosis: Fast programmable match-action processing in hardware for SDN[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 99-110

[24]Jose L, Yan L, Varghese G, et al. Compiling packet programs to reconfigurable switches[C]Proc of the 12th USENIX Conf on Networked Systems Design and Implementation. Berkelely, CA: USENIX Association, 2015: 103-115

[25]Rinta-Aho T, Karlstedt M, Desai M P. The Click2NetFPGA Toolchain[C]Proc of the 2012 USENIX Annual Technical Conf. Berkelely, CA: USENIX Association, 2012: 77-88

[26]Zhu Yibo, Kang Nanxi, Cao Jiaxin, et al. Packet-level telemetry in large datacenter networks[J]. ACM SIGCOMM Computer Communication Review, 2015, 45(4): 479-491

[27]Vigfusson Y, Abu-Libdeh H, Balakrishnan M, et al. Dr. multicast: Rx for data center communication scalability[C]Proc of the 5th European Conf on Computer Systems. New York: ACM, 2010: 349-362

[28]Dean J, Ghemawat S. MapReduce: Simplified data processing on large clusters[C]Proc of the 6th Conf on Symp on Opearting Systems Design & Implementation. Berkelely, CA: USENIX Association, 2004: 137-150

[29]Alizadeh M, Yang S, Sharif M, et al. pfabric: Minimal near-optimal datacenter transport[J]. ACM SIGCOMM Computer Communication Review, 2013, 43(4): 435-446

[30]Alizadeh M, Greenberg A, Maltz D A, et al. Data center TCP (DCTCP)[J]. ACM SIGCOMM Computer Communication Review, 2010, 40(4): 63-74

[31]Kohler E, Morris R, Chen Benjie, et al. The Click modular router[J]. ACM Trans on Computer Systems, 2000, 18(3): 263-297

[32]Anwer M B, Motiwala M, Tariq M B, et al. SwitchBlade: A platform for rapid deployment of network protocols on programmable hardware[J]. ACM SIGCOMM Computer Communication Review, 2010, 40(4): 183-194

[33]FAST. FPGA bAsed SDN swiTch[EBOL]. [2017-12-04]. http:fast-switch.github.io

[34]Sun Chen, Bi Jun, Zheng Zhilong, et al. NFP: Enabling network function parallelism in NFV[C]Proc of the Conf of the ACM Special Interest Group on Data Communication. New York: ACM, 2017: 43-56

[35]Zhu Shuyong, Bi Jun, Sun Chen, et al. SDPA: Enhancing stateful forwarding for software-defined networking[C]Proc of the 23rd Int Conf on Network Protocols (ICNP). Piscataway, NJ: IEEE, 2015: 323-333

[36]Vallentin M, Sommer R, Lee J, et al. The NIDS cluster: Scalable, stateful network intrusion detection on commodity hardware[C]Proc of Int Workshop on Recent Advances in Intrusion Detection. Berlin: Springer, 2007: 107-126

[37]Cisco. Introduce to virtual overlay technologies: Virtual extensible LAN (Vxlan) enhancements and VXLAN gateway[EBOL]. [2017-12-04]. https:learningnetwork.cisco.comdocsDOC-32654?dtid=osscdc000283

[38]Hopps C E. Analysis of an equal-cost multipath algorithm[J]. Journal of Allergy & Clinical Immunology, 2000, 109(1): 265-296

[39]Reese W. Nginx: The high-performance Web server and reverse proxy[J]. Linux Journal, 2008 (173): 2-10

[40]Liu J, Li Yue, Vorst N V, et al. A real-time network simulation infrastructure based on OpenVPN[J]. Journal of Systems & Software, 2009, 82(3): 473-485

[41]Shin S, Yegneswaran V, Porras P, et al. AVANT-GUARD: Scalable and vigilant switch flow management in software-defined networks[C]Proc of the 2013 ACM SIGSAC Conf on Computer & Communications Security. New York: ACM, 2013: 413-424

[42]Barr K C. Energy-aware lossless data compression[J]. ACM Trans on Computer Systems, 2006, 24(3): 250-291

[43]Seddiki M S, Shahbaz M, Donovan S, et al. FlowQoS: QoS for the rest of us[C]Proc of the Workshop on Hot Topics in Software Defined NETWORKING. New York: ACM, 2014: 207-208

[44]Sivaraman V, Narayana S, Rottenstreich O, et al. Heavy-hitter detection entirely in the data plane[C]Proc of the Symp on SDN Research. New York: ACM, 2017: 164-176

[45]Ganegedara T, Prasanna V K. StrideBV: Single chip 400G+ packet classification[C]Proc of the Int Conf on High Performance Switching and Routing. Piscataway, NJ: IEEE, 2012: 1-6

[46]Li Tao, Sun Zhigang, Jia Chunbo, et al. Using NetMagic to observe fine-grained per-flow latency measurements[J]. ACM SIGCOMM Computer Communication Review, 2011, 41(4): 466-467

LiJunnan, born in 1992. PhD candidate at National University of Defense Technology. His main research interests include packet processing on FPGA, network function acceleration.

YangXiangrui, born in 1993. Master candidate at National University of Defense Technology. His main research interests include SDN, network security, network function virtualization.