PCIe的候选？CCIX的应用实例评估_主机_加快器

当将主机 CPU 上基于软件的传统处理与专用硬件加速器相结合以实行异构打算以得到更高的性能或更高的效率时，主机和加速器之间接口的性子是一个关键的设计决策。

对付大多数离散加速器，例如 GPU 或 FPGA 板卡，PCI Express（简称：PCIe）长期以来一贯是紧张的接口。
其性能稳步提升，最新广泛支配的 PCIe 4.0 版本达到每通道 1.97 GB/s。
然而，PCIe 紧张针对高吞吐量批量传输进行了优化。
例如，如 [1] 所示，须要 128 到 256 KB 的传输才能达到至少 50% 的理论带宽。
对付细粒度主机-加速器交互所需的较小传输大小（降至缓存行大小），可实现的吞吐量显著低落。
虽然 PCIe 添加了诸如地址转换做事 (ATS) / 页面要求接口 (PRI) 之类的扩展来支持共享虚拟内存或原子操作，但大多数实现并不包含缓存同等性机制。

这使得细粒度的交互变得非常昂贵，由于在同步实行或交流小参数或结果时，主机或加速器端都须要缓存刷新，或者用于数据传输的内存区域必须标记为未缓存，从而减慢它们所在物理位置的处理元件（主机或加速器）的访问速率。

为理解决这个问题，已经提出了许多还涵盖高速缓存同等性的接口和协议。
在这项事情中，我们研究了加速器缓存同等性互连 (CCIX) 的利用，这是第一个被指定为多供应商标准并跨多个不同加速器和主机架构实现的接口。
一旦得到更广泛行业支持的 Compute Express Link (CXL) 等协议进入市场，估量在不久的将来会有进一步的改进。

我们供应了各种 CCIX 访问场景的详细低级丈量，以及运用程序级用例。
后者在运行利用近数据处理 (NDP) 的数据库管理系统(DBMS) 时，采取 CCIX 实现 FPGA 加速器和主机之间的高性能同步。
据我们所知，这是第一次为此目的利用缓存同等的加速器接口。

我们将不才一节中概述一些接口和协议，然后在第 III 节中谈论 CCIX 细节，尤其是关于FPGA加速器的内容。
不过，我们的紧张贡献是评估，我们在第四节中先容了低级特色，在第五节中先容了运用程序级用例。
我们在第六节中总结并期待未来的事情。

a) PCIe：PCI Express [2] 是将外围设备连接到桌面和做事器系统的标准。
PCIe 通过为单个设备捆绑多个通道来扩展链路的带宽。
在 1.0 版中，它能够以每通道 250 MB/s 的速率传输。
每个后续版本的带宽大约翻了一番，现在在 6.0 版本中达到了每通道 7.88 GB/s。
目前，6.0 版本刚刚被指定，而 5.0 的硬件即将推出，4.0 是当前硬件上支配最广泛的版本。
PCIe 利用全双工串行链路，采取点对点拓扑构造，在电气链路层之上有两个附加层，即数据链路层和事务层。
这些附加层供应纠错和基于数据包的通信。
除了传输数据、设备初始化等基本操作外，PCIe 还支持更高等（可选）的功能，例如 PRI 和 ATS，但不包括缓存同等性。

b) CCIX：CCIX [3]、[4] 是一种高等 I/O 互连，它使两个或多个设备能够以同等的办法共享数据。
在物理层上，它可以与PCIe 兼容（只管它可以选择许可更高的信令速率），并且仅在协议和端点掌握器上有所不同。
它由 CCIX 同盟于 2016 年推出，该同盟由 AMD、ARM、华为、IBM、Mellanox、高通、赛灵思 [5] 创立。
CCIX 已在基于 ARM 和基于 x86 的 CPU 上实现。

c) 其他共享虚拟内存 (SVM) 或缓存同等性 SVM 互连：CCIX 并不是共享虚拟内存互连的唯一竞争者。
阿里巴巴集团、思科系统、戴尔/EMC、Facebook、谷歌、HPE、华为、英特尔和微软在 2019 年基于英特尔之前的事情提出了 CXL [6]。
虽然 CCIX 可以在较旧的 PCIe 连接上运行，但 CXL 最初是基于 PCIe 5.0 设计的。
因此，CXL 可以达到每个通道高达 32 GT/s（即 3.94 GB/s），它供应与 CCIX 类似的功能，但利用不同的逻辑视图。
CXL 已经看到比 CCIX 更广泛的工业运用，并有望成为未来几年的紧张办理方案。

