基于GPU加速的NFV系統(tǒng)的框架設計和性能優(yōu)化

郭良琛 張 凱

1(復旦大學軟件學院 上海201203) 2(復旦大學計算機科學技術學院 上海 201203) 3(上海市數(shù)據(jù)科學重點實驗室 上海 200433)

0 引 言

網(wǎng)絡功能虛擬化(NFV)系統(tǒng)將企業(yè)網(wǎng)絡基礎設施中的關鍵部分——網(wǎng)絡功能進行軟件實現(xiàn)，從而使得其維護、部署及管理更加容易。大部分NFV系統(tǒng)將網(wǎng)絡功能運行在CPU上。這種部署方案門檻不高，但是它相比傳統(tǒng)使用專有硬件實現(xiàn)的網(wǎng)絡功能在執(zhí)行效率上有一定的犧牲。相比CPU，圖形處理器(GPU)在并行計算方面具有突出的性能優(yōu)勢。研究指出，部分具備計算和訪存密集特征的網(wǎng)絡功能使用GPU進行加速可顯著提高性能[1-4]。因此，使用GPU對網(wǎng)絡系統(tǒng)進行加速成為當前高性能網(wǎng)絡處理領域的研究熱點。

在NFV系統(tǒng)中，多個網(wǎng)絡功能實例通常組合成服務鏈，對網(wǎng)絡流量提供復雜的處理功能。在同一套NFV系統(tǒng)中部署的多個網(wǎng)絡功能實例需要共享軟件和硬件基礎設施。在基于GPU加速的NFV系統(tǒng)中，網(wǎng)絡功能在系統(tǒng)中共存并組合成服務鏈的方式主要分為兩種。一種需要網(wǎng)絡功能利用NFV系統(tǒng)API將其功能完全使用GPU核函數(shù)實現(xiàn)，這樣NFV系統(tǒng)能夠實現(xiàn)執(zhí)行的高度集成化，減少網(wǎng)絡功能之間的通信開銷，有助于提高性能。但是，這種方式僅允許網(wǎng)絡功能開發(fā)者使用有限的GPU算子，在網(wǎng)絡功能的實現(xiàn)方面有較多的限制。并且，高度集成的方案對網(wǎng)絡功能的獨立運維、資源分配和數(shù)據(jù)安全隔離等方面也有不便之處。另一種系統(tǒng)則需要將網(wǎng)絡功能部署在具備獨立運行時的虛擬機或容器中，網(wǎng)絡功能可以使用虛擬化的CPU和GPU計算資源對網(wǎng)絡數(shù)據(jù)包進行處理。這種方案有效解決了網(wǎng)絡功能在實現(xiàn)和運維方面的挑戰(zhàn)。

但是，將GPU加速的網(wǎng)絡功能使用虛擬化方式獨立部署也帶來了一些問題。一方面，為保證部署獨立性，這些網(wǎng)絡功能在CPU-GPU執(zhí)行流水線的CPU處理部分有額外的開銷，例如協(xié)議棧處理與有狀態(tài)網(wǎng)絡功能的狀態(tài)管理等。由于GPU處理部分本身較為高效，流水線中的CPU處理的低效對整體性能的負面影響很大。另一方面，相比于集成化的方案，獨立部署的網(wǎng)絡功能需要自行實現(xiàn)大量有關網(wǎng)絡數(shù)據(jù)包預處理的基礎邏輯。這樣的工作增加了網(wǎng)絡功能開發(fā)者的負擔。

基于以上問題，本文提出一種針對GPU加速的NFV系統(tǒng)的框架設計和實現(xiàn)。該框架在允許GPU加速的網(wǎng)絡功能以容器的形式獨立部署在NFV系統(tǒng)中的前提下，利用服務鏈中網(wǎng)絡功能之間共享數(shù)據(jù)和流狀態(tài)的特性，引入了共享式流狀態(tài)管理機制，以減少網(wǎng)絡功能CPU-GPU處理流水線中CPU階段與協(xié)議棧處理和狀態(tài)管理相關的開銷，并降低網(wǎng)絡功能開發(fā)者的開發(fā)負擔。對原型系統(tǒng)的實驗評估表明，相比于現(xiàn)有的系統(tǒng)框架設計方案，該框架能夠顯著降低GPU加速的NFV系統(tǒng)中網(wǎng)絡功能處理流水線中的CPU階段的開銷，并在常見的網(wǎng)絡功能服務鏈上達到了最多2倍的吞吐量提升。

1 背景介紹

1.1 網(wǎng)絡功能與NFV系統(tǒng)

