先详解CXL系统架构

第二章 CXL系统架构

CXL支持三种设备类型，如下图。Type1支持CXL.cache和CXL.io；Type 2支持CXL.cache，CXL.mem和CXL.io；Type 3支持CXL.mem和CXL.io。无论哪种类型，CXL.io都是不可缺少的，因为设备的发现，枚举，配置等都是由CXL.io来负责。

传统的非一致I/O设备主要依赖于标准的生产者-消费者订单模型（Producer-Consumer Ordering Model），并针对主机连接的内存执行。此类设备除了工作提交和工作完成边界上的信号外，很少与主机进行交互。此类加速器还倾向于处理数据流或大型连续数据对象。这些设备通常不需要CXL提供的高级功能，而传统PCIe足以作为加速器连接介质。

插播一句，生产者-消费者模型是一种为了加快系统响应数据的异步模型，系统中一些慢速操作（例如网络I/O，数据统计等）会阻塞主进程的运行，从而使得系统的吞吐量大大降低。如果我们不需要即时得到这些慢速操作的返回结果，那么我们可以使用异步的方式来解决这个问题。生产者-消费者模型通常是多对多的关系，即多个生产者对应多个消费者，他们之间通过共享一个队列来实现通信和同步。生产者负责把请求放到队列中，消费者负责从队列中出去请求并作响应的处理。生产者-消费者模型的核心思想，把数据的生产者和消费者进行解耦，使二者不直接交互，从而使二者的处理速率相对来说互不影响。

2.1 Type 1 CXL设备

Type 1设备的典型应用是网卡这类高速缓存设备。

Type 1 CXL设备，应用于拥有完全一致性缓存的设备。对于这种设备，标准的生产者-消费者模型效果一般，比如，设备需要执行复杂的原子操作，而这些原子操作又不属于PCIe的标准原子操作。基本缓存一致性允许加速器实现它选择的任何排序模型，并允许它实现无限数量的原子操作。它们往往只需要少量的缓存，可以很容易地通过标准的处理器监听过滤（Snoop Filter）机制轻松跟踪。

Type 1设备支持的缓存大小取决于主机的监听过滤能力。CXL使用CXL.cache链接支持此类设备，加速器可以通过该链接使用CXL.cache协议进行缓存一致性事务。

2.2 Type 2 CXL设备

Type 2设备的典型应用是GPU，FPGA，AI这类的加速器。

Type 2设备除了一致性高速缓存外，还具有连接到设备的内存，例如DDR、高带宽内存（High Bandwidth Memory，HBM）等。这些设备的性能依赖于加速器和设备挂载内存（Device-attached Memory）之间的巨大带宽。CXL的关键目标是为主机提供一种将操作数推入设备挂载内存的方法，并为主机提供从设备挂载内存中提取结果的方法，这样就不会增加抵消加速器好处的软件和硬件成本。CXL将一致的系统地址映射设备连接内存称为“主机管理的设备内存“（Host-managedDevice Memory，HDM）。

HDM和传统IO/PCIe专用设备内存（Private Device Memory，PDM）之间有一个重要区别。用带有GDDR的GPGPU来举例，GPGPU往往将其GDDR视为私有。这意味着主机无法访问GDDR，并且与系统的其余部分不一致。它完全由设备硬件和驱动程序管理，主要用作具有大型数据集的设备的中间存储。这种模型的明显缺点是，在引入操作数并将结果写回时，它涉及大量从主机内存到设备连接内存的来回拷贝。HDM虽然也是挂载在设备端，但可以被主机直接访问。

2.2.1 偏向性一致性协议

再次强调，HDM是附属于设备的内存，也就是说HDM在设备端，而不是主机端。

偏向性一致性模型（Bias Based coherency model）定义了设备挂载内存（Device-attached Memory）的两种状态：偏向主机（Host Bias）还是偏向设备（Device Bias）。当设备挂载内存偏向主机时，该内存就像常规的主机连接内存一样。也就是说，如果设备需要访问该内存，设备需要向主机发送一个请求，主机将解析请求的一致性。当设备挂载内存处于偏向设备时，要保证主机中没有对应的缓存行副本。这样设备可以随意的访问设备挂载的存储，而不需要向主机发送任何的请求事务。

需要注意的是，主机本身可以看到与设备连接的内存的统一视图，而不考虑偏向状态。在这两种模式中，设备连接的内存都可以保持一致性。

带有偏向性的一致性模型的优点：

有助于维护映射到系统一致性地址范围内的设备挂载内存的数据一致性。

帮助设备以高带宽访问其本地连接的内存，同时不会产生显著的一致性开销（例如，对主机的监听）。

帮助主机以一致的统一的方式访问设备挂载的存储，就像挂载在主机自己下面一样。

为了维护偏向性一致性模型，Type 2的设备需要：

实现偏向表，该表跟踪页面粒度上的偏向性（例如1b/4KB页面），该表可被缓存在设备中。

使用转换代理（Transition Agent，TA）支持偏向性转换。这本质上看起来像是一个用于“清理”页面的DMA引擎，会清空该页中对应主机里所有的缓存行。

构建对加速器本地内存的基本load/store访问。

2.2.1.1 主机偏向性

主机偏向模式通常是指在工作提交期间主机将操作数据写入内存，或在工作完成后从内存读取数据。如下图所示，内存挂在设备端。在主机偏向模式下，一致性数据流从主机到设备挂载内存，如图中的蓝色箭头所示。但是，设备对此内存的访问效率不是最佳的，因为需要通过主机，如图中的绿色箭头所示，设备先向主机发起请求，然后通过主机来访问HDM。

2.2.1.2 设备偏向性

