[[441966]]

元宇宙SDN控制器?

小伙伴們對(duì)昨天利用BloomFilter過(guò)濾找到密接通信對(duì)而畫(huà)出的3D拓?fù)鋱D很感興趣。

其實(shí)它是基于3D js[1]庫(kù)實(shí)現(xiàn)的，具體如何做渲染可以看昨天分享的zbf的代碼。

當(dāng)然還有一個(gè)項(xiàng)目是3d-force-graph-vr[2]。

等渣有空了買(mǎi)個(gè)VR眼鏡應(yīng)該隨手?jǐn)]幾行代碼就可以實(shí)現(xiàn)類(lèi)似于切水果的ACL動(dòng)態(tài)阻斷，或者基于拖拽的Ruta的靈活路徑規(guī)劃和流量工程。

視頻 

華為 Compute-Native Networking

前幾天收到一封來(lái)自華為的郵件，講了一下它們新的總線協(xié)議，突破內(nèi)存墻和I/O墻，領(lǐng)導(dǎo)數(shù)據(jù)時(shí)代計(jì)算系統(tǒng)創(chuàng)新生態(tài)型格局。這是在APNet 2021上的一個(gè)主題演講[3]：

從原理上看，Compute-native networking(后文縮寫(xiě)成HCNN)的提出是很不錯(cuò)的。

Compute-Native對(duì)于延遲和帶寬的追求以及對(duì)于通信容量的追求，這圖寫(xiě)的非常好。PCIe、CXL都因?yàn)槠淇偩€原因編址和拉遠(yuǎn)都存在問(wèn)題。而超大規(guī)模計(jì)算的需求在那，這個(gè)是大家都要去解決的。整個(gè)思路和NetDAM是類(lèi)似的，但有一點(diǎn)不同的是，整個(gè)UB他們是采用的特殊的通信協(xié)議:

而NetDAM采用的以太網(wǎng)UDP。

其實(shí)很多技術(shù)，要推倒重來(lái)有各種處理方法都非常容易，但是整個(gè)行業(yè)又有誰(shuí)愿意來(lái)推倒重來(lái)給你做嫁衣? NetDAM項(xiàng)目最早是2020年跟第四范式談合作的時(shí)候研發(fā)的，最初的想法也就是直接做PCIe Switch然后擴(kuò)展成一個(gè)更好尋址的總線，后面還有一些討論直接利用IP Packet預(yù)留寄存器區(qū)域和指令的方式來(lái)實(shí)現(xiàn)Cache一致性和多機(jī)同步，這些都是片面的追求極致化而不顧生態(tài)的行為。

但是保持開(kāi)放和持續(xù)的后向兼容才是王道，同時(shí)能夠讀懂別的架構(gòu)師在各種約束下的取舍也是十分重要的。例如在HPC這樣的多機(jī)訪問(wèn)場(chǎng)景中，具有統(tǒng)一地址空間的訪問(wèn)是很不錯(cuò)的選擇，RDMA本身的通信方式帶來(lái)了計(jì)算規(guī)模的瓶頸，HCNN采用了如下的尋址方式：

從通信層面上看，的確報(bào)文尺寸更小，但是直接尋址對(duì)于故障隔離和冗余保護(hù)都極為不利，而且整個(gè)交換路由網(wǎng)絡(luò)都要重新設(shè)計(jì)，并且最終和其它設(shè)備訪問(wèn)還需要添加特殊的網(wǎng)卡不便于利舊。而NetDAM直接利用P4交換機(jī)構(gòu)建MMU的方式，并且完全支持以太網(wǎng)，整個(gè)生態(tài)環(huán)境上會(huì)好很多，Intel、AMD、BRCM、Cisco等很多廠家都有用以太網(wǎng)替代RDMA的利益沖動(dòng)，而RDMA本身又因?yàn)镈MA導(dǎo)致處理器在超過(guò)200Gbps的情況下會(huì)導(dǎo)致大量的Cache miss，另一方面是利舊的原因，例如Fungible這類(lèi)的東西要求全網(wǎng)更新是完全不可能的，因此構(gòu)造一個(gè)任何設(shè)備都可以UDP訪問(wèn)的接口又給NetDAM這個(gè)協(xié)議增加了很多平滑遷移的可能性。

通過(guò)IP地址+內(nèi)存地址，甚至是IPv6地址內(nèi)嵌內(nèi)存頁(yè)地址才是Compute-Native網(wǎng)絡(luò)的最終路徑,IP協(xié)議的腰是很難撼動(dòng)的。

至于計(jì)算指令，有些東西物理的延遲就在那里，通過(guò)計(jì)算范式去做，例如Rust一類(lèi)語(yǔ)言對(duì)內(nèi)存所有權(quán)的管理或許才是未來(lái)，而計(jì)算上，HCNN的UB簡(jiǎn)單的照搬以往的指令。

我們做NetDAM也考慮過(guò)同樣的處理方式，但是很快就放棄了，因?yàn)槲覀兏嗟闹皇亲鲆恍￢ector、Matrix的Offload，Scalar的處理Offload就等于扯淡。這里TensTorrent的一張圖堪稱(chēng)經(jīng)典。

