他來了 他來了 他帶著禮物過來了觉阅，只要跟網(wǎng)絡(luò)沾邊后 還是要看C家崖疤，C家中國研發(fā)中心繼RUTA協(xié)議后的又一力作 NetDAM，它對比了主機(jī)內(nèi)各種通信總線（PCIE/CXL）和主機(jī)之間通信的協(xié)議（以太網(wǎng)典勇、RDMA）之后劫哼，得出結(jié)論說要在網(wǎng)絡(luò)側(cè)添加內(nèi)存，并提供可編程指令集失陷SIMD訪問和計算加速割笙，在AI分布式訓(xùn)練場景中幾乎可以秒默全权烧。網(wǎng)絡(luò)廠商終于沖到了主機(jī)廠商的腹地眯亦，在CPU、GPU之后新的DPU的賽道上沖到了前列
簡介
傳統(tǒng)的馮諾依曼架構(gòu)中般码，計算單元和存儲單元是分離的妻率，因此大量的數(shù)據(jù)流動產(chǎn)生了內(nèi)存牆和馮諾依曼瓶頸
基于特殊領(lǐng)域的集成電路(DSA)被提出，大量的Offload卡被開發(fā)出來板祝，但是這些卡通信同樣需要超高帶寬和超低延遲的通信總線宫静，DPU開始關(guān)注并解決這個問題，但與此同時這樣的Offload架構(gòu)還增加了大量的成本券时，因此這是我們構(gòu)建NetDAM的一個原因
主機(jī)內(nèi)總線和主機(jī)間通信特征
PCIe作為主機(jī)內(nèi)(Intra-Host)各擴(kuò)展卡和CPU通信的標(biāo)準(zhǔn)已經(jīng)存在了接近20年孤里，基于PCIe的直接內(nèi)存訪問DMA也被廣泛的用于芯片間的通信. RDMA over Ethernet簡單的將DMA操作擴(kuò)展到了主機(jī)間(Inter-Host)通信網(wǎng)絡(luò)。但是go-back-N的策略對丟包非常敏感橘洞，因此DCQCN這一類基于PFC的可靠傳輸和擁塞控制機(jī)制被開發(fā)出來捌袜，但是隨著網(wǎng)絡(luò)規(guī)模增大及VPC等Overlay網(wǎng)絡(luò)架構(gòu)的出現(xiàn)，這樣的架構(gòu)將會帶來巨大的延遲和抖動炸枣。因此像Fungible一樣的廠商逐漸開始實(shí)現(xiàn)基于硬件TCP卸載的iWARP技術(shù)琢蛤，與此同時阿里巴巴的HPCC和Intel的NDP也被開發(fā)出來用于消除PFC帶來的影響。但與此同時抛虏，通過一些研究發(fā)現(xiàn)博其，PCIe本身由于RootComplex的設(shè)計和驅(qū)動的問題，也會帶來巨大的延遲迂猴，因此GenZ慕淡、CCIX、CXL等總線被開發(fā)出來用于解決這些問題沸毁。
但是我們重新審視了主機(jī)內(nèi)(Intra-Host)和主機(jī)間(Inter-Host)通信協(xié)議峰髓，主機(jī)內(nèi)通信由于延遲可控丟包可控通常采用共享內(nèi)存(share-memory)的模式，而主機(jī)間通信則通常采用消息傳遞(MPI)的方式息尺，因此兩者在設(shè)計原則上有根本性的不同：
拓?fù)洌褐鳈C(jī)內(nèi)通信協(xié)議通常是有固定的樹狀拓?fù)涞男⑶以O(shè)備編址和尋址相對固定(例如PCIe使用的DFS),消息路由相對簡單。而主機(jī)間通信協(xié)議通常是非固定的并且有多路徑支持和Overlay支持會使得報文調(diào)度更加複雜搂誉。當(dāng)然有一些片上網(wǎng)絡(luò)總線例如AMBA CHI可以實(shí)現(xiàn)多跳通信徐紧，這也是我們?yōu)槭颤N在處理器架構(gòu)中推薦基于ARM Neoverse2的Octeon CN10k的原因。但是CHI總線更多的用于片上網(wǎng)絡(luò)設(shè)計炭懊，對于跨芯片傳輸和跨主機(jī)有丟包和延遲的以太網(wǎng)傳輸則不適合并级。
延遲: 主機(jī)內(nèi)通信協(xié)議通常只有小于200ns的固定傳輸延遲，而主機(jī)間以太網(wǎng)通常為數(shù)個微秒的延遲侮腹，并由于包調(diào)度和多路徑及擁塞控制等原因會帶來不確定性.
丟包: 主機(jī)內(nèi)通信通常由于仲裁器和Credit Token調(diào)度通常不會出現(xiàn)丟包嘲碧，但是在主機(jī)間通信經(jīng)常由于擁塞或者中間節(jié)點(diǎn)失效導(dǎo)致丟包，實(shí)現(xiàn)不丟包的以太網(wǎng)代價巨大并且成本過高而且網(wǎng)絡(luò)利用率和複用率較低.
一致性：在主機(jī)內(nèi)通信由于往返延遲非常低父阻，因此通常采用基于MESI一類協(xié)議的緩存一致性協(xié)議實(shí)現(xiàn)共享內(nèi)存的通信愈涩。而在主機(jī)間高延遲的情況下實(shí)現(xiàn)一致性會非常困難望抽，也帶來了編程模式的挑戰(zhàn)。(注：可以參考OpenMP和OpenMPI在超算中的優(yōu)劣履婉。)
保序 : 通常主機(jī)內(nèi)通信為了內(nèi)存一致性是需要嚴(yán)格保序的糠聪，從物理實(shí)現(xiàn)上也相對容易，雖然PCIe也支持Relax Order但是用處并不是很大谐鼎。而主機(jī)間通信由于多路徑和一些網(wǎng)絡(luò)安全設(shè)備調(diào)度的因素亂序時常發(fā)生舰蟆。
傳輸報文大小 :由于主機(jī)內(nèi)通信實(shí)時性、低延遲和一致性的需求下狸棍，通常一個flit不會放的太大身害，大多數(shù)協(xié)議都最大維持到一個CacheLine(64B)的大小.再大會影響其它設(shè)備的實(shí)時通信，而且很多協(xié)議對于ACK草戈、NACK有嚴(yán)格的時序約束塌鸯，而以太網(wǎng)通常是1500B甚至9000B的傳輸
RDMA:直接擴(kuò)展主機(jī)內(nèi)總線
RDMA實(shí)際上是一種直接將主機(jī)內(nèi)DMA映射到以太網(wǎng)或者IB上的處理機(jī)制，同樣繼承了PCIe已有的go-back-N和QueuePair Credit機(jī)制唐片，但是由于主機(jī)側(cè)PCIe的原因會帶來一些Cache操作的復(fù)雜性和總線爭搶的不確定性丙猬，因此尾部延遲會非常高。同樣在以太網(wǎng)上由于Lossless的需求使得交換機(jī)和各種控制協(xié)議設(shè)計會變得復(fù)雜并進(jìn)一步加大了延遲
NanoPU:直接擴(kuò)展主機(jī)間總線
于是NanoPU走了另一個極端费韭，直接把主機(jī)間的總線懟到CPU上茧球，然后通過寄存器級別的操作實(shí)現(xiàn)了整個網(wǎng)絡(luò)協(xié)議棧的硬化處理。但這樣的架構(gòu)在過去數(shù)年中我們看到大量的網(wǎng)絡(luò)處理器廠商采用星持，針對復(fù)雜的應(yīng)用抢埋，特別是需要大量Branch和不確定性處理Cycles的應(yīng)用(100~10K cycles)時，這樣的架構(gòu)性能會出現(xiàn)極大的問題督暂。
分析對比下來揪垄，形象的說，就需要我們在主機(jī)的邊緣則構(gòu)建一個大壩逻翁，主機(jī)內(nèi)部如同峽谷流速高饥努，并且需要根據(jù)處理器的能力按需調(diào)度，大壩外面也就是主機(jī)間通信會經(jīng)常出現(xiàn)洪峰等情況八回。
這道大壩就是NetDAM酷愧，directly-attached memory 類似于OpenMP和OpenMPI混合使用的方式，在主機(jī)間使用消息傳遞(MPI)的方式采用JumboFrame大批量的調(diào)度的調(diào)度流量來隱藏延遲辽社，而在主機(jī)內(nèi)通過PCIe或者CXL讓處理器自行決定是否加載和進(jìn)行一致性處理
NetDAM架構(gòu)如上圖所示伟墙，我們將內(nèi)存加在了網(wǎng)卡上，并定義了可擴(kuò)展的指令集和大量的可編程邏輯用于近存計算和在網(wǎng)計算滴铅，當(dāng)然這個架構(gòu)以后也可以擴(kuò)展給Samsung的Process-In-Memory HBM使用，我們可以直接將指令發(fā)送到HBM內(nèi)讓內(nèi)存自己執(zhí)行一些操作就乓。因此主機(jī)內(nèi)通信接口可以使用PCIe汉匙、CXL拱烁，當(dāng)然也可以使用您自己的硬件電路邏輯在FPGA上，并通過AXI總線和NetDAM連接.
而通過內(nèi)存的映射噩翠，這樣的一套架構(gòu)構(gòu)建了一個統(tǒng)一的內(nèi)存訪問系統(tǒng)戏自，相較于以往的其它架構(gòu)可以更加便捷和經(jīng)濟(jì)的實(shí)現(xiàn)超大規(guī)模計算集群
NetDAM報文格式
NetDAM是一個基于包傳輸?shù)膮f(xié)議，無論在主機(jī)內(nèi)還是主機(jī)間通信伤锚，Payload具有相同的格式擅笔，其格式定義如下
Sequence: 字段主要用于包順序和可靠傳輸使用.
SegmentRouting Header: 主要是借鑒Ruta的工作，實(shí)現(xiàn)在數(shù)據(jù)中心內(nèi)部的多路徑擁塞避免屯援，與此同時也借助它實(shí)現(xiàn)了服務(wù)鏈(Service-Chain)的基于流的計算業(yè)務(wù)(Streaming Computation),通過Directed acyclic graph(DAG)很容易將計算業(yè)務(wù)分擔(dān)到各個節(jié)點(diǎn)猛们，并使用SR技術(shù)串聯(lián)在一起，具體我們在Ring AllReduce中會有一個詳細(xì)的案例
Instruction: 這是整個NetDAM的核心狞洋，直接將指令編碼放置在數(shù)據(jù)包中并和數(shù)據(jù)緊耦合在一起實(shí)現(xiàn)了以數(shù)據(jù)為中心的指令集架構(gòu)(Data-Centric ISA),NetDAM原始框架中提供了基本的
READ
WRITE
MEMCPY
及部分Atomic
原子操作.但是我們預(yù)留了8bits用于用戶可選擇的擴(kuò)展自己的指令集來支持不同的DSA或者不同的Serverless Function Call弯淘，例如將后續(xù)的地址段擴(kuò)展為Serverless的函數(shù)入口地址，這樣的架構(gòu)對于Serverless平臺具有極高的價值吉懊。
Address：這是指令操作的地址空間庐橙，根據(jù)不同的指令可以定義不同的地址，并且可以設(shè)計相應(yīng)的IOMMU來實(shí)現(xiàn)地址映射將遠(yuǎn)端的地址映射到本地或者在多個虛機(jī)和容器中映射地址借嗽，或者給Serverless實(shí)現(xiàn)虛擬的地址空間态鳖。
Data: Data字段域通常主要用于主機(jī)間通信，主機(jī)內(nèi)通信本來很多東西都在內(nèi)存上恶导，直接就能共享地址訪問郁惜，除非是需要Memory Copy的場景。通過這樣的方式實(shí)現(xiàn)9000B傳輸時甲锡，SIMD可以同時操作多大約2048個32位浮點(diǎn)數(shù)兆蕉，配合NetDAM自帶的ALU可以實(shí)現(xiàn)超大規(guī)模的并行計算，比現(xiàn)有處理器的AVX512處理器執(zhí)行效率高了數(shù)倍.
NetDAM傳輸層
在設(shè)計NetDAM傳輸層時缤沦，我們的原則是在提供超低延遲和超大帶寬的同時盡量減少對硬件的依賴虎韵，其實(shí)簡單來說就是避免使用IB或者特殊的串行結(jié)構(gòu)和特殊的可編程交換機(jī)，當(dāng)然可編程交換機(jī)可以輔助NetDAM實(shí)現(xiàn)分布式的MMU和內(nèi)存安全訪問控制缸废，這個在后續(xù)的章節(jié)會詳細(xì)介紹包蓝。結(jié)論 :我們采用了標(biāo)注的IP/UDP over Ethernet的方式來承載主機(jī)間的NetDAM通信。
確定性延遲: NetDAM具有固定的硬件流水線處理報文的讀寫企量，由于在主機(jī)間采用MPI的通信方式测萎，因此可以避免像PCIe那樣需要DMA和監(jiān)聽維持緩存一致性帶來的長尾延遲缺陷。我們測試了線-線(wire-to-wire)使用NetDAM從遠(yuǎn)端SIMD讀32個32位浮點(diǎn)數(shù)的操作届巩，平均延遲618納秒
,抖動39納秒
,最大延遲也就920ns
（注意硅瞧，我才不會用什么P99延遲麻痹自己). 這種確定性延遲對于擁塞控制非常有用，例如SWIFT就不用去測試主機(jī)處理延遲了恕汇，都固定的腕唧，underlay鏈路選擇好了整個路徑延遲就固定了或辖，簡單的流控加上去就夠了。
可靠傳輸：在NetDAM設(shè)計中枣接，可靠傳輸是可選的颂暇，因?yàn)橐环矫鎸?shí)現(xiàn)無丟包的以太網(wǎng)非常難，特別是在一些虛擬化環(huán)境中但惶，而另一方面很多分布式系統(tǒng)應(yīng)用層接口都具有冪等性耳鸯，因此我們沒有在NetDAM設(shè)計中把可靠傳輸作為必選，同時我們在后續(xù)的MPI Allreduce操作中也使用了冪等的處理方式來簡化故障恢復(fù)膀曾。但是正如前文所述县爬，由于確定性延遲的存在，可靠傳輸實(shí)現(xiàn)非常容易妓肢。
保序: 在很多并行計算中捌省，如果算子具有可交換性，因此就可以亂序執(zhí)行碉钠。由于我們在NetDAM中放置了地址和數(shù)據(jù)段長度的信息在地址空間上隔離了不同的內(nèi)存纲缓，因此在傳輸過程中的操作是完全可交換的。當(dāng)然報文頭部也提供了序列號的支持喊废，用戶也可以根據(jù)自己的計算任務(wù)構(gòu)建相應(yīng)的排序和順序執(zhí)行器件祝高。
多路徑: 許多數(shù)據(jù)中心都采用Fat-Tree的架構(gòu)，當(dāng)然也有很多超算也采用了2D-Torus和3D-Torus的架構(gòu)污筷，相對于超算而言工闺，Torus的架構(gòu)擴(kuò)展性和經(jīng)濟(jì)性都會好很多。因此NetDAM提供了基于Ruta的SegmentRouting over UDP方式瓣蛀，并且支持Service-Chaining的方式來實(shí)現(xiàn)分布式計算
可編程ISA
傳統(tǒng)的處理器架構(gòu)通常有固定的ISA陆蟆，例如X86、ARM惋增、MIPS等叠殷。RISC-V給我們帶來很多新的思路，提供基本的ISA的同時增加可選的ISA來實(shí)現(xiàn)不同DSA芯片诈皿。而NetDAM實(shí)現(xiàn)上也借鑒了這樣的做法林束，但是我們更像一個RPC調(diào)用，因?yàn)檫@樣對軟件更加友好并且完全與已有的CPU指令集無關(guān)稽亏。我們在內(nèi)存中放置了一個特定的區(qū)域構(gòu)建Queue Pair 用于DMA接收Request和放置Compelete信息壶冒， 主機(jī)內(nèi)由于指令攜帶部分操作數(shù)長度肯定小于一個CacheLine，因此可以很容易的構(gòu)建好一個結(jié)構(gòu)體發(fā)送給ReqQ和從CompleteQueue中接收ACK截歉，而主機(jī)間胖腾，我們可以根據(jù)內(nèi)存訪問地址自動封裝成UDP報文發(fā)送。在NetDAM的基礎(chǔ)模板框架中， 我們只提供了基本的
READ
WRITE
MEMCPY
及部分Atomic
原子操作胸嘁，剩下的留了數(shù)個bits給用戶自定義擴(kuò)展瓶摆，因此這樣的架構(gòu)精簡可選凉逛，并且可以實(shí)現(xiàn)Xilinx提出的Adaptive Comuting. 例如針對神經(jīng)網(wǎng)絡(luò)或者科學(xué)矩陣計算性宏，我們可以實(shí)現(xiàn)超大規(guī)模的SIMD(ADD, SUB,MUL, XOR, MIN, MAX)支持，因?yàn)槲覀兊募軜?gòu)中添加了大量的on-Chip ALU状飞， 當(dāng)然還有更快的做法是直接換用三星的PIM-HBM實(shí)現(xiàn)存內(nèi)計算毫胜。
當(dāng)然用戶也可以定義自己的電路或者IP核并通過AXI總線或者以后通過CHI總線和一些封裝技術(shù)實(shí)現(xiàn)更大規(guī)模的芯片。例如針對MPI-Allreduce場景诬辈，我們實(shí)現(xiàn)了Reduce-Scatter和All-Gather指令集.以后針對DPU的場景我們還可以添加加解密和壓縮器件實(shí)現(xiàn)壓縮酵使、加解密、Hash焙糟、LPM等指令集的擴(kuò)展口渔。
內(nèi)存編址
每個NetDAM設(shè)備都有自己的獨(dú)立地址空間，而且這些空間和掛載的主機(jī)需要IOMMU進(jìn)行映射穿撮，正如前文所述缺脉，在主機(jī)側(cè)我們添加了一段特殊的地址空間來構(gòu)建一個命令QueuePair接收和發(fā)送NetDAM指令包。與此同時悦穿，我們也可以通過實(shí)現(xiàn)特殊的電路構(gòu)建一個Memif并將它直接映射到userspace來實(shí)現(xiàn)容器和虛擬機(jī)的高速以太網(wǎng)訪問攻礼，Memif是思科貢獻(xiàn)給FD.io的技術(shù)，我們已經(jīng)通過它實(shí)現(xiàn)了Go語言原生28Mpps的收包能力,這樣簡單的設(shè)計似乎連DPDK都可以bypass掉了
當(dāng)然談到內(nèi)存編址栗柒，還有一個特別的亮點(diǎn)是礁扮，NetDAM可以單獨(dú)脫離主機(jī)工作，并直接連接到交換機(jī)上瞬沦，實(shí)現(xiàn)整機(jī)Multi-Tbps和Multi-TeraBytes的內(nèi)存池
如果沒有可編程交換機(jī)太伊，每個NetDAM可以使用自己獨(dú)立的IOMMU實(shí)現(xiàn)地址映射，而當(dāng)使用了可編程交換機(jī)后逛钻，可以直接將MMU放置于交換機(jī)上僚焦，實(shí)現(xiàn)交換機(jī)根據(jù)NetDAM報文中的內(nèi)存地址到底層NetDAM設(shè)備IP地址的自動翻譯。
Incast
Incast一直是整個數(shù)據(jù)中心網(wǎng)絡(luò)中最頭疼的問題绣的，本質(zhì)上它是一個多對一通信的問題叠赐，然而我們可以采用基于塊交錯的編址技術(shù)，使用NetDAM提供的內(nèi)存池屡江，將這樣的操作變成多對多（實(shí)際上應(yīng)用無感知)的處理芭概，最后由真正的接收的那個主機(jī)按需取回即可，很簡單的避免了擁塞惩嘉。這樣的處理方式在網(wǎng)絡(luò)設(shè)備上可以追溯到上個世紀(jì)罢洲，思科和Juniper都采用類似的方法避免擁塞。
安全
當(dāng)你跨機(jī)共享內(nèi)存和允許遠(yuǎn)程執(zhí)行時，安全就是一個大問題惹苗，我們可以通過SDN控制扮演一個操作系統(tǒng)內(nèi)存管理進(jìn)程的角色殿较，通過簡單的malloc、free RPC 實(shí)現(xiàn)內(nèi)存分配桩蓉，并且同時通過配置相應(yīng)的ACL實(shí)現(xiàn)訪問控制淋纲，當(dāng)然我們還可以實(shí)現(xiàn)加密寫和解密讀等可擴(kuò)展指令來進(jìn)行更加安全的計算
MPI Allreduce應(yīng)用
我們可以看到，現(xiàn)在AI模型規(guī)模越來越大院究，而參數(shù)同步梯度優(yōu)化已經(jīng)成為最大的瓶頸了洽瞬。
因此我們使用NetDAM實(shí)現(xiàn)了Allreduce的操作來顯示這樣的體系架構(gòu)的優(yōu)越性。算法上我們使用了百度于2017年發(fā)布的Ring Allreduce算法业汰，這個算法也被Horovod庫使用伙窃，NCCL也長時間使用過。當(dāng)然NCCL后來換到Tree的模式也因?yàn)镽DMA實(shí)現(xiàn)的問題需要多次同步導(dǎo)致的样漆，后面我們會詳細(xì)解釋为障。
具體算法和RoCEv2的測試結(jié)果可以參考我兩個月前發(fā)的文：分布式AI訓(xùn)練：RoCEv2 AllReduce實(shí)戰(zhàn)
從通信量來看，Ring和Tree是相同的放祟，計算也是相同的鳍怨，我們也可以通過把Ring尺寸減小到2來構(gòu)建一顆樹。但是我們要選擇Ring的目的是顯示NetDAM分布式鏈?zhǔn)接嬎愕膬?yōu)越性舞竿。我們通過對NetDAM擴(kuò)展了兩條指令Ring Reduce-Scatter和Ring AllGather 來完成京景。測試環(huán)境使用了2塊Xilinx Alveo U55N網(wǎng)卡宁否，每個卡使用一個100G以太口和一半的HBM內(nèi)存構(gòu)建為一個NetDAM設(shè)備虐唠，總共四個節(jié)點(diǎn)連接到Cisco Nexus 93180FX交換機(jī)上
Ring Reduce-Scatter
它主要是一個鏈?zhǔn)降目缭蕉喙?jié)點(diǎn)的計算，如下圖所示烦却，第一個節(jié)點(diǎn)把A1發(fā)送到第二個節(jié)點(diǎn)执桌，第二個節(jié)點(diǎn)加上B1后發(fā)送到第三個節(jié)點(diǎn)鄙皇，然后最終第四個節(jié)點(diǎn)獲得A1+B1+C1+D1的結(jié)果
但是呢，這事跟DMA扯上關(guān)系就復(fù)雜了仰挣，在RDMA的實(shí)現(xiàn)上伴逸，數(shù)據(jù)需要多次DMA穿越PCIe總線，并且CPU需要大量的load膘壶、store的操作错蝴，在高并行的情況下，PCIe總線的擁塞時完全無法控制的颓芭，并且原始的算法每輪迭代之間都還需要同步屏障
而NetDAM就不同了顷锰，所有的操作都發(fā)生在PacketBuffer的SRAM里，而DRAM直接可以讀取并封裝好UDP包發(fā)送亡问，整個鏈條伴隨著SR頭還可以自動路由到下一個節(jié)點(diǎn)產(chǎn)生鏈?zhǔn)椒磻?yīng)官紫，延遲完全可控:
當(dāng)然會有一個小問題就是Error Handling，丟包了擁塞了怎么辦？我們可以注意到對于中間節(jié)點(diǎn)束世，由于沒有任何本地的內(nèi)存讀寫酝陈，因此沒有任何副作用，這些操作是完全冪等的毁涉，而只是最后一個節(jié)點(diǎn)需要寫內(nèi)存沉帮。因此我們實(shí)現(xiàn)了一個類似于區(qū)塊鏈的做法，采用block hash的機(jī)制攜帶到NetDAM指令中薪丁，只有鏈的最后一個節(jié)點(diǎn)擁有相同的Hash才能寫入遇西，這樣就解決了可靠性的問題馅精，出了問題不用擔(dān)心副作用簡單的重傳就能搞定严嗜。
Ring All-Gather
這就是一個鏈條下去傻寫咯，每個節(jié)點(diǎn)收到報文就拷貝寫到本地內(nèi)存洲敢，然后發(fā)送到下一個節(jié)點(diǎn)漫玄， 也是冪等操作。當(dāng)然我們都用了以太網(wǎng)了压彭，也可以通過組播的方式進(jìn)行復(fù)制呀睦优，可靠傳輸參考很多證券行情傳輸，NAK指令單播復(fù)制就好
對比測試
RoCEv2選擇了思科的UCS-M5S服務(wù)器壮不，Intel Xeon 6230R CPU汗盘，滿配12根DDR4@2933Mhz 32GB內(nèi)存，網(wǎng)卡Mellanox CX516A询一，交換機(jī)Cisco Nexus 91380FX隐孽，軟件為HPC-X和OFED，測試結(jié)果536,870,912 x float32 allreduce健蕊，采用OpenMPI內(nèi)帶的Allreduce函數(shù)為2.8秒菱阵，而使用RingAllreduce 2.1s。初步使用NetDAM樣機(jī)測試可以低至 400ms缩功，并且我們后期還會進(jìn)一步優(yōu)化晴及。
結(jié)論和展望
我們通過從根本上分析處理器間通信和主機(jī)間通信協(xié)議在拓?fù)洹⒀舆t嫡锌、一致性虑稼、保序性及報文大小等各方面的區(qū)別，得出結(jié)論是直接使用任何一個協(xié)議去擴(kuò)展都不是最有效的势木，RDMA和NanoPU正是從各自的領(lǐng)域去擴(kuò)展通信協(xié)議但都帶來了問題蛛倦。
基于我們過去十多年在思科QuantumFlow處理器上的架構(gòu)設(shè)計經(jīng)驗(yàn)跟压，從軟硬件可編程友好性的經(jīng)驗(yàn)來看，直接在以太網(wǎng)控制器上掛載內(nèi)存并提供可編程的指令集的內(nèi)存訪問時最有效的方式，它可以有效隔離主機(jī)內(nèi)核主機(jī)間的網(wǎng)絡(luò)，并平滑的實(shí)現(xiàn)主機(jī)內(nèi)共享內(nèi)存倔监、主機(jī)間消息傳遞的通信方式济丘。
同時我們借助Ruta這樣的主動選擇路徑和擁塞控制技術(shù)實(shí)現(xiàn)了數(shù)據(jù)中心網(wǎng)絡(luò)的高復(fù)用疟赊，并且可以通過block interleaved的方式編址解決incast的問題。
最后我們通過FPGA實(shí)現(xiàn)了NetDAM吉执，并證明了在讀寫延遲性上遠(yuǎn)遠(yuǎn)優(yōu)于RDMA的方案靠抑，而可編程性上遠(yuǎn)優(yōu)于NanoPU的方案。
未來當(dāng)我們拿到支持CXL的FPGA和CPU樣機(jī)后肌似，我們還會進(jìn)一步在主機(jī)內(nèi)網(wǎng)絡(luò)上進(jìn)行優(yōu)化處理，例如實(shí)現(xiàn)更加有效的容器網(wǎng)絡(luò)邊斗(SideCar)等，當(dāng)然針對一些云服務(wù)提供商場景，我們還會進(jìn)一步研究基于NetDAM的NVMeOF和持久性內(nèi)存的技術(shù)。最后希望能夠技術(shù)扶貧大家一起把它做起來
