面向天河互連網(wǎng)絡(luò)的可擴(kuò)展通信框架實(shí)現(xiàn)技術(shù)

謝 旻，張 偉，周恩強(qiáng)，董 勇

(國(guó)防科技大學(xué)計(jì)算機(jī)學(xué)院,湖南 長(zhǎng)沙 410073)

1 引言

互連網(wǎng)絡(luò)是高性能計(jì)算機(jī)系統(tǒng)的重要組成部分，其性能指標(biāo)對(duì)并行應(yīng)用的運(yùn)行效率有重要影響。并行應(yīng)用的開(kāi)發(fā)和運(yùn)行依賴(lài)各種并行編程模型，例如消息傳遞并行編程模型MPI(Message Passing Interface)和PGAS(Partitioned Global Address Space)等。通常每個(gè)互連網(wǎng)絡(luò)平臺(tái)上都會(huì)提供自定義的通信編程接口，并直接基于這些接口實(shí)現(xiàn)并行編程模型，以充分發(fā)揮互連網(wǎng)絡(luò)性能。但是，這種開(kāi)發(fā)模式需要花費(fèi)很多時(shí)間和人力成本，造成部分編程模型不能在新型互連網(wǎng)絡(luò)平臺(tái)上得到及時(shí)和高效的支持，而且在不同互連平臺(tái)上的編程模型移植需要進(jìn)行一些軟件棧代碼的重寫(xiě)，不能很好地實(shí)現(xiàn)代碼重用。在當(dāng)前互連網(wǎng)絡(luò)和體系結(jié)構(gòu)技術(shù)快速發(fā)展的條件下，這種開(kāi)發(fā)模式面臨很多的挑戰(zhàn)。

因此，高性能計(jì)算社區(qū)協(xié)同發(fā)展了幾個(gè)開(kāi)源的通信框架研究項(xiàng)目，其目標(biāo)是定義滿足主流并行編程模型需求的標(biāo)準(zhǔn)化統(tǒng)一通信編程接口，同時(shí)又便于高效地在各種互連網(wǎng)絡(luò)平臺(tái)上實(shí)現(xiàn)，以便更好地在當(dāng)今和未來(lái)互連網(wǎng)絡(luò)上支持各種編程模型。主要的通信框架包括UCX(Unified Communication X)[1]、OFI(Open Fabrics Interfaces)[2]、CCI(Common Communication Interface)[3]等。UCX和OFI已被移植實(shí)現(xiàn)到很多高性能互連網(wǎng)絡(luò)上，例如InfiniBand、BlueGene/Q、Cray Gemini/Aries等。很多并行編程模型的實(shí)現(xiàn)系統(tǒng)，例如MPI的MPICH[4]和Open MPI[5]等，也有了基于UCX和OFI的實(shí)現(xiàn)，積累了可直接移植的軟件資源。另外，很多高性能并行計(jì)算機(jī)系統(tǒng)中也開(kāi)始運(yùn)行一些大數(shù)據(jù)或人工智能計(jì)算框架，這些計(jì)算框架通常利用TCP/IP協(xié)議的socket接口實(shí)現(xiàn)分布式任務(wù)之間的通信，以便提高可移植性，但這帶來(lái)了通信性能損失，因此一些計(jì)算框架也開(kāi)始嘗試基于開(kāi)源通信框架來(lái)提高性能。

天河互連網(wǎng)絡(luò)[6,7]是國(guó)防科技大學(xué)自主研制的高性能互連網(wǎng)絡(luò)系統(tǒng)，在“天河二號(hào)”等高性能并行計(jì)算機(jī)系統(tǒng)中得到了應(yīng)用，具有同期國(guó)際先進(jìn)水平的網(wǎng)絡(luò)通信性能。目前通過(guò)天河互連網(wǎng)絡(luò)的自定義通信接口，實(shí)現(xiàn)了對(duì)幾個(gè)并行編程模型的高效支持。而本文的研究問(wèn)題是：在天河互連網(wǎng)絡(luò)上是否也能移植實(shí)現(xiàn)主流開(kāi)源通信框架，并提供高性能的數(shù)據(jù)傳輸服務(wù)，支持多種編程模型，以及并行應(yīng)用的可擴(kuò)展運(yùn)行？由于天河互連網(wǎng)絡(luò)研制的技術(shù)積累也是未來(lái)E級(jí)并行計(jì)算機(jī)系統(tǒng)互連網(wǎng)絡(luò)的基礎(chǔ)，研究開(kāi)源通信框架在天河互連網(wǎng)絡(luò)上的實(shí)現(xiàn)技術(shù)，以及在其之上運(yùn)行各種編程模型所獲得的測(cè)試數(shù)據(jù)，對(duì)擴(kuò)展天河互連網(wǎng)絡(luò)上的應(yīng)用類(lèi)型，指導(dǎo)未來(lái)E級(jí)互連網(wǎng)絡(luò)和通信軟件系統(tǒng)的設(shè)計(jì)，都具有重要的研究意義。

本文主要結(jié)構(gòu)如下所示：第2節(jié)對(duì)開(kāi)源通信框架UCX和OFI的系統(tǒng)結(jié)構(gòu)，以及通信接口的類(lèi)型和功能進(jìn)行了對(duì)比說(shuō)明；第3節(jié)簡(jiǎn)要介紹了天河互連網(wǎng)絡(luò)的通信機(jī)制和自定義通信接口；第4節(jié)詳細(xì)描述了利用天河互連網(wǎng)絡(luò)自定義通信接口，為實(shí)現(xiàn)通信框架的主要通信操作接口而設(shè)計(jì)與實(shí)現(xiàn)的多通道數(shù)據(jù)傳輸協(xié)議；第5節(jié)是UCX和OFI的對(duì)象模型在天河互連網(wǎng)絡(luò)上的實(shí)現(xiàn)細(xì)節(jié)；第6節(jié)是天河互連網(wǎng)絡(luò)上的通信框架性能測(cè)試結(jié)果。第7節(jié)總結(jié)了全文工作。

2 開(kāi)源通信框架

UCX和OFI開(kāi)源通信框架均基于Internet協(xié)作開(kāi)發(fā)模式，其系統(tǒng)結(jié)構(gòu)和接口功能的設(shè)計(jì)，都是以先前一些通信接口研究項(xiàng)目的成果為基礎(chǔ)，充分考慮了各種并行編程模型的需求，以及面向當(dāng)前和未來(lái)各種互連網(wǎng)絡(luò)平臺(tái)實(shí)現(xiàn)的可移植性和擴(kuò)展性。

2.1 UCX通信框架

UCX的主要設(shè)計(jì)目標(biāo)包括可移植性，面向未來(lái)互連和體系結(jié)構(gòu)的支持能力，以及產(chǎn)品級(jí)質(zhì)量的實(shí)現(xiàn)代碼等。UCX采用如圖1所示的層次式系統(tǒng)結(jié)構(gòu)，主要包括3個(gè)組成部分，UCP(UC-Protocol)、UCT(UC-Transports)和UCS(UC-Services)層。每個(gè)層次都定義了一組編程接口API，并且是以單獨(dú)的庫(kù)形式提供給用戶使用，用戶可以根據(jù)自己的需求，靈活選擇不同層次的UCX接口來(lái)完成通信功能。

