JP4416658B2 - クラスタ型マルチプロセッサシステムの異なるノード上で実行中のプロセス間でのメッセージの明示的な通信のためのシステムおよび方法 - Google Patents

Description

関連特許出願との相互参照
この発明は、この発明の譲受人であるコロラド（Colorado）州コロラドスプリングス（Colorado Springs）のエス・アール・シィ・コンピューターズ・インコーポレイテッド（SRC Computers, Inc.）に付与された、２００１年８月１７日出願の米国特許出願連続番号第０９／９３２，３３０号「デュアルインラインメモリモジュールフォーマットにおいて一連のマルチアダプティブプロセッサを採用したクラスタ型コンピュータ用スイッチ／ネットワークアダプタポート」（"Switch/Network Adapter Port for Clustered Computers Employing a Chain of Multi-Adaptive Processors in a Dual In-Line Memory Module Format"）に開示された主題に関連し、その開示はここに、その全体がこの引用により特に援用される。

著作権通知／許可
この特許文書の開示の一部には、著作権保護の対象となる資料が含まれる。著作権所有者は、誰でもこの特許開示の特許文書を米国特許商標庁の特許ファイルまたは記録のとおりに複製できるということに対して何ら異存がないが、その他の場合については、すべての著作権を何であれ保有する。以下の通知はソフトウェアおよびデータに当てはまり、適用可能な場合には図面も含めて、以下に説明される：（著作権）２００２ エス・アール・シィ・コンピューターズ・インコーポレイテッド。

発明の背景
発明の分野
この発明は一般に、コンピュータおよびコンピューティングシステムの分野に関する。より特定的には、この発明は、コンピュータシステムクラスタの異なるノード上で実行中のプロセス間でメッセージを通信するために、合理化された、低レベルでユーザモードのデータ伝送メカニズムを実現するためのシステムおよび方法に関する。ここに開示される代表的な一実施例では、これらのプロセスは、スイッチ／ネットワークアダプタポート（ＳＮＡＰ^TM、エス・アール・シィ・コンピューターズ・インコーポレイテッドの登録商標）とともに実現されてもよく、ＳＮＡＰ明示的通信機能（ＳＮＡＰＣＦ^TM、これもエス・アール・シィ・コンピューターズ・インコーポレイテッドの登録商標）と命名される。

関連背景
場合によっては、多数のノードに及ぶアプリケーションがグローバルな通信に参加できるよう、クラスタ型コンピュータシステムをノードから構築し、各ノードはローカルに共有されるメモリアドレス空間を有するいくつかのプロセッサを含むことが望ましい。性能上の理由のため、オペレーティングシステムが転送ごとに関与することなくこの通信が実行されること、エンドツーエンドメッセージ待ち時間が最小限に抑えられること、およびこのメカニズムが利用可能なリンク帯域幅を効率よく使用することが重要である。全体的な使用可能性については、オペレーティングシステムが保護されたメモリアクセスを保持できるようにする態様で、各通信のソース（または「送信」）側がターゲットメモリを宛先に正確にアドレス指定（つまり「名前付け」）できるようにする手段を、このメカニズムが提供することが必要である。

通常、クラスタ型システムでの通信は、ネットワークインターフェイスまたは入力／出力（“Ｉ／Ｏ”）デバイスを介して起こる。これは伝統的に、メッセージを送信するため
にオペレーティングシステムの介入を必要としてきた。より最近では、ネットワークインターフェイスカードの中には、ミリネット（Myrinet）ＧＭ（ワークステーション、ＰＣ、サーバ、または単一ボートのコンピュータのクラスタを相互接続するために幅広く使用されている、高性能のパケット通信および交換技術）、仮想インターフェイスアーキテクチャ（“ＶＩＡ”）、およびスケジュールド・トランスポート（“ＳＴ”）といったオペレーティングシステム（“ＯＳ”）バイパスインターフェイスを用いて、ユーザレベルの通信をサポートするよう設計されつつあるものもある。これらのＯＳバイパス対応インターフェイスは例外なく、ソースネットワークインターフェイスカード（“ＮＩＣ”）と宛先ネットワークインターフェイスカードとの間のパケットベースの通信を中間ストレージなしで可能にするよう設計されてきた。そのため、「送信」側および「受信」側双方におけるバッファスストレージは限られており、どの接続に関連するデータもいつでも受信されるということを可能にするよう、動的に管理されなければならない。

非同期通信サポートに対する要件が存在すること（つまり、システムプロセッサはメッセージデータの伝送に積極的にかかわるべきではないこと）も、一般に仮定されてきた。その結果、既存のＯＳバイパス実現化例はすべて、アドレスマッピング／変換を管理するための複雑で時間がかかるスキーム、および直接メモリアクセス（“ＤＭＡ”）伝送を採用している。

発明の概要
これに対し、ここに開示された、クラスタ型マルチプロセッサシステムの異なるノード上で実行中のプロセス間でのメッセージの明示的な通信のためのシステムおよび方法は、メモリが比較的低価格で、豊富にあり、所与の接続の両側に直接アクセス可能である環境向けに最適化されている。この発明によれば、大きく、静的に割当てられた、接続ごとのメモリバッファの採用によって、新しいタイプの通信プロトコルの作成が可能となり、このプロトコルでは、情報はポイントツーポイントで送信されてもよく、データは、受信側のＳＮＡＰがそれを受入れる準備ができるまで中間場所にストアされる。

この発明のシステムおよび方法は、非同期（つまり並行）通信を用いないかもしれない主として単一のアプリケーション環境において有利に作用する。これは、仮想−物理アドレスマッピング（およびアクティブなＤＭＡ伝送）の提供に関連するシステムハードウェアおよびソフトウェアの実質的な簡略化を可能にし、また、ＳＮＡＰを一度に１つのプロセスまたはユーザに割当てることも可能にする。サービスを受ける接続を現在制御中のプロセスまたはユーザに関連するものに制限することによって保護が与えられてもよく、制御中のプロセスまたはユーザの仮想アドレス（“ＶＡ”）空間でシステムプロセッサが動作することによって伝送が達成されてもよい。

この発明はまた、固定された、単方向の、および／またはポイントツーポイントの接続であってもよい１つ以上の接続を通して達成されてもよいメッセージ伝送も含む。これらの接続の終点は「接続記述子」によって識別されてもよい。各接続記述子はインデックスを、ＳＮＡＰ（ＮＩＣと比較）常駐接続状態テーブル（発信ローカル接続テーブル“ＯＬＣＴ”および着信ローカル接続テーブル“ＩＬＣＴ”）に提供してもよい。

この発明はさらに、接続に結合されてもよい、比較的大きく、静的に割当てられた、接続ごとのメモリバッファを含む。接続ごとのメモリバッファは、送信ＳＮＡＰによって直接書込可能であってもよく、受信側ＳＮＡＰによって直接読出可能であってもよい。この接続ごとのバッファは、接続の送信側および受信側が互いから実質的に切り離されることを可能にする。このため、ソースプロセッサノードからのプロセスデータは、受信側がデ
ータを受信できることを既に確立しておかなくても、送信側から接続ごとのバッファに書込まれてもよい。逆に、受信側の論理は、接続および／またはＳＮＡＰを現在制御しているプロセスの識別情報と各着信接続用に接続ごとのバッファの待ち行列に入れられるデータの量との組合せに基づいて、現在アクティブな接続を自由に選択する。後者の情報は、送信側および受信側のＳＮＡＰ間で直接交換されてもよい制御パケット（インターネット・ポリシー・インスティテュート（“ＩＰＩ”）パケット）によって提供されてもよく、着信接続状態（つまりＩＬＣＴエントリ）を更新するために使用可能である。

この発明は、ソース側システムメモリと送信側ＳＮＡＰとの間、および受信側ＳＮＡＰと宛先側システムメモリとの間のデータのステージングも含んでいてもよく、ユーザモードで仮想アドレスベースのプロセッサのロード／ストアを、ＳＮＡＰ上のメモリマッピングされたウインドウ、プロセッサ、ターゲットメモリ間に有する。これは、接続およびその成分ＳＮＡＰを、データ伝送（ＤＭＡ）およびアドレス変換を行なう必要性から解放する。加えて、保護は、ＯＳにより特権を与えられた動作の接続セットアップを行なうことによって、接続または個々のＳＮＡＰの制御を一度に１つのプロセスに制限することによって、また、制御中のプロセスにアクセス可能な接続を現在のスレッドに関連するものに制限することによって、保証されてもよい。

この発明のこれらの、および他の特徴と利点、ならびにこの発明のさまざまな実施例の構造および動作を、添付図面を参照して以下に詳細に説明する。

好ましい実施例の詳細な説明
この発明にはさまざまな修正および代替的な形態の余地があるが、その特定の実施例が図面に例として示されており、ここに詳細に説明される。しかしながら、図面およびその詳細な説明はこの発明を開示された特定の形態に限定するよう意図してはおらず、逆に、この発明は、添付された特許請求の範囲により定義されるようなこの発明の精神および範囲内に該当するすべての修正、均等物および代替物を網羅するものである、ということが理解されるべきである。

ここで図１を参照すると、米国特許出願連続番号第０９／９３２，３３０号に開示されているような、ＤＩＭＭフォーマットの一連のマルチアダプティブプロセッサを採用するクラスタ型コンピュータ用スイッチ／ネットワークアダプタポート（“ＳＮＡＰ”）を含むコンピュータシステム１００の例示的な実施例の機能ブロック図が示されており、それは、データ転送速度を、その他の場合に周辺機器相互接続（“ＰＣＩ”）バスから利用可能なデータ転送速度を越えて著しく向上させるために使用されてもよい。

