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

在早年的高性能計(jì)算(HPC)系統(tǒng)中，往往會采用一些定制的網(wǎng)絡(luò)解決方案，例如：Myrinet、Quadrics、InfiniBand，而不是以太網(wǎng)。這些網(wǎng)絡(luò)可以擺脫以太網(wǎng)方案在設(shè)計(jì)上的限制，可以提供更高的帶寬、更低的延遲、更好的擁塞控制、以及一些特有的功能。

IBTA在2010年發(fā)布了RoCE(RDMA over Converged Ethernet)協(xié)議技術(shù)標(biāo)準(zhǔn)，隨后又在2014年發(fā)布了RoCEv2協(xié)議技術(shù)標(biāo)準(zhǔn)，同時(shí)帶寬上也有大幅提升。以太網(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)消亡，但I(xiàn)nfiniBand仍然占據(jù)著高性能網(wǎng)絡(luò)中重要的一席之地，另外Cray自研系列網(wǎng)絡(luò)，天河自研系列網(wǎng)絡(luò)，Tofu D系列網(wǎng)絡(luò)也有著其重要的地位。

(資料圖片)

RoCE協(xié)議介紹

RoCE協(xié)議是一種能在以太網(wǎng)上進(jìn)行RDMA（遠(yuǎn)程內(nèi)存直接訪問）的集群網(wǎng)絡(luò)通信協(xié)議。它將收/發(fā)包的工作卸載(offload)到了網(wǎng)卡上，不需要像TCP/IP協(xié)議一樣使系統(tǒng)進(jìn)入內(nèi)核態(tài)，減少了拷貝、封包解包等等的開銷。這樣大大降低了以太網(wǎng)通信的延遲，減少了通訊時(shí)對CPU資源的占用，緩解了網(wǎng)絡(luò)中的擁塞，讓帶寬得到更有效的利用。

RoCE協(xié)議有兩個(gè)版本：RoCE v1和RoCE v2。其中RoCE v1是鏈路層協(xié)議，所以使用RoCEv1協(xié)議通信的雙方必須在同一個(gè)二層網(wǎng)絡(luò)內(nèi)；而RoCE v2是網(wǎng)絡(luò)層協(xié)議，因此RoCE v2協(xié)議的包可以被三層路由，具有更好的可擴(kuò)展性。

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，來表明這是一個(gè)RoCE數(shù)據(jù)包。但是由于RoCE協(xié)議沒有繼承以太網(wǎng)的網(wǎng)絡(luò)層，在RoCE數(shù)據(jù)包中并沒有IP字段，因此RoCE數(shù)據(jù)包不能被三層路由，數(shù)據(jù)包的傳輸只能被局限在一個(gè)二層網(wǎng)絡(luò)中路由。

RoCEv2協(xié)議

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

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

在使用RoCE協(xié)議的網(wǎng)絡(luò)中，必須要實(shí)現(xiàn)RoCE流量的無損傳輸。因?yàn)樵谶M(jìn)行RDMA通信時(shí)，數(shù)據(jù)包必須無丟包地、按順序地到達(dá)，如果出現(xiàn)丟包或者包亂序到達(dá)的情況，則必須要進(jìn)行g(shù)o-back-N重傳，并且期望收到的數(shù)據(jù)包后面的數(shù)據(jù)包不會被緩存。

RoCE協(xié)議的擁塞控制共有兩個(gè)階段：使用DCQCN(Datacenter Quantized Congestion Notification)進(jìn)行減速的階段和使用PFC(Priority Flow Control)暫停傳輸?shù)碾A段（雖然嚴(yán)格來說只有前者是擁塞控制策略，后者其實(shí)是流量控制策略，但是我習(xí)慣把它們看成擁塞控制的兩個(gè)階段，后文中也這會這么寫）。

當(dāng)在網(wǎng)絡(luò)中存在多對一通信的情況時(shí)，這時(shí)網(wǎng)絡(luò)中往往就會出現(xiàn)擁塞，其具體表現(xiàn)是交換機(jī)某一個(gè)端口的待發(fā)送緩沖區(qū)消息的總大小迅速增長。如果情況得不到控制，將會導(dǎo)致緩沖區(qū)被填滿，從而導(dǎo)致丟包。因此，在第一個(gè)階段，當(dāng)交換機(jī)檢測到某個(gè)端口的待發(fā)送緩沖區(qū)消息的總大小達(dá)到一定的閾值時(shí)，就會將RoCE數(shù)據(jù)包中IP層的ECN字段進(jìn)行標(biāo)記。當(dāng)接收方接收到這個(gè)數(shù)據(jù)包，發(fā)現(xiàn)ECN字段已經(jīng)被交換機(jī)標(biāo)記了，就會返回一個(gè)CNP(Congestion Notification Packet)包給發(fā)送方，提醒發(fā)送方降低發(fā)送速度。

