谷歌网络的贼船，你还想上？

拜读了一下夏老师在HPCA发表的关于NOC的论文,简单的评价就是:干净/漂亮. 同时正好网工的圈子都在转谷歌在NSDI上发表的Aquila,只能说差强人意吧,好的地方是给的数据中心网工们一个折腾的空间，但总觉得有点太复杂其它公司无法食用,而且感觉就是离应用太远了。

总体来看NOC+DCN两篇一起看懂了说明书服用疗效更佳，因为在去年曾经写过一个东西

<云网融合的探索>

华为基于应用定义的NOC

看大师的论文,一般来说一看标题< Application Defined On-chip Networks for HeterogeneousChiplets: An Implementation Perspective >就知道这玩意有戏了, 文章一开始就讲清楚了一个道理

三者不可兼得,对于Server-CPU很大程度上是延迟敏感的并且需要严格的处理tail-latency,而针对AI的场景是带宽敏感的,同时从架构上又需要有足够的表现力(原文为Expressiveness),但是你又不得不考虑冯机的大量的应用如何同DSA交互编程的问题,而最后就是物理实现的问题,片上网络的布线和功耗。然后还有一个关键的问题Cache-Coherence怎么搞？某司当年做网络处理器的时候就是简单粗暴，没Coherence的需求不搞，甚至连L2-D都么有.但是夏老师讲的很清楚，他们是做通用处理器的，所以stick to the shared memory abstraction无可厚非(渣也表示赞同,毕竟通用处理器还需要面对大量的普通程序员的代码，易于使用比什么都重要)

让人眼前一亮的就是这个图，简单、干净、漂亮的解决方案

把Cache这么玩，渣的内心想法就是：“艹，我怎么没想到”，通用CPU L3-Tag和L3-Data的分离做的太漂亮了，而同样的方式针对AI处理器的L2$分撒在NOC上，再加上RBRG以及非常简单的I-Tag、E-Tag机制，干净简洁。

你看上面这图，Cache Access的延迟和L3Cache大容量和带宽，特别是per-core能够使用的带宽一下子就上去好多，同时连接I/O的die也非常简洁高效，一个Ring Bridge就完事了。所以我一直善意的提醒国内某个做多核ARM的DPU厂商，你们Memory Subsystem有问题，因为ARM自己的那套NOC讲真我觉得不舒服，可惜人家就是不听还要犯一次当年XLR的错误才会懂。

谷歌Aquila

首先业务的需求是要在公有云上跑HPC，这是很多企业未来几年的刚需，也是公有云业务的增长点，但是呢对于公有云又不想两张网来搞，然后卖螺丝的网卡和TOR交换机也贵，然后很多普通的HPC业务例如CFD一类的通常对于延迟更加敏感，而RoCE一类的又有各种各样傻X的问题，然后HPC计算又可以有很好的局部性处理，但是传统的TCP各种事情又搞不定。

以上这是Aquila的前提，但请注意这是一个实验性质的网络，和Google以往的作风不同的是，它并没有像以前那些大作一样商用几年了再来把其它厂家按在地上摩擦，同时它并不能简单的泛指下一代数据中心网络，当然国内的网工们呢可以用抄作业为名暂且避过互联网的寒冬，问题是你们的运维能力和实施能力离谷歌肯定还有一些差距，这个时候一些设备厂商的Vendor(说的就是BRCM、Cisco以及国内一些DPU厂商)能不能顶上呢？

总体来说的设计就是针对HPC的局部超低延迟通信需求，构建的一个拓扑，然后为了和一些美国国家级的EFLOPS超算抢生意，所以拓扑也采用了DragonFly

然后为了消除抖动(更明确的说是尾延迟)，采用了信元路由的机制，信元头是8B，由pod-id、TiN id和Endpoint-id编码， 16bits的SRC、DST、Cell-Length、VC、TTL、8bits CRC和Trace Enable bit，然后每个TiN都有信元路由的能力，信元最大160B，看上去觉不觉得这是一个大号的ATM？然后Deadlock避免机制用了VC，说实话我很讨厌这玩意，说不出来为啥就是觉得不舒服。

然后整个芯片呢是一个100GE以太网MAC和32个28Gbps Serdes以及2个PCIe3.0组成的

虽然他们称这东西是一个ASIC，但是我觉得Google应该不会为一个实验性质的东西去流片，而且从这些参数来看，感觉可能一个Xilinx KU15P就能放下这些逻辑(可以参考思科的Nexus 3550低延迟交换机)，然后做几个PCB应该整个成本不算太高

而控制器呢，沿用了以前的Orion

敲黑板，分布式控制器，具体的分析见下文

<Google Orion：终于SDN走到了分布式控制器时代>

而对于信元的发送和接收，片上有相应的Ingress和Egress的Buffer，然后通过RTS/CTS信号控制收发及信元重组，调度算法上当然还是在用Nick教授20多年前给Cisco GSR设计时用的iSLIP算法以及一些weighted的增强，总体来说就是实现了多路径的adaptive route

但是至于这个CostEffective，省了网卡的钱，整合进TOR了，但是布线的钱和维保的运营开销呢？

非以太网的东西本来各种器件的价格就会高蛮多的，所以你看AWS SRD和我自己做NetDAM一定是underlay要用以太的，特别是在更高速的场景里，延迟肯定会进一步增加，感觉这事情做的有点过了，当然毕竟是一个研究实验性质的网络嘛，然后又要搭DragonFly的拓扑，可以理解。

从另一个方面来看，这是一个很好的TOR的实践，把网卡从主机再一次剥离出来，直接PCIe到TOR

你可以看到思科自己的UCS-X也在玩类似的事情，

背板有相应的PCIe、CXL交换的空间，并且也把网卡和背板集成在一起了

局部来看，为了降低延迟更加的紧耦合是有必要的，但是这么做总觉得有些不干净，因为这玩意是延迟低啊，但是带宽大了主机的DMA内存墙的问题依旧没有干净的解决，虽然有Snap这样的软件系统去辅助，但是使用效果对于通用的云计算来讲还是相对。。。

另一方面，这个工作和真正的AI团队又是有一定距离的，总觉得Aquila是一个KPI的项目，而真正的重心和值得关注的还是在TPU集群和Pathway这样的东西上，那些才是未来变革的力量。

结语

很多时候吧，外国的月亮不一定圆，谷歌这个东西吧还是太网络团队了，和应用离得远和底层NOC离得远，两边都不讨好，还搞得特别复杂。而夏老师他们做的东西简单、应用直接爽到了，所以建议大家要有一些架构上的自信。

对谷歌Aquila感兴趣的同学点个赞和在看后，在公众号后台回复“Aquila”可以获取相关下载。