RDMA RoCEv2、AWS SRD/EFA和阿里云HPCC

編者按：

本文是《軟硬件融合——超大規(guī)模云計(jì)算架構(gòu)創(chuàng)新之路》圖書內(nèi)容的節(jié)選。云計(jì)算系統(tǒng)持續(xù)解構(gòu)，東西向網(wǎng)絡(luò)流量激增，服務(wù)器堆棧延遲問題凸顯。要想提升數(shù)據(jù)中心網(wǎng)絡(luò)性能，大體上通過(guò)如下措施：

（1）網(wǎng)絡(luò)容量升級(jí)，例如整個(gè)網(wǎng)絡(luò)從25Gbps升級(jí)到100Gbps；

（2）輕量協(xié)議棧，數(shù)據(jù)中心網(wǎng)絡(luò)是局域網(wǎng)絡(luò)，距離短/延遲敏感，不需要復(fù)雜的用于全球互聯(lián)的TCP/IP協(xié)議棧；

（3）網(wǎng)絡(luò)協(xié)議處理硬件加速；

（4）高性能軟硬件交互：高效交互協(xié)議 + PMD + PF/VF/MQ；

（5）擁塞控制：低延遲、高可靠性（低性能抖動(dòng)）、高網(wǎng)絡(luò)利用率。

案例：RDMA RoCEv2、AWS SRD/EFA和阿里云HPCC。

1 高速網(wǎng)絡(luò)接口RDMA/RoCEv2

RDMA是一整套高性能網(wǎng)絡(luò)傳輸技術(shù)的集合，不僅僅是軟件和硬件的接口。RDMA的軟件和硬件接口，并沒有形成如同存儲(chǔ)NVMe那樣非常嚴(yán)格的標(biāo)準(zhǔn)。本節(jié)通過(guò)RDMA以及RoCEv2的相關(guān)介紹，使大家對(duì)高性能網(wǎng)絡(luò)傳輸接口以及協(xié)議棧有個(gè)整體的認(rèn)識(shí)。

1.1 基本概念

RDMA（Remote Direct Memory Access，遠(yuǎn)程直接內(nèi)存訪問）是一種高帶寬、低延遲、低CPU消耗的網(wǎng)絡(luò)互聯(lián)技術(shù)，克服了傳統(tǒng)TCP/IP網(wǎng)絡(luò)的許多困難。RDMA技術(shù)體現(xiàn)在：

Remote（遠(yuǎn)程）：數(shù)據(jù)在網(wǎng)絡(luò)中的兩個(gè)節(jié)點(diǎn)之間傳輸。

Direct（直接）：不需要內(nèi)核參與，傳輸?shù)乃刑幚矶夹遁d到NIC硬件中完成。

Memory（內(nèi)存）：數(shù)據(jù)直接在兩個(gè)節(jié)點(diǎn)的應(yīng)用程序的虛擬內(nèi)存間傳輸；不需要額外的復(fù)制和緩存。

Access（訪問）：訪問操作有send/receive、read/write等。

如圖1，RoCE（RDMA over Converaged Ethernet）v1是基于現(xiàn)有Ethernet網(wǎng)絡(luò)實(shí)現(xiàn)RDMA的一項(xiàng)技術(shù)。RoCEv1允許在現(xiàn)有以太網(wǎng)基礎(chǔ)上實(shí)現(xiàn)RDMA技術(shù)，實(shí)現(xiàn)接近InfiniBand的性能和延遲指標(biāo)，但不需要將現(xiàn)有網(wǎng)絡(luò)基礎(chǔ)設(shè)施升級(jí)成昂貴的InfiniBand，節(jié)約了大量的支出。RoCEv2基于標(biāo)準(zhǔn)網(wǎng)絡(luò)的以太網(wǎng)（Ethernet PHY/MAC）、網(wǎng)絡(luò)層（IP）和傳輸層（UDP）協(xié)議，這可以使得RoCEv2的網(wǎng)絡(luò)流量可以經(jīng)過(guò)傳統(tǒng)的網(wǎng)絡(luò)路由器路由。

圖1 RDMA所使用的InfiniBand、RoCEv1/v2、iWARP技術(shù)對(duì)比

1.2 RoCE分層