在设备偏向模式下，设备负责工作提交和完成。在此模式下，设备需要对设备挂载内存完成高带宽和低延迟访问。设备无需询问主机的一致性引擎，而直接发起访问，如图中的红色箭头所示。主机仍然可以访问设备挂载的内存，但可能会被加速器强制放弃所有权，如图中的绿色箭头所示。设备访问HDM内存实现了延迟低，带宽高，但是主机访问HDM会却相反。

2.2.1.3 模式管理

有两种HDM偏向性模式管理方案：软件辅助和硬件自主。

2.2.1.4 软件辅助偏向模式管理

在软件辅助管理模式下，依靠软件来管理某页面的状态。通过选择适当的主机或设备偏向模式，软件可以在页面粒度上优化一致性性能。

软件辅助偏向性管理的特点如下：

这种方式适用于，在执行计算操作前，加速器内的数据已经准备好。

如果未提前将数据移动到加速器内存中，加速器通常会根据对数据的一些尝试引用来控制移动数据。

在“需要的”数据提取场景中，加速器必须能够找到要执行的工作，对于这些工作，数据已经正确放置，否则它必须暂停。

加速器停顿的每个周期会影响软件运行性能。

简单的加速器通常无法隐藏数据预取的延迟。

2.2.1.5 硬件自主偏向模式管理

软件辅助方式通常适用于简单的加速器。对于复杂的加速器，比如GPU，用软件去管理偏向性将会很复杂，并不适用。硬件自主偏向性管理模式，不依赖软件来管理页面级的一致性偏向。相反，是硬件根据给定页面的请求者对偏向模式进行预测，并相应地进行调整。这种模式的主要好处是：

提供与软件辅助模型中相同的页面粒度一致性偏向功能。

无需软件在卸载执行之前识别和安排页面偏向转换。

为卸载执行期间的动态偏向转换提供硬件支持。

此模型的硬件支持可以是软件辅助模型的简单扩展。

链路流和主机支持不受影响。

影响主要限于当主机接触到设备偏向页面时在加速器上采取的操作，反之亦然。

注意，尽管这是一个表面上看来是硬件驱动的解决方案，但硬件不需要自动执行所有转换（尽管如果需要，也可以这样做）。

2.3 Type 3 CXL设备

Type 3的典型应用是内存缓冲器，常用作内存带宽或者是容量的扩展。

Type 3 CXL设备支持CXL.io和CXL.mem协议。由于这些设备不是加速器，所以它们不会通过CXL.cache发出任何请求。该设备主要通过CXL.mem运行，为主机发送的请求提供服务。CXL.io协议主要用于设备发现、枚举、错误报告和管理。CXL.io协议允许设备用于其它特定于I/O的应用用途。

2.4 多逻辑设备（MultiLogical Device，MLD）

CXL 2.0仅支持Type 3的多逻辑组件。MLD组件最多可以将其资源划分为16个独立的逻辑设备（Logical Device，LD）。在CXL.io和CXL.mem协议中，每个逻辑设备都由逻辑设备标识符（LD-ID）标识。每个逻辑设备都作为Type 3设备运行，对虚拟层次结构（Virtual Hierarchy，VH）可见。LD-ID对访问VH的软件是透明的。MLD组件对于所有逻辑设备中的每个协议都有公共事务层和链路层。

MLD组件有一个为FM（Fabric Manager）保留的LD和最多16个可用于主机绑定的LD。FM拥有的LD（FMLD）允许FM跨LD配置资源分配，并管理与多个VCS（VirtualCXL Switch）共享的物理链路。

插播一句，VH是PCIe MR-IOV（Multiple Root I/O Virtualization）里面的一个概念。MR-IOV扩展了SR-IOV规范，允许PCIe设备在多个有独立PCI根的系统之间共享，这些系统通过基于PCIe转换器的拓扑结构与PCIe设备或者PCIe-PCI桥相接。每个VH（一个VH就是一个虚拟独立的SR-IOV设备）拥有独立的PCI Memory，IO，配置空间。

2.4.1 LD-ID for CXL.io and CXL.mem

LD-ID是一个16位逻辑设备标识符，适用于CXL.io和CXL.mem请求和响应。MLD设备返回的所有目标请求和响应必须包括LD-ID。

2.4.1.1 LD-ID for CXL.mem

CXL.mem仅支持LD-ID的低4位，因此可以通过链路支持多达16个唯一的LD-ID值。通过MLD端口转发的请求和响应用LD-ID标记。

2.4.1.2 LD-ID for CXL.io

CXL.io支持为通过MLD端口转发的所有请求和响应携带16位LD-ID。LD-ID0xFFFF是保留的，始终由FM使用。CXL.io利用供应商定义的本地TLP前缀来携带16位LD-ID值。供应商定义的本地TLP前缀格式如下所示。

2.4.2 内存池设备配置寄存器

每个LD作为一个或多个PCIe EP（End Point） Function对软件可见。虽然LD Function支持所有配置寄存器，但影响常见链路行为的几个控制寄存器被虚拟化，对链路没有直接影响。LD的每个Function都必须实现PCIe规范中所述的配置寄存器。

下表列出了一组寄存器字段，与PCIe基本规范相比，这些字段的行为发生了修改。

2.5 CXL设备扩展

CXL设备扩展限制只允许每个VH（Virtual Hierarchy）启用一个Type 1或Type 2设备。

本章总结：这一章主要定义了3类CXL设备，Type 1支持CXL.cache和CXL.io；Type 2支持CXL.cache，CXL.mem和CXL.io；Type 3支持CXL.mem和CXL.io。这三类设备都需要支持CXL.io协议，不同的是对CXL.cache和CXL.mem支持。 【待续】

审核编辑：刘清