Ch 13: Switching·Fabric Manager — 2.0 pooling에서 3.x fabric까지

#한 줄 요약

**“CXL switch는 2.0의 단일 계층 switch·MLD pooling에서 3.x의 multi-level switching·PBR fabric·G-FAM으로 넓어졌고, 그 구성을 바꾸는 주체가 Fabric Manager(FM)입니다.” — switch 안은 *VCS(Virtual CXL Switch)*와 vPPB로 나뉘고, FM은 FM API로 vPPB를 물리 포트·LD에 bind/unbind하거나 DCD 용량을 붙입니다. FM API는 mailbox CCI나 MCTP로 전달됩니다.

Ch 4 Pooling·GFAM에서 CXL 2.0·3.x fabric의 개념을 봤습니다. 이 장은 그 토폴로지를 움직이는 switch 구조와 Fabric Manager를 봅니다.

#세대별로 더해진 것

spec 개정 이력과 컨소시엄 발표 기준:

#Switch 안 — VCS와 vPPB

CXL switch는 PCIe switch처럼 upstream port 하나에 내부 bus와 downstream port가 붙는 구조를 가상화합니다(§7.1).

Multiple VCS의 규칙(§7.1.2) 중 FM과 관련된 것:

• 초기 binding과 VCS 구조는 switch vendor 방식으로 정합니다.
• FM은 선택 사항입니다. 다만 bind/unbind가 필요하거나 MLD 포트를 지원하는 Multiple VCS에는 FM이 필요합니다.
• downstream port는 FM이 조율하는 managed hot-plug 흐름으로 다른 VCS에 재할당될 수 있습니다.

CXL.mem 요청은 VCS의 주소 디코드 레지스터(HDM Decode)가 어느 downstream PPB로 보낼지 정합니다(§7.3.3.1).

#Routing — HBR vs PBR

host와 디바이스는 기존 메시지를 쓰고, fabric 가장자리의 Edge Switch가 PBR 형식으로 바꿉니다(§2.7).

#PBR과 deadlock

PBR switch가 한 Fabric Port에서 다른 Fabric Port로 메시지를 넘기면 의존 관계가 생깁니다(§7.7.5.1).

• PCIe tree나 fat tree처럼 loop가 없는 토폴로지는 의존도 순환하지 않습니다.
• loop가 있는 토폴로지에서는 의존이 닫힌 고리를 이뤄 deadlock이 날 수 있습니다.
• 그래서 FM이 PBR switch 라우팅 테이블을 짤 때 의존이 닫힌 고리를 만들지 않게 해야 합니다.

spec은 이 규칙을 mesh 토폴로지의 라우팅 예시로 설명합니다(Figure 7-44). mesh가 금지된 것이 아니라, 라우팅 테이블이 순환을 피해야 한다는 뜻입니다.

#Fabric Manager

spec의 정의(§7.6.1): FM은 재구성이 필요한 때를 판단하고 명령을 내리는 논리적 프로세스입니다. 형태는 무엇이든 됩니다.

FM은 FM API 명령 세트로 디바이스를 구성하고, 명령은 CCI(Component Command Interface)로 전달됩니다(§7.6.2). CCI는 두 가지로 노출됩니다.

switch에 붙은 FM은 Tunnel Management Command로 switch 아래 MLD에 명령을 터널링할 수 있습니다. FM 기능이 컴포넌트 안에 내장되면 그 내부 인터페이스는 vendor 구현 사항입니다.

FM API를 MCTP로 실을 때의 binding은 DMTF DSP0234(CXL Fabric Manager API over MCTP Binding)가 정합니다(§7.6.3). MCTP 자체는 DMTF DSP0236입니다.

#Pooling — bind와 unbind

FM이 MLD의 LD를 host에 붙이고 떼는 흐름(§7.6.6.5~7.6.6.6):

host 입장에서는 LD가 PCIe hot-plug로 나타나고 사라지는 것입니다. CEDT가 바뀌는 것이 아닙니다.

#DCD — Dynamic Capacity Device

DCD는 CXL 3.0에서 들어온, 디바이스 리셋 없이 용량을 바꾸는 메모리 디바이스입니다(§9.13.3).

용량을 붙이는 흐름:

반납은 FM이 Initiate Dynamic Capacity Release(Opcode 5605h)로 시작하면 디바이스가 host에 이벤트를 보내고, host가 Release Dynamic Capacity(Opcode 4803h)로 돌려줍니다. host가 이벤트 없이 스스로 반납할 수도 있습니다(§8.2.9.9.9.4). 즉 용량 추가는 FM이 시작하고, host 드라이버는 이벤트를 받아 수락하거나 반납하는 쪽입니다.

#자주 하는 실수

#“HBR은 Host-Based Routing”

Hierarchy Based Routing입니다. PCIe 계층 방식 라우팅을 가리킵니다.

#“PBR에서 mesh는 쓰면 안 된다”

spec은 mesh 라우팅 예시를 직접 듭니다. 조건은 FM이 라우팅 테이블을 짤 때 의존 순환을 만들지 않는 것입니다(§7.7.5.1).

#“Fabric Manager는 별도 서버·네트워크다”

FM은 논리적 프로세스이고 형태는 자유입니다. host 소프트웨어, BMC, switch firmware, 디바이스 내부 state machine 모두 됩니다(§7.6.1).

#“LD를 붙이면 host의 CEDT가 바뀐다”

bind는 vPPB를 물리 포트·LD에 연결하는 것이고, host는 이를 hot-plug로 봅니다. CEDT는 host bridge와 fixed memory window를 기술합니다.

#정리

• CXL 2.0은 단일 계층 switch·MLD pooling, 3.0은 multi-level·fabric·G-FAM·DCD, 3.1은 PBR 라우팅·FM API·deadlock 규칙을 정의했습니다.
• switch는 VCS·vPPB로 host별 가상 switch를 만들고, FM이 vPPB를 포트·LD에 bind/unbind합니다.
• HBR은 Hierarchy Based Routing, PBR은 12-bit PID 기반이며 FM이 순환 없는 라우팅 테이블을 짜야 합니다.
• FM은 형태가 자유로운 논리 프로세스. FM API는 mailbox CCI나 MCTP(DSP0234 binding)로 전달합니다.
• DCD는 DC Region·DC block·Extent List로 용량을 바꾸고, 추가는 FM이 시작해 host가 수락합니다.

#다음 편

Ch 14: Security — IDE·SPDM·TSP·CXL TEE에서 SPDM·IDE·TSP가 각각 무엇을 지키는지, 직접 연결 메모리의 confidential computing까지 봅니다.

#관련 항목

• Ch 2: System Architecture
• Ch 4: Pooling·GFAM·Fabric
• HBM·GDDR 심화 Ch 12: 메모리 풀링과 데이터센터 토폴로지
• Postmortem Debugging Ch 6: CXL Fabric Postmortem

#시리즈 자료 출처 안내

이 글은 CXL 3.1 spec(§7)과 개정 이력, CXL 3.2 발표문, CXL 4.0 웨비나, DMTF DSP0234·DSP0236를 근거로 합니다. 시리즈 전체의 자료 정책은 Ch 1에 있습니다.