RDMA高性能實(shí)踐之軟硬件融合設(shè)計(jì)思路

王璞博士，達(dá)坦科技（DatenLord）聯(lián)合創(chuàng)始人。王璞博士擁有多年云計(jì)算領(lǐng)域的經(jīng)驗(yàn)，擅長(zhǎng)分布式計(jì)算、海量數(shù)據(jù)處理、大規(guī)模機(jī)器學(xué)習(xí)。曾供職Google美國(guó)總部，負(fù)責(zé)Google廣告部門(mén)海量數(shù)據(jù)處理平臺(tái)開(kāi)發(fā)。2014年回國(guó)創(chuàng)業(yè)，創(chuàng)立數(shù)人云，專(zhuān)注容器技術(shù)在國(guó)內(nèi)的落地和推廣。2018年，數(shù)人云被收購(gòu)。2020年，創(chuàng)立達(dá)坦科技（DatenLord），致力打造新一代云原生存儲(chǔ)平臺(tái)，專(zhuān)注解決企業(yè)級(jí)客戶在跨云、跨數(shù)據(jù)中心方面的異構(gòu)存儲(chǔ)、數(shù)據(jù)統(tǒng)一訪問(wèn)需求。王璞擁有美國(guó)George Mason大學(xué)計(jì)算機(jī)博士學(xué)位，北大計(jì)算機(jī)專(zhuān)業(yè)碩士學(xué)位和北航力學(xué)專(zhuān)業(yè)學(xué)士學(xué)位。王璞發(fā)表數(shù)十篇論文，被引用累計(jì)上千次，并擁有多項(xiàng)云計(jì)算專(zhuān)利、軟著。王璞于2020年評(píng)選為騰訊云TVP。

?采用軟硬件融合的方式解決混合云場(chǎng)景下遠(yuǎn)程數(shù)據(jù)訪問(wèn)的性能問(wèn)題

?軟硬件分層思想以及軟硬件融合對(duì)系統(tǒng)設(shè)計(jì)帶來(lái)的挑戰(zhàn)

?引入計(jì)算模型概念，以及做軟硬件設(shè)計(jì)時(shí)需要考慮的點(diǎn)

?并行計(jì)算模型給軟硬件系統(tǒng)帶來(lái)性能的提升，介紹常見(jiàn)的并行計(jì)算模型

?介紹幾種常見(jiàn)的并行計(jì)算模型的硬件架構(gòu)

?軟硬件在并行場(chǎng)景下遇到的幾類(lèi)協(xié)作與沖突問(wèn)題以及解決方法

?基于 RDMA 的軟件系統(tǒng)設(shè)計(jì)思路，解決高性能存儲(chǔ)數(shù)據(jù)傳輸?shù)膯?wèn)題

很高興來(lái)跟大家分享一下我們最近的工作，那天國(guó)強(qiáng)跟我說(shuō)正好今天有兩個(gè) RDMA 相關(guān)的話題，那我就換一個(gè)角度講，不再講 RDMA 的很多細(xì)節(jié)了。因?yàn)榭赡芎芏嗯笥鸦蚨嗷蛏俣加行┝私?，我主要從另外一個(gè)角度，就是硬件融合的角度，這個(gè)也是現(xiàn)在比較熱門(mén)的一個(gè)話題，可能很多朋友有軟件背景或者有硬件背景，但是可能軟硬件都搞的人確實(shí)不多，對(duì)吧？講一些我們?cè)谲浻布?CoDesign 方面的一些思考。

01 Geo-distributed Storage System

我先簡(jiǎn)單介紹一下我們?yōu)槭裁匆丬浻布诤?。首先我?a target="_blank">公司是 DatenLord，我們做的是叫 Geo-distributed Storage System。怎么理解 Geo-distributed Storage System ？就是說(shuō)不同的節(jié)點(diǎn)，它是在不同的 Data Center，Data Center 之間有專(zhuān)線去連接（或者說(shuō)這個(gè)上面是公有云，下面是私有云，中間是專(zhuān)線的連接）。這樣的這種比如多 Data Center 或者所謂 multi cloud 這個(gè)場(chǎng)景，現(xiàn)在是很多企業(yè)客戶都在關(guān)注這個(gè)場(chǎng)景，所謂的多云，所謂混合云等等。

這些概念里邊一個(gè)很頭疼的問(wèn)題就是我的業(yè)務(wù)系統(tǒng)部署在不同的地方，跨 Data Center 最痛苦的就是上面的數(shù)據(jù)怎么辦？你的業(yè)務(wù)系統(tǒng)，比如現(xiàn)在都是打包成 Docker， WebFamily 或者 Serverless 這些形式去部署，部署是很靈活的，對(duì)吧？甚至現(xiàn)在像Serverless 將應(yīng)用部署在哪里提前都不知道的。但是部署之后你的應(yīng)用程序一定是會(huì)訪問(wèn)數(shù)據(jù)的，對(duì)吧？數(shù)據(jù)先天又不是那么靈活的。數(shù)據(jù)絕對(duì)不是我們想放哪就放哪，想從哪訪問(wèn)就從哪訪問(wèn)。所以現(xiàn)在數(shù)據(jù)的遠(yuǎn)程的可訪問(wèn)性，這就是對(duì)于這種多云或者混合云架構(gòu)帶來(lái)的最大的問(wèn)題，所以我們就想嘗試解決這個(gè)問(wèn)題。

