谈谈nanoPU、片上网络、算力网络

先引用一下去年10月评论P4的一篇文：

P4语言本身由于pipeline的模型限制和命令式编程语法，导致它根本无法进行其它的处理，模块化能力几乎也为零，很多时候pipeline决定了一些模块复用和branch/jmp无法实现。然后到架构选择的时候，总是Pipeline快，RTC慢，Pipeline Recycle性能下降厉害，RTC基于流hash的无法处理elephant flow，单核IPC性能差。如何把数据包编码使得转发模型能够更好适应异构的硬件平台，编码上降低RTC-Pipeline-RTC这样的复杂切换流程，设计一种完备的DSL并且可以同时支持流量的RTC/Pipeline offload，这才是关键。

zartbot.Net，公众号：zartbotSRv6/P4/SDWAN都错了：一些看似离经叛道的苦口良药

其实Nick自己也意识到了这个问题，一方面P4社区在给P4加指令集，另一方面又要把P4弄到BPF编译，然后看到Netronome有了BPF的微核构成的智能网卡，最终搞出个NanoPU的东西：

也就是我去年说的：

本质上不要被花哨的定义搞懵逼了，这篇文章也道出了另一个关键的问题：在超过100个核心的ManyCore处理上，片上网络和通信延迟时一个必须要考虑的问题。
这篇文章的解决方法就是“Replacing the software thread scheduler and core-selector with hardware， by bypassing PCIe，main Memory and cache hierarchy completely”

最终P4的遗产还是要继承的，也就是在NDP的实现上，用来做拥塞控制和提高incast情况下的性能。

1.ManyCore的实践
其实很多人看到这里发现这不又回到了很多年前做NPU（Network 不是Nerual）的老路上了么？其实思科最早的QFP架构就是这样，Packet前面有专门的Classfication电路，然后存到一块GPM（Global Packet Memory）中, 然后调度给各个核处理。

当然思科把第一代只有40个Thread的处理器弄到了现在有896个Thread，也发现了一些问题和瓶颈，正如文章所述：

所以在去年初进行下一代处理器架构选型时，我也考虑过这个问题，最终的结论就是第四节所述的随路计算的一些东西。

2.算力的提供形式
其实文章中引用的Amin的这段话很清楚：

“Sustaining exponential scaling in our computing infrastructure 

requires much more predictable, low-latency,

CPU-efficient communication frameworks starting with RPCs,

rather than IP packets.”

Amin Vahdat, 2020

本质上这也道出了云计算下一阶段演进的本质，算力的提供形式更多的会以RPC(或者我们熟知的API形式)提供出来，提供的资源更加底层化，以至于整个云构建成一个巨大的操作系统。而承载这些算力的并不在意是X86还是ARM或者其它专用处理器。延迟便是一个非常关键的因素：
而中间的网络则可能需要分几种情况考虑了，一种是片上网络，即在单一硅片上如何做到核间高速通信，另一方面就是如何利用网络构建多芯片或者多子系统间的高速通信，实际上云计算逐渐的伴随着serverless和service-mesh架构，这样的东西在国内被赋予了一个“算力网络”的名字。

2.冯诺依曼架构的演进

CPU算力的增强却不得不应对内存的缓慢发展，于是逐渐的出现了L1、L2、L3 Cache的结构，事实上通信的延迟使得处理器的实际效率远低于峰值效率，下面这篇文章也是非常值得一读的：

本质上冯诺依曼架构一开始是为标量化的算术和逻辑运算而产生的，指令和数据的鸿沟天然的摆在那里，近代的异构计算或者处理器的AVX指令集等不过都是一些向量、矩阵的计算来降低指令和数据间的鸿沟。

3.内存计算：另一个极端

科学界自然也有很多走极端的，既然指令和数据之间存在鸿沟，那么为什么不把指令直接射到数据堆里呢？于是逐渐就诞生了一些内存计算的想法，或者说是存算一体化（In-memory Computing)的做法，或者说是Memory Centric架构。

4.网络计算：不是算力网络的网络算力

既然各有取舍， 在靠处理器的地方算有内存墙，在靠近内存的地方算又有材料成本和一致性等一系列问题，那么干脆折中一下，想起一句话：“不要通过共享内存来通信，而是应该通过通信来共享内存”，于是一个用空间换时间的想法就诞生了，也就是我去年一直在说的随路计算的问题。顺手在某司搞了一个专利。

当然我们基于FPGA的样机已经做好了，正在进行性能测试，最终会构成一个非常有趣的解决方案可能会在今年某个会议上以论文的形式弄出来。

5.传输层的最佳实践

你会看到本质上nanoPU是在想用一些标准的Socket通信来替代RDMA绕过PCIe，但是还是存在一个问题，NDP并不是一个最优的编码方式，加密通信和可控可信RPC访问以及如何使用Multicast、Broadcast语义构建RPC的东西Nick他们还没研究透，还有一些如何通过chain的方式做计算和同步的东西他们也没想明白。但是有一点是值得肯定的，这件事情一定会发生在Layer4 传输层上，如何借助已有的技术在传输层上构建可编程能力，便是一个非常有趣的事情。

一方面包内含指令，例如Segment Routing期望的可编程，另一方面程序根据包内含指令触发计算。Ruta在设计之初也是为了这个问题构建的。

为了实现3D-Torus拓扑，每台机器需要3张2x100GE网卡，分别连接X+，X-，Y+，Y-，Z+，Z-方向.这些链路可以采用服务器之间网卡直连的方式，当然也可以为了灵活部署全部接在交换机上划分VLAN/VXLAN的方式连接。Ruta会通过链路发现的方式将linkstate和互联拓扑同步到ETCD中，节点的SystemIP编号采用可以采用 10.X.Y.Z方式，这样的目的是可以根据XYZ的值做基于目的地址的路由，Ruta可以根据目的归属的Label或者SystemIP自由选择向dX/dY/dZ方向的方式完成路由。数据包的封装用SRoU实现即可。

zartbot.AI，公众号：zartbotA0001：分布式机器学习的网络优化

其实当我们构建算力网络的时候，被迫需要使用SDWAN或者SideCar的时候，是否可以想想，如果有这么一个标准的RPC协议，能够实现云端资源的调度，那不是更好。再集成好一些低代码能力，那不是更香：）