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

網(wǎng)絡數(shù)據(jù)包的實時 GPU 處理是一種適用于幾個不同應用領域的技術，包括信號處理、網(wǎng)絡安全、信息收集和輸入重建。這些應用程序的目標是實現(xiàn)一個內聯(lián)數(shù)據(jù)包處理管線（Pipeline），以在 GPU 內存中接收數(shù)據(jù)包（無需通過 CPU 內存暫存副本）；與一個或多個 CUDA 內核并行地處理它們；然后運行推斷、評估或通過網(wǎng)絡發(fā)送計算結果。通常，在這個管線中，CPU 是協(xié)調人，因為它必須使網(wǎng)卡（NIC）接收活動與 GPU 處理同步。一旦 GPU 內存中接收到新的數(shù)據(jù)包，這將喚醒 CUDA 內核。類似的方法也可以應用于管線的發(fā)送側。

圖 1 . 以 CPU 為中心的應用程序， CPU 協(xié)調 GPU 和網(wǎng)卡工作數(shù)據(jù)平面開發(fā)套件（DPDK）框架引入了 goudev 庫?來為此類應用提供解決方案：使用 GPU 內存（GPUDirect RDMA 技術）結合低延遲 CPU 同步進行接收或發(fā)送。 ?

01?GPU發(fā)起的通信

從圖 1 中可以看出，CPU 是主要瓶頸。它在同步 NIC 和 GPU 任務以及管理多個網(wǎng)絡隊列方面承擔了太多的責任。例如，考慮一個具有多個接收隊列和 100 Gbps 傳入流量的應用程序。以 CPU 為中心的解決方案將具有：

CPU 調用每個接收隊列上的網(wǎng)絡功能，以使用一個或多個 CPU 核心接收 GPU 存儲器中的數(shù)據(jù)包

CPU 收集數(shù)據(jù)包信息（數(shù)據(jù)包地址、編號）

CPU 向 GPU 通知新接收的數(shù)據(jù)包

GPU 處理數(shù)據(jù)包

這種以 CPU 為中心的方法是：

資源消耗：為了處理高速率網(wǎng)絡吞吐量（100 Gbps 或更高），應用程序可能需要專用整個 CPU 物理核心來接收（和/或發(fā)送）數(shù)據(jù)包

不可擴展：為了與不同的隊列并行接收（或發(fā)送），應用程序可能需要使用多個 CPU 核心，即使在 CPU 核心的總數(shù)可能被限制在較低數(shù)量（取決于平臺）的系統(tǒng)上也是如此

平臺依賴性：低功耗 CPU 上的同一應用程序將降低性能

GPU 內聯(lián)分組處理應用程序的下一個自然步驟是從關鍵路徑中刪除 CPU 。移動到以 GPU 為中心的解決方案，GPU 可以直接與 NIC 交互以接收數(shù)據(jù)包，因此數(shù)據(jù)包一到達 GPU 內存，處理就可以開始。同樣的方法也適用于發(fā)送操作。 GPU 從 CUDA 內核控制 NIC 活動的能力稱為 GPU 發(fā)起的通信。假設使用 NVIDIA GPU 和 NVIDIA NIC ，則可以將 NIC 寄存器暴露給 GPU 的直接訪問。這樣，CUDA 內核可以直接配置和更新這些寄存器，以協(xié)調發(fā)送或接收網(wǎng)絡操作，而無需 CPU 的干預。

圖 2 . 以 GPU 為中心的應用程序，GPU 控制網(wǎng)卡和數(shù)據(jù)包處理，無需 CPU 根據(jù)定義，DPDK 是 CPU 框架。要啟用 GPU 發(fā)起的通信，需要在 GPU 上移動整個控制路徑，這是不適用的。因此，通過創(chuàng)建新的 NVIDIA DOCA 庫來啟用此功能。 ?

02?NVIDIA DOCA GPUNetIO 庫

