第二章 CXL系統架構

CXL支持三種設備類型，如下圖。Type1支持CXL.cache和CXL.io；Type 2支持CXL.cache，CXL.mem和CXL.io；Type 3支持CXL.mem和CXL.io。無論哪種類型，CXL.io都是不可缺少的，因為設備的發現，枚舉，配置等都是由CXL.io來負責。

傳統的非一致I/O設備主要依賴于標準的生產者-消費者訂單模型（Producer-Consumer Ordering Model），并針對主機連接的內存執行。此類設備除了工作提交和工作完成邊界上的信號外，很少與主機進行交互。此類加速器還傾向于處理數據流或大型連續數據對象。這些設備通常不需要CXL提供的高級功能，而傳統PCIe足以作為加速器連接介質。

插播一句，生產者-消費者模型是一種為了加快系統響應數據的異步模型，系統中一些慢速操作（例如網絡I/O，數據統計等）會阻塞主進程的運行，從而使得系統的吞吐量大大降低。如果我們不需要即時得到這些慢速操作的返回結果，那么我們可以使用異步的方式來解決這個問題。生產者-消費者模型通常是多對多的關系，即多個生產者對應多個消費者，他們之間通過共享一個隊列來實現通信和同步。生產者負責把請求放到隊列中，消費者負責從隊列中出去請求并作響應的處理。生產者-消費者模型的核心思想，把數據的生產者和消費者進行解耦，使二者不直接交互，從而使二者的處理速率相對來說互不影響。

2.1 Type 1 CXL設備

Type 1設備的典型應用是網卡這類高速緩存設備。

Type 1 CXL設備，應用于擁有完全一致性緩存的設備。對于這種設備，標準的生產者-消費者模型效果一般，比如，設備需要執行復雜的原子操作，而這些原子操作又不屬于PCIe的標準原子操作。基本緩存一致性允許加速器實現它選擇的任何排序模型，并允許它實現無限數量的原子操作。它們往往只需要少量的緩存，可以很容易地通過標準的處理器監聽過濾（Snoop Filter）機制輕松跟蹤。

Type 1設備支持的緩存大小取決于主機的監聽過濾能力。CXL使用CXL.cache鏈接支持此類設備，加速器可以通過該鏈接使用CXL.cache協議進行緩存一致性事務。

2.2 Type 2 CXL設備

Type 2設備的典型應用是GPU，FPGA，AI這類的加速器。

Type 2設備除了一致性高速緩存外，還具有連接到設備的內存，例如DDR、高帶寬內存（High Bandwidth Memory，HBM）等。這些設備的性能依賴于加速器和設備掛載內存（Device-attached Memory）之間的巨大帶寬。CXL的關鍵目標是為主機提供一種將操作數推入設備掛載內存的方法，并為主機提供從設備掛載內存中提取結果的方法，這樣就不會增加抵消加速器好處的軟件和硬件成本。CXL將一致的系統地址映射設備連接內存稱為“主機管理的設備內存“（Host-managedDevice Memory，HDM）。

HDM和傳統IO/PCIe專用設備內存（Private Device Memory，PDM）之間有一個重要區別。用帶有GDDR的GPGPU來舉例，GPGPU往往將其GDDR視為私有。這意味著主機無法訪問GDDR，并且與系統的其余部分不一致。它完全由設備硬件和驅動程序管理，主要用作具有大型數據集的設備的中間存儲。這種模型的明顯缺點是，在引入操作數并將結果寫回時，它涉及大量從主機內存到設備連接內存的來回拷貝。HDM雖然也是掛載在設備端，但可以被主機直接訪問。

2.2.1 偏向性一致性協議

再次強調，HDM是附屬于設備的內存，也就是說HDM在設備端，而不是主機端。