就是你的業(yè)務(wù)系統(tǒng)部署在任何的地方都可以，當(dāng)然也不是任意的，肯定有所謂的親和性的部署，但是有一定的靈活性。比如你的業(yè)務(wù)可以部署在多個(gè) Data Center，部署在多個(gè)云上。下面的數(shù)據(jù)可以遠(yuǎn)程去訪問(wèn)，數(shù)據(jù)去搬遷這個(gè)事是吃力不討好的，那我們能不能讓數(shù)據(jù)的遠(yuǎn)程訪問(wèn)的性能大幅度提升。

所以就是為了解決遠(yuǎn)程數(shù)據(jù)訪問(wèn)的問(wèn)題，所以我們用軟硬件融合的方式來(lái)把它的性能大幅度提升。因?yàn)檫h(yuǎn)程數(shù)據(jù)訪問(wèn)單靠軟件是無(wú)法解決的，單靠硬件也沒(méi)辦法去搞。這是我們?yōu)槭裁匆捎密浻布诤系姆绞健?/p>

02 System Design Abstraction

接下來(lái)簡(jiǎn)單的列一下，我們從一個(gè)軟硬件系統(tǒng)的角度看我們?cè)O(shè)計(jì)的抽象層次。從上往下越來(lái)越細(xì)。上面系統(tǒng)整體的抽象層次，下面的算法層面，再往下行為級(jí)的層面（行為級(jí)這層面可能有些軟件同學(xué)可能不太理解，舉個(gè)例子，你的加減法操作，在軟件里面你不會(huì)再關(guān)心加減法操作怎么實(shí)現(xiàn)了），這三個(gè)層級(jí)軟件硬件都可以干（系統(tǒng)級(jí)、算法級(jí)和行為級(jí)）。再往下兩個(gè)層級(jí)、寄存器級(jí)和門(mén)級(jí)，當(dāng)然還往下還有晶體管級(jí)，這些層級(jí)只能硬件干了。

所以這是不同的抽象層級(jí)軟件融合，其實(shí)比較大家一直來(lái)講比較難的一個(gè)點(diǎn)就是抽象層級(jí)融合起來(lái)以后會(huì)被打破。以前我們做軟件的人不會(huì)考慮硬件這么多細(xì)節(jié)，基本上不太考慮寄存器這些東西了，但是到了硬件的跨度很大，很底層的東西我得考慮，很上層的整體系統(tǒng)我也得考慮。所以這就是軟件融合帶來(lái)的一個(gè)設(shè)計(jì)上的挑戰(zhàn)。怎么去沿著原來(lái)一致的思路？比如我做系統(tǒng)的時(shí)候，思路不能割裂（這個(gè)事一個(gè)思路，另外的事情又個(gè)思路，這是很痛苦的），我做這種大的工程的時(shí)候，希望我的思路是一致的。

03 Software Design

簡(jiǎn)單回顧一下軟件的題材，思路是比較容易理解的，我們先做架構(gòu)設(shè)計(jì)，做完架構(gòu)設(shè)計(jì)看看算法怎么回事，然后去實(shí)現(xiàn)，去測(cè)試。軟件的架構(gòu)和硬件都是不一樣的，軟件的架構(gòu)我們很多時(shí)候考慮好，比如單線程還是多線程，你是單點(diǎn)還是分布式等等。所以軟件里的一開(kāi)始先考慮架構(gòu)，我們基于現(xiàn)在架構(gòu)設(shè)計(jì)，大家去開(kāi)始實(shí)現(xiàn)，最后測(cè)試一下。

04 Hardware Design

硬件的設(shè)計(jì)的起點(diǎn)，就不一定再?gòu)募軜?gòu)開(kāi)始了，因?yàn)橛布容^ low level ，硬件的設(shè)計(jì)的起點(diǎn)是計(jì)算模型 Model of Computation ，計(jì)算模型之后才是架構(gòu)算法等等實(shí)現(xiàn)， 然后是驗(yàn)證 Verification 。

05 Model of Computation

這個(gè)計(jì)算模型是什么？這最經(jīng)典的兩個(gè)計(jì)算模型：圖靈機(jī) 和 Lambda 演算對(duì)吧？我們今天 CPU 都是 圖靈機(jī) 這種模型，所以為什么前面講我們做軟件的時(shí)候不會(huì)上來(lái)先考慮你計(jì)算模型？是因?yàn)槲覀冏鲕浖蠹夷J(rèn)底下是有 CPU 的嘛。所以 Model of Computation 對(duì)于軟件來(lái)講是定死的，但對(duì)于硬件我們可以采用不同的計(jì)算模型。

