3、CXL协议基础：三大子协议与PCIe的关系
聊CXL，绕不开它的三个“分身”——CXL.io、CXL.cache、CXL.mem。我刚开始接触CXL时，也被这三个名字搞得有点晕。说白了，它们就是CXL协议栈里的三个不同通道，各管一摊活。
你想想看，传统PCIe只负责“搬数据”，但CXL要干的事更多：既要发现设备、配置空间，又要维护缓存一致性，还得直接访问远端内存。所以干脆拆成三个子协议，各司其职。
3.1 CXL.io —— 基础通道
CXL.io是所有CXL设备都必须实现的子协议。它基于PCIe的TLP（事务层包）和DLLP（数据链路层包），负责最基础的工作：设备发现、配置空间访问、中断处理、DMA传输等。
嗯，这里要注意：CXL.io和标准PCIe在事务层上几乎一模一样。所以你在BIOS里看到一个CXL设备，它首先会以PCIe设备的形式被枚举出来。我曾在一次调试中遇到设备无法被系统识别，最后发现是CXL.io链路的训练没通过——说白了就是PCIe链路没起来。
关键点：CXL.io是CXL设备的“身份证”和“通信管道”。没有它，其他两个子协议根本跑不起来。
3.2 CXL.cache —— 一致性通道
CXL.cache是CXL协议最亮眼的设计之一。它允许设备（比如加速器、智能网卡）缓存主机内存中的数据，并且保证缓存一致性。
为什么会需要这个？你想想看，传统PCIe设备访问主机内存，要么通过DMA，要么通过MMIO。但DMA是异步的，设备改了数据，主机不知道；主机改了数据，设备也不知道。这就导致了一致性问题。
CXL.cache解决了这个痛点。设备可以通过CXL.cache协议，向主机发送“缓存请求”——比如读数据、写数据、甚至原子操作。主机端的缓存一致性引擎会处理这些请求，确保设备看到的永远是最新的数据。
我的经验：在部署CXL内存池化方案时，CXL.cache的延迟是关键。我曾经遇到设备频繁请求缓存行，导致主机端一致性协议栈过载。后来通过调整缓存行大小和预取策略，才把性能拉回来。
3.3 CXL.mem —— 内存访问通道
CXL.mem是CXL协议里最“性感”的部分。它允许设备以Load/Store语义直接访问主机内存——注意，是直接访问，不是通过DMA。
这意味着什么？意味着设备可以把主机内存当成自己的内存来用。设备发起一个读请求，CXL.mem协议会把这个请求转换成内存访问事务，直接读取主机物理内存，然后把数据返回给设备。整个过程对设备来说是透明的，就像在访问本地内存一样。
我习惯把CXL.mem理解为“内存语义的PCIe”。它把PCIe从“块设备传输”提升到了“内存访问”的层次。这也是CXL能实现内存池化的核心技术基础。
| 子协议 | 主要功能 | 是否必须 | 典型场景 |
|---|---|---|---|
| CXL.io | 设备发现、配置、中断、DMA | 是 | 所有CXL设备 |
| CXL.cache | 缓存一致性维护 | 可选 | 加速器、智能网卡 |
| CXL.mem | 内存直接访问（Load/Store） | 可选 | 内存池化、内存扩展 |
3.4 CXL与PCIe的关系
这个问题经常有人问。我的回答很简单：CXL是PCIe的“上层建筑”。
物理层上，CXL完全复用PCIe的PHY（物理层）。CXL 1.0/2.0基于PCIe 5.0，CXL 3.0基于PCIe 6.0。所以CXL设备插在PCIe插槽上就能用，电气特性完全兼容。
但协议层上，CXL做了大量扩展。PCIe只定义了“事务层”，而CXL在事务层之上又定义了三个子协议。你可以把PCIe想象成一条高速公路，CXL就是在这条高速公路上跑的三种不同“车辆”——CXL.io是普通轿车，CXL.cache是跑车，CXL.mem是卡车，各有各的用途。
避坑指南：我曾经遇到过CXL设备在PCIe Gen4插槽上无法正常工作的情况。原因很简单——CXL 1.0要求PCIe Gen5，向下兼容Gen4时某些厂商的实现有bug。所以采购前一定要确认主板和设备的CXL/PCIe版本匹配。
总结一下：CXL.io是基础，CXL.cache解决一致性问题，CXL.mem实现内存语义访问。三者配合，让CXL成为数据中心内存池化的关键技术。嗯，下一节我们会深入CXL.io的细节，看看它和标准PCIe到底有哪些不同。