網(wǎng)絡功能是企業(yè)網(wǎng)絡基礎設施的基本組成單元。常見的網(wǎng)絡功能包括防火墻、網(wǎng)絡入侵檢測系統(tǒng)(NetworkIntrusionDetectionSystem, NIDS)，IPsec網(wǎng)關和路由器等。在常見的網(wǎng)絡基礎設施中，網(wǎng)絡功能通常會相互連接形成完整的服務鏈來提供相對靈活可定制的網(wǎng)絡流量處理系統(tǒng)。傳統(tǒng)上，網(wǎng)絡功能由專門設計的網(wǎng)絡硬件設備提供，但這種方式對于服務鏈的部署、運維、擴展方面有較多限制。NFV系統(tǒng)利用軟件和自動化替代專用網(wǎng)絡設備來定義、創(chuàng)建和管理網(wǎng)絡功能，從而實現(xiàn)網(wǎng)絡功能在通用硬件上部署，并達到了較高的靈活性和可擴展性[5]。

NFV系統(tǒng)將多個網(wǎng)絡功能集成在同一個平臺下，合并對外提供網(wǎng)絡服務。在一般的NFV系統(tǒng)中，各個網(wǎng)絡功能被標準化的虛擬機或容器包裝，NFV系統(tǒng)可以允許不同供應商提供的、依賴不同軟件環(huán)境的網(wǎng)絡功能實現(xiàn)共存在一個運行環(huán)境中。虛擬化技術的使用使得系統(tǒng)中不同網(wǎng)絡功能的獨立資源分配、運行時隔離、在線創(chuàng)建和熱更新等操作都成為可能。

大多數(shù)針對NFV系統(tǒng)的研究[6-8]使用最常見的通用處理器——CPU進行網(wǎng)絡流量的處理。盡管CPU的計算資源常見、易獲得，但其處理網(wǎng)絡流量的性能通常無法與配備了專用集成電路(ASIC)的專用網(wǎng)絡設備相提并論。為了提升性能，有一類研究嘗試將通用計算中常用的計算加速器硬件，尤其是圖形處理器(GPU)應用在NFV領域。相比于CPU，GPU具有較高的內(nèi)存帶寬和大量的計算執(zhí)行單元，適用于網(wǎng)絡功能中的數(shù)據(jù)密集型和計算密集型網(wǎng)絡流量處理任務。已經(jīng)有研究表明，一些網(wǎng)絡功能可以使用GPU加速從而獲得顯著的性能提升，例如NIDS模式匹配[3,9]、加密/解密[2]和路由[1]等。

1.2 基于GPU的NFV系統(tǒng)設計

為了在NFV系統(tǒng)中便捷和高效地集成使用GPU加速的網(wǎng)絡功能，研究者設計了多種專用于GPU加速的網(wǎng)絡數(shù)據(jù)包處理系統(tǒng)。根據(jù)將多個GPU加速的網(wǎng)絡功能部署在服務鏈中的形式的區(qū)別，這類系統(tǒng)的設計主要分為兩類。

純GPU實現(xiàn)。GASPP[9]、GPUNFV[10]和FlowShader[11]等系統(tǒng)將網(wǎng)絡系統(tǒng)服務鏈中各個網(wǎng)絡功能的全部功能都用適用于GPU的并行代碼實現(xiàn)。通過將網(wǎng)絡處理的功能高度集成化地執(zhí)行在GPU上，這類系統(tǒng)減少了網(wǎng)絡功能之間數(shù)據(jù)傳輸?shù)拈_銷。但是，高度的集成化不可避免地帶來了一些弊端：開發(fā)者在實現(xiàn)網(wǎng)絡功能時可利用的算子有限，而且因為服務鏈中用來加速網(wǎng)絡功能的GPU核函數(shù)作為一個整體部署在GPU上，因此單個網(wǎng)絡功能的獨立運維、資源動態(tài)分配和數(shù)據(jù)安全隔離都無法保證。