雖然 圖靈機(jī) 我們用了很多，但是 圖靈機(jī) 也帶來(lái)了很多的問(wèn)題，比如典型我們?yōu)槭裁匆鲕浖布?Coding ？因?yàn)榇蠹野l(fā)現(xiàn)軟件很多時(shí)候處理大量數(shù)據(jù)效率并不高，因?yàn)?圖靈機(jī) 它的抽象是指令加數(shù)據(jù)，所以 圖靈機(jī) 很擅長(zhǎng)的是做控制，指令都是控制對(duì)吧，指令里面帶了一點(diǎn)點(diǎn)數(shù)據(jù)。但是你做大量數(shù)據(jù)的處理的時(shí)候，其實(shí)今天看來(lái)為什么大家用 GPU 加速？其實(shí) GPU 每一個(gè) Core 還是 圖靈機(jī)，但是 GPU 一堆并行，所以想做大量數(shù)據(jù)處理的時(shí)候一定要并行，只有并行才能加速。但是 圖靈機(jī) 它是個(gè)串行模型，所以軟件本質(zhì)上是串行的模型。當(dāng)然今天還有多核，但多核的利用效率并不高，在并行的程度上。

所以這兩種計(jì)算模型，一個(gè)是基于是經(jīng)典的 圖靈機(jī)，我們的軟件編程主要是 面向過(guò)程，從 C 開(kāi)始面向過(guò)程。另一個(gè) Lambda 演算，它后來(lái)衍生出來(lái)的就是函數(shù)式編程。函數(shù)式編程今天大家用的時(shí)候，起源就是 Lambda 開(kāi)頭的。所以大家看軟件的發(fā)展也是。從單點(diǎn)到覺(jué)得單點(diǎn)計(jì)算能力有限，縱向擴(kuò)展 scale up 的空間是很有限的，開(kāi)始做橫向擴(kuò)展 scale out，軟件不叫并行，我們叫分布式。軟件分布式的時(shí)候不好搞，這個(gè)時(shí)候借鑒了很多函數(shù)式編程。 今天我們寫(xiě)很多高級(jí)語(yǔ)言的時(shí)候，比如像 RUST 之類(lèi)的這些語(yǔ)言的時(shí)候，里面大量的采用了函數(shù)式編程的一些特性。為什么？因?yàn)檫@是底層的 Model of Computation 帶來(lái)的不一樣， Lambda Calculus 它就沒(méi)有什么指令和數(shù)據(jù)，它靠的是縮減遞歸這些東西，所以他的演算的邏輯和圖靈機(jī)是本質(zhì)上的不一樣。

這個(gè)是我們一直在探索的，解決不同的問(wèn)題需要用不同的 Model of Computation ，這是一個(gè)很大的挑戰(zhàn)。今天基本上幾乎所有的軟件都是基于 圖靈機(jī) 模型，當(dāng)然有這么多年積累，肯定是有很多好處，但是缺點(diǎn)也很明顯，處理大量的數(shù)據(jù)，處理海量數(shù)據(jù)，性能跟不上了。提升性能？從軟件的角度對(duì)吧，借鑒一些 函數(shù)式編程 做分布式并行，這是一個(gè)維度。但是這還不夠，這還是在偏軟件層面。下一步我們想更深入地去壓榨性能，讓硬件先天并行的。

06 Software v.s. Hardware

簡(jiǎn)單地回顧一下，軟件的時(shí)候基本上是 Model of Computation ，我們很難去改變，即便今天用這種并行編程，但它底層還是跑到 CPU 上的，CPU 的計(jì)算模型是 圖靈機(jī) 模型。

當(dāng)然早期（大概上個(gè)世紀(jì)七八十年代）也有人研究基于類(lèi)似 Lambda Calculus 那種所謂數(shù)據(jù)流的方式做 Data Flow 模型，也是一個(gè)當(dāng)年很熱的研究，但是后來(lái)輸給了 圖形機(jī)，還是 圖形機(jī) 變成了 CPU 最主流的架構(gòu)。所以硬件我們?cè)诘臅r(shí)候，根本問(wèn)題就得考慮好。軟件我們沒(méi)有人再去考慮， 圖靈機(jī)模型就是一個(gè)前提假設(shè)，但硬件我可以突破 圖靈機(jī)模型。

當(dāng)然今天有很多硬件，比如 Google 做 TPU( TensorProcessing Units) 的時(shí)候用的也還是 圖靈機(jī)馮諾伊曼這套模型。但是它不一樣， Google 做 TPU 的時(shí)候，它的指令很少，四五條指令，指令的力度是非常非常粗的。不像 CPU x86 幾千條指令， RISC-V 都得上百條指令(這肯定有的)。

