CXL.cache 协议简介

CXL.cache 是什么？说白了，它就是 Host 与 Device 之间一套标准化的“缓存一致性”通信协议。你可以把它想象成一根专用的电话线，Host 和 Device 通过这条线告诉对方：“我刚改了这个地址的数据，你得更新一下你的缓存”。

我个人习惯把 CXL.cache 拆成两个视角来看：Host 端和Device 端。Host 侧负责维护全局的 Snoop Filter，Device 侧则按照协议规范发出读、写、探测请求。嗯，记得我最早接触这协议时，总觉得它跟 QPI/UPI 很像，但仔细一抠发现，CXL.cache 把很多复杂逻辑（比如缓存状态转换）简化了，而且用 Flit 做传输单元，延迟控制得好很多。

2.1 CXL.cache 在 CXL 协议栈中的定位

先看一张总览图。下图展示了一个典型的 CXL.cache 交互框架：

从图里能看到，Host 和 Device 各自维护自己的缓存状态机，中间通过固定的 H2D 和 D2H 消息通道通信。这里最重要的概念是——Host 是“老大”，它决定了 Device 可以怎样访问共享内存区域里的数据。

2.2 H2D Request 消息类型

CXL.cache 协议定义了 4 种常见的 H2D Request（Host 到 Device 的请求）。我整理了个表，方便你对照：

你想想看，为什么 CXL.cache 不给 Device 提供“直接 invalidate 别的缓存”的能力？我刚开始也有这个疑问。后来做项目时踩过一个坑——Device 收到 Host 的 WrCurr 时，如果 Device 本地缓存有 E 状态副本，必须无条件 invalidate 掉。Host 通过 Snoop Filter 保障全局一致性，Device 没有权限主动发起无效化。这就避免了分布式死锁。

2.3 D2H Response 语义

Device 收到 H2D Request 后，通过 D2H Response 消息告诉 Host 操作结果。常见的 Response 有以下几种：

• HIT：数据命中，且本地缓存状态为 E 或 S。
• HITSE：命中且缓存状态为 S 或 E，但希望 Host 记录该地址已被 Device 共享（用于后续 Snoop 优化）。
• MISS：缓存未命中，需要 Host 从主存或其他缓存获取。
• MISS_E：未命中 + 暗示 Device 即将写这块数据（Host 可以预分配 Exclusive）。

我记得在某次优化内存带宽时，发现 Device 侧频繁返回 MISS 而不是 HITSE，导致 Host 每次都要做全路径一致性查询。后来我们改进了 Device 端的预取策略，把 HITSE 比率从 30% 提到了 80%，整体延迟降低了差不多 40%。这就是协议细节对性能的直接作用。

2.4 缓存状态机模型

CXL.cache 的 Device 端缓存状态相比标准 MESI 做了精简，只定义了 I、S、E、M 以及一个特殊的 M_W（写等待）。状态转换完全由 H2D Request 和 D2H Response 驱动。

举个例子：

• Device 收到 RdOwn 且缓存命中时：状态从 E 转为 M（如果原来就是 E，就直接返回数据 + 保持 E？不对，RdOwn 要求获得独占权限，必须转 M）。
• 收到 WrCurr 且缓存是 M 状态时：数据更新后状态变为 I（因为 Host 可能会把最新数据写回主存，Device 不再拥有副本）。

2.5 事务流程示例

我们模拟一次最简单的读操作：

1. Host 生成 RdCurr (地址 A) → 通过 H2D 发送给 Device
2. Device 收到后，查本地缓存 Tag
   - 若 Miss:  返回 D2H Response (MISS + 空数据)
   - 若 Hit+E: 返回 D2H Response (HIT + 数据)
3. Host 根据 Response 决定是否需要从主存取数据
   - MISS: Host 发起主存读，拿到数据后发回 Device（通过另一条 H2D 写数据消息）
   - HIT: Host 直接消费 Device 返回的数据

整个流程延迟主要消耗在：Flit 串行传输 → Device 内部查 Tag → Response 仲裁 → 回传数据。我在实际测试中发现，光是 Tag 查找（SRAM 读取）就能吃掉 8-12 个周期，因此优化方向之一就是减少 Tag 查询深度。

2.6 协议关键参数速查

最后给一张清单，方便你在做延迟建模时参考：