摘要

RoCE(RDMA over Converged Ethernet)協(xié)議是一種能在以太網(wǎng)上進行RDMA（遠(yuǎn)程內(nèi)存直接訪問）的集群網(wǎng)絡(luò)通信協(xié)議，它大大降低了以太網(wǎng)通信的延遲，提高了帶寬的利用率，相比傳統(tǒng)的TCP/IP協(xié)議的性能有了很大提升。本文將聊一聊我對于將RoCE應(yīng)用到HPC上這件事的看法。 ?

HPC網(wǎng)絡(luò)的發(fā)展與RoCE的誕生

在早年的高性能計算(HPC)系統(tǒng)中，往往會采用一些定制的網(wǎng)絡(luò)解決方案，例如：Myrinet、Quadrics、InfiniBand，而不是以太網(wǎng)。這些網(wǎng)絡(luò)可以擺脫以太網(wǎng)方案在設(shè)計上的限制，可以提供更高的帶寬、更低的延遲、更好的擁塞控制、以及一些特有的功能。 IBTA在2010年發(fā)布了RoCE(RDMA over Converged Ethernet)協(xié)議技術(shù)標(biāo)準(zhǔn)，隨后又在2014年發(fā)布了RoCEv2協(xié)議技術(shù)標(biāo)準(zhǔn)，同時帶寬上也有大幅提升。以太網(wǎng)性能的大幅提升，使越來越多的人想要選擇能兼容傳統(tǒng)以太網(wǎng)的高性能網(wǎng)絡(luò)解決方案。這也打破了top500上使用以太網(wǎng)的HPC集群數(shù)量越來越少的趨勢，使以太網(wǎng)現(xiàn)在仍然占有top500的半壁江山。 雖然現(xiàn)在Myrinet、Quadrics已經(jīng)消亡，但InfiniBand仍然占據(jù)著高性能網(wǎng)絡(luò)中重要的一席之地，另外Cray自研系列網(wǎng)絡(luò)，天河自研系列網(wǎng)絡(luò)，Tofu D系列網(wǎng)絡(luò)也有著其重要的地位。

RoCE協(xié)議介紹

RoCE協(xié)議是一種能在以太網(wǎng)上進行RDMA（遠(yuǎn)程內(nèi)存直接訪問）的集群網(wǎng)絡(luò)通信協(xié)議。它將收/發(fā)包的工作卸載(offload)到了網(wǎng)卡上，不需要想TCP/IP協(xié)議一樣使系統(tǒng)進入內(nèi)核態(tài)，減少了拷貝、封包解包等等的開銷。這樣大大降低了以太網(wǎng)通信的延遲，減少了通訊時對CPU資源的占用，緩解了網(wǎng)絡(luò)中的擁塞，讓帶寬得到更有效的利用。 RoCE協(xié)議有兩個版本：RoCE v1和RoCE v2。其中RoCE v1是鏈路層協(xié)議，所以使用RoCEv1協(xié)議通信的雙方必須在同一個二層網(wǎng)絡(luò)內(nèi)；而RoCE v2是網(wǎng)絡(luò)層協(xié)議，因此RoCE v2協(xié)議的包可以被三層路由，具有更好的可擴展性。

RoCE v1協(xié)議

RoCE協(xié)議保留了IB與應(yīng)用程序的接口、傳輸層和網(wǎng)絡(luò)層，將IB網(wǎng)的鏈路層和物理層替換為以太網(wǎng)的鏈路層和網(wǎng)絡(luò)層。在RoCE數(shù)據(jù)包鏈路層數(shù)據(jù)幀中，Ethertype字段值被IEEE定義為了0x8915，來表明這是一個RoCE數(shù)據(jù)包。但是由于RoCE協(xié)議沒有繼承以太網(wǎng)的網(wǎng)絡(luò)層，在RoCE數(shù)據(jù)包中并沒有IP字段，因此RoCE數(shù)據(jù)包不能被三層路由，數(shù)據(jù)包的傳輸只能被局限在一個二層網(wǎng)絡(luò)中路由。

