InfiniBand 소프트웨어 스택의 위치
작성일:2014.04.25
수정일:2014.05.11
이 페이지에서는 InfiniBand 소프트웨어 스택의 위치를 소개한다.
1. 개요
InfiniBand 네이티브 API 는 InfiniBandVerbs 로 불린다. Verbs 는 동사를 의미하는verb 에서 비롯된다. InfiniBand 규격에서 API 와 같은 제대로 된 규약을 만들지 않고, 인터페이스가 갖추어야 할 요건을 자연어로 설명한 정의집만 만들었기 때문에 이와 같은 이름이 붙여졌다고 생각된다.
물론, 그것으로는 프로그래밍할 수 없기 때문에 현재는 일반적으로 시스템콜과 같은 정의가 이루어지고 있다. 그리고 커널에서 액세스하는 인터페이스는 Kernel Verbs API 로 ib_
접두사가 붙은 함수로 정의되어 있다.
Fig 1: InfiniBand Software Stack
InfiniBand는 Kernel Verbs API 를 기반으로 그 위에 Upper Level Protocol (ULP) 이라고 불리는 인터페이스를 여러개 준비하고 있다.
User Verbs API
Kernel Verbs API 와 거의 일대일로 대응하는 User API.
User MAD API
MAD 의 송수신에 관련된 API.
IPoIB (IP over InfiniBand)
UD 서비스 또는 RC 서비스를 사용해 IP 네트워크계층을 구현한 서비스.
RDMA CM (RDMA Communication Manager)
Verbs API 커뮤니케이션의 확립에 관한 처리를 랩핑하여 사용하기 쉽게한 라이브러리이다. 커뮤니케이션 학립 후 통신은 Verbs API 와 거의 동등하다. 또한 QP 기반이 아니라 소켓 기반의 RDMA Socket API (rsocket) 도 포함하고 있다.
iSER (iSCSI RDMA Protocol)
iSCSI 프로토콜을 확장하여 SCSI 버퍼 사이에서 RDMA 를 가능하게 하는 기능.
SRP (SCSI RDMA Protocol)
SCSI 프로토콜에서 RDMA 를 가능하게 하는 확장.
MPI 라이브러리 및 uDAPL 는 User Verb API 와 RDMA CM API 간접적으로 이용하고 있다.
MPI (Message Passing Interface)
HPC 의 일반적인 병렬처리 프레임 워크
uDAPL (User Direct Access Programming Library)
RDMA 를 사용한 데이터 통신 공통 규격으로 http://www.datcollaborative.org 에 정의되어 있다.
RDS 와 SDP 는 예전에 ULP 에 포함되어 있었지만, 폐지 되었다.
RDS (Reliable Datagram Sockets)
Reliable Datagram 서비스를 사용해 UDP 소켓과 같은 인터페이스로 통신하는 라이브러리.
SDP (Sockets Direct Protocol)
InfiniBand 를 기반으로 TCP 소켓과 같은 인터페이스로 통신하는 라이브러리. 또한 SDP 는 LD_PRELOAD 로 libsdp.so 를 프리로드(preload)하여 기존TCP 소켓 통신 프로그램을 대체할 수 있다.
2. Upper Level Protocol (ULP)
ULP 중 User Verbs, IP over InfiniBand (IPoIB), RDMA CM 에 대해 설명한다. 나머지 ULP 에 대해서는 필자도 잘 모르기 때문에 설명할 수 없다.
2.1 User Verbs
InfiniBand 사용자 영역에서 프로그램 인터페이스는User Verbs(uVerbs) 이다. User Verbs 는 ibv_
접두사가 붙은 함수로 정의 된다. 이 사이트의InfiniBand 프로그램에 대한 일련의 기사는 uVerbs 프로그래밍의 해설을 대상으로 하고 있다.
uVerbs 는 초기화나 통신확립 에러 처리를 위해 커널을 경유하여 HCA 기능을 호출하지만, 보통은 커널을 경유하지 않고, 사용자 영역에서 HCA 를 제어하는 기능을 가지고 있다. 이 특징을 커널 바이패스(Kernel Bypass)라 부른다.
커널 바이패스를 실현하려면 HCA 와 사용자 영역에서 공통으로 읽고 쓸 수 있는 메모리 공간을 맵핑하고, 그곳을 통해서 uVerbs API 의 파라미터를 전달한다. 이 영역을Doorbell 이라고 부르는 경우가 있다. 사용자 영역의 uVerbs API 가 파라미터를 doorbell 에 기록, HCA 는 기록을 캐치하여 전송을 시작한다.
Doorbell 의 형식은 HCA 에 의존한다. 또한 커널 바이패스를 사용하지 않고, 모든 API 를 슈퍼바이저 콜에서 실현하는 HCA 도 고려할 수 있다. 이와 같은 구현의 자유를 허용하기 위해 uVerbs 드라이버는 범용 libibverbs.so 와 HCA 마다 제공되는 플러그인 모듈의 2단 구성으로 되어 있다. 플러그인 모듈은 libXXX-rdmav2.so 라는 이름이다.
HCA 는 검출 순서대로 /dev/infiniband/uverbsX, /sys/class/infiniband_verbs/uverbsX/ 가 생성된다. User Verbs API 초기화시에는 sysfs 아래의 /sys/class/infiniband_verbs/uverbsX/ibvdev 전부를 읽어 들인다. 이 중에는 HCA 식별자(mlx4_0, mlx4_1, pib_0, pib_1, …)가 있어 필요한 플러그인 모듈을 지정할 수 있고, libmlx4-rdmav2.so 나 libpib-rdmav2.so 을 로드한다. User Verbs API 의 호출은 로드한 플러그인 모듈을 경유하게 된다.
Fig 2: User Verbs 실행 모델
User Verbs 를 사용하는 프로그램은 개별 플러그인 모듈 경유로 /dev/infiniband/uverbsX를 open()
해서 HCA 에 액세스 한다.
2.2 IP over InfiniBand (IPoIB)
IPoIB 는 InfiniBand 레이어 위에 IP 네트워크 계층을 구성한 서비스이다. IP 데이터그램을 UD 데이터그램으로 캡슐화해서 전송하는 것을 허용한다. HCA 포트마다 ib0, ib1, …, ibN 과 같이 네트워크 디바이스가 만들어지고, IPv4 또는 IPv6 의 IP 네트워크를 구성할 수 있다. ICMP, UDP, TCP 를 이용할 수 있다.
IPoIB 는 어느 정도 크기의 메시지 교환에 대해서 InfiniBand 하드웨어 상의 대역에 가까운 처리성능을 제공한다. 그러나 지연시간은 비교적 크고, InfiniBand 의 특징인 낮은 지연시간은 얻을 수 없다. 또한 커널 레이어의 처리가 많기 때문에 제로 카피나 커널 바이패스도 없고, CPU 파워를 소비한다.
Mellanox ConnectX-3 에서는 IPoIB 를 위한 오프로드 엔진 기능을 가지고 있고, CPU 에서 수행하는 처리의 일부를 HCA 로 위임할 수 있다.
물론 동일한 서브넷이 이더넷과 IPoIB 를 걸치도록 구현할 수는 없다. 단지 이더넷의 IP 서브넷과 IPoIB 의 IP 서브넷 양쪽에 소속된 노드는 양쪽을 라우팅할 수 있다.
IPoIB 는 InfiniBand Trade Association 가 아니라 IETF 에서 규격을 정했다.
- Transmission of IP over InfiniBand (IPoIB) (RFC 4391)
- IP over InfiniBand (IPoIB) Architecture (RFC 4392)
- IP over InfiniBand: Connected Mode (RFC 4755)
브로드캐스팅의 구현 방법
개념편에서 강조했지만, Internet Protocol over Ethernet 의 특징은 로컬 네트워크 내의 Name Resolution1에 브로드캐스팅을 이용하는 점이다. 한편, InfiniBand 는 서브넷 내에도 브로드캐스팅이 없다. 그러나 Address Resolution Protocol (ARP) 을 구현하기 위해 브로드캐스팅이 필요하다.
IPoIB 는 이 문제를 IB 멀티캐스팅을 이용해 해결한다. InfiniBand 에는 128 비트의 Global Identifier(GID)가 존재하는데, 이 중 일부가 멀티캐스팅을 위해 할당된 Multicast Global Identifier(MGID) 이다. RFC 4391 에는 IP 브로드캐스팅을 시뮬레이션하기 위한 IB 멀티캐스트 GID 가 IPv4 용과 IPv6 용 2가지가 정의되어 있다. 이것을 Broadcast-GID 라고 한다.
scop 는 서브넷 내에 닫혀 있는 경우 Link-local (2) 를 지정한다.
P_Key 는 Partition Key 를 지정한다. 이것이 VLAN 역할을 한다. 일반적으로 서브넷 내 모든 노드에 도착 가능한 디폴트 P_Key 인 FFFF 을 지정한다. 따라서 Broadcast-GID 는 IPv4 용인 ff12:401b:ffff::ffff:ffff 와 IPv6 용인 ff12:601b:ffff::ffff:ffff 두개가 된다.
IPoIB 를 동작시키고 싶은 노드는 Subnet Manager 가 서브넷 내의 LID routed Network 구축이 완료 될 때까지 기다린다. 그 후 IPoIB 노드는 Subnet Manager 에 대해 IPv4 용의 ff12:401b:ffff::ffff:ffff 와 IPv6 용의 ff12:601b:ffff::ffff:ffff 두개의 멀티캐스트 그룹에 등록할 것을 요구한다. 여기에는 QP1 을 사용한 Subnet Administration 의 MAD 패킷을 사용한다.
Subnet Manager 는 MGID 에 대해 LID 멀티캐스트 범위(0xC000 ~ 0xFFFE) 에서멀티케스트 LID(MLID)를 할당하고, IPoIB 노드로의 응답과 함께 통지한다. IPoIB 노드는 IPoIB 통신을 사용하는 UD QP 를 포트 마다 작성하여 Subnet Manager 에서 응답 된 MLID 에 연결한다. 이후, IPoIB 통신에는 이 UD QP 를 사용한다.
Broadcast-GID 에 할당된 MLID 를 지정하여 ARP 를 브로드캐스트한다. ARP 패킷 내의 hardware address 는 20 옥텟이며, 그 중에 포트 GID 와 QP 번호가 들어 있다. ARP 는 UD 패킷에 캡슐화 되어 있고, UD 서비스 메시지에는 송신처를 나타내는 LID 가 포함되어 있으므로 LID 와 QP 번호 모두 교환할 수 있게 된다.
IPoIB 네트워크 디바이스에 할당 된 hardware address 는 ip
명령으로 확인할 수 있다. 파란색의d3:38:cc 가 QP 번호이다.
$ ip link show ib0
6: ib0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 2044 qdisc pfifo_fast state UP qlen 256
link/infiniband 80:d3:38:cc:fe:80:00:00:00:00:00:00:00:0c:29:9b:a3:88:03:01 brd 00:ff:ff:ff:ff:12:40:1b:ff:ff:00:00:00:00:00:00:ff:ff:ff:ff
유니캐스트 IP 어드레스를 지정하여 통신하는 경우, UD QP 에서 ARP 로 해결한 LID & QP 번호로 IP 패킷을 UD 데이터그램에 캡슐화해서 송신한다.
IP 멀티캐스트 실현 방법
멀티캐스트 IP 어드레스를 지정해 통신하는 경우, Broadcast-GID 와 마찬가지로 IB 멀티캐스트를 할당한다. MGID 는 아래와 같은 형식이 된다. Group ID 에 멀티캐스트 IP 어드레스의 Group ID 와 일치 시킨다.
24 bits | 8 bits | 16 bits | 16 bits | 80 bits |
---|---|---|---|---|
FF1 | scop | 401B or 601B | P_Key | Group ID |
이 MGID 를 Subnet Manager 에 등록하고, MLID 를 할당 받는다.
Connected Mode
IPoIB 는 기본적으로 UD 서비스를 이용하지만, RC/UC 서비스를 이용하는 Connected Mode 도 정의되어 있다. 이를 IPoIB-CM 로 축약한다.
IPoIB-CM 에서도 ARP 에 의한 Nmae Resolution名前解決까지는 UD 와 같다. 그러나 유니캐스느 통신을 하는 경우에는, 실제 통신에 앞서 서로의 노드에 RC/UC QP 를 작성하고, 커뮤니케이션을 확립한다. 실제 통신은 UD QP 가 아니라 RC/UC QP 를 사용한다. 커뮤니케이션은 InfiniBand 에서 QP 간의 가상 통신 경로를 의미한다. RC/UC QP 에서 커넥션과 거의 같은 뜻이다.
Linux 의 IPoIB 구현에서는 Connected Mode 는 RC 서비스 구현을 제공한다. UC 서비스는 지원하지 않는다.
2.3 RDMA Communication Manager(CM)
RDMA CM 은 User Verbs 중 커뮤니케이션 확립에 관계되는 부분을 랩핑한 라이브러리이다. InfiniBand 이외의 RDMA over Converged Ethernet(RoCE) 나 iWARP 미디어에서도 이용 가능하며, 공통 API 를 제공한다. RDMA CM 은 rdma_ 접두어가 붙은 함수로 정의되어 있다.
RDMA CM 커뮤니케이션 확립은 IP 네트워크 계층을 사용해 필요한 데이터를 교환한다. 따라서 InfiniBand 를 미디어로 이용하는 경우, IPoIB 를 필요로 한다.
RDMA CM API 는 어느 정도 Socket API 와 비슷하게 만들어져 있고, 커뮤니케이션 확립까지는 Socket 과 같은 흐름이다.
Table 1: RDMA CM API 과 Socket API 의 대응관계
RDMA CM API | 대응하는 Socket API |
---|---|
rdma_create_ep | socket |
rdma_listen | listen |
rdma_accept | accept |
rdma_connect | connect |
또한 RDMA CM API 과 함께 RDMA socket API 도 제공한다. 이것은 UDP 나 TCP 와 거의 대등한 인터페이스이지만, 페이로드는 InfiniBand 를 사용해 전송한다. IPoIB 를 이용하는 경우와 비교해 RDMA socket API 는 낮은 지연시간, 낮은 CPU 부하를 실현할 수 있다.
Table 2: RDMA socket API 과 Socket API 의 대응관계
RDMA socket API | 대응하는 Socket API |
---|---|
rsocket | socket |
rbind | bind |
rlisten | listen |
raccept | accept |
rconnect | connect |
rshutdown | shutdown |
rclose | close |
rrecv、rrecvfrom、rrrecvmsg | recv、revfrom、recvmsg |
rsend、rsendto、rsendmsg | send、sendto、sendmsg |