저는 고성능 네트워킹용 테스트 시스템을 개발하는 테스트 및 측정 회사인 Spirent에서 근무했었습니다. 해당 제품은 Test Center라고 불렸으며, 뛰어난 팀원들과 함께 RoCEv2 시스템 테스트에 사용되는 시스템을 개발했습니다. 특히 저는 우선순위 흐름 제어(PFC)에 집중하여 800Gbps FPGA 기반 “패킷 분석기 및 생성기”(PGA)에서 PFC를 활성화하는 방법을 연구했습니다.
하지만 저는 실제로 레이어 4를 살펴본 적이 없었고, 이 메모는 인피니밴드 전송 계층(L4)의 핵심 요소를 설명하고 몇 가지 다이어그램을 통해 시각화함으로써 이러한 격차를 해소하고자 합니다.
RoCEv2 프레임 Link to heading
먼저 실제 RoCEv2 프레임부터 살펴보겠습니다.
기본 전송 헤더(BTH) Link to heading
BTH 헤더에 포함된 주요 필드:
오퍼코드: RDMA_WRITE, RDMA_READ 등과 같이 RDMA 작업 유형을 지정하는 데 사용됩니다.
목적지 큐 쌍(Destination QP): 패킷에 대한 서로 다른 목적지 큐 쌍을 구분하는 데 사용됩니다.
확인 응답 요청: 수신 측에서 이 패킷에 대한 확인 응답(ACK)을 반환해야 하는지 여부를 나타냅니다.
패킷 순서 번호(PSN): 안정적인 전송을 위한 패킷 순서 추적에 사용됩니다.
UDP는 프레임 손실, 순서 오류 또는 중복이 발생할 수 있는 신뢰성이 낮은 프로토콜이므로, PSN(프레임 순서 오류)을 사용하여 정확한 전송을 보장합니다. 하지만 이는 IBTL(인터페이스 전송)에서 프레임 재전송을 요청할 수 있는 방법이 필요하다는 것을 의미하기도 합니다. 이러한 재전송 요청은 아래에서 설명하는 AETH 헤더를 통해 이루어집니다.
확장 전송 헤더(ETH) Link to heading
인피니밴드 전송 계층에는 특정 기능을 위해 사용되는 여러 확장 헤더가 있습니다. RDMA의 경우 가장 중요한 두 가지는 RETH와 AETH입니다.
RDMA 확장 전송 헤더(RETH) Link to heading
RDMA_WRITE 작업에는 여러 요소가 필요하며, 이러한 요소는 RETH 확장 헤더의 필드에 표현됩니다. 이 헤더는 수신 하드웨어에 쓰기 작업에 대한 세부 정보를 알려주는데, 여기에는 다음이 포함됩니다.
가상 주소: 데이터가 기록될 대상 메모리 주소
원격 키(R_Key): 메모리 영역에 대한 권한을 검증하는 액세스 키입니다.
길이: 전송할 데이터의 크기
ACK 확장 전송 헤더(AETH) Link to heading
앞서 설명했듯이, IBTL은 전송이 불안정할 경우 발신자에게 알려야 합니다. 이는 다음 필드를 포함하는 EATH 확장 기능을 사용하여 수행됩니다.
신드롬: 성공(ACK), 오류 조건(NAK) 또는 수신 준비 안 됨(RNR) 상태를 나타내는 응답 코드와 흐름 제어 정보를 포함하는 필드
메시지 순서 번호(MSN): 가장 최근에 완료된 메시지의 순서 번호를 나타냅니다. 이는 순서 번호가 낮은 모든 메시지가 성공적으로 수신되었음을 의미합니다.
사용자 정의 확장 기능 Link to heading
IBTL 사양 (9장 참조)에는 꽤 많은 확장 기능이 포함되어 있는데, 그중 일부가 제 관심을 끌었습니다.
비교 및 교환: 락 없는 동기화를 가능하게 합니다.
전송 vs 쓰기: 전자는 제어 흐름에 사용될 수 있고, 후자는 데이터 흐름에 사용될 수 있습니다.
즉시 확장: 메모리 전송과 함께 사이드 채널 메타데이터 교환을 허용합니다.
헤더에 어떤 확장 기능이 있는지 어떻게 알 수 있는지 궁금했었는데, 답은 간단합니다. 각 오퍼레이션 코드마다 파싱해야 할 확장 기능 목록이 있는데, 이 목록은 명세의 일부로 정적으로 정의되어 있습니다.
코끼리 흐름 챌린지 Link to heading
Toni Pasanen이 자신의 The Network Times 블로그에서 언급한 바와 같이:
GPU 간 통신은 엄청난 양의 트래픽을 발생시키는데, RDMA를 지원하는 NIC는 이를 회선 속도로 전송합니다. 이러한 트래픽은 백엔드 네트워크에 쉽게 혼잡을 초래할 수 있습니다.
RDMA가 회선 속도로 트래픽을 생성할 수 있다는 점은 놀랍습니다. 하지만 이는 플로우렛 크기(연속적인 두 비활성 시간 사이의 플로우 크기)와 관련된 문제를 야기하기도 합니다. RDMA 엘리펀트 플로우를 사용할 경우 “비활성 간격"에 접근할 확률이 현저히 낮아지기 때문입니다.
그림 출처: RDMA를 위한 네트워크 내 재정렬 지원을 통한 네트워크 로드 밸런싱
로드 밸런싱 과제 Link to heading
또 다른 복잡한 문제는 스파인-리프 토폴로지에서 로드 밸런싱을 할 때, 패킷 스프레이 방식의 로드 밸런싱을 사용하면 단일 큐 쌍에서 패킷이 순서대로 수신되지 않을 수 있다는 점입니다. 이러한 복잡성을 해결하기 위해 엔비디아는 “RDMA 쓰기 전용"이라는 새로운 RDMA 연산을 도입했습니다.
원본 이미지 출처: The Network Times
결론 Link to heading
이 메모는 제가 IBTL에 대한 추가 정보를 찾는 대로 계속 업데이트할 “활성” 메모입니다.
아직 결론을 내릴 수는 없지만, RDMA는 네트워크 효율성 문제를 해결하려는 매우 우아한 시도이며, 동시에 새로운 과제들을 제시한다는 점은 분명합니다.
References: