JP5085758B2 - 通信プロトコルにおけるパケット・サイズの削減 - Google Patents

Description

本発明は通信プロトコルにおけるパケット・サイズの削減に関する。

現代のコンピュータ・システムは、プロセッサ、メモリ・デバイス、周辺機器などを含むさまざまな構成要素の相互接続によって実現される。これらの異なる構成要素間の通信を可能にするために、これらのデバイスの一つまたは複数を相互接続するためのさまざまなリンクが存在しうる。システムは多くの異なる型の相互接続またはリンクを含むことができる。典型的には、各個別的な型のリンクについて所与の通信プロトコルがあり、そのようなリンク上で生起する通信はこのプロトコルに従う。

一般に、通信プロトコルは、たとえばあるエージェントにおいて他のエージェントへの通信のために形成されるデータ・パケットのために、情報を通信する比較的標準的な仕方を提供する。典型的なデータ・パケットは、コマンドおよび他の制御情報を含みうるいわゆるヘッダ部分と、パケットに関連するデータを含むペイロード部分を含む。共有メモリ・マルチプロセッサ・システムにおけるポイントツーポイント通信のための典型的な通信プロトコルは、固定データ・パケット・サイズを定めている。

しかしながら、そのような固定データ・パケット・サイズは不必要に相互接続帯域幅を消費することがある。たとえば、通信プロトコルがデータ・パケット・サイズがキャッシュ・ライン・サイズであると指定しているとする。使用される最も一般的なキャッシュ・ライン・サイズは64バイトまたは128バイトである。しかしながら、エージェントがより少量のバイト、たとえば8バイトを送ろうとする場合でも、64または128バイトいっぱいのデータ・パケット・サイズが送信され、無用に帯域幅を消費する。

本発明は請求項記載の手段によって課題を解決する。

本発明のある実施形態に基づくプラットフォームのブロック図である。 本発明のもう一つの実施形態に基づくプラットフォームのブロック図である。 本発明のある実施形態に基づく例示的なパケット・フォーマットを示す図である。 本発明のある実施形態に基づく、メモリ・アクセス・トランザクションを実行するための方法の流れ図である。 本発明の別の実施形態に基づく方法の流れ図である。 本発明のある実施形態に基づくリモート読み出し動作のための流れ図である。 本発明のある実施形態に基づくリモート・エージェントへの書き込み動作のための流れ図である。 本発明のある実施形態に基づく、リモート・ノードへのプリフェッチ動作のための流れ図である。 本発明のある実施形態に基づく、プロセッサのブロック図である。

さまざまな実施形態において、所与の通信プロトコルについての標準的なデータ・パケット・サイズよりも少ないデータ部分を含むデータ・トランザクションの通信を可能にするための技法が提供される。このようにして、通信プロトコルによって指定されるデータ・ペイロードの全量よりも少ない量を要求するトランザクションを送る相互接続オーバーヘッドが回避できる。さらに、より大きなパケット・サイズ中に存在する少量のデータを扱うのに必要な処理の複雑さが回避できるので、処理資源がよりフルに使用されることができる。すなわち、従来のシステムでは、より大きなデータ・パケットは、どうでもいい値（don't cares）を詰め込まれることができ、あるいはトランザクションはバイト・イネーブル（byte enables）をもつフル・データ・パケットを要求しうる。これらの場合、かなりのリンク帯域幅が浪費される。これはさらにプロセッサ計算能力を十分に活用しないことになる。

本発明の範囲はこの点に関して限定されるものではないが、諸実施形態は、シリアル・ベースのポイントツーポイント（PtP）通信プロトコルのようなコヒーレント通信プロトコルとの関連で使用されうる。一つのそのような例はインテル（商標）クイック・パス・インターコネクト（QPI: Quick Path Interconnect）通信プロトコルである。もちろん、諸実施形態は他の相互接続技術とも等しく使うことができる。

一般に、通信プロトコルはデスクトップおよびサーバー・プラットフォームのために最適化されることがあり、よってそのようなプラットフォーム上の一般的な作業負荷のための固定データ・パケット・サイズを実装する。たとえば、本発明のある実施形態に基づく通信プロトコルは、64バイトのデータ部分を通信するために標準的なデータ・パケット・サイズを指定しうる。この64バイトのデータ部分は、フリット（flit）と呼ばれる複数の個々のフロー制御ユニット（flow control unit）にセグメント分割されうる。

そのようなデータ・パケットはデスクトップおよびサーバー・プラットフォーム上での多くのアプリケーションにとって好適でありうるものの、そのようなプラットフォーム上での一部のアプリケーションおよび高性能コンピューティング（HPC: high performance computing）のような異なる型のプラットフォームについては、このパケット・フォーマットは、より小さな（たとえば8バイトの）データ・パケットを転送する際には非常に非効率的であることがある。例として、限られたデータ・ペイロード・サイズのHPC固有の動作はロード、リモート・ノードからのプリフェッチならびにリモート・ノードでのストアおよび原子的メモリ動作を含む。諸実施形態は、相互接続に沿って送信されるパケットについてのデータ・ペイロードのサイズの柔軟性を提供し、それにより、より効率的なデータ通信が生起できるようになる。リモート・ノードへのより小さなデータ・サイズのための要求は、パーティション分割グローバル・アドレス空間（PGAS: partitioned global address space）プログラミング・パラダイムの使用が、期待されているように、HPCコミュニティにおいてより大きな追随を得るにつれ、より優勢となるであろう。

