RDMA ? or NoDMA!

主机网络跳过50G直接到100G，而且很有可能会跳过200G上400G，伴随着Nvme和PMEM的大规模使用，这些高速I/O和多核CPU争抢主机内存，整个工业界很快就会遇到更加严重的内存墙瓶颈。随着SDN被判死刑，而技术上交换机最多再到51.2Tbps也会遇到瓶颈，于是拥塞控制、QoS和流量工程又再一次站上了舞台。

这样的背景下，终于从原来简单粗暴的扩带宽的玩法转换为利用精妙的算法去节省带宽的玩法。加法减法如何做便成了一件非常有趣的事情。

历史及现状

冯诺依曼架构内存墙的问题就不再重复了，但我们还是追溯到智能网卡出来之前的架构，一步步的刨析架构的变化和未来的技术路线.在智能网卡出来之前，整个数据路径上会有多次内存拷贝:

工业界的解决方法就是非常简单的做“双减”, 一方面是使用SR-IOV来bypass hypervisor层，并且把vswitch的一些功能做到网卡上，另一方面是在GuestOS使能RDMA实现Kernel bypass

双减之后，再加上一个果金属大招就成就了现在DPU的格局，资本的簇拥下国内估计现在有10家以上的DPU公司了…

下一刀减法砍在哪？

看上去果金属再加上RDMA KernelBypass，很多场景下虚拟机的性能反而比物理机还要好，但是下一步该往哪走呢？阿里作为国内头羊已经开始盈利了，其它几个云亏损的故事自然就讲不下去了，成本成为接下来竞争的关键。

所以有一个很有趣的话题诞生了，就是云网融合。所以这里提出几个问题，从最终用户到云内主机体系架构：

