search

nariaki3551 / library

Stock of papers and articles to read
1 stars 0 forks source link

Scalable Hierarchical Aggregation Protocol (SHArP): A Hardware Architecture for Efficient Data Reduction (2016) #74

Open nariaki3551 opened 10 months ago

nariaki3551 commented 10 months ago

続編

仮想的な集約ノード(Aggregation Node; AN)を作成し、そのノードで集約を行う。

  1. ANは固定されるため、ANにデータを送信する子ノードも事前にわかる。
  2. ANは収集すべきデータを全て子ノードからRC (Reliable Connection)トランスポートから受け取ると簡約を実行し、UD (Unreliable Datagram)ポートから送信する。
  3. この収集および簡約と送信がデータ全体に対して行われるのか、フレームやパケット単位で行われるかは明記されていない。
  4. 簡約操作は他の通信を邪魔しないようにTCA (Target Channel Adapter)なる箇所で行われるらしい。

背景

近年、システムのサイズの拡大と計算ニーズを達成するためのシステム並列性の利用に対する依存度の増加により、シミュレーションの課題を満たすための革新的なシステムアーキテクチャが求められています。この論文では、データセンターネットワークを通過するデータを操作するインテリジェントネットワークデバイスとしての新しいネットワーククラスのコプロセッサへのステップとして、ネットワークへの集約操作処理をオフロードするために設計されたSHArP技術について説明しています。

どんなもの?

SHArP (Scalable Hierarchical Aggregation Protocol) は、データリダクションの効率的なハードウェアアーキテクチャを提供する技術です。これは、MellanoxのSwitchIB-2 ASICで実装され、データをソースグループから減少させ、結果を配布するためのネットワークツリーを使用しています。

先行研究と比べてどこがすごい?

これまでにネットワーク内での集約のサポートが提供されてきましたが、この設計のユニークな点は、大規模な基数のリダクションツリーと同時に重複する実行ジョブをサポートすることに重点を置いていることです。

技術や手法のキモはどこ?

SHArPは、データリダクションのためのプロトコルを定義しています。これは、MellanoxのSwitchIB-2デバイスで実例化され、小さなデータのリデュースとオールリデュース、およびバリアのサポートを提供しています。この技術により、データセンターネットワーク内でデータが転送されている間にデータの操作が可能となります。

どうやって有効だと検証した?

実験的なデータを使用して、このアプローチがシステムのパフォーマンスを向上させる効果を示しています。具体的には、128ホストのシステムでの8バイトのデータリダクションの遅延を2.1倍に減少させることができました。

議論はある?

nariaki3551 commented 10 months ago

この論文を引用している文献

排他的なネットワークアセクスが必要でありpublic cloudなど複数のテナントでネットワークを共有するような状況には不適。publicでないので中身がわからない。

Mellanox proposes an in-network aggregation solution called Sharp (Bloch, 2019) using a custom hardware specialized for collective reduction operations (allreduce) inside the switch. But because there is no publicly available design, it is hard to speculate(推測) how this has been achieved and if/how it can scale to high data rates. Moreover, Sharp is geared towards HPC and requires exclusive(排他的) network access, making it a poor fit for today’s shared ML clusters in cloud data centers.