諸実施形態は、いわゆる原子的メモリ動作（AMO: atomic memory operation）を介したデータ転送を提供することによって、通信効率のさらなる改善を可能にしうる。AMOは、データ・オペランドを、該オペランドに対して実行されるべき動作と一緒に、また別のデータ・オペランドへの参照を、あるエージェントから別のエージェント（典型的にはリモート・ノードのエージェント）に転送することに関わる。これらは第二のエージェントによって、たとえば該第二のエージェントに関連するメモリへのメモリ読み出しを介して、取得されることができる。いくつかの実施形態では、AMOで送られるデータ・オペランドは、通信プロトコルについての通常のデータ・ペイロード・サイズよりも小さなサイズであってもよい（たとえば、64バイトのペイロードを要求するプロトコルに従う相互接続に沿って送られる8バイトのデータ・オペランド）。

所与の通信プロトコルについて標準的なペイロード・サイズよりも小さいペイロードをもつデータ・パケットの送信をもってトランザクションが起こることを可能にするため、パケットのコマンド部分に、標準ペイロード・サイズよりも小さなペイロード部分を有するパケット・フォーマットを可能にするさまざまなフィールドが含められることができる。のちに論じるように、ある実施形態では、これらのより小さなデータ・パケットを可能にするために、既存の要求の型に対する拡張が提供されることができる。

諸実施形態は、多くの異なる型のシステムとの関連で使用されうる。しかしながら、個別的な実装は、多くのノード（たとえば数千のノード）が相互接続されてHPCアプリケーションのためのコンピューティング機能を提供するようなHPC型のプラットフォームのためであってもよい。ここで図１を参照すると、本発明のある実施形態に基づくHPCプラットフォームのブロック図が示されている。図１に示されるように、システム１００は、複数のノード１１０₀〜１１０₂を含むHPCプラットフォームであってもよい。図解のために三つのノードしか示していないが、多くの実装では、数百または数千のノードが存在してもよいことを理解されたい。見て取れるように、各ノードは、複数のプロセッサを含め、さまざまな処理機能を含みうる。具体的には、各ノードは二つのプロセッサ・ソケット１１２₁〜１１２₂を含む。各プロセッサ・ソケットは、ローカル・メモリの一つまたは複数の部分に結合されていてもよい。ローカル・メモリは、ある実施形態では、動的ランダム・アクセス・メモリであってもよい。具体的には、プロセッサ１１２はローカル・メモリ１１４₁〜１１４₄に結合されていてもよい。図１の実装では、複数のPtPリンク１１５が、各プロセッサとノード・コントローラまたはネットワーク・インターフェース・コントローラ（NIC: network interface controller）１２０との間に設けられてもよい。そのようなリンク１１５での通信は、PtP通信プロトコルを介してであってもよく、この通信プロトコルのコヒーレント・ドメイン内であってもよい。

他のノード（図１には示さず）との通信を可能にするため、コヒーレンス・ドメイン１３０（たとえば、相手先ブランド製品製造業者（OEM: original equipment manufacturer）の）が設けられてもよく、各NIC １２０との通信が相互接続１２５によって生起してもよい。これらの相互接続は今度は相互接続または所与のOEMのファブリックのようなファブリック１３５に結合してもよい。

図２は、同様の多ノードHPCプラットフォームを示している。しかしながら、図２の実装では、システム１００′は、ノード内のプロセッサ・ソケットどうしを直接結合させうるPtP相互接続１１５を含む。他の点ではシステム１００′は図１に関して上で論じたものと同様の構成であってもよい。

諸実施形態は、HPCまたは他のプラットフォームのノード内のPtPリンクにおいて使用されるPtPプロトコルの最適な利用のための備えをしてもよい。具体的には、リモート・コンピューティング・ノード間での非常の小さなデータ語（たとえば8バイト）のデータ転送トランザクション（読み出しまたは書き込み）は、プロセッサまたは他のエージェントをNICに接続するリンク上での帯域幅利用を最大にしつつ、実行されることができる。

本発明の範囲はこの点に関して限定されるものではないが、削減データ・ペイロード・サイズを使って実装されうるリモート・メモリ動作は、部分メモリ読み出しおよび書き込みならびにAMOを含む。ある実施形態では、読み出しトランザクションを開始するために、非コヒーレントな部分読み出しコマンド（NcRdPtl: non-coherent partial read command）セマンティクスが使用されることができ、（たとえば）8バイトのデータ戻りパケットの受領につながりうる。これは本稿ではDataNc8と称される。ある実施形態では、削減データ・ペイロードを示すフィールドをもつ書き込み結合部分的書き込みコマンド（WcWrPtl: write combining partial write command）セマンティクスを使って、部分的メモリ書き込みが実装されることができる。