RoCEv2協(xié)議

RoCE v2協(xié)議對RoCE協(xié)議進行了一些改進。RoCEv2協(xié)議將RoCE協(xié)議保留的IB網(wǎng)絡(luò)層部分替換為了以太網(wǎng)網(wǎng)絡(luò)層和使用UDP協(xié)議的傳輸層，并且利用以太網(wǎng)網(wǎng)絡(luò)層IP數(shù)據(jù)報中的DSCP和ECN字段實現(xiàn)了擁塞控制的功能。因此RoCE v2協(xié)議的包可以被路由，具有更好的可擴展性。由于RoCE v2協(xié)議現(xiàn)在已經(jīng)全面取代存在缺陷的RoCE協(xié)議，人們在提到RoCE協(xié)議時一般也指的是RoCE v2協(xié)議，故本文中接下來提到的所有RoCE協(xié)議，除非特別聲明為第一代RoCE，均指代RoCE v2協(xié)議。

無損網(wǎng)絡(luò)與RoCE擁塞控制機制

在使用RoCE協(xié)議的網(wǎng)絡(luò)中，必須要實現(xiàn)RoCE流量的無損傳輸。因為在進行RDMA通信時，數(shù)據(jù)包必須無丟包地、按順序地到達(dá)，如果出現(xiàn)丟包或者包亂序到達(dá)的情況，則必須要進行g(shù)o-back-N重傳，并且期望收到的數(shù)據(jù)包后面的數(shù)據(jù)包不會被緩存。 RoCE協(xié)議的擁塞控制共有兩個階段：使用DCQCN(Datacenter Quantized Congestion Notification)進行減速的階段和使用PFC(Priority Flow Control)暫停傳輸?shù)碾A段（雖然嚴(yán)格來說只有前者是擁塞控制策略，后者其實是流量控制策略，但是我習(xí)慣把它們看成擁塞控制的兩個階段，后文中也這會這么寫）。 當(dāng)在網(wǎng)絡(luò)中存在多對一通信的情況時，這時網(wǎng)絡(luò)中往往就會出現(xiàn)擁塞，其具體表現(xiàn)是交換機某一個端口的待發(fā)送緩沖區(qū)消息的總大小迅速增長。如果情況得不到控制，將會導(dǎo)致緩沖區(qū)被填滿，從而導(dǎo)致丟包。因此，在第一個階段，當(dāng)交換機檢測到某個端口的待發(fā)送緩沖區(qū)消息的總大小達(dá)到一定的閾值時，就會將RoCE數(shù)據(jù)包中IP層的ECN字段進行標(biāo)記。當(dāng)接收方接收到這個數(shù)據(jù)包，發(fā)現(xiàn)ECN字段已經(jīng)被交換機標(biāo)記了，就會返回一個CNP(Congestion Notification Packet)包給發(fā)送方，提醒發(fā)送方降低發(fā)送速度。需要特別注意的是，對于ECN字段的標(biāo)記并不是達(dá)到一個閾值就全部標(biāo)記，而是存在兩個Kmin和Kmax，如圖2所示，當(dāng)擁塞隊列長度小于Kmin時，不進行標(biāo)記。當(dāng)隊列長度位于Kmin和Kmax之間時，隊列越長，標(biāo)記概率越大。當(dāng)隊列長度大于Kmax時，則全部標(biāo)記。而接收方不會每收到一個ECN包就返回一個CNP包，而是在每一個時間間隔內(nèi)，如果收到了帶有ECN標(biāo)記的數(shù)據(jù)包，就會返回一個CNP包。這樣，發(fā)送方就可以根據(jù)收到的CNP包的數(shù)量來調(diào)節(jié)自己的發(fā)送速度。 當(dāng)網(wǎng)絡(luò)中的擁塞情況進一步惡化時，交換機檢測到某個端口的待發(fā)送隊列長度達(dá)到一個更高的閾值時，交換機將向消息來源的上一跳發(fā)送PFC的暫?？刂茙股嫌畏?wù)器或者交換機暫停向其發(fā)送數(shù)據(jù)，直到交換機中的擁塞得到緩解的時候，向上游發(fā)送一個PFC控制幀來通知上有繼續(xù)發(fā)送。由于PFC的流量控制是支持按不同的流量通道進行暫停的，因此，當(dāng)設(shè)置好了每個流量通道帶寬占總帶寬的比例，可以一個流量通道上的流量傳輸暫停，并不影響其他流量通道上的數(shù)據(jù)傳輸。 值得一提的是，并不是每一款聲稱支持RoCE的交換機都完美的實現(xiàn)了擁塞控制的功能。在我的測試中，發(fā)現(xiàn)了某品牌的某款交換機的在產(chǎn)生擁塞時，對來自不同端口但注入速度相同的流量進行ECN標(biāo)記時概率不同，導(dǎo)致了負(fù)載不均衡的問題。

