一篇了解谷歌樱桃 IPU

网络 通信技术
虽然樱桃以前搞过一个nff-go的项目来将DPDK和Golang结合,但是似乎最终烂尾了,主要是无法提供Golang原生的支持,而cgo编译执行也很麻烦。

[[431841]]

一直觉得Google这样的公司几年前就搞出了DC-tax,但是又天天拿着Snap和swift玩普通网卡有点匪夷所思。但最后居然合作方是樱桃~

其实谈硬件上,各家的DPU都差不多,ARM加可编程逻辑再配点加解密、压缩、Hash、正则等卸载引擎。而我比较期待的是Google接下来在软件上为樱桃IPU提供的能力。比较期待google接下来的论文,看看是否和我们NetDAM有异曲同工之妙~

如果根据协议栈的演进来看,Google一定会把整个Snap框架放置在IPU上:

其实这一点上我是非常认同Google的做法的,对于容器或者虚机网络而言,TCP/IP协议栈太重了。某DPU这种TCP over RDMA over TCP的做法在应用来看也不是一个非常干净漂亮的处理方式,只是或许某厂自身或者某云大量租户的Java生态决定的。而相对于Google而言以及国内Baidu头条等逐渐转向Go生态的企业而言,直接使用Memory-mapped I/O承载应用而bypass容器的协议栈是一个相对更优的选择, 这也是我们构建netDAM项目的一个原因,即完全实现用户态的内存交付。

当然软硬件融合是不可避免的,我最近也在写一个软件版本的NetDAM,即类似于Google Snap一样的处理方式,为Golang提供原生的用户态Bypass kernel收发包机制。

虽然樱桃以前搞过一个nff-go的项目来将DPDK和Golang结合,但是似乎最终烂尾了,主要是无法提供Golang原生的支持,而cgo编译执行也很麻烦。而我最近在做的就是基于DPDK创建一个vhost-user接口给Kernel做ARP、TCP等协议的操作和远程管理支持,而同时提供一个Memif为golang提供原生的用户态收发包能力,先期会先交付Rawsocket的收发包处理,主要是为一些使用SRv6的用户提供用户态的SID编码支持能力。当然VPP也有类似的框架,包括和Calico集成的方式提供memif,但是太笨重了,对于应用侧并不需要那么多网络相关的功能,应用运维也有难度。当然接下来就是扩展NetDAM和Ruta为普通应用或者Serverless提供RPC服务。

另一个问题是在边缘计算上,计算和通信的融合问题上,似乎我们又在走着IPv9的老路,《十进制网络技术及应用》这种书能出版就是一个很值得反思的问题。

看到书中要为细胞和原子分配地址空间真是觉得太有趣了。为啥要说我们又在走IPv9的老路呢?例如某NewIP刚出来的时候提出的可变长度地址,十进制网络也支持16、32、64、128、256、512、1024bits地址。然后趴地上想了一下,1024bits地址不就等于8个IPv6 SID么,现在某个设备上还需要提供12个SID,比IPv9还厉害。想起IPv9 RFC最后一句话

不研究历史的人,注定要重复历史。

而为什么要谈这个问题就是我们似乎还有很多工程师想着通过IP地址编址的方式去解决一些问题,诚然某些问题可以解决的很漂亮很干净,但是加到一定长度后对于硬件的处理能力似乎很多工程师并没有考虑清楚。最终可能在某些场景上看上去很美,最终在实施的时候无法满足容量需求。

例如我们设计NetDAM的过程中,对于网络侧协议设计,也想过用NDP做可靠传输,或者在更早的时候就像很多人臆想的那样使用CXL或者PCIe5.0直接over Ethernet来做拉远,但是当你研究到timing的限制、寻址的限制和一些更多的硬件限制,例如coherence的延迟限制,PCIe NAK时间限制等和普通主机访问及利旧等因素时, 我们最终选择了谁都能用上的UDP over Ethernet,以最标准化的方式提供服务。

所以任何网络传输标准的制定,不要觉得自己搞个编码就行了,更多的要从底层硬件的能力到高层应用的可控制能力去考虑。Option header太多并增加太多的branch处理势必使得硬件的复杂度增高,但最终因为容量上不满足需求和成本上不满足需求而退出了历史的舞台,而很多标准编码很巧妙,例如BIER,但是因为运维难度高,排障不直观推了好多年也最终没被市场接收。还有更多的是网络通信的目的是为应用服务的,可编程网络本质上是要应用能够可编程,但是最终发现一些header需要用Root权限才能修改,这种技术怎么可能被应用接收呢?

最后引用一段几年前报道IPv9的老话,别一天到晚在国内好大喜功了,看看差距,留给我们折腾的时间不多了~

 

在互联网发源地美国,人们对于IPV9并没有讨论。互联网创始人Vint Cerf说,互联网发展过程中出现的这种“噪声”,是因为其提出者还没有搞懂互联网的工作原理。他还提到:“RFC 1606很久之前就被公认为是愚人节的玩笑,IPV9完全出自作者的想象,作为互联网架构,IETF从来没有认可IPV9,IPV9违反了域名系统的规则”。为什么国外不会被IPV9这样的技术“忽悠”?吴建平认为,这与国内外的互联网文化素养以及社会治理的决策过程有关。首先,互联网知识普及,可以让人们对互联网核心技术有清晰的认知,就不会被轻易地“忽悠”;第二,很多东西的决策需要专业人士进行,但近年来一些人好大喜功,很容易上这些人的当。

 

责任编辑:武晓燕 来源: zartbot
相关推荐

2022-10-26 07:39:36

MVCC数据库RR

2022-12-19 08:14:30

注解开发配置

2021-05-20 06:57:16

RabbitMQ开源消息

2021-07-10 09:02:42

编程语言 TypeScript

2021-07-14 10:08:30

责任链模式加工链

2020-10-09 08:15:11

JsBridge

2021-12-30 09:38:51

DDoS攻击防范

2023-05-12 08:19:12

Netty程序框架

2022-06-08 00:10:33

数据治理框架

2021-07-28 10:02:54

建造者模式代码

2021-10-30 07:55:00

BLE 蓝牙开发

2021-07-14 08:24:23

TCPIP 通信协议

2021-06-30 00:20:12

Hangfire.NET平台

2021-08-11 07:02:21

npm包管理器工具

2022-07-31 20:00:59

云原生云计算

2021-11-08 08:42:44

CentOS Supervisor运维

2021-11-24 08:51:32

Node.js监听函数

2021-08-02 06:34:55

Redis删除策略开源

2021-12-15 11:52:34

GPLLinuxGNU

2021-07-08 06:30:03

Linux CPULinux 系统
点赞
收藏

51CTO技术栈公众号