另一种选择是 IBM 于 2014 年推出的 Coherent Accelerator Processor Interface（CAPI，后来的 OpenCAPI）。
虽然第一个版本也是在PCIe 之上实现的，但最近的版本是供应商特定的接口。
CAPI 紧张用于基于 IBM POWER 的主机，因此其范围比CCIX 和 CXL 更有限。
在 OpenCAPI 3.0（x8 通道）中，它供应 22 GB/s 的带宽和 298/80 ns [7] 的读/写延迟。

虽然不是像 CCIX 那样直接扩展 PCIe，但支持缓存同等性协议的另一个互连是 Gen-Z [8]。
它每通道供应高达 56 GT/s 的速率，并许可与 PCIe 类似地组合多个通道。
只管具有令人鼓舞的功能，但尚未商业发布 Gen-Z 硬件，该技能将合并到 CXL中。

d) FPGA 上的数据库加速：[9] 很好地概述了利用 FPGA 加速数据库操作。
最常见的方法，例如在 Centaur [10] 等最前辈的办理方案中利用的方法，采取 FPGA 作为大规模过滤、排序、连接或算术打算的卸载加速器。
但是，这种操作模式会带来大量数据从 FPGA 传输到 FPGA 的本钱，并且与这里研究的旨在避免这些传输的近数据处理方法不同。

本节将概述通用 CCIX 架构，并谈论如何在两个不同的 FPGA 系列中利用它。

A.总体概述

设备在端点连接到 CCIX。
对付这里的谈论，干系类型的端点是归属代理 (HA) 和要求代理 (RA)。
HA 充当物理内存的“所有者”，它供应对物理内存的同等访问，而 RA 通过与拥有的 HA 通信来实行对远程内存的非本地读取和写入。
CCIX 与 PCIe 的差异在于 RA 可以供应自己的缓存，但通过 CCIX 保持与 HA 的同等性。
在 HA 侧，缓存状态的变革将通过发送适当的传播到访问的 RA。
CCIX 本身利用物理地址进行访问，但可以选择利用现有的 PCIe 机制来许可加速器利用虚拟地址。
为了实行实际的地址转换，CCIX 依赖于 PCIe ATS 机制，这也是 CCIX 附加的加速器也在不同的 PCIe 虚拟通道 (VC) 上保持与主机的传统 PCIe 连接的缘故原由之一。
在包括网格和交流层次构造在内的各种 CCIX 拓扑中，我们采取了一种大略的拓扑，它依赖于主机和加速器之间的直接连接。
此外，由于硬件接口级别支持所有必需的操作，包括地址转换和同等性，因此主机上不须要分外的设备驱动程序或自定义固件。

图1 中间 (A)：具有 CCIX 功能的主机的架构，充当 HA，附加 CCIX 的加速器充当 RA。
左 (B)：在 Xilinx UltraScale+ HBM 器件上实现CCIX-RA 的 SoC。
右 (C)：在 Versal ACAP 设备上实现 CCIX-RA 的 SoC。

图 1-(A) 显示了支持 CCIX 设备的高速缓存同等性主机 FPGA 附件的高等架构。
此框图的顶部是主机，底部是加速器，两者都通过支持 CCIX 的 PCIe 接口连接。
CCIX 在 PCIe 事务层上利用多个VC，在同一个 PCIe 插槽上传输 PCIe 和 CCIX 流量。
在支持 CCIX 的插槽上，事务层对 PCIe 数据包利用 VC0，对 CCIX 数据包利用 VC1，共享相同的物理层和链路层。
但是，CCIX 可以选择利用扩展速率模式 (ESM)，这会增加信令速率。
对付我们利用的 PCIe 4.0 附件，ESM 将速率从 16 GT/s 提高到 25 GT/s，每次传输 128 个有效负载位。
如果双方（即 RA 和 HA）都支持，ESM 模式将在勾引时的 CCIX 创造阶段自动启用。

B.利用 Xilinx XDMA的 FPGA RA

