NVIDIA: Mellanox NICのFirmを追いかけるページ¶
DOCA Documentation v2.9.0_CX8¶
まずNVIDIA DOCA Release Notesを見るとDOCA 2.9.0_CX8 is a dedicated branch supporting ConnectX-8 devices only.という表記があり、このFirmはConnectX-8専用である。つまり、このRelease Notesを読むとCX8の気持ちが分かるかもしれない。
Bug Fixesはない。Known Issuesは2.9.0既存のものであるだろう。この辺りは2.9.0の通常版を見れば分かるだろう。
2.9.0_CX8のNew Featuresを読むにあたり、2.9.0通常版のFeaturesを一瞥する。すると、2.9.0 CX8版と明らかに分量が違う。このことからCX8版はCX8対応固有の変更点であると期待できる。読む。
- Added support for NVIDIA® ConnectX®-8 SuperNIC: はこのReleaseの主たる目的であろう。ここで、従来はBF3の専売であった
SuperNICの名称がCX8に使われていることに注目する。 - ConnectX-8 specific features: 以下は固有の機能の説明。
- Support for multiple host pairs
- DPA programmability: DPAはdata-path acceleratorであり、BF3の場合は特定パケットに対してDPUが有する機能を
BlueField DPU に存在するすべてのアクセラレータ (暗号化/復号化、ハッシュ計算、圧縮/解凍など)で処理することができる。CX8のアクセラレータすべてがBF3 SuperNICと同等であるのかは確認が必要。 - Add hop count to Prog CC RTT event: PCCって書いてほしい。PCCはProgrammable Congestion Control である。輻輳発生時のコントロールをユーザが独自に書くことができる。ワークロードに最適化された輻輳制御が実装できるらしい。ここでの輻輳とはECNのCNP受信時のことであり、輻輳制御におけるnotification point (NP)を自分で実装できる。
- Support SD using 2xGen5 PCIe to reach 800Gb/s line rate: 唯一性の低い略語はやめてほしいが文脈的にSocket Directだろう。違ったらごめんなさい。Socket Directは特にマルチCPU環境において1つのNICで複数のCPUソケットに足を持てるメカニズム。ここで言われている
2xGen5はGen5 2 lanesではなくて、2 x PCIe 5.0 x 16 lanesだろう。PHY 800Gという表記にグラッとくるが、このユースケースにおいては2 x 400Gを2CPU Socketでそれぞれ使うのが想定されているんじゃないだろうか。 - Indicate RX port utilization in RTT response packet 直訳するなら
RTT応答によりポートのRx側のUtilを示す何ですがよく分かりません。だれか教えて。ある機能を示したいのか、汎用的にIBパケットなどにマーカーを打てるのか、単にstatのenhanceなのか分からない。 - Expose power, thermal, and event counters: よく分からないが、
/sys/class/infiniband/mlx5_0/ports/1/hw_counters/系のstatが増えたのかな？ - Supported x86 architecture only: これはArmはサポートしていない、と言いたいのかな？
(以上。特定顧客向けのreleaseかなぁ。という感想。)
ZTR-RTT Congestion Control Algorithm Overview v1.0¶
Zero Touch RoCE(ZTR)に関連した機能。
まず、Overviewを読もう。ZTRはRoCEv2対応のスイッチでなくても数千台規模のクラスタでRoCEと同等の性能を出すための技術。ZTRのキーの1つはZTRラウンドトリップ制御(ZTR-RTT CC)アルゴリズム。これを話す。
ZTR-RTT CCはネットワークRTTをエンド-エンドでアクティブに監視して、ドロップ前の輻輳に対して能動的に対応する。この実装のポイントは以下である。
- HWすなわちDPA上の実装(BFやCX8など、と読んでいる)
- RTTベースのCC制御
- “Current default CC algorithm for RoCE “..とあるが、これが輻輳制御する量・戻す量がDefaultと同じ、なのかは不明。
- HPC/AIではDCQCN
よりもよい性能 - StorageではDCDQN
と同じ性能
次にCCを読もう。まずは、文章があまりにも足りないので想像で補う。
LineBlockingの図はOa側がS2で多量の入力を受けており、その結果S1-S2間のinポート(queue)が溢れている部分を埋めてしまい、V-Ov間の通信を圧迫してしまうことを示している（はず）。
Datacenter Congestion Control Challengesでは(行間を読むと)現在のDCQCNの課題が書かれている。
- 100G/400G NWで生じるusオーダの遅延。ただし、瞬時の発生ですぐに収まる。
- 複雑化するトラフィックパターン。また、トポロジやアプリケーション。すべてに対応することは困難。CC側も新しい輻輳通知で工夫はしている。
- HW側の実装がRobustでない。(この意図するところは不明)。
- SW側の反応(react)は遅すぎる。
そこで、ZTR-RTT CCは以下のようなことを提供する。
- CCアルゴリズムの実装のためのプラットフォーム。おそらく、
Prog CC RTTのことだろう。 - DPA上のプロセッサで(CCの)コードが実装されること。ホストまで上がらない。
- CNPとRTTの計測が含まれる。おそらくはタイムスタンプが入っているということか？
- HWによりRate制御とデータ収集を行う。ソフトウェアでないということだろう。
- 宛先ごとにステートフル。E-Eで制御を行うということだろう。
- CCにかかる時間は1us-1.5usオーダ。
次のRTT要求のシーケンスは目を滑らしそうになるが、CCアルゴリズムが要求つまり、ユーザアプリケーションがRTT要求をできることに注意。この後のフローは一般的か。A-ZのRTT測定を考えると、1.データが揃ったらA側のTx Queueに入れるときにRTTを打刻する。2.Z側に到着したらRx Queueに入った時に打刻する。 3.さらにZ側からのの返信時刻も打刻して返信する。 これにより、RTTと書かれているがA->ZとZ->Aの転送時間をしることができる。
一番大切なこの検知アルゴリズムを見ていく。A(RP)-Z(NP)において、輻輳の発生はRTTとCNPだ。レート調整は俗に言うAIMD(additive-increase and multiplicative-decrease, CCでよく使うので参照せよ)。RTTが変更されたときに擬似的なウィンドウサイズを調整(mimic)して制御を行う。