前段时间水了两篇CXL的文章，主要是一些记录和应用设想，毕竟没有实际玩过，想法还是太过于表层。前几天看了夏老师的文章，才明白其中还有很多奥妙之处，这差距还不止是亿点点。再来回看之前写的应用设想，仅仅从减少IO传输数据考虑，多少显得有点儿戏。
01 CXL能带来什么？
提供了可缓存Host Memory的Device Cache和可被缓存的Device Memory，进而提升了CPU和IO之间的交互性能。可缓存Host Memory的Cache，实际上收益并不大，用于在Device侧实现特殊原子操作；可被缓存的Device Memory，可能会给CPU与外设之间的数据交互带来巨大的收益。
基于传统DMA的IO，需要将数据从Device Memory传到Host Memory，CPU再从Host Memory读取数据，这是属于IO push的方式。CPU无法直接从Device Memory拉取大量数据，没有类似于CXL的机制，这种数据操作只能属于non-cahce的属性，延时太大。因此，这种传输方式需要在Host Memory侧引入双倍的IO带宽。
当然，也有一种优化思路，直接将数据发送至Cache内部，就是DDIO。但是，CPU和Device属于两个独立的角色，不可能做到很好的同步，因此需增加Cache容量，但其利用率可能并不高。另外，Transaction Ordering的机制又会增加DDIO的复杂度。
CXL的加入，数据无需再搬运push到Host侧，仅仅写入Device Memory，Host CPU通过Pull的方式读取数据并放入其Cache缓存。此时，Cache缓存为CPU使用，从Device Memory或Host Memory拉取数据，其差别是未命中操作的延时。该IO流程其实并没有引入Host Memory，这带宽就省下来了，包括功耗。
02 实现CXL的代价
引入Cache一致性，需要增加传输额外的信息，其实就是损失了一些带宽，这是我能想到的一个损失。将Device Memory合并到CPU Memory系统内，增大了容量；与PCIe传统设备相比，可被Cache，又降低了CPU访问Device Memory延时。增大容量，降低延时，损失IO带宽，这个TradeOff应该是合理的。
03 如何实现
Type 3 Device仅仅是作为Memory的扩展，这是内存/存储厂家做的事情，Type 1用于存在特殊原子操作需求的场景。我理解能够引入更大价值的是Type 2 Device。
Type 2实现了CXL.io、CXL.cache和CXL.memory。请注意，协议只是说需实现了3种传输层协议，但Device Cache是Optional。也就是说，Type 2可以仅实现其中一点，提供可被缓存的Device Memory，而不需要可缓存Host Memory的Cache。但为什么还需要CXL.cache协议？Device Memory可被Host侧缓存，需要通过CXL.cache维护其一致性。
其实，协议内已经比较清楚的阐述了其实现方式，在Bias Based Coherency Model章节，很多概念也都写得很明白。与PCIe协议相比，CXL是比较友好的，PCIe的很多Cap仅仅是描述其定义，但具体实现和作用，显得有点云里雾里，需结合具体场景。
在Bias Model章节的两张图，基本可以看出需要做哪些事情，如下为其截图。存在Host Managed Device Memory(HDM)，位于Device侧，但是要纳入Host侧的Memory Management管理的。存在Device's Coherency Engine(DCOH)，用于维护Cache一致性，Device的硬件需读取HDM，就不能直接写入或读取了，必须通过DCOH作为中介，否则会引入数据错误的问题。
若熟悉Cache一致性，对于DCOH还是比较容易理解的，其实现也不会存在很大歧义的地方。但是对于HDM，隐藏着另外一个问题，如何寻址？尤其是存在虚拟化、容器的场景，寻址问题会更复杂一些。
04 地址域
我比较喜欢这一概念，在理解系统时能够提供不少帮助。简单来说，同一地址域的两个实体（比如进程）可以直接进行通信，而不同地址域的则需要通过一些转换，而这一转换需要通过更高级别的实体协助处理，比如内核。
在硬件虚拟化一文，提供了如下的图，其实每个方框（VMM除外）就可以看作为一个地址域，图中存在虚拟地址和物理地址。
虚拟地址都是在软件界面看到的地址，但硬件系统都必须使用物理地址进行路由。在CPU侧，MMU将虚拟地址转换为物理地址，在IO侧，则使用IOMMU或SMMU将虚拟地址转换为物理地址，然后在硬件系统总线进行路由。这一转换不仅仅在虚拟化场景存在，在物理机同样存在，进程使用的都是虚拟地址。
再来看HDM，应该属于物理地址域，且其使用分配权属于Host系统，device必须被分配后再使用。问题来了，device侧访问HDM，其地址还是由host侧分配的，可能是虚拟地址，如果是虚拟地址，如何转换为物理地址？？答案是，此时必须使用PCIe协议内的ATS，device侧维护ATC，用于转换地址。同样的，在host RC侧，也需要实现ATS机制。当然，对于仅仅实现CXL.mem，是不需要ATS的，此时device侧仅仅属于被动设备，扩展host内存空间，挂接在系统总线，直接使用物理地址。
05 软件应用模型
加入HDM之后，host系统除了DDR空间，又多了一部分区间。个人理解，在原有的内存分配机制之外，还需增加HDM的分配机制，其调用接口存在区别，需要加入设备号等信息。
另外，HDM是否还存在页面替换？当前对于PCIe设备访问的内存空间，是需要pin操作的，避免页表被替换，导致Page Fault，因为PCIe协议并没有很好处理Page Fault。ATS可以处理Page Fault，但当前较少支持的设备。若HDM分配出来的空间，不会存在页面替换，是否可以带来不少收益？
还有一点，既然实现了ATS，是否可以将进程和硬件分配到相同地址域？除了在初始化阶段，业务场景完全绕过内核进行通信。当然，我理解使用PASID也可以实现，但没能解决pin的问题，收益并不大。
06 其余应用场景
可缓存的Device Memory提供了一种扩展内存带宽和容量的能力，支持软硬件共同维护一致性，访问延时应该是可控的，同时又分散了功耗和散热。基于这些优点，结合具体业务，可以设想其应用场景。
之前看了一些DPU的内容，我理解应该要借助于CXL，将IO语义的内容转换为host侧Load/Store，DPU侧处理一些零碎、不适合使用CPU的数据处理，而Host CPU侧直接读取数据进行高性能计算。
另外，在CXL的应用设想一文，提到了硬件共享的想法，是否会对数据中心的硬件形态产生影响？
07 结语
慢慢地理解了这句话，CXL是intel对计算产业的一次巨大让利。基于CXL，实现了host与device之间的高效交互，缓解了CPU与IO之间的屏障，进而将host侧的算力需求逐步释放到device侧，更好地提升硬件的利用率。还是那句话，个人认为在后续硬件形态会扮演重要的角色。
- End -
作者：芯工阿文
原文链接：芯工阿文
推荐阅读
更多IC设计技术干货请关注IC设计技术专栏。
