UCloud高性能RoCE網(wǎng)絡(luò)設(shè)計(jì)

電商、直播等業(yè)務(wù)要求以非常快的速度完成請(qǐng)求應(yīng)答，計(jì)算和存儲(chǔ)的飛速提高也在推動(dòng)HPC、分布式訓(xùn)練集群、超融合等新應(yīng)用的普及，網(wǎng)絡(luò)變成制約性能的主要因素之一。為此，我們?cè)O(shè)計(jì)了低開銷高性能的RoCE網(wǎng)絡(luò)，構(gòu)建了低時(shí)延、無損的大型以太網(wǎng)數(shù)據(jù)中心，作為RDMA等技術(shù)的底層基石，也為UCloud未來的物理網(wǎng)絡(luò)建設(shè)打下了良好基礎(chǔ)。

一、低開銷高性能的無損網(wǎng)絡(luò)選型

普通的內(nèi)網(wǎng)進(jìn)行數(shù)據(jù)包交互時(shí)，通常會(huì)使用系統(tǒng)級(jí)的TCP/IP協(xié)議棧或者是DPDK技術(shù)，這兩種方案都是依靠軟件進(jìn)行協(xié)議棧解封裝的，對(duì)系統(tǒng)的CPU有不少消耗。而有一種方案：RDMA，可以直接使用網(wǎng)卡進(jìn)行協(xié)議棧解封裝，無需消耗系統(tǒng)CPU，能有效降低數(shù)據(jù)處理的延時(shí)。

RDMA并沒有規(guī)定全部的協(xié)議棧，比如物理鏈路層、網(wǎng)絡(luò)層、傳輸層每個(gè)字段長什么樣，如何使用，但對(duì)無損網(wǎng)絡(luò)有相當(dāng)高的要求：

–?不輕易丟包，重傳帶來的延時(shí)非常大。

–?吞吐量巨大，跑滿最好。

–?延時(shí)越低越好，100us都嫌長。

依據(jù)上述要求，主流的網(wǎng)絡(luò)方案有三種：

圖：主流的RDMA網(wǎng)絡(luò)方案

①?InfiniBand：?該方案重新設(shè)計(jì)了物理鏈路層、網(wǎng)絡(luò)層、傳輸層，是RDMA最初的部署方案，所以要使用專用的InfiniBand交換機(jī)做物理隔離的專網(wǎng)，成本較大，但性能表現(xiàn)最優(yōu)；

②?iWARP：?該方案的目的是讓主流的以太網(wǎng)支持RDMA，將InfiniBand移植到TCP/IP協(xié)議棧，使用TCP協(xié)議保證無丟包，但缺點(diǎn)在于TCP開銷較大，且算法復(fù)雜，所以性能表現(xiàn)較差；

③?RoCEv2：?該方案的目的也是讓主流的以太網(wǎng)支持RDMA（RoCEv1版本已很少提及了）。網(wǎng)絡(luò)側(cè)使用PFC保證擁塞時(shí)不丟包，網(wǎng)卡側(cè)又使用DCQCN的擁塞控制算法進(jìn)一步減緩擁塞（該擁塞算法需要網(wǎng)絡(luò)側(cè)支持ECN標(biāo)記），傳統(tǒng)的以太網(wǎng)經(jīng)過PFC和ECN的加持進(jìn)化成為無損以太網(wǎng)，在無損以太網(wǎng)上運(yùn)行RDMA性能大大增強(qiáng)。

RoCEv2（后文簡稱RoCE）方案的成熟案例較多，我們也選用了該方案進(jìn)行研究。但RoCE方案仍存在一些問題，如PFC壓制的不公平性、PFC傳遞帶來的死鎖風(fēng)險(xiǎn)、過多的調(diào)參、ECN標(biāo)記的滯后性（ECN概率標(biāo)記是軟件輪詢機(jī)制）等，是需要我們解決完善的。

二、網(wǎng)絡(luò)設(shè)計(jì)的目標(biāo)