図示された特定の実施例では、コンピュータシステム１００は、関連するメモリおよびＩ／Ｏコントローラ１０４に結合された１つ以上のプロセッサ１０２₀および１０２₁を含む。動作時、コントローラ１０４は、ＰＣＩ制御ブロック１０６から制御情報を送受信する。なお、この発明の代替的な実現化例では、制御ブロック１０６は特に、拡張周辺機器インターフェイス（ＰＣＩ−Ｘ）、インフィニバンド（Infiniband）、アクセラレイティッド・グラフィックス・ポート（“ＡＧＰ”）、またはシステムメンテナンス（“ＳＭ”）制御ブロックであってもよい。ＰＣＩ制御ブロック１０６は、実質的に２５６ＭＢ／秒の速度でのデータ転送を可能にする、帯域幅が比較的低いＰＣＩバス１１０によって、１つ以上のＰＣＩカードスロット１０８に結合される。上述のこの発明の代替的な実施例では、カードスロット１０８は、それに代えて、ＡＧＰバス接続またはＳＭバス接続を含んでいてもよい。

コントローラ１０４はまた、実質的に２．１ＧＢ／秒またはそれよりも高速のデータ転
送速度が可能な、帯域幅がはるかにより高いＤＩＭＭバス１１６によって、多数のＤＩＭＭスロット１１４に従来通りに結合される。この発明のある特定の実現化例によれば、ＤＩＭＭ ＭＡＰエレメント１１２は、ＤＩＭＭスロット１１４のうちの１つに関連しているか、またはその中に物理的に配置されている。ＤＩＭＭ ＭＡＰエレメント１１２とやり取りする制御情報は、ＰＣＩバス１１０とＤＩＭＭ ＭＡＰエレメント１１２とを相互接続する接続１１８によって提供される。ＤＩＭＭ ＭＡＰエレメント１１２は次に、ＭＡＰチェーンポートに接続されたクラスタ相互接続ファブリック接続１２０によって、別のクラスタ型コンピュータＭＡＰエレメントに結合されてもよい。ＤＩＭＭ ＭＡＰエレメント１１２はまた、ラムバス（Rambus）ＤＩＭＭ（ＲＩＭＭ）ＭＡＰエレメントも含んでいてもよい。

ＤＩＭＭスロット１１４内に配置されたＤＩＭＭメモリはＰＣマイクロプロセッサ１０２₀、１０２₁用の主メモリ記憶場所を含むため、それは、プロセッサバスに電気的に非常に「近接」して、それにより非常に少ない待ち時間を提示するよう設計されている。前述のように、ＤＩＭＭに関連する待ち時間がＰＣＩバス１１０の待ち時間のたった約５％であることは珍しいことではない。本質的に、この帯域幅をコンピュータシステム１００同士間の相互接続として利用することによって、非常に向上したクラスタ性能が実現され得る。

このため、ＤＩＭＭ ＭＡＰエレメント１１２などのプロセッサエレメントをＤＩＭＭスロット１１４のうちの１つに配置することにより、関連するユーザアレイは、通常のメモリ「読出」および「書込」トランザクションを受入れて、それらを相互接続スイッチまたはネットワークによって使用されるフォーマットに変換することができる。前述の特許および特許出願において開示されているように、プロセッサエレメントがＤＩＭＭ ＭＡＰエレメント１１２であってもよいこの発明の一実施例では、ＤＩＭＭ ＭＡＰエレメント１１２は、それが他のボード上のプロセッサエレメントに結合されるようにする、チェーンポートなどの１つ以上のポートを含んでいてもよい。

たとえば一実施例では、２つ以上のボードは各々、ＤＩＭＭ ＭＡＰエレメント１１２などのプロセッサエレメントに結合されたＤＩＭＭスロットを有する。プロセッサエレメントは、ボードの各々の上に配置された少なくとも１つのマイクロプロセッサにも結合されてもよい。各プロセッサエレメントは、データを他のボード上のプロセッサエレメントに、または同じボード上のプロセッサエレメント同士の間で渡すためのクラスタ相互接続ファブリックに結合されたチェーンポートを含んでいてもよい。データはデータパケットとして、クラスタ相互接続ファブリックを介して、プロセッサエレメント同士の間で転送されてもよい。たとえば、チェーンポートを用いて、接続１２０を通して外部クラスタリングファブリックに接続し、データパケットを遠隔ノードに転送してもよく、そこでデータパケットは別のボードによって受信されてもよい。受信ボード上のプロセッサエレメントは、データパケットからデータを抽出して、それをマイクロプロセッサが必要とするまでストアしていてもよい。

この手法は、ＰＣＩバス１１０などの現在利用可能などのＰＣインターフェイスのデータ転送速度よりも数倍速いデータ転送速度の提供をもたらす。しかしながら、ＤＩＭＭの電気プロトコルは、一旦データが受信側に到着すると、ＤＩＭＭスロット１１４内のＤＩＭＭモジュールがマイクロプロセッサ１０２にそれが到着したことを合図する方法はないようになっている場合があり、この機能がなければ、マイクロプロセッサ１０２の作業は、データが到着したかどうかを判断するために、ＤＩＭＭ ＭＡＰエレメント１１２の連続ポーリングの使用を介して同期をとられなければならなくなる。そのような手法は、マイクロプロセッサ１０２、およびそのバス帯域幅の多くを完全に消費し、このため他のバスエージェントをすべて機能停止させる。

この状態を回避するために、データが到着したことをマイクロプロセッサに合図する通信パケットを転送するバスに、プロセッサエレメントが結合されてもよい。たとえば、この発明の一実施例では、ＤＩＭＭ ＭＡＰエレメント１１２は、ＰＣＩバス１１０などの周辺バスに、接続１１８を介して結合されてもよい。この実施例では、ＤＩＭＭ ＭＡＰエレメント１１２は、通信パケットを生成して、それらをＰＣＩバス１１０を介してマイクロプロセッサ１０２に送信してもよい。データがＤＩＭＭ ＭＡＰエレメント１１２によって受信されたことをマイクロプロセッサ１０２に連絡するために、従来のＰＣＩ割込信号が利用されてもよい。ＰＣＩバス１１０上で転送されるこれらの通信パケットはデータ全体のうち低いパーセンテージであるため、ＰＣＩバス１１０の低帯域幅ボトルネック効果は最小限に抑えられ得る。

この発明の別の実施例では、システムメンテナンス（“ＳＭ”）バス（図示せず）も、プロセッサ１０２に合図するために使用可能である。ＳＭバスは、プロセッサボード上のさまざまなデバイスがプロセッサ１０２に従来通り割込めるようにするシリアルカレントモードバスである。代替的な一実施例では、ＡＧＰポートも、プロセッサ１０２に合図するために利用されてもよい。

ＤＩＭＭ ＭＡＰエレメント１１２がＤＩＭＭスロット１１４全体であり得るものと関連している状態で、ＰＣは、通常約１ＧＢのアドレスの大きなブロックを、ＤＩＭＭ ＭＡＰエレメント１１２による使用のために割当てる。これらのうちのいくつかはコマンドとしてデコード可能である一方、（前述の特許および特許出願において開示されているように）多くが依然としてストレージとして使用可能である。少なくとも、周辺機器からデータを転送するために使用される通常の入力／出力（“Ｉ／Ｏ”）ブロックサイズと同じだけ多くのアドレス位置を有することにより、たいていのＰＣ（コントローラ１０４を含む）で使用される従来のインテル^TMチップセットは、ＤＩＭＭ ＭＡＰエレメント１１２への直接Ｉ／Ｏ転送を可能にする。これにより、データは次に、たとえばディスクから到着して、ＤＩＭＭ ＭＡＰエレメント１１２に直接渡るようになる。それは次に、所望の任意のやり方で変えられ、パケット化され、接続１２０を通して遠隔ノードに送信されてもよい。ディスクのＰＣＩバス１１０と、ＤＩＭＭ ＭＡＰエレメント１１２およびＤＩＭＭスロット１１４との双方がＰＣメモリコントローラ１０４によって制御されるため、この転送によって消費されるプロセッサバス帯域幅はない。

なお、ＰＣによっては、ＤＩＭＭスロット１１４内のいくつかのＤＩＭＭが、メモリ帯域幅を増加させるためにより幅広いメモリアクセス能力を提供するよう交互配置されていてもよい。これらのシステムでは、前述の手法も、いくつかのＤＩＭＭスロット１１４において並行して利用されてもよい。にもかかわらず、選択された特定の実現化例の如何にかかわらず、最終結果は、ＤＩＭＭベースのＭＡＰエレメント１１２がＰＣＩバス１１０への、および接続１２０を通した外部スイッチまたはネットワークへの１つ以上の接続を有することであり、それはしばしば、ＰＣＩベースの接続のみの実行、および、データが相互接続ファブリックを通過する際にデータを処理する能力をもたらす。

ここで図２Ａおよび図２Ｂを加えて参照すると、この発明に従ったＳＮＡＰ明示的通信サポート機能（“ＳＮＡＰＣＦ”）によって例示されているような接続２００の送信側２０２および対応する受信側２０４の概要を提供する、簡略化された機能ブロック図が示されている。この例では、送信側２０２および受信側２０４は双方ともＳＮＡＰとして例示されている。以下により十分に説明されるように、特定の例示的なＳＮＡＰデータ構造／プロセスが、プロセス間でメッセージを通信してエス・アール・シィ・コンピューターズ・インコーポレイテッドのスイッチ／共通メモリ（“ＣＭ”）／ＳＮＡＰアーキテクチャを介して接続されたクラスタの異なるノード上で実行するための合理化された低レベルの
ユーザ−ユーザ伝送メカニズムの実現のために開示されている。開示されたこのメカニズムは、特にミリネット／ＧＭ、Ｏｓネット（OsNet）、ＶＩＡ、およびＳＴといった市販のＯＳバイパスクラスタ実現化例によって採用されているものよりもかなり簡単である。

