一些关于DPU的思考

转载自：知乎作者Simpo

Background

Datacenter Architecture

云数据中心通过超卖实现盈利，在满足用户需求的前提下，让各个类型的资源都充分利用将给云提供商带来更低的成本。因此资源利用率是至关重要的指标，然而现在的架构将计算资源，内存资源，存储资源按照固定的比例“装箱”，各个资源不能独立扩展，同时云上的负载类型又是多种多样的（计算密集型，IO密集型），不同的负载对不同的资源有不同的需求。这将带来资源的浪费，例如，内存资源不足而CPU资源充足时，为了添加内存还需要添加额外的CPU，这降低了CPU的资源利用率。下一代云架构从资源利用，管理的角度将采取Disaggreated架构，每个资源单独作为一个资源池，用户可以根据自身业务需求各个资源按需组合，云厂商也可以对资源进行弹性扩展。

Domain Specific Architecture

2017的图灵奖得主在2019年的A New Golden Age for Computer Architecture指出专用系统架构是后摩尔定律时代的一个机会，以硬件为中心的设计思路是设计针对特定问题和领域的架构，并给与它们强大（且高效）的性能。

DSA具有更高能效比的原因是：

1）DSA 为特定领域的计算使用了更加有效的并行形式

2）DSA 可以更有效地利用内存层次结构

3）DSA 在可接受时可以使用较低的精度

4）DSA 受益于以特定领域语言（DSL）编写的目标程序

Why We Need DPU

加速（推动Disaggreated）

随着摩尔定律和登纳德定律的放缓，CPU算力不再能够以较高的能效比处理这些数据，添加更多的CPU会带来更多的能耗和成本，同时更多CPU之间的协作将带来通信的开销，另外由Amdahl定律分析可知，并非所有的程序都能够从程序级并行获得收益 。另一方面是数据量的增长，根据Gartener分析显示在2025年全球数据总量将有185ZB，这里将有超出50%的数据存储在云数据中心，微服务和资源池化的使用增加了数据中心东西向流量，而东西向流量本身就是高带宽，延迟敏感的场景，并且在过去几年网络带宽增速高于CPU性能增速，网络和计算设备性能出现剪刀差，CPU将不能有效承载如此高带宽的流量。

综上所述，一方面是计算需求是爆发性增长 ，一方面是CPU性能提升缓慢，因此需要一个新的处理单元，新的系统结构来应对这一矛盾。DPU就是在这时提出，专为数据移动和安全处理而设计，以数据为中心的专用处理器。通过专用的系统架构以及新的互联方式高效地处理虚拟化，存储，计算，网络等CPU架构匹配程度不高的负载，释放更多的CPU算力给应用，从而建立起一个更加高效的算力平台。

对于DPU而言，其本身就是/包含了DSA结构，能够更好地进行数据移动，促进下一代数据中心高效的新架构。DPU通过集成众多加速器可以卸载CPU的功能，释放CPU算力给应用逻辑，并且专用加速器带来更好的能耗比，实现近网/存计算，减少数据移动的数量 。

管控

这么大一个数据中心，CPU是买的、DDR是买的、SSD是买的，而且供货渠道千奇百怪，任何器件出任何问题都不奇怪。这种基础下，如何能做到安全、容错、快速的资源调配？

虚拟化

1）计算节点虚拟存储（vDPA，Diskless）

2）DSA虚拟化（GPU，TPU）

Challenges

DSA Design: What to offload

1）一个关键的问题是在DPU中添加哪些DSA，这需要考虑DPU所要解决的问题处于的层次（IaaS，PaaS，SaaS），例如在IaaS层需要卸载基础设施的开销（vSwitch，CRC，NVMoF等），处于PaaS层可能需卸载Service Mesh的一些RPC操作（序列化等），处于SaaS层则需要根据具体的业务场景进行卸载。

2）然而这个负载适不适合卸载还需要考虑其他限制因素，比如内存访问效率，因为某些负载CPU不能很好处理的原因并不是算力而是内存等其他因素。例如，GPU可以较好地适应ML等负载，但研究表明这样的性能由于访存并没有充分利用。

3）另一要考虑的是具体的数据中心部署问题，如果说DPU中有许多功能模块，数据中心的DPU是作为一个统一的结构还是说针对不同的设备使用不同DPU产品可能需要权衡。

