網(wǎng)絡(luò)數(shù)據(jù)包的實(shí)時(shí)GPU處理方案原理解析

網(wǎng)絡(luò)數(shù)據(jù)包的實(shí)時(shí)GPU處理方案原理解析網(wǎng)絡(luò)數(shù)據(jù)包的實(shí)時(shí)GPU處理是一種適用于幾個(gè)不同應(yīng)用領(lǐng)域的技術(shù)，包括信號處理、網(wǎng)絡(luò)安全、信息收集和輸入重建。這些應(yīng)用程序的目標(biāo)是實(shí)現(xiàn)一個(gè)內(nèi)聯(lián)數(shù)據(jù)包處理管線（Pipeline），以在GPU內(nèi)存中接收數(shù)據(jù)包（無需通過CPU內(nèi)存暫存副本）；與一個(gè)或多個(gè)CUDA內(nèi)核并行地處理它們；然后運(yùn)行推斷、評估或通過網(wǎng)絡(luò)發(fā)送計(jì)算結(jié)果。通常，在這個(gè)管線中，CPU是協(xié)調(diào)人，因?yàn)樗仨毷咕W(wǎng)卡（NIC）接收活動(dòng)與GPU處理同步。一旦GPU內(nèi)存中接收到新的數(shù)據(jù)包，這將喚醒CUDA內(nèi)核。類似的方法也可以應(yīng)用于管線的發(fā)送側(cè)。圖1.以CPU為中心的應(yīng)用程序，CPU協(xié)調(diào)GPU和網(wǎng)卡工作數(shù)據(jù)平面開發(fā)套件（DPDK）框架引入了goudev庫

來為此類應(yīng)用提供解決方案：使用GPU內(nèi)存（GPUDirectRDMA技術(shù)）結(jié)合低延遲CPU同步進(jìn)行接收或發(fā)送。

01

GPU發(fā)起的通信從圖1中可以看出，CPU是主要瓶頸。它在同步NIC和GPU任務(wù)以及管理多個(gè)網(wǎng)絡(luò)隊(duì)列方面承擔(dān)了太多的責(zé)任。例如，考慮一個(gè)具有多個(gè)接收隊(duì)列和100Gbps傳入流量的應(yīng)用程序。以CPU為中心的解決方案將具有：CPU調(diào)用每個(gè)接收隊(duì)列上的網(wǎng)絡(luò)功能，以使用一個(gè)或多個(gè)CPU核心接收GPU存儲(chǔ)器中的數(shù)據(jù)包CPU收集數(shù)據(jù)包信息（數(shù)據(jù)包地址、編號）CPU向GPU通知新接收的數(shù)據(jù)包GPU處理數(shù)據(jù)包這種以CPU為中心的方法是：資源消耗：為了處理高速率網(wǎng)絡(luò)吞吐量（100Gbps或更高），應(yīng)用程序可能需要專用整個(gè)CPU物理核心來接收（和/或發(fā)送）數(shù)據(jù)包不可擴(kuò)展：為了與不同的隊(duì)列并行接收（或發(fā)送），應(yīng)用程序可能需要使用多個(gè)CPU核心，即使在CPU核心的總數(shù)可能被限制在較低數(shù)量（取決于平臺）的系統(tǒng)上也是如此平臺依賴性：低功耗CPU上的同一應(yīng)用程序?qū)⒔档托阅蹽PU內(nèi)聯(lián)分組處理應(yīng)用程序的下一個(gè)自然步驟是從關(guān)鍵路徑中刪除CPU。移動(dòng)到以GPU為中心的解決方案，GPU可以直接與NIC交互以接收數(shù)據(jù)包，因此數(shù)據(jù)包一到達(dá)GPU內(nèi)存，處理就可以開始。同樣的方法也適用于發(fā)送操作。GPU從CUDA內(nèi)核控制NIC活動(dòng)的能力稱為GPU發(fā)起的通信。假設(shè)使用NVIDIAGPU和NVIDIANIC，則可以將NIC寄存器暴露給GPU的直接訪問。這樣，CUDA內(nèi)核可以直接配置和更新這些寄存器，以協(xié)調(diào)發(fā)送或接收網(wǎng)絡(luò)操作，而無需CPU的干預(yù)。圖2.以GPU為中心的應(yīng)用程序，GPU控制網(wǎng)卡和數(shù)據(jù)包處理，無需CPU根據(jù)定義，DPDK是CPU框架。要啟用GPU發(fā)起的通信，需要在GPU上移動(dòng)整個(gè)控制路徑，這是不適用的。因此，通過創(chuàng)建新的NVIDIADOCA庫來啟用此功能。