この簡略化は、エス・アール・シィ・コンピューターズ・インコーポレイテッドのプラットフォームと既存のＩ／Ｏベースのクラスタとの少なくとも２つの著しい違いによって可能となる。事前準備として、ここに開示されるこの発明のメカニズムは、任意の所与の転送の送信側および受信側は接続ごとのメモリバッファを介して部分的に、または完全に切り離されることが可能で、そのバッファはその特定のポイントツーポイント接続専用のものである、という仮定の下に作用してもよい。これにより、送信側が受信側ＳＮＡＰからの認証を必要とせずに大量をバッファに入れることが可能になり得るだけでなく、受信側ＳＮＡＰが任意の所与の時点でどの接続にサービスを提供したいかを決めることができるようにもし得る。受信側の論理は一度に１つの接続用のデータのみを取扱えばよいため、これはＳＮＡＰ処理要件を非常に簡略化できる。

ＳＮＡＰは、そのＤＩＭＭスロットインターフェイスのおかげで、ＰＣボードプロセッサの観点からは完全に受動的なデバイスであってもよい。これには、その他の場合には非同期通信を利用できるかもしれないアプリケーションにとっては不利な点があり得るものの、それは、適切な接続ベースの保護メカニズムと、ＳＮＡＰの非特権的制御を所与のユーザプロセスに割当てる能力とを与えられて、通信ハードウェアを、着信データ上で仮想アドレス変換を実行する必要性から解放するかもしれない。

代表的なプロトコルはプロセッサとＳＮＡＰとの間の公知の送信エラーに対処するための措置を含んでいてもよいが、それは、そのようなエラーを検出するためのメカニズムを含んでいないかもしれない。エラー検出用のメカニズムはプロトコルの外部で独立して実現されてもよく、先入れ先出しレジスタ（“ＦＩＦＯ”）に書込まれたデータを転送するかどうかの決定は、より低いレベルで判断され得るステータスのみに基づいて下されてもよい。

ここで図２Ａの接続２００の送信側２０２を特に参照する。この例では、接続２００は、関連部分に、発信直接メモリアクセス（“ＯＤＭＡ”）制御ページ２０６を含んでいてもよい。ＯＤＭＡ制御ページ２０６は、フロー制御送信／受信（“ＦＬＯＷＣＴＬ＿ＳＲ”）用、フロー制御受信／送信（“ＦＬＯＷＣＴＬ＿ＲＳ”）用、転送初期化（“ＸＦＥＲ＿ＩＮＩＴ”）用、および接続テーブルインデックスセットアップ（“ＣＩＤ＿ＳＥＴＵＰ”）用のレジスタを含んでいてもよい。ＦＬＯＷＣＴＬ＿ＳＲレジスタは、接続テーブルインデックス（“ＣＩＤ”）、転送書込ポインタ（“ＸＦＥＲ＿ＷＰ”）およびステータス（“ＳＴＡＴＵＳ”）というエントリを含んでいてもよく、一方、ＦＬＯＷＣＴＬ＿ＲＳレジスタは、関連するＣＩＤ、転送コミット（“ＸＦＥＲ＿ＣＯＭＭＩＴ”）、転送受入（“ＸＦＥＲ＿ＡＣＣＥＰＴ”）およびＳＴＡＴＵＳというエントリを含んでいてもよい。ＸＦＥＲ＿ＩＮＩＴレジスタは、ＣＩＤ、長さ（“ＬＥＮＧＴＨ”）、仮想アドレス（“ＶＡ”）およびＳＴＡＴＵＳというエントリを含み、一方、ＣＩＤ＿ＳＥＴＵＰレジスタは、アプリケーション識別子（“ＡＰＰＩＤ”）、ターゲットノード（“ＴＡＲＧＥＴ＿ＮＯＤＥ”）、ターゲットＣＩＤ（“ＴＡＲＧＥＴ＿ＣＩＤ”）、共通メモリベース（“ＣＭ＿ＢＡＳＥ”）、共通メモリ長さ（“ＣＭ＿ＬＥＮ”）およびローカルＣＩＤ（“ＬＯＣＡＬ＿ＣＩＤ”）というエントリを含んでいる。ＯＤＭＡ制御ページ２０６におけるこれらのエントリは、一度に１つのブロックがアクティブとなる状態で重ね合わされてもよい。

接続２００の送信側２０２はさらに、発信ローカル接続テーブル（“ＯＬＣＴ”）最大ＣＩＤ（“ＯＬＣＴ［ＭＡＸ＿ＣＩＤＳ］”）テーブル２０８とＯＬＣＴ［ＣＩＤ］テー
ブル２１０とを含んでいてもよく、それらは以下により十分に説明される。ＯＬＣＴ［ＣＩＤ］テーブル２１０は、ＡＰＰＩＤ、ＴＡＲＧＥＴ＿ＮＯＤＥ、ＴＡＲＧＥＴ＿ＣＩＤ、ＣＭ＿ＢＡＳＥ、ＣＭ＿ＬＥＮ、転送長さ（“ＸＦＥＲ＿ＬＥＮ”）、バッファカウント（“ＢＵＦＣＮＴ”）および書込ポインタ（“ＷＰ”）エントリ用のエントリを含む。現在の転送状態（“ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ”）テーブル２１２は、図示されているように、ＡＰＰＩＤ、ＴＡＲＧＥＴ＿ＮＯＤＥ、ＴＡＲＧＥＴ＿ＣＩＤ、ＣＭ＿ＢＡＳＥ、ＣＭ＿ＬＥＮ、ＸＦＥＲ＿ＬＥＮ、ＢＵＦＣＮＴ、転送受入（“ＸＦＥＲ＿ＡＣＣＥＰＴＥＤ”）、転送完了（“ＸＦＥＲ＿ＣＯＭＰＬＥＴＥＤ”）および次のＩＰＩ（“ＮＥＸＴ＿ＩＰＩ”）というフィールド用のエントリを含んでいてもよい。以下に同様により十分に説明されるように、ＯＤＭＡ先入れ先出し（“ＦＩＦＯ”）バッファ２１４が、ＯＤＭＡ制御ブロック２１６およびＯＤＭＡエンジン２１８とともに含まれていてもよい。出力アドレスバッファ２２０および出力データバッファ２２２も含まれていてもよい。

加えてここで図２Ｂを特に参照すると、接続２００の受信側２０４は、関連部分に、着信直接メモリアクセス（“ＩＤＭＡ”）制御ページ２３０を含んでいてもよい。ＩＤＭＡ制御ページ２３０は、着信ＣＩＤセットアップ（“ＩＣＩＤ＿ＳＥＴＵＰ”）用、ＦＬＯＷＣＴＬ＿ＳＲ用、ＦＬＯＷＣＴＬ＿ＲＳ用およびＸＦＥＲ＿ＩＮＩＴ用のレジスタを含んでいてもよい。ＩＣＩＤ＿ＳＥＴＵＰレジスタは、ＡＰＰＩＤ、ＴＡＲＧＥＴ＿ＮＯＤＥ、ＴＡＲＧＥＴ＿ＣＩＤ、ＣＭ＿ＢＡＳＥ、ＣＭ＿ＬＥＮおよびＬＯＣＡＬ＿ＣＩＤエントリ用のエントリを含んでいてもよい。ＦＬＯＷＣＴＬ＿ＳＲレジスタは、ＣＩＤ、ＸＦＥＲ＿ＷＰおよびＳＴＡＴＵＳというエントリを含んでいてもよく、一方、ＦＬＯＷＣＴＬ＿ＲＳレジスタは、関連するＣＩＤ、ＸＦＥＲ＿ＣＯＭＭＩＴ、ＸＦＥＲ＿ＡＣＣＥＰＴおよびＳＴＡＴＵＳというエントリを含んでいてもよい。ＸＦＥＲ＿ＩＮＩＴレジスタは、ＣＩＤ、ローカルＣＩＤ（“ＬＯＣＡＬ＿ＣＩＤ”）、ＬＥＮＧＴＨ、長さ単位（“ＬＥＮ＿ＵＮＩＴＳ”）、ＳＴＡＴＵＳおよびＶＡというエントリを含んでいてもよい。

接続２００の受信側２０４はさらに、着信ローカル接続テーブル（“ＩＬＣＴ”）最大ＣＩＤ（“ＩＬＣＴ［ＭＡＸ＿ＣＩＤＳ］”）テーブル２３２とＩＬＣＴ［ＣＩＤ］テーブル２３２とを含んでいてもよく、それらは以下により十分に説明される。ＩＬＣＴ［ＣＩＤ］テーブル２３４は、ＡＰＰＩＤ、ソースノード（“ＳＲＣ＿ＮＯＤＥ”）、ＣＭ＿ＢＡＳＥ、ＣＭ＿ＬＥＮ、ＸＦＥＲ＿ＬＥＮ、ＢＵＦＣＮＴ、ＷＰ、読出ポインタコミット（“ＲＰ＿ＣＯＭＭＩＴ”）および読出ポインタ（“ＲＰ”）エントリ用のエントリを含んでいてもよい。現在の着信転送状態（“ＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥ”）テーブル２３６は、図示されているように、ＡＰＰＩＤ、ＳＲＣ＿ＮＯＤＥ、ＳＲＣ＿ＣＩＤ、ＣＭ＿ＢＡＳＥ、ＣＭ＿ＬＥＮ、ＸＦＥＲ＿ＬＥＮ、ＢＵＦＣＮＴ、ＷＰ、ＲＰ＿ＣＯＭＭＩＴ、ＲＰおよびＮＥＸＴ＿ＩＰＩ用のエントリを、含んでいてもよい。以下に同様により十分に説明されるように、ＩＤＭＡ ＦＩＦＯバッファ２３８が、ＩＤＭＡ制御ブロック２４０、ＩＬＣＴマネージャ（“ＩＬＣＴ ＭＧＲ”）２４２およびＩＤＭＡエンジン２４４とともに含まれていてもよい。入力アドレスバッファ２４６および入力データバッファ２４８も含まれていてもよい。