RoCEv2是當(dāng)前數(shù)據(jù)中心比較流行的RDMA技術(shù)，我們以RoCEv2為例，介紹RoCE的系統(tǒng)分層。

如圖2所示，RoCEv2自下而上分為：

以太網(wǎng)層：標(biāo)準(zhǔn)的Ethernet協(xié)議，即網(wǎng)絡(luò)五層協(xié)議物理層和數(shù)據(jù)鏈路層。

網(wǎng)絡(luò)層（IP）：即網(wǎng)絡(luò)五層協(xié)議中的網(wǎng)絡(luò)層。

傳輸層（UDP）：即網(wǎng)絡(luò)五層協(xié)議中的傳輸層（選用UDP協(xié)議而不是TCP協(xié)議）。

IB傳輸層（Transport Layer）：IB傳輸層負(fù)責(zé)數(shù)據(jù)包的分發(fā)、分割、通道復(fù)用和傳輸服務(wù)。接收方會(huì)確認(rèn)數(shù)據(jù)包，然后把確認(rèn)信息發(fā)動(dòng)到發(fā)送方，發(fā)送方會(huì)根據(jù)這些確認(rèn)信息更新完成隊(duì)列。

RDMA硬件數(shù)據(jù)引擎層（Data Engine Layer）：負(fù)責(zé)內(nèi)存隊(duì)列和RDMA硬件之間工作/完成請(qǐng)求的數(shù)據(jù)傳輸?shù)取?/p>

RDMA接口驅(qū)動(dòng)層：負(fù)責(zé)RDMA硬件的配置管理，負(fù)責(zé)隊(duì)列和內(nèi)存的管理，負(fù)責(zé)工作請(qǐng)求添加到工作隊(duì)列中，負(fù)責(zé)完成請(qǐng)求的處理等。

Verbs API層：接口驅(qū)動(dòng)的封裝。管理連接狀態(tài)、管理內(nèi)存和隊(duì)列訪問、提交工作給RDMA硬件、從RDMA硬件獲取工作和事件。

ULP層：OFED ULP（Upper Layer Protocol，上層協(xié)議）軟件庫(kù)，提供了各種軟件協(xié)議的RDMA verbs支持，讓上層應(yīng)用可以無(wú)縫移植到RDMA平臺(tái)。

應(yīng)用層：分為兩類，RDMA原生的應(yīng)用，基于RDMA verbs API開發(fā)；另外，OFA提供了可以無(wú)縫兼容已有應(yīng)用的OFED協(xié)議棧，讓已有的應(yīng)用可以無(wú)縫的使用RDMA功能。

圖2 RoCEv2分層

1.3 RDMA接口

RDMA并沒有約束嚴(yán)格的軟硬件接口，各家的實(shí)現(xiàn)各有不同，只需要支持RDMA的隊(duì)列機(jī)制即可。Verbs API則是開源的標(biāo)準(zhǔn)的接口，具體的軟硬件接口實(shí)現(xiàn)需要通過(guò)驅(qū)動(dòng)對(duì)接到Verbs API。

a.RDMA工作隊(duì)列

軟件驅(qū)動(dòng)和硬件設(shè)備的交互通常基于生產(chǎn)者消費(fèi)者模型，這樣能夠?qū)崿F(xiàn)異步的交互，實(shí)現(xiàn)軟件和硬件的解耦。RDMA接口中驅(qū)動(dòng)和設(shè)備的交互也是如此，RDMA軟硬件共享的隊(duì)列數(shù)據(jù)結(jié)構(gòu)稱為工作隊(duì)列（Work Queue）。

如圖3所示，工作隊(duì)列是軟件驅(qū)動(dòng)和硬件RDMA交互的共享Queue。驅(qū)動(dòng)負(fù)責(zé)把工作請(qǐng)求（Work Request）添加到工作隊(duì)列，成為工作隊(duì)列中的一項(xiàng)，稱為工作隊(duì)列項(xiàng)（Work Queue Element）。RDMA硬件設(shè)備會(huì)負(fù)責(zé)WQE在內(nèi)存和硬件之間的傳輸，并且通過(guò)RDMA網(wǎng)絡(luò)最終把WQE送到接收方的工作隊(duì)列中去。最后，接收方RDMA硬件會(huì)反饋確認(rèn)信息給到發(fā)送方RDMA硬件，發(fā)送方RDMA硬件會(huì)根據(jù)確認(rèn)信息生成完成隊(duì)列項(xiàng)（Completion Queue Element）發(fā)送到內(nèi)存的完成隊(duì)列（Completion Queue）。