02

NVIDIADOCAGPUNetIO庫NVIDIADOCASDK是新的NVIDIA框架，由驅(qū)動(dòng)程序、庫、工具、文檔和示例應(yīng)用程序組成。需要這些資源通過利用NVIDIA硬件可以在主機(jī)系統(tǒng)和DPU上可用的網(wǎng)絡(luò)、安全性和計(jì)算功能來支持應(yīng)用程序。NVIDIADOCAGPUNetIO是在NVIDIADOCA1.5版本的基礎(chǔ)上開發(fā)的一個(gè)新庫，用于在DOCA生態(tài)系統(tǒng)中引入GPU設(shè)備的概念（圖3）。為了促進(jìn)創(chuàng)建以DOCAGPU為中心的實(shí)時(shí)數(shù)據(jù)包處理應(yīng)用程序，DOCAGPUNetIO結(jié)合了GPUDirectRDMA用于數(shù)據(jù)路徑加速、智能GPU內(nèi)存管理、CPU和GPU之間的低延遲消息傳遞技術(shù)（通過GDRCopy功能）和GPU發(fā)起的通信。這使CUDA內(nèi)核能夠直接控制NVIDIAConnectX網(wǎng)卡。為了最大化性能，DOCAGPUNetIO庫必須用于GPUDirect友好的平臺，其中GPU和網(wǎng)卡通過專用PCIe網(wǎng)橋直接連接。DPU融合卡就是一個(gè)示例，但同樣的拓?fù)湟部梢栽谥鳈C(jī)系統(tǒng)上實(shí)現(xiàn)。DOCAGPUNetIO目標(biāo)是GPU數(shù)據(jù)包處理網(wǎng)絡(luò)應(yīng)用程序，使用以太網(wǎng)協(xié)議在網(wǎng)絡(luò)中交換數(shù)據(jù)包。對于這些應(yīng)用程序，不需要像基于RDMA的應(yīng)用程序那樣，通過OOB機(jī)制跨對等端進(jìn)行預(yù)同步階段。也無需假設(shè)其他對等端將使用DOCAGPUNetIO進(jìn)行通信，也無需了解拓?fù)?。在未來的版本中，RDMA選項(xiàng)將被啟用以覆蓋更多的用例。DOCA當(dāng)前版本中啟用的GPUNetIO功能包括：GPU發(fā)起的通信:CUDA內(nèi)核可以調(diào)用DOCAGPUNetIO庫中的CUDAdevice函數(shù)，以指示網(wǎng)卡發(fā)送或接收數(shù)據(jù)包精確的發(fā)送調(diào)度：通過GPU發(fā)起的通信，可以根據(jù)用戶提供的時(shí)間戳來調(diào)度未來的數(shù)據(jù)包傳輸GPUDirectRDMA：以連續(xù)固定大小GPU內(nèi)存步幅接收或發(fā)送數(shù)據(jù)包，無需CPU內(nèi)存暫存副本信號量：在CPU和GPU之間或不同GPUCUDA內(nèi)核之間提供標(biāo)準(zhǔn)化的低延遲消息傳遞協(xié)議CPU對CUDA內(nèi)存的直接訪問：CPU可以在不使用GPU內(nèi)存API的情況下修改GPU內(nèi)存緩沖區(qū)圖3.NVIDIADOCAGPUNetIO是一個(gè)新的DOCA庫，需要在同一平臺上安裝GPU和CUDA驅(qū)動(dòng)程序和庫如圖4所示，典型的DOCAGPUNetIO應(yīng)用程序步驟如下：CPU上的初始配置階段：使用DOCA識別和初始化GPU設(shè)備和網(wǎng)絡(luò)設(shè)備使用DOCAGPUNetIO創(chuàng)建可從CUDA內(nèi)核管理的接收或發(fā)送隊(duì)列使用