4）DSA并不是单纯的将软件使用硬件实现，而是需要抽象出一套公用的逻辑（或者说指令集，例如使用VLIW，SIMD），对于这一类的问题可以通过编程适应具体的业务。

InterConnect: How to Scale Out

1）网络互联（Inter-host），Disaggregated架构需要具有更高可扩展性，更低时延（包括平均时延和尾部时延）和经济的网络结构，然而现在TCP/IP，ROCEv2都不能满足这个要求，TCP复杂的协议栈和软件处理会带来更高和不稳定的时延，同时ROCEv2由于Go-Back-N机制要求下层的网络是无损的，因此使用PFC防止丢包，但引入了PFC暂停帧风暴以及死锁等一系列问题，同时由于片上内存的容量限制，对于RDMA可靠连接不能大规模扩展。因此，需要一个新的/改进的网络协议来承载Disaggreatd架构。（IRN，SRD，TrueFabric，MELO）

2）设备互联（Intra_host），由于摩尔定律的放缓，未来使用更多的DSA设备，如何让这些DSA协同工作需要更加高效的设备间通信协议，虽然当前PCIe带宽每代都会翻倍但与DSA算力提升而言仍然较慢，另外当前PCIe的时延接近1us，这限制了通过PCIe访问内存的性能。（CCIX，CXL，NVLink）

3）片上互联（intra-chip），此外，联系更加密切的功能模块会在一个SoC中进行协调通信，随着越来越多的IP模块加入SoC中，需要一个可扩展低时延的片上互联以及Die-to-Die之间通信协议。（NoC，UCIe）

4）边缘计算以及分布式数据中心网络协议（SDWAN）

Virtualization: How To Share

除了DPU内部包含的一些DSA加速器之外，会有其他的DSA（GPU，TPU等）将作为单独的设备池向用户提供。然而一个问题是当前除了CPU之外其他的包括GPU在内没有很好的虚拟化机制，并且似乎也没有必要向DSA里添加虚拟化的开销，这意味着如何让多个租户共享DSA（DSA上云），提供良好的隔离机制也是DPU所需要解决的问题。

Energy: How To Save

虽然解耦结构带来了诸多收益，但是也增加了数据移动的距离，增加数据中心东西向的流量，带来更多的能源消耗，如果DPU能够在数据搬迁的过程中就能够进行数据的处理，从而减少带宽的占用以及能源的消耗。

Flexible: How To Use

DPU 中的DSA获取性能提升之外，另一个需要面临的问题是使用DSA的易用性，例如数据中心的Overlay网络协议和存储协议需要经常进行迭代以及更新，同时云数据中心的负载不断进行变化，因此需要DPU/DSA能够提供一个更加灵活的编程接口。与DSA设计相似，需要根据DPU产品的定位决定这种灵活性的程度，如果会有较多开发者进行迭代开发那么提供一个类C的高级语言将是可行的方案。

Related Technology

从前面的章节中也可以看出DPU并不是一个单一的产品，需要结合上层业务，主机互联协议，片上互联，指令集等各个方面，在这些方面也都有一些非常重要的进展，如何与这些技术更好的结合是决定DPU未来形态的一个关键因素。

CXL

同样由于摩尔定律的放缓，需要其他的硬件来弥补算力，各个算力之间如何进行高效数据通信至关重要（通信的实质是共享内存）。然而通过PCIE设备的方式会面临以下几个问题：

1）需要DMA Driver来进行数据传输

2）PCIE事务层会带来严重的时延开销

3）数据首先放在主机内存中再拷贝（例如主存->显存）

4）在冯诺伊曼架构下，当前内存和算力仍然存在内存墙，需要Cache来隐藏延迟，而PCIe设备和主机之间内存一致性当前需要软件来实现，例如Mellanox Connect-X NIC中缓存的页表和QP，如果在NIC缓存不命中时将需要驱动进行处理，这个开销是相当可观的，这也是对于RC QP不能够大规模扩展的一个重要原因

在此驱动下产生了CXL，CXL包含三个部分CXL.mem，http://CXL.io，CXL.cache，在CXL spec上有更加详细的解释和说明。

UCIE

受限于制造工艺的良品率，同时为了提升IP复用，Chiplet进入主流业界，原来在同一个Die上的模块可以拆分成多个独立的die，在UCIE的协议层使用的是CXL/PCIe进行作为chiplet之间的通信协议。(怎么划分Chiplet也是非常关键的问题，毕竟Die-to-Die之间的通信会有性能损耗)