要把RoCE搬到經(jīng)典的數(shù)據(jù)中心網(wǎng)絡(luò)上，這可不是一件容易的事兒。

當(dāng)前數(shù)據(jù)中心是常見的CLOS架構(gòu)，LCS是匯聚交換機(jī)，LAS是TOR交換機(jī)。如果RoCE直接運(yùn)行在這上面，問題是顯而易見的：例如出現(xiàn)Incast事件時(shí)，轉(zhuǎn)發(fā)不了的報(bào)文會(huì)被存放在交換機(jī)緩存中，但緩存也不是無限大的，如果存滿了，這個(gè)數(shù)據(jù)包就丟掉了，很明顯這種丟包頻率肯定不能被RDMA所接受。

圖：CLOS架構(gòu)示意

上面只是舉了一個(gè)簡單的例子，實(shí)際上出現(xiàn)的問題要更復(fù)雜一些。在設(shè)計(jì)之前，需要先明確好我們的目標(biāo)是什么，做到有的放矢。

簡單來講我們的目標(biāo)就是：

–?在各種流量模型下，網(wǎng)絡(luò)帶寬要能跑滿；

– 緩存使用要盡可能低；

–?極限情況下緩存使用滿了也不能丟包。

總結(jié)來說，為了讓RoCE跑在已有的網(wǎng)絡(luò)上，我們需要從三個(gè)方面下手：
①?QOS設(shè)計(jì)：指隊(duì)列、調(diào)度、整形等一系列的轉(zhuǎn)發(fā)動(dòng)作，相對(duì)獨(dú)立。

②?無損設(shè)計(jì)：是RDMA的要求之一，使用PFC技術(shù)實(shí)現(xiàn)。無損是一種基本保障，含義是在最擁塞的情況下也能保證其可用性，讓上層應(yīng)用可以放心發(fā)送數(shù)據(jù)，不必?fù)?dān)心丟包的風(fēng)險(xiǎn)（所以說PFC并不是降速的手段）。

③?擁塞控制設(shè)計(jì)：使用DCQCN技術(shù)實(shí)現(xiàn)。擁塞控制是滿足基本保障前提下的進(jìn)一步優(yōu)化，含義是在開始擁塞的時(shí)候，就告知服務(wù)器兩端，使其從源端開始降速，從根本上解決問題。

補(bǔ)充一點(diǎn)擁塞帶來的壞處：當(dāng)出現(xiàn)擁塞后，必然要使用緩存，使用緩存后雖然不丟包了，但是帶來的后果是延遲上升，而且吞吐也不能再增加一絲一毫。網(wǎng)絡(luò)中擁塞點(diǎn)有很多，每一跳都可能成為擁塞點(diǎn)，在上圖的網(wǎng)絡(luò)中，最多會(huì)有3個(gè)擁塞點(diǎn)。

緩存的使用能帶來多少延時(shí)？

我們按25Gbps來算，緩存25Mb的數(shù)據(jù)，大約需要1ms的時(shí)間才能發(fā)送完畢，25Mb也僅僅是3.1MB，而常見的Broadcom Trident 3芯片有32MB的緩存。

有了這三個(gè)方面的認(rèn)識(shí)，我們就可以化繁為簡，逐一破解。

三、QOS設(shè)計(jì)

QOS的設(shè)計(jì)，無非是入隊(duì)、調(diào)度、監(jiān)管和整形。

入隊(duì)方式可以依據(jù)DSCP、TOS、COS等標(biāo)記，然后信任某種標(biāo)記入隊(duì)，也可以選擇使用策略抓取其它報(bào)文特征入隊(duì)。我們最終選擇的策略是：在IDC邊界處，使用報(bào)文特征抓取入隊(duì)，并重寫DSCP，IDC內(nèi)部僅根據(jù)DSCP入隊(duì)（IDC內(nèi)部減少策略使用，滿足高速轉(zhuǎn)發(fā)即可）。這樣，既能保證DSCP標(biāo)記的可信任，又能減輕IDC內(nèi)部的策略復(fù)雜度。根據(jù)這個(gè)思路，我們分別設(shè)置對(duì)應(yīng)策略：

– 對(duì)ToR下行端口與Border上行端口：?抓取特定報(bào)文，進(jìn)入特定隊(duì)列。

–?對(duì)其余設(shè)備和端口設(shè)置：信任DSCP，按映射入隊(duì)。

用圖表表達(dá)即：

■ IDC邊界入隊(duì)

次序

Match

Action

1

udp_dport==4791? &&
dscp==48

入隊(duì)列6

2

udp_dport==4791? &&
dscp==46

入隊(duì)列5

其他

其他

修改dscp為預(yù)定義

*這是已有的標(biāo)記策略，我們IDC內(nèi)部為業(yè)務(wù)進(jìn)行分類，并標(biāo)記特定的DSCP。

*其中次序1、2只在RoCE網(wǎng)絡(luò)的ToR部署。

■ IDC內(nèi)部DSCP映射

DSCP

隊(duì)列

48

6

46

5

其他

2…

下面該聊聊調(diào)度設(shè)計(jì)了，調(diào)度的對(duì)象是緩存中的數(shù)據(jù)，也就是說，調(diào)度是僅在擁塞時(shí)才生效的，而且調(diào)度生效后，影響的將是各隊(duì)列的流量大小。

帶著以上的認(rèn)識(shí)，我們開始調(diào)度設(shè)計(jì)。在一般的RoCE網(wǎng)絡(luò)中，使用的有如下隊(duì)列（或流量）：

①?協(xié)議信令類，目前來看只有CNP流量；（其它協(xié)議均不跨跳，所以不考慮）

②?RoCE流量；

③?業(yè)務(wù)/管理流量。

這三大類流量，還可以繼續(xù)分小類。按照ETC所推薦的調(diào)度模型，我們選擇了SP+WDRR的調(diào)度方式，即：1類流量絕對(duì)優(yōu)先，在緩存積壓的時(shí)候優(yōu)先調(diào)度，直到隊(duì)列為空。2類和3類流量次優(yōu)，兩者之間按照WDRR調(diào)度，權(quán)重值可以靈活定義。這樣就能保證CNP報(bào)文在3us內(nèi)轉(zhuǎn)發(fā)給流量源站（沒有擁塞的網(wǎng)絡(luò)單跳的延時(shí)在1us以內(nèi)）。

以上調(diào)度設(shè)計(jì)中有個(gè)漏洞：如果隊(duì)列6的流量過大，可能會(huì)將低優(yōu)先級(jí)的隊(duì)列餓死（即長時(shí)間得不到調(diào)度），雖然理論上隊(duì)列6的流量一般都在幾十~幾百M(fèi)bps，但仍要提防服務(wù)器惡意***行為。于是，我們將SP的隊(duì)列限制其隊(duì)列使用帶寬。這個(gè)便是所謂的監(jiān)管和整形了。

四、無損涉及與分析

RoCE的流量需要保證運(yùn)行在無損隊(duì)列中，無損隊(duì)列使用了PFC技術(shù)，能針對(duì)某一隊(duì)列發(fā)送Pause幀，迫使上游停流。

在博通的XGS系列芯片中，有一塊緩存管理單元MMU（簡稱緩存），存放已收到但沒轉(zhuǎn)發(fā)走的報(bào)文，并給入口和出口都計(jì)數(shù)：“0/1的入口和0/2的出口，都用了1個(gè)cell”（cell是緩存資源的最小單位）。

緩存會(huì)給每個(gè)入口和出口設(shè)置一個(gè)上限，超過這個(gè)上限就不能再使用cell緩存報(bào)文了。上限以下還畫了很多其它的水線，同時(shí)對(duì)每一個(gè)出口和入口進(jìn)行進(jìn)一步細(xì)分，可以按照隊(duì)列進(jìn)行統(tǒng)計(jì)限額其中入方向。入方向上，細(xì)分了PG-Guaranteed大小、PG-Share大小、Headroom大?。怀龇较蛏?，細(xì)分了Queue-Guaranteed大小，Queue-Share大?。ㄈ缦聢D所示，這里我們不考慮端口，只考慮隊(duì)列）。