需要特別注意的是，對于ECN字段的標(biāo)記并不是達(dá)到一個(gè)閾值就全部標(biāo)記，而是存在兩個(gè)Kmin和Kmax，如圖2所示，當(dāng)擁塞隊(duì)列長度小于Kmin時(shí)，不進(jìn)行標(biāo)記。當(dāng)隊(duì)列長度位于Kmin和Kmax之間時(shí)，隊(duì)列越長，標(biāo)記概率越大。當(dāng)隊(duì)列長度大于Kmax時(shí)，則全部標(biāo)記。而接收方不會每收到一個(gè)ECN包就返回一個(gè)CNP包，而是在每一個(gè)時(shí)間間隔內(nèi)，如果收到了帶有ECN標(biāo)記的數(shù)據(jù)包，就會返回一個(gè)CNP包。這樣，發(fā)送方就可以根據(jù)收到的CNP包的數(shù)量來調(diào)節(jié)自己的發(fā)送速度。

當(dāng)網(wǎng)絡(luò)中的擁塞情況進(jìn)一步惡化時(shí)，交換機(jī)檢測到某個(gè)端口的待發(fā)送隊(duì)列長度達(dá)到一個(gè)更高的閾值時(shí)，交換機(jī)將向消息來源的上一跳發(fā)送PFC的暫停控制幀，使上游服務(wù)器或者交換機(jī)暫停向其發(fā)送數(shù)據(jù)，直到交換機(jī)中的擁塞得到緩解的時(shí)候，向上游發(fā)送一個(gè)PFC控制幀來通知上有繼續(xù)發(fā)送。由于PFC的流量控制是支持按不同的流量通道進(jìn)行暫停的，因此，當(dāng)設(shè)置好了每個(gè)流量通道帶寬占總帶寬的比例，可以一個(gè)流量通道上的流量傳輸暫停，并不影響其他流量通道上的數(shù)據(jù)傳輸。

值得一提的是，并不是每一款聲稱支持RoCE的交換機(jī)都完美的實(shí)現(xiàn)了擁塞控制的功能。在我的測試中，發(fā)現(xiàn)了某品牌的某款交換機(jī)的在產(chǎn)生擁塞時(shí)，對來自不同端口但注入速度相同的流量進(jìn)行ECN標(biāo)記時(shí)概率不同，導(dǎo)致了負(fù)載不均衡的問題。

RoCE和Soft-RoCE

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

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

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

我認(rèn)為HPC網(wǎng)絡(luò)的核心需求有兩個(gè)：①低延遲；②在迅速變化的流量模式下仍然能保持低延遲。

對于①低延遲，RoCE就是用來解決這個(gè)問題的。如前面提到的，RoCE通過將網(wǎng)絡(luò)操作卸載到網(wǎng)卡上，實(shí)現(xiàn)了低延遲，也減少了CPU的占用。

對于②在迅速變化的流量模式下仍然能保持低延遲，其實(shí)就是擁塞控制的問題。但是關(guān)鍵在于HPC的流量模式是迅速變化的，而RoCE在這個(gè)問題上表現(xiàn)是欠佳的。

RoCE的低延遲

實(shí)機(jī)測試

RoCE的延遲有幸有機(jī)會與IB實(shí)測對比了一下：以太網(wǎng)用的是25G Mellanox ConnectX-4 Lx 以太網(wǎng)卡，和Mellanox SN2410交換機(jī)；IB用的是100G InfiniBand EDR網(wǎng)卡(Mellanox ConnectX-4)，和Mellanox CS7520。測試中以太網(wǎng)交換機(jī)擺位于機(jī)架頂部，IB交換機(jī)擺在比較遠(yuǎn)的機(jī)柜，因而IB的會因?yàn)榫€纜的實(shí)際長度較長而有一點(diǎn)劣勢。測試使用OSU Micro-Benchmarks中的osu_latency對IB、RoCE、TCP協(xié)議進(jìn)行延遲測試，結(jié)果如下。

雖然IB用的是100G的，RoCE用的是25G的，但是這里我們關(guān)注的是延遲，應(yīng)該沒有關(guān)系。

可以看出，雖然RoCE協(xié)議的確能大幅降低通信延遲，比TCP快了5倍左右，但仍然比IB慢了47%-63%。

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

上面用到的以太網(wǎng)交換機(jī)SN2410的官方延遲數(shù)據(jù)是300ns，雖然IB交換機(jī)CS7520沒找到官方延遲數(shù)據(jù)，不過找到了同為EDR交換機(jī)的SB7800的官方數(shù)據(jù)，延遲為90ns。

不過上面這些是有些舊的前兩年的設(shè)備了，新一點(diǎn)的Mellanox以太網(wǎng)交換機(jī)SN3000系列的200G以太網(wǎng)交換機(jī)官方延遲數(shù)據(jù)是425ns，更新的Mellanox SN4000系列400G以太網(wǎng)交換機(jī)，在官方文檔沒有找到延遲數(shù)據(jù)。新一點(diǎn)的Mellanox IB交換機(jī)QM8700系列HDR交換機(jī)的官方延遲數(shù)據(jù)是130ns，最新的QM9700系列NDR交換機(jī)，在官方文檔中也沒有找到延遲數(shù)據(jù)。（不知道為啥都是新一代的比舊的延遲還大一點(diǎn)，而且最新一代的延遲都沒放出來）

