人工智能 (AI) 的興起極大地提高了對強大、高效和可擴展的網(wǎng)絡(luò)傳輸協(xié)議的需求。本文深入探討了 RDMA（遠(yuǎn)程直接內(nèi)存訪問）傳輸協(xié)議，并重點討論 ROCEv2 協(xié)議，目前基于 ROCEv2 的 RDMA已經(jīng)在一些超大規(guī)模數(shù)據(jù)中心中取代了 TCP。

在最近的NDSI-23-Talk中，微軟強調(diào)，70% 的 Azure 云網(wǎng)絡(luò)流量（主要是存儲網(wǎng)絡(luò)流量）在基于以太網(wǎng)的 ROCEv2 RDMA 上運行，只有一小部分依賴基于 TCP/IP 的網(wǎng)絡(luò)，這一轉(zhuǎn)變在 Oracle、阿里巴巴和 Meta 等其他超大規(guī)模提供商中也很明顯。這一趨勢表明，隨著云計算、人工智能/機器學(xué)習(xí)工作負(fù)載的持續(xù)增長，整個行業(yè)正朝著采用RDMA技術(shù)來優(yōu)化網(wǎng)絡(luò)性能的方向發(fā)展。

01RDMA概述

RDMA 通過直接將“內(nèi)存映射”數(shù)據(jù)傳輸?shù)竭h(yuǎn)程內(nèi)存位置來運行，具有兩個關(guān)鍵優(yōu)勢：

CPU 效率：與消耗多個 CPU 核心的 TCP/IP 不同，RDMA在內(nèi)存注冊后將數(shù)據(jù)傳輸委托給 RDMA 網(wǎng)絡(luò)適配器來執(zhí)行，這樣的方式釋放了CPU資源，對于云服務(wù)提供商來說，這可以更有效地利用這些新可用的CPU核心，實現(xiàn)更高的資源利用率。

低延遲和內(nèi)存效率：RDMA 繞過 Linux 內(nèi)核，直接將數(shù)據(jù)傳輸?shù)綉?yīng)用程序緩沖區(qū)，這一功能稱為零復(fù)制。這消除了在發(fā)送和接收端點節(jié)點處進行內(nèi)存復(fù)制的需要。內(nèi)核旁路和零拷貝功能可最大限度地減少延遲和抖動。

RoCEv2 RDMA 起源于高性能計算 (HPC)，并結(jié)合了 IB 傳輸協(xié)議。

| InfiniBand 和 ROCEv2 協(xié)議棧

RoCEv2 保留了 InfiniBand 語義及其傳輸和網(wǎng)絡(luò)協(xié)議，并將InfiniBand鏈路層和物理層替換為以太網(wǎng)。

因此，ROCEv2 RDMA 已成為數(shù)據(jù)中心后端網(wǎng)絡(luò)的標(biāo)準(zhǔn)，可提供高吞吐量、微秒范圍的低延遲和完整的 CPU 卸載。

注意：前端網(wǎng)絡(luò)通常運行 TCP/IP 或 QUIC 等其他協(xié)議。RDMA、InfiniBand 等協(xié)議作為后端網(wǎng)絡(luò)，通常被稱為東西向流量，占現(xiàn)代數(shù)據(jù)中心流量的 70-80%。

02以太網(wǎng) ROCEv2 挑戰(zhàn)

InfiniBand架構(gòu)

InfiniBand架構(gòu)是無損網(wǎng)絡(luò)，重點關(guān)注服務(wù)質(zhì)量 (QoS) 和傳輸層端到端信用。IB 協(xié)議棧非常適合 HPC 和 AI/ML 網(wǎng)絡(luò)。然而，InfiniBand 網(wǎng)絡(luò)通常比以太網(wǎng)更昂貴，可擴展性也更差。