図示されているように、送信側２０２および受信側２０４は、図２Ａおよび図２Ｂ双方に示されるＳＮＡＰ＿ＣＯＮＴＥＸＴテーブル２５０によって示されるような、ある共有状態および機能性を有していてもよい。ＳＮＡＰ＿ＣＯＮＴＥＸＴテーブル２５０は、現在のＣＩＤ（“ＣＵＲＲＥＮＴ＿ＣＩＤ”）、現在のＡＰＰＩＤ（“ＣＵＲＲＥＮＴ＿ＡＰＰＩＤ”）、プロセッサにより期待されるブロック長さ（“ＰＥ＿ＢＬＯＣＫ＿ＬＥＮ”）、ＩＰＩ間隔（“ＩＰＩ＿ＩＮＴＥＲＶＡＬ”）および現在の着信ＣＩＤ（“ＣＵＲＲＥＮＴ＿ＩＣＩＤ”）エントリ用のエントリを含んでいてもよい。送信側２０２および
受信側２０４はまた、以下により十分に述べられるような、共有されるＩＰＩジェネレータ（“ＩＰＩ ＧＥＮ”）２５２およびＩＰＩハンドラ（“ＩＰＩ ＨＡＮＤＬＥＲ”）２５４も含んでいてもよい。

エス・アール・シィ・コンピューターズ・インコーポレイテッドによって開発されたＳＮＡＰの１つの目的は、商品のパーソナルコンピュータ（“ＰＣ”）ボードが、ＳＲＣスイッチ／共通メモリ（“ＣＭ”）を介してすべて接続された従来の、および再設定可能なマルチアダプティブプロセッサ（ＭＡＰ^TM、この発明の譲受人であるエス・アール・シィ・コンピューターズ・インコーポレイテッドの登録商標）を特徴とするスケーラブルなコンピュータにおいて、処理ノードとしての役割を果たせるようにすることである。ＳＲＣ−６コンピュータとは対照的に、従来のプロセッサはグローバルな共通メモリへのロード／ストアアクセスを持たないかもしれず、アクセスは代わりに、ＳＮＡＰとスイッチ／ＣＭとの間のプログラム可能な直接メモリアクセス（“ＤＭＡ”）で結合された、ＳＮＡＰ上のメモリマッピングされたＦＩＦＯを介する。

原則として、この機能は、遠隔プロセッサ割込を生成するための手法と結合されて、同じまたは異なるボード上のマイクロプロセッサ間のエンドツーエンド通信を可能にする。たとえば、図１は、システム１００を構成するマイクロプロセッサ１０２₀と１０２₁および／またはＭＡＰエレメント１１２を用いたこの機能および手法の一実施例を示している。しかしながら、実際には、関与するプロセッサ１０２₀と１０２₁との間で直接動作するメッセージ受け渡し実現化例に関連するセットアップ／プロトコルオーバーヘッドが問題を有するかもしれない。さらに、接続の両端でのＳＮＡＰ（またはＳＮＡＰとＭＡＰ）の専用使用を必要とするポイントツーポイントプロトコルがスケーラビリティの問題を提示するかもしれない。

ＳＮＡＰにおいて再設定可能な論理が比較的多いことは、上述の基本的なＳＮＡＰ ＤＭＡ機能性に加えて、高性能、軽量の明示的通信処理機能を実現する機会を与える。シミュレーションの結果は、そのような特徴により、その他の場合には任意の既存の商業的に入手可能なクラスタ相互接続によって達成可能なものよりも大きなメッセージ受け渡しスループットを、実装者が提供できるようになることを示している。同様に、双方向メッセージ受け渡しインターフェイス（“ＭＰＩ”送信／受信）プロトコルおよび一方向（ＭＰＩ２／共有メモリアクセスライブラリ“ＳＨＭＥＭ”）明示的通信プロトコル双方のための、競合するオペレーションシステム（“ＯＳ”）−バイパス対応のクラスタソリューションによって提示されるものに匹敵するメッセージ起動オーバーヘッドを達成する可能性がある。

接続２００の考えられる機能性は、前述のように、概ね別個で、コンフィギュレーション／コンテキスト用の何らかの共有ストレージをＳＮＡＰ＿ＣＯＮＴＥＸＴテーブル２５０に有する、送信側２０２および受信側２０４を含む。ＩＰＩ生成および取扱い論理は、ＩＰＩ ＧＥＮ２５２およびＩＰＩ ＨＡＮＤＬＥＲ２５４によって共有されている。送信側２０２と受信側２０４との間の通信は、固定された、単方向ポイントツーポイント接続を通して達成され、それらの接続の各々は、ソース側にある発信接続記述子（ＯＬＣＴエントリ）と、宛先にある対応する着信接続記述子（ＩＬＣＴエントリ）と、共通メモリの専用部分であり得る、接続ごとのメモリバッファとを有していてもよい。

ここに開示されたこの発明の例示的な実施例では、接続セットアップはＯＳにより特権が与えられており、アプリケーション起動時点で起こり、ソース上で実行中のＯＳインスタンスと宛先ノードとの間の調整／通信を必要とする。この最初のオペレーションシステム間の通信に使用されるチャネルは設計上の選択の問題であるが、ソフトウェア制御の下で「生の」ＰＥ−＞ＳＮＡＰ−＞ＣＭ通信を使用してもよい。一旦セットアップされると
、各接続は、送信側２０２の出力ＦＩＦＯ２１４と受信側２０４の入力ＦＩＦＯ２３８との間にユーザがアクセス可能な経路を提供する。

任意の所与の時点で、各プロセッサに関連するＳＮＡＰは、単一のアプリケーションプロセスの制限された制御下にあってもよく、それは、単一の識別子またはＡＰＰＩＤの下でグループ化された通信プロセスのクラスタ幅の集合に加わっていてもよい。

送信側２０２では、現在制御中のプロセスが、転送初期化／再開のための制御ページ書込によって、アクティブな接続を判断してもよい。このプロセスは、そのＡＰＰＩＤによって所有される（以前にオペレーションシステムによってセットアップされた）接続２００上で送信してもよい。

受信側２０４では、ＳＮＡＰ ＩＤＭＡ制御論理２４０が、現在制御中のプロセスのＡＰＰＩＤを有し、かつ、送信用にＣＭのバッファに入れられた未処理のデータを有するＩＬＣＴのエントリから選択して、現在アクティブな接続を判断する。これは、特に着信データの潜在的ソースがたくさんあり得る場合に、さもなければ禁止オーバーヘッドを招く、プロセッサにより指示される着信転送のスケジューリングの必要性をなくす。このメカニズムは、制御中のアプリケーションと同じＶＡ空間で動作する専用アプリケーションスレッドによって受信側２０４がサービスを受けるようにすることを含み、それは、着信転送のためにＩＤＭＡ制御ページ２３０をポーリングし、データをＩＤＭＡ ＦＩＦＯ２３８から正しいターゲットメモリ位置に読み出す責任を有していてもよい。

ＩＤＭＡ制御ページ２３０およびＯＤＭＡ制御ページ２０６の多数のプロセッサアクセス可能レジスタは、多すぎて直接対処不可能であり、図示されるように小さなブロックを重ね合わせることなどによる補助アクセスメカニズムを必要とするかもしれない。この構成の下では、プロセッサ１０２₀または１０２₁は（図示されていないある特定のレジスタに）制御書込を発行して、アクティブなレジスタブロック間をスイッチする。

発信ローカル接続テーブル（ＯＬＣＴ）
送信側２０２に関し、ＯＬＣＴ［ＣＩＤ］テーブル２１０は、ローカルノードから生じる各発信ポイントツーポイント接続２００用のエントリを含んでいてもよい。テーブル２１０はＯＤＭＡ制御論理２１６によって保持される。接続２００は、一般にオペレーションシステムによって特権が与えられた動作である、接続テーブルインデックス（“ＣＩＤ”）、ＡＰＰＩＤ、ＴＡＲＧＥＴ＿ＮＯＤＥ、ＴＡＲＧＥＴ＿ＣＩＤ、ベースアドレス、および、接続のＣＭバッファ用のアドレス長さの、ＣＩＤセットアップレジスタへの書込によって、プロセッサ１０２₀または１０２₁によりセットアップされてもよい。

ＯＬＣＴテーブル２０８のＣＩＤエントリ２１０は、ＯＤＭＡ制御ページ２０６のＸＦＥＲ＿ＩＮＩＴレジスタまたはＣＩＤ＿ＳＥＴＵＰレジスタが書込まれた際にはいつでも、および、アクティブな発信接続がスイッチされた際にはいつでも、ＯＤＭＡ制御論理２１６によって更新される。この機能性についての可能なフォーマットは以下のようになっていてもよい。

ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ
現在アクティブな発信転送用のＯＬＣＴエントリはＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥテーブル２１２に複製されてもよく、それは、アクティブな転送の進行を追跡するフィールド、つまりＸＦＥＲ＿ＡＣＣＥＰＴＥＤ、ＸＦＥＲ＿ＣＯＭＰＬＥＴＥＤおよびＮＥＸＴ＿ＩＰＩ ＸＦＥＲ＿ＣＯＭＰＬＥＴＥＤも含んでいてもよい。転送はスイッチング前にアイドルになるかもしれないため、これらのフィールドはＯＬＣＴ自体には存在しないかもしれない。

ＯＤＭＡ ＦＩＦＯ
ＯＤＭＡ ＦＩＦＯ２１４は、プロセッサ１０２₀または１０２₁のデータページへの書込用の宛先であり、ＯＤＭＡエンジン２１８の書込データ用のソースである。