NVIDIA DOCA SDK 是新的 NVIDIA 框架，由驅動程序、庫、工具、文檔和示例應用程序組成。需要這些資源通過利用 NVIDIA 硬件可以在主機系統(tǒng)和 DPU 上可用的網(wǎng)絡、安全性和計算功能來支持應用程序。 NVIDIA DOCA GPUNetIO 是在 NVIDIA DOCA 1.5 版本的基礎上開發(fā)的一個新庫，用于在 DOCA 生態(tài)系統(tǒng)中引入 GPU 設備的概念（圖 3）。為了促進創(chuàng)建以 DOCA GPU 為中心的實時數(shù)據(jù)包處理應用程序，DOCA GPUNetIO 結合了 GPUDirect RDMA 用于數(shù)據(jù)路徑加速、智能 GPU 內存管理、CPU 和 GPU 之間的低延遲消息傳遞技術（通過 GDRCopy 功能）和 GPU 發(fā)起的通信。這使 CUDA 內核能夠直接控制 NVIDIA ConnectX 網(wǎng)卡。為了最大化性能， DOCA GPUNetIO 庫必須用于 GPUDirect 友好的平臺，其中 GPU 和網(wǎng)卡通過專用 PCIe 網(wǎng)橋直接連接。DPU 融合卡就是一個示例，但同樣的拓撲也可以在主機系統(tǒng)上實現(xiàn)。 DOCA GPUNetIO 目標是 GPU 數(shù)據(jù)包處理網(wǎng)絡應用程序，使用以太網(wǎng)協(xié)議在網(wǎng)絡中交換數(shù)據(jù)包。對于這些應用程序，不需要像基于 RDMA 的應用程序那樣，通過 OOB 機制跨對等端進行預同步階段。也無需假設其他對等端將使用 DOCA GPUNetIO 進行通信，也無需了解拓撲。在未來的版本中，RDMA 選項將被啟用以覆蓋更多的用例。 DOCA 當前版本中啟用的 GPUNetIO 功能包括：

GPU 發(fā)起的通信: CUDA 內核可以調用 DOCA GPUNetIO 庫中的 CUDA device 函數(shù)，以指示網(wǎng)卡發(fā)送或接收數(shù)據(jù)包

精確的發(fā)送調度：通過 GPU 發(fā)起的通信，可以根據(jù)用戶提供的時間戳來調度未來的數(shù)據(jù)包傳輸

GPU Direct RDMA ：以連續(xù)固定大小 GPU 內存步幅接收或發(fā)送數(shù)據(jù)包，無需 CPU 內存暫存副本

信號量：在 CPU 和 GPU 之間或不同 GPU CUDA 內核之間提供標準化的低延遲消息傳遞協(xié)議

CPU 對 CUDA 內存的直接訪問：CPU 可以在不使用 GPU 內存 API 的情況下修改 GPU 內存緩沖區(qū)

圖 3 . NVIDIA DOCA GPUNetIO 是一個新的 DOCA 庫，需要在同一平臺上安裝 GPU 和 CUDA 驅動程序和庫如圖 4 所示，典型的 DOCA GPUNetIO 應用程序步驟如下： CPU 上的初始配置階段：

使用 DOCA 識別和初始化 GPU 設備和網(wǎng)絡設備

使用 DOCA GPUNetIO 創(chuàng)建可從 CUDA 內核管理的接收或發(fā)送隊列

使用?DOCA Flow?確定應在每個接收隊列中放置哪種類型的數(shù)據(jù)包（例如，IP 地址的子集、TCP 或 UDP 協(xié)議等）

啟動一個或多個 CUDA 內核（執(zhí)行數(shù)據(jù)包處理/過濾/分析）

CUDA 內核內 GPU 上的運行時控制和數(shù)據(jù)路徑：

使用 DOCA GPUNetIO CUDA 設備函數(shù)發(fā)送或接收數(shù)據(jù)包

使用 DOCA GPUNetIO CUDA 設備函數(shù)與信號量交互，以使工作與其他 CUDA 內核或 CPU 同步

圖 4 . 由多個構建塊組成的通用 GPU 數(shù)據(jù)包處理管線數(shù)據(jù)流以下各節(jié)概述了結合 DOCA GPUNetIO 構建塊的可能 GPU 數(shù)據(jù)包處理管線應用程序布局。 ?

03?CPU 接收和 GPU 處理

第一個示例以 CPU 為中心，不使用 GPU 發(fā)起的通信功能。它可以被視為以下章節(jié)的基線。CPU 創(chuàng)建可從 CPU 自身管理的接收隊列，以接收 GPU 存儲器中的數(shù)據(jù)包，并為每個隊列分配流量控制規(guī)則。在運行時，CPU 接收 GPU 存儲器中的數(shù)據(jù)包。它通過 DOCA GPUNetIO 信號量向一個或多個 CUDA 內核通知每個隊列新一組數(shù)據(jù)包的到達，提供 GPU 內存地址和數(shù)據(jù)包數(shù)量等信息。在 GPU 上，CUDA 內核輪詢信號量，檢測更新并開始處理數(shù)據(jù)包。

圖 5 . GPU 數(shù)據(jù)包處理管道，CPU 在 GPU 內存中接收數(shù)據(jù)包，并使用 NVIDIA DOCA GPUNetIO 信號量通知數(shù)據(jù)包處理 CUDA 內核有關傳入數(shù)據(jù)包這里，DOCA GPUNetIO 信號量具有類似于 DPDK gpudev communication list 的功能，使得 CPU 接收數(shù)據(jù)包和 GPU 在處理這些數(shù)據(jù)包之前等待接收這些數(shù)據(jù)包之間能夠實現(xiàn)低延遲通信機制。信號量還可用于 GPU 在包處理完成時通知 CPU ，或在兩個 GPU CUDA 內核之間共享關于已處理包的信息。該方法可作為性能評估的基準。由于它以 CPU 為中心，因此嚴重依賴 CPU 型號、功率和內核數(shù)量。 ?

