RDMA（遠程直接數據存取），以其對業務帶來的高性能、低延時優勢，在數據中心尤其是AI、HPC、大數據等場景得到了廣泛應用。為保障RDMA的穩定運行，基礎網絡需要提供端到端無損零丟包及超低延時的能力，這也催生了PFC、ECN等網絡流控技術在RDMA網絡中的部署。在RDMA網絡中，如何合理設置MMU（緩存管理單元）水線是保證RDMA網絡無損和低延時的關鍵。本文將以RDMA網絡作為切入點，結合實際部署經驗，分析MMU水線設置的一些思路。

什么是RDMA？

RDMA（Remote Direct Memory Access），通俗的說就是遠程的DMA技術，是為了解決網絡傳輸中服務器端數據處理的延遲而產生的。

▲ 傳統模式與RDMA模式工作機制對比

如上圖，在傳統模式下，兩臺服務器上的應用之間傳輸數據，過程是這樣的：

● 首先要把數據從應用緩存拷貝到Kernel中的TCP協議棧緩存；

● 然后再拷貝到驅動層；

● 最后拷貝到網卡緩存。

多次內存拷貝需要CPU多次介入，導致處理延時大，達到數十微秒。同時整個過程中CPU過多參與，大量消耗CPU性能，影響正常的數據計算。

在RDMA 模式下，應用數據可以繞過Kernel協議棧直接向網卡寫數據，帶來的顯著好處有：

● 處理延時由數十微秒降低到1微秒內；

● 整個過程幾乎不需要CPU參與，節省性能；

● 傳輸帶寬更高。

RDMA對于網絡的訴求

RDMA在高性能計算、大數據分析、IO高并發等場景中應用越來越廣泛。諸如iSICI， SAN， Ceph， MPI， Hadoop， Spark， Tensorflow等應用軟件都開始部署RDMA技術。而對于支撐端到端傳輸的基礎網絡而言，低延時（微秒級）、無損（lossless）則是最重要的指標。

低延時

網絡轉發延時主要產生在設備節點（這里忽略了光電傳輸延時和數據串行延時），設備轉發延時包括以下三部分：

● 存儲轉發延時：芯片轉發流水線處理延遲，每個hop會產生1微秒左右的芯片處理延時（業界也有嘗試使用cut-through模式，單跳延遲可以降低到0.3微秒左右）；

● Buffer緩存延時：當網絡擁塞時，報文會被緩存起來等待轉發。這時Buffer越大，緩存報文的時間就越長，產生的時延也會更高。對于RDMA網絡，Buffer并不是越大越好，需要合理選擇；

● 重傳延時：在RDMA網絡里會有其他技術保證不丟包，這部分不做分析。

無損

RDMA在無損狀態下可以滿速率傳輸，而一旦發生丟包重傳，性能會急劇下降。在傳統網絡模式下，要想實現不丟包最主要的手段就是依賴大緩存，但如前文所說，這又與低延時矛盾了。因此，在RDMA網絡環境中，需要實現的是較小Buffer下的不丟包。

在這個限制條件下，RDMA實現無損主要是依賴基于PFC和ECN的網絡流控技術。

PFC

PFC（Priority-based Flow Control），基于優先級的流量控制。是一種基于隊列的反壓機制，通過發送Pause幀通知上游設備暫停發包來防止緩存溢出丟包。

▲ PFC工作機制示意圖

PFC允許單獨暫停和重啟其中任意一條虛擬通道，同時不影響其它虛擬通道的流量。如上圖所示，當隊列7的Buffer消耗達到設置的PFC流控水線，會觸發PFC的反壓：

● 本端交換機觸發發出PFC Pause幀，并反向發送給上游設備；

● 收到Pause幀的上游設備會暫停該隊列報文的發送，同時將報文緩存在Buffer中；

● 如果上游設備的Buffer也達到閾值，會繼續觸發Pause幀向上游反壓；

● 最終通過降低該優先級隊列的發送速率來避免數據丟包；

● 當Buffer占用降低到恢復水線時，會發送PFC解除報文。

RDMA無損網絡的關鍵技術：ECN

ECN（Explicit Congestion Notification）：顯示擁塞通知。ECN是一個非常古老的技術，只是之前使用的并不普遍，該協議機制作用于主機與主機之間。

ECN是報文在網絡設備出口（Egress port）發生擁塞并觸發ECN水線時，使用IP報文頭的ECN字段標記數據包，表明該報文遇到網絡擁塞。一旦接收服務器發現報文的ECN被標記，立刻產生CNP（擁塞通知報文），并將它發送給源端服務器，CNP消息里包含了導致擁塞的Flow信息。源端服務器收到后，通過降低相應流發送速率，緩解網絡設備擁塞，從而避免發生丟包。

通過之前的描述可以了解到，PFC和ECN之所以可以實現網絡端到端的零丟包，是通過設置不同的水線來實現的。對這些水線的合理設置，就是針對交換機MMU的精細化管理，通俗講就是對交換機Buffer的管理。接下來我們具體分析下PFC的水線設置。

PFC水線設置

交換芯片都有固定的Pipeline（轉發流水線）， Buffer管理處于入芯片流程和出芯片流程的中間位置。報文處于在這個位置上時，已經知道了該報文的入口和出口信息，因此邏輯上就可以分成入方向和出方向分別對緩存進行管理。

PFC水線是基于入方向緩存管理進行觸發的。芯片在入口方向提供了8個隊列，我們可以將不同優先級的業務報文映射到不同的隊列上，從而實現對不同優先級的報文提供不同的Buffer分配方案。

▲ 隊列Buffer的組成部分

具體到每個隊列，其Buffer分配根據使用場景設計為3部分：保證緩存，共享緩存，Headroom。

● 保證緩存：每個隊列的專用緩存，確保每個隊列均有一定緩存以保證基本轉發；

● 共享緩存：流量突發時可以申請使用的緩存，所有隊列共享；

● Headroom：在觸發PFC水線后，到服務器響應降速前，還可以繼續使用的緩存。

保證緩存設置

保證緩存是一個靜態水線（固定的、獨享的）。靜態水線的利用率非常低，資源消耗卻非常大。我們在實際部署時建議不分配保證緩存，以減少這部分的緩存消耗。這樣，入方向報文直接使用共享緩存空間，可提高Buffer的利用率。

共享緩存設置

對于共享緩存的設置，需要采用更為靈活的動態水線。動態水線能根據當前空閑的Buffer資源，以及當前隊列已使用的Buffer資源數量來決定能否繼續申請到資源。由于系統中空閑共享Buffer資源與已使用的Buffer資源都是時刻變化的，因此閾值也處于不斷變動中。相對于靜態水線，動態水線能更靈活、有效的利用Buffer及避免造成不必要的浪費。

銳捷網絡交換機支持基于動態的方式進行Buffer資源的分配，對共享緩存的設置分為11檔，動態水線alpha值=隊列可申請緩存量/剩余共享緩存量。隊列的α值越大，其在共享緩存中可使用的百分數占比也就越高。

▲共享水線α值與可使用率對應關系

我們不妨分析一下：

隊列的α值設置越小，其最大可申請的共享緩存占比就越小。當端口擁塞時就會越早觸發PFC流控，PFC流控生效后隊列降速，可以很好地保證網絡不丟包。

但從性能的角度看，過早觸發PFC流控，會導致RDMA網絡吞吐下降。因此我們在MMU水線設置時需要選取一個平衡值。

PFC水線到底設置多少，是一個非常復雜的問題，理論上不存在一個固定的值。實際部署時，需要我們具體分析業務模型，并搭建測試環境進行水線調優，找到匹配業務的最佳水線。

Headroom設置

Headroom：顧名思義，就是頭部空間的意思，是在PFC觸發后，到PFC真正生效這一段時間，用來緩存隊列報文的。Headroom設置多大合適？這里與4個因素有關：

● PG檢測到觸發XOFF水線，到構造PFC幀發出的時間（這里主要跟配置的檢測精度以及平均隊列算法相關，固定配置是固定值）

● 上游收到PFC Pause幀，到停止隊列轉發的時間（主要跟芯片處理性能有關系，交換芯片實際上是固定值）

● PFC Pause幀在鏈路上的傳輸時間（跟AOC線纜/光纖距離成正比）

● 隊列暫停發送后鏈路中報文的傳輸時間（跟AOC線纜/光纖距離成正比）

因此Headroom所需要的緩存大小，我們可以根據組網的架構，以及流量模型測算得出。以100米光纖線 + 100G光模塊，緩存64字節小包，計算出所需的Headroom大小是408個cell（cell是緩存管理的最小單元，一個報文會占用1個或者多個cell），實際測試數據也吻合。當然，考慮一定的冗余性，Headroom設置建議比理論值稍大。

RDMA網絡實踐

銳捷網絡在研發中心搭建了模擬真實業務的RDMA網絡，架構如下：

▲銳捷網絡RDMA組網架構

● 組網模型：大核心三級組網架構，核心采用高密100G線卡；

● POD內：Spine采用提供64個100G接口的 BOX設備，Leaf采用提供48個25G接口+8個100G接口的BOX設備；

● Leaf作為服務器網關，支持和服務器間基于PFC流控（識別報文的DSCP并進行PG映射），同時支持擁塞ECN標記；

● RDMA僅運行于POD內部，不存在跨POD的RDMA流量，因此核心無需感知RDMA流量；

● 為了避免擁塞丟包，需要在Leaf與Spine之間部署PFC流控技術，同時Spine設備也需要支持基于擁塞的ECN標記；

● Leaf和Spine設備支持PFC流控幀統計、ECN標記統計、擁塞丟包統計、基于隊列的擁塞統計等，并支持將統計信息通過gRPC同步到遠端gRPC服務器。

寫在最后

銳捷網絡在研發中心同樣搭建了模擬真實業務的浸泡組網環境（包括RG-S6510、RG-S6520、RG-N18000-X系列25G/100G網絡設備、大型測試儀、25G服務器）。在疊加了多種業務模型，并進行了長時間浸泡測試后，我們對于RDMA網絡的MMU水線設置已有一些推薦的經驗值。此外，在RDMA網絡中，還存在一些部署難點，比如多級網絡中 PFC風暴、死鎖問題、ECN水線設計復雜問題等。對于這些問題，銳捷網絡也有一些研究和積累，期待與大家共同探討。

責任編輯：gt