所以在硬件我們?cè)賮?lái)設(shè)計(jì)的時(shí)候，我們就必須根據(jù)你要做的計(jì)算任務(wù)，從 Model of Computation 出發(fā)，才有后面的東西。如果沒(méi)想清楚，后面在硬件上面，你做架構(gòu)，做算法，做實(shí)現(xiàn)，后面無(wú)從談起。

07 Model of Computation for Parallel

前面跟大家講了 Model of Computation 計(jì)算模型的概念。剛才講硬件先天并行，今天雖然有多核，但是軟件來(lái)源于圖靈機(jī)，它是個(gè)串行模型。我們今天所謂做性能加速，其實(shí)本質(zhì)上就是把以前串行的事該變成并行的，這樣速度就能快了。

剛才講了，硬件我們?cè)O(shè)計(jì)的時(shí)候，第一步就要考慮計(jì)算模型是什么？計(jì)算模型這個(gè)東西，其實(shí)計(jì)算機(jī)系統(tǒng)過(guò)去幾十年的研究已經(jīng)研究得很透徹了。在這舉了兩相對(duì)常見(jiàn)的，對(duì)于并行場(chǎng)景來(lái)講，我可以采用什么計(jì)算模型？這就不是 圖靈機(jī)，也不是 Lambda Calculus。

第一個(gè)模型叫做 Kahn Process，名字大家不一定那么熟悉，但是其實(shí)它的理念很簡(jiǎn)單。每個(gè)節(jié)點(diǎn)是我的功能模塊，一個(gè)是生產(chǎn)者，另一個(gè)是它的消費(fèi)者。生產(chǎn)者生產(chǎn)出來(lái)這些數(shù)據(jù)或者消息傳給消費(fèi)者，消費(fèi)者可能又是別人的生產(chǎn)者。所以其實(shí)就是生產(chǎn)者消費(fèi)者問(wèn)題，只不過(guò)這些生產(chǎn)者消費(fèi)者之間的邏輯關(guān)系是一個(gè)網(wǎng)狀的，最后形成的 DAG 有向無(wú)關(guān)圖。還有很重要一點(diǎn)，這些消息中間都有個(gè)隊(duì)列給你緩沖一下。它假設(shè)是這些隊(duì)列是無(wú)限長(zhǎng)的（這是一個(gè)數(shù)學(xué)上的一個(gè)很大的假設(shè)）。所以。生產(chǎn)者來(lái)生產(chǎn)數(shù)據(jù)的時(shí)候，你隊(duì)列是無(wú)限長(zhǎng)的，所以寫(xiě)操作是無(wú)阻塞的。消費(fèi)者在讀取數(shù)據(jù)的時(shí)候，接收消息的時(shí)候是有可能阻塞的，因?yàn)槟氵@個(gè)隊(duì)列有可能是空。它就是個(gè)并行的模型。

第二個(gè)模型叫做 Petri Net，可能有的朋友聽(tīng)說(shuō)過(guò)，這也是很常見(jiàn)的一個(gè)并行模型。它也是生產(chǎn)者和消費(fèi)者模型，只不過(guò)它的建模方式和上面不一樣，它中間沒(méi)有所謂的緩沖隊(duì)列了，通過(guò) transition 的關(guān)系來(lái)建模。圓圈代表不同的功能模塊（代表生產(chǎn)者），黑點(diǎn)代表生產(chǎn)資料。比如生產(chǎn)者（P1）黑點(diǎn)經(jīng)過(guò) transition 或者一個(gè)動(dòng)作，它可以生產(chǎn)出兩個(gè)數(shù)據(jù)分別給到兩個(gè)消費(fèi)者（ P2 P3），這兩個(gè)數(shù)據(jù)是相同的數(shù)據(jù)，這兩個(gè)消費(fèi)者（ P2 P3）他拿分別拿到不同數(shù)據(jù)，他就可以變成生產(chǎn)者（ P2 P3）。這兩個(gè)生產(chǎn)者都得生產(chǎn)出來(lái)數(shù)據(jù)才能給到后面的消費(fèi)者（T2）。

并行模型中每一個(gè)功能模塊可以同時(shí)工作，只不過(guò)有的時(shí)候你上游數(shù)據(jù)不 ready，你這時(shí)候沒(méi)有數(shù)據(jù)讓你去處理。這種模型在于硬件建模是非常方便的，因?yàn)橛布忍炀褪遣⑿械?。但是又不是那種 free parallel，并行工作時(shí)候你要定期去 sync ，比如模塊都是生產(chǎn)者也同時(shí)都是消費(fèi)者，你什么時(shí)候有數(shù)據(jù)可以消費(fèi)，你什么什么時(shí)候生產(chǎn)數(shù)據(jù)，你下游不 ready，你生產(chǎn)出來(lái)數(shù)據(jù)會(huì)不會(huì)丟掉等等各種各樣配合的問(wèn)題。