ある実施形態では、AMOは、（たとえば）8バイトのオペランドを、要求された動作と一緒に、リモートのエージェントに送付するために使われることができる。リモートのエージェントは第二のオペランドを（たとえば該リモートのエージェントに付随する）メモリから読んでもよい。あるそのような実施形態では、メモリに付随するメモリ・コントローラが要求された動作を、二つのデータ・オペランドを使って実行し、結果を直接メモリに書き戻してもよい。ある実施形態では、この動作のために、非コヒーレントな入出力書き込みコマンド（NcIOWr: non-coherent input/output write command）セマンティクスを使うことができる。

これらの動作を可能にするために、ある種のパケットのヘッダ部分におけるフィールドが、たとえば数万のノードにおける分散された（distributed）メモリにアドレッシング機能を拡張し、個々のスレッド通信をより効率的に管理するために、使用されることができる。

ここで図３を参照すると、本発明のある実施形態に基づく例示的なデータ・パケットが示されている。図３に見られるように、データ・パケット１５０はコマンド・ヘッダおよびデータ部分を含む。これは、本発明のある実施形態に基づく極小サイズのデータ・パケットであってもよく、トランザクションに関連する種々の情報を示すためのさまざまなフィールドを含んでいてもよい。コマンド・ヘッダのフォーマットとしては、一組のレーンが示されている。各レーンは、二つのエージェント間のシリアル相互接続の個々の差動対（differential pair）上で通信されてもよい。図３に示した実施形態では、データ情報の18本のレーンが設けられており、それに加えてチェックサム情報、たとえば巡回冗長チェックサム（CRC: cyclic redundancy checksum）を提供するための２本のチェックサム・レーンがある。図３でさらに見られるように、コマンド・ヘッダは２フリットであってもよく、各フリットは複数の20ビット部分から形成されていてもよい。該20ビット部分はフィット（phit）または物理層ユニット（physical layer unit）と称される。

見て取れるように、トランザクションに関する詳細を与えるために、さまざまな情報が存在している。にもかかわらず、これらのフィールドの一部のみが以下で詳細に論じられる。種々のフィールドに格納されるそのような情報は、アドレッシング、トランザクション・エンコード（オペコードとも称されるオペレーション・コードによる）、仮想チャネル情報などに関する情報を含んでいてもよい。さらに、諸実施形態は、実行されるべき個別的なコマンドに関する、たとえば所与の通信プロトコルの標準的なペイロードよりも小さなデータ・ペイロードをもって実行されるべきオペレーションのための、情報を提供する第二のまたは追加的なオペレーション・コード・フィールドを含んでいてもよい。ある実施形態では、このフィールドは、受信エージェント（たとえば、プロセッサからの要求を受け取るNICまたはパケットの実際の宛先）によって実行されるべきプロセッサ固有オペレーションを指定するための3ビット・フィールドであってもよい。加えて、（たとえばNICからプロセッサまたは他のエージェントにコマンドを送るために使用可能な）個別的なOEMコマンドに関する情報を含めるためのさらにもう一つのオペレーション・コード・フィールドが設けられてもよい。ある実施形態では、このOEMによって定義されるコマンド・フィールドは、プロセッサに対してコマンドを指定する、NICのようなOEMデバイスによって設定される3ビット・フィールドであってもよい。ある実施形態では、このフィールドは、プロセッサまたは他のエージェントからNICまたは他のOEMデバイスに送られるメッセージについて、0の値に設定されてもよい。このように、図３は二組のオペコードを示している。つまり、さまざまなQPIコマンド型を表すために使用される通常のオペコード[3:0]と、GSAストア、GSAプリフェッチおよびAMOの間の区別をするために使われるHPCオペコード[3:0]である。これら三つのオペレーションはすべて、通常のオペコードの同じコマンドを使ってもよいが、GSAストア、GSAプリフェッチおよびAMOの間の区別をするために異なるHPCオペコード・フィールドが使われる。

さらに、上で論じたように、非常に多数の相互接続されたノードのアドレッシングを可能にするために、コマンド・ヘッダ内に、拡張されたアドレッシング情報（たとえばアドレス・ビット63:51）が存在してもよい。諸実施形態はさらに、よりよいスレッド・レベル管理を可能にするためのさまざまな情報のためのフィールドを含んでいてもよい。そのようなスレッド・ベースのフィールドは、要求を発するプロセッサ・コアの識別子（ID）を指定するコア識別子（たとえば6ビット）を含んでいてもよい。ある実施形態では、このフィールド情報は、要求のソースを追跡するために、受信エージェント（NICのような）によって使用されてもよい。もう一つのそのようなフィールドは、要求を発したプロセッサ・コア上で走っているスレッドのIDを指定するスレッド識別子（たとえば5ビット）を含んでいてもよい。ここでもまた、このフィールドはNICまたは他の受信エージェントによって、要求のソースを追跡するために使用されてもよい。さらにまた、特権レベル（たとえば2ビット）が、コア上で走っているスレッドの特権レベルの指標を与えてもよい。