CPU-GPU流水線實現(xiàn)。G-NET[12]和Grus[13]等GPU加速的NFV系統(tǒng)采用了虛擬化設計，并針對GPU加速計算的場景進行了優(yōu)化。這類系統(tǒng)要求網(wǎng)絡功能開發(fā)者分別實現(xiàn)網(wǎng)絡功能在CPU和GPU上的處理邏輯，并最終在NFV系統(tǒng)上以流水線的方式執(zhí)行。一個典型的GPU加速的網(wǎng)絡功能流水線如圖1所示。首先，流量從網(wǎng)絡功能所部署在的虛擬機(或容器)的虛擬網(wǎng)絡接口中流入，并被暫存在主內(nèi)存的緩沖區(qū)中，進而分別被開發(fā)者自定義的預處理(Pre-processing)模塊、GPU核函數(shù)(GPUKernelFunction)與后處理(Post-processing)模塊進行處理。網(wǎng)絡流量需要首先經(jīng)PCIe通道從主機到設備(Hostto Device, HtoD)傳輸?shù)紾PU顯存中,GPU處理完成的結果同樣需要從設備到主機(Device to Host, DtoH)傳回主內(nèi)存。在NFV系統(tǒng)中，多個這樣的流水線共存從而形成網(wǎng)絡功能的服務鏈，而每個網(wǎng)絡功能的CPU執(zhí)行部分(Pre-processing和Post-processing)與GPU執(zhí)行部分(Kernel Function)都分別被虛擬化并共享硬件資源。這類切分網(wǎng)絡功能各個步驟的執(zhí)行職責并分別進行虛擬化的方式使得GPU加速的網(wǎng)絡功能在實現(xiàn)上更加靈活。

圖1 一個典型的使用GPU加速的網(wǎng)絡功能流水線

2 相關工作

許多研究致力于提升NFV系統(tǒng)的性能。OpenBox[14]、SNF[15]、Metron[7]和NetBricks[8]一類基于CPU的NFV系統(tǒng)與GASPP[9]、FlowShader[11]等基于GPU的NFV系統(tǒng)通過放棄虛擬化，將網(wǎng)絡功能中核心邏輯與I/O操作進行合并的方式提高了NFV的網(wǎng)絡流量處理性能。盡管其中NetBricks[8]能夠利用API抽象層為各網(wǎng)絡功能提供單獨的運行時環(huán)境，但是虛擬化的其他優(yōu)勢，包括靈活部署、靈活資源分配等都將不復存在。

網(wǎng)絡協(xié)議棧處理和狀態(tài)管理是網(wǎng)絡功能執(zhí)行中的重要開銷。許多系統(tǒng)實現(xiàn)了在多個網(wǎng)絡功能組成的服務鏈中設計協(xié)議棧共享的機制，以簡化網(wǎng)絡功能的開發(fā)，并減少不同網(wǎng)絡功能之間重復性協(xié)議棧處理的開銷，如MiddleClick[16]、Microboxes[17]和基于GPU的GASPP[9]等。這類系統(tǒng)中的協(xié)議棧功能提供了數(shù)據(jù)包分片重組、TCP流重組等一系列高級功能，并提供了針對多種協(xié)議層級的API。但這類系統(tǒng)中系統(tǒng)基礎設施和網(wǎng)絡功能之間存在高耦合度的問題，并不能良好地支持網(wǎng)絡功能的隔離部署。

基于GPU加速并實現(xiàn)了網(wǎng)絡功能隔離部署的NFV系統(tǒng)包括G-NET[12]和Grus[13]。其中G-NET[12]通過利用現(xiàn)代GPU的并行核函數(shù)執(zhí)行(CKE)特性提高GPU計算資源的利用效率。但是，這類系統(tǒng)的計算流水線中存在CPU階段低效的問題。

3 現(xiàn)有系統(tǒng)的問題

盡管使用虛擬化技術進行網(wǎng)絡功能封裝的GPU加速的NFV系統(tǒng)能夠達到可觀的性能和部署靈活性，但是其中依然有性能方面的問題，從而限制了這類系統(tǒng)在生產(chǎn)環(huán)境中的廣泛部署。

部分網(wǎng)絡功能處理流水線中，計算密集型和數(shù)據(jù)密集型任務是網(wǎng)絡功能性能的主要瓶頸，這也是業(yè)界采用GPU進行加速的主要原因。當這類任務轉移到高性能的GPU之后，系統(tǒng)的性能瓶頸可能會隨之轉移。為了探索常見GPU加速的網(wǎng)絡功能的性能瓶頸，我們使用CPU-GPU異構方式實現(xiàn)了幾個常見的網(wǎng)絡功能，并測量了執(zhí)行流水線中各個關鍵處理步驟的相對時間開銷，結果如圖2所示?？梢钥闯觯W(wǎng)絡功能中GPU處理的總時間開銷(包括核函數(shù)執(zhí)行和PCIe數(shù)據(jù)傳輸)相對較小，一般不超過總處理時間的一半。在這種情況下，GPU處理部分具有充分的并行性，因此網(wǎng)絡功能中CPU處理部分成為了影響總體性能的重要因素之一。