注意：無損意味著底層網(wǎng)絡(luò)被配置為避免因網(wǎng)絡(luò)擁塞而導(dǎo)致數(shù)據(jù)包的丟失。盡管如此，偶爾仍可能會由于錯誤情況導(dǎo)致數(shù)據(jù)包損壞或丟失。在這種情況下，傳輸協(xié)議包括一種端到端的交付機制，其中內(nèi)置了數(shù)據(jù)包重傳邏輯，通常由硬件實現(xiàn)，以此在不需要軟件干預(yù)的情況下觸發(fā)，以恢復(fù)丟失的數(shù)據(jù)包。這確保了在網(wǎng)絡(luò)出現(xiàn)問題時可以自動糾正數(shù)據(jù)包的丟失，無需人工介入。

ROCEv2架構(gòu)

RoCEv2 在以太網(wǎng)鏈路上通過 UDP/IP 上運行。UDP 是一種不可靠的數(shù)據(jù)報服務(wù)，而以太網(wǎng)的架構(gòu)并非無損。由于 ROCEv2 期望底層網(wǎng)絡(luò)是無損的，因此在將以太網(wǎng)配置為無損網(wǎng)絡(luò)時面臨著多項挑戰(zhàn)，如下所述。

| ROCEv2 數(shù)據(jù)包格式

隊頭 (HOL) 阻塞：由于優(yōu)先流量控制 (PFC)，不同流中的數(shù)據(jù)包可能會被擁塞流阻塞，跨更大的網(wǎng)絡(luò)、跨多個交換機進行擴展成為一個挑戰(zhàn)。

擁塞管理：通常由軟件以帶外方式處理?，F(xiàn)有技術(shù)緩慢且復(fù)雜，一些供應(yīng)商借用了 InfiniBand 的硬件技術(shù)，但這些是定制的，不是以太網(wǎng)標(biāo)準(zhǔn)的一部分。

減少有效吞吐量：以太網(wǎng)不是一個無損網(wǎng)絡(luò)。由于擁塞下降，可能會發(fā)生數(shù)據(jù)包丟失，這種數(shù)據(jù)包丟失會導(dǎo)致整個數(shù)據(jù)包窗口的重傳（稱為 Go-back-to-N），從而降低網(wǎng)絡(luò)“goodput”。

盡管存在這些挑戰(zhàn)，大型 ROCEv2 網(wǎng)絡(luò)已經(jīng)成功部署，但要求對其進行精細(xì)調(diào)優(yōu)和持續(xù)監(jiān)控。大多數(shù)超大規(guī)模企業(yè)都采用自定義、非標(biāo)準(zhǔn)的 ROCEv2 解決方案，并在針對不同工作負(fù)載微調(diào)RDMA堆棧方面投入了大量資金。

在某些情況下，組織甚至為 AI/ML 或存儲等特定應(yīng)用程序建立了單獨的基于 ROCEv2 RDMA 的數(shù)據(jù)中心，但這也導(dǎo)致了運營成本的顯著增加。

接下來，我們將深入研究三個不同的案例，以便更全面地理解這一情況。

03大廠案例

微軟

十多年來，微軟一直在大型數(shù)據(jù)中心部署 RoCEv2，并發(fā)表了一篇見解深刻的Microsoft-RDMA-Challenges研究論文。微軟的部署面臨 PFC 死鎖挑戰(zhàn)、RDMA 傳輸活鎖挑戰(zhàn)以及其他網(wǎng)卡相關(guān)問題。

微軟認(rèn)為，單靠協(xié)議理論不足以滿足現(xiàn)實世界的部署，嚴(yán)格的大規(guī)模測試、分階段部署和網(wǎng)卡供應(yīng)商協(xié)作對于發(fā)現(xiàn)協(xié)議最初設(shè)計時隱藏的漏洞至關(guān)重要。微軟已經(jīng)為ROCEv2開發(fā)了自定義協(xié)議擴展，例如基于 DSCP 的 PFC，一些網(wǎng)卡/交換機供應(yīng)商已經(jīng)支持該協(xié)議。此外，微軟還實施了用于健康跟蹤和故障排除的遙測系統(tǒng)，這對于識別這些隱藏的復(fù)雜性問題至關(guān)重要。

