私は以前、高性能ネットワーク向けテストシステムを開発する計測機器メーカーであるSpirent社に勤務していました。製品はTest Centerと呼ばれ、非常に優秀なチームと共に、RoCEv2システムのテストに使用されるシステムを開発していました。私の主な担当は、優先フロー制御（PFC）と、800GbpsのFPGAベースの「パケットアナライザおよびジェネレータ」（PGAとも呼ばれる）でPFCを有効にする方法でした。

しかし、私はレイヤー4を実際に見たことがなかったので、このメモでは、InfiniBandトランスポート層（L4）の主要な要素を明確にし、いくつかの図を用いて視覚化することで、このギャップを埋めようと試みます。

RoCEv2フレーム 見出しへのリンク

まずは実際のRoCEv2フレームから見ていきましょう。

RoCEv2フレーム

ベーストランスポートヘッダー (BTH) 見出しへのリンク

BTHヘッダーに含まれる主要フィールド：

  • オペコード: RDMA_WRITE、RDMA_READなどのRDMA操作の種類を指定するために使用されます。

  • 宛先キューペア: パケットの異なる宛先キューペアを区別するために使用されます。

  • 確認応答要求: 受信側がこのパケットに対してACKを返す必要があるかどうかを示します。

  • パケットシーケンス番号（PSN）：確実な配信のためのパケットシーケンス追跡に使用されます。

UDPは信頼性の低いプロトコルであり、フレームが失われたり、順序が狂ったり、重複したりする可能性があるため、PSNを使用して正しい配信を保証します。しかし、これはIBTLがフレームの再送信を要求する方法が必要であることも意味します。これは、後述するAETHヘッダーを使用して実現されます。

拡張トランスポートヘッダー (ETH) 見出しへのリンク

InfiniBandトランスポート層には、特定の機能に使用される拡張ヘッダーがいくつかあります。RDMAの場合、最も重要なのはRETHとAETHの2つです。

RDMA拡張トランスポートヘッダー（RETH） 見出しへのリンク

RDMA_WRITE操作にはいくつかの要素が必要であり、それらはRETH拡張ヘッダーのフィールドで表現されます。このヘッダーは、受信側のハードウェアに対して、書き込み操作の詳細（以下を含む）を伝えます。

  • 仮想アドレス：データが書き込まれるメモリ上のアドレス

  • リモートキー (R_Key): メモリ領域へのアクセス権限を検証するアクセスキー

  • 長さ：転送するデータのサイズ

ACK 拡張トランスポート ヘッダー (AETH) 見出しへのリンク

前述のとおり、IBTLは信頼性の低い送信の場合に送信者に通知する必要があります。これは、以下のフィールドを含むEATH拡張機能を使用して行われます。

  • シンドローム: フロー制御情報とともに、成功 (ACK)、エラー状態 (NAK)、または受信側準備未完了 (RNR) ステータスを示す応答コードを含むフィールド

  • メッセージシーケンス番号 (MSN): 直近に完了したメッセージのシーケンス番号を示し、シーケンス番号が小さいメッセージはすべて正常に受信されたことを意味します。

カスタム拡張機能 見出しへのリンク

IBTL仕様書（第9章を参照）には、かなりの数の拡張機能が含まれており、そのうちのいくつかは私の注意を引きました。

  • 比較と交換: ロックフリー同期が可能になります。

  • 送信と書き込み：前者は制御フローに使用され、後者はデータフローに使用されます。

  • 即時拡張：転送されるメモリとともにサイドチャネルメタデータの交換を可能にする。

ヘッダーにどの拡張機能が含まれているかをどうやって知るのか、私も疑問に思っていました。答えは簡単です。各オペコードに対して、解析する拡張機能のリストがあり、そのリストは仕様の一部として静的に定義されています。

象の流れの課題 見出しへのリンク

Toni Pasanenが自身のブログThe Network Timesで述べているように：

GPU間通信は膨大なデータフロー（エレファントフロー）を生成し、RDMA対応NICはこれを回線速度で送信します。これらのフローは、バックエンドネットワークで容易に輻輳を引き起こす可能性があります。

RDMAが回線速度でトラフィックを生成できる能力は素晴らしい。しかし、これはフローレットサイズ（連続する2つの非アクティブ時間の間のフローのサイズ）に関する問題も引き起こす。RDMAエレファントフローを使用すると、「非アクティブギャップ」にアクセスできる確率が著しく低下するのだ。

フローレットサイズ - RDMA vs TCP 画像出典: RDMA のネットワーク内再順序付けをサポートするネットワーク負荷分散

負荷分散の課題 見出しへのリンク

もう一つの複雑な点は、スパインリーフ型トポロジーにおける負荷分散に関するもので、パケットスプレー方式の負荷分散を使用する場合、単一のキューペア上でパケットが順不同で受信される可能性があります。この複雑さをNvidiaは「RDMA書き込み専用」と呼ばれる新しいRDMA操作を導入することで解決しました。

パケットスプレー：オペコード：TDMA書き込み専用 元画像出典：The Network Times

＃ 結論

これは「進行中」のメモであり、IBTLに関する情報が見つかり次第、随時更新していきます。

RDMAはネットワーク効率の課題を解決するための非常に洗練された試みであると同時に、新たな課題も伴う、ということ以外にはまだ結論は出ていない。

References: