如果我們的預(yù)期是將網(wǎng)絡(luò)延時(shí)從10ms 降低到1ms，那么應(yīng)該先分析這些時(shí)延的具體構(gòu)成，很有可能瓶頸并不是網(wǎng)絡(luò)傳輸；如果目標(biāo)是將網(wǎng)絡(luò)延時(shí)降低到微秒級(jí)或者百微秒級(jí)，那么我們才可能使用到高性能網(wǎng)絡(luò)，例如RDMA技術(shù)。

1. TCP/IP 協(xié)議棧的局限

數(shù)據(jù)中心內(nèi)部服務(wù)器的接入帶正在由萬兆（10G）接入升級(jí)為25G，在某些用于機(jī)器學(xué)習(xí)的服務(wù)器上甚至使用了100G的接入帶寬。量變引起質(zhì)變，增大的接入帶寬讓傳統(tǒng)的TCP/IP協(xié)議棧遇到了嚴(yán)重的性能挑戰(zhàn)。

在當(dāng)前的操作系統(tǒng)中，使用TCP傳輸數(shù)據(jù)，需要大量的CPU參與，包括報(bào)文的封裝解析和流控處理等。一個(gè)TCP報(bào)文均由一個(gè)CPU核處理，單個(gè)TCP流的最大吞吐受制于CPU單核的處理能力。無奈的是，CPU單核計(jì)算能力幾乎不能再提升了，這導(dǎo)致采用TCP/IP協(xié)議棧的數(shù)據(jù)傳輸一定會(huì)遇到吞吐量瓶頸。如果想充分地利用100G的帶寬，就必須使用多個(gè)流的并行傳輸。這一方面增加了應(yīng)用程序的復(fù)雜度，另一方面也意味著不得不將更多昂貴的計(jì)算資源投入到網(wǎng)絡(luò)傳輸?shù)念I(lǐng)域中去。

除了帶寬以外，時(shí)延同樣是使用傳統(tǒng)TCP/IP協(xié)議棧的一個(gè)主要痛點(diǎn)。一個(gè)應(yīng)用程序要發(fā)送數(shù)據(jù)，必須先通過socket API，數(shù)據(jù)從用戶態(tài)進(jìn)入到內(nèi)核態(tài)，經(jīng)過內(nèi)核的報(bào)文處理后，再交給網(wǎng)絡(luò)協(xié)議棧發(fā)送出去。類似地，在接收端，內(nèi)核先收到報(bào)文，進(jìn)行處理后提取出數(shù)據(jù)，等待用戶態(tài)的處理。這中間需要經(jīng)過操作系統(tǒng)在內(nèi)核態(tài)/用戶態(tài)轉(zhuǎn)化，要經(jīng)過CPU的報(bào)文處理，也還要依賴操作系統(tǒng)的中斷。因此，在小數(shù)據(jù)量的傳輸時(shí)延中，主要延時(shí)并非是在物理網(wǎng)絡(luò)上的傳輸時(shí)延，而是在發(fā)送/接收軟件協(xié)議棧中的處理時(shí)延。

2. 高性能IB網(wǎng)絡(luò)

在高性能計(jì)算集群中，網(wǎng)絡(luò)協(xié)議一般不是Ethernet+TCP/IP，而是Infiniband（IB）協(xié)議，是從物理層到傳輸層的一整套協(xié)議棧。Infiniband的物理接口與以太網(wǎng)接口是完全不同的，是一套完全不同于一般數(shù)據(jù)中心中以太網(wǎng)架構(gòu)的網(wǎng)絡(luò)。

Infiniband是完全基于集中控制的一種網(wǎng)絡(luò)設(shè)計(jì)，簡化了交換設(shè)備的復(fù)雜度，有助于降低轉(zhuǎn)發(fā)時(shí)延，但這也就導(dǎo)致了IB網(wǎng)絡(luò)的擴(kuò)展性不如以太網(wǎng)。作為超級(jí)計(jì)算機(jī)思想的自然延伸，Infiniband對(duì)上層表現(xiàn)為一條計(jì)算機(jī)內(nèi)的總線，并不采用Best Effort的轉(zhuǎn)發(fā)策略，而采用了避免丟包的lossless設(shè)計(jì)，并且上層編程接口開放了直接針對(duì)遠(yuǎn)程內(nèi)存的Read/Write。

Infiniband的傳輸層協(xié)議是RDMA，即Remote Direct Memory Access，利用了底層網(wǎng)絡(luò)lossless的特性，并向上層應(yīng)用程序提供一種稱為verbs API的編程接口。RDMA從設(shè)計(jì)之初就是讓硬件網(wǎng)卡ASIC來執(zhí)行網(wǎng)絡(luò)傳輸相關(guān)操作的。

第一個(gè)Infiniband的標(biāo)準(zhǔn)成形于2000年，自產(chǎn)生以來在HPC領(lǐng)域得到了大量的使用。直到2010年，首個(gè)RDMA over Converged Ethernet（RoCE）標(biāo)準(zhǔn)形成，宣告IB網(wǎng)絡(luò)的傳輸層協(xié)議RDMA可以以覆蓋網(wǎng)絡(luò)的形式運(yùn)行于以太網(wǎng)之上，RoCE的性能相比Infiniband還是要差一些的。自此，IB網(wǎng)絡(luò)和以太網(wǎng)正式發(fā)生交疊，RDMA技術(shù)開始進(jìn)入一般數(shù)據(jù)中心，為即將到來的AI計(jì)算和云計(jì)算的爆發(fā)式增長提供了關(guān)鍵支持。

3. RDMA的特性

當(dāng)我們使用RDMA的時(shí)候，應(yīng)用程序的實(shí)際數(shù)據(jù)發(fā)送根本不用經(jīng)過內(nèi)核處理，也不用拷貝，而是由RDMA網(wǎng)卡直接從用戶態(tài)內(nèi)存中DMA到網(wǎng)卡上，然后在網(wǎng)卡硬件上進(jìn)行封裝等處理，而接收端也是從網(wǎng)卡上解封裝處理后，直接把數(shù)據(jù)DMA給用戶態(tài)內(nèi)存。這就是RDMA技術(shù)中kernel bypass和zero copy兩個(gè)特性的真正涵義。

正是因?yàn)閗ernel bypass和zero copy，RDMA獲得了三個(gè)關(guān)鍵的衍生特性：低時(shí)延、高帶寬和低CPU消耗。這三個(gè)衍生特性往往作為RDMA相對(duì)于TCP/IP協(xié)議棧的主要優(yōu)勢被提出。需要特別注意的是，kernel bypass和zero copy都需要網(wǎng)卡的硬件支持，這意味著若想用RDMA，就必須要擁有支持RDMA技術(shù)的網(wǎng)卡。

上圖中RDMA的左邊經(jīng)過libibverbs的部分一般稱為Command Channel，是應(yīng)用程序調(diào)用verbs API時(shí)的命令通道，并不是真正的數(shù)據(jù)通道。

3.1 RDMA的verbs API

應(yīng)用程序使用RDMA用的是verbs API，而不是socket API。RDMA有三種隊(duì)列：Send Queue(SQ)、Recv Queue(RQ)和Completion Queue(CQ)。SQ和RQ往往成對(duì)出現(xiàn)，合起來稱為Queue Pair。SQ是發(fā)送請(qǐng)求隊(duì)列，RQ就是接收請(qǐng)求隊(duì)列，CQ就是發(fā)送請(qǐng)求和接收請(qǐng)求完成情況的隊(duì)列。

當(dāng)一個(gè)應(yīng)用程序需要發(fā)送數(shù)據(jù)的時(shí)候，會(huì)向SQ里提交一個(gè)發(fā)送請(qǐng)求（API：ibvpostsend），這個(gè)請(qǐng)求并不包含數(shù)據(jù)本身，只包含指向數(shù)據(jù)的指針以及數(shù)據(jù)的長度，提交操作是通過API實(shí)現(xiàn)的。這個(gè)請(qǐng)求會(huì)傳遞到網(wǎng)卡，由網(wǎng)卡自己按照地址和長度把要發(fā)送的數(shù)據(jù)取出，然后發(fā)送到網(wǎng)絡(luò)。發(fā)送完成后，會(huì)在CQ中生成一個(gè)發(fā)送完成的說明。在接收端，應(yīng)用程序必須事先提交一個(gè)接收請(qǐng)求到RQ（API：ibvpostrecv），這個(gè)接收請(qǐng)求里包含了接收數(shù)據(jù)要存放的內(nèi)存指針以及可以接收的最大數(shù)據(jù)長度。當(dāng)數(shù)據(jù)到來的時(shí)候，網(wǎng)卡會(huì)將數(shù)據(jù)放在RQ隊(duì)列頭中的接收請(qǐng)求所指明的內(nèi)存位置，然后在CQ中生成一個(gè)接收完成的說明。verbs API的發(fā)送與接收都是異步非阻塞的調(diào)用，應(yīng)用程序需要檢查CQ中來判斷一個(gè)請(qǐng)求的完成情況，QP可以視為類似socket。