04?GPU 接收和 GPU 處理

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

05?多 CUDA 內核

使用這種方法，至少涉及兩個 CUDA 內核，一個專用于接收數(shù)據(jù)包，另一個專用用于數(shù)據(jù)包處理。接收器 CUDA 內核可以通過信號量向第二 CUDA 內核提供數(shù)據(jù)包信息。

圖 6 . GPU 數(shù)據(jù)包處理管線，CPU 在 GPU 內存中接收數(shù)據(jù)包，并使用 DOCA GPUNetIO 信號量通知數(shù)據(jù)包處理 CUDA 內核有關傳入數(shù)據(jù)包這種方法適用于高速網(wǎng)絡和延遲敏感的應用程序，因為兩個接收操作之間的延遲不會被其他任務延遲。期望將接收器 CUDA 內核的每個 CUDA 塊關聯(lián)到不同的隊列，并行地接收來自所有隊列的所有數(shù)據(jù)包。 ?

06?單CUDA內核

通過使單個 CUDA 內核負責接收和處理數(shù)據(jù)包，仍然為每個隊列專用一個 CUDA 塊，可以簡化先前的實現(xiàn)。

圖 7 . GPU 數(shù)據(jù)包處理管線，單個 GPU CUDA 內核接收 GPU 內存中的數(shù)據(jù)包并進行數(shù)據(jù)包處理這種方法的一個缺點是每個 CUDA 塊兩個接收操作之間的延遲。如果數(shù)據(jù)包處理需要很長時間，應用程序可能無法跟上在高速網(wǎng)絡中接收新數(shù)據(jù)包的速度。 ?

07?GPU 接收、 GPU 處理和 GPU 發(fā)送

到目前為止，大多數(shù)關注點都集中在管線的“接收和處理”部分。然而，DOCA GPUNetIO 還可以在 GPU 上生成一些數(shù)據(jù)，制作數(shù)據(jù)包并從 CUDA 內核發(fā)送，而無需 CPU 干預。圖 8 描述了一個完整的接收、處理和發(fā)送管線的示例

圖 8 . 具有 GPU CUDA 內核的 GPU 數(shù)據(jù)包處理管線在 GPU 內存中接收數(shù)據(jù)包，進行數(shù)據(jù)包處理，最后制作新數(shù)據(jù)包 ?

08?NVIDIA DOCA?

GPUNetIO 示例應用程序

與任何其他 NVIDIA DOCA 庫一樣，DOCA GPUNetIO 有一個專用應用程序，用于 API 使用參考和測試系統(tǒng)配置和性能。該應用程序實現(xiàn)了前面描述的管線，提供了不同類型的數(shù)據(jù)包處理，如 IP 校驗和、HTTP 數(shù)據(jù)包過濾和流量轉發(fā)。以下部分概述了應用程序的不同操作模式。報告了一些性能數(shù)據(jù)，將其視為可能在未來版本中更改和改進的初步結果。使用兩個基準系統(tǒng)，一個用于接收數(shù)據(jù)包，另一個用于發(fā)送數(shù)據(jù)包，背靠背連接（圖 9）。運行 DOCA GPUNetIO 應用程序的接收器是帶有 NVIDIA BlueField-2X DPU 融合卡?的 Dell PowerEdge R750 。該配置為嵌入式 CPU 模式，因此應用程序使用 DPU 上的 NVIDIA ConnectX-6 Dx 網(wǎng)卡和 GPU A100X 在主機系統(tǒng) CPU 上運行。軟件配置為 Ubuntu 20.04 、MOFED 5.8 和 CUDA 11.8 。發(fā)送器是 Gigabyte Intel Xeon Gold 6240R ，其通過 PCIe Gen 3 與 NVIDIA ConnectX-6 Dx 連接。此計算機不需要任何 GPU ，因為它運行 T-Rex DPDK packet generator v2.99 。軟件配置為 Ubuntu 20.04 和 MOFED 5.8 。

圖 9 . 接收器（Dell R750）和發(fā)送器（Gigabyte）系統(tǒng)背靠背連接到基準 NVIDIA DOCA GPUNetIO 應用程序該應用程序也已在 DPU Arm 內核上執(zhí)行，導致了相同的性能結果，并證明了以 GPU 為中心的解決方案與 CPU 無關。請注意，DOCA GPUNetIO 最低要求是具有 GPU 和具有直接 PCIe 連接的 NIC 的系統(tǒng)。DPU 并不是嚴格要求。 ?