圖3 RDMA數(shù)據(jù)傳輸模型——工作隊(duì)列

RDMA Queue類型有：

發(fā)送隊(duì)列（Send Queue）：用于發(fā)送數(shù)據(jù)消息。

接收隊(duì)列（Receive Queue）：用于接收輸入的數(shù)據(jù)消息。

完成隊(duì)列（Completion Queue）：完成隊(duì)列主要是用于實(shí)現(xiàn)RDMA操作異步的實(shí)現(xiàn)。

隊(duì)列對(duì)（Queue Pair）：發(fā)送隊(duì)列和接收隊(duì)列組成一組隊(duì)列對(duì)。

b.Verbs API操作

RDMA Verbs是提供給應(yīng)用程序使用的最底層的RDMA功能抽象，RoCEv2中的Verbs操作主要有兩類：

Send/Recv。類似于Client/Server結(jié)構(gòu)，發(fā)送操作和接收操作協(xié)作完成，在發(fā)送方連接之前，接收方必須處于偵聽狀態(tài)；發(fā)送方不知道接收方的虛擬內(nèi)存位置，接收方也不知道發(fā)送方的虛擬內(nèi)存地址。不同的是RDMA Send/Recv因?yàn)槭侵苯訉?duì)內(nèi)存操作，因此需要提前注冊(cè)用于傳輸?shù)膬?nèi)存區(qū)域。

Write/Read。與Client/Server架構(gòu)不同，Write/Read是請(qǐng)求方處于主動(dòng)，響應(yīng)方處于被動(dòng)。請(qǐng)求方執(zhí)行Write/Read操作，響應(yīng)方不需要做任何操作。為了能夠操作響應(yīng)方的內(nèi)存，請(qǐng)求方需要提前獲得響應(yīng)方的地址和鍵值。

1.4 RDMA總結(jié)

計(jì)算機(jī)網(wǎng)絡(luò)中的通信延遲主要是指：處理延遲和網(wǎng)絡(luò)傳輸延遲。處理延遲開銷指的就是消息在發(fā)送和接收階段的處理時(shí)間。網(wǎng)絡(luò)傳輸延遲指的就是消息在發(fā)送和接收之間的網(wǎng)絡(luò)中傳輸?shù)臅r(shí)間。在通常的南北向網(wǎng)絡(luò)流量場(chǎng)景，基本都是遠(yuǎn)距離傳輸，網(wǎng)絡(luò)傳輸延遲占了絕大部分，因此處理延遲問題并沒有凸顯。

隨著云計(jì)算技術(shù)的發(fā)展，需要頻繁的在集群服務(wù)器之間傳遞數(shù)據(jù)流量，數(shù)據(jù)中心中的東西向網(wǎng)絡(luò)流量激增。在數(shù)據(jù)中心的短距離傳輸下，網(wǎng)絡(luò)傳輸延遲大幅度縮小，處理延遲問題開始凸顯。另外，東西向流量本身就是流量大、延遲敏感的應(yīng)用場(chǎng)景，這要求進(jìn)一步的優(yōu)化處理延遲。如圖4，RDMA不僅僅是一種高效的用于數(shù)據(jù)傳輸?shù)能浻布涌?，更是一種通過(guò)硬件實(shí)現(xiàn)網(wǎng)絡(luò)數(shù)據(jù)傳輸加速的軟硬件整體解決方案。

圖4 RDMA傳輸模型

跟傳統(tǒng)的TCP/IP網(wǎng)絡(luò)技術(shù)相比，RDMA技術(shù)的優(yōu)勢(shì)體現(xiàn)在：

更高效的協(xié)議棧：InfiniBand相比傳統(tǒng)的TCP/IP網(wǎng)絡(luò)協(xié)議棧更加高效，RoCEv2使用了UDP，相比TCP更高效一些。因?yàn)槭怯糜诰钟蚓W(wǎng)的數(shù)據(jù)傳輸，數(shù)據(jù)的丟包率會(huì)低很多，UDP有更優(yōu)的性能。

