一张图想到的故事…

昨天看到JNPR的一个图,一直觉得不完美感觉少点什么,半夜偶尔看Linux调度器的一些文章讲进程分为I/O密集和计算密集时,举了几个同时I/O密集和计算密集的反例,一下子想明白了,这图原来是缺了一个三角形:

一张图想到的故事...

这也讲清楚了困境,一颗芯片如果要同时兼顾计算密集和高度的可编程灵活性必定无法兼顾很高的吞吐,而困境的原因竟然又是非常简单的一个问题:内存墙一张图想到的故事...

很简单的一个道理就是,Cisco我们自己的Silicon One能做到19.2Tbps,ASR9000的LightSpeed+差不多400Gbps, 而完全可编程的QFP只能到100Gbps,同样的业务代码跑到X86上只能20Gbps,其实问题都在这里,越复杂的应用越需要多次访问内存,而片上缓存的容量决定了系统必定会有Cache-miss

那么在这个两难的境地下,该怎么做呢?针对I/O和计算双密集的场景下,I/O内存和计算内存的解耦就成了必然的选择,所以你会看到十多年前我们就想明白做好的东西, 整个工业界似乎还不懂, 以至于现在看到一些DPU公司,笑而不语…

另一个处理方式,前几天看到献涛的一个对话也讲的很清楚了:

此外,新一代神龙加入了对「可信计算与加密计算」的支持,实现系统可信防篡改与数据可用不可见,确保客户对「安全」的要求。

后续阿里云计划在所有数据链路经过神龙架构时做更多预处理,从而大大提升DPU的计算效率。原来计算1万条数据,所有数据都落到内存里挨个算,现在做预处理后可能只需要计算50条,这样一来,效率就提升了数倍。

据张献涛透露,接下来,除了做到速度更快、带宽更高、延迟更低、每秒IO次数更多外,神龙架构还将在性能、稳定性、安全性方面层层加码,推动神龙作为加密计算的载体。

面向未来,DPU领域可做的东西还很多。比如新兴的存内计算,本质上要解决的问题与DPU是一致的,即如何减少数据搬移,从而提升计算效率和降低功耗。所有数据经过DPU时都可以进行一次存内计算过滤,只有有效的数据才会进入主CPU内存,这样整个计算系统的性能也将会数倍的提升。

“纵观未来,你会发现尤其是今天异构计算变成潮流的情况下,几乎所有DPU努力的方向都是为了解决掉内存墙带来数据处理效率下降的问题。”张献涛相信,未来DPU的发展值得期待,并将一定和某种业务结合度越来越高。

然后另一个问题是Pipeline和RTC的区别,似乎很多人还是不太明白这个微妙的平衡,其实它们只是时空维度上的区分罢了,以时间换芯片空间,还是以芯片空间换时间,所以本质上又回到了延迟和吞吐的取舍上,当交换机芯片到了25.6Tbps以上时,功耗成为一个大问题,I/O和各种Serdes伴随着大的TM需求,那么取舍就很明显了,天底下没有什么新鲜事,都是取舍的艺术。

回到JNPR的那个图上,在Logical Scale上特意标注的一个ML~,有点意思,其实很简单的一个基于统计学的调度器就行了,然后使得Cache-Miss Rate降低,传统的做法是基于Flow Based Distribution做flow cache,也就是说五元组去调度到特定的核上处理,但是这种处理方式,又会面临路由收敛和DDoS下的巨大内存开销,例如某公司一个100Gbps路由器在一次集采中被我玩得1Gbps线速都到不了。

所以ML算法的本质就是在芯片内监控Cache-Miss Rate并根据CacheMiss来反馈调度,加权ByteDistribution和FlowDistribution及cache-miss rate, 并根据统计结果构造一个调度矩阵就好,因为在这么高的吞吐下要去做复杂的per packet ML逻辑几乎不太可能,最多也就可以玩玩Sflow、Netflow的ML。

还有一些解法就是直接把信息携带在数据包里,降低芯片的内存访问复杂度,因为这些信息直接就会在D-Cache中拿来用就行了,那么最典型的代表就是MPLS、SegmentRouting,而SRv6最大的问题就是没考虑D-Cache如何处理,又在编码的过程中为了压缩加入了Branch,都是拖累整个处理的昏招… 无奈了…

一张图想到的故事…》来自互联网,仅为收藏学习,如侵权请联系删除。本文URL:http://www.hashtobe.com/48.html