ＯＤＭＡ制御
ＯＤＭＡ制御２１６は、コマンドのために制御ページを監視し、プロセッサ１０２₀および／または１０２₁がアクセス可能なステータス、ＳＮＡＰコンテキストおよびＯＬＣＴを必要に応じて更新し、アクティブなＡＰＰＩＤ間、転送間のスイッチングを必要に応じて管理する。その機能性は、接続セットアップ制御ページ書込（ＣＩＤ＿ＳＥＴＵＰ）を受信次第、ＯＬＣＴを更新すること、および、転送起動制御ページ書込（ＸＦＥＲ＿ＩＮＩＴ）を受信次第、アクティブな転送間をスイッチすることを含んでいてもよい。なお、現在の転送は、このメッセージを受信次第、アイドルになるべきであり（つまり、ＯＤＭＡ ＦＩＦＯ２１４は空となるべきであり）、その時点で、ＯＤＭＡエンジン２１８は遮断されなければならず（ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ無効）、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥはＯＬＣＴにまた書込まなければならない。新しい転送ＣＩＤ用のＯＬＣＴエントリはＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥに書込まれなければならない。再開フラグがセットされる（つまりプロセッサ１０２がＸＦＥＲ＿ＩＮＩＴ＿ＳＴ
ＡＴＵＳに書込まれる）場合を除き、転送長さは制御ページからＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥにコピーされなければならず、転送進行フィールド（ＸＦＥＲ＿ＡＣＣＥＰＴＥＤ、ＸＦＥＲ＿ＣＯＭＰＬＥＴＥＤ、ＮＥＸＴ＿ＩＰＩ）は初期化されなければならない。ＯＤＭＡエンジン２１８は、データがＯＤＭＡ ＦＩＦＯ２１４に着信するにつれて転送を処理するために、さらに、着信転送進行ＩＰＩを処理し、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ、ＦＬＯＷＣＴＬ＿ＲＳ制御ページレジスタおよびＯＬＣＴを更新して、コミットされたＣＭ読出ポインタ（ＸＦＥＲ＿ＣＯＭＰＬＥＴＥＤ）を反映するために、解放されなければならない（ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥは有効）。

なお、現在のＣＩＤ以外の転送については進行ＩＰＩが無視されてもよいが、「スイッチアウト」の時点で完全に受入れられることによってコミットされなかった転送が、「スイッチイン」の時点で完全である（または中止されるなど）としてユーザに通知されることを確実にするために、何らかのメカニズムが必要とされる。これは、読出ポインタをＯＬＣＴにストアする、または更新する必要性を有用に排除する。

ＯＤＭＡエンジン
ＯＤＭＡエンジン２１８および関連する論理は、（ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥに基づいて）ＣＭ書込要求を生成して、データをＯＤＭＡ ＦＩＦＯ２１４からスイッチ要求バッファに転送すること、ＳＮＡＰをＣＭ転送進行に反映させるよう、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ（ＢＵＦＣＮＴ、ＸＦＥＲ＿ＡＣＣＥＰＴＥＤ、およびＮＥＸＴ＿ＩＰＩ）を更新すること、および、ＩＰＩ＿ＩＮＴＥＲＶＡＬラインが最後のＩＰＩ以降送信された場合はいつでもＩＰＩ ＧＥＮ２５２をトリガしてＮＥＸＴ＿ＩＰＩカウンタをリセットすることに対して責任を有していてもよい。

上述の事項に加え、ＯＤＭＡエンジン２１８は、制御ページ書込を介して直接プログラムされるべきその既存の能力も維持するべきである。この「生の」アクセスモードはスイッチングを介して、永続的に定義された、システムによる特権が与えられたＣＩＤにセットされてもよい。

入力ローカル接続テーブル（ＩＬＣＴ）
受信側２０４に関し、ＩＬＣＴ［ＩＣＩＤ］テーブル２３２は、ローカルノードから生じる各着信ポイントツーポイント接続用のエントリを含んでいてもよい。接続ステータスはＩＬＣＴマネージャ２４２によって維持され、接続セットアップは、オペレーティングシステムにより特権を与えられたＩＤＭＡ制御ページ２３０のＣＩＤセットアップ書込に応答して、ＩＤＭＡ制御論理２４０によって実行される。１つの可能なフォーマットは以下のとおりである。

なお、出力（または送信）側２０２とは対照的に、現在の着信転送以外の転送用のＩＬＣＴエントリはＩＬＣＴにおいて更新される必要はない。なぜなら、各接続の送信側２０２からのＩＰＩはいつでも到着可能であり、ＩＬＣＴマネージャ２４２は、どの着信接続がサービス提供を必要としているかを判断するために、正確な共通メモリ書込ポインタなどを有する必要があるためである。

ここに開示された特定の実施例では、ベースＶＡはＩＬＣＴ内に存在すべきである。なぜなら、ＸＦＥＲ＿ＩＮＩＴメッセージは通常、アクティブな着信接続がスイッチング中の時点しかプロセッサ１０２に送信されないためである。ＶＡは、次の（または後の）アクティブな転送スイッチまでプロセッサ１０２への送信が延期され得る着信転送イニットＩＰＩの一部であり得るため、ＩＰＩにおける情報は、関連ＣＩＤ用のＩＬＣＴエントリにストアされるべきである。ストレージが少なくて貴重である場合、ストレージ要件は、（たとえば１２ビットの）インデックスを、ＶＡ自体にではなく転送イニットＩＰＩ中間（つまりＶＡ）データのテーブルにストアすることによって、緩和可能である。

ＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥ
現在アクティブな発信転送用のＩＬＣＴエントリはＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥテーブル２３６に複製されてもよく、それは、アクティブな転送の進行を追跡するために必要なフィールド（ＷＰ、ＲＰ、ＲＰ＿ＣＯＭＭＩＴおよびＮＥＸＴ＿ＩＰＩ）も含んでいてもよい。

ＩＤＭＡ ＦＩＦＯ
ＩＤＭＡ ＦＩＦＯ２３８は、ＩＤＭＡエンジン２４４の読出データ用の宛先であってもよく、プロセッサ１０２へのデータページ読出応答用のソースであってもよい。

ＩＤＭＡ制御
ＩＤＭＡ制御２４０は、接続セットアップ制御ページ書込（ＣＩＤ＿ＳＥＴＵＰ）を受信次第ＩＬＣＴを更新することと、サービス提供を必要とする接続を識別すること（つまり、（ＣＭ Ｗｒｉｔｅ ｐｏｉｎｔｅｒ！＝ＣＭ Ｒｅａｄ Ｐｏｉｎｔｅｒ）ｉｎ ＩＬＣＴ ｅｎｔｒｙ，＆＆（ＩＬＣＴ［ＣＵＲＲＥＮＴ＿ＩＣＩＤ]．ＡＰＰＩＤ＝＝ＣＵＲＲＥＮＴ＿ＡＰＰＩＤ））と、以前に識別された、現在待機中の着信接続間で優先順位をつけることと、その存在がプロセッサ１０２にまだ通知されていないアクティブな転送の選択時に転送起動通知（ＩＤＭＡ制御ページ２３０のＸＦＥＲ＿ＩＮＩＴレジスタの内容）を生成することと、ラウンドロビンなどのスケジューリングアルゴリズムに従って現在アクティブな転送を必要に応じてスイッチし、アイドルに、および出力または送信側２０２と同様にスイッチオンすることに対して責任を有していてもよい。現在のアクティブな転送は、スイッチが起こり得る前にアイドルとなるべきであり（つまり、ＩＤＭＡ
ＦＩＦＯ２３８は空であるべきであり）、プロセッサ１０２は全データの認証された受信を有するべきであり、受信−送信転送コミットＩＰＩ（ＦＬＯＷＣＴＬ＿ＲＳ）は、プロセッサ１０２によって受入れられた全データについて送信されていなければならない。

単一の着信接続がＳＮＡＰを長期間独占し、その間、他の着信接続が待っている、という可能性を排除するために、ＩＤＭＡ制御２４０は、現在の着信接続についての未読データがまだ共通メモリ内に存在していてもＩＤＭＡエンジン２４４をアイドルにする機能を有していてもよい。現在の転送が一旦アイドルになると、スイッチは、ＩＤＭＡエンジン２４４を遮断することによって達成されてもよい（つまり、ＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥは無効である）。以前にアクティブだった転送が不完全である場合、ＩＤＭＡ制御ページ２３０の転送中断フラグ（ＦＬＯＷＣＴＬ＿ＲＳ＿ＳＴＡＴＵＳの一部）は、現在の転送が中断されて、それが新しい転送イニットメッセージのためにポーリングすべきであることをプロセッサ１０２に示し（転送はアイドル状態で、ＩＬＣＴはＩＬＣＴマネージャ２４２によって直接更新されるため、ＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥをＩＬＣＴにまた書込む必要はない）、アクティブとなる次の転送（つまりＩＣＩＤ）を選択し、新しい現在のＩＣＩＤ用のＩＬＣＴエントリをＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥにコピーし、ＩＤＭＡ制御ページ２３０のＸＦＥＲ＿ＩＮＩＴレジスタを新しい（または予め存在する場合には再開された）転送の詳細で更新してＸＦＥＲ＿ＩＮＩＴ＿ＳＴＡＴＵＳの有効ビットをセットし、データがＩＤＭＡ ＦＩＦＯ２３８に着信するにつれて転送を進行させるためにＩＤＭＡエンジン２４４を解放する（ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥは有効である）よう、セットされてもよい。

ＩＬＣＴマネージャ
ＩＬＣＴマネージャ２４２は、着信転送起動および進行ＩＰＩに応答して、および、プロセッサ１０２がＩＤＭＡ制御ページ２３０のＦＬＯＷＣＴＬ＿ＲＳレジスタに書込む際はいつでもＩＬＣＴを更新する責任を有していてもよい。なお、この点で、どの有効なＣＩＤも、現在の着信転送のためだけではなく、更新を必要とするかもしれない。更新が現在の転送に関係する場合、現在アクティブな転送状態における関連フィールド（つまりＢＵＦＣＮＴ、ＷＰ）は、ＩＬＣＴエントリと並行して更新されてもよい。