Figure 1 Architecture of UCX圖1 UCX系統(tǒng)結(jié)構(gòu)

UCS層提供可移植的系統(tǒng)環(huán)境訪問(wèn)控制接口，以及一些公共數(shù)據(jù)結(jié)構(gòu)和操作接口等，用于支持UCT和UCP層的實(shí)現(xiàn)。UCT作為傳輸層，面向互連網(wǎng)絡(luò)平臺(tái)的移植需求，定義了一組適用于各種互連網(wǎng)絡(luò)特性的基本通信接口和內(nèi)存管理操作，目標(biāo)是通過(guò)對(duì)互連接口硬件資源的直接訪問(wèn)操作，減少軟件層開(kāi)銷(xiāo)。UCT的通信操作主要包括AM(Active Message)和RMA(Remote Memory Access)2種，并且在AM和RMA接口中又區(qū)分?jǐn)?shù)據(jù)長(zhǎng)度定義了不同的接口，分別對(duì)應(yīng)直接短數(shù)據(jù)傳輸、帶數(shù)據(jù)拷貝的傳輸和零拷貝傳輸模式。另外，UCT層也定義了原子操作和Tag消息接口，可以通過(guò)在一些新型具有通信卸載功能的互連網(wǎng)絡(luò)上直接實(shí)現(xiàn)這些接口，來(lái)優(yōu)化UCP層接口的實(shí)現(xiàn)。UCP層接口的定義則面向編程模型的需求，提供Tag消息傳輸、RMA操作和原子操作等。UCP層接口基于UCT層接口來(lái)實(shí)現(xiàn)，但由于特定互連平臺(tái)上UCT層接口的類(lèi)型和傳輸能力差異，因此在運(yùn)行時(shí)UCP層會(huì)通過(guò)不同的通信協(xié)議來(lái)完成數(shù)據(jù)傳輸。例如，如果UCT層只實(shí)現(xiàn)AM和RMA接口，則UCP層的Tag消息傳輸接口對(duì)短消息是直接通過(guò)UCT層AM接口來(lái)傳輸數(shù)據(jù)，而對(duì)長(zhǎng)消息則采用Rendezvous協(xié)議，先通過(guò)AM操作進(jìn)行發(fā)送和接收方之間的協(xié)同和緩沖區(qū)信息交換，再調(diào)用RMA接口完成數(shù)據(jù)傳輸。

2.2 OFI通信框架

OFI由OpenFabrics Alliance發(fā)起，其設(shè)計(jì)目標(biāo)是為多種不同的高速互連定義一個(gè)抽象的新通信編程接口，覆蓋各種互連的主要功能特性，既能夠貼近應(yīng)用的需求，同時(shí)又不會(huì)影響面向特定互連的實(shí)現(xiàn)優(yōu)化。

OFI的總體結(jié)構(gòu)如圖2所示，定義了MSG消息傳輸、Tag消息傳輸、RMA通信操作和原子操作等數(shù)據(jù)傳輸接口。MSG消息傳輸是2個(gè)通信端點(diǎn)間維護(hù)消息數(shù)據(jù)邊界的順序數(shù)據(jù)傳輸，而Tag消息傳輸則是在MSG基礎(chǔ)上加入了基于Tag的消息選擇接收。OFI定義了EP_DGRAM、EP_MSG和EP_RDM這幾種不同的通信端點(diǎn)類(lèi)型，分別對(duì)應(yīng)無(wú)連接不可靠報(bào)文、有連接可靠消息和無(wú)連接可靠報(bào)文通信模式，每種通信端點(diǎn)上能支持的接口也不同。不同于UCX的明確分層結(jié)構(gòu)，OFI的接口是由各個(gè)Provider直接實(shí)現(xiàn)的。Provider又區(qū)分為Core和Utility 2類(lèi)，每個(gè)Core Provider直接對(duì)應(yīng)一個(gè)互連平臺(tái)，但基于互連網(wǎng)絡(luò)的功能特性，可以選擇只實(shí)現(xiàn)部分OFI接口。而Utility Provider則通過(guò)軟件層的協(xié)議仿真操作為Core Provider添加一些其它未實(shí)現(xiàn)的接口功能[8]，例如RXD為只支持EP_DGRAM端點(diǎn)的Core Provider增加了對(duì)EP_RDM端點(diǎn)和相應(yīng)的Tag消息傳輸接口等的支持，而RXM為只支持EP_MSG端點(diǎn)的Core Provider增加了對(duì)EP_RDM端點(diǎn)和相對(duì)應(yīng)通信接口的支持。

Figure 2 Architecture of OFI圖2 OFI系統(tǒng)結(jié)構(gòu)

2.3 UCX和OFI通信框架對(duì)比

從定義的通信接口功能來(lái)看，UCX和OFI還是相類(lèi)似的，例如二者都包括基于Tag的消息傳輸、RMA遠(yuǎn)程內(nèi)存訪問(wèn)和遠(yuǎn)程原子操作等，而且UCX和OFI都支持非阻塞模式通信操作，并提供了通信推進(jìn)接口，這有助于利用互連平臺(tái)特性，實(shí)現(xiàn)計(jì)算與通信重疊執(zhí)行。但是，UCX對(duì)編程模型提供的是抽象程度高的UCP層接口，即使因?yàn)榛ミB網(wǎng)絡(luò)的功能限制無(wú)法支持全部UCT層接口，在UCP層也可以通過(guò)軟件層的協(xié)議操作，來(lái)完成UCP層的全部數(shù)據(jù)傳輸語(yǔ)義。而OFI的接口由Provider直接實(shí)現(xiàn)，因此在不同互連網(wǎng)絡(luò)平臺(tái)上的接口類(lèi)型、功能和參數(shù)限制等差異情況，都直接展現(xiàn)給編程模型，這既帶來(lái)了靈活性，也帶來(lái)了實(shí)現(xiàn)復(fù)雜性[9]。

UCX和OFI的接口抽象層次和功能差別，對(duì)其上編程模型的實(shí)現(xiàn)帶來(lái)了一定的影響。例如，在MPICH的CH4設(shè)備抽象層[10]中包含基于OFI和UCX的2個(gè)網(wǎng)絡(luò)傳輸模塊。在UCX模塊中，由于UCP層接口是與互連網(wǎng)絡(luò)的功能特性無(wú)關(guān)的完整接口，MPI的點(diǎn)點(diǎn)消息傳遞語(yǔ)義基本上可以直接對(duì)應(yīng)UCP的Tag消息傳輸接口，因此MPI的消息傳遞接口被直接轉(zhuǎn)換為對(duì)UCP層Tag消息傳輸接口的函數(shù)調(diào)用來(lái)完成，這極大地簡(jiǎn)化了CH4層代碼。而在OFI模塊中，由于運(yùn)行時(shí)OFI選擇的Provider可能展現(xiàn)出不同的端點(diǎn)類(lèi)型和數(shù)據(jù)傳輸接口能力，因此OFI模塊在初始化時(shí)會(huì)依據(jù)獲取的Provider屬性參數(shù)，按消息長(zhǎng)度范圍，使用OFI的不同接口實(shí)現(xiàn)Eager和Rendezvous消息數(shù)據(jù)傳輸協(xié)議完成數(shù)據(jù)傳輸，代碼的復(fù)雜性明顯高于UCX模塊的。

