目錄
1.rdma介紹
2. rdma原理
網絡環境下的CPU負載消耗
3. rdma傳輸
3.1雙邊操作
3.2 單邊操作
4 RoCEv2的封包格式
4.1 RoCEv2的封包格式
4.2 IB BTH格式和字段定義
5 無損網絡和PFC
5.1 擁塞産生的原因
5.1.1 收斂比(總輸入帶寬/總的輸出帶寬)
5.1.2 ECMP(ECMP建構多條等價負載鍊路,HASH選擇到已擁塞鍊路發送加劇擁塞）
5.1.3 TCP Incast（多對一）
5.2 PFC如何實作流控
5.2.1FC(整個鍊路流控）
5.2.2 PFC（基于優先級流控）
5.2.3 RoCEv1（RDMA封裝協定）隊列映射
5.2.4 RoCEv2（RDMA封裝協定）隊列映射
5.3 PFC存在的問題
5.3.1 死鎖（PFCdeadlock）
5.3.2 pause幀風暴
5.3.3 隊頭阻塞（HOL Blocking/堵塞問題）
5.3.4 不公平問題
5.4 利用ECN實作端到端的擁塞控制
5.4.1 ECN互動過程
5.4.2 PFC和ECN對比
1.rdma介紹
在網絡融合的大趨勢下出現的RoCE，使高速、超低延時、極低cpu使用率的RDMA得以部署在目前使用最廣泛的以太網上。
對比傳統DMA的内部總線IO，RDMA通過網絡在兩個端點的應用軟體之間實作buffer的直接傳遞；
而對比傳統的網絡傳輸，RDMA又無需作業系統和協定棧的介入。
RDMA可以輕易實作端點間的超低延時、超高吞吐量傳輸，而且基本不需要CPU、OS的資源參與，在高速網絡環境下，不必再為網絡資料的處理和搬移耗費過多資源。
一言概之，RDMA三大特性：CPU offload 、kernel bypass、zero-copy。
傳統方式
rdma方式
如上圖，在傳統模式下，兩台伺服器上的應用之間傳輸資料，過程是這樣的：
首先要把資料從應用緩存拷貝到Kernel中的TCP協定棧緩存；
然後再拷貝到驅動層；
最後拷貝到網卡緩存。
多次記憶體拷貝需要CPU多次介入，導緻處理延時大，達到數十微秒。同時整個過程中CPU過多參與，大量消耗CPU性能，影響正常的資料計算。
在RDMA 模式下，應用資料可以繞過Kernel協定棧直接向網卡寫資料，帶來的顯著好處有：
處理延時由數十微秒降低到1微秒内；
整個過程幾乎不需要CPU參與，節省性能；
傳輸帶寬更高。
2. rdma原理
傳統的網絡架構以“網絡為中心”，網絡公用的軟體部分被實作到OS的協定棧，是以OS在所有應用的網絡請求時都必須參與其中，并且socket、skbuff、ring buffer的轉換都伴随着資料封包的拷貝，容易産生性能瓶頸。
網絡環境下的CPU負載消耗
RDMA提供了基于消息隊列的點對點通信，每個應用都可以直接擷取自己的消息，無需OS和協定棧的介入。
消息服務建立在通信雙方本端和遠端應用之間建立的channel-IO連接配接之上。
當應用需要通信時，就會建立一條Channel連接配接，每條Channel的首尾端點是兩對Queue Pairs（QP），每對QP由Send Queue（SQ）和Receive Queue（RQ）構成，這些隊列中管理着各種類型的消息。
QP會被映射到應用的虛拟位址空間，使得應用直接通過它通路RNIC。除了QP描述的兩種基本隊列之外，RDMA還提供一種隊列-Complete Queue（CQ），CQ用來知會使用者WQ上的消息已經被處理完。
RDMA提供了一套software transport interface，友善使用者建立傳輸請求-Work Request（WR），WR中描述了應用希望傳輸到Channel對端的消息内容。
WR通知給QP中的某個隊列-Work Queue（WQ）。
在WQ中，使用者的WR被轉化為Work Queue Ellement（WQE）的格式，等待RNIC的異步排程解析，并從WQE指向的buffer中拿到真正的消息發送到Channel對端。
3. rdma傳輸
RDMA 的send/receive和read/write傳輸
RDMA共有三種底層資料傳輸模式。
SEND/RECEIVE是雙邊操作，即必須要遠端的應用感覺參與才能完成收發。
READ和WRITE是單邊操作，隻需要本端明确資訊的源和目的位址，遠端應用不必感覺此次通信，資料的讀或存都通過遠端的DMA在RNIC與應用buffer之間完成，再由遠端RNIC封裝成消息傳回到本端。
在實際中，SEND/RECEIVE多用于連接配接控制類封包，而資料封包多是通過READ/WRITE來完成的。
3.1雙邊操作
對于雙邊操作為例，A向B發送資料的流程如下：
首先，A和B都要建立并初始化好各自的QP，CQ
A和B分别向自己的WQ中注冊WQE，對于A，WQ=SQ，WQE描述指向一個等到被發送的資料；對于B，WQ=RQ，WQE描述指向一塊用于存儲資料的buffer。
A的RNIC異步排程輪到A的WQE，解析到這是一個SEND消息，從buffer中直接向B發出資料。資料流到達B的RNIC後，B的WQE被消耗，并把資料直接存儲到WQE指向的存儲位置。
AB通信完成後，A的CQ中會産生一個完成消息CQE表示發送完成。與此同時，B的CQ中也會産生一個完成消息表示接收完成。每個WQ中WQE的處理完成都會産生一個CQE。
雙邊操作與傳統網絡的底層buffer pool類似，收發雙方的參與過程并無差别，差別在零拷貝、kernel bypass，實際上傳統網絡中一些進階的網絡SOC已經實作類似功能。
對于RDMA，這是一種複雜的消息傳輸模式，多用于傳輸短的控制消息。
3.2 單邊操作
對于單邊操作，以存儲網絡環境下的存儲為例（A作為檔案系統，B作為存儲媒體）：
首先A、B建立連接配接，QP已經建立并且初始化。
資料被存檔在A的buffer位址VA，注意VA應該提前注冊到A的RNIC，并拿到傳回的local key，相當于RDMA操作這塊buffer的權限。
A把資料位址VA，key封裝到專用的封包傳送到B，這相當于A把資料buffer的操作權交給了B。同時A在它的WQ中注冊進一個WR，以用于接收資料傳輸的B傳回的狀态。
B在收到A的送過來的資料VA和R_key後，RNIC會把它們連同存儲位址VB到封裝RDMA READ，這個過程A、B兩端不需要任何軟體參與，就可以将A的資料存儲到B的VB虛拟位址。
B在存儲完成後，會向A傳回整個資料傳輸的狀态資訊。
單邊操作傳輸方式是RDMA與傳統網絡傳輸的最大不同，提供直接通路遠端的虛拟位址，無須遠端應用的參與，這種方式适用于批量資料傳輸。
4 RoCEv2的封包格式
RoCEv2的協定棧包括IB傳輸層、UDP、IP和Ethernet，其中，後面三層都使用了TCP/IP中相應層次的封包格式。
4.1 RoCEv2的封包格式
RoCEv2的封包格式如下圖所示
其中，UDP標頭中，目的端口号為4791即代表是RoCEv2幀。
IB BTH即InfiniBand Base Transport Header，定義了IB傳輸層的相應頭部字段。
IB Payload即為消息負載。ICRC和FCS分别對應備援檢測和幀校驗。
4.2 IB BTH格式和字段定義
其中，Opcode用于表明該包的type或IB PayLoad中更高層的協定類型。
S是Solicited Event的縮寫，表明回應者産生應該産生一個事件。
M是MigReq的縮寫，一般用于遷移狀态。Pad表明有多少額外位元組被填充到IB PayLoad中。
TVer即Transport Header Version，表明該包的版本号。
Partition Key用來表征與本Packet關聯的邏輯記憶體分區。
rsvd是reserved的縮寫，該字段是保留的。
Destination QP表明目的端Queue Pair序号。
A是Acknowledge Request，表示該packet的應答可由響應者排程。
PSN是Packet Sequence Number，用來檢測丢失或重複的資料包。
如前文所述，RDMA是一種智能網卡與軟體架構充分優化的遠端記憶體直接高速通路技術，通過将RDMA技術固化于網卡上實作，
即，在RoCEv2協定棧中，IB BTH、UDP、IP以及Ethernet Layer全是固化在網卡上的。
使用者空間的Application通過OFA Stack(亦或其他組織編寫的RDMA stack)提供的verbs程式設計接口(比如WRITE、READ、SEND等)形成IB payload，接下來便直接進入硬體，由RDMA網卡實作負載的層層封裝。
如上圖，在傳統模式下，兩台伺服器上的應用之間傳輸資料，過程是這樣的：
首先要把資料從應用緩存拷貝到Kernel中的TCP協定棧緩存；
然後再拷貝到驅動層；
最後拷貝到網卡緩存。
多次記憶體拷貝需要CPU多次介入，導緻處理延時大，達到數十微秒。同時整個過程中CPU過多參與，大量消耗CPU性能，影響正常的資料計算。
在RDMA 模式下，應用資料可以繞過Kernel協定棧直接向網卡寫資料，帶來的顯著好處有：
處理延時由數十微秒降低到1微秒内；
整個過程幾乎不需要CPU參與，節省性能；
傳輸帶寬更高。
5 無損網絡和PFC
目前RDMA在以太網上的傳輸協定是RoCEv2，RoCEv2是基于無連接配接協定的UDP協定，相比面向連接配接的TCP協定，UDP協定更加快速、占用CPU資源更少，但其不像TCP協定那樣有滑動視窗、确認應答等機制來實作可靠傳輸，一旦出現丢包，依靠上層應用檢查到了再做重傳，會大大降低RDMA的傳輸效率。
是以要想發揮出RDMA真正的性能，突破資料中心大規模分布式系統的網絡性能瓶頸，勢必要為RDMA搭建一套不丢包的無損網絡環境，而實作不丢包的關鍵就是解決網絡擁塞。
5.1 擁塞産生的原因
5.1.1 收斂比(總輸入帶寬/總的輸出帶寬)
進行資料中心網絡架構設計時，從成本和收益兩方面來考慮，多數會采取非對稱帶寬設計，即上下行鍊路帶寬不一緻，交換機的收斂比簡單說就是總的輸入帶寬除以總的輸出帶寬。
交換機A：下行帶寬480G，上行帶寬240G，整機收斂比為2:1
交換機B：下行帶寬1200G，上行帶寬800G，整機收斂比為1.5:1
也就是說，當下聯的伺服器上行發包總速率超過上行鍊路總帶寬時，就會在上行口出現擁塞
5.1.2 ECMP(ECMP建構多條等價負載鍊路,HASH選擇到已擁塞鍊路發送加劇擁塞）
目前資料中心網絡多采用Fabric架構，并采用ECMP來建構多條等價負載的鍊路，并HASH選擇一條鍊路來轉發，是簡單的，但這個過程沒有考慮到所選鍊路本身是否有擁塞，對于已經産生擁塞的鍊路來說，很可能加劇鍊路的擁塞
5.1.3 TCP Incast（多對一）
TCP Incast是Many-to-One（多對一）的通信模式，parent向所有node發出資料請求，多個node幾乎同時向parent發出資料回複，形成多打一造成擁堵。
為了實作端到端的無損轉發，避免因為交換機中的Buffer緩沖區溢出而引發的資料包丢失，交換機必須引入其他機制，如流量控制，通過對鍊路上流量的控制，減少對交換機Buffer的壓力，來規避丢包的産生。
5.2 PFC如何實作流控
IEEE 802.1Qbb(Priority-based Flow Control，基于優先級的流量控制)簡稱PFC，是流量控制的增強版。
（流控發展史：FC(整個鍊路流控）-->PFC（基于優先級流控）-->PFC+ECN（流控發生前避免擁塞）/PFC+ETS（配置設定帶寬）+ECN）
5.2.1FC(整個鍊路流控）
IEEE 802.3X(Flow Control)流控的機制：當接收者沒有能力處理接收到的封包時，為了防止封包被丢棄，接收者需要通知封包的發送者暫時停止發送封包
如下圖所示，端口G0/1和G0/2以1Gbps速率轉發封包時，端口F0/1将發生擁塞。為避免封包丢失，開啟端口G0/1和G0/2的Flow Control功能。
當F0/1在轉發封包出現擁塞時，交換機B會在端口緩沖區中排隊封包，當擁塞超過一定門檻值時，端口G0/2向G0/1發PAUSE幀，通知G0/1暫時停止發送封包。
• G0/1接收到PAUSE幀後暫時停止向G0/2發送封包。暫停時間長短資訊由PAUSE幀所攜帶。交換機A會在這個逾時範圍内等待，或者直到收到一個Timeout值為0的控制幀後再繼續發送。
5.2.2 PFC（基于優先級流控）
FC（IEEE 802.3X協定）缺點：一旦鍊路被暫停，發送方就不能再發送任何資料包，如果是因為某些優先級較低的資料流引發的暫停，結果卻讓該鍊路上其他更高優先級的資料流也一起被暫停了，其實是得不償失的。
▲ PFC工作機制示意圖
PFC允許單獨暫停和重新開機其中任意一條虛拟通道，同時不影響其它虛拟通道的流量。如上圖所示，當隊列7的Buffer消耗達到設定的PFC流控水線，會觸發PFC的反壓：
- 本端交換機觸發發出PFC Pause幀，并反向發送給上遊裝置；
- 收到Pause幀的上遊裝置會暫停該隊列封包的發送，同時将封包緩存在Buffer中；
- 如果上遊裝置的Buffer也達到門檻值，會繼續觸發Pause幀向上遊反壓；
- 最終通過降低該優先級隊列的發送速率來避免資料丢包；
- 當Buffer占用降低到恢複水線時，會發送PFC解除封包。
PFC在基礎流控IEEE 802.3X基礎上進行擴充，允許在一條以太網鍊路上建立8個虛拟通道，并為每條虛拟通道指定相應優先級，允許單獨暫停和重新開機其中任意一條虛拟通道，同時允許其它虛拟通道的流量無中斷通過。
PFC将流控的粒度從實體（端口）細化到（8個虛拟通道），分别對應Smart NIC硬體上的8個硬體發送隊列(這些隊列命名為Traffic Class，分别為TC0,TC1,...,TC7)，在RDMA不同的封裝協定下，也有不同的映射方式。
5.2.3 RoCEv1（RDMA封裝協定）隊列映射
這個協定是将RDMA資料段封裝到以太網資料段内，再加上以太網的頭部，是以屬于二層資料包。為了對它進行分類，隻能使用VLAN(IEEE 802.1q)頭部中的PCP(Priority Code Point)域3 Bits來設定優先級值。
5.2.4 RoCEv2（RDMA封裝協定）隊列映射
這個協定是将RDMA資料段先封裝到UDP資料段内，加上UDP頭部，再加上IP頭部，最後再加上以太網頭部，屬于三層資料包。對它進行分類，既可以使用以太網VLAN中的PCP域，也可以使用IP頭部的DSCP域。
在二層網絡的情況下，PFC使用VLAN中的PCP位來對資料流進行區分，在三層網絡的情況下，PFC既可以使用PCP、也可以使用DSCP，使得不同資料流可以享受到獨立的流控制。當下資料中心因多采用三層網絡，是以使用DSCP比PCP更具有優勢。
5.3 PFC存在的問題
5.3.1 死鎖（PFCdeadlock）
PFC死鎖，是指當多個交換機之間因微環路等原因同時出現擁塞,各自端口緩存消耗超過門檻值，而又互相等待對方釋放資源，進而導緻所有交換機上的資料流都永久阻塞的一種網絡狀态。
正常情況下，當一台交換機的端口出現擁塞并觸發XOFF水線時，即下遊裝置将發送PAUSE幀反壓，上遊裝置接收到PAUSE幀後停止發送資料，如果上遊裝置本地端口緩存消耗超過門檻值，則繼續向上遊反壓。如此一級級反壓，直到網絡終端伺服器在PAUSE幀中指定Pause Time内暫停發送資料，進而消除網絡節點因擁塞造成的丢包。
但在特殊情況下，例如發生鍊路故障或裝置故障時，BGP路由重新收斂期間可能會出現短暫環路，會導緻出現一個循環的緩沖區依賴。如下圖所示，當4台交換機都達到XOFF水線，都同時向對端發送PAUSE幀，這個時候該拓撲中所有交換機都處于停流狀态，由于PFC的反壓效應，整個網絡或部分網絡的吞吐量将變為零。
5.3.2 pause幀風暴
由于
PFC pause
是傳遞的，是以很容器引起
pause frame storm
。比如，NIC因為bug導緻接收緩沖區填滿，NIC會一直對外發送
pause frame
。需要在NIC端和交換機端使用
watchdog
機制來防止
pause storm
。
1. 伺服器0的NIC發生故障，不斷向其ToR交換機發送暫停幀;
2. ToR交換機依次暫停所有其餘端口，包括到Leaf交換機的所有上遊端口。
3.葉子交換機暫停脊椎交換機；
4. Spine交換機暫停其餘的Leaf交換機；
5.其餘的葉子交換機暫停其ToR交換機；
6. ToR交換機會暫停連接配接到它們的伺服器
PFC風暴問題的根本原因是NIC的接收管道中存在錯誤。 該錯誤使NIC無法處理收到的資料包。 結果，NIC的接收緩沖區已滿，并且NIC一直一直發出暫停幀。
5.3.3 隊頭阻塞（HOL Blocking/堵塞問題）
如上圖 a)，Flow 1 和 Flow 2 從同一個 Ingress 1 流向不同的 Egress 1 和 2。
圖 b)，Egress 1 觸發了 PFC Pause，Ingress 1 暫停發送。Flow 2 并不需要經過 Egress 1，卻受其影響也被暫停了。
5.3.4 不公平問題
如上圖 a)，交換機上兩個流入端口有資料流向同一個流出端口：Ingress 1 攜帶 Flow 1，Ingress 2 攜帶 Flow 2 和 3。
圖 b) 觸發了 PFC Pause，Ingress 1 和 2 同時暫停發送。
圖 c) Egress 1 隊列空閑，通知 Ingress 1 和 2 恢複發送。
圖 d) 由于 Ingress 1 和 2 是同時暫停和恢複的，Flow 2 和 3 需要競争 Ingress 2，導緻 Flow 1 始終能夠獲得比 Flow 2 或 3 更高的帶寬，出現了不同 Flow 帶寬配置設定不公平。
5.4 利用ECN實作端到端的擁塞控制
目前的RoCE擁塞控制依賴ECN(Explicit Congestion Notification，顯式擁塞通知)來運作。ECN最初在RFC 3168中定義，網絡裝置會在檢測到擁塞時，通過在IP頭部嵌入一個擁塞訓示器和在TCP頭部嵌入一個擁塞确認實作。
RoCEv2标準定義了RoCEv2擁塞管理(RCM)。啟用了ECN之後，網絡裝置一旦檢測到RoCEv2流量出現了擁塞，會在資料包的IP頭部ECN域進行标記。
5.4.1 ECN互動過程
① 發送端發送的IP封包标記支援ECN(10); (ECT=10 or 01，發送端10，接收端01？）
② 交換機在隊列擁塞情況下收到該封包，将ECN字段修改為11并發出，網絡中其他交換機将透傳;
③ 接收端收到ECN為11的封包發現擁塞，正常處理該封包;
④ 接收端産生擁塞通告，每ms級發送一個CNP(Congestion Notification Packets)封包，ECN字段為01，要求封包不能被網絡丢棄。接收端對多個被ECN标記為同一個QP的資料包發送一個單個CNP即可(格式規定見下圖);--（即對同一個QP的資料發送同一個CNP即可）
⑤ 交換機收到CNP封包後正常轉發該封包;
⑥ 發送端收到ECN标記為01的CNP封包解析後對相應的流(對應啟用ECN的QP)應用速率限制算法。
CNP作為擁塞控制封包，也會存在延遲和丢包，從發送端到接收端經過的每一跳裝置、每一條鍊路都會有一定的延遲，會最終加大發送端接收到CNP的時間，而與此同時交換機端口下的擁塞也會逐漸增多，若發送端不能及時降速，仍然可能造成丢包。建議擁塞通告域的規模不要過大，進而避免因為ECN控制封包互動回路的跳數過多，而影響發送端無法及時降速，造成擁塞。
5.4.2 PFC和ECN對比
在 RoCE 網絡中，需要建構無損以太網保證網絡不丢包，建構無損以太網需支援以下關鍵特性：
(必選)PFC(Priority-based Flow Control，基于優先級的流量控制)：逐跳提供基于優先級的流量控制，能夠實作在以太網鍊路上運作多種類型的流量而互不影響。
(必選)ECN(Explicit Congestion Notification，顯示擁塞通知)：裝置發生擁塞時，通過對封包 IP 頭中 ECN 域的辨別，由接收端向發送端發出降低發送速率的 CNP(Congestion Notification Packet，擁塞通知封包)，實作端到端的擁塞管理，減緩擁塞擴散惡化。
(建議)DCBX(Data Center Bridging Exchange Protocol，資料中心橋能力交換協定)：使用 LLDP 自動協商 DCB 能力參數（包括 PFC 和 ETS 等）。一般用在接入交換機連接配接伺服器的端口，與伺服器網卡進行能力協商。
(可選)ETS(Enhanced Transmission Selection，增強傳輸選擇)：将流量按服務類型分組，在提供不同流量的最小帶寬保證的同時提高鍊路使用率，保證重要流量的帶寬百分比。需要逐跳提供。
PFC 點到點逐跳反壓，ECN端到端，向源頭發送暫停通知
從充分發揮網絡高性能轉發的角度，我們一般建議通過調整ECN和PFC的buffer水線，讓ECN快于PFC觸發，即網絡還是持續全速進行資料轉發，讓伺服器主動降低發包速率。如果還不能解決問題，再通過PFC讓上遊交換機暫停封包發送，雖然整網吞吐性能降低，但是不會産生丢包。