圖2 一些GPU加速的網(wǎng)絡功能批處理時間的分解

通常，GPU加速的網(wǎng)絡功能中CPU處理部分負責網(wǎng)絡數(shù)據(jù)包解析和狀態(tài)維護。例如，網(wǎng)絡功能在處理每個數(shù)據(jù)包之前，都需要對包的元信息進行提取，包括讀取包頭和定位負載位置等，這個過程包括數(shù)次隨機內(nèi)存訪問。對于需要維護連接狀態(tài)信息的網(wǎng)絡功能，它們還需要自行實現(xiàn)完整的高層協(xié)議棧，以實現(xiàn)基于流的狀態(tài)管理。此外，網(wǎng)絡功能還需要根據(jù)流的處理情況對其狀態(tài)進行實時讀取和更新。從圖2可以看出，基于有狀態(tài)的網(wǎng)絡功能中，協(xié)議棧處理和狀態(tài)維護工作最多占據(jù)了網(wǎng)絡功能總處理時間的一半以上，是CPU-GPU工作流水線中的重要開銷。

盡管協(xié)議棧處理和狀態(tài)維護的開銷在網(wǎng)絡系統(tǒng)中普遍存在，但是在GPU加速的NFV系統(tǒng)中，這部分開銷尤為突出。這主要有兩方面原因：(1)在基于虛擬化的網(wǎng)絡系統(tǒng)中，網(wǎng)絡功能模塊大多是獨立的，它們自身包含完整的協(xié)議棧實現(xiàn)。當多個此類網(wǎng)絡功能部署在同一個服務鏈中后，服務鏈中流過的數(shù)據(jù)包需要經(jīng)過多次重復的協(xié)議棧處理，浪費了大量的CPU計算資源。(2)為了最大化流水線中GPU的資源利用效率，GPU核函數(shù)會一次性并行處理整批數(shù)據(jù)包，因此上游數(shù)據(jù)包需要積累至一定批量才會被送入GPU核函數(shù)。在這種情況下，部分數(shù)據(jù)包需要在待處理的緩沖區(qū)中等待一段時間，這導致CPU處理階段平均時延被進一步放大。因此，CPU處理階段的低效會極大程度上影響整個CPU-GPU處理流水線的效率，從而讓GPU加速的性能優(yōu)勢不復存在。

4 系統(tǒng)設計

針對以上問題，本文提出一種適用于GPU加速的NFV系統(tǒng)的框架。該系統(tǒng)框架一方面使用CPU和GPU上的虛擬化技術將網(wǎng)絡功能運行時獨立開來，以簡化網(wǎng)絡功能的開發(fā)、運維和資源分配；另一方面利用共享的狀態(tài)管理機制，通過減少CPU-GPU流水線中CPU部分的計算開銷，提升整體運行效率。

4.1 總體框架

本文提出的系統(tǒng)總體框架如圖3所示。與傳統(tǒng)NFV一致，本系統(tǒng)主要包括基礎設施和網(wǎng)絡功能兩大部分。其中基礎設施負責支持網(wǎng)絡功能所需的基礎服務，例如網(wǎng)絡I/O、狀態(tài)管理與GPU虛擬化等，運行在獨立的進程中。由供應商開發(fā)的網(wǎng)絡功能則被部署在具備獨立運行時環(huán)境的容器中，負責執(zhí)行具體的網(wǎng)絡數(shù)據(jù)包處理功能。系統(tǒng)中允許同時部署多個網(wǎng)絡功能組成的服務鏈。同時，系統(tǒng)分配了多個共享內(nèi)存區(qū)域，并使用無鎖環(huán)形隊列等數(shù)據(jù)結構實現(xiàn)網(wǎng)絡功能之間、網(wǎng)絡功能與NFV基礎設施之間的通信。

圖3 系統(tǒng)架構

