# White-Boxing RDMA with Packet-Granular Software Control > [!abstract] 概要 > 多様なワークロードとデプロイメントに駆動され、輻輳制御・マルチテナント分離・ルーティングなどにまたがる RDMA トランスポートをカスタマイズする革新が数多く登場している。しかし RDMA のハードウェアオフロード特性は、こうした革新を実装する際に重大な硬直性をもたらす。従来のカスタマイズ実現手法は、長期のハードウェア反復を待つか、専用ハードウェアを開発するか、ブラックボックスの RDMA NIC に対して粗粒度な制御を適用するかのいずれかであった。多大な努力にもかかわらず、現行のカスタマイズワークフローは柔軟性・生の性能・広範な可用性を依然として欠いている。 > 本研究では White-Boxing RDMA を提唱する。これはハードウェアトランスポートの制御を、生のデータプレーン性能を保ちながら汎用ソフトウェアへ与えるものである。white-boxing 手法を実現するため、我々は Software-Controlled RDMA(SCR)を設計・実装する。これはハードウェアトランスポートに対するパケット粒度のソフトウェア制御を可能にするフレームワークである。高速ラインレート下での粒度制御に起因する課題に対処するため、SCR は効果的な制御モデルを採用し、フレームワーク内のサブシステムの効率を高め、新興のハードウェア機能を活用する。我々は Datapath Accelerator を備えた最新の Nvidia BlueField-3 上に SCR を実装し、レガシー RDMA トランスポートには存在しない多様な新規カスタマイズ——マルチテナント公平スケジューラ、ユーザ定義輻輳制御、受信者主導型フロー制御、マルチパスルーティング選択——を実現する。さらに、SCR が機械学習コードやストレージコードへの変更なしに GPU-Direct と NVMe-oF RDMA に適用可能であることを示す。 ## 論文情報 - 著者: Chenxingyu Zhao・Jaehong Min([[University of Washington]])、[[Ming Liu]]([[University of Wisconsin-Madison]])、[[Arvind Krishnamurthy]]([[University of Washington]]) - 会議: USENIX NSDI 2025(22nd USENIX Symposium on Networked Systems Design and Implementation, 2025-04-28〜30, Philadelphia) - リンク: https://www.usenix.org/conference/nsdi25/presentation/zhao-chenxingyu - 実装: BlueField-3 DPA 上に C/C++ で 7.8K 行 ## 概要 本論文は、RDMA トランスポートのハードウェアオフロードが持つ硬直性を、スイッチの white-boxing(制御プレーンをソフトウェアへ、データプレーンを高性能ハードウェアへ)という先行事例に倣って解消しようとする研究である。著者らは Software-Controlled RDMA(SCR)というフレームワークを提案し、BlueField-3 の Datapath Accelerator(DPA)上に実装する。SCR は「何を制御するか(What to Control)」への回答として Dequeue Rate Control Model(デキュー速度制御モデル)を、「どう制御するか(How to Control)」への回答として Event-Driven Rate Computation Framework(イベント駆動レート計算フレームワーク)を提示する。この枠組みの上に、公平 QP スケジューラ・ユーザ定義輻輳制御・マルチパスルーティング選択・受信者主導型フロー制御という 4 系統の新規カスタマイズを実装し、いずれもレガシー RDMA トランスポートには存在しない機能であることを実験で示す。 ![[fig08-new-customizations.png]] Host ドメイン(Fair QP Scheduler)、Fabric ドメイン(Congestion Control・Multi-Path Routing)、Peer ドメイン(Receiver-Driven)、Application ドメイン(GPU-Direct RDMA・NVMe-oF RDMA)という 4 系統の新規カスタマイズが、共通の Dequeue Rate 制御点を介して実現される(Figure 8)。 ## 問題設定 RDMA はデータセンターワークロードに高性能ネットワーキングをもたらすが、そのハードウェアオフロードトランスポートは輻輳制御・マルチテナント分離・ルーティングなどのカスタマイズを取り込む際に大きな硬直性を示す。DCQCN のような輻輳制御は ASIC に焼き付けられて以来ほぼ 10 年変わっておらず、後続の輻輳制御の革新を統合できずにいる。 論文は従来のカスタマイズ実現手法を 4 通りに整理し、いずれも不十分だとする。 1. RNIC ベンダーと協業して次世代 ASIC に機能を統合する(Microsoft/Mellanox の DCQCN → ConnectX 統合)——ハードウェア世代サイクル(年単位)に律速される。 2. FPGA/ASIC でベスポークな RNIC をゼロから開発する(AWS SRD・Google 1RMA・Falcon)——多大なコストと専門知識を要し、商用 RNIC ほど成熟しない。 3. ソフトウェアオーバレイでユーザ空間ライブラリを RNIC ドライバの上に被せる(Justitia・Flor・Harmonic など)——verb(メッセージ)粒度(最大 GB)の粗粒度制御にとどまり、トランスポート層のパケット粒度(典型 1024B)には届かず、追加処理オーバーヘッドとレイテンシ・セキュリティ懸念を招く。 4. SoftRoCE のような完全ソフトウェアエミュレーション——ハードウェアアクセラレーションされたデータプレーンという RDMA の核心特性を欠く。 著者らは、輻輳制御・マルチテナント分離・受信者主導型フロー制御・マルチパスルーティングという 4 領域それぞれについて先行研究(DCQCN・HPCC・Timely・Swift・ACC、Harmonic・Husky・Flor・X-RDMA・Justitia、Homa・EQDS・NDP・pHost・RCC、MP-RDMA・AWS SRD・PLB)を概観し、「新しい種類の信号・新しい制御対象ドメイン・新しいフロー制御パラダイム・新しいルーティング制御」への需要(I1〜I4)を導出する。 理想的な制御システムに求められる要件として、古典制御理論の信号駆動フィードバックループに倣い、以下 4 点を挙げる。 - R1: マルチスレッド性能 - R2: RNIC との相互作用(制御インタフェース) - R3: 生 Ethernet 能力 - R4: メモリアクセス遅延 BlueField-3 上の Host CPU・DPU ARM・DPA(Datapath Accelerator)を比較すると(Table 1)、DPA のみが R2(RNIC との細粒度相互作用 API、すなわち Programmable Congestion Control モジュール)を満たし、R1・R3・R4 も部分的に満たす。ホスト CPU と DPU ARM は R2 を欠く。DPA は 256 ハードウェアスレッドを持つが、1 スレッドあたりの計算能力は低く(GEMM ベンチマークで ARM 1 スレッド相当に DPA 16 スレッドを要する)、L1/L2 キャッシュも限られる(§3.3)。したがって DPA は「唯一無二ではないが妥当な候補」であり、wimpy core の制約とキャッシュ局所性の確保という課題への対処が必要になる。 ![[fig01-system-model-dpa-architecture.png]] BF3 SoC は Host CPU・DPU ARM・DPA・RNIC が PCIe スイッチと NIC サブシステムを介して接続されるシステムモデルを取り、DPA は L2 バンク・LLC・メモリアパーチャを介してホスト/DPU/DPA の 3 階層メモリと RNIC の TX/RX パイプラインへアクセスできる(Figure 1)。 ![[fig02-dpa-characterization.png]] DPA のマルチスレッド実行はスレッド数に対しほぼ線形にスケールし、パケット粒度イベント(PCC Events)を受信可能で、1 スレッドあたり約 1.8 Mpps の生 Ethernet 送受信性能を持ち、メモリアクセスレイテンシは L1・L2/L3・ヒープの階層で段階的に増加する(Figure 2)。 ## 提案手法 ### Dequeue Rate Control Model(何を制御するか) RNIC の QP スケジューラは、テナントが SQ に post した WQE をフェッチし、per-QP メタデータ(QPC・WQE)と per-QP レートに基づいて実行順序を決定する。従来はこの per-QP レートを DCQCN のような輻輳制御が単独で割り当ててきた。しかし Table 2 が示す通り、帯域飢餓的な QP と競合した場合、スループット指向テナントは不公平な劣化を、レイテンシ指向テナントは遅延増加を被る——ファブリック全体としては輻輳していない(集約帯域がライン速度に達している)ため DCQCN は反応しない。 ![[fig03-qp-scheduling-model.png]] QP スケジューラは per-QP レート割当を入力として WQE 実行順序を出力する(Figure 3)。従来はこの入力を輻輳制御が単独で決めていたのに対し、SCR は Dequeue Rate Control という新しい入力経路を提案する。 著者らは QP スケジューラの「入力」である Dequeue Rate(RNIC がホストメモリ領域からメッセージをフェッチする速度)を制御ノブとして提案する。Dequeue Rate は以下 4 点で多重的な効果を持つ(§4.2、Figure 4)。 1. 送信速度: デキューされて初めて送出されるため、送信速度を直接規定する。 2. PCIe 利用率: デキュー速度が高いほど DMA 転送による PCIe 利用が増える。 3. RNIC 内部リソース配分: デキュー操作がパケタイズなど後続のハードウェア処理を起動するため、ASIC 内の処理ユニット割当に影響する。 4. 受信者側背圧への応答: 送信者側のデキュー速度を落とすことで受信者側の圧力を緩和できる。 ![[fig04-dequeue-rate-domains.png]] Dequeue Rate はホスト側の PCIe・送信側 RNIC から TOR を経て受信者側 RNIC に至るまで、複数ドメインに影響が及ぶ制御点である(Figure 4)。 ### Event-Driven Rate Computation Framework(どう制御するか) Dequeue Rate をどう計算し適用するかを担うのが、event collectors・event queues・event processor の 3 サブシステムからなるイベント駆動フレームワークである(Figure 5)。 ![[fig05-event-driven-framework.png]] DPA ソフトウェアが Host/Peer ドメインの Event Collector を、ASIC ハードウェアが Fabric ドメインの Event Collector をそれぞれ担い、Event Queues に蓄積された信号は Event Multiplexor(DPA/CPU SW または ASIC HW)を介して Event Processor(スレッドプール)へ渡され、Ctrl 信号として QP Scheduler / RNIC Data Path へフィードバックされる(Figure 5)。 **Event Collectors**: Fabric・Host・Peer の 3 ドメインから信号を収集する(Table 3)。Fabric ドメインは in-band(TX/RX/CNP/ACK/NACK。現行 BF3 は RX 未対応)と out-of-band(DPA 実装の UDP ベースプロービングによる RTT 測定など)の 2 系統。Host ドメインはアプリケーションヒント(共有メモリ経由)、PCIe 利用率(Intel PCM またはホスト-DPA 間 ping-pong によるレイテンシ測定)、RNIC 利用率(クエリ API)。Peer ドメインは受信者クレジット・ピア PCIe/RNIC 利用率を、生 Ethernet 上の軽量 UDP プロトコル(128B ペイロード)で周期的・サンプリング的・異常検知トリガ的に送受信する。 **Event Queues and Multiplexer**: RDMA の WRITE のような verb は 1 つの WQE が最大 GB のメッセージを表す一方、ワイヤ上は MTU(典型 1024B)単位のパケットに分割されるため、per-packet の TX イベントが急速に蓄積する(Figure 6)。既存の ASIC ハードウェアコアレシングは in-band 信号にしか適用できず、Accumulation 戦略のみをサポートするという 2 つの限界を持つ。SCR はこれを DPA ソフトウェアによるコアレシング・マルチプレクシングで補完し、Host/Peer ドメインの信号にも適用可能にし、Keep-Latest-Event・Keep-Oldest-Event など多様な戦略を実装する。BF3 の DPA は実行時にスレッドを生成できず(RTOS の制約)、doca_pcc プロセスのみがレート設定 API を持つという 2 つの制約があり、ホスト CPU/DPU ARM をプロセス起動とメールボックス仲介のエージェントとして用いることでこれを回避する。 ![[fig06-coalescing-mechanism.png]] 1 つの WQE の Message が SQ Depth 分の複数 WQE として Tx Pipe から MTU 単位のパケットへ分割される過程で、Tx Event Queue に蓄積された TX イベントが Multiplexer の Coalescing 機構を経て 1 つの処理イベントへまとめられ、Thread へ渡される(Figure 6)。 **Event Processor**: Run-to-Completion かつ Shared-Nothing の Deterministic Multi-Threading(DMT)モデルを採用し、コンテキストスイッチや inter-thread ロックを排除する。スレッドプールサイズは事前決定され、per-node 処理(Host ドメイン信号など)はフロー数によらず少数スレッド(10 未満)で足り、per-flow 処理は Steering Policy によりスレッド数を超えるフロー数でも複数フローを 1 スレッドへ集約する。 著者らはこの集約が処理忠実度を損なわないことを **Granularity Invariance Principle(粒度不変性原理)** として証明する(§4.3.3、Figure 7)。固定スレッド数 $T$・固定ライン速度の下で、$N$ 本のフローが飽和しているとき、1 イベントあたりの送出バイト数(coalescing granularity)$B_{spe}$ は $LineRate = B_{spe} \times C$($C$ は総イベント処理能力の定数)として決まり、$N$ に依存しない。したがって in-band ファブリック信号の処理には典型 64 スレッド、out-of-band/peer 信号にはより粗粒度なため 16 スレッドで足りるという設計判断を導く。 ![[fig07-granularity-invariance.png]] 固定 2 スレッドのまま QP 数を 1→2→4 と増やしても、コアレシング粒度(1 イベントあたりのバイト数)は不変に保たれる(Figure 7)。 メモリ効率のため、ステートフル操作(メンバーシップ判定・カウント)には BloomFilter・HashMap・HyperLogLog・Count-Min Sketch を、ステートレス操作には固定小数点(FXP-16)演算とビット演算を用いて、DPA の wimpy core 制約下での time-space トレードオフを最適化する。 ## 新規性 1. **RDMA トランスポートの white-boxing という新しい方法論**: スイッチの white-boxing(制御プレーンのソフトウェア化、データプレーンのハードウェア温存による SDN 革新)を RDMA トランスポートへ転用する初の体系的提案。既存のソフトウェアオーバレイ(verb/メッセージ粒度)と異なり、トランスポート層のパケット粒度(典型 1024B)でのソフトウェア制御を実現する。 2. **Dequeue Rate という統一制御ノブ**: 輻輳制御専用だった per-QP レート割当を、ホスト・ファブリック・ピアの複数ドメインにまたがる汎用制御点として再定義した。 3. **Granularity Invariance Principle**: フロー数の増加に対して処理スレッド数をスケールさせなくても処理忠実度が保たれることを理論的に証明し、DPA のような wimpy core 環境でのスケーラブルな設計指針を与えた。 4. **DPA ソフトウェアコアレシング/マルチプレクシング**: ASIC ハードウェアコアレシングが in-band 信号・Accumulation 戦略のみに限定される制約を、DPA ソフトウェア実装で全ドメイン・複数戦略へ拡張した。 5. **ゼロタッチでの GPU-Direct/NVMe-oF 対応**: アプリケーション・ライブラリのコード変更なしに機械学習・ストレージワークロードへ適用可能であることを示した。 ## 実験設定 - テストベッド: 100GbE スイッチで接続した 2 台のサーバ。各サーバは Dual Intel Xeon Gold 6346・384GB DDR4・PCIe Gen4・Nvidia BlueField-3 DPU(100GbE)。各サーバに Nvidia A30 GPU(24GB HBM2、driver-550、CUDA v12.4)を搭載。Ubuntu 22.04・kernel 6.5.0・DOCA SDK v2.6・SPDK v24.05。マルチテナントは SR-IOV VF で構成。 - マイクロベンチマーク: Perftest ib_write_bw でトラフィックを生成し、QP(フロー)数を 1〜1024 まで変化。メッセージサイズ 64KB・キュー深度 4 で 100Gbps ライン速度を飽和。DPA スレッドは最大 64 起動。指標は Event Rate・Coalescing Granularity・Processing Rate。 - QP スケジューラ公平性: Perftest WRITE で 2 テナントを競合させ、メッセージサイズを変えながら Jain's Fairness Index と帯域を測定。既定スケジューラ・Static Allocation・Water Filling の 3 アルゴリズムを比較。READ の実験は付録 A.5。 - 性能分離: 帯域飢餓的テナント(64KB メッセージ・キュー深度 128)とレイテンシ指向テナント(256B メッセージ・キュー深度 4)を競合させ、レイテンシと帯域を測定。 - 付録では Swift(delay-based CC)・MP-RDMA 由来のマルチパスルーティング・Homa 由来の受信者主導型フロー制御・NVMe-oF/GPU-Direct RDMA への適用をそれぞれ個別に評価している。 ## 実験結果 - **DPA のハードウェア特性(Figure 2)**: GEMM ベンチマークでスレッド数に対しほぼ線形にスケールするが、1 ARM スレッド相当の処理には最大 16 DPA スレッドを要する。1 DPA スレッドで約 1.8 Mpps(100B パケット)の生 Ethernet 送受信が可能。DPA が DPA ローカルメモリ・DPU on-SoC メモリ・ホストメモリへアクセスする際のレイテンシは、この順で段階的に増加する(L1 → L2/L3 → 1GB ヒープの階層でジャンプがある)。 ![[fig10-microbenchmark-key-properties.png]] - **処理容量とスケーラビリティ(Figure 10a, 10b)**: 1024 QP まで拡張しても処理速度がライン速度と一致し続け、Granularity Invariance Principle の予測どおり、64 QP を超えてスレッド数を増やさなくてもコアレシング粒度が不変に保たれる。 - **ソフトウェアコアレシングの効果(Figure 10c, 10d)**: ソフトウェアコアレシングは Fabric TX・Peer Credit・Host PCIe レイテンシなど全ドメインに適用可能で、スレッド数が 4 に限られる場合、HW+SW コアレシングは HW-Only コアレシング比で 51.3% 高いイベントレートを達成する。 - **空間効率(Figure 10e)**: 新規フロー検知に用いる BloomFilter は Bitmap よりメモリ使用量が小さく、両者とも同等のイベント処理レートを達成する。 ![[fig09-water-filling-strategies.png]] Water Filling アルゴリズムは、新しいフローが加わるたびに既存フローのデキュー速度を $\frac{n-1}{n}$ 倍へ縮小し新規フローを $\frac{1}{n} \times LineRate$ から開始するなど複数の縮小戦略を持ち、8 本の帯域飢餓的 QP を 50ms 間隔で順次投入する実験で公平性と収束時間の両立を示す(Figure 9)。 ![[fig11-fairness-qp-scheduling.png]] **公平 QP スケジューラ(Figure 11, 12)**: 既定スケジューラはメッセージサイズが等しいテナント間でしか公平にならず(対角線上のみ濃い緑)、小メッセージ(256B)は帯域を飽和できない。Water Filling アルゴリズムは Static Allocation と同等の公平性を保ちながら過剰配分・飢餓を防ぎ、既定スケジューラ比で Jain's Fairness Index を最大 1.78 倍(4KB メッセージ QP vs 1MB メッセージ QP)改善する(Figure 11)。 ![[fig12-fairness-multiple-tenants.png]] QP 数を 4〜1024 まで拡張する実験(Figure 12)では、Static および Water Filling が既定スケジューラ比で Jain's Fairness Index を最大 1.88 倍改善する。100 flow を超えると per-flow 帯域が Mbps オーダーとなり、RNIC のレート制限精度の限界(最小 1 Gbps を設定)から公平性指標が低下する。 ![[fig13-performance-isolation.png]] **テナント分離(Figure 13)**: Water Filling は既定スケジューラ比でレイテンシ指向テナントのレイテンシを最大 52.8% 削減し(5.3us→2.8us)、帯域飢餓的テナントの帯域も既定スケジューラと同水準(82.4 Gbps)を維持する。SCR によるカスタマイズはデータプレーン性能を犠牲にせず、むしろレイテンシ指標を改善する場合があるという観察を全ケーススタディで確認したとしている。 - **付録の追加ケーススタディ**: Swift(delay-based CC)を SCR 上に実装し、ターゲット遅延曲線と背景トラフィックへの収束挙動が原設計と一致することを確認(§A.6)。マルチパス RTT モニタリングで背景トラフィックによる輻輳増加・リンク障害を検知できることを示した(§A.7)。受信者主導型クレジット付与により 16-to-1 incast でも残存帯域を有効利用できること、受信者起動 ECN 様背圧が AIMD 的挙動を再現することを示した(§A.8)。NVMe-oF/GPU-Direct RDMA では、アプリケーション/ライブラリのコード変更なしに複数テナント間の公平な帯域共有を実現した(§A.9)。付録の各図は主張済みの定量結果(§5.2、Table 4)を補強する時系列トレースであり、本文主張自体は上記の主要図に含まれるため、図の埋め込みは割愛する。 ## 考察 - **DOCA PCC との関係**: SCR は QP のレート設定や Fabric ドメイン信号取得に PCC の API を参照する一方、Dequeue Rate Control Model・DPA RTOS の制約に対処するソフトウェアコアレシング/マルチプレクシング・DPA 効率化戦略は SCR 独自の貢献であり、これらは PCC 自体にも還元可能だとしている。 - **他プラットフォームへの一般化**: BF3 DPA 以外にも、Google Falcon の Rate Update Engine(RUE)や Broadcom の Inband Flow Analyzer(IFA)の Initiating Function Node が同様のアーキテクチャ上の位置を占めるとし、Dequeue Rate 制御とコアレシング/マルチプレクシング戦略はこれらにも適応可能だと論じている。 - **リソースコスト**: ホスト側は DPA スレッド起動やプローブ応答などの軽量作業にとどまり、実験ではホスト CPU 1 コアで十分だったとしている。DPA は RISC-V ベースで電力・チップ面積・コストの効率を狙った設計であり、低電力版の BF3(SuperNIC)にも DPA が搭載される。out-of-band プローブと in-band テレメトリの帯域消費は輻輳制御分野で一般的な課題だとしている。 ## 強み / 弱点・課題 - 強み - パケット粒度(トランスポート層)のソフトウェア制御という、既存のverb粒度オーバレイと質的に異なる制御点を提示し、Dequeue Rate という単一の制御ノブで輻輳制御・マルチテナント分離・マルチパス・受信者主導型制御という異種のカスタマイズを統一的に説明する枠組みを与えている。 - Granularity Invariance Principle により、wimpy core(DPA)資源制約下でのスケーラビリティを理論的に裏付けている点は、単なる実装論文を超えた設計原理の提示になっている。 - 商用ハードウェア(BlueField-3)のみで実装しており、FPGA や専用 ASIC を要する先行研究(SRNIC・MP-RDMA の FPGA プロトタイプなど)より配備障壁が低い。 - 弱点・課題(著者らが§6.4 Limitationsで認めている点) - 現行 BF3 は RX イベントの in-band 収集に対応しておらず、Host ドメイン収集で代替している。 - DPA の RTOS は実行時のスレッド生成や汎用 IPC を持たず、ホスト CPU/DPU ARM をエージェントとして介在させる必要があり、設計を複雑化させている。 - RNIC のレート制限は Mbps 粒度での精密な制御が困難であり(Figure 12b で 100 flow を超えると 1 Gbps 未満の設定が必要になり利用率が低下)、この制約は SCR 自体ではなく基盤 RNIC 由来である。 - マルチパスルーティングの経路指定は、現行 RNIC ハードウェアのフローエンジンによるパケットヘッダ書き換えに依存しており、パケット単位の完全な経路制御はできない(§A.7)。 - Water Filling などの制御則は「表現力の実証」を主眼としており、アルゴリズム自体の最適性は将来課題としている(§5.1)。