偏向性一致性模型（Bias Based coherency model）定義了設備掛載內存（Device-attached Memory）的兩種狀態：偏向主機（Host Bias）還是偏向設備（Device Bias）。當設備掛載內存偏向主機時，該內存就像常規的主機連接內存一樣。也就是說，如果設備需要訪問該內存，設備需要向主機發送一個請求，主機將解析請求的一致性。當設備掛載內存處于偏向設備時，要保證主機中沒有對應的緩存行副本。這樣設備可以隨意的訪問設備掛載的存儲，而不需要向主機發送任何的請求事務。

需要注意的是，主機本身可以看到與設備連接的內存的統一視圖，而不考慮偏向狀態。在這兩種模式中，設備連接的內存都可以保持一致性。

帶有偏向性的一致性模型的優點：

有助于維護映射到系統一致性地址范圍內的設備掛載內存的數據一致性。

幫助設備以高帶寬訪問其本地連接的內存，同時不會產生顯著的一致性開銷（例如，對主機的監聽）。

幫助主機以一致的統一的方式訪問設備掛載的存儲，就像掛載在主機自己下面一樣。

為了維護偏向性一致性模型，Type 2的設備需要：

實現偏向表，該表跟蹤頁面粒度上的偏向性（例如1b/4KB頁面），該表可被緩存在設備中。

使用轉換代理（Transition Agent，TA）支持偏向性轉換。這本質上看起來像是一個用于“清理”頁面的DMA引擎，會清空該頁中對應主機里所有的緩存行。

構建對加速器本地內存的基本load/store訪問。

2.2.1.1 主機偏向性

主機偏向模式通常是指在工作提交期間主機將操作數據寫入內存，或在工作完成后從內存讀取數據。如下圖所示，內存掛在設備端。在主機偏向模式下，一致性數據流從主機到設備掛載內存，如圖中的藍色箭頭所示。但是，設備對此內存的訪問效率不是最佳的，因為需要通過主機，如圖中的綠色箭頭所示，設備先向主機發起請求，然后通過主機來訪問HDM。

2.2.1.2 設備偏向性

在設備偏向模式下，設備負責工作提交和完成。在此模式下，設備需要對設備掛載內存完成高帶寬和低延遲訪問。設備無需詢問主機的一致性引擎，而直接發起訪問，如圖中的紅色箭頭所示。主機仍然可以訪問設備掛載的內存，但可能會被加速器強制放棄所有權，如圖中的綠色箭頭所示。設備訪問HDM內存實現了延遲低，帶寬高，但是主機訪問HDM會卻相反。

2.2.1.3 模式管理

有兩種HDM偏向性模式管理方案：軟件輔助和硬件自主。

2.2.1.4 軟件輔助偏向模式管理

在軟件輔助管理模式下，依靠軟件來管理某頁面的狀態。通過選擇適當的主機或設備偏向模式，軟件可以在頁面粒度上優化一致性性能。

軟件輔助偏向性管理的特點如下：

這種方式適用于，在執行計算操作前，加速器內的數據已經準備好。

如果未提前將數據移動到加速器內存中，加速器通常會根據對數據的一些嘗試引用來控制移動數據。

在“需要的”數據提取場景中，加速器必須能夠找到要執行的工作，對于這些工作，數據已經正確放置，否則它必須暫停。

加速器停頓的每個周期會影響軟件運行性能。

簡單的加速器通常無法隱藏數據預取的延遲。

2.2.1.5 硬件自主偏向模式管理

軟件輔助方式通常適用于簡單的加速器。對于復雜的加速器，比如GPU，用軟件去管理偏向性將會很復雜，并不適用。硬件自主偏向性管理模式，不依賴軟件來管理頁面級的一致性偏向。相反，是硬件根據給定頁面的請求者對偏向模式進行預測，并相應地進行調整。這種模式的主要好處是：

提供與軟件輔助模型中相同的頁面粒度一致性偏向功能。

無需軟件在卸載執行之前識別和安排頁面偏向轉換。

為卸載執行期間的動態偏向轉換提供硬件支持。

此模型的硬件支持可以是軟件輔助模型的簡單擴展。

