🔥**[点击查看精选 CXL 系列文章](#点击查看精选 CXL 系列文章)** 🔥

📢 声明：

🥭 作者主页：【MangoPapa的CSDN主页】。

⚠️ 本文首发于CSDN，转载或引用请注明出处【https://mangopapa.blog.csdn.net/article/details/132553151】。

⚠️ 本文目的为个人学习记录及知识分享。因个人能力受限，存在协议解读不正确的可能。若您参考本文进行产品设计或进行其他事项并造成了不良后果，本人不承担相关法律责任。

⚠️ 若本文所采用图片或相关引用侵犯了您的合法权益，请联系我进行删除。

😄 欢迎大家指出文章错误，欢迎同行与我交流 ~

📧 邮箱：mangopapa@yeah.net

💬 直达博主：loveic_lovelife 。（搜索或点击扫码）

文章目录

[1. CXL.cache](#1. CXL.cache)
- [1.1 背景意义](#1.1 背景意义)
- [1.2 Channel 简介](#1.2 Channel 简介)
- - [1.2.1 Pre-allocated 怎么理解？](#1.2.1 Pre-allocated 怎么理解？)
[2. CXL.mem](#2. CXL.mem)
- [2.1 背景意义](#2.1 背景意义)
- [2.2 Channel 简介](#2.2 Channel 简介)

1. CXL.cache

在 CXL 支持的三种协议中，CXL.cache 协议是可选的。CXL.cache 主要目的是为了便于设备访问主存（Device 访问 Host-attached Memory）。

1.1 背景意义

采用 PCIe 的方案中，Device 在需要访问 Host Memory 的时候，通过 PCIe 给 Host 发送 Memory 读写请求，这样一来一回时延较大。为了降低 Device 访问 Host Memory 的时延，可以在 Device 端增加一块 Cache，将 Device 经常用到的 Host Memory 的数据缓存在 Device Cache 内。这样，当 Device 侧的 Processor 需要访问 Host Memory 时，如果访问的地址刚好在 Device Cache 内，则直接对 Device Cache 进行访问，能够大大减少访问时延，实现 Device 对 Host Memory 的低时延、大带宽访问。

考虑到 Host Memory 同一地址数据可能被缓存在了多个 Cache 中，这就涉及到多个 Cache 的一致性（或称缓存一致性）的问题。CXL.cache 就是为解决缓存一致性而生的，通过 CXL.cache 来实现 Host 与 Device 的缓存一致性。

1.2 Channel 简介

为了实现 Host 和 Device 之间的缓存一致性，CXL.cache 提供了 D2H、H2D 两个方向的 Cache 管理，每个方向均有 3 个 Channel：Req、Rsp 及 Data。CXL.cache 的 6 个 Channel 作用概况如下：

D2H Req ，在 Type 1 及 Type 2 设备中用以 Device 访问 Host Memory，在 HDM-D Host Bias 设备中也用于 Device 访问 Device Memory。若访问的地址位于 Host Memory，Host 会通过 H2D Rsp/Data 反馈相关响应/数据；若访问的地址位于 Device Memory，Host 会通过 CXL.mem 的 M2S Req/RwD 把请求转发回 Device。
H2D Req ，Host 通过该 Channel 来 Snoop Type 1 或 Type 2 Device Cache 中归属于 Host Memory 的 Cacheline，并通过 D2H Rsp 及 Data 来反馈 Snoop Response 及 Data。

在 CXL.cache 的 6 个 Channel 中，Rsp 及 Data 在发送之前均已在接收端提前分配（Pre-allocated）好相关 Buffer，且两者有独立的 Channel（有别于 CXL.mem 的 RwD、NDR，CXL.mem 的 Rsp+Data 共用 RwD，单纯的 Rsp 用 NDR）。

1.2.1 Pre-allocated 怎么理解？

H2D 方向发出的请求可以认为是读请求，D2H 方向既有读请求又有写请求。对于写请求，在发送请求之前需要确保对端有足够的 Credit 来接收当前 Req 及 Data；对于读请求，在发送请求之前，一方面确保对端有足够的 Credit 来接收当前 Req，另一方面需确保本段有足够的 Buffer 来接收对端反馈回来的数据。对于读响应，本端在发出 Req 之前即已分配好相应 Entry 来接收 Rsp 和 Data；对于写响应，一方面本端在发出 Req 之前即已分配好响应 Entry 来接收 Rsp，另一方面对端收到 Req 后也已分配好相应 Entry 来接收数据。

2. CXL.mem

2.1 背景意义

在 CXL 支持的三种协议中，CXL.mem 协议是可选的。CXL.mem 主要目的是为了便于 Host 直接访问 Device Memory。

纯粹的 PCIe 方案中，Host Processor Cache 无法通过 Prefetch 的方式拿到 Device Memory 的数据，也无法将 Cache 中的数据直接 Flush 到 Device Memory。Host 想要把 Processor 处理产生的数据存放到 Device Memory 需要以下流程：

Host Processor 把数据缓存至 Host Cache；
Host Cache 把数据 Flush 到 Host Memory；
Host 通过中断通知 Device 来取数据；
Device DMA 通过 DMA 来 Host Memory 读数据，并写回到 Device Memory。

以上方案较为繁杂，不利于 Host 对 Device Memory 的使用。在采用 CXL.mem 的方案中，Device Memory 跟 Host Memory 一同编址，Host 可以绕过 Host Memory 及中断直接访问到 Device Memory。以上流程可简化为：

Host Processor 把数据缓存至 Host Cache；
Host Cache 通过 CXL.mem 把数据 Flush 到 Device Memory。

显然，采用 CXL.mem 的方案能够实现 Host 对 Device Memory 的高效访问。除了访问效率，Processor 能够使用的 Memory 容量也得到了扩展。

2.2 Channel 简介

CXL.mem 提供了双向 6 个 Channel 来实现 ①Host 对 Device Memory 的直接访问；②Device 对 Host Cache 的 Back Invalidation。

两个方向为：M2S 及 S2M。M 负责生成读写请求，S 负责反馈响应及数据。举个例子：CPU Coherency Engine 作为 Master，Device Memory 作为 Subordinate。若 S 为 HDM-D 或 HDM-DB，CXL.mem 默认存在 Device Coherency Engine，DCOH 负责实现 Device Cache 的 Snooping 等 Coherency 相关功能并负责更新元数据。

6 个 Channel 分别为：M2S Req、RwD、BIRsp，S2M NDR、DRS、BISnp。BISnp/BIRsp 非必须，但对于支持 HDM-DB 的设备必须实现 BI* Channel。

|-------------|
| --- END --- |

🔥 **精选往期 CXL 协议系列文章，请查看【 CXL 专栏】**🔥

⬆️**返回顶部** ⬆️

CXL.cachemem 简介（背景&通道）