圖：隊(duì)列入方向與出方向示意

緩存使用的時(shí)候，總是從下往上依次申請(qǐng)使用，所以更喜歡把這些區(qū)塊大小稱之為“水線”，當(dāng)“某區(qū)塊”都使用完畢，就稱之為“緩存水位”到達(dá)了“某水線”。例如：當(dāng)PG-Share區(qū)塊使用完畢，就稱之為，入口緩存水位已經(jīng)到達(dá)PG-Share水線。如果所有區(qū)塊用完就產(chǎn)生丟包了，稱為no buffer丟包。

每一塊大小都有其特殊用處，先簡單看下其作用，后面再探討下無損隊(duì)列中的這5個(gè)水線應(yīng)該如何設(shè)置。

?PG-Guaranteed和Queue-Guaranteed是保證緩存，這部分是獨(dú)享的，即使不用，別的隊(duì)列也不能搶占使用。

?PG-Share和Queue-Share使用的是共享緩存，因?yàn)閯?dòng)態(tài)水線的緣故，它們的大小不固定，如果很多隊(duì)列都在用，那平分一下，每個(gè)隊(duì)列的水線就都很小。另外，PG-Share還有另一個(gè)重要的作用：PFC發(fā)送的臨界點(diǎn)，也稱為xoff水線，只要到達(dá)該水線，PFC就會(huì)從這個(gè)口發(fā)出去，回落一些后，才恢復(fù)正常。

?Headroom是一個(gè)特殊的水線，只有在無損隊(duì)列中才能發(fā)揮其作用。設(shè)想一下，PFC發(fā)出去以后，流量真的能瞬間停下來么？答案是不能的！因?yàn)榫€纜中還有一部分?jǐn)?shù)據(jù)，而且七七八八的轉(zhuǎn)發(fā)處理時(shí)間也要算進(jìn)去。所以Headroom空間就是用來做這個(gè)的。

**1、PG-Guaranteed和Queue-Guaranteed

**

講完了基本原理，回過頭來看網(wǎng)絡(luò)設(shè)計(jì)。先看PG-Guaranteed和Queue-Guaranteed水線，這倆水線與“無損隊(duì)列”關(guān)系不大，保證緩存的作用只是滿足交換機(jī)基本的存儲(chǔ)轉(zhuǎn)發(fā)功能，所以配置為一個(gè)數(shù)據(jù)包大小即可。那我們按照最差的情況來算，即MTU=9216的巨型幀。

但實(shí)際上我們不必為此發(fā)愁，因?yàn)閯?dòng)態(tài)水線的緣故，共享緩存中總會(huì)有剩余的緩存以供使用，所以保持原廠的默認(rèn)配置即可。

2、Queue-Share

接下來是Queue-Share水線。在無損隊(duì)列中，我們希望在緩存丟包前，能觸發(fā)PFC進(jìn)行反壓，所以在任何情況下，都應(yīng)該入口PG-Share先到達(dá)水線，出口Queue-Share永遠(yuǎn)不能到達(dá)水線（PG-Share到達(dá)會(huì)發(fā)PFC，Queue-Share到達(dá)會(huì)丟包）。

之前講過，MMU記賬是出口入口各記一筆，這樣來看，最差情況應(yīng)該是多打一（出口的帳全記在一個(gè)隊(duì)列上，入口的帳會(huì)均攤到不同隊(duì)列中）。為了讓出口水線永遠(yuǎn)不會(huì)到達(dá)，索性將出口水線配置為無限大好了，事實(shí)證明這樣做也沒有問題，因?yàn)槿肟诘腜G-Share是動(dòng)態(tài)水線，總能在Buffer破產(chǎn)前觸發(fā)該水線。

這樣一來，Queue-Share好像已經(jīng)搞定了，其實(shí)不然，如果TCP流量參與進(jìn)來混跑呢？這問題可就嚴(yán)重了，TCP的Lossy隊(duì)列會(huì)吃掉大量緩存，所以Lossy隊(duì)列中，對(duì)應(yīng)的Queue-Share水線也應(yīng)當(dāng)限制一下。