いくつかの実施形態では、異なるコマンド・ヘッダ・フォーマットは、図３に示されたような長さフィールドの代わりに、データ部分の複数のバイトのうちのどれが有効にされるべきかを示すバイト・イネーブル・フィールドを含んでいてもよい。さらにまた、他のデータ・パケット・フォーマットは、（たとえば8バイト以下で形成される）単一フリット・データ部分を伴う単一フリットであるコマンド・ヘッダを有していてもよい。そのようなデータ・パケットは、限られたデータ量（たとえば8バイト以下）に対する読み出し要求に応答するデータを提供するための応答または戻りメッセージとして使用されることができる。

下記の表１は、プロセッサ固有およびOEM固有のエンコードのための例示的なエンコードを示している。そのそれぞれは、コマンド・ヘッダ内の別個のフィールドであっても（かつ当該通信プロトコルのトランザクションのための標準エンコードに加えてであっても）よい。

諸実施形態は、このように、原子的メモリ・オペレーションおよび他のオペレーションに加えて読み出しおよび書き込み要求のようなメモリ・アクセス・トランザクションを含む種々の型のトランザクションを実行するために使用されうる。そのような他のオペレーションは、HPCプロセッサのようなプロセッサが所与の通信プロトコルによって通常サポートされていないトランザクションを実行することを可能にするプロセッサ固有動作を含んでいてもよい。例として、そのようなトランザクションは、リモート・ノードからの短いデータ項目にアクセスすること、リモート・エージェントにおけるデータに対して原子的にオペレーションを実行すること、あるいはリモート・エージェントから要求の開始者により近い何らかの記憶位置にデータをフェッチすることを含んでいてもよい。さらに、諸実施形態は、OEM固有トランザクションが生起することを可能にしてもよい。すなわち、たとえばOEM固有のオペレーション・コード・フィールドの個別的なエンコードは、OEMが所与の通信プロトコルによって同様にサポートされていない固有のトランザクションを実行することを可能にしてもよい。

図４を参照するに、本発明のある実施形態に基づくメモリ・アクセス・トランザクションを実行する方法の流れ図が示されている。図４に示されるように、方法２００は、たとえば、コヒーレントPtPプロトコルのような所与の通信プロトコルに従うリンクを介してNICのような他のエージェントと通信するシステム・エージェントによって実装されてもよい。方法２００は、最小限のデータ量に対するメモリ・トランザクションの要求を受信することによって始まってもよい（ブロック２１０）。すなわち、たとえばプロセッサ・コアからの要求が、少量のデータ、つまり通信プロトコルについての標準的なデータ・ペイロード・サイズより小さい量のデータを、ロードまたはストアすることであってもよい。

菱形２２０では、この量のデータが閾値以下であるかどうかが判定されてもよい。本発明の範囲はこの点で限定されるものではないが、ある実施形態では、この閾値は8バイトであってもよい。このようにして、トランザクションに関連するデータ量が8バイト以下であれば、メモリ・アクセス・トランザクションは最小限の量のフリット（通信プロトコルの通常のトランザクションのためよりも少数のフリット）をもって行われることができる。菱形２２０において量が閾値未満でないと判定される場合、制御はブロック２３０に移る。ここでは、標準的なメモリ・トランザクション・オペコードを含むトランザクションのためのパケットが生成されうる。こうして、トランザクションは、標準的な通信プロトコルの処理フローに従って、送られ、処理される。

そうではなく、菱形２２０において、データ量が閾値以下であると判定される場合、制御はブロック２４０に移る。ブロック２４０では、標準的なメモリ・トランザクション・オペコードおよび最小限のデータ・ペイロードの存在を示す特殊なオペコードの両方を含むトランザクションのためのパケットが生成されてもよい。次いで制御は菱形２５０に移り、ここではトランザクションが書き込み要求についてであるかどうかが判定される。もしそうであれば、制御はブロック２６０に移り、ここで、最小限のデータ・ペイロードを含むパケットが送信されてもよい（ブロック２６０）。たとえば、データ部分が8バイト以下であるとすると、このメモリ・トランザクションのためのパケットはたったの２フリットであってもよい（１フリットのヘッダと１フリットのデータ・ペイロード）。対照的に、例示的な通信プロトコルについて、典型的な書き込みトランザクション・データ・パケットは８フリットであることがある。パケットが送信されて宛先によって適切に処理されたのち、エージェントは完了パケットを受信してもよい（ブロック２７０）。

引き続き図４を参照するに、そうではなくて菱形２５０において、要求が読み出し要求であると判定される場合、制御はブロック２８０に移り、ここで、読み出し要求が送信されてもよい。次いで、データが宛先位置から読み出されたとき、エージェントは最小限のペイロード・パケットにおいて要求されたデータを受信しうる（ブロック２９０）。上記の例を参照するに、このパケットは最小限のサイズ（たとえば２フリット）の非コヒーレント読み出し完了であってもよい。