這就是計(jì)算模型就把這些問(wèn)題給你抽象出來(lái)，大家并行的時(shí)候提升性能，但是并行不是代表大家各自去自由地去跑，一定要有中間的協(xié)同，這些就是 Model of Computation 帶來(lái)的。所以這就是我們做軟件融合系統(tǒng)的時(shí)候，一定第一步把這個(gè)問(wèn)題要想清楚，你到底解決這個(gè)問(wèn)題，它是用什么樣的一個(gè)計(jì)算模型來(lái)跟他進(jìn)行抽象。這些想明白的時(shí)候，剩下的東西就變得相對(duì)簡(jiǎn)單一些。

08 Architecture in Hardware

剛才講的是并行的計(jì)算模型，接下來(lái)對(duì)硬件的階段來(lái)講，計(jì)算模型定好之后，接下來(lái)定下硬件的架構(gòu)。常見(jiàn)的硬件架構(gòu)，我這列了幾個(gè)

?有限狀態(tài)自動(dòng)機(jī)（FSM），這是很常用的一個(gè)硬件模式，但狀態(tài)機(jī)它的一個(gè)缺點(diǎn)是什么？狀態(tài)機(jī)本質(zhì)它是個(gè)串行模型（現(xiàn)在是第一個(gè)狀態(tài)，什么時(shí)候到第二個(gè)狀態(tài)，什么時(shí)候第三個(gè)狀態(tài)）。

?流水線（Pipeline）， 是個(gè)很經(jīng)典的硬件的一個(gè)并行東西，只不過(guò)流水線的不同階段處理不同的數(shù)據(jù)，但它們是在一起來(lái)工作的。

?Replica，你的模塊想并行工作，怎么辦？在硬件上我也可以搞多份。比如我的加法器和乘法器，1 個(gè)不夠用，來(lái) 10 個(gè)，100 個(gè)。

?脈動(dòng)陣列（Systolic Array），是現(xiàn)在神經(jīng)網(wǎng)絡(luò)里面用的很多。它是一個(gè)陣列的方式，數(shù)據(jù)在上面不停地流動(dòng)每一個(gè)方框，這是一個(gè)處理節(jié)點(diǎn)。

所以大家看硬件設(shè)計(jì)的時(shí)候，對(duì)和軟件就很不一樣，這是常見(jiàn)的硬件的架構(gòu)圖，我們軟件不會(huì)畫(huà)這種架構(gòu)圖，因?yàn)橛布詈竽惴诺焦杵?，在硅片上?huà)的東西它是個(gè)二維結(jié)構(gòu)

09?Single-core Issue

硬件并行帶來(lái)了很大的問(wèn)題，并行模塊之前的協(xié)同是 Model of Computation 解決的問(wèn)題。

還有一個(gè)重要的問(wèn)題就是硬件并行工作，一定會(huì)導(dǎo)致沖突。例如兩個(gè)不同模塊，你去競(jìng)爭(zhēng)的寫(xiě)同一個(gè)地方，或者一個(gè)讀一個(gè)寫(xiě)，你希望先看到讀的結(jié)果還是先看到寫(xiě)的結(jié)果等等。所以沖突管理這是并行的時(shí)候一定要解決的。

?Control 沖突，比如你指令的跳轉(zhuǎn)帶來(lái)的沖突問(wèn)題，這因?yàn)橹噶钍橇魉€，同時(shí)有多條指令在執(zhí)行，你多條指令同時(shí)執(zhí)行，帶來(lái)的沖突。

?Data 沖突，先讀后寫(xiě)還是先寫(xiě)后讀。

?Resource 沖突，CPU 里邊加法器，乘法器和 Cache 是有限的。那對(duì)于資源的競(jìng)爭(zhēng)沖突訪問(wèn)，這也是沖突。

10 Multi-core Issue

多核帶來(lái)的問(wèn)題可能對(duì)于軟件的同學(xué)感受比較深一些。比如多核帶來(lái)了一個(gè)很頭疼的問(wèn)題，就是內(nèi)存一致性的問(wèn)題。多個(gè)核的競(jìng)爭(zhēng)的往內(nèi)存里讀寫(xiě)，這個(gè)時(shí)候你內(nèi)存的數(shù)據(jù)怎么才能稱之為是一致的？定義了幾種 Memory Order 的一致性的級(jí)別。

?順序內(nèi)存一致性 Sequential Consistency ，假設(shè)大家雖然是并行目的，但是順序地來(lái)讀寫(xiě)內(nèi)存顯然不會(huì)出錯(cuò)，但是顯然 sequential 太強(qiáng)的要求了，你想要性能的時(shí)候 sequence 為了保證正確性，得是串行的來(lái)。這跟我們對(duì)性能的要求是沖突的。