其實(shí)在RDMA中，除了Send/Recv以外，還有RDMA Write/Read的特別請(qǐng)求，可以直接實(shí)現(xiàn)對(duì)遠(yuǎn)端應(yīng)用程序虛擬內(nèi)存的訪問。RDMA Write/Read請(qǐng)求也是向發(fā)起端SQ提交的），但與Send/Recv不同的是，另一端并不需要事先向RQ提交接收請(qǐng)求。這種單邊的RDMA傳輸方式會(huì)比Send/Recv有更好的性能，不過必須事先知道數(shù)據(jù)在對(duì)端的確切地址。

3.2 RDMA 的無丟包實(shí)現(xiàn)

丟包本身就是網(wǎng)絡(luò)傳輸?shù)男阅軞⑹?，而且為了從丟包中快速恢復(fù)，需要引入復(fù)雜的、難以用硬件實(shí)現(xiàn)的處理邏輯。以太網(wǎng)可以利用pause機(jī)制變成無丟包的，無丟包機(jī)制的實(shí)現(xiàn)對(duì)RDMA是至關(guān)重要的，在RoCE中啟用pause機(jī)制的時(shí)候，為了盡可能限制pause的副作用，可以在網(wǎng)絡(luò)中分出不同的優(yōu)先級(jí)隊(duì)列，僅僅在特定的優(yōu)先級(jí)隊(duì)列上開啟pause，這就是以太網(wǎng)的優(yōu)先級(jí)流控（PFC）機(jī)制，已經(jīng)作為DCB標(biāo)準(zhǔn)的一部分?，F(xiàn)在多數(shù)的數(shù)據(jù)中心交換機(jī)都已經(jīng)支持PFC。在PFC配置生效的情況下，RDMA流量跑在開啟了pause的優(yōu)先級(jí)下，而讓TCP的流量跑在沒有開啟pause的優(yōu)先級(jí)下來盡可能限制pause機(jī)制所帶來的副作用。

RDMA可以在特殊設(shè)計(jì)下放棄PFC配置，但這樣的設(shè)備還沒有真正誕生，依然要假定RDMA需要無丟包的底層網(wǎng)絡(luò)，RDMA的正常使用高度依賴于網(wǎng)絡(luò)內(nèi)交換設(shè)備以及網(wǎng)卡的正確配置。

3.3 RDMA的相關(guān)技術(shù)

RDMAcm，全稱為RDMA communication manager，是對(duì)verbs API的一個(gè)封裝調(diào)用庫。RDMAcm的API近似于socket API，如rdmaconnect，rdmalisten，rdma_accept等，只是作為部分verbs API的一個(gè)簡化使用方案而已。rsocket是包含在librdmacm中的一個(gè)工具，可以把RDMA使用封裝為socket接口，替代系統(tǒng)默認(rèn)的socket，從而使得應(yīng)用程序在不修改代碼的情況下使用RDMA。

DPDK源自Intel的網(wǎng)卡kernel bypass技術(shù)，在數(shù)據(jù)中心中得到了廣泛的應(yīng)用。DPDK和RDMA沒有直接關(guān)系，但都可以kernel bypass，不免有時(shí)會(huì)拿來對(duì)比。DPDK相比RDMA，主要有兩個(gè)不同：一是DPDK必須輪詢，會(huì)消耗CPU資源；二是DPDK仍需要由用戶態(tài)做報(bào)文處理，這部分的時(shí)延和開銷并沒有降低。然而，DPDK有一個(gè)優(yōu)勢，即其不需要通信對(duì)端也做同樣的支持，RDMA和DPDK各有屬于自己的應(yīng)用場景。

3.4 RDMA 的典型應(yīng)用場景

RDMA當(dāng)前最主要的應(yīng)用場景有兩類：一是高性能計(jì)算，包括分布式機(jī)器學(xué)習(xí)訓(xùn)練（尤其是使用GPU的時(shí)候）；二是計(jì)算存儲(chǔ)分離。前者主要關(guān)注高帶寬，例如tensorflow、paddlepaddle等。后者主要關(guān)注低時(shí)延，代表性案例有nvmf、smb direct等。另外，RDMA在大數(shù)據(jù)處理（如spark）和虛擬化（如虛機(jī)遷移）等場景中也有應(yīng)用，更多的使用場景仍在探索之中。

4 小結(jié)

對(duì)于高性能網(wǎng)絡(luò)而言，通過kernel bypass和zero copy，RDMA實(shí)現(xiàn)了網(wǎng)絡(luò)傳輸?shù)牡蜁r(shí)延、高帶寬與低CPU消耗。一般地，應(yīng)用程序需要通過特殊的API來使用RDMA，而RDMA則需要底層網(wǎng)絡(luò)具備無丟包配置，其主要應(yīng)用場景包括了高性能計(jì)算以及計(jì)算存儲(chǔ)分離。