協(xié)議棧硬件卸載：整個(gè)RDMA協(xié)議棧處理完全由硬件完成，進(jìn)一步提升性能，并且降低CPU資源消耗。

直接內(nèi)存操作：內(nèi)存一旦注冊(cè)，數(shù)據(jù)就可以直接在內(nèi)存和內(nèi)存之間拷貝，不需要經(jīng)過(guò)內(nèi)核協(xié)議棧層的發(fā)送接收方各一次的拷貝；

操作系統(tǒng) Bypass：沒有了內(nèi)核協(xié)議棧，用戶空間驅(qū)動(dòng)直接繞過(guò)內(nèi)核，減少了操作系統(tǒng)模式切換的開銷；

異步操作：一次事務(wù)操作分為發(fā)送Request（請(qǐng)求）和接收Completion（完成），這樣就不會(huì)阻塞傳輸。

2 高性能網(wǎng)絡(luò)優(yōu)化

在基礎(chǔ)網(wǎng)絡(luò)、硬件加速以及網(wǎng)絡(luò)接口都確定的情況下，為了更充分的利用網(wǎng)絡(luò)容量，達(dá)到網(wǎng)絡(luò)的高性能的同時(shí)防止性能抖動(dòng)，就需要進(jìn)行網(wǎng)絡(luò)擁塞控制。

a.網(wǎng)絡(luò)擁塞控制簡(jiǎn)介

網(wǎng)絡(luò)中如果存在太多的數(shù)據(jù)包，會(huì)導(dǎo)致數(shù)據(jù)包的延遲，并且會(huì)因?yàn)槌瑫r(shí)而丟失，從而降低了傳輸性能，這種情況稱為擁塞(Congestion) 。高性能網(wǎng)絡(luò)非常重要的一個(gè)方面，就是在充分利用網(wǎng)絡(luò)容量，提供低延遲網(wǎng)絡(luò)傳輸?shù)耐瑫r(shí)，盡可能的避免網(wǎng)絡(luò)擁塞。

如圖5(a)所示，當(dāng)主機(jī)發(fā)送到網(wǎng)絡(luò)的數(shù)據(jù)包數(shù)量在其承載能力范圍之內(nèi)時(shí)，送達(dá)的數(shù)據(jù)包數(shù)與發(fā)送的數(shù)據(jù)包數(shù)成正比例增長(zhǎng)。隨著負(fù)載接近網(wǎng)絡(luò)承載能力，偶爾突發(fā)的網(wǎng)絡(luò)流量會(huì)導(dǎo)致?lián)砣罎?。如圖 8.16(b)所示，為加載的數(shù)據(jù)包和延遲的函數(shù)關(guān)系，可以看到，當(dāng)加載的數(shù)據(jù)包增加到接近承載上限的時(shí)候，其延遲時(shí)間是急劇上升的。

(a) 實(shí)際吞吐率的擁塞崩潰 (b) 延遲成指數(shù)上升

圖5 網(wǎng)絡(luò)擁塞導(dǎo)致的吞吐率和延遲問題

說(shuō)明：擁塞控制和流量控制不是一回事：擁塞控制的目標(biāo)是確保網(wǎng)絡(luò)能夠承載所有到達(dá)的流量，這是一個(gè)全局性的問題；相對(duì)的，流量控制只與特定的發(fā)送方和特定的接收方之間的點(diǎn)到點(diǎn)流量有關(guān)，流量控制的目標(biāo)是確保一個(gè)快速的發(fā)送方不會(huì)持續(xù)地以超過(guò)接收方接收能力的速率傳輸數(shù)據(jù)。

針對(duì)擁塞所采取的辦法有很多種，根據(jù)解決方案效果的從慢到快，介紹如下：

避免擁塞的最基本方法是建立一個(gè)與流量匹配的網(wǎng)絡(luò)，需要根據(jù)流量的利用率增長(zhǎng)趨勢(shì)提前升級(jí)網(wǎng)絡(luò)；

充分利用現(xiàn)有網(wǎng)絡(luò)容量，根據(jù)不同時(shí)刻的流量模式度身定制路由，這稱為流量感知的路由；

增加網(wǎng)絡(luò)容量需要時(shí)間，因此解決擁塞的最直接的辦法就是降低負(fù)載。比如拒絕新連接的建立，這稱為準(zhǔn)入控制；