Oracle

OCI（Oracle Cloud Infrastructure，Oracle 云基礎(chǔ)設(shè)施）是一個公有云，可在同一 RDMA 網(wǎng)絡(luò)上運行 AI、HPC、數(shù)據(jù)庫和存儲等多種不同應(yīng)用程序。

| Oracle RDMA 網(wǎng)絡(luò)結(jié)構(gòu)

Oracle 通過多種方法應(yīng)對 ROCEv2 挑戰(zhàn)：

限制優(yōu)先級流控制 (PFC)：僅限于 3 層 Clos 網(wǎng)絡(luò)中的網(wǎng)絡(luò)邊緣。

網(wǎng)絡(luò)局部性提示：Oracle 根據(jù)網(wǎng)絡(luò)關(guān)聯(lián)性放置工作負(fù)載，以將大部分流量保持在本地，稱為網(wǎng)絡(luò)局部性提示。

微調(diào)擁塞控制：利用顯式擁塞通知 (ECN) 和 DC-QCN，每個都針對特定 RDMA 工作負(fù)載進行微調(diào)，以平衡延遲和吞吐量。

Meta

Meta 專注于針對 AI/ML 工作負(fù)載的 ROCEv2 RDMA 部署，正如Meta @Scale 2023活動視頻中所討論的那樣，主要工作負(fù)載包括推薦引擎、內(nèi)容理解和大語言模型（LLM），這些集群的規(guī)模從數(shù)百個 GPU 到數(shù)萬個 GPU不等。

有趣的是，Meta 并沒有面臨與微軟相同的挑戰(zhàn)。例如，由于骨干交換機中的深度緩沖區(qū)，PFC HOL 阻塞不再是問題。Meta 還成功地使用 DC-QCN 進行擁塞控制，并且由于現(xiàn)代 NIC 具有更大的 NIC 緩存，因此沒有面臨擴展問題?？偟膩碚f，由于具有先進功能的新硬件以及拓?fù)?、工作?fù)載和軟件策略的差異等多種原因，Meta 沒有遇到相同的問題。

Meta的關(guān)鍵挑戰(zhàn)主要圍繞負(fù)載均衡，這通過依靠 SDN 控制器對路由進行編程來解決。在網(wǎng)絡(luò)事件發(fā)生之前，這些路由不會更新。ECMP 哈希方案僅在網(wǎng)絡(luò)事件發(fā)生后生效。跨多個隊列對 (QP) 的元多路復(fù)用流和定制的 ECMP 哈希方案以增加熵。

Meta 使用 PCIe 點對點 (P2P) DMA 技術(shù)，通過支持跨 GPU 的直接數(shù)據(jù)傳輸來提高應(yīng)用程序性能。

Meta 還超額訂閱了主干層，因為 AI/ML 流量模式不需要完整的非阻塞主干連接。這降低了數(shù)據(jù)中心成本。

與許多其他公司一樣，Meta 正在探索數(shù)據(jù)包噴射、基于分解 VOQ 的交換機以及可以容忍亂序交付的自定義傳輸協(xié)議。

一篇MIT + Meta 研究論文《針對 LLM 的優(yōu)化網(wǎng)絡(luò)架構(gòu)》提出了一種針對 LLM 流量模式的新網(wǎng)絡(luò)架構(gòu)，可以將網(wǎng)絡(luò)成本削減 37% - 75%。該架構(gòu)為具有高通信需求的 GPU 定義了高帶寬或 HB 域。在 HB 內(nèi)，GPU 通過任意對任意互連進行互連。在Meta部署中，跨HB網(wǎng)絡(luò)流量稀疏，可以消除跨HB域的連接和交換機，從而降低網(wǎng)絡(luò)成本。

04RDMA 的未來

超大規(guī)模廠商和供應(yīng)商都以自定義的方式解決了 ROCEv2 的潛在問題。ROCEv2 網(wǎng)絡(luò)仍然需要針對每個工作負(fù)載進行定制和微調(diào)。