在面向互連網(wǎng)絡(luò)平臺(tái)的可移植性方面，UCX內(nèi)部提供了很多有用的數(shù)據(jù)結(jié)構(gòu)和操作接口，例如內(nèi)存緩沖池的分配管理接口、注冊(cè)內(nèi)存Cache機(jī)制、Hash函數(shù)接口、鏈表操作和指針數(shù)組等，有助于運(yùn)行時(shí)減少資源消耗，提高可擴(kuò)展性。OFI也有類(lèi)似的數(shù)據(jù)結(jié)構(gòu)和操作接口，但部分接口的靈活性和功能弱于UCX的實(shí)現(xiàn)，例如對(duì)內(nèi)存緩沖池的分配管理等。另外，UCX還包含對(duì)GPU等計(jì)算加速器的支持，支持在CPU和GPU之間的數(shù)據(jù)傳輸，OFI目前還缺乏對(duì)此的支持。

3 天河互連網(wǎng)絡(luò)和通信接口

天河互連網(wǎng)絡(luò)由2個(gè)ASIC專(zhuān)用芯片組成，一個(gè)是結(jié)點(diǎn)內(nèi)的主機(jī)接口NIC(Network Interface Chip)，為各種系統(tǒng)和應(yīng)用軟件提供互連通信服務(wù)；另一個(gè)是NRC(Network Router Chip)，采用高階路由結(jié)構(gòu)，可以構(gòu)建結(jié)點(diǎn)間光電混合的互連拓?fù)浣Y(jié)構(gòu)和交換網(wǎng)絡(luò)。

NIC支持完全用戶級(jí)通信技術(shù)，通過(guò)一種虛端口機(jī)制，允許多個(gè)進(jìn)程在用戶空間受保護(hù)地并發(fā)訪問(wèn)通信硬件資源，在關(guān)鍵通信路徑旁路操作系統(tǒng)的介入和數(shù)據(jù)拷貝操作，簡(jiǎn)化通信協(xié)議。NIC支持無(wú)連接可靠通信模式，虛端口間只要獲取對(duì)方地址，即可進(jìn)行MP短報(bào)文傳輸和RDMA通信操作。并且NIC內(nèi)部有多個(gè)數(shù)據(jù)傳輸引擎，通過(guò)并發(fā)執(zhí)行通信操作來(lái)提高數(shù)據(jù)傳輸效率。MP短報(bào)文傳輸是無(wú)連接多對(duì)一的報(bào)文數(shù)據(jù)傳輸，所有到達(dá)虛端口的MP短報(bào)文在一條MPQ短報(bào)文隊(duì)列中順序排隊(duì)等待接收處理。RDMA通信操作是單邊通信模式，通信發(fā)起方設(shè)定源和目的緩沖區(qū)地址和長(zhǎng)度信息，源和目的虛端口之間直接以遠(yuǎn)程DMA方式讀寫(xiě)緩沖區(qū)數(shù)據(jù)來(lái)完成數(shù)據(jù)傳輸。NIC內(nèi)部設(shè)計(jì)實(shí)現(xiàn)了地址變換機(jī)制，使得RDMA可以直接傳輸用戶進(jìn)程地址空間虛地址連續(xù)而物理地址不連續(xù)的數(shù)據(jù)緩沖區(qū)。

天河互連網(wǎng)絡(luò)的NIC自定義實(shí)現(xiàn)了一個(gè)GLEX(GaLaxy EXpress)通信接口，對(duì)NIC的硬件功能與通信機(jī)制進(jìn)行直接的抽象封裝，進(jìn)程在GLEX接口中通過(guò)直接控制訪問(wèn)NIC硬件資源來(lái)完成通信操作，具有很低的軟件層開(kāi)銷(xiāo)。GLEX提供了基于端點(diǎn)(對(duì)應(yīng)NIC的虛端口)的MP短報(bào)文傳輸操作、RDMA通信操作(支持Put/Get 2種模式)和面向RDMA的內(nèi)存注冊(cè)管理接口等。通信操作是非阻塞模式，通過(guò)一組事件接口來(lái)檢測(cè)通信操作的完成狀態(tài)，以方便實(shí)現(xiàn)計(jì)算與通信操作的重疊執(zhí)行。

4 面向通信框架數(shù)據(jù)傳輸服務(wù)的多通道通信協(xié)議

從第2節(jié)的通信框架對(duì)比分析中可以看出，在通信框架面向新型互連網(wǎng)絡(luò)平臺(tái)需要移植實(shí)現(xiàn)的接口中，消息傳輸和RMA單邊通信是其中2類(lèi)最主要的數(shù)據(jù)傳輸服務(wù)，因此在天河互連網(wǎng)絡(luò)上實(shí)現(xiàn)通信框架需要解決的主要技術(shù)問(wèn)題，就是如何設(shè)計(jì)與實(shí)現(xiàn)基于GLEX通信接口的高性能數(shù)據(jù)傳輸協(xié)議，來(lái)完成通信框架的消息傳輸和RMA單邊通信操作功能。

通信框架的消息傳輸服務(wù)是維護(hù)了消息數(shù)據(jù)邊界的可變長(zhǎng)度數(shù)據(jù)傳輸方式,GLEX通信接口的MP短報(bào)文傳輸也是一種消息傳輸方式，但一次傳輸?shù)臄?shù)據(jù)量很少。GLEX的RDMA接口雖然支持進(jìn)程緩沖區(qū)之間的高速塊數(shù)據(jù)傳輸，直接對(duì)應(yīng)通信框架的RMA接口功能，但是在傳輸消息數(shù)據(jù)前，需要預(yù)先獲取發(fā)送和接收消息緩沖區(qū)的描述信息。因此，本文設(shè)計(jì)了多種結(jié)合MP短報(bào)文傳輸和RDMA通信操作的通信協(xié)議，來(lái)實(shí)現(xiàn)滿足通信框架可變長(zhǎng)度消息傳輸語(yǔ)義的高性能數(shù)據(jù)傳輸。

4.1 可擴(kuò)展可靠短報(bào)文通信協(xié)議

對(duì)通信框架的短數(shù)據(jù)消息傳輸操作，數(shù)據(jù)可以直接封裝在GLEX的MP短報(bào)文中完成傳輸。但是，由于虛端口的MPQ是面向所有發(fā)送方共享的MP短報(bào)文接收隊(duì)列，如果MP報(bào)文接收處理不及時(shí)，則MPQ存在溢出的可能性，會(huì)造成報(bào)文丟失?？紤]到并行應(yīng)用的規(guī)模和通信模式，可以有2種不同的可靠MP短報(bào)文傳輸協(xié)議設(shè)計(jì)原則。