09?IP 校驗和， GPU 僅接收

應用程序使用 GPU 發(fā)起的通信來創(chuàng)建一個或多個接收隊列以接收分數(shù)據(jù)包。可以使用單 CUDA 內核或多 CUDA 內核模式。

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

10?HTTP 過濾， GPU 僅接收

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

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

11?流量轉發(fā)

本節(jié)介紹如何通過 GPU 發(fā)起的通信使用 DOCA GPUNetIO 啟用流量轉發(fā)。在每個接收到的數(shù)據(jù)包中，在通過網(wǎng)絡發(fā)送回數(shù)據(jù)包之前，交換 MAC 和 IP 源地址和目的地址。

圖 12 . NVIDIA DOCA GPUNetIO 應用程序中的第三種管線模式。GPU 接收、交換每個數(shù)據(jù)包的 MAC 和 IP 地址，并發(fā)送回修改后的數(shù)據(jù)包。通過使用 T-Rex 數(shù)據(jù)包生成器以 ~90 Gbps 的速度發(fā)送 30 億個 1KB 大小的數(shù)據(jù)包，實現(xiàn)了只有一個接收隊列和一個發(fā)送隊列的零數(shù)據(jù)包丟失。 ?

12?用于 5G 的 NVIDIA Aerial SDK

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

圖 13 .?NVIDIA Aerial 5G L1 以 CPU 為中心的架構，帶有 DPDK gpudev 庫第一個實現(xiàn)在現(xiàn)代 Intel x86 系統(tǒng)上僅使用一個 CPU 內核，就能夠以 25 Gbps 的速度保持 4 個 RU 的工作速度。然而，隨著基站數(shù)量的增加，網(wǎng)卡和 GPU 之間的 CPU 功能成為瓶頸。 CPU 按順序工作。隨著單個 CPU 核心接收和管理越來越多的 RU 流量，同一 RU 的兩次接收之間的時間取決于 RU 的數(shù)量。對于 2 個 CPU 核，每個核在 RU 的子集上工作，相同 RU 的兩次接收之間的時間減半。然而，這種方法對于越來越多的客戶端是不可擴展的。此外，PCIe 事務的數(shù)量從 NIC 增加到 CPU ，然后從 CPU 增加到 GPU （圖 14）。

圖 14 . NVIDIA Aerial 5G 應用程序以 CPU 為中心的控制流程，連接了多個 RU 。CPU 內核順序地接收并通知每個連接的 RU 的 GPU 重建內核。這不是一種可擴展的方法。為了克服所有這些問題，NVIDIA Aerial SDK 的以 GPU 為中心的新版本已通過 DOCA GPUNetIO 庫實現(xiàn)。每個 CUDA 內核負責在每個時隙重建來自特定 RU 的數(shù)據(jù)包，并通過接收能力進行了改進（圖 15）。

圖 15 . 以 GPU 為中心的 NVIDIA Aerial SDK 5G 架構，采用 NVIDIA DOCA GPUNetIO 此時，關鍵路徑中不需要 CPU ，因為每個 CUDA 內核都是完全獨立的，能夠并行和實時處理越來越多的 RU 。這增加了系統(tǒng)容量，并減少了每個時隙處理數(shù)據(jù)包的延遲和 PCIe 事務的數(shù)量。CPU 不必與 GPU 通信以提供數(shù)據(jù)包信息。

圖 16 . NVIDIA Aerial 5G SDK 以 GPU 為中心的控制流程，連接了多個 RU 。這是一種可擴展的方法，它保證了對所有連接的平等和公平服務。根據(jù)標準，5G 網(wǎng)絡必須根據(jù)特定模式交換數(shù)據(jù)包。每個時隙（例如 500 微秒），數(shù)據(jù)包應該以 14 個所謂的符號發(fā)送。每個符號由若干個數(shù)據(jù)包組成（取決于使用情況），這些數(shù)據(jù)包將在較小的時間窗口（例如，36 微秒）內發(fā)送。為了在下行鏈路側支持這種定時傳輸模式，NVIDIA Aerial SDK 通過 DOCA GPUNetIO API 將 GPU 發(fā)起的通信與精確發(fā)送調度相結合。一旦 GPU 信號處理準備好要在未來時隙中發(fā)送的數(shù)據(jù)，每個 RU 的專用 CUDA 內核將該數(shù)據(jù)分割成每個 RU 的以太網(wǎng)數(shù)據(jù)包，并在未來的特定時間調度它們的未來傳輸。然后，同一 CUDA 內核將數(shù)據(jù)包推送到 NIC ，NIC 將負責在正確的時間發(fā)送每個數(shù)據(jù)包（圖 17）。