他の諸実施形態は、オペレーションの少なくとも一つのオペランドも所与の通信プロトコルについての標準的なペイロードに比べて限られたサイズである原子的メモリ・オペレーションを実行するために使用されてもよい。ここで図５を参照するに、本発明のもう一つの実施形態に基づく方法の流れ図が示されている。図５に示されるように、方法３００は、第一のエージェントにおいて原子的なメモリ・オペレーションの要求を受領することによって始まりうる。一例として、この要求は、リモート・ノードのエージェントから第一のノードのホーム・エージェントにおいて受領されうる。より具体的には、要求はリモート・ノードから送信され、ローカル・ノードのたとえばNICに与えられてもよく、該NICが今度はその要求をホーム・エージェントに与えてもよい。ある実施形態では、この要求は第一のオペランド、もう一つのオペランドの位置の指示および所与の算術演算のような要求されるオペレーションを含んでいてもよい。次に、メモリ・コントローラが要求されたオペレーションを実行できるかどうかが判定されてもよい（菱形３１５）。すなわち、いくつかの実装では、ノードのローカル・メモリに結合されたメモリ・コントローラが、要求されたオペレーションを実行できる算術論理ユニット（ALU: arithmetic logic unit）のような一つまたは複数の実行ユニットを有していてもよい。図５はこの判定を示しているものの、諸実施形態は、その代わりに、この判定をすることなく、要求をメモリ・コントローラに与えるか、ホーム・エージェント内でオペレーションを処理するかしてもよい。

メモリ・コントローラがそのオペレーションを実行できないと判定された場合、制御はブロック３２０に渡され、ここで、第二のオペランドを取得するためにメモリ・アクセス要求がメモリ・コントローラに送られてもよい。次いで第二のオペランドがメモリ・コントローラから受信されてもよく（ブロック３２５）、こうしてホーム・エージェントが要求されたオペレーションを実行してもよい（ブロック３３０）。要求は原子的なメモリ・オペレーションに応答するので、要求元エージェントへの戻り通信は必要とされないことを注意されたい。オペレーションは第一のノードにおいて直接実行されることができるからである。

その代わりにメモリ・コントローラがそのオペレーションを処理するサポートをもつと判定された場合には、制御は菱形３１５からブロック３４０に渡され、ここで、メモリ・アクセス要求、第一のオペランドおよび要求されたオペレーションがメモリ・コントローラに送られうる。こうして、メモリ・コントローラはメモリから第二のオペランドを取得し、オペレーションを実行しうる（ブロック３４５）。

制御はブロック３３０および３４５からブロック３５０に渡され、オペレーションの結果が、要求元エージェントへのいかなる結果の戻り通信も必要とすることなく、直接、オペレーションの結果がメモリに記憶される。この時点で、オペレーションは完了し、完了メッセージがリモート・エージェントに送り返されてもよい（ブロック３６０）。図５の実施形態ではこの特定の実装をもって示されているが、本発明の範囲はこの点に関して限定されるものではない。

図６〜図８は、種々の実施形態に基づくオペレーションを処理するための例示的なフローを示している。図６は、GSAロード（リモート・ノードからのデータの読み込み）のためのトランザクション・フローを描いており、図７は、リモート・ノードにおけるAMOオペレーションのためのトランザクションを描いており、図８はGSAプリフェッチ（リモート・ノードからのデータのプリフェッチ）のためのトランザクションを描いている。これらの図は、記述される実施形態にとって重要でないフローの詳細は含んでいないことを注意しておく。見て取れるように、これらのファインマン図はローカル／要求元ノードにおけるプロトコル・エージェントのセットおよび宛先またはホーム・メモリ・ノードにおけるセットを示している。これらのエージェントは、データをキャッシュできるエージェントであるキャッシング・エージェント、リンク・メッセージを生成できるリンク層のようなリンク・エージェント、ソース（source）および宛先（destination）ノードにおけるNIC、ホーム・エージェント（これはメモリのターゲットにされる領域を所有するエージェントである）およびメモリ・コントローラである。

図６を参照するに、リモート８バイト読み込みのためのフローが示されている。見て取れるように、要求元のキャッシング・エージェントは読み取り要求をローカルNIC（SrcNIC）に送付し、ローカルNICは今度はその要求をリモートNIC（DestNIC）に送付する。このNICはその要求をホーム・エージェントに送付する。今度は、ホーム・エージェントはローカルなスヌープ（snooping）を実行し（もし必要とされるなら）、メモリ読み出しも実行する。これに関し、ホーム・エージェントはこのように非コヒーレントなメモリ・アクセス要求（NcRdPtl）セマンティックを使用してNICがリンク上でのコヒーレンス・チェックを実行する必要を回避し、（スヌープ・オペレーションのため）この要求をコヒーレントなメモリ要求に変換することを受け持つことを注意しておく。したがって、諸実施形態は、非コヒーレントな要求セマンティクスを使う要求に応答してコヒーレントなオペレーションを実行する機能を提供する。

引き続き図６を参照するに、メモリからのデータ読み出しは次いで、要求と同じ経路を通じて要求元のキャッシング・エージェントに送り返される。限られたデータ・サイズのパケットのために本発明のある実施形態に基づく特別なオペレーション・コードを使うことによって、読み出し要求およびデータ戻りメッセージが限られたペイロードのパケットをもって送られることができ、標準的な通信プロトコルに基づく全２１フリットに代わって要求経路のために４フリット、戻り経路のために４フリットだけを使うことを注意しておく。

