3.3 CXL.mem

3.3.1 介紹

CXL內存協議被稱作CXL.mem。CXL.mem定義了CPU和內存之間的傳輸接口。該協議可用于多個不同的內存連接選項，包括當內存控制器位于主機CPU中時，或當內存控制器位于加速器設備內時，或當內存控制器移動到內存緩沖芯片時。

CPU中的一致性引擎使用CXL.mem請求和響應與內存接口。在此配置中，CPU一致性引擎被視為CXL.mem主設備（Master），內存設備被視為CXL.mem從設備（Subordinate）。主設備負責向從設備發起讀寫請求，從設備負責響應主設備的讀寫請求。

當從設備是一個加速器時，CXL.mem協議認為設備內部也有一個一致性引擎（Device Coherency Engine，簡稱DCOH）。

從Master到Subordinate的CXL.mem事務被稱作M2S；反過來，從Subordinate到Master的事務稱作S2M。

M2S事務只有兩種消息類型：

無數據的請求（Req）

有數據的請求（RwD）

對應的，S2M事務也只有兩種類型：

無數據的響應（NDR）

有數據的響應（DRS）

3.3.2 內存QoS遙測

內存QoS遙測是內存設備的一種機制，用于在CXL.mem請求的每個響應消息中指示其當前負載級別（DevLoad）。這使主機能夠根據負載級別來衡量對部分設備、單個設備或設備組的CXL.mem請求的速率，從而優化這些內存設備的性能，同時限制結構擁塞。

插播一句，QoS是Quality of Service的縮寫，翻譯過來就是服務質量。對于內存系統而言，帶寬和延時受到一定的限制，如何向其它的模塊提供服務是一個系統問題。SoC有的模塊可能帶寬需求不大，但是對于延時要求很高，比如顯示模塊。而有的模塊對于帶寬要求很大，但是延時可以略高，比如數據處理器。如果對SoC所有模塊的內存需求一視同仁，可能影響整個系統的運行。利用QoS機制，可以對每個模塊的內存訪問排列順序，達到內存系統的最佳利用。

內存QoS遙測內容比較繞，我也沒看太懂，暫時略過，不影響CXL的學習。

3.3.3 M2S請求（Req）

Req消息是無數據請求，消息字段定義如下：

各字段的編碼和詳細解釋就不貼圖了，如果有需要，大家可以去協議里面查找。

3.3.4 M2S帶數據請求（RwD）

RwD是有數據請求，消息字段定義如下：

3.3.5 S2M無數據響應（NDR）

NDR消息類包含從Subordinate到Master的完成和指示，不帶數據。

3.3.6 S2M數據響應（DRS）

DRS消息類包含從Subordinate到Master讀取的內存數據。

3.3.7 轉發和排序規則

在多跳互連網絡中，Req和RwD消息的每一跳都需要信用值

如果請求和MemRdFwd或MemWrFwd指向相同的緩存行地址，則M2S Req通道中的CXL.mem請求不能發送MemRdFwd或MemWrFwd

NDR和DRS消息需要在源位置預先分配

在CXL.mem上，只有在寫入完成后，寫入數據才能保證對以后的訪問可見

CXL.mem請求需要在設備上進行轉發，而不依賴于任何設備啟動請求

緩存行的M2S和S2M數據傳輸不能與其它緩存行交織

3.4 事務順序總結（Transaction Ordering Summary）

沒什么重要內容，暫時略過。

3.5 到設備掛載內存（DAM）的事務流

3.5.1 Type 1和Type 2的事務流

3.5.1.1 注釋和假設

下面的示意圖做了如下假設：

設備內部有一個設備一致性引擎，稱作DCOH

DCOH里包含一個監聽過濾器，是用來追蹤監聽設備的緩存

DCOH有一個偏置表查找機制，具體實現依賴于設備

設備特定的流程，如下圖紅色箭頭所示，不需要完全遵守下圖，具體實現取決于設備

3.5.1.2 主機請求

主機發起的可緩存讀（Cacheable read）示例如下圖。主機請求獲得一個緩存行的非獨占副本。主機發送MemRd，SnpData給設備，設備DCOH接收到SnpData，在偵聽過濾器中查找此緩存行。如果SF Hit（圖中綠色字體），設備將該緩存行狀態從Exclusive變為Shared（圖中綠色字體）。隨后將數據和響應發給DCOH，DCOH收到之后，回復Cmp-S給主機，然后將數據通過MemData發送給主機。

CXL協議中還給了好幾個示例，就不一一貼上了。

3.5.1.3 設備請求（主機偏向和設備偏向）

到設備掛載內存的設備讀取示例如下圖，包含兩個流程分支。第一個，設備向設備掛載的內存發起讀請求，由于配置成主機偏向（圖中的紫色字體），設備要向主機發送一致性請求。主機在解析完一致性后，在CXL.mem上發送MemRdFwd以完成事務，此時設備可以在內部完成讀取。第二個，配置成設備偏向，設備讀取可以在設備內完成，不需要向主機發送請求。

同樣的，后面還有幾個流程示例，先不貼了。

3.5.2 Type2和Type 3的內存流

為了支持節省延遲，CXL.mem包含一個推測性內存讀取命令（MemSpecRd），用于在主代理解決一致性之前啟動內存訪問。解決完一致性問題后，主機可能會發出請求讀取（MemRd，MemRdOwn），設備應與較早的MemSpecRd合并以節省延遲，見下圖。為了避免性能影響，建議將MemSpecRd命令視為低優先級，以避免其它正常請求訪問增加延遲。

3.6 Type 3設備的事務流

Type 3設備是內存擴展器，它既不緩存主機內存，也不需要主機主動管理設備緩存。因此，Type 3設備沒有DCOH代理。主機將這些設備視為分解的內存控制器。到Type 3設備的事務流簡化為兩個類，即讀和寫。

M2S讀取Type 2設備與Type 3設備的關鍵區別在于，Type 3設備沒有S2M NDR響應消息。與Type 2設備一樣，向Type 3設備的寫入完成也需要S2M NDR Cmp消息

本章總結：這一章的內容極多，很多地方看的也是暈頭轉向，先搭個架子在這，以后有需要或者有時間再來仔細研究。

審核編輯 ：李倩