當(dāng)擁塞即將到來(lái)前，網(wǎng)絡(luò)可以給造成擁塞問題的源端傳遞反饋信息，要求源端抑制它們的流量；

當(dāng)一切努力均失敗，網(wǎng)絡(luò)不得不丟棄它無(wú)法傳遞的數(shù)據(jù)包，這稱為負(fù)載脫落。

擁塞控制算法的目標(biāo)是：

更加易于避免擁塞，即找到一種優(yōu)化的帶寬分配方法。一個(gè)優(yōu)化的帶寬分配方法能帶來(lái)更好的性能，因?yàn)樗艹浞掷盟械目捎脦拝s能避免擁塞；

并且，此帶寬分配算法對(duì)于所有傳輸是公平的，既能保證大流量數(shù)據(jù)流的快速傳輸，又能保證小流量數(shù)據(jù)流的及時(shí)傳輸；

最后，擁塞控制算法能夠快速收斂到公平高效的帶寬分配。

b.阿里云HPCC，RDMA擁塞控制優(yōu)化

在過(guò)去的十年中，數(shù)據(jù)中心網(wǎng)絡(luò)的端口帶寬已從1 Gbps增長(zhǎng)到100 Gbps，并且這種增長(zhǎng)還在持續(xù)。越來(lái)越多的應(yīng)用程序要求更低的延遲和更高的帶寬，在數(shù)據(jù)中心，有兩個(gè)重要的趨勢(shì)驅(qū)動(dòng)著對(duì)高性能網(wǎng)絡(luò)的需求：

第一個(gè)趨勢(shì)是新的數(shù)據(jù)中心架構(gòu)。例如資源解構(gòu)和異構(gòu)計(jì)算：在資源解構(gòu)中，CPU需要與GPU、內(nèi)存和磁盤等遠(yuǎn)程資源進(jìn)行高速網(wǎng)絡(luò)互聯(lián)；在CPU和加速器解構(gòu)的異構(gòu)計(jì)算環(huán)境中，不同的計(jì)算芯片也需要（通過(guò)網(wǎng)絡(luò)）高速互連，并且延遲越小越好。

第二個(gè)趨勢(shì)是新的應(yīng)用程序。例如運(yùn)行于高速IO介質(zhì)（如NVMe）上的存儲(chǔ)，以及在GPU和ASIC之類的加速計(jì)算設(shè)備上進(jìn)行大規(guī)模機(jī)器學(xué)習(xí)訓(xùn)練。這些應(yīng)用程序會(huì)定期的傳輸大量數(shù)據(jù)，其存儲(chǔ)和計(jì)算速度非常快，性能的瓶頸通常是網(wǎng)絡(luò)傳輸。

傳統(tǒng)的基于軟件的網(wǎng)絡(luò)堆棧不再能夠滿足關(guān)鍵的延遲和帶寬要求，將網(wǎng)絡(luò)堆棧卸載到硬件中是高速網(wǎng)絡(luò)中的必然方向。在數(shù)據(jù)中心中的部署RoCEv2，通過(guò)RDMA進(jìn)行網(wǎng)絡(luò)傳輸，是當(dāng)前主要的硬件卸載解決方案。不幸的是，大規(guī)模的RDMA網(wǎng)絡(luò)在平衡低延遲、高帶寬利用率和高穩(wěn)定性方面面臨根本的挑戰(zhàn)。經(jīng)典的RDMA擁塞機(jī)制，例如DCQCN和TIMELY算法，具有一些局限性：

收斂緩慢。對(duì)于粗粒度的反饋，例如ECN（Explicit Congestion Notification，顯式擁塞通知）或RTT（Round-Trip Time，傳輸往返時(shí)間），擁塞方案無(wú)法確切知道增加或降低發(fā)送速率的程度，使用啟發(fā)式方法推測(cè)速率更新，迭代收斂到穩(wěn)定的速率。

不可避免的數(shù)據(jù)包排隊(duì)。DCQCN利用ECN標(biāo)記來(lái)判斷擁塞風(fēng)險(xiǎn)，TIMELY使用RTT增加來(lái)檢測(cè)擁塞。兩個(gè)算法都是在隊(duì)列建立后，發(fā)送方才開始降低流量，這些堆積的隊(duì)列會(huì)大大增加網(wǎng)絡(luò)延遲。