RoCE和Soft-RoCE

雖然現(xiàn)在大部分的高性能以太網(wǎng)卡都能支持RoCE協(xié)議，但是仍然有一些網(wǎng)卡不支持RoCE協(xié)議。因此IBM、Mellanox等聯(lián)手創(chuàng)建了開源的Soft-RoCE項目。這樣，在安裝了不支持RoCE協(xié)議的網(wǎng)卡的節(jié)點上，仍然可以選擇使用Soft-RoCE，使其具備了能與安裝了支持RoCE協(xié)議的網(wǎng)卡的節(jié)點使用RoCE協(xié)議進行通信的能力，如圖3所示。雖然這并不會給前者帶來性能提升，但是讓后者能夠充分發(fā)揮其性能。在一些場景下，比如：數(shù)據(jù)中心，可以只將其高IO存儲服務(wù)器升級為支持RoCE協(xié)議的以太網(wǎng)卡，以提高整體性能和可擴展性。同時這種RoCE和Soft-RoCE結(jié)合的方法也可以滿足集群逐步升級的需求，而不用一次性全部升級。

將RoCE應(yīng)用到HPC上存在的問題

HPC網(wǎng)絡(luò)的核心需求

我認(rèn)為HPC網(wǎng)絡(luò)的核心需求有兩個：①低延遲；②在迅速變化的流量模式下仍然能保持低延遲。 對于①低延遲，RoCE就是用來解決這個問題的。如前面提到的，RoCE通過將網(wǎng)絡(luò)操作卸載到網(wǎng)卡上，實現(xiàn)了低延遲，也減少了CPU的占用。 對于②在迅速變化的流量模式下仍然能保持低延遲，其實就是擁塞控制的問題。但是關(guān)鍵在于HPC的流量模式是迅速變化的，而RoCE在這個問題上表現(xiàn)是欠佳的。

RoCE的低延遲

實機測試

RoCE的延遲有幸有機會與IB實測對比了一下：以太網(wǎng)用的是25G Mellanox ConnectX-4 Lx 以太網(wǎng)卡，和Mellanox SN2410交換機；IB用的是100G InfiniBand EDR網(wǎng)卡(Mellanox ConnectX-4)，和Mellanox CS7520。測試中以太網(wǎng)交換機擺位于機架頂部，IB交換機擺在比較遠(yuǎn)的機柜，因而IB的會因為線纜的實際長度較長而有一點劣勢。測試使用OSU Micro-Benchmarks中的osu_latency對IB、RoCE、TCP協(xié)議進行延遲測試，結(jié)果如下。 雖然IB用的是100G的，RoCE用的是25G的，但是這里我們關(guān)注的是延遲，應(yīng)該沒有關(guān)系。 可以看出，雖然RoCE協(xié)議的確能大幅降低通信延遲，比TCP快了5倍左右，但仍然比IB慢了47%-63%。

官方紙面數(shù)據(jù)