図７を参照するに、リモートのホーム・エージェントへの８バイト書き込みのためのフローが示されている。この書き込みフローは、小さなサイズ（たとえば３フリット）の非コヒーレントなIO書き込みトランザクション（NcIOWr）セマンティクスによってであってもよい。さらに見て取れるように、完了メッセージがソースNICから直接、リモート・エージェントのメモリ・コントローラにおいて完全なメモリ・トランザクションが完了するのを待つことなく、キャッシング・エージェントに送り返されてもよい。ここでもまた、削減されたデータ・ペイロードをもつ書き込み要求を送るために削減された数のフリットが使用されることができる。また、同様のフローが原子的なメモリ・オペレーションのために使用されてもよく、よって、リモートのホーム・エージェントからリモート・ノードのキャッシング・エージェントおよびメモリ・コントローラへの指示は、原子的なメモリ・オペレーションを実行するための可能なトランザクションを示す。

ここで図８を参照するに、リモート・ノードへの８バイト・プリフェッチのためのフローが示されている。ここでは、先述したような要求されたデータは、要求元により近い記憶位置にプリフェッチされうる。必ずしも要求元プロセッサのキャッシュにではない。見て取れるように、要求元ノードでのこのプリフェッチは、同様に、非コヒーレントなI/O書き込み要求セマンティクスを介してであってもよい。ここでもまた、完了が、プリフェッチ要求の受領に際してソースNICによって直接生成されてもよいことを注意しておく。これは、キャッシング・エージェントがこの要求によって使われたいかなる資源をも早期に解放し、前記近いNICでの記憶へのデータ戻りが行われる間、関係ない処理を続けることを可能にする。使用される特別なオペレーション・コードのため、より小さなデータ・ペイロード、つまり８バイトのデータ戻りメッセージ（２フリットのメッセージ）のための戻りが実現されることを注意しておく。上記の例ではこれらの特定のフローをもって示されているが、本発明の範囲は、転送のサイズに関しても記憶要素の位置に関してもこれに限定されるものでないことを理解されたい。

ここで図９を参照するに、本発明のある実施形態に基づくプロセッサのブロック図が示されている。上で論じたように、諸実装は、HPCプロセッサを含むHPCシステムに組み込まれてもよい。このプロセッサは、コア論理４１０として図９に概括的に表現されている複数のコアを含んでいてもよい。たとえば、各コアは、低レベル・キャッシュ・メモリのようなプライベートなキャッシュ・メモリに関連付けられていてもよい。これらのプライベート・キャッシュ・メモリは今度は、たとえばインクルーシブな（inclusive）キャッシュ階層構造として、共有されるキャッシュ・メモリに結合されていてもよい。ただし、本発明の範囲はこの点に関して限定されるものではない。

図９においてさらに見て取れるように、プロセッサ４００はさらに、相互接続論理４３０を含んでいてもよい。そのような相互接続論理は、所与の通信プロトコルに基づく論理であってもよく、さらにそのようなプロトコルに対する拡張、たとえばそのプロトコルについての標準よりも小さなデータ・ペイロードをもつデータ・パケットの送信または通信プロトコルによってサポートされていないプロセッサもしくはOEM固有のコマンドの送信を扱うための備えをしていてもよい。図９に表されているように、そのような論理はパッケージ生成論理４３２を含んでいてもよい。これは、コアから要求を受領してプロセッサを他のエージェントに結合する一つまたは複数の相互接続上での送信のためのパケットを生成するリンク層論理であってもよい。そのような論理は、たとえばメモリ・アクセス・トランザクションのために、単一データ・パケットのための複数のオペレーション・コードを有するパケットの通信を可能にしうる。該複数のオペレーション・コードのうちの一つは標準的なオペレーション・コードであり、第二はこのトランザクションを扱うための特別な情報を与えるもの、たとえばそのパケットのペイロード部分のより小さなサイズを指示するものまたは原子的メモリ・オペレーションのような特定の要求を与えるものである。

パッケージ生成論理４３２には、パケット送信論理４３４が結合されていてもよい。これは、生成されたパケットを受けて、これを前記相互接続に沿った電気通信のためにフォーマットする物理層論理であってもよい。図解の簡単のために示されていないが、パケット送信論理４３４およびパケット生成論理４３２はいずれも、相互接続（単数または複数）からのはいってくるパケットを受領し、その情報を処理してプロセッサの前記一つまたは複数のコアに与える、対応する受信論理および変換論理を有していてもよいことを理解されたい。図９の実施形態ではこの高レベルのビューで示されているが、本発明の範囲はコン点に関して限定されるものではないことを理解されたい。

