[[431841]]

一直覺得Google這樣的公司幾年前就搞出了DC-tax,但是又天天拿著Snap和swift玩普通網(wǎng)卡有點(diǎn)匪夷所思。但最后居然合作方是櫻桃~

其實(shí)談?dòng)布?，各家的DPU都差不多，ARM加可編程邏輯再配點(diǎn)加解密、壓縮、Hash、正則等卸載引擎。而我比較期待的是Google接下來在軟件上為櫻桃IPU提供的能力。比較期待google接下來的論文，看看是否和我們NetDAM有異曲同工之妙~

如果根據(jù)協(xié)議棧的演進(jìn)來看，Google一定會(huì)把整個(gè)Snap框架放置在IPU上：

其實(shí)這一點(diǎn)上我是非常認(rèn)同Google的做法的，對(duì)于容器或者虛機(jī)網(wǎng)絡(luò)而言，TCP/IP協(xié)議棧太重了。某DPU這種TCP over RDMA over TCP的做法在應(yīng)用來看也不是一個(gè)非常干凈漂亮的處理方式，只是或許某廠自身或者某云大量租戶的Java生態(tài)決定的。而相對(duì)于Google而言以及國內(nèi)Baidu頭條等逐漸轉(zhuǎn)向Go生態(tài)的企業(yè)而言，直接使用Memory-mapped I/O承載應(yīng)用而bypass容器的協(xié)議棧是一個(gè)相對(duì)更優(yōu)的選擇， 這也是我們構(gòu)建netDAM項(xiàng)目的一個(gè)原因，即完全實(shí)現(xiàn)用戶態(tài)的內(nèi)存交付。

當(dāng)然軟硬件融合是不可避免的，我最近也在寫一個(gè)軟件版本的NetDAM，即類似于Google Snap一樣的處理方式，為Golang提供原生的用戶態(tài)Bypass kernel收發(fā)包機(jī)制。

雖然櫻桃以前搞過一個(gè)nff-go的項(xiàng)目來將DPDK和Golang結(jié)合，但是似乎最終爛尾了，主要是無法提供Golang原生的支持，而cgo編譯執(zhí)行也很麻煩。而我最近在做的就是基于DPDK創(chuàng)建一個(gè)vhost-user接口給Kernel做ARP、TCP等協(xié)議的操作和遠(yuǎn)程管理支持，而同時(shí)提供一個(gè)Memif為golang提供原生的用戶態(tài)收發(fā)包能力，先期會(huì)先交付Rawsocket的收發(fā)包處理，主要是為一些使用SRv6的用戶提供用戶態(tài)的SID編碼支持能力。當(dāng)然VPP也有類似的框架，包括和Calico集成的方式提供memif，但是太笨重了，對(duì)于應(yīng)用側(cè)并不需要那么多網(wǎng)絡(luò)相關(guān)的功能，應(yīng)用運(yùn)維也有難度。當(dāng)然接下來就是擴(kuò)展NetDAM和Ruta為普通應(yīng)用或者Serverless提供RPC服務(wù)。

另一個(gè)問題是在邊緣計(jì)算上，計(jì)算和通信的融合問題上，似乎我們又在走著IPv9的老路，《十進(jìn)制網(wǎng)絡(luò)技術(shù)及應(yīng)用》這種書能出版就是一個(gè)很值得反思的問題。

看到書中要為細(xì)胞和原子分配地址空間真是覺得太有趣了。為啥要說我們又在走IPv9的老路呢?例如某NewIP剛出來的時(shí)候提出的可變長度地址，十進(jìn)制網(wǎng)絡(luò)也支持16、32、64、128、256、512、1024bits地址。然后趴地上想了一下，1024bits地址不就等于8個(gè)IPv6 SID么，現(xiàn)在某個(gè)設(shè)備上還需要提供12個(gè)SID，比IPv9還厲害。想起IPv9 RFC最后一句話

不研究歷史的人，注定要重復(fù)歷史。

而為什么要談這個(gè)問題就是我們似乎還有很多工程師想著通過IP地址編址的方式去解決一些問題，誠然某些問題可以解決的很漂亮很干凈，但是加到一定長度后對(duì)于硬件的處理能力似乎很多工程師并沒有考慮清楚。最終可能在某些場景上看上去很美，最終在實(shí)施的時(shí)候無法滿足容量需求。

例如我們?cè)O(shè)計(jì)NetDAM的過程中，對(duì)于網(wǎng)絡(luò)側(cè)協(xié)議設(shè)計(jì)，也想過用NDP做可靠傳輸，或者在更早的時(shí)候就像很多人臆想的那樣使用CXL或者PCIe5.0直接over Ethernet來做拉遠(yuǎn)，但是當(dāng)你研究到timing的限制、尋址的限制和一些更多的硬件限制，例如coherence的延遲限制，PCIe NAK時(shí)間限制等和普通主機(jī)訪問及利舊等因素時(shí)， 我們最終選擇了誰都能用上的UDP over Ethernet，以最標(biāo)準(zhǔn)化的方式提供服務(wù)。

所以任何網(wǎng)絡(luò)傳輸標(biāo)準(zhǔn)的制定，不要覺得自己搞個(gè)編碼就行了，更多的要從底層硬件的能力到高層應(yīng)用的可控制能力去考慮。Option header太多并增加太多的branch處理勢(shì)必使得硬件的復(fù)雜度增高，但最終因?yàn)槿萘可喜粷M足需求和成本上不滿足需求而退出了歷史的舞臺(tái)，而很多標(biāo)準(zhǔn)編碼很巧妙，例如BIER，但是因?yàn)檫\(yùn)維難度高，排障不直觀推了好多年也最終沒被市場接收。還有更多的是網(wǎng)絡(luò)通信的目的是為應(yīng)用服務(wù)的，可編程網(wǎng)絡(luò)本質(zhì)上是要應(yīng)用能夠可編程，但是最終發(fā)現(xiàn)一些header需要用Root權(quán)限才能修改，這種技術(shù)怎么可能被應(yīng)用接收呢?

最后引用一段幾年前報(bào)道IPv9的老話，別一天到晚在國內(nèi)好大喜功了，看看差距，留給我們折騰的時(shí)間不多了~

在互聯(lián)網(wǎng)發(fā)源地美國，人們對(duì)于IPV9并沒有討論?；ヂ?lián)網(wǎng)創(chuàng)始人Vint Cerf說，互聯(lián)網(wǎng)發(fā)展過程中出現(xiàn)的這種“噪聲”，是因?yàn)槠涮岢稣哌€沒有搞懂互聯(lián)網(wǎng)的工作原理。他還提到：“RFC 1606很久之前就被公認(rèn)為是愚人節(jié)的玩笑，IPV9完全出自作者的想象，作為互聯(lián)網(wǎng)架構(gòu)，IETF從來沒有認(rèn)可IPV9，IPV9違反了域名系統(tǒng)的規(guī)則”。為什么國外不會(huì)被IPV9這樣的技術(shù)“忽悠”?吳建平認(rèn)為，這與國內(nèi)外的互聯(lián)網(wǎng)文化素養(yǎng)以及社會(huì)治理的決策過程有關(guān)。首先，互聯(lián)網(wǎng)知識(shí)普及，可以讓人們對(duì)互聯(lián)網(wǎng)核心技術(shù)有清晰的認(rèn)知，就不會(huì)被輕易地“忽悠”;第二，很多東西的決策需要專業(yè)人士進(jìn)行，但近年來一些人好大喜功，很容易上這些人的當(dāng)。