3、PG-Share

PG-Share水線只要配置為動(dòng)態(tài)水線即可，大小可以隨意調(diào)節(jié)，都不會(huì)出太大問題的，但需要滿足一個(gè)不等式：(PG-Share?+ PG-Guarantee + Headroom) *?[入口個(gè)數(shù)]≤?Queue-Share +?Queue-Guarantee

該公式描述的是一個(gè)端口多打一的場景。入口個(gè)數(shù)根據(jù)實(shí)際情況選取一個(gè)較大值（拿ToR來看，最差情況是39打1，32個(gè)25G下行，8個(gè)100G上行）。

這里的PG-Share是動(dòng)態(tài)水線，動(dòng)態(tài)水線用一個(gè)簡潔的公式即可表達(dá)：PG-Share =?[剩余Buffer] * α

這里的α是縮放因子，用戶可自由調(diào)節(jié)。可以看出，縮放因子決定了PG-Share水線的大小。依據(jù)上面等式，我們只要將Queue-Share水線設(shè)置為靜態(tài)最大、PG-Share設(shè)置為動(dòng)態(tài)即可，入口的縮放因子α可隨意。當(dāng)然入口α也不能設(shè)置太小，在端口少打多的情況下，由于入口的水位很低，導(dǎo)致均攤到每個(gè)出口時(shí)，出口的水位更低！出口的水位過低時(shí)，會(huì)發(fā)現(xiàn)已有的ECN配置不再生效（例如：可能出口的水位還到不了Kmax的一半）。在我們的經(jīng)驗(yàn)看來，無損隊(duì)列中PG-Share的α，配置1/8，1/4，1/2，1都可以，具體大小還要聯(lián)合擁塞設(shè)計(jì)中ECN參數(shù)來決定。

4、Headroom

Headroom水線很重要，但可以通過實(shí)驗(yàn)+推導(dǎo)的方式得出合理的配置，先來看一個(gè)等式：[Headroom大小] = [PFC構(gòu)造到停流的時(shí)間]?*?[端口速率] /?[64字節(jié)小包占用的比特?cái)?shù)]

使用64字節(jié)小包計(jì)算，是因?yàn)樾“鼘?duì)緩存的使用率最低，單個(gè)Cell有200多字節(jié)，但只能被一個(gè)報(bào)文獨(dú)享。其中，只有[PFC構(gòu)造到停流的時(shí)間]是需要進(jìn)一步分解的：T = Tm1?+Tr1?+ Tm2?+Tr2*?Tm1：下游PG檢測(cè)到xoff用完，到構(gòu)造PFC幀發(fā)出的時(shí)間。

* Tr1：PFC幀從下游發(fā)往上游的時(shí)間。

* Tm2：對(duì)端收到PFC幀，到隊(duì)列停止的時(shí)間。

* Tr2：隊(duì)列停止后，線纜中報(bào)文傳輸?shù)臅r(shí)間。

可以看出，這四個(gè)時(shí)間中，只有線纜長度是變量，繼續(xù)化簡后可以得出：[Headroom大小]?= (Tm1?+ Tm2?+2 *?[線纜長度] / [信號(hào)傳播速度]) *?[端口速率] / [64字節(jié)小包占用的比特?cái)?shù)])

這里面Tm1?+ Tm2?是常數(shù)，可以實(shí)驗(yàn)測(cè)得，剩余的都是已知量了。最后根據(jù)公式就可以算得100G口，100M光纖下，H = 408 cell；25G口，15M AOC下，H = 98 cell。當(dāng)然，真正使用的時(shí)候，還要再冗余一點(diǎn)，畢竟這是臨界值。

5、死鎖分析和解決

談到PFC就不得不提一下死鎖，死鎖危害極大，而且其傳遞性會(huì)迅速擴(kuò)散到整個(gè)網(wǎng)絡(luò)，以至于整個(gè)網(wǎng)絡(luò)的無損隊(duì)列全部停流。死鎖的研究很多，其中較詳細(xì)的是微軟的一篇論文《Deadlocks in Datacenter Networks: Why Do They Form, and How to Avoid Them》。

