[[431841]]

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

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

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

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

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

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

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

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

不研究歷史的人，注定要重復歷史。

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

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

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

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

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