定制網(wǎng)絡(luò)的Cray XC系列Aries交換機(jī)延遲大約是100ns，天河-2A的交換機(jī)延遲也大約是100ns。

可見在交換機(jī)實(shí)現(xiàn)上，以太網(wǎng)交換機(jī)與IB交換機(jī)以及一些定制的超算網(wǎng)絡(luò)的延遲性能還是有一定差距的。

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

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

以太網(wǎng)鏈路層：14 bytes MAC header + 4 bytes CRC以太網(wǎng)IP層：20 bytes以太網(wǎng)UDP層：8 bytesIB傳輸層：12 bytes Base Transport Header (BTH)

總計(jì)：58 bytes

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

IB鏈路層：8 bytes Local Routing Header(LHR) + 6 byte CRCIB網(wǎng)絡(luò)層：0 bytes 當(dāng)只有二層網(wǎng)絡(luò)時(shí)， 鏈路層Link Next Header (LNH)字段可以指示該包沒有網(wǎng)絡(luò)層IB傳輸層：12 bytes Base Transport Header (BTH)

總計(jì)：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的一個(gè)阻礙之一。

數(shù)據(jù)中心的以太網(wǎng)交換機(jī)往往還要具備許多其他功能，還要付出許多成本來進(jìn)行實(shí)現(xiàn)，比如SDN、QoS等等，這一塊我也不是很懂。

對于這個(gè)以太網(wǎng)的這些features，我挺想知道：以太網(wǎng)針這些功能與RoCE兼容嗎，這些功能會對RoCE的性能產(chǎn)生影響嗎？

RoCE擁塞控制存在的問題

RoCE協(xié)議的兩段擁塞控制都存在一定的問題，可能難以在迅速變化的流量模式下仍然能保持低延遲。

采用PFC(Priority Flow Control)采用的是暫?？刂茙瑏矸乐菇邮盏竭^多的數(shù)據(jù)包從而引起丟包。這種方法比起credit-based的方法，buffer的利用率難免要低一些。由其對于一些延遲較低的交換機(jī)，buffer會相對較少，此時(shí)用PFC(Priority Flow Control)就不好控制；而如果用credit-base則可以實(shí)現(xiàn)更加精確的管理。

DCQCN與IB的擁塞控制相比，其實(shí)大同小異，都是backward notification：通過通過先要將擁塞信息發(fā)送到目的地，然后再將擁塞信息返回到發(fā)送方，再進(jìn)行限速。但是在細(xì)節(jié)上略有不同：RoCE的降速與提速策略根據(jù)論文Congestion Control for Large-Scale RDMA Deployments，是固定死的一套公式；而IB中的可以自定義提速與降速策略；雖然大部分人應(yīng)該實(shí)際上應(yīng)該都用的是默認(rèn)配置，但是有自由度總好過沒有叭。還有一點(diǎn)是，在這篇論文中測試的是每N=50us最多產(chǎn)生一個(gè)CNP包，不知道如果這個(gè)值改小行不行；而IB中想對應(yīng)的CCTI_Timer最小可以為1.024us，也不知道實(shí)際能不能設(shè)置這么小。

最好的方法當(dāng)然還是直接從擁塞處直接返回?fù)砣畔⒔o源，即Forward notification。以太網(wǎng)受限于規(guī)范不這么干可以理解，但是IB為啥不這么干呢？

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

Slingshot

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

將IP數(shù)據(jù)包最小幀大小減小到32 bytes相鄰交換機(jī)的排隊(duì)占用情況(credit)會傳播給相鄰的交換機(jī)更加nb的擁塞控制，但是具體怎么實(shí)現(xiàn)的論文里沒細(xì)說

最后達(dá)到的效果是交換機(jī)平均延遲是350ns，達(dá)到了較強(qiáng)的以太網(wǎng)交換機(jī)的水平，但是還沒沒有IB以及一些定制超算交換機(jī)延遲低，也沒有前一代的Cray XC超算交換機(jī)延遲低。

但是在實(shí)際應(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倍，但是也有一點(diǎn)點(diǎn)參考價(jià)值。

GROMACS測試結(jié)果

一些期待

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

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

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

以太網(wǎng)交換機(jī)的延遲相比于IB交換機(jī)以及一些HPC定制網(wǎng)絡(luò)的交換機(jī)要高一些RoCE的流量控制、擁塞控制策略還有一些改進(jìn)的空間以太網(wǎng)交換機(jī)的成本還是要高一些

但是從實(shí)測性能上來看，在小規(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?

關(guān)鍵詞： 擁塞控制 以太網(wǎng)交換機(jī) 隊(duì)列長度 可擴(kuò)展性 以太網(wǎng)卡