InfiniBand のソフトウェアスタックの位置づけ

作成日:2014.04.25
修正日:2014.05.11

このページでは InfiniBand のソフトウェアスタックの位置づけを紹介する。

以下は関連ページ。


更新履歴
(2014.04.25) 作成。
(2014.04.26) RDMA CM の説明を追加
(2014.05.11) API にリンクを貼る


目次

1. 概要

InfiniBand のネイティブ API は InfiniBand Verbs と呼ばれる。 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 をプリロードすることで、既存の TCP ソケット通信プログラムを置き換えることができる。

2. Upper Level Protocol (ULP)

ULP のうち User VerbsIP 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/uverbsXopen() して 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 で仕様策定されている。

ブロードキャストの実現方法

概念編で強調したが Internet Protocol over Ethernet を特徴付けているのは、ローカルネットワーク内の名前解決にブロードキャストを用いる点である。 一方、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 と呼ぶ。

種類24 bits8 bits16 bits16 bits48 bits32 bitsIPv6 アドレス形式の表現
IPv4FF1scop401bP_Key00.......0all 1'sff12:401b:ffff::ffff:ffff
IPv6FF1scop601bP_Key00.......0all 1'sff12:601b:ffff::ffff:ffff

scop はサブネット内に閉じている場合は Link-local (2) を指定する。

P_KeyPartition 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 番号の両方が交換できることになる。

 +0+1+2+3
0ReservedQP Number
4GID
8
12
16

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 bits8 bits16 bits16 bits80 bits
FF1scop401B or 601BP_KeyGroup ID

この MGID を Subnet Manager へ登録し、MLID を割り当てを受ける。

Connected Mode

IPoIB はデフォルトでは UD サービスを用いるが、RC/UC サービスを用いる Connected Mode も定義されている。 これを IPoIB-CM と略される。

IPoIB-CM でも ARP による名前解決までは 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_epsocket
rdma_listenlisten
rdma_acceptaccept
rdma_connectconnect

また 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
rsocketsocket
rbindbind
rlistenlisten
racceptaccept
rconnectconnect
rshutdownshutdown
rcloseclose
rrecv、rrecvfrom、rrrecvmsgrecv、revfrom、recvmsg
rsend、rsendto、rsendmsgsend、sendto、sendmsg

コメント

コメントを書き込む

TOP    掲示板    戻る
Written by NAKAMURA Minoru, Email: nminoru atmark nminoru dot jp, Twitter:@nminoru_jp