?Total Store Order 就是 X86 的默認(rèn)的 Order，先 store 后 load，可以亂序。

?Multi-copy Atomic 就是 RISC-V 的默認(rèn)Order。你個(gè)核先寫(xiě)的東西自己可以看見(jiàn)，如果別的核看見(jiàn)，都得能看見(jiàn)。

在借鑒 CPU 體系結(jié)構(gòu)過(guò)往的一些工程經(jīng)驗(yàn)里邊，已經(jīng)有很多實(shí)踐去來(lái)解決并行工作帶來(lái)的數(shù)據(jù)沖突的問(wèn)題。這塊是個(gè)很麻煩的問(wèn)題，我們做軟硬件設(shè)計(jì)的時(shí)候，這些問(wèn)題你都會(huì)碰到，因?yàn)槟阕鰯?shù)據(jù)處理，一旦并行的時(shí)候，這些問(wèn)題自然而就來(lái)了。而且我們做計(jì)算的時(shí)候很少碰到那種場(chǎng)景是純并行，完全不用考慮互相的協(xié)作，是很少很少的場(chǎng)景。

11 Parallel vs Distributed

不管是并行也好，還是分布式也好，是沖突的問(wèn)題，我們?nèi)ピ趺慈ソ鉀Q它。其實(shí)從軟件和硬件角度我們都有大量的工作。

?比如 分布式一致性 算法，像 Python 算法常用的 Raft 協(xié)議等等，它們也是在解決沖突的，只不過(guò)是在一個(gè)時(shí)間維度很大的的維度上（比如毫秒級(jí)，網(wǎng)絡(luò)傳輸都基本上都是毫秒）。

?到了 內(nèi)存一致性 問(wèn)題的時(shí)候，這個(gè)時(shí)候就到了一臺(tái)服務(wù)器了，這時(shí)候它的時(shí)間維度大概是微秒或者亞微秒，大幾十納秒等等。

?到了 CPU 里頭，這就是變成 Cache一致性 問(wèn)題，考慮就是納秒級(jí)的問(wèn)題了。

所以其實(shí)我們?cè)谧鲆粋€(gè)復(fù)雜的系統(tǒng)（計(jì)算機(jī)系統(tǒng)或者數(shù)字系統(tǒng)）的時(shí)候，為了解決性能問(wèn)題，大量的用并行或者用分布式來(lái)做加速做肯定快。但是并行或者分布式加速帶來(lái)的問(wèn)題就是沖突。其實(shí)協(xié)作還是小問(wèn)題，沖突是最大的問(wèn)題。沖突怎么做？其實(shí)有很多現(xiàn)有的方案，只不過(guò)這些方案不一定是大家每個(gè)人都天天在研究的東西。但是當(dāng)我們下沉到軟硬件協(xié)同設(shè)計(jì)的時(shí)候，這些問(wèn)題就通通都暴露出來(lái)了，為什么會(huì)暴露出來(lái)？我們平時(shí)寫(xiě)軟件，我們我有一定的抽象，但是當(dāng)我軟硬件聯(lián)合迭代的時(shí)候，這些抽象就打破了，所以你只能從根上你把這個(gè)問(wèn)題想明白。

12 Conflict Resolution in Hardware

怎么解決沖突這個(gè)問(wèn)題？其實(shí)都有很多開(kāi)源的庫(kù)去解決它，每個(gè)語(yǔ)言里邊都有。硬件里面的沖突管理怎么做的？其實(shí) CPU 的體系結(jié)構(gòu)的研究里面講了不少，比如一個(gè)核里的流水線，各種 hazard 這些。

但是推而廣之，如果一個(gè)硬件系統(tǒng)，特指數(shù)字硬件 IC 這種系統(tǒng)，如果我們?cè)斓牟皇?CPU，今天做軟件融合的時(shí)候，大概率底下硬件系統(tǒng)不一定是個(gè) CPU，這個(gè)時(shí)候怎么解決這些沖突？其實(shí)借鑒的方法跟軟件的思路是一致的，本質(zhì)都是個(gè)都是并行工作帶來(lái)的沖突。所以解決問(wèn)題的思路是一致的，只不過(guò)具體的方法不一樣。

?彈性 Elastic ，軟件是很靈活很彈性的，但硬件沒(méi)那么彈性。硬件我在設(shè)計(jì)的時(shí)候，協(xié)議層面讓大家互相的消息傳遞要變成彈性，對(duì)這個(gè)消息的 delay，要對(duì) delay 變得不敏感（不要假設(shè)過(guò)多長(zhǎng)時(shí)間，我把消息發(fā)給你），這些消息的 delay 你是不可控的，什么時(shí)候消息傳遞成功等等。

