DPU该干嘛…不该干嘛

昨天一文中提到2000年~2010年那些做网络处理器的团队又在十年后的DPU时代登场了，Intel IXP十几年后就变成了Netronome，然后国内又给了芯启源， Cavium十多年以后收到Marvell门下诞生了CN10K，RMI被BRCM收购后，然后整个团队被裁掉，倒也诞生了神龙的早期团队和现在的云豹，而Tilera几经流转进了EzChip然后去了Mellanox最后投到nVidia旗下成了如今的BlueField，Juniper的创立了Fungible，但是….

居然这整个局里面缺少了思科做网络处理器的团队，而云上DPU业务中和网络相关的雏形便是这个团队一手打造的CSR1000v系列云路由器.

当然有人会提到MPLS去做Pensando，但MPLS毕竟是交换的团队，但是真正做多业务路由的这群人在干什么呢？说出来都不信，大家都在玩软件…当然这里的软件不是指DPDK或者VPP这样的东西。VPP是开源出来了，但是我们这种真正做多业务路由器的团队压根就懒得看这玩意,因为多业务并发以后性能就…

关于多业务并发，过去很多年和友商玩集采或者竞标的时候，随便出几手技术分就第一了，某大厂一些技术缺陷直接被我废标的案例也多的去了。一个路由器只做简单的转发非常容易做到极致，但是当你考虑要加上IPSec、NAT、压缩、TLS-Offload、BRAS、正则表达式、DPI、流控、计费、防火墙、语音等几十个功能一起叠加时，基本上没有一家能够做好的，而即便能做性能也差的一塌糊涂。而这些多业务融合都是DPU大概率需要去做的。

很多时候说性能不够需要Offload其实就是不会写软件，举个最简单的例子，Viptela被思科收购进来以后，同样的硬件盒子，同样的业务场景，思科自己的转发平面代码性能是Viptela基于开源实现的2倍以上，而且功能还多得多~

那是什么原因导致我们逐渐把重心转向软件和通用处理器的呢？从商业逻辑上来看，很多DPU企业都准备投重金购买ARM的IP，因为如上的很多功能的确用Pipeline的方式不好写，所以大家也看到了AWS Nitro为什么是ARM多核架构。而另一个没被大家关注的一点是Graviton 2里内置了一颗压缩的协处理器，但是阿里的倚天似乎还没考虑到这一点。

AWS针对自身业务而言，做ARM多核的芯片同时用在通用CPU和DPU上可以很好的摊销自己的成本，而Gravition2除了公开售卖ARM实例，必定会作为一颗DPU用在存储上。阿里后期也会遇到FPGA功能上的局限性而必定逐渐转向多核处理器的架构。

另一方面的原因是从核使用成本上来看，例如某厂胶片讲的：

这个算法可能在几年前可以这么算，但是如今似乎需要打一个问号了，AMD和Intel基本上给云定制的处理器例如AMD 7T83，本来64个核，然后内部又是Chiplet的结构，Cache优化非常麻烦，在这种视角上，浪费几个核，上图中的分母差距就不那么大了(64 vs 60)，说不定还能填回DPU的成本。所以我自己在一些容器网络的项目中，直接玩zmemif(github.com/zartbot/zmemif)了,利用DPDK把要处理的报文Prefetch到Cache中，再共享内存给容器内Golang用，香不香~直接Golang果奔就可以把现在大多数DPU打到内出血.

所以从DPU是大CPU下挂载的小CPU，这样的视角是有一些违背内在逻辑的，而且现在很多业务性能来看，也够用了，牺牲一个大CPU解放所有大CPU。另一方面来看跟着通用CPU大厂吃肉，每年人家优化IPC提升15%不香么，非得自己去搞个团队做出来的DPU比CPU结构还复杂，为啥不直接正面刚人家AMD、Intel呢？而从历史上来看，凡是DPU能做的功能，固化后了很多时候都被整合进了通用CPU了，现在是加密、以后就会有压缩和hash,毕竟樱桃这样的企业CPU才是主业。

那么DPU的业务核心逻辑在哪呢？第一，可靠的传输，但不需要建立在无损的交换网络上。第二，为应用提供更好的交付，例如前面提到的，也是我们在NetDAM DPU架构中要做的，数据的交付是以内存的方式进行的，而不是通信的数据包。怎么理解这个问题呢？

例如我有一个健康码人脸识别的应用，肯定是把自己的照片TCP传给服务器，然后识别完了，再把身份传到后台数据库，最后生成健康码传回来。这个过程中，如果按照传统的通信方式，TCP需要建立socket buffer，服务器收完了以后又要拷贝到GPU上做推理，推理结果拷贝回主内存，然后又通过一个Socket传到后台数据库，后来数据库查询ID返回健康码。

而整个过程中，健康码或者人脸图片都需要多个报文传递，这是一个标准的Service-Chaining的场景，而计算的路径和context需要跨越多个包，每个包都需要保序，因为乱序很容易导致重传，另一方面是数据库很有可能在内网或者云VPC内部，SRv6似乎可以保证通信，但是无论如何人脸识别的照片所产生的多个IP报文需要在推理服务器上被全部捕获下来，然后处理，这样的逻辑下，SRv6的segment在Service-Chaining场景下还会带来更多的负担。

而进一步从这个角度看， 容器启动通常非常快，而传统的DPU针对虚机的热迁移等技术或者SRIOV技术实际上逐渐也会因为虚机向容器迁移的过程中而变得非常鸡肋。

当然有些功能的确CPU做起来费力的，还是需要Offload的，看来看去也就ML推理、AI训练中的Allreduce和梯度、数据库的一些Sequenecer、加解密、Hash、压缩等，好好的做好自己的本分工作帮助CPU更好的交付应用才是DPU的关键啊, 正如昨天谈到的内容：

网络的本质是承载数据流，而内存是数据流在某个时刻的快照，而计算是基于快照信息而产生新的数据流。对于未来， 以应用为中心,并兼顾软硬件一体化的传输协议才是我们最迫切需求的，或者更加需要的是华为鸿蒙提出的软总线概念，或者简单来说就是多云RPC的框架，把云和本地终端构成一个大的操作系统，这才是DPU的最终意义。