4. CXL.cache事务层协议：读请求、写请求、Snoop、Completion等事务类型

搞CXL.cache的Trace分析，你得先摸透事务层。说白了，这是Host和Device之间加速器一致性交互的核心。我最早啃这部分时，总觉得不就是发个请求回个响应嘛，结果一抓Trace就懵了——事务类型不对，时序永远对不上。今天咱们就把这四种主要事务类型掰开揉碎。

4.1 读请求：不仅仅是拉数据

读请求，在CXL.cache里叫RdReq。它比你想的复杂一点。

Host发起的读，可能是读Device私有数据，也可能是读Device缓存的Home数据。Device发起的读，大概率是为了拿自己不在Cache里的行。我记得第一次调CXL.cache时，也困惑这个“隐性”读。

读请求包含的关键信息：

• 地址（Address）：完整物理地址或部分tag。
• 长度（Length）：通常固定为64B或128B。
• 请求者ID（RequesterID）：谁发的请求。
• 监听域（Snoop Domain）：只有Device发的读请求才带。

举个实战场景：你在Trace里看到Device频繁发读请求给Host，但Host响应延迟很高。这时候别光盯着Completion时间，还得看Host内部Cache Miss了多少次。

4.2 写请求：一致性写入的三种模式

写请求，CXL.cache里分WrReq和WrCpt。你想想看，一致性协议下的写没那么简单。

我踩过一次坑：Device用WrReq写共享行时没触发Snoop，结果Host那边Cache行还是旧数据。说白了，写请求必须和Snoop配合好。

4.3 Snoop：一致性维护的“探照灯”

Snoop，也叫监听。CXL.cache里用SnpReq和SnpResp来维护一致性。

Host发起Snoop，实际上是问Device：“你缓存了A地址吗？状态怎样？”

Snoop事务的分类：

1. SnpInv（监听无效）：Host要求Device把缓存行失效。Device必须回应SnpRespI。
2. SnpCur（监听当前状态）：Host只查状态，不改数据。Device回应SnpRespS或SnpRespE。
3. SnpData（监听并回传数据）：Host不仅要失效，还要拿数据。Device既失效又回传。

你分析Trace时，得区分Snoop请求是发给哪个缓存层次。我记得有一次Snoop请求被Device忽略没处理，Host一直等，最后超时了。嗯，这里要注意：Snoop必须2-4个时钟周期内响应。

4.4 Completion：响应也得有说法

Completion，我用得最多的是Cmp和DataCmp。读请求必须有DataCmp，写请求用Cmp就行。

Completion里藏着响应者的状态信息。比如读回应DataCmp的RespType字段告诉你该行是I（无效）、S（共享）还是E（独占）。

Completion的几种类型：

• DataCmp：带数据的完成。读请求完整响应。
• Cmp：不带数据的完成。写请求或Snoop响应。
• CmpE：带Error的完成。Trace里看到这个，基本就是一致性错误或访问违规。

我有一次在Trace里发现DataCmp一直带StaleData标志，查了半天发现是Device那边Cache行状态没更新。

4.5 事务交互流程全景

这些事务之间怎么配合？下面这张图是我惯用的分析框架。它帮你把四种事务的交互逻辑理清楚。

看到没？读请求先走Snoop，再回DataCmp。写请求可以走WrReq直接带数据，也可以先发WrReq再等Cmp。Snoop贯穿始终，确保一致性。

4.6 事务类型快速参考表

最后，我整理了一个表格。你在调Trace时，可以直接对查。