ＩＤＭＡエンジン
ＩＤＭＡエンジン２４４および関連する論理は、（ＣＵＲＲＥＮＴ＿Ｉ＿ＸＦＥＲ＿ＳＴＡＴＥに基づいて）共通メモリ読出要求を生成して、データをスイッチ応答バッファからＩＤＭＡ ＦＩＦＯ２３８に転送すること、ＳＮＡＰを接続ごとのメモリバッファの転送進行に反映させるよう、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥ（ＢＵＦＣＮＴ、ＸＦＥＲ＿ＡＣＣＥＰＴＥＤ、およびＮＥＸＴ＿ＩＰＩ）を更新すること、および、受信側２０４のプロセッサ１０２がＩＤＭＡ ＦＩＦＯ２３８から読出されるために利用可能なデ
ータの量を判断できるよう、ＦＬＯＷＣＴＬ＿ＳＲ ＩＤＭＡ制御ページ２３０の書込ポインタを維持することに責任を有していてもよい。送信側２０２と同様に、ＩＤＭＡエンジン２４４も、制御ページ書込を介して直接プログラムされるべきその既存の能力、つまり「生の」アクセスモードを維持すべきである。

共有される状態／機能性
ＳＮＡＰコンテキスト
図２Ａおよび図２Ｂをともに参照すると、ＳＮＡＰ＿ＣＯＮＴＥＸＴテーブル２５０は、現在のＡＰＰＩＤに関連し、制御中のユーザプロセスが変更される際はいつでもオペレーティングシステムにより特権を与えられた制御ページ書込を介して書込まれる、転送に特有ではないコンテキスト情報用の包括的な場所である。ＳＮＡＰ＿ＣＯＮＴＥＸＴテーブル２５０は以下のエントリを含んでいてもよい
ＣＵＲＲＥＮＴ＿ＣＩＤ−現在アクティブな接続のＯＬＣＴエントリを選択するために使用され得る、現在の発信接続ＩＤ
ＣＵＲＲＥＮＴ＿ＡＰＰＩＤ−現在制御中のプロセスに関連していない接続を保護するために使用される
ＰＥ＿ＢＬＯＣＫ＿ＬＥＮ−プロセッサ１０２がＯＤＭＡ制御ページ２０６のＦＬＯＷＣＴＬ更新／ステータスの各ポーリング間に書込むよう期待されている、データの量
ＩＰＩ＿ＩＮＴＥＲＶＡＬ−フロー制御ＩＰＩを受信側２０４のＳＮＡＰに送信する前にＯＤＭＡエンジン２１８によって書込まれるべき、さらに、ＳＮＡＰの受信から送信まで進行ＩＰＩをスケジューリングするためにも使用されるべきラインの数
ＣＵＲＲＥＮＴ＿ＩＣＩＤ−現在アクティブな着信転送用のＩＬＣＴへのインデックス。

ＩＰＩ生成／ＩＰＩハンドラ
ＩＰＩ生成２５２は、ＩＰＩパケットを出力ストリームに挿入する責任を有する。ＩＰＩパケットペイロードのフォーマットは以下のようであってもよい。

ターゲットＳＮＡＰでのＩＰＩハンドラ２５４は、ＩＰＩパケットを沈め、それらを処理するために転送する。トリガリングイベント／動作の例示的な説明は以下のようになってもよい。

転送起動ＩＰＩ
これは、プロセッサ１０２から有効なＸＦＥＲ＿ＩＮＩＴメッセージを受信次第、ＯＤＭＡ制御２１６によってトリガされてもよい。受信時、このメッセージはＩＬＣＴマネージャ２４２に送られてもよく、それは、指示されたＣＩＤ用の接続テーブルエントリを更新する。なお、現在不完全な転送の詳細に上書きすることは、ＳＮＡＰの観点からは正当であるが、受信側２０４の制御中のプロセスは、たとえば、ＣＩＤが次にアクティブになる際に再開フラグがセットされていないことを検出して適切な処置をとることによってそれを取扱うよう、セットアップされるべきである。

フォワードフロー制御ＩＰＩ
これは、ＯＤＭＡエンジン２１８が現在の転送用の書込まれたＩＰＩ＿ＩＮＴＥＲＶＡＬラインを有する場合に、および、転送の最後のラインが接続ごとのメモリバッファに書込まれた後で、ＯＤＭＡエンジン２１８によってトリガされてもよい。受信側のＳＮＡＰで受信されると、データはＩＬＣＴマネージャ２４２に送られてもよく、それは、ＩＰＩデータのＣＩＤフィールドによって示されるＩＬＣＴエントリの共通メモリ書込ポインタを更新してもよい。

リターントランスファー進行通知ＩＰＩ
これは、新しいＸＦＥＲ＿ＣＯＭＭＩＴ値がＩＤＭＡ制御ページ２３０のＦＬＯＷＣＴＬ＿ＲＳブロックのＸＦＥＲ＿ＣＯＭＭＩＴレジスタに書込まれる際はいつでも、ＩＬＣＴマネージャ２４２によってトリガされてもよい。これは、現在の着信転送用のＩＬＣＴ
エントリのＲＰ＿ＣＯＭＭＩＴフィールドの更新と並行して起こり得る。ＳＮＡＰ（つまり、送信側２０２）によって受信次第、ＩＰＩハンドラ２５４はデータをＯＤＭＡ制御ブロック２１６に送ってもよく、それは前述のように転送進行を反映するよう、ＯＬＣＴおよびＯＤＭＡ制御ページ２０６のＦＬＯＷＣＴＬ＿ＲＳレジスタを更新する。

ＳＮＡＰＣＦ：プログラミングインターフェイス
明示的通信機能のアプリケーション使用をサポートするソフトウェアは、以下の構成要素を含んでいてもよい。

ＯＳ／カーネルサポート
１．ユーザメモリマップされたＳＮＡＰ通信インターフェイス（ＳＮＡＰＣＩ）の割当／管理
ユーザプロセス間のコンテキストスイッチＳＮＡＰＣＩは、通信インターフェイスをアイドルにし、ＡＰＰＩＤに固有のコンテキストの読出／書込を行ない、制御ページをアンマッピング／リマッピングすることを伴う。

２．ＯＳ←→ＯＳ低レベルクラスタ間通信サポート
これは、メッセージ待機を示すために、永続的な共通メモリメールボックスへの「生の」ＳＮＡＰ→共通メモリデータ転送および遠隔割込を用いることを含んでいてもよい。この通信は比較的不十分であり得るため、それは、ＯＳインスタンス間でのあまり頻繁ではない通信のためのみに使用されるべきである。それは、アプリケーションワークグループおよび接続セットアップを可能にするためにも使用されてもよい。

３．ＮＡＰＣＩシステムコールサポート
アプリケーション起動時、ユーザプロセスは、それ自体を分散型アプリケーションの参加者として確立して（ＡＰＰＩＤＪｏｉｎ）、仮想ＰＥ番号を取得する（Ｇｅｔ＿ＭＹＰＥ）ことができる。これが一旦行なわれると、接続は、ソースおよび宛先を特定するのに仮想ＰＥ番号を用いて、確立可能である。

−アプリケーションワークグループに参加する ＡＰＰＩＤ＿ｔ ＡＰＰＩＤＪｏｉｎ（ＡｐｐＭａｇｉｃ）
・ＡｐｐＭａｇｉｃはＯＳに登録されており、どのような高レベルパラレルランチャが使用されていても、それによりアプリケーションに供給されてもよい
・参加する１番目のプロセスはＭＹＰＥ＝０を取得し、２番目は１を取得する、などとなる。共通メモリにおいて集中化した物理的ＳＮＡＰＩＦ→仮想プロセッサマッピングを必要とする。

−自分の（仮想）プロセッサ番号を取得する Ｉｎｔ Ｇｅｔ＿ＭＹＰＥ（ＡＰＰＩＤ）
・ＡＰＰＩＤＪｏｉｎ時点で確立された仮想ＰＥ番号を取得する。集中化された（または、好ましくはＡＰＰＩＤＪｏｉｎ時点でＯＳによりキャッシュされた）テーブルを調べる。

−Ｃｏｎｎｅｃｔｉｏｎ ＣＩＤ＿ｔＳｅｔｕｐＣＩＤ（ＡＰＰＩＤ，ＭＹＰＥ，ＤｅｓｔＰＥ）を確立する（送信側）。

・接続はポイントツーポイントで単方向性であり、送信側から作られる
・接続セットアップは以下を伴う。

・接続を引き裂く ｉｎｔ ｄｅｓｔｒｏｙＣＩＤ（ＡＰＰＩＤ，ＣＩＤ）
・アプリケーションワークグループを離れる ｉｎｔ ＡＰＰＩＤＤｅｔａｃｈ（ＡＰＰＩＤ）。

送信側アプリケーションライブラリ転送初期化／処理
送信ルーチンは、実行中、割込まれて接続２００の制御を潜在的に失う／取戻すことができる必要がある。しかしながら、ＯＳは、ＳＮＡＰによって受信中であるとして認識されているデータが接続ごとのメモリバッファに配送済みであることを保証すべきである。最後の受入メッセージの後、コンテキストスイッチの前に送られたデータもメモリバッファに書込まれてもよいが、次のＦＬＯＷＣＴＬ＿ＲＳポーリングにおいて不良ステータスとなるかもしれず、それは、最後の受入後にアプリケーションに全データを再送させるかもしれない。

なお、ＶＡパラメータは、転送セットアップの一環として受信側２０４プロセスに直接渡されてもよい。ＳＨＭＥＭ実現化例については、ＶＡは実際には、ターゲットアプリケーションによって直接使用可能な形の宛先開始アドレスである。ＭＰＩについては、これは（たとえば）ｃｐｌａｎｔポータルハンドルまたは他のポート識別子であってもよい。