?保證原子性 Atomic。比如大家我們做分布式系統(tǒng)的時(shí)候，基本上都有一個(gè)分布式一致性的，一個(gè)節(jié)點(diǎn)或者一個(gè)服務(wù)保證原子性。硬件也一樣，各種沖突我也得保證原子性，其實(shí)本質(zhì)上就是個(gè) transaction 的概念。怎么保證？就需要你底干上有一些東西，所以原子性是不好做的。比如軟件里面大家用所謂各種無(wú)鎖操作，其實(shí)本質(zhì)上就是用 CPU 直接提供原子操作。

?調(diào)度 Scheduling ，本質(zhì)通過(guò)優(yōu)先級(jí)來(lái)解決沖突問(wèn)題（沖突是不可避免的）。沖突的時(shí)候誰(shuí)優(yōu)先級(jí)更高，誰(shuí)優(yōu)先級(jí)更低。

當(dāng)然這幾個(gè)方法，可能彈性相對(duì)還好處理一點(diǎn)，有硬件協(xié)議來(lái)做，剩下的原子性，還有 Scheduling 都得我們?cè)O(shè)計(jì)硬件的都想得很清楚。

13 RDMA Software/Hardware Co-design

以我們做 RDMA 這樣一個(gè)軟件系統(tǒng)，給大家簡(jiǎn)單介紹一下我們的思路，就說(shuō)我們用 RDMA 主要是解決高性能存儲(chǔ)數(shù)據(jù)傳輸?shù)膯?wèn)題。 RDMA 本質(zhì)其實(shí)也是軟硬件的一個(gè)系統(tǒng)。我們?yōu)槭裁醋约鹤?RDMA 的硬件，是因?yàn)?RDMA 商用的卡里邊有一些不夠靈活的地方，比如 RDMA 的擁塞控制，今天基本上就兩種解決方案，一種你就買(mǎi) InfiniBand 的那套商用的方案。

但是當(dāng)今數(shù)據(jù)中心我們大量用的交換機(jī)路由器還是以太網(wǎng)的。你要用 InfiniBand 的解決方案，那跟以太網(wǎng)的交換記錄器的協(xié)議都不一樣，雖然也可以融合，但是肯定不是個(gè)很優(yōu)的方案，再加上成本的考慮。

今天 RDMA 落地?cái)?shù)據(jù)中心大部分都是 RoCE 方案，所以我們也是采用 RoCE 方案， RDMA 跟以太網(wǎng)融合。但 RoCE 方案最大的問(wèn)題是什么？流量控制對(duì)他來(lái)講是黑洞。為什么這么講？你看，比如像 InfiniBand 它解決 RDMA 的流量控制問(wèn)題，他從他的鏈路層，網(wǎng)絡(luò)層，傳輸層，每一層都要去解決這個(gè)問(wèn)題。但是到 RoCE 的時(shí)候就沒(méi)那么容易了。

RoCE 是把 RDMA 的傳輸層嫁接到了 UDP 上， UDP 根本沒(méi)有任何的流量控制和擁塞控制的管理能力，只用 RDMA 的傳輸層， RDMA 傳輸層只有很少的流量控制，而且 RDMA 傳輸層沒(méi)有擁塞控制能力。今天所有的 RDMA 的流量控制和擁塞控制，都是靠額外的算法在外層去來(lái)解決這個(gè)問(wèn)題。

我們?yōu)榱藢?shí)現(xiàn)高性能傳輸?shù)臅r(shí)候，就要流量控制和擁塞控制，特別是擁塞控制。我們覺(jué)得這個(gè)問(wèn)題對(duì)我們是非常關(guān)鍵的，所以我們自己去搞硬件。而且擁塞控制這個(gè)東西，它還不是純硬件能解決的，上面還有軟件的很多東西。當(dāng)然這些問(wèn)題我們今天還沒(méi)有解決完。所以我這列的時(shí)候沒(méi)有提很多流量空投有所控制的問(wèn)題。但是如果感興趣，是網(wǎng)絡(luò)研究的一個(gè)很大的熱點(diǎn)。

我們做 RDMA 軟件和硬件的時(shí)候，其實(shí)功能模塊還是比較容易理解的。

?軟件首先就是 RDMA 的 API，因?yàn)槲覀冘浖?Rust，我們把它做了一套 RDMA 的 API 的 Rust binding forlibverbs。再一個(gè) RDMA 的測(cè)試是沒(méi)有什么開(kāi)源的方案，所以我們自己搞了一套協(xié)議的一個(gè)測(cè)試框架。再一個(gè)還有驅(qū)動(dòng)的部分（硬件必然會(huì)有驅(qū)動(dòng)），今天我們看 Linux 內(nèi)核已經(jīng)開(kāi)始采用 Rust，我們正在看用 Rust for Linux 怎么來(lái)做一個(gè)驅(qū)動(dòng)，前期做了一些調(diào)研，但目前還不太成熟，所以我們還沒(méi)有真正上手在干?；氐接布@端 RDMA 的傳輸層，是要硬件實(shí)現(xiàn)好。