死鎖產(chǎn)生的一個(gè)必要條件是CBD（環(huán)狀緩存依賴），在我們的組網(wǎng)環(huán)境中，是典型的CLOS組網(wǎng)，所以在穩(wěn)定狀態(tài)下不會(huì)存在CBD，也沒有死鎖風(fēng)險(xiǎn)。而且整個(gè)POD內(nèi)部路由不做過濾，明細(xì)互知，匯聚采用4臺(tái)~8臺(tái)冗余，即使出現(xiàn)兩點(diǎn)故障，收斂后的拓?fù)湟膊粫?huì)存在CBD，即不會(huì)存在死鎖風(fēng)險(xiǎn)。

圖：CBD和死鎖

至此，我們已經(jīng)解決穩(wěn)定狀態(tài)下的死鎖了，但還要考慮一點(diǎn)：收斂過程中，是否存在CBD？其實(shí)仔細(xì)分析一下還是會(huì)存在的，我們考慮了很多收斂場景，確實(shí)會(huì)有部分場景下，存在微環(huán)路。有微環(huán)路就一定有CBD。事實(shí)證明，我們也真實(shí)地模擬出了微環(huán)路導(dǎo)致的死鎖。

死鎖問題總是要解決的。我們使用三種方法：

1、針對(duì)各種微環(huán)路場景，通過設(shè)計(jì)網(wǎng)絡(luò)協(xié)議，控制收斂的現(xiàn)先后關(guān)系，避免出現(xiàn)微環(huán)路出現(xiàn)。

2. 對(duì)于其它未知的死鎖風(fēng)險(xiǎn)，使用交換機(jī)的死鎖檢測(cè)功能，釋放緩存（釋放緩存會(huì)產(chǎn)生丟包，但收斂過程本身就有亂序/丟包情況）。

3. 將PG-Share的水線適當(dāng)拉高，盡量使用DCQCN擁塞控制來壓制流量。

五、擁塞控制設(shè)計(jì)與分析

網(wǎng)絡(luò)擁塞控制是一個(gè)很復(fù)雜的課題，這里只講一些基本的設(shè)計(jì)思路。
RoCE使用的擁塞控制算法是DCQCN，_《Congestion Control for Large-Scale RDMA Deployments》_這篇論文很詳細(xì)地描述了該算法。

這里先簡單的描述下這個(gè)算法：維護(hù)這個(gè)算法的節(jié)點(diǎn)是服務(wù)器，也就是流量的兩端，中間的交換機(jī)作為傳輸節(jié)點(diǎn)，通告是否擁塞。發(fā)送方叫Reaction Point，簡稱RP；接收方叫Notification Point，簡稱NP；中間交換機(jī)叫 Congestion Point，簡稱CP。發(fā)送方（RP）以最高速開始發(fā)送，沿途過程中如果有擁塞，會(huì)被標(biāo)記ECN顯示擁塞，當(dāng)這個(gè)被標(biāo)記的報(bào)文轉(zhuǎn)發(fā)到接收方（NP）的時(shí)候，接收方（NP）會(huì)回應(yīng)一個(gè)CNP報(bào)文，通知發(fā)送方（RP）。收到CNP報(bào)文的發(fā)送方（RP），就會(huì)開始降速。當(dāng)發(fā)送方?jīng)]有收到CNP報(bào)文時(shí)，就開始又提速了。

上述過程就是DCQCN的基本思路。雖然整個(gè)算法十分復(fù)雜，但都是圍繞這個(gè)基本思路，繼續(xù)完善算法細(xì)節(jié)（下圖分別是NP的狀態(tài)機(jī)和RP的算法）。可調(diào)參數(shù)也十分眾多，比如降速要降低多少？提速效率是否積極？網(wǎng)絡(luò)擁塞度如何維護(hù)？擁塞度更新周期多久？CNP報(bào)文的敏感度多大？這都是問題，需要對(duì)流量建模后找出合理參數(shù)。