把Tensors拆分成packets，然后利用一個(gè)類(lèi)似于BitTorrent的結(jié)構(gòu)一邊轉(zhuǎn)發(fā)一邊計(jì)算，所以我一直說(shuō)這件事情上Jim Keller和他的小伙伴們是看清楚了的，具體可以看如下的Video：

https://www.youtube.com/watch?v=KOHQQyAKY14

TensTorrent的芯片結(jié)構(gòu)也值得大家去好好學(xué)習(xí)一下：

最關(guān)鍵的是利用標(biāo)準(zhǔn)的RISC-V核，非常漂亮,這也是架構(gòu)師必須要考慮的問(wèn)題，對(duì)上的生態(tài)兼容問(wèn)題和編程靈活性的問(wèn)題：

當(dāng)然思科的QFP在20年前也是采用同樣的方法，2D-Mesh的片上網(wǎng)絡(luò)，然后標(biāo)準(zhǔn)的C編譯環(huán)境，多芯片互聯(lián)[4]。

因此我們?cè)贜etDAM的設(shè)計(jì)中也使用UDP使得用戶(hù)態(tài)可以非常靈活的編程產(chǎn)生指令，同時(shí)針對(duì)內(nèi)存訪問(wèn)，還可以提供類(lèi)似于memif的結(jié)構(gòu)給其它編程語(yǔ)言。

至于某個(gè)DPU公司，看過(guò)一些當(dāng)年的文檔[5] 有些東西over-engineering了。

自然而然在靈活性上產(chǎn)生了缺失...其實(shí)很多產(chǎn)品都這樣，設(shè)計(jì)時(shí)以處理器為中心：

因此從這個(gè)結(jié)論上來(lái)看，Compute-Native networking 只看到了一個(gè)很片面的視角，而更多的是以Data-Centric為主,特別是在各個(gè)公司都承諾3060碳中和的時(shí)候，最應(yīng)該關(guān)注的便是數(shù)據(jù)的移動(dòng)。

所以NetDAM會(huì)在上面放置一些ALU，實(shí)現(xiàn)近存計(jì)算(Nearly-In-Memory)或者在轉(zhuǎn)發(fā)報(bào)文的時(shí)候?qū)崿F(xiàn)隨路計(jì)算。把一些ALU放置在靠近內(nèi)存和靠近通信的位置就是NetDAM的價(jià)值。

而實(shí)現(xiàn)Processing-In-Memory(PIM)還需要很多工作，一方面是微處理器架構(gòu)，然后軟硬件接口，然后到系統(tǒng)軟件、編程語(yǔ)言，再到算法。

DreamBig才能有未來(lái)，至于同名的某個(gè)DPU公司，一上手就來(lái)QUIC優(yōu)化，從體系結(jié)構(gòu)來(lái)看很有可能又是一個(gè)和Marvel CN10K或者x豹類(lèi)似的多核處理器廠家，因?yàn)樗以谥vQUIC FastPath的時(shí)候還提到過(guò)嵌入式處理器。

QUIC的Offload是一個(gè)非常有趣的話題，但是也可能非常難，因?yàn)閰f(xié)議編碼的一些問(wèn)題，利用QUIC的可靠傳輸和安全性配合SegmentRouting的可編程能力，這也是渣另一個(gè)項(xiàng)目Ruta的初衷。

《QUIC-SR：關(guān)于NewIP的答案》

云網(wǎng)質(zhì)量保障計(jì)劃

渣去年測(cè)完公有云的互通質(zhì)量后：

《國(guó)內(nèi)共有云互通測(cè)試》

《公有云互通測(cè)試報(bào)告(2)》

終于過(guò)了一年中國(guó)信息通信研究院聯(lián)合中國(guó)通信標(biāo)準(zhǔn)化協(xié)會(huì)在京召開(kāi)了2021混合云大會(huì)，會(huì)上啟動(dòng)了云網(wǎng)質(zhì)量保障計(jì)劃，可喜可賀~至于測(cè)量方法上，渣表示就不多評(píng)價(jià)了，留篇文章自己抄作業(yè)吧

《Internet 的性能測(cè)量》

《Ruta：不用花10個(gè)億也能做千眼》

Reference

[1]3d-force-graph:

https://github.com/vasturiano/3d-force-graph

[2]3d-force-graph-vr:

https://github.com/vasturiano/3d-force-graph-vr,

[3]Compute-native networking:

https://conferences.sigcomm.org/events/apnet2021/records/25/4.Towards%20Compute-Native%20Networking.mp4

[4]Troubleshooting of ASR1K and ISR IOS-XE Made Easy:

https://www.ciscolive.com/c/dam/r/ciscolive/emea/docs/2020/pdf/BRKARC-3147.pdf

[5]RMI MIPS XLR多核處理器培訓(xùn).ppt:

https://download.csdn.net/download/zeroqi1706/1486860?utm_source=bbsseo