?硬件里邊 DMA 基本是 RDMA的性能瓶頸， DMA 系統(tǒng)的最大的 delay 都是 PCIE 帶來(lái)的。基于 PCIE的 DMA controller 怎么做高性能的 DMA 操作。包括現(xiàn)在新出 CXL 協(xié)議出來(lái)之后，會(huì)很大程度上解決 DMA 的性能問(wèn)題， CPU 和你的外設(shè)是在同一個(gè)地址空間，再也不需要做什么內(nèi)存的地址空間和 PCIE 地址空間 mmap 的問(wèn)題了。

?再一個(gè)就是 RoCE 方案，是用 UDP 來(lái)傳輸?shù)摹?UDP 也搬到硬件上去實(shí)現(xiàn)，需要實(shí)現(xiàn)的這些組件。

14 RDMA Software

但是在實(shí)現(xiàn)的時(shí)候，幾個(gè)底層的抽象就不一樣。軟件可能相對(duì)好想一些，你不需要考慮 Model of Computation ，你軟件是 圖靈機(jī) 模型。

?軟件的架構(gòu)。這個(gè)時(shí)候我們選一個(gè)架構(gòu)，比如上面 RDMA 的這些 API 等等，我們都用協(xié)程的方式（不希望用線程這種模型，因?yàn)榫€程要內(nèi)核來(lái)調(diào)度，我們不希望做很多的上下文切換）。

?算法不太涉及， RDMA 網(wǎng)絡(luò)協(xié)議不太涉及太多算法。

?軟件我們主要是用 Rust，Rust 里面就是Rust Async。驅(qū)動(dòng)在內(nèi)核里面用 Rust for Linux 。

?測(cè)試我們主要用 Python，在 Python 里面主要用 Scapy做網(wǎng)絡(luò)包的一個(gè)測(cè)試，很常見(jiàn)的框架。

15 RDMA Hardware

硬件的設(shè)計(jì)要從 Model of Computation 開(kāi)始了。因?yàn)?RDMA 它是個(gè)網(wǎng)絡(luò)協(xié)議不是 CPU ，網(wǎng)絡(luò)協(xié)議主要是做數(shù)據(jù)傳輸。

?它的 Model of Computation 我們選擇的是叫作同步數(shù)據(jù)流模型。其實(shí)它本質(zhì)上是一個(gè)前面介紹 Kahn Process的簡(jiǎn)化。最大的簡(jiǎn)化在于好我不同的生產(chǎn)者、消費(fèi)者中間之間緩沖 FIFO，我這是要管理的（它不可能是無(wú)限的，硬件沒(méi)有那么多無(wú)限的資源）。同步數(shù)據(jù)的模型 它的一個(gè)很大的優(yōu)點(diǎn)就是做了比較強(qiáng)的一些假設(shè)，就是每個(gè)生產(chǎn)者每個(gè)時(shí)刻產(chǎn)生一個(gè)數(shù)據(jù)，每個(gè)消費(fèi)者每個(gè)時(shí)刻接收一個(gè)數(shù)據(jù)，這樣有了很強(qiáng)的一個(gè)假設(shè)之后，好我中間緩沖，我就可以精確地算出來(lái)了。有了 同步數(shù)據(jù)流模型之后，你的這些并行之間的調(diào)度問(wèn)題也可以提前做一些安排。

?架構(gòu)層面這就是用一些硬件經(jīng)典的架構(gòu)，比如 pipeline 流水線架構(gòu)。像網(wǎng)絡(luò)數(shù)據(jù)進(jìn)來(lái)之后，很長(zhǎng)的一個(gè)流水線，我們最長(zhǎng)的流水線也大概十七八級(jí)了。狀態(tài)機(jī)也少不了。整體的并行控制等等。比如 RDMA 它不同的隊(duì)列對(duì)吧？不同的 QP(Queue Pair)，預(yù)先設(shè)好有多少個(gè) QP，靠不停地去在硬件上去復(fù)制它。

?算法不涉及。

?Implementation 的時(shí)候，我們沒(méi)有采用 Verilog 傳統(tǒng)的硬件開(kāi)發(fā)語(yǔ)言。用一些比較新的 Implementation 的硬件描述，主要的考慮也在于盡可能提高開(kāi)發(fā)的效率。用兩個(gè)東西，一個(gè)是 Bluespec SystemVerilog，一個(gè)是 SpinalHDL。

?測(cè)試的時(shí)候，我們現(xiàn)在做一些基于 Python 來(lái)做硬件的 Verification。當(dāng)然這兩個(gè)開(kāi)發(fā)語(yǔ)言本質(zhì)它也要寫(xiě)很多測(cè)試驗(yàn)證的問(wèn)題。

這個(gè)是我們整個(gè)迭代硬件的一些思考和價(jià)值。

編輯：黃飛

?