(1) 數(shù)據(jù)平面。系統(tǒng)的基礎設施部分為網(wǎng)絡數(shù)據(jù)包在其整個生命周期中的存儲和傳遞提供支持。當系統(tǒng)的接收線程(RX)從網(wǎng)卡收到數(shù)據(jù)包之后，會直接將其保存在由基礎設施和網(wǎng)絡功能共享的內(nèi)存區(qū)域——數(shù)據(jù)包緩存中，并同時生成對應的包描述符(descriptor)，進而將其指針添加至網(wǎng)絡功能實例的接收隊列。包描述符是包含數(shù)據(jù)包元信息的小型數(shù)據(jù)結構，其中也包括指向該數(shù)據(jù)包在緩存區(qū)中位置的指針。因此，網(wǎng)絡功能通過讀取包描述符便能夠訪問、修改數(shù)據(jù)包信息，包括元信息以及數(shù)據(jù)包內(nèi)容。這樣，數(shù)據(jù)包在系統(tǒng)內(nèi)部的轉發(fā)只要通過拷貝包描述符指針即可完成。因為包描述符指針的大小(通常8 B)遠遠小于數(shù)據(jù)包內(nèi)容(64 B～1 500 B)，數(shù)據(jù)平面中數(shù)據(jù)包傳遞的內(nèi)存拷貝開銷可以大幅度降低。對于已被處理完成的數(shù)據(jù)包，發(fā)送線程(TX)會根據(jù)其描述符指針從數(shù)據(jù)包緩存中提取出包內(nèi)容，并發(fā)送至網(wǎng)卡的輸出端。

(2) 網(wǎng)絡功能。系統(tǒng)支持遵循CPU預處理-GPU核函數(shù)處理-CPU后處理流水線的網(wǎng)絡功能。對于CPU處理階段，系統(tǒng)提供的API允許網(wǎng)絡功能直接訪問、維護數(shù)據(jù)包所在流的狀態(tài)信息，以平攤多個網(wǎng)絡功能中的相關開銷。對于GPU處理階段，系統(tǒng)也提供了GPU虛擬化API，允許網(wǎng)絡功能向GPU拷貝數(shù)據(jù)、執(zhí)行核函數(shù)等。

(3) GPU虛擬化。網(wǎng)絡功能通過調(diào)用GPU虛擬化API，可以利用共享內(nèi)存信道與GPU虛擬化層進行通信。網(wǎng)絡功能會將執(zhí)行請求添加到共享內(nèi)存中的隊列來通知GPU虛擬化層執(zhí)行相應功能。為了在不同網(wǎng)絡功能之間共享GPU計算資源，GPU虛擬化層在運行時只創(chuàng)建一個執(zhí)行上下文(executioncontext)，并將不同網(wǎng)絡功能的核函數(shù)執(zhí)行請求或內(nèi)存管理請求提交到此上下文中。此外，虛擬化層還利用了現(xiàn)代GPU中的并行核函數(shù)執(zhí)行(CKE)的特性，允許不同網(wǎng)絡功能的多個核函數(shù)在GPU中并行執(zhí)行，以實現(xiàn)GPU計算資源的空間共享，提高GPU計算資源的利用效率。

4.2 協(xié)議棧處理與狀態(tài)管理

網(wǎng)絡協(xié)議棧處理和狀態(tài)管理是網(wǎng)絡功能執(zhí)行中的重要開銷。為降低此類開銷對網(wǎng)絡功能中GPU加速效果的影響，本文提出基于流的共享式狀態(tài)管理機制，以在服務鏈中分攤網(wǎng)絡功能的狀態(tài)管理開銷。同時，與之對應的API也有助于簡化網(wǎng)絡功能的開發(fā)。

共享式狀態(tài)管理的核心思想是利用不同網(wǎng)絡功能之間協(xié)議棧處理和流狀態(tài)管理的相似性，將大部分該類計算集中在NFV系統(tǒng)的基礎設施部分，并將計算結果向各個網(wǎng)絡功能共享。系統(tǒng)基礎設施層的協(xié)議棧模塊負責預處理數(shù)據(jù)包并管理流狀態(tài)，而流狀態(tài)存儲模塊則允許網(wǎng)絡功能對這類狀態(tài)進行訪問。下文將對共享狀態(tài)管理中的一些關鍵步驟進行詳細介紹。

(1) 數(shù)據(jù)包解析。網(wǎng)絡功能對入站流量處理的第一步是解析數(shù)據(jù)包，并根據(jù)其實際結構提取一些關鍵字段。系統(tǒng)的協(xié)議棧模塊會首先對數(shù)據(jù)包進行解析，并將其結構記錄下來，這樣后續(xù)的網(wǎng)絡功能就可以直接讀取數(shù)據(jù)包中的關鍵字段從而跳過解析步驟。如圖4所示，數(shù)據(jù)包中各層協(xié)議棧對應的包頭指針可被協(xié)議棧模塊解析取得，并保存在數(shù)據(jù)包描述符中。而網(wǎng)絡功能開發(fā)者只需要調(diào)用相關API，即可直接讀取所需的信息，包括數(shù)據(jù)包傳輸層協(xié)議的類型與其頭部的位置等，而無須再自行實現(xiàn)協(xié)議棧進行解析。

圖4 流的共享狀態(tài)管理