1. 用户从广域网接入云到使用云资源的整个路径上成本开销(专线、SDWAN）如何节省？

2. VPC伴随着Serverless的演进是否还有存在的价值，隔离有更好的做法么？

3. RDMA本身对于互联网终端访问和云网关穿越的难题如何解决，是否真的需要RDMA？

4. 伴随着主机网络到200GE、400GE，如何缓解内存墙？

前两个问题的答案和Ruta有关，后两个问题的答案和NetDAM有关。我们先放一放Ruta相关的问题来谈谈后两个事情…

RDMA是刚需么？

从公有云架构来看，最早搞RDMA的是Azure，然后阿里入局了，而反观AWS和GCP则继续在以太网的道路上疯狂的试探。AWS的SRD(Scalable Reliable Datagrams)在以太网上实现了可靠传输，而GCP未知只是跟樱桃IPU发布的时候带了一句说他们有跟樱桃一起做一个可靠传输协议。当然阿里神龙也搞了一个基于RDMA的可靠传输协议,疗效未知…

当然正如他们自己论文讲的：

RDMA 的一些缺陷在 SMC-R 中同样存在。特别是在建连性能上，由于 RDMA 需要与硬件交互，其建连性能远不如 TCP，所以在大量短连接的场景下，SMC-R 的表现不如 TCP；SMC-R 需要为每个连接预先分配内存，在连接数非常多的情况下，内存占用也会比 TCP 更高。另外，SMC-R 作为一种数据中心内部使用的通信方式，并不适合对公网暴露。

其实还有一个数学问题，我也给一些同学提过：半格的代数结构是通信协议栈优化的最核心问题. 这也是AWS在SRD里强调的一个问题Order：

半格(Semi-Lattic)是个什么鬼呢？于是找了一段鬼话，看不懂直接跳到下一节，这是给学霸技术扶贫的

A commutative idempotent semi-group,然后又来个Partially ordered set，然后AWS SRD又来个Out-Of-Order是不是一下子就懵逼了？首先我们来看内存的分布，其实它就是以内存地址为序列的一个偏序集(Partially ordered set),对内存上进行的操作如果满足可交换(Commutative)、幂等(idempotent)并且满足半群(Semi-Group)中定义的封闭性和结合律。那么这个对内存的操作就是一个半格(Semi-lattice).

RDMA的问题正如AWS在实现SRD里指出的，它不满足交换律。而简单的内存读写操作是满足幂等的，至于结合律取决于这个操作里的幺元是什么，也就是说是以消息为原子，还是以Byte为原子进行操作，因为内存例如 Write 和 Read之间操作的地址空间有冲突则不满足结合律了，而消息的语义则很好的隔离开了这两者，其实这就是AWS实现SRD从数学上的解释，但是AWS也有没做好的地方，既然是MPI超算的业务，针对Reduce-Scatter这些语义的Offload没有考虑，无法直击最大的痛点(NetDAM一开始设计的时候就考虑到了),另一个是多路径只是简单的ECMP，事实上Segment Routing能够进一步解决这个问题。

而AWS花了那么大篇幅解释的一堆东西，本质上就是semi-lattice几个字，交换率(Commutative)决定了Out-of-order可以随便用多路径解决拥塞，幂等(idempotent)决定了丢包可以随便重传，结合律(associative)使得多个操作可以代数上merge好了再传远端，并且可以实现Transactional Memory的访问，保证Transaction的原子性。

通信方式上引入Semi-Lattice，本质上不亚于当年大数据时代引入的map-reduce，而reduce对算子的要求也是要满足交换律，这是分布式系统提升容量的最关键的地方.

可惜国内学渣都学不明白学神的东西，只会去抄学霸的作业…

回到正题，如果通信能够满足这样的东西，那么以太网也就可以玩的飞起来了，也就是说阿里前面讲的SMC-R 作为一种数据中心内部使用的通信方式，并不适合对公网暴露, 而如果我们把这个满足Semi-Lattice的协议做成UDP的，公网都可以玩飞起来？只可惜谈到拥塞控制，所有的人都去搞滑动窗口了，而滑动窗口本身又是有一个保序和头端阻塞的缺陷不满足交换律了…

结论:RDMA并不是刚需，但是Fungible你这种数学不太好的，换什么TCP呢？下一节还有一个更悲惨的消息呈现给你的是DMA本身都要成为灾难.

DMA的问题

下图可以看到以太网接口速率的交货量，未来几年200GE和400GE会很快到达主机，但是主机的I/O准备好了么？

于是我们做了一些测试，首先很多智能网卡只会接在NUMA结构某一个CPU的PCIe-RC上，当然卖螺丝也有双上联的Socket-Direct技术，但是我们还是以常见的场景去计算单个NUMA的瓶颈，以现在Scalable Xeon常见的DDR4-2666 6通道来看，峰值读写带宽为：

然后我们对被测主机发送100Gbps流量测试DMA的影响，具体的测试可以参考

>探索400Gbps主机网络<

测试结果来看峰值带宽在应用正常随机读写时只有89GB/s了. 标准的100Gbps DMA的内存读写开销为24GB/s，也就是说当上到400GE时光DMA就把主内存带宽全吃光了…虽然Intel有DDIO一类的技术来缓解DMA的内存,我们也做了一些测试，如果Cache密集型的应用会轻易的导致DDIO失效，数据包将会从Cache内flush out到DMA，然后过一会儿又Read进来，所以在不同的CacheMiss Rate下，基本上可以看到10%的Cache Miss Rate就要消耗6.8%的内存带宽，而当400GE到来时差不多1/3的带宽也被I/O给浪费了。

因此针对DMA还要减一刀才行…

减法怎么玩？

简单粗暴的减法有两种，一种是NanoPU，另一种是NetDIMM， 还有一种是更高级的加一减二的玩法，比如NetDAM

本质上它们最大的问题就像AWS写SRD的时候谈到的：其实很多时候延迟不是个事，吞吐才是最重要的，需要去做取舍。从体系结构上看，NanoPU和NetDIMM都看到了PCIe作为通路上的瓶颈，于是一个直接把网卡怼到CPU上，另一个直接把网卡怼到内存上试图降低延迟，但事实上两者都无法解决内存带宽瓶颈。而解决瓶颈的最关键技术就是隔离DMA的内存和主内存，让CPU可控的去访问I/O内存和主内存，并将I/O内存映射到用户态，这样从上到下连最后一次DMA带来的主内存memory copy都省了:

然后在网卡上放置一些ALU干嘛的呢？做消息的裁剪和加工，和Pensando放置P4-DMA engine类似，让CPU通过一些指令去更加节省带宽的方式批量获取数据，而不是将整个数据包读入Cache，例如加解密、NFV等场景只需要先读个包头就够了，这样CPU可以可编程的去控制DDIO的Cache用量，按需Poll.

另一方针对前面AWS利用SRD做超算不太干净的做法，例如即便是SRD做AI参数同步All-reduce时依旧要通过CPU去算：

内存前置到网络侧，一方面bypass了PCIe的延迟，所以我们比RoCE快了20%

而另一方面，主机内，GPU的数据可以直接DMA到我板载内存上进行计算，对主内存完全没影响，而对于网络其它主机的消息，我们只有一次板载内存读，也不影响主内存:

这不就是一个加法再做两个减法了么？

就此前面提出的3，4两个问题都有了答案，我们再来看1，2两个答案。本质上我们对Cloud的访问都是一个个的消息，无论是JSON请求还是图片传输，文件传输也可以按照blk来做，视频也有固定的fps，音频也是固定的ptime，一切都是分割的。TCP本身假设的连续不断的数据流实际上是毫无意义的。但是流控的思路上，我们很多人又回到了保序滑动窗口的路子里，说到可靠传输基本上就是抄TCP…

但反过来从Linux服务器端来看，socket buffer开在那里，作为服务器有几百万个公网来的连接，为啥不把它变成一块内存，例如某个用户socket要发包，给他malloc一块内存，让它自己写，写完了让你出来好了自己free掉就行了，搞那么麻烦干嘛。基于这种思路，广域网上的多路径就可以玩起来了呀，例如华为云喜提的”云原生路由架构”, 所以某XQUIC团队自己想想看…

然后这么一干，数据中心通信协议和广域网通信协议不就完全串起来了么，既然这样内存池化和隔离也做好, 还要什么VPC呢？

然后Ruta这样的QUIC+SR的技术，保证公有云零丢包多路径传输，专线也省了，SDWAN也不用了，直接上云了，不香么？

还有一个问题就是基础架构团队从云原生的人只会用VXLAN，从运营商和设备商出来的人狂推SRv6， 所以云网融合的过程中这样的标准之争真的很烦人，最终只能靠4层去解决2，3层的问题， Ruta本身对于3层以下就是你随意爱干嘛干嘛，MPLS、IPv6、SRv6怎么搞都行，哪怕现在IPv4都用的好好的，搁置争议保障各个团队的利益才是关键：）

但接下就有一个问题出现，很多企业都有的，那就无解了，只能看到像诺基亚当年那样 “我们并没有做错什么，但不知道为什么，我们输了。”