CXL spec이 매우 방대한 내용을 담고 있기 때문에 본 블로그에서는 CXL spec을 이해하기 위해 도움이 될 만한 것들을 골라서 간략히 정리하였습니다. 자세한 내용은 PCIe/CXL spec을 참고해주세요.
이전 글)
CXL.cache 개요
CXL.cache 프로토콜은 장치와 호스트 간의 상호작용을 정의하며, 각 요청에는 최소 하나의 응답 메시지와 때로는 데이터 전송이 포함됩니다. 이 인터페이스는 각 방향으로 세 개의 채널로 구성됩니다: Request, Response, Data. 각 채널은 방향(D2H, H2D)과 전송하는 트랜잭션(Request, Response, Data)을 나타냅니다. 독립적인 채널을 통해 다양한 종류의 메시지가 전용 와이어를 사용하며, 와이어당 높은 유효 처리량을 달성할 수 있습니다.
CXL.cache 채널
D2H Request
D2H Request 채널은 장치에서 호스트로의 새로운 요청을 전송합니다. 이러한 요청은 일반적으로 메모리를 대상으로 하며, 각 요청은 최대 두 개의 응답과 하나의 64바이트 캐시라인 데이터를 수신할 수 있습니다. 채널은 문제 없이 백프레셔를 받을 수 있습니다.
D2H Response
D2H Response 채널은 장치에서 호스트로의 모든 응답을 전송합니다. 응답은 snoop에 대한 응답으로 캐시 라인의 상태를 나타내며, 데이터 버퍼로 데이터를 반환할 수 있습니다. 링크 레이어 크레딧으로 인해 일시적으로 차단될 수 있지만, 다른 트랜잭션이 완료될 필요는 없습니다.
D2H Data
D2H Data 채널은 장치에서 호스트로의 모든 데이터와 바이트 인에이블을 전송합니다. 데이터 전송은 snoop의 결과로 또는 캐시 용량 부족으로 인한 명시적 쓰기 백의 결과로 이루어집니다. 모든 경우에 64바이트의 전체 캐시라인 데이터가 전송됩니다.
H2D Request
H2D Request 채널은 호스트에서 장치로의 요청을 전송합니다. 이러한 요청은 일관성을 유지하기 위한 snoop입니다. snoop에 대한 데이터가 반환될 수 있습니다. 요청은 반환 데이터가 기록될 데이터 버퍼의 위치를 전달합니다. H2D Request는 장치 리소스 부족으로 인해 백프레셔를 받을 수 있지만, 이러한 리소스는 D2H 요청이 진행되지 않아도 해제되어야 합니다.
H2D Response
H2D Response 채널은 순서 지정 메시지와 쓰기 데이터 요청을 처리합니다. 각 응답은 원래 장치 요청의 식별자를 포함하여 응답이 어디로 라우팅되어야 하는지를 나타냅니다. H2D Response는 일시적으로 링크 레이어 크레딧으로 차단될 수 있습니다.
H2D Data
H2D Data 채널은 장치 읽기 요청에 대한 데이터를 전달합니다. 모든 경우에 64바이트의 전체 캐시라인 데이터가 전송됩니다. H2D 데이터 전송은 링크 레이어 크레딧으로 일시적으로 차단될 수 있습니다.
CXL.cache 트랜잭션
Device to Host 요청
CXL.cache Read
장치에서 호스트로의 캐시 라인 읽기 요청으로, 호스트에서 데이터를 수신하고 요청을 완료합니다.
D2H Request Channel
- D2H Read Request Message: 다이어그램의 시작점에서, Device는 호스트에게 읽기 요청을 전송합니다. 이 요청은 D2H(Request) 채널을 통해 전달됩니다. D2H Read Request Message는 호스트의 특정 메모리 주소에서 데이터를 읽기 위한 요청입니다.
H2D Response Channel
- H2D Response (GO) Message: 호스트는 요청을 처리한 후, H2D(Response) 채널을 통해 응답을 보냅니다. 이 응답은 "GO" 메시지로, 요청된 데이터가 준비되었음을 나타냅니다. 다이어그램에서는 'Not present for RdCurr'로 표시되어 있는데, 이는 RdCurr(Read Current) 요청의 경우 GO 메시지가 필요 없음을 의미합니다.
H2D Data Channel
- H2D Data Message (32 B): 응답 후, 호스트는 H2D(Data) 채널을 통해 32바이트 크기의 데이터 메시지를 전송합니다. 이 메시지는 Device가 요청한 데이터를 포함하고 있습니다. 첫 번째 32바이트 데이터 메시지가 전송되고 나서, 동일한 채널을 통해 두 번째 32바이트 데이터 메시지가 전송됩니다. 이는 전체 64바이트의 캐시 라인 데이터를 구성합니다.
CXL.cache Read0
응답 메시지만 받고 데이터 메시지는 받지 않는 읽기 요청입니다. 자세한 예시는 spec을 참고해주세요.
CXL.cache Write
장치에서 호스트로의 캐시 라인 쓰기 요청으로, 쓰기 완료를 위해 호스트에서 데이터를 수신합니다. 자세한 예시는 spec을 참고해주세요.
CXL.cache Read0-Write
읽기-쓰기 요청으로, 호스트에서 데이터를 수신하고 쓰기 완료를 확인합니다. 자세한 예시는 spec을 참고해주세요.
Host to Device 요청
Snoop Request
호스트에서 장치로의 snoop 요청으로, 일관성을 유지하기 위해 캐시 라인을 검사합니다.
H2D Request Channel
- H2D Snoop Request Message: 다이어그램의 시작점에서, Host는 Device에게 snoop 요청을 전송합니다. 이 요청은 H2D(Request) 채널을 통해 전달됩니다. Snoop Request Message는 호스트가 특정 메모리 주소에 대한 일관성을 검사하기 위해 보냅니다.
D2H Response Channel
- D2H Response (Rsp-X) Message: Device는 snoop 요청을 받은 후, D2H(Response) 채널을 통해 응답 메시지를 보냅니다. Rsp-X 메시지는 snoop 요청에 대한 응답으로, 캐시 라인의 상태 정보를 포함합니다. 이 응답은 Host에게 snoop 요청에 대한 결과를 알립니다.
D2H Data Channel
- D2H Data Message (if RspIFwdM): 응답 메시지에 따라, 필요하다면 Device는 D2H(Data) 채널을 통해 데이터 메시지를 보냅니다. RspIFwdM 조건이 충족될 때만 데이터 메시지가 전송됩니다. 이 데이터 메시지는 64바이트의 캐시 라인 데이터를 포함할 수 있습니다.
- D2H Data Message (if RspIFwdM): 첫 번째 데이터 메시지와 동일한 조건으로, 두 번째 64바이트 데이터 메시지가 전송될 수 있습니다. 이는 전체 캐시 라인 데이터를 전송하기 위함입니다.
SnpData
share 또는 exclusive 상태로 캐시될 라인을 검사하는 snoop 요청입니다. 자세한 예시는 spec을 참고해주세요.
SnpInv
요청자에게 exclusive 상태로 소유권을 부여하기 위한 snoop 요청입니다. 자세한 예시는 spec을 참고해주세요.
SnpCur
현재 버전의 라인을 얻기 위한 snoop 요청으로, 캐시 상태를 변경할 필요는 없습니다. 자세한 예시는 spec을 참고해주세요.
결론
CXL.cache 트랜잭션 레이어는 장치와 호스트 간의 효율적인 데이터 전송과 일관성 유지를 위한 중요한 역할을 합니다. 각 채널의 독립성과 크레딧 기반 흐름 제어는 높은 성능과 확장성을 보장합니다. CXL.cache 프로토콜을 통해 다양한 장치와 호스트 간의 상호작용을 최적화할 수 있으며, 이는 고성능 컴퓨팅 환경에서 중요한 역할을 합니다.
Reference)
- Compute Express Link Specification
'Interface Standards > CXL' 카테고리의 다른 글
[5] CXL - Transaction layer - Transaction Flow (0) | 2024.07.07 |
---|---|
[4] CXL - Transaction layer - CXL.mem protocol (0) | 2024.07.07 |
[2] CXL - Transaction layer - CXL.io protocol (0) | 2024.07.07 |
[1] CXL Architecture (0) | 2024.07.07 |
[0] CXL Introduction: why CXL? (0) | 2024.05.11 |
포스팅이 좋았다면 "좋아요❤️" 또는 "구독👍🏻" 해주세요!