NOC

随着Chip中IP模块越来越多，基于总线和Crossbar的SoC会面临扩展性以及全局同步时钟所带来的功耗问题，NOC使用分层协议以及数据包交换路由实现更大规模的扩展，通过异步时钟减少功耗，并且相对于Crossbar减少了Tile面积。

MicroService

微服务 (Microservices) 是一种软件架构风格，它是以专注于单一责任与功能的小型功能区块 (Small Building Blocks) 为基础，利用模块化的方式组合出复杂的大型应用程序，各功能区块使用与语言无关 (Language-Independent/Language agnostic) 的 API 集相互通信。

Usage Type

DPU + CXL

1）未来网络上升到400/800Gbps，那么仅仅是网络就将占用大量的内存带宽，CPU可用的内存带宽更加少，这将给应用带来非常大的影响，因此，在DPU添加自己的内存用于接收网络流量，不与Host竞争带宽，当主机需要数据时通过CXL.mem获取需要处理的数据，另外在DPU中添加内存的另一个好处是片上加速器可以使用这个内存进行一些有状态数据流处理。

2）通过CXL.cache协议，将网卡缓存的一致性通过硬件实现这将提升缓存效率，减少软件处理带来的时延，例如Mellnaox Connect-X系列的可扩展性将会有所改善。

DPU + Memory Pool

耦合的内存池将带来较低的内存利用率并且不方便管理，因此，数据中心寻求能够将内存解耦的方法，但是与存储相比，内存比网络具有更加低的延迟和更高的带宽，因而分布式内存池会需要更加严苛的条件，需要仔细设计来达到目标要求。

1）如果内存池端不提供算力，那么需要在客户端进行同步协调，另外一些复杂操作需要多次网络交互。

2）如果在内存池端直接使用CPU，一方面会增加内存池的能耗，另一方由于软件的开销会带来不可预测的延迟（维持一个低尾部延迟对SLO至关重要，尤其在一些HPC应用中，MPI计算可能会等待最慢的那一个任务）。

因此，使用DPU构建分布式内存池是一个可选的方案，通过将内存池中的页表转化，指针解析，同步语义，分布式事务等操作进行硬件卸载，从而可以提供更加稳定的延迟和更高的吞吐。

页表转化：Object-based内存池（例如DAOS）不需要进行页表转化，用户给出一个对象ID就可以进行相应的读写，这省略了页表开销。页表的带来的好处是每个客户端只能访问自己的虚拟地址空间，提供更佳的隔离机制。（在具体的实现中为了进一步节约成本，可以提供比真实物理内存更大的虚拟空间，例如对冷数据可以进行Swap）

DPU + GPU/DSA

由DPU进行GPU/DSA虚拟化，如果说有多少GPU/DSA就按照多少去卖，这样实现会相对简单，但这给云提供商带来的收益很少，因此，还是需要进行GPU/DSA虚拟化；一个思路是在GPU/DSA这端的DPU中运行一个轻量级抽象层（控制路径），这个抽象层里的单元代表了一定的GPU/DSA算力，与用户其他资源进行组合售卖。

DPU + Service Mesh

当前Service Mesh组件以代理模式计算并转发请求，并且需要进行一定程度上会降低通信系统性能，并增加系统资源开销（MicroService Tax），通过将Service Mesh组件卸载到DPU中减少MicroService Tax，同时与业务负载进行隔离，在卸载之后例如Crypto，load-balancer（L4/7）以及安全验证等操作可以利用硬件加速实现。

DPU + DataBase

1）SQL解析：将OLAP数据库中核心的Sort、Filter、Join和Hash以及Regex/TS时间序列处理等操作分别进行了硬件加速，将SQL语句对应的Query Plan按具体组成部分直接映射到相应的硬件加速模块。

2）计算下推：对于SQL中的过滤表达式（where，join，TopN等）操作卸载到近存的DPU计算中，在靠近存储的地方对数据进行过滤，从而减少传输的数据总量。

3）EC校验存储，减少多副本开销，例如在RAID5 RMW算法中在DPU中进行校验值计算。

原文链接：

https://zhuanlan.zhihu.com/p/576234159

【活动专栏】

【转载须知】

若转载文章为原创文章，可在相应文章下或公众号后台留言；其他非转载类文章须在文首以不小于14号字体标明转载自SDNLAB。