圖：接收方

圖：發(fā)送方

DCQCN算法中，對(duì)RP、NP和CP都有很多參數(shù)可以調(diào)節(jié)。RP和NP節(jié)點(diǎn)在服務(wù)器上，準(zhǔn)確來說應(yīng)該是在網(wǎng)卡上，網(wǎng)卡初始化的參數(shù)已經(jīng)為最優(yōu)值，無需再進(jìn)行調(diào)整，這樣就剩CP上的參數(shù)需要調(diào)整了。

CP上有三個(gè)參數(shù)其實(shí)就是WRED-ECN的那三個(gè)參數(shù)，分別是Kmin，Kmax，Pmax，這三者的關(guān)系，可以用下圖來表示。橫軸是出向隊(duì)列長度，縱軸是報(bào)文被標(biāo)記的概率。從圖中可以看到，在隊(duì)列長度超過Kmax時(shí)，標(biāo)記概率出現(xiàn)一個(gè)跳變，從Pmax直接到達(dá)100%。

根據(jù)上面的理論分析，我們可以通過實(shí)驗(yàn)證實(shí)和試錯(cuò)的方法一步步找到最優(yōu)解。

現(xiàn)在設(shè)想一下：在一個(gè)擁塞場景中，當(dāng)出口隊(duì)列長度小于Kmin時(shí)，不會(huì)被標(biāo)記，出口隊(duì)列長度可能會(huì)穩(wěn)步增長，當(dāng)隊(duì)列長度超過Kmin時(shí)，DCQCN才開始降速。
所以Kmin的大小決定了RoCE網(wǎng)絡(luò)的基礎(chǔ)延時(shí)，這些緩存中的報(bào)文是發(fā)送者發(fā)出，但未被接收者確認(rèn)的報(bào)文，我們稱之為inflight bytes，約等于延時(shí)帶寬積。所以，Kmin的配置規(guī)范為小于期望的延時(shí)帶寬積。有了這個(gè)理論基礎(chǔ)后，實(shí)踐測(cè)得理論符合實(shí)際，還可以根據(jù)測(cè)得的延時(shí)進(jìn)一步調(diào)整該數(shù)值。

我們用同樣的思路來思考Kmax，承接剛剛的思路，那就是：Kmax的配置規(guī)范為小于或等于能容忍的延時(shí)帶寬積。但這次不再這么簡單了，因?yàn)镵max還決定了圖中的斜率。同樣決定斜率的還有Pmax，在討論Kmax和Pmax前，我們不得不先介紹下整個(gè)ECN的理想與現(xiàn)實(shí)。

理想狀態(tài)下，標(biāo)記概率在定義域Kmin~Kmax內(nèi)的變化是連續(xù)的，而且，隊(duì)列的長度是準(zhǔn)確的。但事與愿違，博通芯片SDK使用軟件輪詢的方式測(cè)得隊(duì)列長度，而且將此刻的隊(duì)列長度與歷史值做指數(shù)平均，并依此計(jì)算標(biāo)記概率。軟件輪詢帶來的結(jié)果是，標(biāo)記概率在定義域Kmin~Kmax內(nèi)的變化是不連續(xù)的，其次，指數(shù)平均值會(huì)讓測(cè)得的隊(duì)列長度是滯后的（當(dāng)然指數(shù)平均也帶來了好處，這里不展開）。

這件事帶給我們的影響就是，理論推導(dǎo)的Pmax，甚至Kmin、Kmax都被推翻，請(qǐng)繼續(xù)往下看：理想狀態(tài)下，一個(gè)25G端口、單QP會(huì)話下，最大的有效Pmax是多少？