1RMA 擴展框架

具有多個租戶的公共云需要大規(guī)模擴展，達到數(shù)百萬個節(jié)點和數(shù)十億個流。由于 ROCEv2 面向連接的特性，工作隊列條目 (WQE) 通常在硬件中實現(xiàn)，這限制了流量擴展。跨多個租戶的安全性和線速加密給 RoCEv2 帶來了額外的挑戰(zhàn)。

| 消費者排隊模型

云數(shù)據(jù)中心的一個替代方案是1RMA 論文中記錄的 1-Shot 遠(yuǎn)程內(nèi)存訪問 (1RMA) 方法，該方法建議以軟件為中心的重新架構(gòu)。由于片上系統(tǒng) (SoC)處理器內(nèi)核現(xiàn)在可在基于 DPU/IPU 的網(wǎng)絡(luò)適配器上運行軟件，因此這種以軟件為中心的方法變得更加可行。主要思想是：

軟件重點：將一些傳統(tǒng)的網(wǎng)卡硬件數(shù)據(jù)結(jié)構(gòu)（例如排隊、數(shù)據(jù)包排序、數(shù)據(jù)包調(diào)步和擁塞控制）轉(zhuǎn)移到軟件中。

硬件重點：將網(wǎng)卡硬件重點放在主數(shù)據(jù)路徑、DMA 傳輸、incast 邊界、身份驗證和加密上。硬件無需連接，并向軟件提供細(xì)粒度的延遲測量和故障通知。

1RMA 方法主張將連接和大部分狀態(tài)轉(zhuǎn)移到軟件中，以獲得更好的可擴展性。這簡化了硬件并支持公共云所需的大規(guī)模擴展。

請注意，采用 1RMA 方法可能需要從頭開始重新架構(gòu)，涉及新協(xié)議和 NIC 硬件。此外，1RMA 的研究重點是云數(shù)據(jù)中心的需求；AI/ML 和 HPC 網(wǎng)絡(luò)可能需要不同的權(quán)衡。

UEC聯(lián)盟

UEC聯(lián)盟提議用基于UDP/IP的新開放協(xié)議取代ROCEv2。UEC 的重點是 AI/ML 和 HPC 網(wǎng)絡(luò)。

# ROCEv2 替代協(xié)議的關(guān)鍵屬性

多路徑和數(shù)據(jù)包噴射

靈活的交付順序和選擇性重傳

響應(yīng)式擁塞控制機制

規(guī)模更大、穩(wěn)定可靠

堆棧的所有層可能都需要進行更改。

UEC聯(lián)盟白皮書中的一些主題確實與1RMA Paper和EDQS Paper(由Correct Networks撰寫，被Broadcom收購)產(chǎn)生了共鳴。

在10 月 17 日的OCP峰會上，OCP與 UEC 達成合作，利用兩家組織的專業(yè)技能來提高AI工作負(fù)載的以太網(wǎng)性能。已確定初步探索潛在合作的領(lǐng)域包括 OCP交換機抽象接口（SAI）、OCP Caliptra Workstream、OCP網(wǎng)絡(luò)項目、OCP網(wǎng)卡Workstream、OCP Time Appliance項目和OCP未來技術(shù)倡議。

未來的開放標(biāo)準(zhǔn)

到目前為止，還沒有 ROCEv3 標(biāo)準(zhǔn)。針對這些挑戰(zhàn)的可擴展、通用和開放的解決方案仍然難以實現(xiàn)。

AI/ML、HPC 和云數(shù)據(jù)中心工作負(fù)載的需求可能差異很大，以至于我們需要多種解決方案。例如，

# UEC聯(lián)盟

UltraEthernet 聯(lián)盟僅專注于大規(guī)模人工智能和高性能計算。

# 工作負(fù)載特征

HPC 要求超低延遲，而 AI/ML 訓(xùn)練優(yōu)先考慮高吞吐量和低尾延遲。

# 多種拓?fù)?/strong>