諸実施形態は、コードにおいて実装されてもよく、命令が記憶されている記憶媒体上に記憶されていてもよい。該命令は、該命令を実行するようシステムをプログラムするために使うことのできるものである。記憶媒体は、これに限られないが、フロッピー（登録商標）ディスク、光ディスク、半導体ドライブ（SSD: solid state drive）、コンパクトディスク読み出し専用メモリ（CD-ROM: compact disk read-only memory）、書き換え可能型コンパクトディスク（CD-RW: compact disk rewritable）および光磁気ディスク、読み出し専用メモリ（ROM: read-only memory）、動的ランダム・アクセス・メモリ（DRAM: dynamic random access memory）、静的ランダム・アクセス・メモリ（SRAM: static random access memory）のようなランダム・アクセス・メモリ（RAM: random access memory）、消去可能型プログラム可能読み出し専用メモリ（EPROM: erasable programmable read-only memory）、フラッシュメモリ、電気的消去可能型プログラム可能読み出し専用メモリ（EEPROM: electrically erasable programmable read-only memory）のような半導体デバイス、磁気もしくは光カードまたは電子的な命令を記憶するのに好適な他の任意の型の媒体を含みうる。

本発明は限られた数の実施形態に関して記載されてきたが、当業者はそれから数多くの修正および変形を理解するであろう。付属の請求項は本発明の真の精神および範囲内にはいるそのようなすべての修正および変形をカバーすることが意図されている。

１００ システム
１１０ ノード
１１２ プロセッサ
１１４ ローカル・メモリ
１１５ ポイントツーポイント（PtP）・リンク
１２０ ネットワーク・インターフェース・コントローラ（NIC）
１３０ コヒーレンス・ドメイン
１５０ データ・パケット
２１０ 極小量のデータのメモリ・トランザクションの要求を受信
２２０ データ量は閾値以下か？
２３０ メモリ・トランザクション・オペコードを含むトランザクション用パケットを生成
２４０ メモリ・トランザクション・オペコードおよび極小データ・ペイロードのための特殊オペコードを含むトランザクション用パケットを生成
２５０ 書き込み要求？
２６０ 極小データ・ペイロードを含むパケットを送信
２７０ パケットが宛先に到着したのち完了を受信
２８０ パケットを送信
２９０ 極小ペイロードにおいて要求したデータを受信
３１０ 第一のオペランド、第二のオペランドの位置および要求された動作を含む、リモート・エージェントからの原子的メモリ動作のための要求を第一のエージェントにおいて受信
３１５ メモリ・コントローラは要求された動作を実行する機能があるか？
３２０ 第二のオペランドを得るためにメモリ・コントローラにメモリ・アクセス要求を送る
３２５ メモリ・コントローラから第二のオペランドを受信
３３０ 第一のエージェントにおいて動作を実行
３４０ メモリ・アクセス要求、第一のオペランドおよび要求動作をメモリ・コントローラに送る
３４５ メモリ・コントローラにおいて動作を実行
３５０ 結果をメモリに格納
３６０ 完了メッセージをリモート・エージェントに送る

Claims (16)

1. リモート・エージェントから第一のエージェントにおいて原子的メモリ・オペレーションの要求を受信する段階であって、前記要求は第一のオペランド、前記原子的メモリ・オペレーションのためのオペコードおよび第二のオペランドへのアクセスを可能にするアドレスを含む、段階と；
   前記要求に応答して、前記第二のオペランドを取得するために、前記第一のエージェントからメモリに結合されたメモリ・コントローラにメモリ・アクセス要求を送る段階と；
   前記第一のエージェントおよび前記メモリ・コントローラのうちの一方において前記第一および第二のオペランドに対して前記原子的メモリ・オペレーションのオペコードに応答してオペレーションを実行して結果を得る段階であって、前記第二のオペランドは前記第一のエージェントと前記リモート・エージェントの間のリンクの通信プロトコルに基づくデータ部分のサイズより小さなサイズであり、前記要求は前記通信プロトコルについてのデータ・パケット・サイズよりも小さなサイズをもつデータ・パケットにおいて受領される、段階と；
   前記結果を前記メモリに記憶する段階とを含む、
   方法。
2. 前記結果が前記メモリに記憶されたのち、前記第一のエージェントから前記リモート・エージェントに完了メッセージを送る段階を更に含む、請求項１記載の方法。
3. 前記結果が前記リモート・エージェントに通信されない、請求項２記載の方法。
4. 前記第二のオペランドが前記リモート・エージェントに通信されない、請求項２記載の方法。
5. 請求項１記載の方法であって、当該方法は、前記オペレーションを前記メモリ・コントローラにおいて実行することをさらに含み、前記メモリ・コントローラは前記オペレーションを実行する論理ユニットを含み、当該方法は、前記第一のオペランドおよび前記原子的メモリ・オペレーションのオペコードを前記第一のエージェントから前記メモリ・コントローラに送ることをさらに含み、前記第二のオペランドは前記第一のエージェントと前記リモート・エージェントの間のリンクの通信プロトコルに基づくデータ部分のサイズより小さなサイズであり、前記要求は前記通信プロトコルについてのデータ・パケット・サイズよりも小さなサイズをもつデータ・パケットにおいて受領される、方法。
6. プロセッサを有する装置であって、
   前記プロセッサは該プロセッサとエージェントの間に結合された、ある通信プロトコルに基づくリンク上での送信のためにデータ・パケットを生成するリンク論理を含み、前記リンク論理はコマンド部分を有する第一のデータ・パケットを生成し、前記コマンド部分は、前記第一のデータ・パケットのトランザクション種別をエンコードする第一のオペレーション・コードおよび前記エージェントに結合された宛先エージェントによって実行されるべきプロセッサ固有オペレーションをエンコードする第二のオペレーション・コードを含み、
   前記リンク論理が、前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズをもつデータ部分をもつ前記第一のデータ・パケットを生成し、前記より小さなサイズのデータ部分を同定するために前記第二のオペレーション・コードを設定する、
   装置。
