謝 旻，張 偉，周恩強，董 勇

(國防科技大學計算機學院,湖南 長沙 410073)

1 引言

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

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

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

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

2 開源通信框架

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

2.1 UCX通信框架

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

Figure 1 Architecture of UCX圖1 UCX系統(tǒng)結構

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

2.2 OFI通信框架

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

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

Figure 2 Architecture of OFI圖2 OFI系統(tǒng)結構

2.3 UCX和OFI通信框架對比

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

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

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

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

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

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

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

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

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

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

4.1 可擴展可靠短報文通信協(xié)議

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

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

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

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

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

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

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

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

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

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

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

但是，因為這是發(fā)送方主導的數(shù)據(jù)傳輸協(xié)議，所以這種遠程FIFO結構只能成為2個特定發(fā)送方和接收方之間的獨占消息傳輸通道，是以通信內(nèi)存資源的消耗來換取通信性能的提升的。

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

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

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

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

從上文可以看出，SR和ER通道有不同的性能特性和通信資源消耗，考慮到很多并行應用會展現(xiàn)出近鄰通信模式[11]，因此在通信框架的實現(xiàn)中，可以通過組合通道傳輸方式，在密集通信的并行任務間建立一組ER通道進行消息傳輸，而其它任務間的消息傳輸則采用同一個SR通道來完成，這樣可以在確保并行應用性能的前提下，減少通信資源內(nèi)存消耗，提高并行應用的可擴展性。

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

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

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

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

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

Figure 4 UCT object model on GLEX圖4 基于GLEX的UCT對象模型

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

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

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

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

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

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

Figure 5 OFI object model on GLEX圖5 基于GLEX的OFI對象模型

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

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

6 通信性能測試

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

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

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

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

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

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

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

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

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

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

7 結束語

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