DOCAFlow

確定應(yīng)在每個(gè)接收隊(duì)列中放置哪種類型的數(shù)據(jù)包（例如，IP地址的子集、TCP或UDP協(xié)議等）啟動(dòng)一個(gè)或多個(gè)CUDA內(nèi)核（執(zhí)行數(shù)據(jù)包處理/過濾/分析）CUDA內(nèi)核內(nèi)GPU上的運(yùn)行時(shí)控制和數(shù)據(jù)路徑：使用DOCAGPUNetIOCUDA設(shè)備函數(shù)發(fā)送或接收數(shù)據(jù)包使用DOCAGPUNetIOCUDA設(shè)備函數(shù)與信號量交互，以使工作與其他CUDA內(nèi)核或CPU同步圖4.由多個(gè)構(gòu)建塊組成的通用GPU數(shù)據(jù)包處理管線數(shù)據(jù)流以下各節(jié)概述了結(jié)合DOCAGPUNetIO構(gòu)建塊的可能GPU數(shù)據(jù)包處理管線應(yīng)用程序布局。

03

CPU接收和GPU處理第一個(gè)示例以CPU為中心，不使用GPU發(fā)起的通信功能。它可以被視為以下章節(jié)的基線。CPU創(chuàng)建可從CPU自身管理的接收隊(duì)列，以接收GPU存儲(chǔ)器中的數(shù)據(jù)包，并為每個(gè)隊(duì)列分配流量控制規(guī)則。在運(yùn)行時(shí)，CPU接收GPU存儲(chǔ)器中的數(shù)據(jù)包。它通過DOCAGPUNetIO信號量向一個(gè)或多個(gè)CUDA內(nèi)核通知每個(gè)隊(duì)列新一組數(shù)據(jù)包的到達(dá)，提供GPU內(nèi)存地址和數(shù)據(jù)包數(shù)量等信息。在GPU上，CUDA內(nèi)核輪詢信號量，檢測更新并開始處理數(shù)據(jù)包。圖5.GPU數(shù)據(jù)包處理管道，CPU在GPU內(nèi)存中接收數(shù)據(jù)包，并使用NVIDIADOCAGPUNetIO信號量通知數(shù)據(jù)包處理CUDA內(nèi)核有關(guān)傳入數(shù)據(jù)包這里，DOCAGPUNetIO信號量具有類似于DPDKgpudevcommunicationlist的功能，使得CPU接收數(shù)據(jù)包和GPU在處理這些數(shù)據(jù)包之前等待接收這些數(shù)據(jù)包之間能夠?qū)崿F(xiàn)低延遲通信機(jī)制。信號量還可用于GPU在包處理完成時(shí)通知CPU，或在兩個(gè)GPUCUDA內(nèi)核之間共享關(guān)于已處理包的信息。該方法可作為性能評估的基準(zhǔn)。由于它以CPU為中心，因此嚴(yán)重依賴CPU型號、功率和內(nèi)核數(shù)量。

04

GPU接收和GPU處理上一節(jié)中描述的以CPU為中心的管線可以通過以GPU為中心的方法進(jìn)行改進(jìn)，該方法使用GPU發(fā)起的通信，使用CUDA內(nèi)核管理接收隊(duì)列。以下部分提供了兩個(gè)示例：多CUDA內(nèi)核和單CUDA內(nèi)核。

05

多CUDA內(nèi)核使用這種方法，至少涉及兩個(gè)CUDA內(nèi)核，一個(gè)專用于接收數(shù)據(jù)包，另一個(gè)專用用于數(shù)據(jù)包處理。接收器CUDA內(nèi)核可以通過信號量向第二CUDA內(nèi)核提供數(shù)據(jù)包信息。圖6.GPU數(shù)據(jù)包處理管線，CPU在GPU內(nèi)存中接收數(shù)據(jù)包，并使用DOCAGPUNetIO信號量通知數(shù)據(jù)包處理CUDA內(nèi)核有關(guān)傳入數(shù)據(jù)包這種方法適用于高速網(wǎng)絡(luò)和延遲敏感的應(yīng)用程序，因?yàn)閮蓚€(gè)接收操作之間的延遲不會(huì)被其他任務(wù)延遲。期望將接收器CUDA內(nèi)核的每個(gè)CUDA塊關(guān)聯(lián)到不同的隊(duì)列，并行地接收來自所有隊(duì)列的所有數(shù)據(jù)包。