復(fù)雜的參數(shù)調(diào)整。例如，DCQCN有15個(gè)參數(shù)可以調(diào)整，操作員在日常RDMA網(wǎng)絡(luò)維護(hù)中要面對(duì)復(fù)雜且耗時(shí)的參數(shù)調(diào)整，這會(huì)大大增加配置錯(cuò)誤的風(fēng)險(xiǎn)，這些錯(cuò)誤配置會(huì)導(dǎo)致不穩(wěn)定或性能下降。

HPCC（High Precision Congestion Control，高精度擁塞控制）背后的關(guān)鍵思想是利用INT（In-Network Telemetry，網(wǎng)絡(luò)內(nèi)遙測(cè)）提供的精確的鏈路負(fù)載信息來(lái)計(jì)算準(zhǔn)確的流量更新，HPCC在大多數(shù)情況下僅需要一個(gè)速率更新步驟。HPCC發(fā)送方可以快速提高流量以實(shí)現(xiàn)高利用率，或者降低流量以避免擁塞；HPCC發(fā)送者可以快速調(diào)整流量，以使每個(gè)鏈接的輸入速率略低于鏈接的容量，保持高鏈接利用率；由于發(fā)送速率是根據(jù)交換機(jī)直接測(cè)量的結(jié)果精確計(jì)算得出的，HPCC僅需要3個(gè)獨(dú)立參數(shù)即可調(diào)整公平性和效率。

如圖6，HPCC實(shí)現(xiàn)為由發(fā)送者驅(qū)動(dòng)的擁塞控制框架。接收方確認(rèn)發(fā)送方發(fā)送的每個(gè)數(shù)據(jù)包。數(shù)據(jù)包從發(fā)送方傳輸?shù)浇邮辗降倪^(guò)程中，路徑上的每個(gè)交換機(jī)都利用INT功能插入一些元數(shù)據(jù)，這些數(shù)據(jù)報(bào)告了數(shù)據(jù)包出口的當(dāng)前負(fù)載。當(dāng)接收方收到數(shù)據(jù)包后，它將所有的元數(shù)據(jù)復(fù)制到ACK消息中。發(fā)送方根據(jù)ACK信息決定如何調(diào)整流量。

圖6 HPCC框架示意圖

圖7為基于FPGA可編程NIC上的HPCC實(shí)現(xiàn)，NIC提供了一個(gè)FPGA芯片，并且用了基礎(chǔ)的PCIe以及MAC模塊，PCIe連接到主機(jī)內(nèi)存，MAC模塊連接到以太網(wǎng)。HPCC模塊位于PCIe和MAC之間，實(shí)現(xiàn)發(fā)送方和接收方的角色。擁塞控制（CC）模塊實(shí)現(xiàn)了發(fā)送方擁塞控制算法，它接收RX方向返回的ACK信息，根據(jù)這些信息調(diào)整發(fā)送窗口和速率，并且更新新的發(fā)送窗口和速率到流量調(diào)度器。

圖7 支持HPCC的FPGA NIC實(shí)現(xiàn)

通過(guò)測(cè)試平臺(tái)實(shí)驗(yàn)和大規(guī)模仿真，與DCQCN、TIMELY等方案相比，HPCC對(duì)可用帶寬和擁塞的反應(yīng)更快，并保持接近零的隊(duì)列。在32臺(tái)服務(wù)器測(cè)試平臺(tái)中，在50％的流量負(fù)載下HPCC在中位數(shù)保持隊(duì)列大小為零，當(dāng)負(fù)載達(dá)到99%的情況下，隊(duì)列大小為22.9KB（僅需要7.3μs的排隊(duì)延遲）。與DCQCN相比，它使99％負(fù)載情況下的延遲減少了95％，而不會(huì)犧牲吞吐量。在320臺(tái)服務(wù)器的測(cè)試中，即使DCQCN和TIMELY方案頻繁發(fā)生PFC（Priority Flow Control，基于優(yōu)先級(jí)的流量控制）風(fēng)暴的情況下，HPCC也不會(huì)觸發(fā)PFC暫停。

c.AWS的SRD和EFA

EFA（Elastic Fabric Adapter，彈性互聯(lián)適配器）是AWS EC2實(shí)例的一種網(wǎng)絡(luò)接口，EFA性能改進(jìn)主要通過(guò)三項(xiàng)關(guān)鍵技術(shù)：

