RoCE技術(shù)在HPC中的應(yīng)用分析

摘要

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

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

在早年的高性能計(jì)算(HPC)系統(tǒng)中，往往會(huì)采用一些定制的網(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)性能的大幅提升，使越來(lái)越多的人想要選擇能兼容傳統(tǒng)以太網(wǎng)的高性能網(wǎng)絡(luò)解決方案。這也打破了top500上使用以太網(wǎng)的HPC集群數(shù)量越來(lái)越少的趨勢(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)存直接訪(fǎng)問(wèn)）的集群網(wǎng)絡(luò)通信協(xié)議。它將收/發(fā)包的工作卸載(offload)到了網(wǎng)卡上，不需要想TCP/IP協(xié)議一樣使系統(tǒng)進(jìn)入內(nèi)核態(tài)，減少了拷貝、封包解包等等的開(kāi)銷(xiāo)。這樣大大降低了以太網(wǎng)通信的延遲，減少了通訊時(shí)對(duì)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，來(lái)表明這是一個(gè)RoCE數(shù)據(jù)包。但是由于RoCE協(xié)議沒(méi)有繼承以太網(wǎng)的網(wǎng)絡(luò)層，在RoCE數(shù)據(jù)包中并沒(méi)有IP字段，因此RoCE數(shù)據(jù)包不能被三層路由，數(shù)據(jù)包的傳輸只能被局限在一個(gè)二層網(wǎng)絡(luò)中路由。

RoCEv2協(xié)議

RoCE v2協(xié)議對(duì)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é)議，人們?cè)谔岬絉oCE協(xié)議時(shí)一般也指的是RoCE v2協(xié)議，故本文中接下來(lái)提到的所有RoCE協(xié)議，除非特別聲明為第一代RoCE，均指代RoCE v2協(xié)議。

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

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

RoCE和Soft-RoCE

雖然現(xiàn)在大部分的高性能以太網(wǎng)卡都能支持RoCE協(xié)議，但是仍然有一些網(wǎng)卡不支持RoCE協(xié)議。因此IBM、Mellanox等聯(lián)手創(chuàng)建了開(kāi)源的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所示。雖然這并不會(huì)給前者帶來(lái)性能提升，但是讓后者能夠充分發(fā)揮其性能。在一些場(chǎng)景下，比如：數(shù)據(jù)中心，可以只將其高IO存儲(chǔ)服務(wù)器升級(jí)為支持RoCE協(xié)議的以太網(wǎng)卡，以提高整體性能和可擴(kuò)展性。同時(shí)這種RoCE和Soft-RoCE結(jié)合的方法也可以滿(mǎn)足集群逐步升級(jí)的需求，而不用一次性全部升級(jí)。

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

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

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

RoCE的低延遲

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

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

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

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

IB傳輸層：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 CRC

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

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

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

RoCE擁塞控制存在的問(wèn)題

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

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

Slingshot

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

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

相鄰交換機(jī)的排隊(duì)占用情況(credit)會(huì)傳播給相鄰的交換機(jī)

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

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

CESM與GROMACS測(cè)試

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

一些期待

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

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

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

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

RoCE的流量控制、擁塞控制策略還有一些改進(jìn)的空間

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

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

參考資料

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 ? ?

編輯：黃飛

?