7. 前記リンク論理が、前記通信プロトコルに基づくデータ・パケットについてのフロー制御ユニットの数よりも少ない数のフロー制御ユニットをもつ前記第一のデータ・パケットを送信する、請求項６記載の装置。
8. 前記第二のオペレーション・コードが前記宛先エージェントに、メモリからデータを取得して、戻りデータ・パケットを介して該データを前記プロセッサに通信することをさせ、前記戻りデータ・パケットは前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズをもつデータ部分をもつ、請求項６記載の装置。
9. 前記第二のオペレーション・コードは、前記宛先エージェントに、前記第一のデータ・パケットのデータ部分のデータを前記宛先エージェントに関連付けられたメモリ中に書き込ませることをさせ、前記データ部分は前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズをもつ、請求項６記載の装置。
10. 前記第二のオペレーション・コードは、前記宛先エージェントに、第二のオペランドを取得するためにメモリ・アクセス要求を、メモリに結合されたメモリ・コントローラに送り、前記第一のデータ・パケットのデータ部分に含まれていた第一のオペランドおよび前記第二のオペランドに対して前記第二のオペレーション・コードに応答してオペレーションを実行して結果を取得し、該結果を前記メモリに記憶することをさせる、請求項６記載の装置。
11. 請求項１０記載の装置であって、前記第二のオペレーション・コードは、前記宛先エージェントに、前記結果が前記メモリに記憶されたのちに前記プロセッサに完了メッセージを送ることをさせる、装置。
12. 前記第一のオペレーション・コードはメモリ・アクセス・トランザクションを指示し、前記第二のオペレーション・コードは前記メモリ・アクセス・トランザクションのデータが前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズであることを指示する、請求項６記載の装置。
13. 請求項１２記載の装置であって、前記メモリ・アクセス・トランザクションが非コヒーレント・トランザクションであり、前記宛先エージェントが該非コヒーレント・トランザクションをコヒーレント・トランザクションに変換し、該コヒーレント・トランザクションに応答してコヒーレントな処理を実行する、装置。
14. 第一のプロセッサと、第一のNICと、第二のNICと、第二のプロセッサとを有するシステムであって、
    前記第一のプロセッサは、前記第一のプロセッサと前記第一のネットワーク・インターフェース・コントローラ（NIC）との間に結合された、ある通信プロトコルに基づく第一のリンク上での送信のためにデータ・パケットを生成するリンク論理を有し、前記リンク論理はコマンド部分を有する第一のデータ・パケットを生成し、前記コマンド部分は、前記第一のデータ・パケットのトランザクション種別をエンコードする第一のオペレーション・コードおよび前記第二のプロセッサによって実行されるべきプロセッサ固有オペレーションをエンコードする第二のオペレーション・コードを含み；
    前記第一のNICは前記第一のリンクを介して前記第一のプロセッサに結合されており；
    前記第二のNICはファブリックを介して前記第一のNICに結合されており；
    前記第二のプロセッサは前記第二のNICに結合されており、前記第一のデータ・パケットを受信して、前記第一および第二のオペレーション・コードに応答して前記プロセッサ固有オペレーションを実行し、
    前記リンク論理は、前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズをもつデータ部分をもつ前記第一のデータ・パケットを生成し、前記より小さなサイズのデータ部分を同定するために前記第二のオペレーション・コードを設定する、
    システム。
15. 前記第二のオペレーション・コードが前記第二のプロセッサに、メモリからデータを取得して、戻りデータ・パケットを介して該データを前記第一のプロセッサに通信することをさせ、前記戻りデータ・パケットは前記通信プロトコルに基づくデータ部分のサイズよりも小さなサイズをもつデータ部分をもつ、請求項１４記載のシステム。
16. 前記第二のオペレーション・コードは、前記第二のプロセッサに、第二のオペランドを取得するためにメモリ・アクセス要求を、メモリに結合されたメモリ・コントローラに送り、前記第一のデータ・パケットに含まれていた第一のオペランドおよび前記第二のオペランドに対して前記第二のオペレーション・コードに応答してオペレーションを実行して結果を取得し、該結果を前記メモリに記憶することをさせ、前記第二のプロセッサに、前記結果が前記メモリに記憶されたのち、前記第一のプロセッサに前記第二のオペランドや前記結果を通信することなく、前記第一のプロセッサに完了メッセージを送ることをさせる、請求項１４記載のシステム。

Images