(2) 流狀態(tài)管理。網(wǎng)絡包所在流的狀態(tài)(例如TCP連接狀態(tài))是網(wǎng)絡功能進行有狀態(tài)處理所需要的關鍵信息。例如，有狀態(tài)防火墻通常情況下會根據(jù)數(shù)據(jù)包所屬連接的狀態(tài)，拒絕那些并不屬于已成功建立的TCP連接的數(shù)據(jù)包。為加速網(wǎng)絡功能流狀態(tài)的獲取，系統(tǒng)協(xié)議棧模塊處理入站數(shù)據(jù)包之后，會將其流狀態(tài)添加或更新到流狀態(tài)存儲表中，并同時寫入數(shù)據(jù)包描述符的特定元信息字段，供后續(xù)網(wǎng)絡功能進行快速訪問。以圖4所示的流狀態(tài)表為例，表中的主鍵是由網(wǎng)絡層和傳輸層的關鍵信息組成的五元組，另外表中還存儲有該五元組所對應流的狀態(tài)信息。協(xié)議棧模塊在處理數(shù)據(jù)包時，會首先在表中查找到數(shù)據(jù)包所對應的流在表中的位置，進而獲取當前流的狀態(tài)。協(xié)議棧模塊會基于數(shù)據(jù)包的內(nèi)容及其流狀態(tài)，生成更新的狀態(tài)，并覆蓋保存至原流狀態(tài)信息表以及數(shù)據(jù)包描述符中。因此，網(wǎng)絡功能無須自行實現(xiàn)協(xié)議棧并維護連接狀態(tài)，而只需要讀取數(shù)據(jù)包描述符便可獲得相應流的狀態(tài)值。

(3) 網(wǎng)絡功能自定義狀態(tài)管理。除了流本身的狀態(tài)，一些網(wǎng)絡功能也需要維護其自定義的狀態(tài)，如網(wǎng)絡入侵檢測中模式識別所用到的自動機狀態(tài)，以及加解密中的密鑰等。類似于流狀態(tài)，維護網(wǎng)絡功能的自定義狀態(tài)同樣是網(wǎng)絡功能中的重要開銷。在本文系統(tǒng)中，網(wǎng)絡功能自定義狀態(tài)管理使用了類似于流狀態(tài)管理的方法，它將主要狀態(tài)信息保存在共享的流狀態(tài)表中。如圖4所示，狀態(tài)表中為每個網(wǎng)絡功能預留了存儲自定義狀態(tài)的內(nèi)存空間。網(wǎng)絡功能在處理數(shù)據(jù)包時，只要使用描述符中的流指針便可獲取其對應流的狀態(tài)存儲位置，因此網(wǎng)絡功能可以在此方便地維護自定義狀態(tài)，無須預先創(chuàng)建和維護額外的狀態(tài)表。在流狀態(tài)表中，系統(tǒng)為每個流中的每個網(wǎng)絡功能的自定義狀態(tài)預留了64 bit的空間。該大小對于絕大多數(shù)網(wǎng)絡功能已經(jīng)足夠。但如果網(wǎng)絡功能開發(fā)者希望使用更大的存儲空間，可將狀態(tài)存儲空間分配到網(wǎng)絡功能私有的內(nèi)存空間中，并將該位置的指針保存在公有的狀態(tài)表中?；谝陨戏椒?，網(wǎng)絡功能只需要進行一到兩次指針訪問，便可以獲取到數(shù)據(jù)包對應流的自定義狀態(tài)，而無須自行維護流狀態(tài)表。

(4) 超時機制。流生命周期的終止(例如TCP連接關閉)會使得流狀態(tài)存儲的空間被釋放，以便為新的流存儲狀態(tài)提供空間。但是，由于NFV系統(tǒng)中的網(wǎng)絡功能服務鏈通常有一定長度，可能會出現(xiàn)協(xié)議棧檢測到流已經(jīng)終止，而服務鏈中的網(wǎng)絡功能依然在處理該流的數(shù)據(jù)包的現(xiàn)象，如果在此刻該流的狀態(tài)存儲空間被即時回收，那網(wǎng)絡功能可能會訪問到不正確的狀態(tài)。為了避免該問題，本文系統(tǒng)使用超時機制，在流終止后僅記錄當前的時間戳，以便讓系統(tǒng)在足夠長時間(例如10 ms)后再對該流狀態(tài)的存儲空間進行回收。

5 實 驗

5.1 實驗環(huán)境

1) 實驗平臺。本文實驗服務器采用18核Intel Xeon E5-2695v4 CPU和128 GB的DDR4 ECC內(nèi)存，并配備有NVIDIATitanX (Pascal) GPU(共有3 584個CUDA核心)。該服務器的網(wǎng)絡接口使用具有雙SPF插槽的IntelXL710 40GbENIC網(wǎng)卡。軟件配置方面，服務器安裝有Ubuntu 16.04，Linux kernel版本為4.15.0-43-generic。

2) 系統(tǒng)實現(xiàn)。我們的原型系統(tǒng)基于IntelDPDK(Data Plane Development Kit) 18.02實現(xiàn)了用戶態(tài)的網(wǎng)絡I/O。系統(tǒng)使用Docker 18.09.3容器平臺，每個網(wǎng)絡功能的進程運行在單獨的Docker容器中。與此同時，原型系統(tǒng)的基礎設施部分運行在獨立的進程中，并使用共享內(nèi)存與網(wǎng)絡功能進行通信。為了使系統(tǒng)性能盡可能高效，我們將原型系統(tǒng)基礎設施和網(wǎng)絡功能中的每個線程與一個物理CPU核心使用sched_setaffinityAPI進行綁定，以消除操作系統(tǒng)上下文切換可能帶來的性能開銷。在流狀態(tài)管理方面，系統(tǒng)基于libnids 1.24實現(xiàn)協(xié)議棧相關功能，并在此基礎上實現(xiàn)了共享狀態(tài)機制。為了便于比較，我們還實現(xiàn)了另一套不具備共享狀態(tài)機制的對照系統(tǒng)。在對照系統(tǒng)中，除了原系統(tǒng)基礎設施部分的協(xié)議棧和狀態(tài)存儲需要由各個網(wǎng)絡功能自行實現(xiàn)，其他部分與原型系統(tǒng)完全相同。

3) 網(wǎng)絡功能。我們實現(xiàn)了4個GPU加速的網(wǎng)絡功能，以對系統(tǒng)在實際負載中的性能表現(xiàn)進行評估。我們實現(xiàn)的網(wǎng)絡功能包括：(1)Firewall：針對包在TCP/IP層的五元組進行過濾[18]，CPU上執(zhí)行有狀態(tài)過濾，GPU上執(zhí)行無狀態(tài)過濾。(2)IPsec網(wǎng)關：使用HMAC-SHA1 和AES-128 (CTR mode)進行網(wǎng)絡包的加解密，有狀態(tài)。(3)NIDS：使用Aho-Corasick算法[19]執(zhí)行網(wǎng)絡入侵檢測，有狀態(tài)。需要注意的是，各個已經(jīng)實現(xiàn)的網(wǎng)絡功能的GPU加速部分實現(xiàn)并不是高度優(yōu)化、性能領先的最先進方案。本節(jié)的討論重點在于使用共享狀態(tài)管理機制是否能帶來系統(tǒng)的整體性能提升，而不在于性能的絕對值大小。

4) 測試流量。使用基于IntelDPDK實現(xiàn)了一個網(wǎng)絡流量生成器，并將其部署在一臺配備Intel XL710 40GbE網(wǎng)卡的服務器上，以便提供實驗中所需要的網(wǎng)絡流量。這臺機器與部署NFV系統(tǒng)的實驗服務器使用速度為40 Gbit/s的光纖相連。在實驗中，網(wǎng)絡流量生成器可以連續(xù)不斷地生成具有不同目的IP地址的TCP包，從而模擬包含大量TCP連接的網(wǎng)絡流量。

5.2 網(wǎng)絡功能中CPU時間開銷

首先驗證使用共享式管理機制時，網(wǎng)絡功能處理數(shù)據(jù)包時CPU開銷的變化。本實驗中，使用Firewall、IPsec和NIDS三個GPU加速的網(wǎng)絡功能，分別在原型系統(tǒng)與對照系統(tǒng)中測量了這些網(wǎng)絡功能處理每批數(shù)據(jù)包時，CPU處理時間的平均占比。實驗結果如圖5所示，其中原型系統(tǒng)在以上各類網(wǎng)絡功能中均有效地減少了CPU處理部分的時間開銷占總開銷的比重，在批數(shù)量為1 024時，三個網(wǎng)絡功能的CPU處理時間的比重分別減少了26.7%、26.5%和24.0%。這是因為在原型系統(tǒng)中，網(wǎng)絡功能可以利用共享式狀態(tài)管理特性，節(jié)省大量協(xié)議棧處理和狀態(tài)管理的計算，從而降低CPU-GPU計算流水線中CPU部分的開銷。

圖5 網(wǎng)絡功能中CPU執(zhí)行時間比例