一種是允許出現(xiàn)MPQ溢出。但是，這需要在發(fā)送方和接收方之間實(shí)現(xiàn)滑動(dòng)窗口重傳機(jī)制，在出現(xiàn)接收方MPQ溢出時(shí)，通過(guò)發(fā)送方重傳操作實(shí)現(xiàn)MP短報(bào)文傳輸?shù)目煽啃?。這種傳輸協(xié)議為重傳而進(jìn)行的MP報(bào)文管理較為復(fù)雜，還需要引入超時(shí)機(jī)制，實(shí)現(xiàn)開(kāi)銷(xiāo)較大。

另一種則是避免MPQ溢出的通信協(xié)議。本文設(shè)計(jì)了一種動(dòng)態(tài)信用流控機(jī)制，設(shè)計(jì)思路是為發(fā)送方預(yù)先分配發(fā)送信用，防止MPQ溢出，但每個(gè)發(fā)送方的發(fā)送信用可以按任務(wù)間通信密集度動(dòng)態(tài)調(diào)整。每個(gè)虛端口的MPQ的所有單元在初始化時(shí)被分成2個(gè)部分：一部分是為每個(gè)發(fā)送方預(yù)留的少量初始發(fā)送信用單元，而另一部分則是作為動(dòng)態(tài)信用單元擴(kuò)展池。發(fā)送方消耗一個(gè)發(fā)送信用，才能向目的方發(fā)送一個(gè)MP短報(bào)文，而接收方會(huì)在反方向數(shù)據(jù)傳輸時(shí)順帶回填信用，或在檢測(cè)到發(fā)送方信用耗盡時(shí)主動(dòng)回填信用。如果發(fā)送方密集發(fā)送數(shù)據(jù)，則有可能耗盡發(fā)送信用，此時(shí)可以觸發(fā)設(shè)置信用請(qǐng)求標(biāo)記，在后續(xù)的短報(bào)文傳輸中攜帶，接收方在處理MP短報(bào)文看到該標(biāo)記時(shí)，就會(huì)從動(dòng)態(tài)信用單元擴(kuò)展池中申請(qǐng)一些單元反饋給發(fā)送方，這樣就可以動(dòng)態(tài)增加發(fā)送方信用，確保頻繁通信的任務(wù)之間可以使用更多MPQ單元。這種通信協(xié)議軟件層開(kāi)銷(xiāo)低，因此在通信框架中用于實(shí)現(xiàn)結(jié)點(diǎn)間可靠MP短報(bào)文傳輸。

4.2 共享RDMA通道(SR)通信協(xié)議

對(duì)較長(zhǎng)消息數(shù)據(jù)的傳輸，可以切分成多次可靠短報(bào)文傳輸操作來(lái)完成，但傳輸效率較低，因此可以考慮使用RDMA通信來(lái)傳輸消息數(shù)據(jù)。但是，RDMA是單邊通信，要求預(yù)先交換發(fā)送方和接收方消息數(shù)據(jù)區(qū)信息，并且消息數(shù)據(jù)被內(nèi)存注冊(cè)鎖定后才能進(jìn)行RDMA傳輸，這是一個(gè)高開(kāi)銷(xiāo)的操作系統(tǒng)內(nèi)核級(jí)操作。對(duì)一定長(zhǎng)度范圍內(nèi)的數(shù)據(jù)，CPU的數(shù)據(jù)拷貝開(kāi)銷(xiāo)低于內(nèi)存注冊(cè)操作，因此本文設(shè)計(jì)了結(jié)合數(shù)據(jù)拷貝與RDMA通信流水執(zhí)行的通信協(xié)議，來(lái)實(shí)現(xiàn)可變長(zhǎng)度的消息傳輸。

在發(fā)送方和接收方都預(yù)先設(shè)置一組固定長(zhǎng)度的緩沖單元，這些單元被內(nèi)存注冊(cè)鎖定組成RDMA緩沖池。在消息傳輸操作中，發(fā)送方的消息數(shù)據(jù)按長(zhǎng)度被拷貝到一個(gè)或多個(gè)緩沖池單元中，然后先通過(guò)前述可靠短報(bào)文傳輸協(xié)議，將發(fā)送方緩沖單元的地址和長(zhǎng)度信息傳輸?shù)浇邮辗?，接收方收到MP短報(bào)文后也在本地RDMA緩沖池中分配對(duì)應(yīng)數(shù)目的單元，然后啟動(dòng)RDMA Get操作在發(fā)送方和接收方對(duì)應(yīng)的緩沖池單元間傳輸數(shù)據(jù)。RDMA傳輸完成后在雙方都觸發(fā)通知事件，發(fā)送方處理事件回收緩沖池單元，而接收方處理事件則將數(shù)據(jù)從RDMA緩沖池拷貝到接收消息緩沖區(qū)，然后再回收緩沖池單元。可以看出，這是通過(guò)發(fā)送方和接收方的數(shù)據(jù)拷貝，再結(jié)合RDMA數(shù)據(jù)傳輸來(lái)仿真的消息傳輸語(yǔ)義，但多組消息傳輸操作中的數(shù)據(jù)拷貝，以及MP和RDMA通信是流水重疊執(zhí)行的，以便提高傳輸效率。

由于這是由接收方啟動(dòng)的RDMA數(shù)據(jù)傳輸，多對(duì)一消息傳輸下的RDMA緩沖池單元競(jìng)爭(zhēng)由接收方解決，因此該通信協(xié)議中的RDMA緩沖池可以共享用于和所有其它任務(wù)之間的通信，成為每個(gè)任務(wù)和其它所有任務(wù)間消息通信的共享通道。

4.3 獨(dú)占RDMA通道(ER)通信協(xié)議

共享RDMA通道通信協(xié)議需要MP和RDMA Get 2個(gè)階段的操作才能完成消息數(shù)據(jù)傳輸，這樣增加了通信延遲。而RDMA Put操作可以直接將數(shù)據(jù)從發(fā)送方傳輸?shù)浇邮辗?，但如何協(xié)調(diào)雙方消息數(shù)據(jù)區(qū)的地址和長(zhǎng)度信息是需要解決的技術(shù)問(wèn)題。

