CXL.cache 与 CXL.mem、CXL.io 的区别
刚接触 CXL 协议栈的人，很容易把三种协议混为一谈。我刚开始啃 spec 的时候也犯过这毛病——明明都走 PCIe 物理层，怎么还分三套？其实说白了，CXL.io、CXL.cache、CXL.mem 各自负责不同层面的通信，就像一个团队里的三个角色：一个管后勤（IO），一个管同步（cache），一个管仓库（memory）。
从协议栈看一眼架构
CXL 跑在 PCIe 5.0/6.0 的物理层和链路层之上，但从事务层开始岔开三条路。下图是我自己画的一张架构图，帮你理清这三者的位置关系。
你看，CXL.io 在最底层，跟标准 PCIe 的事务层几乎一样。CXL.cache 和 CXL.mem 靠上面一点，它们复用同样的物理层，但事务语义完全不同。我习惯把 CXL.io 称为 控制面，把 cache 和 mem 称为 数据面。
核心差异对比
光看分层还不过瘾，咱们拉一张具体对比表，把三个协议的区别钉死。这张表我每次培训必讲，学员看完基本不会再搞混。
| 维度 | CXL.io | CXL.cache | CXL.mem |
|---|---|---|---|
| 本质用途 | 设备发现、配置、中断、DMA | CPU 与设备缓存一致性维护 | 将设备内存映射为主机内存 |
| 缓存层级 | 无缓存一致性要求 | 设备侧可拥有缓存，与 CPU Cache 保持一致 | 设备内存通常不缓存（或选择性缓存） |
| 一致性模型 | 无 | MESI / MOESI 子集，支持 snoop | 简单弱一致性，可配置 |
| 传输粒度 | 通常 64B（PCIe TLP） | Cacheline 粒度（64B），支持子块 | 64B ~ 4KB，甚至更大 |
| 延迟要求 | ～微秒级（非关键路径） | 数十纳秒（必须低延迟） | 数百纳秒（可接受较高） |
| 典型应用 | Smart NIC、加速器初始化 | 带缓存的一致性加速器（如 AI 推理卡） | 内存池、CXL 内存扩展（Type 3 设备） |
从实际案例看混淆的危害
我记得有一次，项目里一个加速器芯片第一次上电后主机死活检测不到设备。硬件同事反复量 PCIe 链路，信号完美。后来我拿到 trace 一看，发现问题出在协议类型字段上——设备把配置空间的 CXL.io 包编码成了 CXL.mem。这就像你寄快递填错了运输方式，快递员根本不知道该往哪儿送。
那次之后我养成了一个习惯：拿到任何 CXL trace，第一件事就是按 protocol type 分组统计。看看三种协议的比例，如果发现 0 个 CXL.io 包，那一定是有问题的——因为设备根本无法完成初始化握手。
避坑指南
- 试图在 CXL.io 通道上实现缓存一致性 —— 这是不可能的，必须走 CXL.cache
- 把 CXL.mem 当作 CXL.cache 使用，导致设备缓存与主机不一致，跑着跑着数据就错了
- 忽视 CXL.io 的链路层 CRC —— 虽然它跟 PCIe 一样，但 CXL 对错误恢复有额外要求，不检查会丢包
你想想看，如果三种协议的语义都能混用，那 CXL 规范也没必要分三份文档了。所以排查问题时，先搞清当前流量的协议类型，再去查对应的事务规则，效率能翻倍。
一句话总结
CXL.io 负责建立连接和控制，CXL.cache 负责保持缓存一致，CXL.mem 负责访问远端内存。三者缺一不可，但职责严格分离。这也是为什么 trace 分析的第一步，必须是识别协议类型——因为同样的 bit 位置，在不同的协议里意义完全不同。