另外，從實驗結果可以看出，隨著批處理數(shù)量的增長，網(wǎng)絡功能中的CPU處理的開銷占總處理開銷的比例也顯著增加。這是由于網(wǎng)絡功能的CPU和GPU處理流水線中，CPU部分的并行度較低，因此其處理時間受到批數(shù)量的影響相比于GPU更大，最終體現(xiàn)在隨著批數(shù)量增大，CPU處理時間比例也隨之增長。這種效應在能夠于GPU中大量并行處理數(shù)據(jù)包載荷的IPsec和NIDS兩個網(wǎng)絡功能中尤為突出。這類網(wǎng)絡功能中，共享式狀態(tài)管理對CPU處理開銷的優(yōu)化更為明顯，因此，使用共享式狀態(tài)管理后，后兩種網(wǎng)絡功能在CPU上開銷降低的效果更為顯著。

5.3 服務鏈上的吞吐量

本節(jié)分別在原型系統(tǒng)和對照系統(tǒng)上部署由多個網(wǎng)絡功能組成的服務鏈，以評估共享式狀態(tài)管理機制對系統(tǒng)吞吐量的影響。本實驗中，我們使用的服務鏈由三個網(wǎng)絡功能構成：Firewall-NIDS-IPsec網(wǎng)關。由于在GPU加速的網(wǎng)絡功能中，通?？梢酝ㄟ^調(diào)節(jié)每次傳入GPU的數(shù)據(jù)包批數(shù)量(batchsize)來增加數(shù)據(jù)包處理延遲的代價換取吞吐量的提升，為了公正對比兩系統(tǒng)，我們在GPU資源調(diào)度中實現(xiàn)了動態(tài)批數(shù)量調(diào)節(jié)機制，以確保兩個系統(tǒng)中各個網(wǎng)絡功能的延遲均相同(均為1 ms)。在此實驗條件下，使用具有不同TCP流數(shù)量的網(wǎng)絡流量分別原型系統(tǒng)和對照系統(tǒng)中測量了系統(tǒng)的最高吞吐量的相對差異，實驗結果如圖6所示。從實驗結果可以看出，當數(shù)據(jù)包大小為512 B時，本文的原型系統(tǒng)實現(xiàn)了最多達2倍的吞吐量提升，而其中的主要原因在于網(wǎng)絡功能中協(xié)議棧處理和狀態(tài)管理開銷的大大降低。原型系統(tǒng)中使用3.2節(jié)的狀態(tài)管理方法，可以允許網(wǎng)絡功能在無須實現(xiàn)協(xié)議棧的情況下，利用框架提供的包描述符實現(xiàn)流狀態(tài)和自定義狀態(tài)的快速維護，網(wǎng)絡功能中CPU處理的時間開銷降低，在網(wǎng)絡功能處理總延遲一定的情況下，GPU資源調(diào)度器可以進一步通過調(diào)整GPU批數(shù)量提升GPU處理階段計算效率，從而提升整個服務鏈數(shù)據(jù)包處理吞吐量。另外，從圖6可以看出，本文原型系統(tǒng)相比對照系統(tǒng)獲得的性能提升隨著網(wǎng)絡流量中流數(shù)量的增加而增長。這是因為流數(shù)量的增加可以顯著增大協(xié)議棧處理和狀態(tài)管理中的內(nèi)存訪問開銷，而共享式狀態(tài)管理有效地分攤了額外的開銷，從而降低了網(wǎng)絡功能中的CPU負載并防止其成為系統(tǒng)的性能瓶頸。

圖6 服務鏈上共享式狀態(tài)管理帶來的吞吐量提升

6 結 語

本文對GPU加速的NFV系統(tǒng)中，利用虛擬化方式獨立部署網(wǎng)絡功能的一類系統(tǒng)中存在的問題進行了分析，發(fā)現(xiàn)這類系統(tǒng)存在網(wǎng)絡功能的CPU處理階段性能低效的問題。針對以上問題，本文提出一個新的針對GPU加速的NFV系統(tǒng)框架，通過共享式狀態(tài)管理機制，減少網(wǎng)絡功能中重復性的協(xié)議棧處理和流狀態(tài)管理開銷，以提升GPU加速的效果。通過對原型系統(tǒng)進行實驗評估，本文驗證了該機制有效地降低了GPU加速的NFV系統(tǒng)網(wǎng)絡功能處理流水線中CPU階段的開銷，使得整個處理流水線更加高效，并在常見的網(wǎng)絡功能服務鏈上達到了最高2倍的吞吐量提升。