RDMA：キュー、メモリ登録、完了セマンティクス

ワークサブミットが成功した後、デバイスがまだソースバッファを読んでいる可能性があります。また、リモートメモリが更新された後、アプリケーションがまだそれを消費していない可能性があります。RDMA は特定データパスの処理とコピーを削減しますが、⁠リソースの認可、完了、再利用を明確にする必要があります。

1. InfiniBand、RoCE、iWARP

RoCE のデプロイメントでは、ECN、輻輳制御、および適切な PFC ポリシーと併用されることが多いですが、PFC は「RoCEv2 がある場合は無条件にネットワーク全体で有効にする」という論理的前提ではありません。パケットロスおよびパージポリシーの実際の効果は、ハードウェアおよびネットワーク設計に依存し、明確な検証が必要です。また、PFC 自体がヘッドオブラインブロックや輻輳伝播を引き起こす可能性があります。

Linux の RXE、SIW などのソフトウェア実装は、対応する RDMA インターフェースの学習やテストに役立ちますが、データプレーンでは依然として CPU を消費し、ソフトウェア処理を経ます。ソフトウェア RDMA で測定された動作を、ハードウェア RNIC のパフォーマンスやバイパスの証明としてそのまま扱うことはできません。

2. QP、CQ、PD は個別に管理されるオブジェクト

QP には通常、SQ（Send Queue）と RQ（Receive Queue）が含まれます。SQ は能動的に送信される SEND、READ、WRITE などのワークを受信します。RQ は SEND などの操作に必要なバッファを提供します。CQ は個別に作成され関連付けられるオブジェクトであり、QP 構造体の定義内に必ずプライベートな第 3 のキューがあるわけではありません。

複数の QP が CQ を共有できます。send_cq と recv_cq は同じでも異なっていても構いません。SRQ を使用する場合は、複数の QP が受信リソースを共有できます。作成時に要求した能力とプロバイダが返した実際の能力を確認する必要があります。特に最大 WR、SGE、およびインラインデータのサイズが重要です。ibv_create_qp を参照してください。

PD（Protection Domain）は、QP、MR などのリソースへのアクセス制御に関与します。オブジェクトを正しい PD に配置し、アドレス、キー、アクセスフラグなどの要件を満たして初めて、登録されたメモリを合法に使用できます。ポインタの値を知っていれば DMA を送信できるわけではありません。

RC QP は通常、RESET、INIT、RTR、RTS の状態遷移を経ます。アドレス、パス、PSN、アクセス権限、リトライなどのパラメータを設定する必要があります。RDMA CM は接続管理を支援できますが、パラメータの交換と設定はプログラムで別途行うこともでき、すべてのアプリケーションが同じ CM フローを使用する必要はありません。UD などの QP タイプでは、接続、信頼性、およびサポートされるオペレーションが異なります。

3. Memory Region：登録が約束するもの

通常の MR 登録は、プロバイダ/RNIC に対してメモリアドレス範囲と権限を確立します。通常、ページ固定、DMA マッピング、およびハードウェア変換テーブルが含まれ、制限されたリソースを消費します。lkey はローカル SGE アクセスの検証に使用され、rkey は対応するリモートアクセスの検証に使用されます。

ODP（On-Demand Paging）などのメカニズムは、サポートされている環境でページマッピングを必要に応じて処理でき、作成から破棄まで全ページを固定する必要はありません。したがって、「登録は必ず全ページを永久にロックする」や「RDMA は常にページフォルトが発生しない」という主張は極端すぎます。

リモート側が受信するアドレスの意味は、MR の IOVA/ゼロベースなどの設定に依存し、常に未変換のローカル CPU ポインタとして扱うことはできません。アクセスフラグは、リモート読み取り/書き取り/アトミック操作が許可されるかどうかを決定します。リモート書き込みが必要な場合、ローカル書き込み権限などの関連要件もインターフェース設定に従って設定する必要があります。ibv_reg_mr を参照してください。

キーは暗号化キーではない

rkey はアクセス認可に関連する識別子であり、トランスポートの暗号化、認証、またはアプリケーションデータの機密性保護を提供しません。アドレス、長さなどの情報とともに信頼できるプロトコルを通じて交換され、露出範囲が制限され、リソースの取り消し時にはリモート側で進行中の操作が処理される必要があります。

プロセス全体の大きなアドレス範囲を登録すると管理回数が減少する可能性がありますが、誤ったリモート書き込みの影響範囲も拡大します。MR/MW の範囲、権限、キーの存続期間、および接続アイデンティティは、登録オーバーヘッドの削減だけを追求するのではなく、共同で設計する必要があります。

4. SEND、WRITE、READ の役割の違い

RC SEND は、リモート受信リソースが不足している場合、RNR（Resource Not Ready）とリトライをトリガーする可能性があり、最終的には失敗する可能性があります。WRITE_WITH_IMM はデータを指定されたリモートアドレスに書き込みますが、通常の SEND がデータを receive SGE に書き込むものだと誤解しないでください。ただし、受信通知には対応する RQ/SRQ のワークリソースが消費されます。

RDMA アトミック操作は、サポートされるサイズ、アライメント、操作、およびスコープの原子性のみを提供し、任意のマルチフィールドデータ構造に自動的にトランザクション整合性を持たせるものではありません。

5. Post 成功と完了成功

ibv_post_send() が成功したことは、ワークがサブミットされて受け入れられたことを示しますが、デバイスがデータの使用を完了したことを意味しません。バッチ WR チェーンの途中で失敗した場合、bad_wr は最初の失敗項目を指しますが、それ以前の項目は既に成功してサブミットされている可能性があります。エラーが見つかるとすぐにバッチ全体を解放してはいけません。