Xilinx Virtex UltraScale+ HBM 器件支持 CCIX，但必须以扩展 XDMA IP 块的形式将 CCIX 功能实现为可重新配置的“软”逻辑。
如图 1-(B) 所示，关键模块包括一个支持 CCIX 的 PCIe 掌握器、一个 ATS 交流机和一个 PCIe-AXIMM 桥。
ATS 开关用于通过 PCIe VC0 将虚拟到物理地址转换要求插入到常规 PCIe 通信中，然后检索它们的结果。
它还包括一个小的地址转换缓存 (ATC) 来缓冲现有的转换结果，以避免对已知映射进行相对昂贵的地址转换。
AXIMM 桥供应主机和加速器之间的内存映射通信（紧张是掌握平面流量）。
对付数据平面访问，加速器采取了利用赛灵思系统缓存 IP 块 [11] 实现的片上缓存，该缓存又利用 CCIX 流协议与 CCIX 同等性机制交互。
此缓存中的未命中成为远程内存访问，通过 CCIX 转发到 HA 以检索数据。
反过来，HA 确保了 FPGA 端 SC 与主机端缓存的同等性。

C.利用 Xilinx CPM 的 FPGA RA

最新的 Xilinx Versal 器件在其芯片中优化了对 CCIX 的“强化”支持。
详细来说，同等性和 PCIe 模块 (CPM) IP 块 [12] 包括一个集成的 L2 缓存，利用ARM的CHI协议与芯片范围内的同等性网状网络通信，后者又利用CXS 与支持 CCIX 的 PCIe 掌握器接口。
与之前在UltraScale+设备中一样，两个 PCIe VC 用于分离在同一PCIe插槽上运行的PCIe和CCIX流量。
我们的设置只须要CPM模块供应的两个支持CCIX的PCIe 掌握器之一。
ATS Switch 和 AXIMM 块与以前一样利用。

D. 地址翻译

在系统缓存 (SC) 收到来自加速器的读/写要求后，它会检讨 ATC 的虚拟到物理映射。
如果 SC 在 ATC 中没有找到有效的转换（即ATC未命中），它会通过 VC0 利用 PCIe ATS 功能向主机要求转换。
系统缓存上的 ATS 接口利用要求完成协议 [13] 通过四个流接供词给翻译做事：传入完成者要求 (CQ)、传出完成者完成 (CC)、传出要求者要求 (RQ) 和传入要求者完成（RC）。
来自主机的回答（例如，保留物理地址）利用相同的机制通报回 FPGA。

E. CCIX 时序模型

CCIX 事务的均匀延迟如公式 1 所示。
每个事务的延迟取决于ATC中可用的有效缓存地址转换的概率与ATS必须从主机要求新转换的概率，以及所要求的数据是否存在于本地片上缓存中。
必须从远程 HA 要求。
请把稳，利用 ESM 时，物理 CCIX 延迟可能比物理 PCIe 延迟更短。

我们在真实硬件中进行实际评估，即利用支持 CCIX 的 ARM N1-SDP 平台作为主机，利用分别具有UltraScale+ HBM 和 Versal ACAP FPGA Xilinx 的Alveo U280 (AU280) 和 VCK5000 CCIX附加板作为加速器。
表I显示了不同设备的规格。

A. 丈量设置

稍后描述的所有低级基准测试都利用相同的基本丈量方法，该方法由三个紧张组件组成：软件运用程序编程接口 (API)、硬件模块和上述片上 CCIX 组件。
软件 API 在主机上运行，卖力实行基准测试并读取硬件剖析的 CCIX 延迟特性。
软件 API 有四个紧张任务：a) 在主机内存等分配缓冲区，b) 初始化硬件模块以访问丈量，c) 检索硬件模块记录的延迟数据，以及 d) 剖析结果。
软件 API 的伪代码如算法 1 所示。
请把稳，我们将地址随机化以逼迫 SC 未命中，从而确保我们感兴趣的 CCIX 传输实际发生。

