칩렛 재시작 뒤 도착한 완료가 새 요청을 끝내면 안 되는 이유

가속기 die를 재시작했더니 링크는 다시 켜졌지만 드라이버의 요청 하나가 끝나지 않는다. 더 곤란한 경우에는 이전 요청의 완료가 새 요청의 완료로 받아들여진다. chiplet reset recovery에서는 재훈련 성공 이후에 남은 거래의 의미를 닫아야 한다. 리셋된 저장 공간과 리셋되지 않은 기록 사이의 경계가 핵심이다.

링크를 비우는 일과 거래를 끝내는 일

UCIe 2.0의 LinkReset 규칙은 retry 버퍼를 가능한 범위에서 부드럽게 비우되, 그것을 기다리느라 LinkReset 진입이 끝없이 지연되지 않도록 한다. 해당 FDI가 LinkReset에 들어가면 프로토콜과 어댑터가 관련 파이프라인과 retry 버퍼를 drain·flush해야 한다. 원문 499쪽, 10.3.3.5절

이 처리가 이전 명령을 모두 성공시켰다는 뜻은 아니다. 링크의 flit을 정리하는 것과 호스트가 기다리는 연산을 성공·실패로 완료하는 것은 서로 다른 상태 변화다. 이미 장치에서 부작용을 실행한 요청, 장치에 닿기 전의 요청, 결과를 아직 확정할 수 없는 요청을 상위 계약에 맞게 구분해야 한다.

또한 리셋의 범위를 명시한다. 하나의 프로토콜 스택의 LinkReset과 전체 die의 reset은 같은 범위가 아니다. UCIe의 multi-stack 예에서는 각 스택이 독립적으로 LinkReset에 들어갈 수 있고 관련 스택들이 모두 그 상태가 되어야 RDI의 LinkReset으로 이어진다. 원문 504쪽, 10.3.4.1절

같은 번호를 다시 쓰면 이전 완료가 끼어들 수 있다

자체 드라이버 모델을 정하자. 요청은 (세대, 번호)로 식별한다. 세대 7의 번호 3은 X에 5를 쓰는 명령이다. 시간 5에 쓰기가 실행됐고, 완료는 호스트 쪽의 별도 대기열에 이미 들어왔지만 아직 드라이버에 전달되지 않았다. 그 대기열은 가속기 die의 reset 범위 밖에 있다고 가정한다.

시간 6에 die가 재시작하고 세대를 8로 바꾼다. 시간 9에 번호 3을 다시 써서 Y에 9를 쓰는 새 명령을 냈다. 시간 10에 옛 대기열의 완료 (7,3)이 드라이버에 도착한다. 번호 3만 비교하면 아직 끝나지 않은 새 명령을 성공으로 처리할 수 있다. (8,3)과 전체 식별자를 비교하면 다른 세대의 완료를 거절하거나 별도 기록으로 보낼 수 있다.

이 예는 이전 flit이 UCIe LinkReset의 flush를 통과해서 남았다는 주장이 아니다. 이미 상위에 전달된 기록이 다른 reset domain에 남는 문제를 분리했다. 실제 시스템에서는 완료 대기열, 인터럽트, DMA로 기록한 상태와 소프트웨어 작업 대기열이 어느 reset에 속하는지 각각 확인한다.

세대 번호를 붙이는 것만으로 영구 보장이 되지는 않는다

세대 번호가 두 비트라면 네 번 바뀐 뒤 같은 값으로 돌아온다. 오래된 완료가 그때까지 남고 요청 번호도 재사용되면 (세대, 번호)까지 다시 같아질 수 있다. 따라서 세대 값의 폭, 오래된 기록의 최대 생존 시간, 재사용 전 배출 조건을 함께 정해야 한다. 유한한 번호만으로 무한히 오래 남은 메시지를 구별할 수는 없다.

이전 명령의 부작용도 별도 문제다. X에 5를 썼다는 것을 호스트가 확정하지 못한 상태에서 재발행한다면, 동일 값 쓰기는 재실행 가능한 상황일 수 있지만 계수기 증가나 자원 할당은 결과가 달라질 수 있다. 완료를 못 봤다는 이유로 모든 명령을 자동 재시도하지 않는다. 상태를 재확인할 수 있는지, 완료 기록이 유지되는지, 불명확한 결과를 어떻게 보고하는지 정의한다.

멈추는 순서와 다시 여는 순서를 검증한다

복구 중에는 새 요청을 받는 경로를 먼저 제어하고 outstanding 기록을 안정적으로 모은다. 링크와 상위 대기열을 정해진 범위에서 정리하고, 이전 세대의 요청을 정책대로 종료한다. 이후 링크의 협상·훈련과 장치 설정을 복원하고 새 세대의 요청을 허용한다. 갑작스러운 전원 손실에서는 부드러운 정리를 완료할 수 없다는 조건도 남겨야 한다.

관리 상태가 유지되는지도 확인한다. UCIe 2.0은 mainband의 관리 transport가 프로토콜 스택과 mux를 공유하는 구성에서 해당 스택의 reset·disable이 관리 경로에도 영향을 준다고 설명한다. 데이터 경로를 재시작하면서 관리 경로로 상태를 읽을 계획이라면 이 의존 관계가 맞는지 먼저 본다. 원문 362쪽, 8.2.5.2.5절

chiplet reset recovery의 완료 조건은 링크가 다시 Active인 순간보다 구체적이다. 이전 요청이 새 요청으로 바뀌지 않고, 남은 부작용의 불확실성이 정책대로 보고되며, 필요한 설정이 복원되어야 한다. reset domain과 거래 세대를 함께 추적하면 부분 재시작의 이점을 유지하면서도 오래된 상태가 새 동작을 오염시키는 문제를 막을 수 있다.