06

單CUDA內(nèi)核通過使單個(gè)CUDA內(nèi)核負(fù)責(zé)接收和處理數(shù)據(jù)包，仍然為每個(gè)隊(duì)列專用一個(gè)CUDA塊，可以簡化先前的實(shí)現(xiàn)。圖7.GPU數(shù)據(jù)包處理管線，單個(gè)GPUCUDA內(nèi)核接收GPU內(nèi)存中的數(shù)據(jù)包并進(jìn)行數(shù)據(jù)包處理這種方法的一個(gè)缺點(diǎn)是每個(gè)CUDA塊兩個(gè)接收操作之間的延遲。如果數(shù)據(jù)包處理需要很長時(shí)間，應(yīng)用程序可能無法跟上在高速網(wǎng)絡(luò)中接收新數(shù)據(jù)包的速度。

07

GPU接收、GPU處理和GPU發(fā)送到目前為止，大多數(shù)關(guān)注點(diǎn)都集中在管線的“接收和處理”部分。然而，DOCAGPUNetIO還可以在GPU上生成一些數(shù)據(jù)，制作數(shù)據(jù)包并從CUDA內(nèi)核發(fā)送，而無需CPU干預(yù)。圖8描述了一個(gè)完整的接收、處理和發(fā)送管線的示例圖8.具有GPUCUDA內(nèi)核的GPU數(shù)據(jù)包處理管線在GPU內(nèi)存中接收數(shù)據(jù)包，進(jìn)行數(shù)據(jù)包處理，最后制作新數(shù)據(jù)包

08

NVIDIADOCA

GPUNetIO示例應(yīng)用程序與任何其他NVIDIADOCA庫一樣，DOCAGPUNetIO有一個(gè)專用應(yīng)用程序，用于API使用參考和測試系統(tǒng)配置和性能。該應(yīng)用程序?qū)崿F(xiàn)了前面描述的管線，提供了不同類型的數(shù)據(jù)包處理，如IP校驗(yàn)和、HTTP數(shù)據(jù)包過濾和流量轉(zhuǎn)發(fā)。以下部分概述了應(yīng)用程序的不同操作模式。報(bào)告了一些性能數(shù)據(jù)，將其視為可能在未來版本中更改和改進(jìn)的初步結(jié)果。使用兩個(gè)基準(zhǔn)系統(tǒng)，一個(gè)用于接收數(shù)據(jù)包，另一個(gè)用于發(fā)送數(shù)據(jù)包，背靠背連接（圖9）。運(yùn)行DOCAGPUNetIO應(yīng)用程序的接收器是帶有NVIDIABlueField-2XDPU融合卡

的DellPowerEdgeR750。該配置為嵌入式CPU模式，因此應(yīng)用程序使用DPU上的NVIDIAConnectX-6Dx網(wǎng)卡和GPUA100X在主機(jī)系統(tǒng)CPU上運(yùn)行。軟件配置為Ubuntu20.04、MOFED5.8和CUDA11.8。發(fā)送器是GigabyteIntelXeonGold6240R，其通過PCIeGen3與NVIDIAConnectX-6Dx連接。此計(jì)算機(jī)不需要任何GPU，因?yàn)樗\(yùn)行T-RexDPDKpacketgeneratorv2.99。軟件配置為Ubuntu20.04和MOFED5.8。圖9.接收器（DellR750）和發(fā)送器（Gigabyte）系統(tǒng)背靠背連接到基準(zhǔn)NVIDIADOCAGPUNetIO應(yīng)用程序該應(yīng)用程序也已在DPUArm內(nèi)核上執(zhí)行，導(dǎo)致了相同的性能結(jié)果，并證明了以GPU為中心的解決方案與CPU無關(guān)。請注意，DOCAGPUNetIO最低要求是具有GPU和具有直接PCIe連接的NIC的系統(tǒng)。DPU并不是嚴(yán)格要求。