本文設(shè)計(jì)了如圖3所示的一種基于RDMA Put的消息傳輸協(xié)議。發(fā)送方和接收方各預(yù)先在內(nèi)存注冊(cè)一個(gè)同樣長(zhǎng)度的RDMA緩沖區(qū)，通過(guò)RDMA Put操作將這2個(gè)RDMA緩沖區(qū)構(gòu)造成一個(gè)發(fā)送方管理的遠(yuǎn)程FIFO結(jié)構(gòu)。發(fā)送方消息數(shù)據(jù)被順序拷貝到發(fā)送方的RDMA緩沖區(qū)中，然后通過(guò)RDMA Put傳輸?shù)浇邮辗絉DMA緩沖區(qū)的相同位置，再利用遠(yuǎn)程事件通知接收方將數(shù)據(jù)從RDMA緩沖區(qū)拷貝到接收消息緩沖區(qū)中。對(duì)較短的消息數(shù)據(jù)傳輸，還可以使用立即數(shù)RDMA Put操作，這是一種將源數(shù)據(jù)嵌入RDMA通信描述符中的通信機(jī)制，具有更低的通信延遲。理論上，這種遠(yuǎn)程FIFO結(jié)構(gòu)可以按字節(jié)順序使用，但考慮到RDMA Put傳輸在對(duì)齊Cacheline邊界時(shí)效率更高，所以切分成Cacheline長(zhǎng)度的單元。每次消息傳輸按數(shù)據(jù)長(zhǎng)度使用連續(xù)數(shù)個(gè)單元，只有最后1個(gè)單元會(huì)浪費(fèi)少量?jī)?nèi)存未被使用。消息的第1個(gè)單元里面預(yù)留消息頭，在接收方消息頭里面的數(shù)據(jù)長(zhǎng)度域由RDMA Put遠(yuǎn)程事件來(lái)更新，這樣接收方可以獲知消息數(shù)據(jù)的長(zhǎng)度。多個(gè)消息傳輸對(duì)應(yīng)的數(shù)據(jù)拷貝和RDMA Put操作也是流水重疊執(zhí)行的，可以提高消息數(shù)據(jù)的傳輸帶寬。這種遠(yuǎn)程FIFO采用靜態(tài)流控機(jī)制，RDMA緩沖區(qū)切分出的Cacheline單元數(shù)就是最大發(fā)送信用值。接收方可以通過(guò)向發(fā)送方的反向消息傳輸操作順帶回填信用，或在接收處理了足夠的單元時(shí)觸發(fā)閾值，再主動(dòng)通過(guò)MP短報(bào)文回填信用。

Figure 3 Data transfer protocol of exclusive RDMA channel圖3 獨(dú)占RDMA通道消息傳輸協(xié)議

但是，因?yàn)檫@是發(fā)送方主導(dǎo)的數(shù)據(jù)傳輸協(xié)議，所以這種遠(yuǎn)程FIFO結(jié)構(gòu)只能成為2個(gè)特定發(fā)送方和接收方之間的獨(dú)占消息傳輸通道，是以通信內(nèi)存資源的消耗來(lái)?yè)Q取通信性能的提升的。

4.4 零拷貝RDMA通道(ZC)通信協(xié)議

共享和獨(dú)占RDMA通道傳輸協(xié)議因?yàn)榇嬖诎l(fā)送方和接收方的數(shù)據(jù)拷貝，所以會(huì)影響長(zhǎng)消息傳輸?shù)膸?，增加CPU的占用率。因此，可以采用Rendezvous協(xié)議傳輸長(zhǎng)消息，先對(duì)發(fā)送方和接收方的消息數(shù)據(jù)進(jìn)行內(nèi)存注冊(cè)，然后使用SR或ER通道完成雙方消息緩沖區(qū)地址和長(zhǎng)度信息交換，再利用RDMA Get或Put操作直接進(jìn)行消息數(shù)據(jù)的零拷貝傳輸。對(duì)消息傳輸完成的狀態(tài)檢測(cè)也是利用在發(fā)送方和接收方觸發(fā)的RDMA事件來(lái)實(shí)現(xiàn)，并且長(zhǎng)消息的順序處理和流控，也依賴(lài)于SR或ER通道的相應(yīng)處理來(lái)完成。而通信框架的RMA接口，也可以直接對(duì)應(yīng)到零拷貝RDMA通信操作。

RDMA操作前的內(nèi)存注冊(cè)過(guò)程是高開(kāi)銷(xiāo)的操作系統(tǒng)內(nèi)核級(jí)操作，但很多并行應(yīng)用通常會(huì)進(jìn)行消息和RMA數(shù)據(jù)緩沖區(qū)的重用，因此需要通過(guò)一個(gè)注冊(cè)Cache機(jī)制，將已注冊(cè)數(shù)據(jù)區(qū)的地址和長(zhǎng)度等信息緩存起來(lái)，并延遲解除內(nèi)存注冊(cè)的操作。這樣多次的RDMA數(shù)據(jù)傳輸如果仍然重復(fù)使用已注冊(cè)的內(nèi)存區(qū)域，就可以不再進(jìn)行內(nèi)存注冊(cè)相關(guān)操作，從而減少了開(kāi)銷(xiāo)。

4.5 面向可擴(kuò)展通信的組合通道消息傳輸

從上文可以看出，SR和ER通道有不同的性能特性和通信資源消耗，考慮到很多并行應(yīng)用會(huì)展現(xiàn)出近鄰?fù)ㄐ拍Ｊ絒11]，因此在通信框架的實(shí)現(xiàn)中，可以通過(guò)組合通道傳輸方式，在密集通信的并行任務(wù)間建立一組ER通道進(jìn)行消息傳輸，而其它任務(wù)間的消息傳輸則采用同一個(gè)SR通道來(lái)完成，這樣可以在確保并行應(yīng)用性能的前提下，減少通信資源內(nèi)存消耗，提高并行應(yīng)用的可擴(kuò)展性。

因?yàn)镚LEX采用非阻塞通信模式，因此需要專(zhuān)門(mén)的通信推進(jìn)過(guò)程推動(dòng)各個(gè)傳輸通道的消息處理。但是，GLEX接口中虛端口MPQ和事件隊(duì)列始終是MP短報(bào)文數(shù)據(jù)和通信操作狀態(tài)的單一輪詢點(diǎn)，和并行應(yīng)用的任務(wù)規(guī)模無(wú)關(guān)，而且在通信推進(jìn)過(guò)程的實(shí)現(xiàn)中，可以只將那些實(shí)際發(fā)生通信狀態(tài)變化的傳輸通道加入通信推進(jìn)處理流程中。在大規(guī)模并行應(yīng)用運(yùn)行時(shí)，這種單一輪詢點(diǎn)和動(dòng)態(tài)通道推進(jìn)方法有助于減少通信延遲，提高應(yīng)用運(yùn)行的擴(kuò)展性。

5 基于天河互連網(wǎng)絡(luò)的通信框架對(duì)象模型實(shí)現(xiàn)

雖然UCX和OFI的系統(tǒng)結(jié)構(gòu)不同，但都采用了面向?qū)ο蠹夹g(shù)的思想，在系統(tǒng)實(shí)現(xiàn)代碼中通過(guò)對(duì)象模型描述互連網(wǎng)絡(luò)資源，定義通信實(shí)體，以及提供各種服務(wù)接口。因此，在一個(gè)新型互連網(wǎng)絡(luò)上的實(shí)現(xiàn)，需要解決對(duì)象模型如何對(duì)應(yīng)到互連網(wǎng)絡(luò)硬件資源的技術(shù)問(wèn)題。本節(jié)將描述在天河互連網(wǎng)絡(luò)上實(shí)現(xiàn)UCX和OFI通信框架時(shí)，通信框架對(duì)象模型和互連網(wǎng)絡(luò)硬件資源的映射實(shí)現(xiàn)問(wèn)題。

5.1 基于天河互連網(wǎng)絡(luò)的UCX對(duì)象模型