上面用到的以太網(wǎng)交換機SN2410的官方延遲數(shù)據(jù)是300ns，雖然IB交換機CS7520沒找到官方延遲數(shù)據(jù)，不過找到了同為EDR交換機的SB7800的官方數(shù)據(jù)，延遲為90ns。 不過上面這些是有些舊的前兩年的設(shè)備了，新一點的Mellanox以太網(wǎng)交換機SN3000系列的200G以太網(wǎng)交換機官方延遲數(shù)據(jù)是425ns，更新的Mellanox SN4000系列400G以太網(wǎng)交換機，在官方文檔沒有找到延遲數(shù)據(jù)。新一點的Mellanox IB交換機QM8700系列HDR交換機的官方延遲數(shù)據(jù)是130ns，最新的QM9700系列NDR交換機，在官方文檔中也沒有找到延遲數(shù)據(jù)。（不知道為啥都是新一代的比舊的延遲還大一點，而且最新一代的延遲都沒放出來） 定制網(wǎng)絡(luò)的Cray XC系列Aries交換機延遲大約是100ns，天河-2A的交換機延遲也大約是100ns。 可見在交換機實現(xiàn)上，以太網(wǎng)交換機與IB交換機以及一些定制的超算網(wǎng)絡(luò)的延遲性能還是有一定差距的。

RoCE的包結(jié)構(gòu)

假設(shè)我們要使用RoCE發(fā)送1 byte的數(shù)據(jù)，這時為了封裝這1 byte的數(shù)據(jù)包要額外付出的代價如下：

以太網(wǎng)鏈路層：14 bytes MAC header + 4 bytes CRC

以太網(wǎng)IP層：20 bytes

以太網(wǎng)UDP層：8 bytes

IB傳輸層：12 bytes Base Transport Header (BTH)

總計：58 bytes 假設(shè)我們要使用IB發(fā)送1 byte的數(shù)據(jù)，這時為了封裝這1 byte的數(shù)據(jù)包要額外付出的代價如下：

IB鏈路層：8 bytes Local Routing Header(LHR) + 6 byte CRC

IB網(wǎng)絡(luò)層：0 bytes 當(dāng)只有二層網(wǎng)絡(luò)時， 鏈路層Link Next Header (LNH)字段可以指示該包沒有網(wǎng)絡(luò)層

IB傳輸層：12 bytes Base Transport Header (BTH)

總計：26 bytes 如果是定制的網(wǎng)絡(luò)，數(shù)據(jù)包的結(jié)構(gòu)可以做到更簡單，比如天河-1A的Mini-packet (MP)的包頭是有8 bytes。 由此可見，以太網(wǎng)繁重的底層結(jié)構(gòu)也是將RoCE應(yīng)用到HPC的一個阻礙之一。 數(shù)據(jù)中心的以太網(wǎng)交換機往往還要具備許多其他功能，還要付出許多成本來進行實現(xiàn)，比如SDN、QoS等等，這一塊我也不是很懂。 對于這個以太網(wǎng)的這些features，我挺想知道：以太網(wǎng)針這些功能與RoCE兼容嗎，這些功能會對RoCE的性能產(chǎn)生影響嗎？

RoCE擁塞控制存在的問題

RoCE協(xié)議的兩段擁塞控制都存在一定的問題，可能難以在迅速變化的流量模式下仍然能保持低延遲。 采用PFC(Priority Flow Control)采用的是暫?？刂茙瑏矸乐菇邮盏竭^多的數(shù)據(jù)包從而引起丟包。這種方法比起credit-based的方法，buffer的利用率難免要低一些。由其對于一些延遲較低的交換機，buffer會相對較少，此時用PFC(Priority Flow Control)就不好控制；而如果用credit-base則可以實現(xiàn)更加精確的管理。 DCQCN與IB的擁塞控制相比，其實大同小異，都是backward notification：通過通過先要將擁塞信息發(fā)送到目的地，然后再將擁塞信息返回到發(fā)送方，再進行限速。但是在細(xì)節(jié)上略有不同：RoCE的降速與提速策略根據(jù)論文Congestion Control for Large-Scale RDMA Deployments，是固定死的一套公式；而IB中的可以自定義提速與降速策略；雖然大部分人應(yīng)該實際上應(yīng)該都用的是默認(rèn)配置，但是有自由度總好過沒有叭。還有一點是，在這篇論文中測試的是每N=50us最多產(chǎn)生一個CNP包，不知道如果這個值改小行不行；而IB中想對應(yīng)的CCTI_Timer最小可以為1.024us，也不知道實際能不能設(shè)置這么小。 最好的方法當(dāng)然還是直接從擁塞處直接返回?fù)砣畔⒔o源，即Forward notification。以太網(wǎng)受限于規(guī)范不這么干可以理解，但是IB為啥不這么干呢？