鏈路流和主機支持不受影響。

影響主要限于當主機接觸到設備偏向頁面時在加速器上采取的操作，反之亦然。

注意，盡管這是一個表面上看來是硬件驅動的解決方案，但硬件不需要自動執行所有轉換（盡管如果需要，也可以這樣做）。

2.3 Type 3 CXL設備

Type 3的典型應用是內存緩沖器，常用作內存帶寬或者是容量的擴展。

Type 3 CXL設備支持CXL.io和CXL.mem協議。由于這些設備不是加速器，所以它們不會通過CXL.cache發出任何請求。該設備主要通過CXL.mem運行，為主機發送的請求提供服務。CXL.io協議主要用于設備發現、枚舉、錯誤報告和管理。CXL.io協議允許設備用于其它特定于I/O的應用用途。

2.4 多邏輯設備（MultiLogical Device，MLD）

CXL 2.0僅支持Type 3的多邏輯組件。MLD組件最多可以將其資源劃分為16個獨立的邏輯設備（Logical Device，LD）。在CXL.io和CXL.mem協議中，每個邏輯設備都由邏輯設備標識符（LD-ID）標識。每個邏輯設備都作為Type 3設備運行，對虛擬層次結構（Virtual Hierarchy，VH）可見。LD-ID對訪問VH的軟件是透明的。MLD組件對于所有邏輯設備中的每個協議都有公共事務層和鏈路層。

MLD組件有一個為FM（Fabric Manager）保留的LD和最多16個可用于主機綁定的LD。FM擁有的LD（FMLD）允許FM跨LD配置資源分配，并管理與多個VCS（VirtualCXL Switch）共享的物理鏈路。

插播一句，VH是PCIe MR-IOV（Multiple Root I/O Virtualization）里面的一個概念。MR-IOV擴展了SR-IOV規范，允許PCIe設備在多個有獨立PCI根的系統之間共享，這些系統通過基于PCIe轉換器的拓撲結構與PCIe設備或者PCIe-PCI橋相接。每個VH（一個VH就是一個虛擬獨立的SR-IOV設備）擁有獨立的PCI Memory，IO，配置空間。

2.4.1 LD-ID for CXL.io and CXL.mem

LD-ID是一個16位邏輯設備標識符，適用于CXL.io和CXL.mem請求和響應。MLD設備返回的所有目標請求和響應必須包括LD-ID。

2.4.1.1 LD-ID for CXL.mem

CXL.mem僅支持LD-ID的低4位，因此可以通過鏈路支持多達16個唯一的LD-ID值。通過MLD端口轉發的請求和響應用LD-ID標記。

2.4.1.2 LD-ID for CXL.io

CXL.io支持為通過MLD端口轉發的所有請求和響應攜帶16位LD-ID。LD-ID0xFFFF是保留的，始終由FM使用。CXL.io利用供應商定義的本地TLP前綴來攜帶16位LD-ID值。供應商定義的本地TLP前綴格式如下所示。

2.4.2 內存池設備配置寄存器

每個LD作為一個或多個PCIe EP（End Point） Function對軟件可見。雖然LD Function支持所有配置寄存器，但影響常見鏈路行為的幾個控制寄存器被虛擬化，對鏈路沒有直接影響。LD的每個Function都必須實現PCIe規范中所述的配置寄存器。

下表列出了一組寄存器字段，與PCIe基本規范相比，這些字段的行為發生了修改。

2.5 CXL設備擴展

CXL設備擴展限制只允許每個VH（Virtual Hierarchy）啟用一個Type 1或Type 2設備。

本章總結：這一章主要定義了3類CXL設備，Type 1支持CXL.cache和CXL.io；Type 2支持CXL.cache，CXL.mem和CXL.io；Type 3支持CXL.mem和CXL.io。這三類設備都需要支持CXL.io協議，不同的是對CXL.cache和CXL.mem支持。 【待續】

審核編輯：劉清