基于天河互連網(wǎng)絡(luò)的UCX實(shí)現(xiàn)集中于UCT層接口的實(shí)現(xiàn)。如圖4所示，UCX的UCT層接口定義，是圍繞幾個(gè)抽象數(shù)據(jù)對(duì)象實(shí)現(xiàn)的各種通信操作。

Figure 4 UCT object model on GLEX圖4 基于GLEX的UCT對(duì)象模型

圖4中uct_md對(duì)象是內(nèi)存注冊(cè)域，用于對(duì)用戶數(shù)據(jù)緩沖區(qū)進(jìn)行內(nèi)存注冊(cè)管理；uct_worker對(duì)象是通信推進(jìn)引擎和資源上下文，用于推動(dòng)各種數(shù)據(jù)傳輸操作，以及在多線程間協(xié)同對(duì)通信資源的使用；uct_iface對(duì)象表示通信接口，基于一個(gè)uct_md和uct_worker對(duì)象創(chuàng)建，代表用戶進(jìn)程在互連接口上的一個(gè)入口點(diǎn)，用于接收處理到達(dá)的各種消息，UCT的所有通信接口也定義在uct_iface對(duì)象中?；趗ct_ifac對(duì)象，可以創(chuàng)建uct_ep對(duì)象，每個(gè)uct_ep對(duì)應(yīng)和一個(gè)遠(yuǎn)程uct_iface對(duì)象的通信連接，綁定遠(yuǎn)程uct_iface的地址信息。

基于天河互連網(wǎng)絡(luò)平臺(tái)實(shí)現(xiàn)時(shí)，因?yàn)镚LEX接口的端點(diǎn)glex_ep是用戶進(jìn)程對(duì)互連網(wǎng)絡(luò)接口的訪問(wèn)點(diǎn)，通過(guò)glex_ep可以進(jìn)行內(nèi)存注冊(cè)和全部無(wú)連接模式的通信操作，因此在創(chuàng)建uct_md對(duì)象時(shí)，會(huì)分配一個(gè)glex_ep，這樣和uct_md關(guān)聯(lián)的其它UCT對(duì)象都繼承使用這個(gè)glex_ep端點(diǎn)完成各種通信操作。所有的uct_ep都共享相同的glex_ep完成AM消息傳輸和RMA通信操作。uct_ep和遠(yuǎn)程uct_iface之間優(yōu)先嘗試使用ER通道傳輸協(xié)議進(jìn)行AM消息傳輸，只有在通信資源使用達(dá)到限額時(shí)，才轉(zhuǎn)為使用所有uct_ep共享的SR通道傳輸協(xié)議傳輸AM消息數(shù)據(jù)。零拷貝RMA接口則直接使用ZC通道傳輸協(xié)議來(lái)實(shí)現(xiàn)，UCS層提供了注冊(cè)Cache接口，可以減少內(nèi)存注冊(cè)開(kāi)銷(xiāo)。

由于MPI等并行編程模型假定并行任務(wù)間是全連接模式，因此基于UCX的MPICH等實(shí)現(xiàn)系統(tǒng)會(huì)在初始化時(shí)為COMM_WORLD通信器內(nèi)每個(gè)任務(wù)都建立一個(gè)uct_ep。為減少內(nèi)存開(kāi)銷(xiāo)，將uct_ep為實(shí)現(xiàn)ER或SR通道協(xié)議而維護(hù)的協(xié)議狀態(tài)和流控?cái)?shù)據(jù)結(jié)構(gòu)設(shè)置在另外的虛連接VC結(jié)構(gòu)中，只有在uct_ep進(jìn)行首次通信時(shí)才動(dòng)態(tài)創(chuàng)建，結(jié)合應(yīng)用的通信模式，可以顯著降低uct_ep對(duì)象的內(nèi)存消耗。而對(duì)所有uct_ep上通信操作狀態(tài)的跟蹤與處理，是通過(guò)uct_worker對(duì)象的通信推進(jìn)過(guò)程來(lái)完成的，通過(guò)推動(dòng)對(duì)glex_ep的MPQ和事件隊(duì)列的處理，完成所有uct_ep關(guān)聯(lián)的各種ER、SR和ZC通道傳輸協(xié)議。

總體來(lái)說(shuō)，由于UCX的UCT層的接口相對(duì)較少，而且UCS層提供了一些具有良好擴(kuò)展性的數(shù)據(jù)結(jié)構(gòu)和操作接口，例如mpool注冊(cè)內(nèi)存管理接口，可以用于ER或SR通道RDMA緩沖池的分配和管理，這都能簡(jiǎn)化UCT在天河互連網(wǎng)絡(luò)上的實(shí)現(xiàn)代碼。

5.2 基于天河互連網(wǎng)絡(luò)的OFI對(duì)象模型

OFI的對(duì)象模型如圖5所示，其中各個(gè)對(duì)象的詳細(xì)功能說(shuō)明可參考文獻(xiàn)[2]。雖然和UCX的UCT對(duì)象結(jié)構(gòu)不同，但OFI的domain和endpoint等對(duì)象的作用和UCX的uct_md和uct_ep相差不多。在OFI中domain也對(duì)應(yīng)于互連接口的一個(gè)入口點(diǎn)，注冊(cè)內(nèi)存的管理(Memory Regions)和通信完成狀態(tài)的檢測(cè)(Completion Queues/Counters)都通過(guò)domain進(jìn)行。因此，在天河互連網(wǎng)絡(luò)上，GLEX接口的端點(diǎn)glex_ep也是在domain對(duì)象創(chuàng)建時(shí)分配。而endpoint代表和一個(gè)遠(yuǎn)程實(shí)體通信的通信操作入口點(diǎn)，和UCX的uct_ep類(lèi)似，所有的endpoint共享domain對(duì)象的glex_ep完成全部通信操作。

Figure 5 OFI object model on GLEX圖5 基于GLEX的OFI對(duì)象模型

由于GLEX接口是無(wú)連接的可靠傳輸服務(wù)，因此可以實(shí)現(xiàn)OFI的無(wú)連接EP_DGRAM和EP_RDM端點(diǎn)類(lèi)型。OFI的MSG消息傳輸接口在運(yùn)行時(shí)也可以使用ER或SR通道傳輸協(xié)議來(lái)實(shí)現(xiàn)。但是，只有EP_RDM類(lèi)型的端點(diǎn)才能支持Tag消息傳輸和RMA操作。實(shí)現(xiàn)EP_RDM端點(diǎn)類(lèi)型有2種途徑：一是直接在Provider中實(shí)現(xiàn)，但是OFI沒(méi)有可重用的Tag消息傳輸協(xié)議代碼，需要Provider自己實(shí)現(xiàn)，代碼復(fù)雜性較高；二是只在Provider中實(shí)現(xiàn)EP_DGRAM端點(diǎn)類(lèi)型，然后利用OFI的RXD Utility Provider，通過(guò)軟件層仿真協(xié)議的方式實(shí)現(xiàn)EP_RDM端點(diǎn)類(lèi)型，以及Tag消息傳輸和RMA接口等，但這種形式的RMA接口目前是軟件仿真操作，不能直接對(duì)應(yīng)到互連網(wǎng)絡(luò)的RDMA傳輸接口，傳輸性能受到一定的影響。