RoCE在HPC上的應(yīng)用案例

Slingshot

美國的新三大超算都準(zhǔn)備用Slingshot網(wǎng)絡(luò)，這是一個改進的以太網(wǎng)，其中的Rosetta交換機兼容傳統(tǒng)的以太網(wǎng)同時還對RoCE的一些不足進行了改進，如果一條鏈路的兩端都是支持的設(shè)備（專用網(wǎng)卡、Rosetta交換機）就可以開啟一些增強功能：

將IP數(shù)據(jù)包最小幀大小減小到32 bytes

相鄰交換機的排隊占用情況(credit)會傳播給相鄰的交換機

更加nb的擁塞控制，但是具體怎么實現(xiàn)的論文里沒細(xì)說

最后達(dá)到的效果是交換機平均延遲是350ns，達(dá)到了較強的以太網(wǎng)交換機的水平，但是還沒沒有IB以及一些定制超算交換機延遲低，也沒有前一代的Cray XC超算交換機延遲低。 但是在實際應(yīng)用的表現(xiàn)似乎還行，但是論文An In-Depth Analysis of the Slingshot Interconnect中似乎只是和前一代的Cray超算比，沒有和IB比。

CESM與GROMACS測試

我也用前面測試延遲的25G以太網(wǎng)和100G測了CESM與GROMACS來對比了應(yīng)用的性能。雖然兩者之間帶寬差了4倍，但是也有一點點參考價值。 GROMACS測試結(jié)果

一些期待

如果能有人將100G或者200G的IB和以太網(wǎng)組一個大規(guī)模集群來對比兩者之間的性能差距，其實就能說明很多問題，但是成本實在太高，到目前為止還沒發(fā)現(xiàn)有哪里做了這樣的實驗。

總結(jié)與結(jié)論

將RoCE應(yīng)用到HPC中有我覺得如下問題：

以太網(wǎng)交換機的延遲相比于IB交換機以及一些HPC定制網(wǎng)絡(luò)的交換機要高一些

RoCE的流量控制、擁塞控制策略還有一些改進的空間

以太網(wǎng)交換機的成本還是要高一些

但是從實測性能上來看，在小規(guī)模情況下，性能不會有什么問題。但是在大規(guī)模情況下，也沒人測過，所以也不知道。雖然Slingshot的新超算即將出來了，但是畢竟是魔改過的，嚴(yán)格來說感覺也不能算是以太網(wǎng)。但是從他們魔改這件事情來看，看來他們也覺得直接應(yīng)用RoCE有問題，要魔改了才能用。

參考資料

https://en.wikipedia.org/wiki/Myrinet https://en.wikipedia.org/wiki/Quadrics_(company) https://www.nextplatform.com/2021/07/07/the-eternal-battle-between-infiniband-and-ethernet-in-hpc/ On the Use of Commodity Ethernet Technology in Exascale HPC Systems https://network.nvidia.com/pdf/prod_eth_switches/PB_SN2410.pdf Infiniband Architecture Specification1.2.1 Tianhe-1A Interconnect and Message-Passing Services https://fasionchan.com/network/ethernet/ Congestion Control for Large-Scale RDMA Deployments An In-Depth Analysis of the Slingshot Interconnect ? ?

編輯：黃飛

?