基于GPU加速的NFV系統的框架設計和性能優化

郭良琛 張 凱

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

0 引 言

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

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

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

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

1 背景介紹

1.1 網絡功能與NFV系統

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

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

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

1.2 基于GPU的NFV系統設計

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

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

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

圖1 一個典型的使用GPU加速的網絡功能流水線

2 相關工作

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

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

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

3 現有系統的問題

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

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

圖2 一些GPU加速的網絡功能批處理時間的分解

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

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

4 系統設計

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

4.1 總體框架

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

圖3 系統架構

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

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

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

4.2 協議棧處理與狀態管理

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

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

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

圖4 流的共享狀態管理

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

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

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

5 實 驗

5.1 實驗環境

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

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

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

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

5.2 網絡功能中CPU時間開銷

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

圖5 網絡功能中CPU執行時間比例

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

5.3 服務鏈上的吞吐量

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

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

6 結 語

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