称为 CCIX 流量天生器 (CTG) 的硬件模块利用获取/存储方法来捕获 CCIX延迟。
该模块接管来自主机中软件API的 startTrans 调用的要求（包括类型、虚拟地址和长度）。
在 API 要求之后，CTG 通过 AXI4-MM 接口向 SC 创建要求，SC 实行 CCIX RA 的角色，然后打算相应到达 SC 的韶光。
然后可以通过软件 API 读取捕获的时序。
请把稳，我们仅在其所有数据到达后才认为事务完成。

表II 显示了我们检讨的大略 CCIX-RA 所需的 FPGA 资源。
如图 1-(C) 所示，VCK5000 利用硬化 CPM 模块形式的 PCIe 掌握器，但仍须要一些额外的“软”逻辑来支持 PCIe 传输和 ATS 转换。

B.Low-Level实验评估

实验 1：CCIX 与 PCIe - 延迟和吞吐量。

在这个实验中，我们比较了细粒度交互中相对较小的块大小（32B 到 16KiB）的 CCIX 和 PCIe 传输延迟（并且比 [1] 中检讨的 PCIe 批量传输要小得多）。
开源 TaPaSCo [14] 框架用于测试 DMA 传输。
在这个实验中，通过确保地址转换已经存在于ATC中来肃清 ATS 延迟。
图 2-(A) 和图 2-(B) 分别显示了 PCIe 和 CCIX 流量的读取和写入延迟。
对付 PCIe-DMA 传输，我们利用TaPaSCo 的高性能 DMA 引擎，通过设置不同的数据传输大小，直策应用主机内存数据的物理地址。
对付 CCIX 丈量，在主机内存等分配一个缓冲区，并将其虚拟地址通报给 CTG 模块。

图2 比较 AU280 和 VCK5000 上的 CCIX 和 PCIe 读/写访问延迟

我们的评估表明，在AU280和VCK5000上，与 PCIe-DMA 传输比较，CCIX 传输具有更好的主机读取延迟，只要传输的数据短于 4 KiB。
在这两种情形下，加速都是由于 CCIX 利用的优化数据包协议。
但是，当利用优化的数据包协议从 FPGA 写入主机存储器时，CCIX 会产生比 PCIe 传输更长的延迟，由于这些写入参与了同等性机制。
我们的吞吐量丈量显示，对付 1KiB、16KiB 和 32KiB 的数据集大小，CCIX 的读取吞吐量相对付 PCIe 分别为 3.3x、1.29x、0.87x。
读取和写入吞吐量的其他数据点显示在表 III 中。

实验 2：ATS 的本钱。

透明地解析虚拟地址的能力大大简化了加速器设计和主机接口。
但是，该操作可能代价高昂，由于如果要求的转换不存在于主机 IOMMU 的 TLB 之一中，它可能会触发主机上缓慢的完全页表遍历。
在实验 1 中，我们检讨了不须要地址转换 (noATS) 的访问。
但是为了检讨 ATS 的本钱，我们现在构建了两个访问场景，如图 3 所示：在第一个场景中（利用 ATS），我们逼迫在 SC 和 ATC 中未命中，因此总是会产生 ATS 开销。
在第二个（noATS）中，我们许可 ATC 命中，但仍旧逼迫 SC 未命中，以便实际发生 CCIX 事务。
结果表明，特殊是对付较小的传输，ATS 开销可能很大，导致 ATC 未命中时的访问延迟增加三倍。
但是，对付 32KB 及以上的传输，传输韶光开始主导 ATS 开销。

图3 ATS 对从 Alveo U280 卡和 VCK5000 上的 CTG 模块随机访问 RA 模块的 CCIX 访问延迟的影响

为了进一步研究 ATS 延迟，我们可以利用全体 ATS 机制在 SoC 的 ATS Switch 块中实现的事实。
因此，我们可以监控该模块的要求/回答接口，以捕获 ATS 操作本身的确切要求-相应韶光。
图4显示了 64 B（高速缓存行大小）、128 B 和 4 KiB 块的 CCIX 访问延迟。
由于 Linux Page Size 为 4KiB，因此这些要求每个只须要一个 ATS 转换。
通过增加要求的大小，须要更多的翻译。
对主机内存等分配的缓冲区的初始访问具有最长的延迟。
往后的顺序访问具有较少的 ATS 开销，纵然在 4 KiB 跨到另一个页面时也是如此。
我们假设这是由于主机 IOMMU 对此处利用的顺序访问实行了预翻译。
对付重复 64 B 读取的情形，通过比较主机 IOMMU 相应 ATS 要求所需的延迟（≈ 617 ns，在 ATS 交流机处捕获），以及在 SC 未命中情形下读取 64B 的已知延迟（≈ 700 ns，来自图 3-(A)），ATC 本身彷佛须要 (2453 - 617 - 700 ≈ 1136 ns) 进行操作。