インライン以外の送信バッファは、対応する完了条件が満たされるまで存続する必要があります。インラインデータはサブミット構造体にコピーされた後、インライン契約に従って元のデータをより早く再利用できますが、キューリソースと完了管理は依然として存在します。ibv_post_send を参照してください。

CQ の返却数と WC ステータスは別々に確認する

完了レコードの数と各ワークの成功与否は、2 段階の判断です。

失敗した完了では、wr_id、status、qp_num、vendor_err などの一部のフィールドのみが有効であることが保証されます。CQ イベント通知は WC 自体ではありません。イベントはアプリケーションに poll を促し、poll によって初めて完了レコードが取得されます。通知インターフェースの契約に従ってイベントを再要求し、確認して、スリープと新しい完了の間の競合を避けてください。

unsignaled 送信を選択すると CQE の数は減少しますが、すべてのバッファを即座に再利用できるわけではありません。QP の順序、操作/fence セマンティクス、および後続の signaled 完了に基づいて回収水位を設定する必要があり、エラーパスも考慮する必要があります。CQ を長期間消費しないとオーバーランする可能性があるため、単に統計ログが1件失われるだけの小さな問題として扱ってはいけません。ibv_poll_cq を参照してください。

6. リモートメモリ更新はアプリケーショントランザクションコミットではない

リモートのレコードスロットを、完全に管理が必要なオブジェクトとして扱います。

RNIC によるデータ搬送は、これらの状態遷移をアプリケーションに自動的に補完するものではありません。

「まず payload を WRITE し、次に ready=1 を WRITE する」という手法は、QP、操作順序、メモリの可視性、および relaxed ordering などの条件を無視して、一般的な公開プロトコルとして扱うことはできません。QP を跨ぐ操作には、自動的にグローバルな順序性が保証されません。トランスポート/プロバイダの完了と fence 契約に従い、CPU の同期方法と組み合わせて通知を設計する必要があります。

リモート更新、消費、永続化は個別に確認する

通常の WRITE のローカル成功完了は、サーバーアプリケーションがデータを消費したことを意味するものでも、サーバーがデータをディスクに永続化したことを意味するものでもありません。ビジネスで永続化の確認が必要な場合、サーバー側で対応するストレージとメタデータのステップを完了した後に返信するか、永続化セマンティクスを明示的にサポートする専用ソリューションを採用する必要があります。

RDMA READ もまた、一貫性のあるスナップショットを自動的に取得するものではありません。読み取り中にリモート側がマルチフィールドオブジェクトを変更している可能性があります。バージョン番号の検証、ロック、またはコピープロトコルは依然として必要です。

以下に示すのは、リクエスト、トランスポート、CQE、リモートアプリケーションの消費、永続保存の順に見えますが、各アクションは自身の条件のみを履行します。ローカル完了の直後にソースを再利用し、その後でリモートコンテンツがすでに永続化されているかどうかを確認できます。

7. 「カーネルバイパス」の実際の範囲

ハードウェアユーザーランド verbs の高速パスは、プロバイダがマップされたキュー/ドアベルに直接アクセスできるため、操作ごとにシステムコールを削減します。しかし、カーネルは依然としてリソースの作成、マッピング認可、イベント、例外、ODP、およびデバイスのライフサイクルを処理し、アプリケーションも依然としてサブミットと poll のロジックを実行します。

パフォーマンス比較時は、まず測定境界を固定する

ビジーポーリングは CPU を使用して低レイテンシを実現します。イベント駆動はアイドル時間を削減しますが、通知コストを導入します。バッファの事前登録、メッセージサイズ、NUMA、キュー深度、輻輳、およびプロバイダがすべて効果に影響します。TCP と RDMA を比較する際は、単一操作のレイテンシ、スループット、CPU/バイト、またはアプリケーションエンドツーエンドの完了時間のいずれを指しているかを明確にする必要があります。

一部のハードウェア RoCE データパスは、通常のホスト IP ソケットスタックを経ないため、nftables のソケット/転送ルールや tcpdump がすべての RDMA トラフィックを自動的にカバーすると仮定してはいけません。リソース権限、NIC/スイッチのカウンタ、および RDMA イベントを共同で観察する必要があります。ユーザーランド verbs を参照してください。

8. RDMA デバイスとポートの読み取り専用表示

from pathlib import Path

root = Path('/sys/class/infiniband')
devices = sorted(root.glob('*'))
if not devices:
    print('no RDMA devices visible in this environment')
for dev in devices:
    print(dev.name)
    for port in sorted((dev / 'ports').glob('*')):
        for field in ('state', 'phys_state', 'link_layer'):
            try:
                print(' ', port.name, field, (port / field).read_text().strip())
            except OSError:
                pass

rdma link show などのツールは、カーネル RDMA オブジェクト情報を補完できます。デバイスが見えることは、リモート QP、MR、ルーティング、またはアプリケーションプロトコルがすでに正常に設定されていることを証明するものではありません。可視なデバイスがないことは、現在の環境のみを記述するものであり、実際のトランスポートを検証するためにこれを使用することはできません。

実装の詳細については、rdma-core の libibverbs、librdmacm、プロバイダ、およびカーネル drivers/infiniband/ を参照してください。post 関数だけを眺めるのではなく、リソースの作成、1回の完了、およびエラークリーンアップを優先して追跡してください。