受信側リスナー（接続サービススレッド）処理
ローカルＡＰＰＩＤ用の主要アプリケーション処理スレッドと同じ仮想アドレス空間で
動作し得る、受信側接続（たとえばＳＮＡＰＣＦ）サービススレッドは、着信ＳＮＡＰＣＦ転送の処理専用であってもよい。使用されるメッセージ受け渡しモデルに依存して、このサービススレッドは、転送イニットメッセージのＶＡプラス転送オフセット（たとえばＳＨＭＥＭ）に基づいてアプリケーションメモリに直接着信データを預けてもよく、または、それは、主要アプリケーション処理スレッド（たとえばＭＰＩ）で実行中のメッセージ受け渡しライブラリ受信ルーチンによる処理のためにそれをライブラリバッファに配置してもよい。後者の場合、転送イニットメッセージＶＡフィールドは、ゼロコピーユーザモードメッセージング（たとえばＣｐｌａｎｔ／サンディア（Sandia）“ポータル”）をサポートするために使用可能である。

いずれの場合も、サービススレッドは、現在のＡＰＰＩＤ（つまり、現在ＳＮＡＰのユーザモード制御を有しているＡＰＰＩＤ）のために現在確立されている任意の着信ＣＩＤについてのデータの塊を要約できなければならない。これは、接続にサービスを提供している制御が通常、サービススレッドというよりはむしろ、ＳＮＡＰ ＩＤＭＡ制御２４０とともに存在するためである。このため、スレッドは着信ＣＩＤのテーブルを、各々についてのベース“ＶＡ”（たとえばポータルＩＤなど）および現在の転送オフセットとともに維持してもよい。

ＣＩＤ間で着信ストリームをスイッチすることは、中断フラグおよび再開フラグを介して達成されてもよい。ＩＤＭＡ制御ページ２３０のＦＬＯＷＣＴＬ＿ＳＲステータスにおける中断フラグは、ＩＤＭＡ ＦＩＦＯ２３８が現在の転送のために空となり、それが新しいＩＤＭＡ ＸＦＥＲ＿ＩＮＩＴメッセージのためにポーリングすべきであることをリスナーに示した後で、接続２００（つまりＳＮＡＰＣＦ）によってセットされてもよい。ＩＤＭＡ制御ページ２３０のＸＦＥＲ＿ＩＮＩＴステータスにおける再開フラグは、イニットメッセージが既に部分的に完了した転送に関していることをリスナーに示す。

ＳＮＡＰＣＦは、それがサービス提供のために非ゼロオフセットを用いた転送を選択する場合にはつねに再開フラグをセットするが、（ＳＮＡＰＣＦの観点からは）送信ＣＩＤの所有者が、古い転送が不完全であっても新しい転送をＣＩＤ上で起動することが許可されている。この場合、ＳＮＡＰ ＩＬＣＴオフセットはゼロにリセットされ、再開フラグは、ＣＩＤが次にアクティブとなるまでセットされない。

受信側ＳＮＡＰＣＦサービススレッドについての典型的な処理シーケンスを、以下のように概説する。

なお、データが実際には不良で、ターゲットがライブラリバッファというよりもむしろユーザメモリである場合、このコピーは有効なユーザメモリを処分してもよい。このため、ＳＨＭＥＭプログラムは、中間バッファを介してデータをステージして、ターゲットメモリへのコピー前にブロックについての良好なステータスの確認を待つ間そこでそれを保持する必要があるかもしれない。バッファが常にキャッシュにあるため、問題は何ら予期されず、それは（おそらくキャッシュにはない）真のターゲットラインを先取りするための時間を許可するため、実際には物事を若干加速させるかもしれない。なお、メモリ内のデータは、後に良好な値で上書きされるまで不良である。つまり、ターゲットがライブラリバッファである場合、何も問題はないはずである。

ここで図３Ａおよび図３Ｂを加えて参照すると、前述の２つの図面の接続２００の送信側２０２および受信側２０４が、この発明の一実施例に従った代表的なエンドツーエンド
処理例を示すために示されている。なお、図３Ａおよび図３Ｂにおける構造および要素の番号付けは、明瞭にするために省略されている。

エンドツーエンド処理例
以下の事柄は、単一の転送をセットアップすることに伴うステップを示している。番号をつけられ下線が引かれたステップは、特に指示されていない限り、図３Ａおよび図３Ｂに示す、番号をつけられ下線が引かれた要素に対応している。

ステップ１（図示せず）：前述のようなアプリケーション初期化／接続セットアップ。

ステップ２：送信側アプリケーションは、ＣＩＤ、長さ、ＶＡをＯＤＭＡ制御ページ２０６ＸＦＥＲ＿ＩＮＩＴレジスタに書込むことによって、転送を開始する。

ステップ３Ａ：ＯＤＭＡ制御論理２１６はＸＦＥＲ＿ＩＮＩＴレジスタ書込を沈め、接続ＡＰＰＩＤが制御プロセスのＡＰＰＩＤに整合することをチェックした後で、
ステップ３Ｂ：ＸＦＥＲ＿ＩＮＩＴ ＣＩＤで特定されたＣＩＤについて、転送の詳細をＯＬＣＴエントリに書込む。

ステップ４：ＯＤＭＡ制御論理２１６は、その内容をＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥにコピーすることによってＣＩＤを現在のものにし、転送起動ＩＰＩの生成を開始し、ＩＰＩが送信されて沈めるべきデータがあり次第ＯＤＭＡ ＦＩＦＯ２１４を空にするようＯＤＭＡエンジン２１８を解放する。

ステップ５Ａ：ＩＰＩジェネレータ２５２は、起動ＩＰＩをターゲットＳＮＡＰに送信し、次に
ステップ５Ｂ：ＩＰＩハンドラ２５４は、起動ＩＰＩデータをＩＬＣＴマネージャ２４２に渡し、それは、
ステップ５Ｃ：新しい転送の詳細を反映するよう、ＣＩＤのためにＩＬＣＴを更新する。

ステップ６：ステップ３、４および５と並行して、アプリケーションはＯＤＭＡ ＦＩＦＯ２１４へのデータの書込を開始するが、接続は、ステップ４が完了するまでそれを処理できない。

ステップ７：第１のラインが利用可能になると、ＯＤＭＡエンジン２１８は、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥにおいてＣＭ＿Ｂａｓｅ＋ｏｆｆｓｅｔを用いて、共通メモリ書込要求を生成する。オフセットは次にインクリメントされ、ｎｅｘｔ＿ＩＰＩはデクリメントされる。このステップはＮＥＸＴ＿ＩＰＩ＝０、または転送の終了まで繰返されるべきである。

ステップ８：ステップ６と並行して実行されて、ＩＰＩ生成論理２５２は、（ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥからの）遠隔ＣＩＤとともに、ＩＰＩ用ターゲットアドレスを検索する。ＩＰＩ用共通メモリ書込ポインタも前もって計算される。

ステップ９：ＮＥＸＴ＿ＩＰＩ＝０の場合、ＯＤＭＡエンジン２１８は遮断し、ＩＰＩジェネレータ２５２は、予めフォーマット化されたＦＬＯＷＣＴＬ＿ＳＲ ＩＰＩパケットを宛先ＳＮＡＰに送信する。

ステップ１０：宛先側のＩＰＩハンドラ２５４は、ＩＰＩデータをＩＬＣＴマネージャ２４２へ送る。

ステップ１１：ＩＬＣＴマネージャ２４２は、新しい共通メモリ書込ポインタを反映するよう、ＩＰＩパケットに特定されたＣＩＤについてＩＬＣＴエントリを更新する。

ステップ１２：その後、（ＩＤＭＡがアイドルとなったらすぐに）ＩＤＭＡ制御論理２４０は、この転送用ＣＩＤを現在のものとして選択し、ＩＬＣＴエントリをＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥにコピーし、ＩＤＭＡエンジン２４４を解放してＩＤＭＡ ＦＩＦＯ２３８を充填し始める。

ステップ１３：ＩＤＭＡ制御論理２４０は、新しい転送の詳細を反映するよう、ＩＤＭＡ制御ページ２３０のＸＦＥＲ＿ＩＮＩＴレジスタを更新する。

ステップ１４：アイドルループでＸＦＥＲ＿ＩＮＩＴレジスタをポーリングしていた受信側２０４のプロセッサ１０２は、転送起動メッセージを読出し、その状態を更新し、ＦＬＯＷＣＴＬ＿ＳＲメッセージのためにポーリングを開始する。

ステップ１５：ステップ１３および１４と並行して、ＩＤＭＡエンジン２４４は、共通メモリからＩＤＭＡ ＦＩＦＯ２３８を充填し始め、各ラインが読込まれるにつれて現在の入力転送状態にある共通メモリ読出ポインタを更新する。

ステップ１６：設定可能な数のライン（または短い場合には転送全体）がＩＤＭＡ ＦＩＦＯ２３８に蓄積された後で、ＩＤＭＡ制御ブロック２４０は、現在のＣＩＤおよびＲＰをＩＤＭＡ制御ページ２３０のＦＬＯＷＣＴＬ＿ＳＲレジスタに書込む。

ステップ１７：リスナースレッドポーリング応答は、ＦＬＯＷＣＴＬ＿ＳＲメッセージを取上げる。

ステップ１８：リスナースレッドはＩＤＭＡ ＦＩＦＯ２３８からデータを読出す。

ステップ１９：データがすべて読出されると、リスナースレッドはデータの受信を認識し、その読出ポインタをＦＬＯＷＣＴＬ＿ＳＲ ＲＰ＿ＣＯＭＭＩＴレジスタに書込むことによって、転送を読出ポイントまでコミットする。転送が１ブロックを超える場合、処理は前述の規則に従って継続する。

ステップ２０（図示せず）：ＩＤＭＡ制御ブロック２４０は、ＦＬＯＷＣＴＬ＿ＲＳレジスタからコミットされた読出ポインタを読出し、ＩＬＣＴを更新し、ＦＬＯＷＣＴＬ ＩＰＩを起動して送信元に戻す。

ステップ２１（図示せず）：ＦＬＯＷＣＴＬ＿ＲＳ ＩＰＩは送信側２０２のＳＮＡＰによって取上げられ、そのＳＮＡＰは、コミットされた新しい読出ポインタを反映するよう、ＣＵＲＲＥＮＴ＿ＸＦＥＲ＿ＳＴＡＴＥを更新する。ＤＭＡエンジンはここでは、新しいＲＰまで共通メモリバッファに自由に上書きする。

ステップ２２（図示せず）：送信側２０２のＯＤＭＡ制御ブロック２１６は、ＯＤＭＡ制御ページ２０６のＦＬＯＷＣＴＬ＿ＲＳ ＲＰ＿ＣＯＭＭＩＴ値を更新し、それは次のプロセッサ１０２のポーリングで取上げられる。

この発明の原理を、特定の手法および機能ブロックとともに上に説明してきたが、上の説明は単なる例示であって、この発明の範囲に対する限定としては行なわれていないことがはっきりと理解されるべきである。特に、上の開示の教示は当業者に他の修正を示唆す
るということが認識される。そのような修正は、本質的に既に公知の、および、ここに既に説明された特徴の代わりに、または特徴に加えて用いられ得る、他の特徴を伴うかもしれない。請求項は、この出願において、特徴の特定の組合せに対して策定されているが、ここの開示の範囲が、明示的にまたは暗示的に開示された任意の新規の特徴または特徴の任意の新規の組合せ、もしくは、当業者には明らかな任意のその一般化または修正も、そのようなものが任意の請求項において現在請求されているものと同じ発明に関するか否かにかかわらず、および、それがこの発明が直面しているものと同じ技術的問題のいずれかまたはすべてを緩和するか否かにかかわらず、含む、ということが理解されるべきである。出願人はこれにより、この出願の、またはそれから由来する任意のさらなる出願の審査中、そのような特徴および／またはそのような特徴の組合せに対して新しい請求項を策定する権利を保持する。

データ転送速度を、その他の場合に周辺機器相互接続（“ＰＩＣ”）バスから利用可能なデータ転送速度を越えて著しく向上させるために、ＤＩＭＭフォーマットの一連のマルチアダプティブプロセッサを採用しているクラスタ型コンピュータ用の、前述の特許出願に開示されたようなスイッチ／ネットワークアダプタポート（“ＳＮＡＰ”）の例示的な一実施例の機能ブロック図である。 この発明の一実施例に従ったＳＮＡＰ明示的通信サポート機能（“ＳＮＡＰＣＦ”）に例示されるような接続の送信側の概要を提供する、簡略化された機能ブロック図である。 この発明の一実施例に従ったＳＮＡＰ明示的通信サポート機能（“ＳＮＡＰＣＦ”）に例示されるような接続の対応する受信側の概要を提供する、簡略化された機能ブロック図である。 この発明の一実施例に従った代表的なエンドツーエンド処理例を示す前述の図面に示されたＳＮＡＰＣＦによって例示されるような接続の送信側の図である。 この発明の一実施例に従った代表的なエンドツーエンド処理例を示す前述の図面に示されたＳＮＡＰＣＦによって例示されるような接続の受信側の図である。

Claims (16)

1. クラスタ型マルチプロセッサシステムにおいてプロセスを実行するプロセッサノード間で通信するＯＳバイパスメッセージ伝送メカニズムであって、
   ソースプロセッサノードに結合された送信側と宛先プロセッサノードに結合された受信側とを含む接続と、
   接続の送信側および受信側にそれぞれのスイッチ／ネットワークアダプタインターフェイスによってそれぞれ結合された、出力データバッファおよび入力データバッファを含む接続ごとの単一のメモリバッファと、
   接続ごとの単一のメモリバッファと送信側スイッチ／ネットワークアダプタインターフェイスおよび受信側スイッチ／ネットワークアダプタインターフェイスの各々とに関連するダイナミック共通メモリ読出ポインタおよび書込ポインタと、
   送信側および受信側に結合され、送信側と受信側との間で共有される制御データを生成するためのＩＰＩジェネレータとを含み、
   出力データバッファは、ソースプロセッサノードと接続ごとの単一のメモリバッファとの間に結合され、入力データバッファは、接続ごとの単一のメモリバッファと宛先プロセッサノードとの間に結合され、
   接続ごとの単一のメモリバッファは前記プロセス専用であり、
   前記送信側は、プロセスからの要求に応答して出力データバッファから接続ごとの単一のメモリバッファへのデータの転送を開始する、発信直接メモリアクセス（ＯＤＭＡ）エンジンを含み、
   ＩＰＩジェネレータは、発信直接メモリアクセス（ＯＤＭＡ）エンジンによるデータ転送中またはデータ転送後に、ダイナミック共通メモリ読出ポインタを更新するための制御データを生成し、接続ごとの単一のメモリバッファを介して出力データバッファから転送されたデータは、更新されたダイナミック共通メモリ読出ポインタに従って、入力データバッファに読出される、ＯＳバイパスメッセージ伝送メカニズム。
2. 接続ごとの単一のメモリバッファは、クラスタ型マルチプロセッサシステムの共通メモリの一部を含む、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
3. 送信側および受信側に結合された、ＩＰＩジェネレータによって生成された制御データを処理するためのＩＰＩハンドラを含む、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
4. 前記出力データバッファおよび入力データバッファは、先入れ先出し（ＦＩＦＯ）バッファを含む、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
5. 各前記スイッチ／ネットワークアダプタインターフェイスはスイッチ／ネットワークアダプタポート（ＳＮＡＰ）を含む、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
6. 送信側は発信ローカル接続テーブル（ＯＬＣＴ）を含み、受信側は着信ローカル接続テーブル（ＩＬＣＴ）を含み、
   接続は、ＯＬＣＴおよびＩＬＣＴにおけるエントリによって、送信側と受信側との間に確立される、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
7. 接続は固定された単方向性接続である、請求項６に記載のＯＳバイパスメッセージ伝送メカニズム。
8. 前記プロセッサノードは、マルチアダプティブプロセッサ（ＭＡＰ）エレメントに結合されている、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
9. ＭＡＰエレメントに結合されたプロセッサノードは、デュアルインラインメモリモジュール（ＤＩＭＭ）ソケット用に設定されている、請求項８に記載のＯＳバイパスメッセージ伝送メカニズム。
10. 接続ごとの単一のメモリバッファは静的に割当てられている、請求項１に記載のＯＳバイパスメッセージ伝送メカニズム。
11. クラスタ型マルチプロセッサシステムであって、
    前記システムにおいてプロセスを実行するプロセッサノード間で通信するＯＳバイパスメッセージ伝送メカニズムを含み、前記メカニズムは、
    ソースプロセッサノードに結合された送信側と宛先プロセッサノードに結合された受信側とを含む接続と、
    接続の送信側および受信側にそれぞれのスイッチ／ネットワークアダプタインターフェイスによってそれぞれ結合された、出力データバッファおよび入力データバッファを含む接続ごとの単一のメモリバッファと、
    接続ごとの単一のメモリバッファと送信側スイッチ／ネットワークアダプタインターフェイスおよび受信側スイッチ／ネットワークアダプタインターフェイスの各々とに関連するダイナミック共通メモリ読出ポインタおよび書込ポインタと、
    送信側および受信側に結合され、送信側と受信側との間で共有される制御データを生成するためのＩＰＩジェネレータとを含み、
    出力データバッファは、ソースプロセッサノードと接続ごとの単一のメモリバッファとの間に結合され、入力データバッファは、接続ごとの単一のメモリバッファと宛先プロセッサノードとの間に結合され、
    接続ごとの単一のメモリバッファは前記プロセス専用であり、
    前記送信側は、プロセスからの要求に応答して出力データバッファから接続ごとの単一のメモリバッファへのデータの転送を開始する、発信直接メモリアクセス（ＯＤＭＡ）エンジンを含み、
    ＩＰＩジェネレータは、発信直接メモリアクセス（ＯＤＭＡ）エンジンによるデータ転
    送中またはデータ転送後に、ダイナミック共通メモリ読出ポインタを更新するための制御データを生成し、接続ごとの単一のメモリバッファを介して出力データバッファから転送されたデータは、更新されたダイナミック共通メモリ読出ポインタに従って、入力データバッファに読出される、クラスタ型マルチプロセッサシステム。
12. クラスタ型マルチプロセッサシステムにおいてオペレーティングシステムをバイパスする、プロセスデータをソースプロセッサノードから宛先プロセッサノードに転送する方法であって、
    ソースプロセッサノードおよび宛先プロセッサノードによってそれぞれのスイッチ／ネットワークアダプタインターフェイスを介してアクセス可能な入力バッファおよび出力バッファを含む、接続ごとの単一のメモリバッファを割当てるステップと、
    接続ごとの単一のメモリバッファとソースプロセッサノードスイッチ／ネットワークアダプタインターフェイスおよび宛先プロセッサノードスイッチ／ネットワークアダプタインターフェイスの各々とに関連するダイナミック共通メモリ読出ポインタおよび書込ポインタを設けるステップと、
    ダイナミック共通メモリ書込ポインタに従って、プロセスデータをソースプロセッサノードから送信側の出力データバッファに転送するステップと、
    プロセスデータの転送中または転送後に制御データを生成するステップと、
    ダイナミック共通メモリ読出ポインタを更新するステップと、
    更新されたダイナミック共通メモリ読出ポインタに従って、プロセスデータを出力データバッファから入力データバッファに読出すステップと、
    入力データバッファからのプロセスデータを、宛先プロセッサノードを用いて処理するステップとを含む、方法。
13. 接続ごとの単一のメモリバッファは静的に割当てられている、請求項１２に記載の方法。
14. プロセスデータをソースプロセッサノードから宛先プロセッサノードに転送する間、接続ごとの単一のメモリバッファをプロセスデータに制限するステップをさらに含む、請求項１２に記載の方法。
15. ソースプロセッサノードおよび宛先プロセッサノードは、デュアルインラインメモリモジュール（ＤＩＭＭ）フォーマットで結合されている、請求項１２に記載の方法。
16. 各スイッチ／ネットワークアダプタインターフェイスはスイッチ／ネットワークアダプタポートを含む、請求項１２に記載の方法。

Images