目前在天河互連網(wǎng)絡(luò)上的OFI實(shí)現(xiàn)，采用了一種更為簡(jiǎn)化的實(shí)現(xiàn)方式，支持EP_RDM端點(diǎn)和Tag消息傳輸操作。使用UCX的UCP接口實(shí)現(xiàn)了一個(gè)Core Provider，將OFI的Tag消息轉(zhuǎn)化成UCP 的Tag消息傳輸操作來(lái)實(shí)現(xiàn)。這種方式只是初步的原型實(shí)現(xiàn)，還不能實(shí)現(xiàn)最優(yōu)的傳輸性能，后續(xù)將直接使用GLEX通信接口完善Core Provider的功能和實(shí)現(xiàn)代碼。

6 通信性能測(cè)試

本節(jié)對(duì)基于天河互連網(wǎng)絡(luò)的開(kāi)源通信框架進(jìn)行了性能測(cè)試，測(cè)試所用的天河互連網(wǎng)絡(luò)的端口速率是14 Gbps，結(jié)點(diǎn)CPU是Intel Xeon E5-2692，主頻2.2 GHz，結(jié)點(diǎn)主存64 GB，NIC互連接口通過(guò)PCIe 3.0 x16和結(jié)點(diǎn)CPU相連。

UCX和OFI的通信性能使用其自帶的性能測(cè)試程序進(jìn)行，由于基于GLEX的UCX實(shí)現(xiàn)較完善，而OFI還是初步原型實(shí)現(xiàn)，所以MPI測(cè)試使用MPICH3.3版本，在編譯時(shí)選擇CH4抽象設(shè)備接口和UCX網(wǎng)絡(luò)傳輸模塊，性能數(shù)據(jù)由OSU Micro Benchmarks測(cè)試集獲得。另外，也使用現(xiàn)有的天河MPI實(shí)現(xiàn)系統(tǒng)進(jìn)行性能對(duì)比，天河MPI也是以MPICH 3.3為基礎(chǔ)，但是通過(guò)CH3抽象設(shè)備層的Nemesis通道[12]接口實(shí)現(xiàn)的GLEX網(wǎng)絡(luò)模塊，主要的消息數(shù)據(jù)傳輸協(xié)議也是前述的ER/SR/ZC通道傳輸協(xié)議。由于CH3層是和互連網(wǎng)絡(luò)特性無(wú)關(guān)的抽象接口，基于CH3的MPI消息傳遞接口需要實(shí)現(xiàn)Eager和Rendezvous等通信協(xié)議[6,7]，還需要面向這些協(xié)議定義復(fù)雜的協(xié)議請(qǐng)求和應(yīng)答報(bào)文格式，實(shí)現(xiàn)代碼較為復(fù)雜。

圖6是最短長(zhǎng)度消息傳輸延遲的對(duì)比結(jié)果，這里列出了ER和SR 2種傳輸協(xié)議的延遲。在ER通道中作為基準(zhǔn)的GLEX延遲是使用立即數(shù)RDMA Put操作傳輸1 B數(shù)據(jù)的延遲，在SR通道中則是MP短報(bào)文傳輸1 B的延遲。UCT是AM接口傳輸8 B數(shù)據(jù)的延遲(這是UCX測(cè)試程序的限制)，UCP是Tag消息傳輸接口傳輸1 B數(shù)據(jù)的延遲，CH4-UCX則是MPI消息傳遞接口1 B數(shù)據(jù)的傳輸延遲，而OFI則是Tag消息的最低延遲。從測(cè)試結(jié)果可以看出，UCT層ER通道的最低延遲是0.89 μs，相對(duì)GLEX層增加的延遲少于200 ns。這些增加的開(kāi)銷(xiāo)來(lái)自于發(fā)送方和接收方的數(shù)據(jù)拷貝操作、RDMA描述符的構(gòu)造處理過(guò)程，以及AM協(xié)議消息的處理等。而在UCP層Tag消息傳輸接口的協(xié)議設(shè)計(jì)中，短消息傳輸基本上就是直接調(diào)用UCT層AM short接口完成的，只是在接收方有針對(duì)消息Tag的處理過(guò)程，而且UCP采用一種結(jié)合Hash技術(shù)的鏈表結(jié)構(gòu)進(jìn)行消息Tag的匹配處理優(yōu)化，所以UCP在UCT上只增加了約20 ns的延遲，最低延遲是0.91 μs。而在OFI的原型實(shí)現(xiàn)中，Tag消息傳輸接口在進(jìn)行參數(shù)檢查和目的地址查找后，就轉(zhuǎn)為UCP的Tag消息接口來(lái)完成，所以只增加約10 ns的延遲。而基于CH4層的MPI消息傳遞，除了基本的參數(shù)檢查和數(shù)據(jù)類(lèi)型轉(zhuǎn)換外，直接調(diào)用UCP的Tag消息傳輸接口進(jìn)行數(shù)據(jù)傳輸，最低延遲是0.95 μs，相對(duì)UCP層也只增加了很少的軟件層開(kāi)銷(xiāo)。

Figure 6 Comparison of message transfer latency圖6 消息傳輸延遲比較

圖7是MPI消息傳遞延遲的測(cè)試結(jié)果，CH4-ER-UCX是基于CH4層UCX網(wǎng)絡(luò)模塊的MPI延遲，使用ER通道協(xié)議，而CH4-SR-UCX則是SR通道協(xié)議的延遲。CH3-ER-GLEX是現(xiàn)有天河MPI中基于CH3層GLEX網(wǎng)絡(luò)模塊實(shí)現(xiàn)的ER通道協(xié)議延遲，CH3-SR-GLEX是SR通道協(xié)議的延遲。測(cè)試數(shù)據(jù)表明，即使存在數(shù)據(jù)拷貝操作，SR和ER通信協(xié)議傳輸短消息仍具有很低的延遲，并且基于CH4層接口的UCX網(wǎng)絡(luò)模塊MPI延遲，不管是ER通道協(xié)議還是SR通道協(xié)議，都優(yōu)于現(xiàn)有的基于CH3層的實(shí)現(xiàn)。CH4-ER-UCX的延遲是0.95 μs，而CH3-ER-GLEX的延遲是1.07 μs。延遲的降低來(lái)自于幾個(gè)方面：一是在CH4層的實(shí)現(xiàn)中，MPI的消息傳遞接口被直接轉(zhuǎn)化成了UCP的Tag消息接口函數(shù)調(diào)用，對(duì)應(yīng)很少的指令條數(shù)，并且也不再需要傳輸原來(lái)CH3層復(fù)雜的協(xié)議報(bào)文，在發(fā)送方和接收方都減少了內(nèi)存拷貝的數(shù)據(jù)量；二是通過(guò)使用UCP的Tag消息接口，MPI原來(lái)的消息信封匹配比對(duì)過(guò)程被簡(jiǎn)化為對(duì)Tag值的比對(duì)，UCP還通過(guò)結(jié)合Hash的鏈表結(jié)構(gòu)，提高了Tag消息匹配處理效率。本文也在天河互連網(wǎng)絡(luò)上測(cè)試了基于UCX的Open MPI，由于Open MPI模塊結(jié)構(gòu)也是通過(guò)一個(gè)簡(jiǎn)化的PML軟件層將MPI消息傳遞接口轉(zhuǎn)化成UCP的Tag消息接口，所以最低消息延遲和基于UCX的MPICH基本相當(dāng)。