09

IP校驗(yàn)和，GPU僅接收應(yīng)用程序使用GPU發(fā)起的通信來創(chuàng)建一個(gè)或多個(gè)接收隊(duì)列以接收分?jǐn)?shù)據(jù)包?？梢允褂脝蜟UDA內(nèi)核或多CUDA內(nèi)核模式。圖10.NVIDIADOCAGPUNetIO應(yīng)用程序中的第一個(gè)管線模式：GPU接收、計(jì)算IP校驗(yàn)和并向CPU報(bào)告每個(gè)數(shù)據(jù)包都通過簡單的IP校驗(yàn)和驗(yàn)證進(jìn)行處理，只有通過此測試的數(shù)據(jù)包才算作“好數(shù)據(jù)包”。通過信號量，好數(shù)據(jù)包的數(shù)量被報(bào)告給CPU，CPU可以在控制臺上打印報(bào)告。通過使用T-Rex數(shù)據(jù)包生成器以約100Gbps（約11.97Mpps）的速度發(fā)送30億個(gè)1KB大小的數(shù)據(jù)包，并在DOCAGPUNetIO應(yīng)用程序側(cè)報(bào)告相同數(shù)量的數(shù)據(jù)包以及正確的IP校驗(yàn)和，實(shí)現(xiàn)了單隊(duì)列零數(shù)據(jù)包丟失。相同的配置在BlueField-2融合卡上進(jìn)行了測試，結(jié)果相同，證明了GPU發(fā)起的通信是一個(gè)獨(dú)立于平臺的解決方案。由于數(shù)據(jù)包大小為512字節(jié)，T-Rex數(shù)據(jù)包生成器無法發(fā)送超過86Gbps（約20.9Mpps）的數(shù)據(jù)包。即使每秒數(shù)據(jù)包的數(shù)量幾乎是兩倍，DOCAGPUNetIO也沒有報(bào)告任何數(shù)據(jù)包丟失。

10

HTTP過濾，GPU僅接收假設(shè)一個(gè)更復(fù)雜的場景，數(shù)據(jù)包處理CUDA內(nèi)核只過濾具有特定特征的HTTP數(shù)據(jù)包。它將“好數(shù)據(jù)包”信息復(fù)制到第二個(gè)GPU內(nèi)存HTTP數(shù)據(jù)包列表中。一旦此HTTP數(shù)據(jù)包列表中的下一個(gè)項(xiàng)目充滿了數(shù)據(jù)包，通過專用信號量，過濾CUDA內(nèi)核就會(huì)解除第二個(gè)CUDA內(nèi)核的阻止，從而對累積的HTTP數(shù)據(jù)包進(jìn)行一些推斷。信號量還可用于向CPU線程報(bào)告統(tǒng)計(jì)信息。圖11.

NVIDIADOCAGPUNetIO應(yīng)用程序中的第二種管線模式。GPU只接收、過濾HTTP數(shù)據(jù)包，并通過專用信號量解除阻止CUDA內(nèi)核對這些數(shù)據(jù)包進(jìn)行分析該管線配置提供了復(fù)雜流水線的示例，該復(fù)雜管線包括多個(gè)數(shù)據(jù)處理和過濾階段以及諸如AI管線之類的推理功能。

11

流量轉(zhuǎn)發(fā)本節(jié)介紹如何通過GPU發(fā)起的通信使用DOCAGPUNetIO啟用流量轉(zhuǎn)發(fā)。在每個(gè)接收到的數(shù)據(jù)包中，在通過網(wǎng)絡(luò)發(fā)送回?cái)?shù)據(jù)包之前，交換MAC和IP源地址和目的地址。圖12.NVIDIADOCAGPUNetIO應(yīng)用程序中的第三種管線模式。GPU接收、交換每個(gè)數(shù)據(jù)包的MAC和IP地址，并發(fā)送回修改后的數(shù)據(jù)包。通過使用T-Rex數(shù)據(jù)包生成器以~90Gbps的速度發(fā)送30億個(gè)1KB大小的數(shù)據(jù)包，實(shí)現(xiàn)了只有一個(gè)接收隊(duì)列和一個(gè)發(fā)送隊(duì)列的零數(shù)據(jù)包丟失。

