前往小程序,Get更优阅读体验!
立即前往
首页
学习
活动
专区
工具
TVP
发布
社区首页 >专栏 >智能网卡的智障需求

智能网卡的智障需求

作者头像
SDNLAB
发布2021-07-27 11:53:28
1.3K0
发布2021-07-27 11:53:28
举报
文章被收录于专栏:SDNLAB

❝智能网卡也进入了一个盲人摸象的年代,每家都在做却没有一家做好,如同当年的SDWAN,大家疲于奔命的往上加功能,你抄我我抄你。所以写下一文来谈谈智能网卡的最小(智障)需求, 别被某些头部企业带偏了:) ❞

很多事情,我们想不明白只是因为没有从根源上去分析,那么我们来从智障网卡说起,来谈谈智能网卡的最小需求.

网卡是什么?

从硬件的视角来看,网卡芯片就是一个以太网控制器的IP核和一个PCIe的IP核,然后通过AXI接口连起来.无论你玩什么智能,无非是在AXIStreaming中加一些小功能。

如果详细到细节,以100G为例,QSFP28接收后会有4对信号线,然后RS-FEC可选,然后PCS中retiming,并完成64b/66b解码,通过CGMII接口到MAC,MAC中会有一些AN自动协商链路训练的逻辑,以及收发的CRC校验逻辑,流控逻辑,处理完成后变成AXIS总线协议往内传输。最简单的网卡就是直接给到PCIe的AXIS接口,然后DMA到主内存。当然还有一些特别的直接进CPU LastLevel Cache的,例如Intel的DDIO,这个都是特例。

为什么要强调基本的网卡转发呢?因为一切复杂的东西都是在基座上慢慢搭建的,总结这一段,本质上最简单的网卡是以太网协议然后通过PCIe DMA到内存(反向亦然),更直白的说是以太网协议和PCIe协议互转的一个转换器。这一点和最早期的路由器类似了,也是转换不同的介质。

❝所以为什么你会看到一些传统的做路由器网络芯片的厂商,例如Marvell Octeon、Netronome会突然宣称自己也是做DPU的,本质上就是因为智能网卡和多业务路由器基本上是一个同构的东西.这些后面还会强调. ❞

网卡的演进

早期为了解决虚拟化场景的问题,SRIOV中的VF是不是和路由器中的子接口和VRF类似了吧,然后就是一系列Kernel bypass的处理方式,Cisco的userspace nic或者Solarflare onload,还有一些TCP offload engine。当然还有更激进的直接把一些运算逻辑在网卡上处理,这些在高频交易场景中非常常见。因此你会看到一些做高频交易设备的厂商也混进来搞智能网卡了,例如Xilinx收购solarflare,思科收购Exablaze。

云计算的网卡需求

当然最出名的几块智能网卡不得不提 AWS的Nitro、Azure的FPGA和阿里云的神龙。我们暂且不谈RTC和Pipeline、FPGA和ARM的不同技术路线,简单的来看一张云计算的网卡有什么需求,归根到底是

❝"流动"基础设施要求池化资源能够动态按需的拆分和组合 ❞

基础设施的池化资源通常简单可看做:CPU 内存 存储 网络的按需组合。

拆分->虚拟化

例如一个CPU几十个核,拆分了卖也就是对应的虚拟化架构,例如以Nitro为例,AWS最早基于Xen的虚拟化I/O路径太长,消耗太大,因此逐渐的开始进行优化,例如C3开始使用SR-IOV ,然后C4开始将远端的存储(EBS Volumes)通过新收购的Annapurna以NVMe的形式呈现给虚机。然后X1开始将VPC的一些功能加入,同时也负责磁盘的监控、加密和QoS等业务。最后到了2016~2017这个时间段,唯一的问题就是原来的hypervisor了,最终裸金属出现了.然后到了这个时间段,基本上网卡、存储、各种加速卡、外设都可以虚拟成PCIe设备了。所以你会看到最近AWS发布的基于Apple M1的虚机,直接一根雷电线查到MAC mini上。

组合->DPU

而组合则是将多个CPU socket连接,并attach相应的内存和存储按需构建,也就是Fungible一直强调的DPU概念。

但是这个概念的最大问题来自于整个Fabric需要Fungible的私有协议,无法多厂商互联,特别是内存如何以池化的方式加载,这便是IBM提出OMI的原因,以及AMD Zen4逐渐也会采用类似的处理方式:

按需->QoS和拥塞控制

按需又暗含了另一个词,按量供应,也就是需要各种队列和延迟控制、拥塞策略来满足SLA,这些不就是路由器中的QoS么?而对于那些NVMeOF一类的技术,简而言之看成各种VPN技术不就行了么?

小结

所以你会看到NVMe这样的标准把存储先PCIe化,然后CXL内存总线串行化,最终的目的就是在协议上慢慢融合,最终在机架内部会被PCIe总线整合,那么做个PCIe交换机就行了啊,但是为啥智能网卡这种类似于路由器的设备会火呢?PCIe传输距离和以太网成本优势。

因此稍微做个总结:

❝在单个机柜内部可以通过智能网卡并使用PCIe按需构建,但是在一个数据中心多机架环境依旧需要使用以太网技术。在跨越多个数据中心和边缘云场景中,还需要SDWAN融合智能网卡。 ❞

所以智能网卡的最智障需求就是:

  • PCIe和以太网传输协议的互通及互相Overlay
  • 符合资源拆分场景:实现裸金属虚拟化
  • 符合资源组合场景: 实现多池化设备动态组网
  • 拥塞控制: QoS和swift一类的拥塞算法,满足SLA需求.

基于这样的解释,你也就会不难理解一张智能网卡什么是刚需了。