根據(jù)DCQCN中NP的算法，50us內(nèi)收到多個(gè)CE標(biāo)記包，會(huì)被認(rèn)為只有一個(gè)有效包，所以最高的CE標(biāo)記速率應(yīng)該為20000個(gè)包每秒（即1個(gè)包每50微秒），依此，我們算得最高有效Pmax，即是設(shè)置的Pmax值，如下表所示：我們假設(shè)一個(gè)25G端口、只有一個(gè)QP會(huì)話，此時(shí)最高有效Pmax是多少？可以根據(jù)表格中第4、5列計(jì)算出最后一列最高有效Pmax的值。

再回到現(xiàn)實(shí)，我們按照推導(dǎo)的數(shù)據(jù)對(duì)表格最后一行進(jìn)行驗(yàn)證。

對(duì)端口限速模擬擁塞，測(cè)得穩(wěn)定時(shí)RoCE流量pps=2,227,007，然后選取一組ECN配置：Kmin=1cell，Kmax=1400cell，Pmax=1%，理論上來說Pmax已經(jīng)超出最高有效的值了，理論上即使在擁塞時(shí)，出口水位也不可能達(dá)到1400cell，所以再設(shè)置一個(gè)監(jiān)控項(xiàng)，監(jiān)控出口水位有沒有超過1400cell（觸發(fā)式告警，并非輪詢，所以不會(huì)存在采集不到的情況）這是第一個(gè)實(shí)驗(yàn)。

作為對(duì)比，第二個(gè)實(shí)驗(yàn)使用另一組ECN配置，Kmin=800cell，Kmax=1400cell，Pmax=1%，按照之前分析，這一組配置下，出口水位也不會(huì)超過1400cell，因?yàn)樵?400cell水位時(shí)，Pmax=1已經(jīng)超過最高有效標(biāo)記概率了。

可是實(shí)驗(yàn)結(jié)果并不符合預(yù)期，第一個(gè)實(shí)驗(yàn)沒有觸發(fā)告警，通過；第二個(gè)卻觸發(fā)告警了。這就意味著在某些時(shí)刻，緩存水位超過1400cell了！水位是波動(dòng)的，并沒有穩(wěn)定在某個(gè)值！我們大膽猜測(cè)其中原因：從緩存隊(duì)列積壓，到得到緩解，這其中有太多地方消耗了時(shí)間：隊(duì)列長度的輪詢、指數(shù)平均算法、CNP的生成與轉(zhuǎn)發(fā)，甚至于降速后線纜中的數(shù)據(jù)傳輸?shù)鹊取?/p>

為解決這一難題，我們另辟蹊徑，選擇了另外一條路：首先制定了幾個(gè)小目標(biāo)，然后通過大量的實(shí)驗(yàn)來摸索出驗(yàn)證一套安全可靠的配置。這個(gè)方法雖然更野蠻，但很有效。

??小目標(biāo)1：服務(wù)器端口吞吐量要在95%以上；

??小目標(biāo)2：所有流量場景下交換機(jī)99%的時(shí)間里PFC發(fā)送速率不得高于5pps；

??小目標(biāo)3：任意場景下服務(wù)器端到端延時(shí)不得高于80us（90%場景下低于40us）。

對(duì)于流量模型，我們?cè)O(shè)計(jì)篩選后，選用了50余種流量，最終我們得到了同時(shí)滿足這三個(gè)小目標(biāo)的合理參數(shù)。

不得不說，DCQCN很難玩轉(zhuǎn)，參數(shù)眾多且互有聯(lián)系，這里也只是提供一些實(shí)踐規(guī)律，歡迎一同深入探討。

六、總結(jié)

為使物理網(wǎng)絡(luò)具備承載RDMA業(yè)務(wù)流量的能力，我們選擇了RoCE的網(wǎng)絡(luò)方案，并通過QOS、無損、擁塞控制三塊設(shè)計(jì)，來保證物理網(wǎng)絡(luò)無損轉(zhuǎn)發(fā)。RoCE無損網(wǎng)絡(luò)為快杰云主機(jī)這樣高性能的業(yè)務(wù)系統(tǒng)提供了強(qiáng)大的支撐，如高達(dá)120萬IOPS的RSSD云盤，25Gbps的內(nèi)網(wǎng)線速轉(zhuǎn)發(fā)帶寬。