12

用于5G的NVIDIAAerialSDK決定采用以GPU為中心的解決方案的動(dòng)機(jī)可能是性能和低延遲要求，但也可能是為了提高系統(tǒng)容量。CPU在處理連接到接收器應(yīng)用程序的越來越多的對等端時(shí)可能成為瓶頸。GPU提供的高度并行化可以提供可擴(kuò)展的實(shí)現(xiàn)，以并行處理大量對等端，而不會(huì)影響性能。NVIDIAAerial是一個(gè)用于構(gòu)建高性能、軟件定義的5GL1堆棧的SDK，該堆棧通過GPU上的并行處理進(jìn)行了優(yōu)化。具體而言，NVIDIAAeroSDK可用于構(gòu)建基帶單元（BBU）軟件，該軟件負(fù)責(zé)通過無線電單元（RU）發(fā)送（下行鏈路）或接收（上行鏈路）無線客戶端數(shù)據(jù)幀，該數(shù)據(jù)幀被拆分為多個(gè)以太網(wǎng)數(shù)據(jù)包。在上行鏈路中，BBU接收數(shù)據(jù)包，驗(yàn)證數(shù)據(jù)包，并在觸發(fā)信號處理之前重建每個(gè)RU的原始數(shù)據(jù)幀。使用NVIDIAAerialSDK，這在GPU中發(fā)生：CUDA內(nèi)核專用于每個(gè)時(shí)隙的每個(gè)RU，以重建幀并觸發(fā)GPU信號處理的CUDA內(nèi)核序列。通過DPDKgpudev庫實(shí)現(xiàn)了網(wǎng)卡接收數(shù)據(jù)包以及GPU重新排序和處理數(shù)據(jù)包的編排（圖13）。圖13.

NVIDIAAerial5GL1以CPU為中心的架構(gòu)，帶有DPDKgpudev庫第一個(gè)實(shí)現(xiàn)在現(xiàn)代Intelx86系統(tǒng)上僅使用一個(gè)CPU內(nèi)核，就能夠以25Gbps的速度保持4個(gè)RU的工作速度。然而，隨著基站數(shù)量的增加，網(wǎng)卡和GPU之間的CPU功能成為瓶頸。CPU按順序工作。隨著單個(gè)CPU核心接收和管理越來越多的RU流量，同一RU的兩次接收之間的時(shí)間取決于RU的數(shù)量。對于2個(gè)CPU核，每個(gè)核在RU的子集上工作，相同RU的兩次接收之間的時(shí)間減半。然而，這種方法對于越來越多的客戶端是不可擴(kuò)展的。此外，PCIe事務(wù)的數(shù)量從NIC增加到CPU，然后從CPU增加到GPU（圖14）。圖14.NVIDIAAerial5G應(yīng)用程序以CPU為中心的控制流程，連接了多個(gè)RU。CPU內(nèi)核順序地接收并通知每個(gè)連接的RU的GPU重建內(nèi)核。這不是一種可擴(kuò)展的方法。為了克服所有這些問題，NVIDIAAerialSDK的以GPU為中心的新版本已通過DOCAGPUNetIO庫實(shí)現(xiàn)。每個(gè)CUDA內(nèi)核負(fù)責(zé)在每個(gè)時(shí)隙重建來自特定RU的數(shù)據(jù)包，并通過接收能力進(jìn)行了改進(jìn)（圖15）。圖15.以GPU為中心的NVIDIAAerialSDK5G架構(gòu)，采用NVIDIADOCAGPUNetIO此時(shí)，關(guān)鍵路徑中不需要CPU，因?yàn)槊總€(gè)CUDA內(nèi)核都是完全獨(dú)立的，能夠并行和實(shí)時(shí)處理越來越多的RU。這增加了系統(tǒng)容量，并減少了每個(gè)時(shí)隙處理數(shù)據(jù)包的延遲和PCIe事務(wù)的數(shù)量。CPU不必與GPU通信以提供數(shù)據(jù)包信息。圖16.NVIDIAAerial5GSDK以GPU為中心的控制流程，連接了多個(gè)RU。這是一種可擴(kuò)