王璞博士，達(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廣告部門海量數(shù)據(jù)處理平臺(tái)開發(fā)。2014年回國(guó)創(chuàng)業(yè)，創(chuàng)立數(shù)人云，專注容器技術(shù)在國(guó)內(nèi)的落地和推廣。2018年，數(shù)人云被收購(gòu)。2020年，創(chuàng)立達(dá)坦科技（DatenLord），致力打造新一代云原生存儲(chǔ)平臺(tái)，專注解決企業(yè)級(jí)客戶在跨云、跨數(shù)據(jù)中心方面的異構(gòu)存儲(chǔ)、數(shù)據(jù)統(tǒng)一訪問(wèn)需求。王璞擁有美國(guó)George Mason大學(xué)計(jì)算機(jī)博士學(xué)位，北大計(jì)算機(jī)專業(yè)碩士學(xué)位和北航力學(xué)專業(yè)學(xué)士學(xué)位。王璞發(fā)表數(shù)十篇論文，被引用累計(jì)上千次，并擁有多項(xiàng)云計(jì)算專利、軟著。王璞于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)景下遇到的幾類協(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)在比較熱門的一個(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 之間有專線去連接（或者說(shuō)這個(gè)上面是公有云，下面是私有云，中間是專線的連接）。這樣的這種比如多 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í)和門級(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)還是分布式等等。所以軟件里的一開始先考慮架構(gòu)，我們基于現(xiàn)在架構(gòu)設(shè)計(jì)，大家去開始實(shí)現(xiàn)，最后測(cè)試一下。

04 Hardware Design

硬件的設(shè)計(jì)的起點(diǎn)，就不一定再?gòu)募軜?gòu)開始了，因?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 開始面向過(guò)程。另一個(gè) Lambda 演算，它后來(lái)衍生出來(lái)的就是函數(shù)式編程。函數(shù)式編程今天大家用的時(shí)候，起源就是 Lambda 開頭的。所以大家看軟件的發(fā)展也是。從單點(diǎn)到覺(jué)得單點(diǎn)計(jì)算能力有限，縱向擴(kuò)展 scale up 的空間是很有限的，開始做橫向擴(kuò)展 scale out，軟件不叫并行，我們叫分布式。軟件分布式的時(shí)候不好搞，這個(gè)時(shí)候借鑒了很多函數(shù)式編程。 今天我們寫很多高級(jí)語(yǔ)言的時(shí)候，比如像 RUST 之類的這些語(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ì)七八十年代）也有人研究基于類似 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)的，所以寫操作是無(wú)阻塞的。消費(fèi)者在讀取數(shù)據(jù)的時(shí)候，接收消息的時(shí)候是有可能阻塞的，因?yàn)槟氵@個(gè)隊(duì)列有可能是空。它就是個(gè)并行的模型。

第二個(gè)模型叫做 Petri Net，可能有的朋友聽說(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ì)畫這種架構(gòu)圖，因?yàn)橛布詈竽惴诺焦杵希诠杵袭嫷臇|西它是個(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)的寫同一個(gè)地方，或者一個(gè)讀一個(gè)寫，你希望先看到讀的結(jié)果還是先看到寫的結(jié)果等等。所以沖突管理這是并行的時(shí)候一定要解決的。

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

?Data 沖突，先讀后寫還是先寫后讀。

?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)存里讀寫，這個(gè)時(shí)候你內(nèi)存的數(shù)據(jù)怎么才能稱之為是一致的？定義了幾種 Memory Order 的一致性的級(jí)別。

?順序內(nèi)存一致性 Sequential Consistency ，假設(shè)大家雖然是并行目的，但是順序地來(lái)讀寫內(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è)核先寫的東西自己可以看見(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í)寫軟件，我們我有一定的抽象，但是當(dāng)我軟硬件聯(lián)合迭代的時(shí)候，這些抽象就打破了，所以你只能從根上你把這個(gè)問(wèn)題想明白。

12 Conflict Resolution in Hardware

怎么解決沖突這個(gè)問(wèn)題？其實(shí)都有很多開源的庫(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 的擁塞控制，今天基本上就兩種解決方案，一種你就買 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)有什么開源的方案，所以我們自己搞了一套協(xié)議的一個(gè)測(cè)試框架。再一個(gè)還有驅(qū)動(dòng)的部分（硬件必然會(huì)有驅(qū)動(dòng)），今天我們看 Linux 內(nèi)核已經(jīng)開始采用 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 開始了。因?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)的硬件開發(fā)語(yǔ)言。用一些比較新的 Implementation 的硬件描述，主要的考慮也在于盡可能提高開發(fā)的效率。用兩個(gè)東西，一個(gè)是 Bluespec SystemVerilog，一個(gè)是 SpinalHDL。

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

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

編輯：黃飛

?