應(yīng)用程序繞過(guò)操作系統(tǒng)內(nèi)核直接與硬件對(duì)話，這提高了應(yīng)用程序性能的穩(wěn)定性；

持續(xù)開發(fā)和調(diào)整ENA和設(shè)備驅(qū)動(dòng)程序以適應(yīng)新的高帶寬實(shí)例類型；

新的以云為中心的可靠性協(xié)議層，稱為SRD（Scalable Reliable Datagram，可擴(kuò)展可靠數(shù)據(jù)報(bào)）。

如圖8，EFA定制的操作系統(tǒng)旁路硬件接口增強(qiáng)了實(shí)例間通信的性能。借助EFA，使用消息傳遞接口（MPI）的高性能計(jì)算（HPC）應(yīng)用程序和使用NVIDIA集體通信庫(kù)（NCCL）的機(jī)器學(xué)習(xí)（ML）應(yīng)用程序可以擴(kuò)展到數(shù)千個(gè)CPU或GPU，并且，將獲得本地HPC集群的應(yīng)用程序性能以及AWS云的按需彈性和靈活性。

圖8 基于EFA的HPC網(wǎng)絡(luò)協(xié)議棧

SRD是專為AWS設(shè)計(jì)的可靠的、高性能的、低延遲的網(wǎng)絡(luò)傳輸。這是數(shù)據(jù)中心網(wǎng)絡(luò)數(shù)據(jù)傳輸?shù)囊淮沃卮蟾倪M(jìn)，已實(shí)現(xiàn)為AWS第三代NITRO芯片的一個(gè)重要功能。SRD受InfiniBand可靠數(shù)據(jù)報(bào)的啟發(fā)，與此同時(shí)，考慮到大規(guī)模的云計(jì)算場(chǎng)景下的工作負(fù)載，SRD也經(jīng)過(guò)了很多的修改和改進(jìn)。SRD利用了云計(jì)算的資源和特點(diǎn)（例如AWS的復(fù)雜多路徑主干網(wǎng)絡(luò)）來(lái)支持新的傳輸策略，為其在緊耦合的工作負(fù)載中發(fā)揮價(jià)值。SRD的主要功能包括：

亂序交付：取消按順序傳遞消息的約束，消除了行首阻塞，AWS在EFA用戶空間軟件堆棧中實(shí)現(xiàn)了數(shù)據(jù)包重排序處理引擎。

等價(jià)多路徑路由（ECMP）:兩個(gè)EFA實(shí)例之間可能有數(shù)百條路徑，使用大型多路徑網(wǎng)絡(luò)的一致性流哈希的屬性，以及SRD對(duì)網(wǎng)絡(luò)狀況的快速反應(yīng)能力，找到消息的最有效路徑。數(shù)據(jù)包噴涂（Packet Spraying）可防止擁塞熱點(diǎn)，并可以從網(wǎng)絡(luò)故障中快速而無(wú)感地恢復(fù)。

快速的丟包響應(yīng)：SRD對(duì)丟包的響應(yīng)比任何高層級(jí)的協(xié)議都快得多。偶爾的數(shù)據(jù)包丟失是正常網(wǎng)絡(luò)操作的一部分，這不是異常情況。

可擴(kuò)展的傳輸卸載：使用SRD，與其他可靠協(xié)議（如InfiniBand可靠連接IBRC）不同，一個(gè)進(jìn)程可以創(chuàng)建并使用一個(gè)隊(duì)列對(duì)與任何數(shù)量的對(duì)等方進(jìn)行通信。

表1為SRD和TCP、InfiniBand網(wǎng)絡(luò)的功能特征對(duì)比：

表1 TCP、InfiniBand以及SRD的特征比較

如圖9所示，EFA非常明顯的提高了帶寬利用率（接近于線速100 Gbps），同時(shí)還明顯的減少單數(shù)據(jù)包延遲，并且基于SRD的鏈接失效的處理，其性能抖動(dòng)也變得非常的小。

(a) EFA的帶寬性能對(duì)比 (b) EFA的延遲性能對(duì)比

(c) SRD與TCP的性能抖動(dòng)對(duì)比

圖9 EFA/SRD的HPC性能

審核編輯 ：李倩