--> SHARPv3は、ネットワークを介した小規模および大規模なデータ集約に対して、SHARPv2では２つまでの同時論理ツリーが、SHARPv3では64までに拡張されることにより、実質的に無制限の拡張性を実現し、従来世代と比較して32倍高いAIアクセラレーションパワーを実現する。これによりさらに、複数のテナントまたは複数の並列アプリケーションが、パフォーマンスの低下なしにインフラストラクチャを共有できるようにするのだ。MPIタグマッチングハードウェアエンジン、および高度な輻輳制御、適応ルーティング、および自己修復ネットワーキングなどの機能は、HPCおよびAIクラスタに重要な機能強化をもたらし、これまで以上に高いレベルのパフォーマンスを実現している。 (https://www.hpcwire.jp/archives/57681)

なのでSHARPv3では解決していそう

全てのデータが届くまで集約処理が行われない。

In-network Aggregation. The idea of in-network aggregation has been explored in wireless networks [18, 59]; in big-data systems and distributed training systems using endhosts [23], a specialized host [48], high performance middleboxes [49] or overlay networks [17,63]. DAIET [55] proposed a simple proof-of-concept design of in-network aggregation without a testbed prototype. ShArP [#This], supported by special Mellanox Infiniband switches, builds an overlay reduction tree to aggregate data going through it, but it does not apply the aggregation until the switch receives all the data. ATP is the first to provide a dynamic, best-effort in-network aggregation service for multi-tenant multi-switch clusters.

- [55] In-network computation is a dumb idea whose time has come. In Proceedings of the 16th ACM Workshop on Hot Topics in Networks, HotNets-XVI, 2017

集約に使用されるALUは専用(他のことに使えない)

Mellanox’s Scalable Hierarchical Aggregation Protocol (SHARP) is a proprietary(独自の) in-network aggregation scheme available in certain InfiniBand switches [#This]. SHARP uses dedicated on-chip FPUs for collective offloading. The most recent version, SHARPv2 [68] uses streaming aggregation analogous to ours. A key difference is that SHARP builds on InfiniBand where it can leverage link-layer flow control and lossless guarantees, whereas SwitchML runs on standard Ethernet8 with an unmodified network architecture, necessitating a new packet recovery protocol. More fundamentally, SwitchML builds on programmable network hardware rather than SHARP’s fixed-function FPUs, which offers two benefits. First, operators can deploy a single switch model either for SwitchML or traditional networking without waste: the ALUs used for aggregation can be repurposed for other tasks. Second, it allows the system design to evolve to support new ML training approaches. For example, we are currently experimenting with new floating-point representations and protocols for sparse vector aggregations [27]. With a fixed-function approach, these would require new hardware, just as moving from single HPC reductions (SHARPv1) to streaming ML reductions (SHARPv2) required a new ASIC generation.

New hardware chips or architecture for accelerating DNN training: Recently, there are many new chips, like TPU [38] and Habana [6], that are specifically designed for DNN training. In fact, the design of BytePS is not GPU-specific, and should apply to them as long as they are also PCIe devices. Some also propose using InfiniBand switch ASIC [#This] to accelerate all-reduce, or using P4 switches [58, 59] to accelerate PS. E3 [46] leverages SmartNICs to accelerate network applications, and can potentially benefit BytePS by offloading the gradient summation from CPUs to SmartNICs. PHub [48] proposes a rack-scale hardware architecture with customized network configurations, e.g., 10 NICs on one server. BytePS focuses on using generally available CPU and GPU servers in commodity data centers.

- [46] Ming Liu, Simon Peter, Arvind Krishnamurthy, and Phitchaya Mangpo Phothilimthana. E3: EnergyEfficient Microservices on SmartNIC-Accelerated Servers. In ATC 2019.
- [48] Liang Luo, Jacob Nelson, Luis Ceze, Amar Phanishayee, and Arvind Krishnamurthy. Parameter Hub: A Rackscale Parameter Server for Distributed Deep Neural Network Training. In SoCC 2018.

ASICに直接実装された集約処理に制限される

SHArP [This] is designed to offload MPI collective operation processing to the network. Reduction operations are performed on the data as it traverses a reduction tree in the network, reducing the volume of data as it goes up the tree. SHArP only supports a limited set of combiners, since they are directly implemented in the switch ASIC. Unlike NetAgg and SHArP, DAIET does not modify the network architecture and provides more flexibility to support a variety of applications.

汎用ではない(InfiniBandに限定される) 浮動小数点演算に制限があり、新しくFP16などの演算を追加するとコストがかかる（実際にfloating point supportに4年かかったよね)

The second approach is to build a switch ASIC that includes floating point hardware. This is the approach taken by the Mellanox Quantum switch [This, 76]. Dedicating chip resources for this purpose is expensive: we show (Sec. 4.2) that adding dedicated FPU hardware takes more than 5× the die area and power of integer ALUs. As a result, this is not a general-purpose approach; it has only been taken for InfiniBand switches, which have simpler routing designs and buffer requirements than Ethernet switches, and hence have spare die area. It also lacks flexibility: it is tied to specific operations on specific floating-point formats. New ML-specific numeric representations (e.g., FP16 [79, 106], bfloat16 [21, 30, 53], TF32 [86], and MSFP [18]) represent an area of ongoing innovation, and adding support for a new format requires developing and manufacturing a new ASIC – an expensive and time-consuming endeavor. For example, it took four years for Mellanox to release its second version of switches with floating point support [31, 32].

nariaki3551 commented 10 months ago

Introduction

TL; DR

  1. すべてのデータ処理をlocalまたはremoteのCPUで処理するのではなく、データの処理の分散化や、メモリの場所間で移動されるデータの量の削減を可能にする、特殊なシステムが必要ではないか
  2. Co-Designについて; システムのすべてのdeviceとsoftwareが連携して、さまざまなcomputation, networking、およびdata storage infrastructure全体でbalanceの取れたarchitectureを生み出すこと
  3. MellanoxはCo-Designとしてhost channel adapterやswitch上でデータが移動する際に、ネットワークによって実行されるCPUオフロード技術に焦点を当てている
  4. Scalable Hierarchical Aggregation Protocol（SHArP）を提案
    • MellanoxのSwitchIB-2デバイスで実装、小さなデータのreduceやallreduce、およびbarrierのサポートを提供
    • データがネットワーク内の削減ツリーを通過する際に削減操作を実行することで、これらの頻繁に使用されるグローバル操作を最適化する
  5. 大きな基数の削減ツリーと同時にオーバーラップして実行されるジョブのサポートに重点を置いている?
nariaki3551 commented 10 months ago

Previous Work

TL; DR

Details

II. 以前の研究 過去には、ブロッキングおよびノンブロッキングのバリアおよび削減アルゴリズムのパフォーマンスを向上させるための広範な研究が行われてきました。 Venkataらによって行われたアルゴリズムの研究[16]では、再帰的なK-ing型のホストベースのアプローチを使用して、短いベクトルのブロッキングおよびノンブロッキングの削減およびバリア操作が開発され、Thakur[17]による研究が拡張されました。Vadhiarら[18]は、連鎖、バイナリ、二項ツリー、およびRabsnseifnerアルゴリズムを使用して、ブロッキング削減、収集、およびブロードキャスト操作の実装を提示しました。Hoeflerら[19]は、ノンブロッキングのMPI Allreduce()操作のいくつかの実装を研究し、大きなコミュニケータと大きなメッセージを使用するときのパフォーマンスの向上を示しました。 一部の研究は、特定のトポロジーのための集合操作を最適化することを目的としています。代表的な例として、ref. [20]および[21]があり、これらはそれぞれメッシュトポロジーおよびハイパーキューブのための集合体を最適化しました。 他の研究では、パフォーマンスの向上のためのハードウェアサポートが提示されました。従来、ほとんどの実装は、CPUを使用して集合操作をセットアップおよび管理し、ネットワークはデータの導管としてのみ使用されていました。しかし、Quadrics[22]は、ネットワークデバイスのハードウェアでのブロードキャストとバリアのサポートを実装しました。最近のIBMのBlue Gene super computerは、バリアおよび削減操作のためのネットワークレベルのハードウェアサポートを含んでいます。その予備バージョンであるBlue Gene/L [23]は、トーラスインターコネクト[24]を使用し、すべての集合操作のスループットパフォーマンスを最大2倍向上させました[25]、[26]。512ノードのシステム上で、16バイトのMPI Allreduce()の遅延は4.22µ秒でした。後に、次世代のスーパーコンピュータBlue Gene/PのためのメッセージパッシングフレームワークDCMFが導入されました[27]。この世代のBlue GeneのためのMPI集合体最適化アルゴリズムは[28]で分析されました。最新バージョンのBlue Gene/Q [29]は、MPI集合体の追加のパフォーマンス向上を提供します[30]。96,304ノードのシステム上で、短いallreduceの遅延は約6.5µ秒です。IBMのPERCSシステム[31]は、集合削減操作をハードウェアに完全にオフロードします。最後に、MaiらはNetAggプラットフォーム[32]を提示しました。これは、ネットワークリンクの利用を効率的にするために、ネットワーク内のミドルボックスを使用して分割/集約操作を行います。CrayのAriesネットワーク[33]は、HCAで64バイトの削減サポートを実装し、最大32の基数を持つ削減ツリーをサポートしています。約12,000プロセスの8バイトMPI Allreduce()の遅延は、ホストあたり16プロセスで約10µ秒でした。

HCAへの集合操作管理のオフロードのためのいくつかのAPIが提案されています。これには、MellanoxのCORE-Direct [34]、Portal 4.0 triggered operations[35]、および an extension to Portals 4.0[36]が含まれます。これらすべては、集合操作のエンドポイント管理を使用するプロトコルをサポートしていますが、現在のアプローチでは、エンドポイントは集合の開始と完了のみに関与し、スイッチングインフラストラクチャが集合操作の管理をサポートしています。

nariaki3551 commented 10 months ago

AGGREGATION PROTOCOL

新しいネットワークコプロセッサアーキテクチャの目標は、頻繁に使用されるグローバル通信パターンの完了時間を最適化し、そのCPU利用を最小限に抑えることです。最初に対象とされるパターンのセットは、少量のデータのグローバル削減であり、バリア同期や小さなデータ削減を含みます。SHArPは、データ削減を記述する抽象化を提供します。このプロトコルは、集約ツリー内の集約ノード（AN）を定義し、これはネットワーク内の削減操作オフロードの基本的なコンポーネントです。この抽象化では、データはツリーの葉から集約ツリーに入り、ツリーを上っていき、各ANでデータ削減が行われ、グローバル集約はツリーの根に終わります。この結果は、集約パターンとは独立した方法で分散されます。これらの操作の通信処理の多くはネットワークに移動し、ホストに依存しない進行を提供し、システムノイズの悪影響に対するアプリケーションの露出を最小限に抑えます。実装は、データがネットワークを通過する際にデータを操作し、データの移動を最小限に抑えます。この設計は、高次元のInfiniBandスイッチを使用して浅い削減ツリーを使用するネットワークレベルの並列性の高さから利益を得ています。集約プロトコルは、以下のサブセクションで説明されます。データは、その葉で集約ツリーに入り、集約ノードがデータを操作してツリーの根まで上がります。集約グループは、集約データパスを最小限に抑えるために使用されます。

A. 集約ノード

集約ノードは論理的な構造であり、具体的には集約ツリーのノードです。ノードはその子からデータを受け取り、データを削減し、適切であれば結果を親に転送します。ノードがルートとして定義されている場合、ツリーの上に転送する代わりに結果の分配を開始します。プロトコルによってサポートされている操作は、ツリーの個々の子から入ってくるデータと同じボリュームの結果データを保持するものです。これにより、ユーザーデータのサイズがゼロのバリア同期、および合計のような操作を持つベクトル削減がサポートされます。

集約はさまざまな方法で実装できます。クラスタに接続されたサーバーで実行されるプロセスとして、スイッチデバイスで実行されるプロセスとして、またはスイッチハードウェアの一部としてインスタンス化することができます。

B. 集約ツリー

集約ツリーは、エンドノードから入力されるデータの削減パターンを定義し、結果はツリーのルートに終わります。ANは論理的なツリートポロジーで接続されています。

図1は、物理ネットワークトポロジー上のSHArPツリーの割り当ての例を示しています。図1aは物理ネットワークのファットツリートポロジーの例を示し、図1bはこのトポロジー上のSHArPツリーの割り当てです。一般的に、SHArPツリーは論理的なものであるため、任意のトポロジー上に作成できます。与えられたトポロジー上のツリー割り当ての最適化は、この論文の範囲外です。

SHArPエンドノード（図で青い星で示される）はAN（図で赤い星で示される）に接続され、ANとともにSHArPツリーを定義します。図からわかるように、ANは通常スイッチで実装されますが、ホストでも実装できます。さらに、AN間の接続は論理的であり、したがって物理的なトポロジーに従う必要はありません。さらに、エンドノードは必ずしも物理的に最も近いスイッチ、またはSHArPツリー内のANに接続されているわけではありません。ツリーの1つのノードがルートとして定義され、それがツリー内のANの親子階層を定義します。

一般的に、各ANはいくつかのツリーに参加できますが、各削減操作は一度に1つのツリーのみを使用できます。SHArPレベルの上では、単一の削減が複数の小さな削減操作に分割され、同じツリーまたは異なるツリーで実行されます。

プロトコルはデータ転送を定義していないため、InfiniBandやRDMA over Converged Ethernet（RoCE）のようなRDMA対応プロトコルなど、さまざまなトランスポートを使用して通信が行われる可能性があります。また、パケットの損失や並べ替えを処理せず、上位層へのパケットの信頼性のある順序通りの配信を提供する信頼性のあるトランスポートが必要です。

複数のツリーがサポートされており、システム全体の負荷をより適切に分散し、利用可能な集約リソースを活用します。基盤となるネットワークの物理的なトポロジーに関して仮定はされておらず、ツリーはファットツリー、DragonFly+、ハイパーキューブなどの任意の物理ネットワークトポロジーをオーバーレイすることができます。

C. 集約グループ

システムリソースの利用を向上させるメカニズムとして、実装はグループという概念を定義しています。これには、ツリーの葉ノードに接続されているホストのサブセットが含まれます。グループは、コミュニケータを跨ぐホストのサブセットを含むように定義することができます。グループが形成されると、ANはその子供と親（ルートでない場合）の説明を作成し、削減が行われるサブツリーを定義します。指定されたツリーは、単一のジョブおよび異なるユーザーに属する複数のジョブからの複数のグループをサポートします。

パフォーマンスの最適化として、グループが定義され、対応するサブツリーが設定されると、このサブツリーはトリミングされ、ツリーのルートへの残りの部分でその幅が1になるサブツリーのレベルで終了します。これは、すべてのデータがツリーのルートに到達する必要を排除するために行われます。むしろ、そのデータを削減するためにツリー内で必要な最も高いレベルにのみ到達する必要があります。分散グループ作成の詳細なアルゴリズムは、この論文の範囲外です。

例えば、新しいMPIコミュニケータが作成されると、SHArPグループが作成されます。このグループには、このコミュニケータのメンバーであるMPIプロセスのサブセット、ホストごとに1つのMPIプロセス、またはソケットごとに1つのMPIプロセスが含まれます。各グループメンバーは、ホスト内またはソケット内のデータ集約を担当し、この集約されたデータをSHArPプロトコルに渡します。

集約操作でのデッドロックを回避するために、AN内のバッファなどのSHArPリソースのエンドツーエンドの利用可能性を確保する必要があります。これが確保されていない場合、同じANリソースを競合する複数の削減操作の同時かつ非調整の実行により、複数の削減操作が同じANリソースの利用可能性を待機し、どれも完了できなくなる可能性があります。リソース割り当て方法はこの論文では取り上げられていません。結果がそのターゲットに到着すると、実装は削減で使用されたリソースがまだ使用中でないことを確認します。これはフロー制御の目的で使用される場合があります。

D. 集約操作

集約操作は、集約グループの各メンバーの参加で実行されます。このような操作を開始するために、集約グループの各メンバーは集約要求メッセージをその葉の集約ノードに送信します。SHArPの要求メッセージには、集約要求ヘッダーに続いて削減ペイロードが含まれます。図2と図3はSHArPメッセージの形式を示しています。

集約要求ヘッダーには、集約を実行するために必要なすべての情報が含まれています。これには、データの説明、すなわち、データタイプ、データサイズ、そのような要素の数、および実行される集約操作、たとえばminまたはsum操作が含まれます。

集約要求を受信する集約ノードは、すべての子からこれらを収集し、すべての予想される要求が到着すると集約操作を実行します。各ANでの集団操作ごとの内部データ構造は、集団操作の進行状況を追跡するために使用されます。これらは、集団操作に関連する最初のメッセージの到着時に割り当てられ、操作がローカルで完了すると解放されます。集約操作の結果は、新しい集約要求の一部としてANによって親の集約ノードに送信されます。ルート集約ノードは、集約操作の結果を生成する最終集約を実行します。

集約操作が完了すると、ルート集約ノードは指定された宛先に集約結果を転送します。宛先は、MPI Reduce()の場合のように、要求するプロセスの1つ、MPI Allreduce()操作の場合のように、グループのすべてのプロセス、または大量データのMapReduceタイプの操作の場合のように、削減グループのメンバーでない別のプロセスのいずれかになる可能性があります。これらのケースでデータを配布するために集約ツリーを使用することができます。ターゲットは、ユーザー定義のInfiniBandマルチキャストアドレスでもよいです。基本的なトランスポートによってマルチキャストデータ配布がサポートされていることに注意が必要ですが、これは信頼性のない配信メカニズムを提供します。必要な信頼性プロトコルは、このメカニズムの上に提供される必要があります。

E. 障害処理

いくつかのタイプのエラーが発生する可能性があり、これにはトランスポートレベルのエラー、エンドノードのエラー、およびSHArPプロトコルのエラーが含まれます。障害処理メカニズムの主な目的は、データの一部が失われたという前提のもと、そのようなエラーのホストプロセスに通知することです。したがって、集約操作は正常に完了できません。これが発生すると、特定のエラーが処理できる保証がないため、割り当てられたANリソースが解放され、エンドユーザープロセスに通知されます。そのため、アプリケーションはエラーから回復できるか、中止する必要があるかどうかを決定する方法を選択できます。

すべてのタイプのエラーで、可能な場合、Aggregation Manager（AM）として知られる管理エンティティにエラーが通知されます。AMはエンドノードプロセスにエラーを通知しようとし、実行中のジョブに関連するSHArPリソースの割り当てを取り消します。エラーを検出するために、バンド内のSHArP監視機能およびInfiniBandネットワーク監視機能の両方が使用されます。SHArPは、集約操作の期間を制限しないMPIおよびSHMEM通信ライブラリをサポートすることも意図されているため、エラー検出のためにタイムアウトに依存することはできません。ハードウェア機能をサポートするソフトウェアインフラストラクチャの説明は、この論文の範囲を超えています。

SHArPのエラー、たとえばツリー接続の失敗やTarget Channel Adapter（TCA）内のエラーは、SHArPのハードウェア実装によって検出されます。そのようなエラー検出の結果としてAMに通知されます。

トランスポート固有のエラー、たとえばデータ転送エラー、リンクエラー、およびスイッチの障害は、トランスポート層およびその監視インフラストラクチャによって処理されます。トランスポート層がそのようなエラーから回復でき、データ転送が続行される場合、AMにそのようなエラーは通知されません。

エンドノードのエラー、たとえば接続の失敗やプロセスの失敗は、ホストと通信しようとするときに葉のスイッチによって検出され、AMの通知を結果とします。

F. SwitchIB-2に基づく集約サポート

スイッチベースのリダクション操作のサポートの実装は、セクションIIIで説明されているSHArPプロトコルに基づいています。集約ノードのロジックは、スイッチASICに統合されたInfiniBand TCAとして実装されています。集約ツリー内のANとホスト間の通信に使用されるトランスポートは、InfiniBand Reliable Connection（RC）トランスポートです。結果は、ツリーを下って葉ノード、またはホストに分散されるか、またはInfiniBand Multi-castグループのターゲットに分散されます。詳細は以下に示されています。

MellanoxのSwitchIB-2は、InfiniBandネットワーク上でSHArPのサポートを実装しています。SHArP集約ノードは、スイッチASICに統合されており、帯域幅と遅延の面で最高のパフォーマンスを提供する能力が向上しています。図4に示されているように、内部論理ポートがInfiniBand SHArP TCAをスイッチに接続します。このTCAは、集約ロジックによって操作されるデータをターゲットとするメカニズムとして機能し、集約プロトコルによって必要とされる集約の結果としてのソースとして機能するInifinBandトランスポート終了ポイントを提供します。TCAは、集約ツリーを通じてデータの信頼性のある配信を可能にするRCトランスポートと、集約結果のマルチキャスト配布を可能にするUnreliable Datagram（UD）トランスポートの両方をサポートしています。集約が行われているとき、データはRCトランスポートを使用してルートの方向に送信されます。結果は、RCトランスポートを使用してツリーを下ってルートから配布されるか、UDトランスポートを使用してUDマルチキャストグループに配布されることができます。集約ノードの機能の高性能ハードウェア実装がTCAハードウェアに組み込まれています。

集約ノードの実装には、集約ノードでサポートされている集約操作を実行するために使用される高性能算術論理ユニット（ALU）が含まれています。32ビットおよび64ビットの符号付きおよび符号なし整数および浮動小数点データで動作できます。サポートされている操作には、MPI標準とOpenSHMEM仕様をサポートするために必要な、積を除くすべての操作を含む、合計、最小値、最大値、MPIのMinLocおよびMaxLoc、ビット単位のOR、AND、およびXORが含まれます。

浮動小数点の加算および乗算操作はともに可換ですが、結合的ではありません。つまり、(a+b)+cは必ずしもa+(b+c)と等しくありません。浮動小数点オペランドで非可換のリダクション操作を実行する場合、実装は繰り返し可能な操作結果を有効にするために実行の順序を考慮する必要があります。たとえば、1020 - (1020 + ) = 0は(1020 - 1020) -  = -とは同じではありません。したがって、集約ノードに到着する集約要求の順序が非決定的であるため、操作は集約要求が集約ノードに到着する順序で実行できません。リクエストはTCAで収集され、すべてのオペランドが利用可能になった後にのみ、予め定められた固定の順序でリダクションが実行されます。SwitchIB-2は、集約要求の到着順序に関係なく、繰り返し可能な結果を有効にするための予測可能な操作の順序を実装しています。

SwitchIB-2 SHArP実装の重要な設計目標は、この機能が大規模な本番環境で役立つことです。これには、少数の大規模な実行ジョブ、または多数の小規模なジョブが含まれます。このようなジョブは計算ノードを共有しない場合がありますが、同じスイッチの一部をまだ使用することができます。実行中のジョブが他のジョブに与える影響を最小限に抑えることが不可欠です。集約操作の影響を他のデータフローに減少させ、スイッチバッファリソースがリダクションノードに到達するのを待って長時間使用されるのを避けるために、集約サポートはASIC内の別のユニット、TCAで実装されており、専用の仮想レーンは必要ありません。実装は、多くのアプリケーションが同時に実行され、重複するスイッチリソースを使用して同時に実行されることを可能にする、集約ノードごとに最大64ツリー、多数のグループ、および数百の未解決の集約操作のサポートを提供します。ジョブごとに複数のリダクショングループもサポートされており、いくつかの同時リダクション操作を効率的に実行することができます。

ホストからのSHArPツリーへのアクセスは、Aggregation Manager（AM）から割り当てられたリソースのリストを取得する特権を持つSHArPdによって制御されます。SHArPdは、スイッチで実行されるRDMA CMの代わりに、ホストと葉スイッチ間のRC接続の確立に関与し、AMによって提供されるリソース割り当てを強制します。さらに、InfiniBand Partition Keys（pkey）がトラフィックの隔離に使用されます。各ジョブに対して、AMはジョブに割り当てられたスイッチリソースを決定し、この情報をすべての関連するANに渡します。これは、このリソースを追跡し、アプリケーションによって現在使用されているリソースの量を追跡し、割り当てを超えることを許可しないためです。

nariaki3551 commented 10 months ago

Discussion

TL; DR