图4 比较 Alveo U280 卡上 CCIX-RA 的读/写延迟和 ATS 延迟

改进 CCIX 流量延迟的一种方法是减轻地址转换的影响。
例如，这可以通过利用Linux大页面支持来实现。
这将导致更大的页面，进而须要新翻译的页面边界交叉更少。
N1-SDP平台在启动时确实支持不同大小（即 64KB、2MB、32MB 和 1GB）的巨页。
我们在数据库用例（第 V 节）中采取了这种方法来提高性能。

实验 3：数据局部性。

CCIX 的利用许可加速器利用自己的缓存，确信它们将始终与主机保持同等。
为了展示两个 SoC 的最佳情形基线性能，我们评估了担保所有访问都在设备上缓存中命中的情形，在图 5 中称为本地数据，并丈量这些命中的延迟。
为了比较，我们还展示了覆盖缓存未命中的数据远程案例。
AU280 中更大略的缓存层次构造实现了比 VCK5000 上的二级缓存（写入 ≈ 150 ns，读取 ≈ 170 ns）更小的延迟（写入 ≈ 80 ns，读取 ≈ 100 ns），以实现更小的传输大小。
但是，对付较大的传输，两级层次构造变得更快。

图5 数据局部性对 AU280 和 VCK5000 的 CCIX 延迟的影响

实验 4：同等性努力。

在这种情形下，主机上的运用程序分配一个共享缓冲区，主机和加速器同时访问和修正该缓冲区。
这些并发访问/修正增加了同等性事情，进而增加了访问延迟。
大页面用于避免 ATS 开销。
如算法 2 所述，硬件 CTG 和软件 API 同时修正共享缓冲区中的缓存行。
最初，我们利用 2 MiB 的缓冲区进行丈量，然后分别缩小到 512 KiB、128 KiB 和 32 KiB，以增加争用程度，从而增加保持同等性所需的努力。
缓冲区的这种缩小显示在图 6 左侧的 Y 轴上。
对付这些共享缓冲区大小中的每一个，我们利用单个 CPU 内核和 FPGA 从两个主机对缓冲区中的随机地址实行 1024 次访问，并跟踪它们的延迟。
正如预期的那样，随着访问次数的增加以及缓冲区大小的缩小，争用都会增加。
在这两种情形下，必须办理的同等性冲突的可能性都会增加。
有趣的是，额外的同等性事情紧张影响主机的访问，FPGA 端访问的延迟险些保持不变。
这在图 6 的右侧进行了更详细的检讨，该图绘制了访问韶光的直方图，现在为 20,000 次访问，对付 32 KiB 和 2 MiB 共享缓冲区大小。
虽然韶光更长，但来自 FPGA 真个远程访问比本地主机端访问的“抖动”（分布更窄）要少得多。
请把稳，FPGA 端访问的非常短的非常值实际上是 SC 中的命中，其概率在较小的 32 KiB 中大于在较大的共享缓冲区中。
在这个实验中，主机上只有一个内核访问共享缓冲区。
为了进一步调查，我们利用主机上的多个内核来修正和访问共享缓冲区。
我们的评估表明，由于更多的缓存命中，将 32 KiB 地址范围的内核数量从 1 个增加到 3 个实际年夜将本地主机端均匀访问延迟从 333 ns 缩短到 235 ns。
另一方面，由于更多的缓存未命中，设备访问延迟从 674 ns 增长到 741 ns。
对付更大的内存范围，访问韶光将再次保持险些恒定。

THE END

免责声明：本文由作者原创。
文章内容系作者个人不雅观点，半导体行业不雅观察转载仅为了传达一种不同的不雅观点，不代表半导体行业不雅观察对该不雅观点赞许或支持，如果有任何异议，欢迎联系半导体行业不雅观察。

本日是《半导体行业不雅观察》为您分享的第3090内容，欢迎关注。