Figure 7 Comparison of MPI message transfer latency圖7 MPI消息傳輸延遲比較

圖8是MPI消息傳遞帶寬的測(cè)試結(jié)果。在基于UCX的MPICH實(shí)現(xiàn)中，主要的數(shù)據(jù)傳輸協(xié)議都是在UCP的Tag消息接口中完成的。UCP的Tag消息接口，對(duì)短消息使用Eager協(xié)議，通過(guò)UCT層的AM接口直接傳輸消息數(shù)據(jù)。對(duì)長(zhǎng)消息則使用Rendezvous協(xié)議，先內(nèi)存注冊(cè)發(fā)送緩沖區(qū)，然后通過(guò)AM傳輸發(fā)送緩沖區(qū)地址和長(zhǎng)度信息，由接收方的AM處理函數(shù)內(nèi)存注冊(cè)接收緩沖區(qū)，再調(diào)用UCT層的RMA零拷貝接口完成消息數(shù)據(jù)的傳輸。CH3層基于GLEX的網(wǎng)絡(luò)模塊實(shí)現(xiàn)，是利用Nemesis通道的LMT接口，實(shí)現(xiàn)了類(lèi)似的傳輸流程。因此，在帶寬測(cè)試中，兩者的性能差別不大，都可以達(dá)到互連硬件峰值性能。但是，在短消息傳輸帶寬上，CH4層基于UCX的實(shí)現(xiàn)還是略好于CH3層基于GLEX的實(shí)現(xiàn)。從測(cè)試數(shù)據(jù)也可以看出，使用ER通道協(xié)議，短消息傳輸可以用更短的數(shù)據(jù)長(zhǎng)度實(shí)現(xiàn)1/2峰值帶寬，這也反映出本文設(shè)計(jì)的ER通信協(xié)議具有很低的軟件層實(shí)現(xiàn)開(kāi)銷(xiāo)。

Figure 8 Comparison of MPI message transfer bandwidth圖8 MPI消息傳輸帶寬比較

圖9是使用單處理器核基于ER通道傳輸協(xié)議的消息速率測(cè)試結(jié)果?？梢钥闯?，因?yàn)榛赨CX的MPI實(shí)現(xiàn)簡(jiǎn)化了軟件層開(kāi)銷(xiāo)，提高了網(wǎng)絡(luò)報(bào)文中有效消息數(shù)據(jù)的比率，所以相對(duì)現(xiàn)有的天河MPI實(shí)現(xiàn)，使用立即數(shù)RDMA Put的短消息傳輸速率有明顯提高，最高消息傳輸速率約為540萬(wàn)messages/s，而CH3層基于GLEX的實(shí)現(xiàn)最高傳輸速率約為380萬(wàn)messages/s。當(dāng)轉(zhuǎn)換為使用RDMA Put傳輸數(shù)據(jù)時(shí)，在128 B～4 KB范圍內(nèi)，基于CH3的MPI傳輸消息速率稍好。這是因?yàn)樵贑H3層的MPI實(shí)現(xiàn)中，ER通道協(xié)議可以自行根據(jù)消息數(shù)據(jù)長(zhǎng)度進(jìn)行發(fā)送數(shù)據(jù)的拷貝操作，這使得在RDMA緩沖區(qū)單元回繞處理過(guò)程中，可以更快地利用已有單元啟動(dòng)數(shù)據(jù)傳輸。而在UCT的ER通道協(xié)議實(shí)現(xiàn)中，數(shù)據(jù)拷貝是由AM接口參數(shù)中的打包函數(shù)完成的，打包函數(shù)調(diào)用完成時(shí)才能獲知數(shù)據(jù)長(zhǎng)度，所以RDMA緩沖區(qū)單元回繞處理的過(guò)程要更復(fù)雜一些，這對(duì)消息傳輸速率產(chǎn)生了一點(diǎn)影響。ER通道協(xié)議的最小傳輸單元長(zhǎng)度是Cacheline長(zhǎng)度，因此RDMA緩沖區(qū)的有效數(shù)據(jù)利用率還是比較高的，這使得ER通道可以用較短的RDMA緩沖區(qū)長(zhǎng)度，高效地支持變長(zhǎng)消息的數(shù)據(jù)傳輸。對(duì)一個(gè)大規(guī)模并行應(yīng)用來(lái)說(shuō)，在通信內(nèi)存資源使用上限范圍內(nèi)，可以在應(yīng)用中為并行任務(wù)間通信創(chuàng)建更多的ER通道，從而在保證并行應(yīng)用可擴(kuò)展性的前提下，確保任務(wù)間的數(shù)據(jù)傳輸性能。

Figure 9 Comparison of MPI message transfer rate圖9 MPI消息傳輸速率比較

7 結(jié)束語(yǔ)

開(kāi)源通信框架為在互連網(wǎng)絡(luò)平臺(tái)上提高各種并行編程模型的開(kāi)發(fā)效率，實(shí)現(xiàn)軟件代碼的重用提供了較好的解決方案。本文描述了UCX和OFI開(kāi)源通信框架在天河互連網(wǎng)絡(luò)上的實(shí)現(xiàn)技術(shù)，通過(guò)設(shè)計(jì)與實(shí)現(xiàn)多通道數(shù)據(jù)傳輸協(xié)議實(shí)現(xiàn)了通信框架的高性能通信服務(wù)，并通過(guò)組合通道傳輸技術(shù)提高了并行應(yīng)用的可擴(kuò)展性。雖然通信框架在天河互連網(wǎng)絡(luò)自定義通信接口上又增加了一個(gè)軟件層次，但編程模型的性能測(cè)試結(jié)果仍然展現(xiàn)出很低的軟件層開(kāi)銷(xiāo)。目前多種MPI和PGAS并行編程模型的實(shí)現(xiàn)系統(tǒng)均可以基于開(kāi)源通信框架在天河互連網(wǎng)絡(luò)上高效地運(yùn)行。開(kāi)源通信框架面向未來(lái)的E級(jí)并行計(jì)算平臺(tái)也做了很多針對(duì)性的設(shè)計(jì)，在天河互連網(wǎng)絡(luò)上實(shí)現(xiàn)通信框架的一些經(jīng)驗(yàn)將有助于指導(dǎo)未來(lái)對(duì)天河互連網(wǎng)絡(luò)的改進(jìn)工作，例如將更多的通信功能卸載到互連網(wǎng)絡(luò)接口自主執(zhí)行，可以獲取更好的通信性能，同時(shí)提高計(jì)算與通信重疊執(zhí)行能力。