智能网卡的SOTA

智能网卡现在工程实践上遇到的一系列问题,本质上来自于做网卡的人有大量的先入为主的思维方式,并且以自己的业务条线来盲人摸象,当然就出问题了。

  • Pensando本质上是在传统的ToR overlay下看到TCAM资源不够用,因此需要进一步分布式的来处理,所以他们的场景中更多的是把交换机和部分防火墙能力在智能网卡上赋能。
  • Fungible的问题是私有的TCP拥塞控制算法,然后DPU的概念包装上没讲清楚,虽然基本的功能都有了..
  • BRCM:Stingray,可编程能力未知,反正也是属于不知道该干嘛的那种..
  • Mellonax:CX5、CX6采用ASIC Offload配合X86可以玩不少事情,Offload了一部分东西,另一方面Bluefield本质上是来自于Tilera的众核NP技术,但是和BRCM一样,A72的核太老了,而且产品线的原因,在ARM生态上布局太少.
  • Netronme:基于最早Intel IXP的技术,开发难度还是蛮大的,生态并不好
  • Intel : FPGA还不错,可以玩一些事情,但是说实话工艺落后Xilinx太多,然后FPGA+Xeon....
  • Xilinx : 收购Solarflare,然后还是卖卡为主,只是开发难度有些高,对软件工程师不是太友好,还需要多建立生态,但是我还是比较看好,特别是手上另一个跟他们合作的项目。
  • Marvell: 在DPDK的ARM生态建设上很不错,新的DPDK 21.05 Release note透露了一块XPU。

总体来说,智能网卡面临着和异构数据中心的CPU GPU 内存抢供电的窘境,因此通常不会给单块智能网卡外接电源,75W的功耗墙在那里,而FPGA虽然可以做很多事情,但是开发周期和软件迭代速度都是问题,例如干一个xxx需要两个月我就不多说了,纯CPU多核的,基本上也就是多核ARM,现在性能有一些问题,和以前路由器一样,基于NP的吞吐总归没有基于ASIC的好,延迟也相对大一些。但是未来我还是很期待ARM Neoverse 2的架构以及AMBA CHI总线,可以干很多事情,再配合一点点的批处理引擎(这一点很认同Pensando的做法,在DMA和Ethernet上配置P4处理矩阵)就很容的构建了FastPath和SlowPath的架构了。

智能网卡工程实践

当然各家有各家的问题,解决性能的问题来自于应用,特别是下面这个图

应用程序的编程语言决定了走不同的路线。例如阿里系Java保有量太大所以有些事情只能硬件做,但是鹅和头条这些基于C艹或者Go的自然就可以用别的解法,例如使用纯软件的做法,基于VPP的Memif也可以干很多事情,还是那句话:

❝Software when you can, hardware when you must. Whenever possible, compute, networking, and storage functions should be done in software where reasonable performance can be attained. ❞

归根到底,同源同构尽量和通用的东西兼容才是最佳实践,任何一个私有化的东西都不会成为生态。所以这也是我构建Ruta协议的原因:

智能网卡展望

智能网卡的控制器该如何设计,这也是一个大家还没开始想的问题,如何完成多种智能网卡的互联互通,如何构建软智能网卡,如果把智能网卡看作路由器,谁来实现新一代的OSPF、MP-BGP路由协议,如何在以太网上完成加密传输和拥塞控制?控制器还用OpenFlow么?数据面除了P4的PNA还有别的做法么?P4相对于写Verilog还是方便不少,但是还是有太多的业务逻辑需要RTC的多核CPU完成,那么这些业务逻辑对应的协议栈是否可以优化呢?VPP、DPDK是否可以构建软硬件一体化的一个智能网卡协议栈呢?都是一系列需要仔细探讨的问题。

这是一个最好的时光,但不要被各种tricky的offload浪费了。这也是一个最差的时光,你不做,应用会自己演进把这一切做了。

❝It was the best of times, it was the worst of times, it was the age of wisdom, it was the age of foolishness, it was the epoch of belief, it was the epoch of incredulity, it was the season of Light, it was the season of Darkness, it was the spring of hope, it was the winter of despair, we had everything before us, we had nothing before us, we were all going direct to Heaven, we were all going direct the other way --in short, the period was so far like the present period, that some of its noisiest authorities insisted on its being received, for good or for evil, in the superlative degree of comparison only. ❞

本文参与 腾讯云自媒体同步曝光计划,分享自微信公众号。
原始发表:2021-07-05,如有侵权请联系 cloudcommunity@tencent.com 删除

本文分享自 SDNLAB 微信公众号,前往查看

如有侵权,请联系 cloudcommunity@tencent.com 删除。

本文参与 腾讯云自媒体同步曝光计划  ,欢迎热爱写作的你一起参与!

评论
登录后参与评论
0 条评论
热度
最新
推荐阅读
目录
  • 网卡是什么?
  • 网卡的演进
  • 云计算的网卡需求
    • 拆分->虚拟化
      • 组合->DPU
        • 按需->QoS和拥塞控制
        • 小结
        • 智能网卡的SOTA
        • 智能网卡工程实践
        • 智能网卡展望
        相关产品与服务
        VPN 连接
        VPN 连接(VPN Connections)是一种基于网络隧道技术,实现本地数据中心与腾讯云上资源连通的传输服务,它能帮您在 Internet 上快速构建一条安全、可靠的加密通道。VPN 连接具有配置简单,云端配置实时生效、可靠性高等特点,其网关可用性达到 99.95%,保证稳定、持续的业务连接,帮您轻松实现异地容灾、混合云部署等复杂业务场景。
        领券
        问题归档专栏文章快讯文章归档关键词归档开发者手册归档开发者手册 Section 归档