(57)【要約】  データ処理システム及びデータ処理の方法が提供される。このシステムは、第１及び第２のデータ処理エージェントと、両データ処理エージェント間にコヒーレントに共有され、両データ処理エージェント間にメッセージ・チャネルを提供するメッセージ・データ構造を格納するデータ・ストレージとを備える。追加のデータ・ストレージは、メッセージ・チャネルのメッセージ・ステータス情報を提供するメッセージ・チャネル・メタデータを格納するために、両データ処理エージェントにアクセスできる。メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つであり、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する。
2020537235.tif 000002
【特許請求の範囲】
【請求項１】
第１のデータ処理エージェント及び第２のデータ処理エージェントと、
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間にコヒーレントに共有され、前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間にメッセージ・チャネルを提供する１つ又は複数のメッセージのメッセージ・データ構造を格納するデータ・ストレージと、
前記第１のデータ処理エージェント及び前記第２のデータ処理エージェントにアクセス可能であり、メッセージ・チャネル・メタデータを格納する、追加のデータ・ストレージであって、前記メッセージ・チャネル・メタデータは、前記メッセージ・チャネルのメッセージ・ステータス情報を提供し、前記メッセージ・チャネル・メタデータは、前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、追加のデータ・ストレージとを備え、
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いて前記メッセージ・チャネルを確立する、データ処理システム。
【請求項２】
前記データ処理システムは、メッセージ・インターフェース・データ構造を格納するように構成され、各メッセージ・インターフェース・データ構造は、前記データ・ストレージ及び前記追加のデータ・ストレージに確立された複数のメッセージ・チャネルを定義する、請求項１に記載のデータ処理システム。
【請求項３】
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとのうちの少なくとも一方は、前記初期化トリガに応答して、前記メッセージ・インターフェース・データ構造のための前記選択されたメッセージ・チャネル・タイプを選択することにより、前記複数のメッセージ・チャネルのための前記選択されたメッセージ・チャネル・タイプを定義する、請求項２に記載のデータ処理システム。
【請求項４】
前記データ処理システムは、複数のメッセージ・インターフェース・データ構造を格納するように構成され、前記複数のメッセージ・インターフェース・データ構造の各々のための前記選択されたメッセージ・チャネル・タイプは、独立して設定される、請求項３に記載のデータ処理システム。
【請求項５】
前記第１のデータ処理エージェント及び前記第２のデータ処理エージェントにアクセス可能な前記追加のデータ・ストレージは、前記データ処理システムにおけるハードウェア・デバイスにレジスタのセットを備え、前記レジスタのセットにメモリ・アドレスのセットがメモリ・マッピングされる、請求項１から４までのいずれか一項に記載のデータ処理システム。
【請求項６】
前記メモリ・アドレスのセットの少なくともサブセットは、前記データ処理システムにおける複数の場所にメモリ・マッピングされ、前記複数の場所のうちの少なくとも１つは、前記データ処理システムにおけるデータ処理デバイスに専用の周辺機器デバイスにある、請求項５に記載のデータ処理システム。
【請求項７】
前記メモリ・アドレスのセットの各アドレスは、前記データ処理システム内のそれぞれ固有の場所にメモリ・マッピングされる、請求項５に記載のデータ処理システム。
【請求項８】
前記それぞれ固有の場所は、前記データ処理システムにおける単一の周辺機器デバイス内にある、請求項７に記載のデータ処理システム。
【請求項９】
前記メモリ・アドレスのセットの少なくとも１つのアドレスは、前記データ処理システムにおける複数の周辺機器デバイス内の場所にメモリ・マッピングされ、前記複数の周辺機器デバイスは、前記レジスタのセットのコンテンツの一貫したコピーを保証するコヒーレンス・メカニズムを実装するように構成される、請求項５に記載のデータ処理システム。
【請求項１０】
前記レジスタのセットは、前記メッセージ・チャネル・メタデータを格納するための通知レジスタを備え、前記通知レジスタに格納された値は、前記メッセージ・チャネルの前記メッセージ・ステータス情報を提供し、前記ハードウェア・デバイスは、前記通知レジスタに格納された値の変更に応答して、前記メッセージ・チャネルに対して所定のアクションを実行する、請求項５から９までのいずれか一項に記載のデータ処理システム。
【請求項１１】
請求項２に従属する場合、前記レジスタのセットは、前記複数のメッセージ・チャネルにそれぞれ対応する複数の通知レジスタを備え、前記通知レジスタに格納された前記値は、前記メッセージ・チャネルの前記メッセージ・データ構造に格納された、選択されたメッセージを示す、請求項１０に記載のデータ処理システム。
【請求項１２】
請求項２に従属する場合、前記レジスタのセットは、前記メッセージ・チャネル・メタデータを格納するためのダイジェスト・レジスタを備え、前記ダイジェスト・レジスタに格納された値は、各それぞれのメッセージ・チャネルが、１つ又は複数の新たなメッセージを保持するための容量を現在有しているか否かを示す、前記複数のメッセージ・チャネルの各々の前記メッセージ・ステータス情報を提供する、請求項５から９までのいずれか一項に記載のデータ処理システム。
【請求項１３】
請求項２に従属する場合、前記レジスタのセットは、前記メッセージ・チャネル・メタデータを格納するための追加のダイジェスト・レジスタを備え、前記追加のダイジェスト・レジスタに格納された値は、各それぞれのメッセージ・チャネルが、１つ又は複数の新たなメッセージを現在保持しているか否かを示す、前記複数のメッセージ・チャネルの各々の前記メッセージ・ステータス情報を提供する、請求項５から９までのいずれか一項、又は請求項１２に記載のデータ処理システム。
【請求項１４】
前記ハードウェア・デバイスにおける前記レジスタのセットは、前記メッセージ・データ構造に関連付けられた構成データ構造を格納するように構成され、前記構成データ構造は、前記メッセージ・データ構造の使用パラメータを定義し、前記使用パラメータは、前記メッセージ・データ構造のインデクスを備え、前記ハードウェア・デバイスは、前記インデクスの変更に応答して、前記メッセージ・データ構造に関して所定のアクションを実行する、請求項５から１３までのいずれか一項に記載のデータ処理システム。
【請求項１５】
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとのうちの少なくとも一方は、前記データ処理システムで実行するソフトウェア・タスクである、請求項１から１４までのいずれか一項に記載のデータ処理システム。
【請求項１６】
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとのうちの少なくとも一方は、前記データ処理システムにおけるハードウェア・エージェントである、請求項１から１５までのいずれか一項に記載のデータ処理システム。
【請求項１７】
前記メッセージ・データ構造は、メッセージの順序付けされたキューである、請求項１から１６までのいずれか一項に記載のデータ処理システム。
【請求項１８】
前記メッセージ・チャネルは、前記第１のデータ処理エージェントから前記第２のデータ処理エージェントへの一方向メッセージ送信を提供する、請求項１から１７までのいずれか一項に記載のデータ処理システム。
【請求項１９】
第１のデータ処理エージェントを操作することと、
第２のデータ処理エージェントを操作することと、
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間にコヒーレントに共有されたデータ・ストレージに、１つ又は複数のメッセージのメッセージ・データ構造を格納することと、
前記第１のデータ処理エージェント及び前記第２のデータ処理エージェントにアクセス可能な追加のデータ・ストレージに、メッセージ・チャネル・メタデータを格納することであって、前記メッセージ・チャネル・メタデータは、前記メッセージ・チャネルのメッセージ・ステータス情報を提供し、前記メッセージ・チャネル・メタデータは、前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納することと、
初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いて前記メッセージ・チャネルを確立することとを備える、データ処理の方法。
【請求項２０】
第１のデータ処理エージェントを操作する手段と、
第２のデータ処理エージェントを操作する手段と、
前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間にコヒーレントに共有され、１つ又は複数のメッセージのメッセージ・データ構造を格納する手段と、
前記第１のデータ処理エージェント及び前記第２のデータ処理エージェントにアクセス可能な、メッセージ・チャネル・メタデータを格納する手段であって、前記メッセージ・チャネル・メタデータは、前記メッセージ・チャネルのメッセージ・ステータス情報を提供し、前記メッセージ・チャネル・メタデータは、前記第１のデータ処理エージェントと前記第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納する手段と、
初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いて前記メッセージ・チャネルを確立する手段とを備える、データ処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本開示は、データ処理に関する。より詳細には、データ処理システムにおけるメッセージ受渡しに関する。
【背景技術】
【０００２】
データ処理システムでは、メッセージを交換することによって互いに通信するために、いくつかの別個のデータ処理エージェントが必要になる場合がある。これらメッセージには、コマンド、確認応答、委任された処理のデータなど、アプリケーションに応じて様々なコンテンツが含まれる場合がある。これらメッセージは、発信元のエージェントによって作成され、たとえば共有メモリにおけるリング・バッファを利用して、宛先のエージェントによって取得されるキューに格納される。このようなキューを管理するには、様々な手法がある。
【発明の概要】
【課題を解決するための手段】
【０００３】
１つの実例の実施例では、第１のデータ処理エージェント及び第２のデータ処理エージェントと、第１のデータ処理エージェントと第２のデータ処理エージェントとの間にコヒーレントに共有され、第１のデータ処理エージェントと第２のデータ処理エージェントとの間にメッセージ・チャネルを提供する１つ又は複数のメッセージのメッセージ・データ構造を格納するデータ・ストレージと、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能であり、メッセージ・チャネル・メタデータを格納する、追加のデータ・ストレージであって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、追加のデータ・ストレージとを備え、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する、データ処理システムがある。
【０００４】
別の実例の実施例では、第１のデータ処理エージェントを操作することと、第２のデータ処理エージェントを操作することと、第１のデータ処理エージェントと第２のデータ処理エージェントとの間にコヒーレントに共有されたデータ・ストレージに、１つ又は複数のメッセージのメッセージ・データ構造を格納することと、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能な追加のデータ・ストレージに、メッセージ・チャネル・メタデータを格納することであって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納することと、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立することとを備える、データ処理の方法がある。
【０００５】
別の実例の実施例では、第１のデータ処理エージェントを操作する手段と、第２のデータ処理エージェントを操作する手段と、第１のデータ処理エージェントと第２のデータ処理エージェントとの間にコヒーレントに共有され、１つ又は複数のメッセージのメッセージ・データ構造を格納する手段と、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能な、メッセージ・チャネル・メタデータを格納する手段であって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納する手段と、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する手段とを備える、データ処理システムがある。
【０００６】
本技術は、添付の図面に例示されているようなその実施例を参照して、単なる実例としてさらに説明される。
【図面の簡単な説明】
【０００７】
【図１】１つの実施例におけるデータ処理システムを概略的に例示する図である。
【図２】いくつかの実施例において、メモリ・マッピング、共有コヒーレント・メモリ、及び追加のストレージを使用して、メッセージ・データ構造及びメッセージ・チャネル・ステータス情報を格納する方法を概略的に例示する図である。
【図３Ａ】いくつかの処理要素に関連付けられた専用のローカル周辺機器デバイスにわたっていくつかのメモリ・マッピングされたレジスタ・アドレスのエイリアシングが存在する実施例におけるデータ処理システムを概略的に例示する図である。
【図３Ｂ】システムにおける複数の処理要素によって使用されるメモリ・マッピングされたレジスタ・アドレスが周辺機器デバイス内の固有の物理レジスタにマッピングする実施例におけるデータ処理システムを概略的に例示する図である。
【図４】いくつかの実施例において第１のタイプのメッセージ・チャネルがどのように提供されるかを概略的に例示する図であり、メッセージ・チャネルのメッセージを保持するメッセージ・データ構造は、共有コヒーレント・メモリに格納され、メッセージ・チャネルに関連付けられたすべてのメッセージ・チャネル・メタデータはアクセラレータ・ユニットの内部ストレージに格納される。
【図５】ソフトウェア・タスクが第１のタイプのチャネルを介してメッセージを送信するときに、いくつかの実施例で行われる一連のステップを示す図である。
【図６】ソフトウェア・タスクが第１のタイプのメッセージ・チャネルを介してメッセージを受信するときに、いくつかの実施例で行われる一連のステップを示す図である。
【図７】いくつかの実施例において第２のタイプのメッセージ・チャネルがどのように提供されるかを概略的に例示する図であり、メッセージ・チャネルのメッセージを保持するメッセージ・データ構造と、メッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの多くの両方が、共有コヒーレント・メモリに格納され、通知レジスタは、アクセラレータ・ユニットの内部ストレージで使用される。
【図８】ソフトウェア・タスクが第２のタイプのメッセージ・チャネルを介してメッセージを送信するときに、いくつかの方法の実施例で行われる一連のステップを示す図である。
【図９】ソフトウェア・タスクが第２のタイプのメッセージ・チャネルを介してメッセージを受信するときに、いくつかの方法の実施例で行われる一連のステップを示す図である。
【発明を実施するための形態】
【０００８】
少なくともいくつかの実施例は、第１のデータ処理エージェント及び第２のデータ処理エージェントと、第１のデータ処理エージェントと第２のデータ処理エージェントとの間でコヒーレントに共有され、第１のデータ処理エージェントと第２のデータ処理エージェントとの間にメッセージ・チャネルを提供する１つ又は複数のメッセージのメッセージ・データ構造を格納するデータ・ストレージと、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能であり、メッセージ・チャネル・メタデータを格納する、追加のデータ・ストレージであって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、追加のデータ・ストレージとを備え、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する、データ処理システムを提供する。
【０００９】
データ処理システムは、コヒーレントに共有されたデータ・ストレージ（たとえば、ＤＲＡＭなどのメモリ）を利用して、定義されたメッセージ・データ構造を格納し、第１及び第２のデータ処理エージェントの間のメッセージが格納され、第１及び第２のデータ処理エージェントの両方がアクセスを有する。メッセージは、多種多様な形式をとることができ、本開示全体を通して、一般に、１つのデータ処理エージェントが他のデータ処理エージェントに送信することを望むいくつかのタイプのデータであると単に見なすことができる。データ処理システムはさらに、第１及び第２のデータ処理エージェントの両方にアクセスでき、コヒーレントに共有されたデータ・ストレージに格納されたメッセージ・データ構造に関連付けられたメッセージ・チャネル・メタデータを格納するために使用される、追加のデータ・ストレージを提供する。第１及び第２のデータ処理エージェントの両方へのこのアクセス可能性は様々な手法で提供され得るが、いくつかの実施例では、これは追加のデータ・ストレージ内のメモリ・マッピングされたアドレスによって達成される。
【００１０】
データ処理システム用に定義され、データ処理システムにおけるデータ処理エージェント間のメッセージの通信のために確立される複数のメッセージ・チャネル・タイプがある。メッセージ・チャネル・メタデータは、メッセージ・チャネルのタイプに応じて形式及びコンテンツが異なる。メッセージ・チャネルは、データ処理システムにおいて（データ・ストレージ内のメッセージ・データ構造と、追加のデータ・ストレージ内の対応するメッセージ・チャネル・メタデータとのインスタンス化によって）動的に作成され得る。したがって、データ処理エージェント間の通信のためにデータ処理システムで確立されたメッセージ・チャネルは、システムの起動時に事前定義されていないが、データ処理システムのデータ処理アクティビティが必要なときに、メッセージ・チャネルが作成され得る（さらに、チャネルは、もはや必要とされない場合に停止され得る）。さらに、異なるタイプのメッセージ・チャネルは、そのタイプのメッセージ・チャネルをサポートするためのストレージ要件に関して、異なる要件を有する可能性がある。データ処理システムにおいて（様々な形式をとり得る適切なトリガに応じて）、新たなメッセージ・チャネルが確立されると、そのメッセージ・チャネルの要件とそれをサポートするために利用可能なリソースとに応じて、メッセージ・チャネル・タイプが選択される。
【００１１】
いくつかの実施例では、データ処理システムは、メッセージ・インターフェース・データ構造を格納するように構成され、各メッセージ・インターフェース・データ構造は、データ・ストレージ及び追加のデータ・ストレージに確立された複数のメッセージ・チャネルを定義する。したがって、いくつかのメッセージ・チャネルを、メッセージ・インターフェース・データ構造にまとめることができる。これにより、複数のメッセージ・チャネルの管理が容易になり、たとえば、メッセージ・チャネルのグループは、（１つのメッセージ・インターフェース・データ構造のインスタンス化によって）単一のアクションにおいて確立され、複数のメッセージ・チャネルの構成のために、メッセージ・インターフェース・データ構造のレベルで、その構成の選択によって一方的に適用されることが可能となる。
【００１２】
いくつかの実施例では、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、メッセージ・インターフェース・データ構造のために選択されたメッセージ・チャネル・タイプを選択することにより、複数のメッセージ・チャネルのために選択されるメッセージ・チャネル・タイプを定義する。したがって、一方的に確立できる複数のメッセージ・チャネルの１つの構成は、選択されたメッセージ・チャネル・タイプであり、メッセージ・インターフェース・データ構造が作成されると、メッセージ・インターフェース・データ構造の性質により、そのメッセージ・インターフェース・データ構造によって定義された複数のメッセージ・チャネルの各々のために選択されるメッセージ・チャネル・タイプを定義できる。
【００１３】
いくつかの実施例では、データ処理システムは、複数のメッセージ・インターフェース・データ構造を格納するように構成され、複数のメッセージ・インターフェース・データ構造の各々のために選択されるメッセージ・チャネル・タイプは、独立して設定される。本技術の柔軟性はさらに拡張され、複数のメッセージ・インターフェース・データ構造をデータ処理システムにおいて確立して、メッセージ・チャネルの複数の別個のグループを確立できるようにし、これらグループの各々のために選択されるメッセージ・チャネル・タイプは、独立して設定され得る。言い換えれば、複数のメッセージ・チャネル・タイプを、データ処理システム内で並行して構成及び操作できる。
【００１４】
いくつかの実施例では、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能な追加のデータ・ストレージは、データ処理システムにおけるハードウェア・デバイスにレジスタのセットを備え、レジスタのセットにメモリ・アドレスのセットがメモリ・マッピングされる。追加のデータ・ストレージは、データ処理システムにおいて様々な形式をとり得るが、ハードウェア・デバイスにおけるレジスタのセットとして、追加のデータ・ストレージを提供し、データ処理システムにおけるメモリ・アドレスのセットを、そのレジスタのセットにマッピングすることは、これを達成できる１つの方式である。データ処理システムにおいて確立されたメッセージ・チャネルの管理は、様々な手法で実行され得るが、追加のデータ・ストレージが、ハードウェア・デバイスにレジスタのセットを備えるこのタイプのアプローチでは、ハードウェア・デバイスによってその管理が有用な程度で実行可能となり得る。そのようなハードウェア・デバイスが、データ処理システムにおけるメッセージの交換をサポートするために明示的に提供されている場合、結果として、これは効率的なシステムをサポートし、追加のデータ・ストレージ（すなわち、ここでは、ハードウェア・デバイスにおけるレジスタのセット）に格納されたメッセージ・チャネル・メタデータによって提供されるメッセージ・ステータス情報により、ハードウェア・デバイスは、メッセージ・チャネルを効率的に管理できる。
【００１５】
いくつかの実施例では、メモリ・アドレスのセットの少なくともサブセットは、データ処理システムにおける複数の場所にメモリ・マッピングされ、複数の場所のうちの少なくとも１つは、データ処理システムにおけるデータ処理デバイスに専用の周辺機器デバイス内にある。言い換えれば、そのような実施例は、ローカル周辺機器におけるこれらメモリ・アドレスのエイリアシングを可能にする。このアプローチは、たとえば、データ処理システムにおける個々のデータ処理エージェントが、パフォーマンス上の理由から互いに対してより独立して動作できることが望ましい実施例で使用され得る。たとえば、データ処理システムにおけるデータ処理エージェントは、システムにおける他のデータ処理エージェントがアクセスできない周辺機器デバイスへのアクセスを有し得、データ処理エージェントが、専用の周辺機器デバイスに保持されているメッセージ・チャネル・データに対してその操作の一部を実行できるようにすると、たとえば、平均アクセス・レイテンシが低くなるため、パフォーマンスが向上する。
【００１６】
いくつかの実施例では、メモリ・アドレスのセットの各アドレスは、データ処理システム内のそれぞれ固有の場所にメモリ・マッピングされる。言い換えれば、そのような実施例では、上述したエイリアシングが存在しない場合があり、その結果、メモリ・マッピングされたレジスタのビューは、データ処理システムにおけるすべてのデータ処理エージェントに対して一貫している。これは、たとえば、１つのデータ処理エージェントによって実行されているタスクの移行が別のデータ処理エージェントによって実行されることを、容易にすることができる。
【００１７】
いくつかの実施例では、それぞれ固有の場所は、データ処理システムにおける単一の周辺機器デバイス内にある。たとえば、データ処理システムにおけるいくつかのデータ処理エージェントは、メッセージ・チャネル・メタデータにおける追加のデータ・ストレージが格納されている場合、単一の周辺機器デバイスにアクセスし得る。これは、たとえば、上述した専用のハードウェア・デバイス内にあってもよい。
【００１８】
いくつかの実施例では、メモリ・アドレスのセットの少なくとも１つのアドレスは、データ処理システムにおける複数の周辺機器デバイス内の場所にメモリ・マッピングされ、複数の周辺機器デバイスは、レジスタのセットのコンテンツの一貫したコピーを保証するコヒーレンス・メカニズムを実装するように構成される。或いは、このため、複数の周辺機器デバイスの並列動作を可能にするために、エイリアシングを許可してパフォーマンスを向上させる、さらなるアプローチを採用することもできるが、これら複数の周辺機器デバイスに格納されたメッセージ・チャネル・メタデータにわたる一貫性は、このコヒーレンス・メカニズムによって達成され得る。
【００１９】
いくつかの実施例では、レジスタのセットは、メッセージ・チャネル・メタデータを格納するための通知レジスタを備え、通知レジスタに格納された値は、メッセージ・チャネルのメッセージ・ステータス情報を提供し、ハードウェア・デバイスは、通知レジスタに格納された値の変更に応答して、メッセージ・チャネルに対して所定のアクションを実行する。したがって、このメモリ・マッピングされた通知レジスタは、様々な「ドアベル」として機能でき、データ処理システムにおけるデータ処理エージェントでは、通知レジスタに格納された値を変更でき、この変更により、メッセージ・チャネルに関するアクションを、ハードウェア・デバイスにおいてトリガできる。ハードウェア・デバイスが、通知レジスタにおける値の変更を通知するように構成される特定の方式は、様々な形式をとり得る。たとえば、ハードウェア・デバイスは、メッセージ・チャネルの目的に適した頻度で通知レジスタをポーリングし得るか、又は、通知レジスタに、この「ドアベル」通知をトリガする物理的接続が提供され得る。さらに、ハードウェア・デバイスが、メッセージ・チャネルに関して行う所定のアクションは、システム要件に応じて、様々な形式をとり得る。たとえば、値の変更は、新たなメッセージが、メッセージ・チャネルを提供するメッセージ・データ構造に格納されたことをハードウェア・デバイスに通知することができ、ハードウェア・デバイスは、そのメッセージを、適切な宛先に転送するように機能し得る。
【００２０】
いくつかの実施例では、レジスタのセットは、複数のメッセージ・チャネルにそれぞれ対応する複数の通知レジスタを備え、通知レジスタに格納された値は、メッセージ・チャネルのメッセージ・データ構造に格納された、選択されたメッセージを示す。したがって、各メッセージ・チャネルに１つの通知レジスタが存在する場合、所与の通知レジスタに格納されている値を使用して、そのメッセージ・チャネルのメッセージ・データ構造に格納されている特定のメッセージを示すことができる。たとえば、通知レジスタは、格納できる値の範囲が、メッセージ・チャネルのメッセージ・データ構造に格納できる個々のメッセージの（少なくとも）数に対応するように構成され、したがって、値は、特定のメッセージ（たとえば、新たに格納されたメッセージ）を示し得る。
【００２１】
いくつかの実施例では、レジスタのセットは、メッセージ・チャネル・メタデータを格納するためのダイジェスト・レジスタ(digest register）を備え、ダイジェスト・レジスタに格納された値は、各それぞれのメッセージ・チャネルが、１つ又は複数の新たなメッセージを保持するための容量を現在有しているか否かを示す、複数のメッセージ・チャネルの各々についてのメッセージ・ステータス情報を提供する。したがって、そのような実施例では、ダイジェスト・レジスタ（「送信」ダイジェスト）を提供して、複数のメッセージ・チャネルの概要を与え、特に、各メッセージ・チャネルが、１つ又は複数の新たなメッセージを保持する容量を現在有している（すなわち、残りスペースがある）か、又はそうではない（すなわち、満杯である）かを示す。
【００２２】
同様に、いくつかの実施例では、レジスタのセットは、メッセージ・チャネル・メタデータを格納するための追加のダイジェスト・レジスタを備え、追加のダイジェスト・レジスタに格納された値は、各それぞれのメッセージ・チャネルが、１つ又は複数のメッセージを現在保持しているか否かを示す、複数のメッセージ・チャネルの各々のメッセージ・ステータス情報を提供する。したがって、そのような実施例では、複数のメッセージ・チャネルの概要を与えるために、特に、各メッセージ・チャネルが、現在、１つ又は新たな複数のメッセージを保持している（すなわち、処理する準備ができている新たなメッセージを有している）か、又はそうではない（すなわち、空である）かを示すために、追加のダイジェスト・レジスタ（「受信」ダイジェスト）が提供され得る。
【００２３】
いくつかの実施例では、ハードウェア・デバイスにおけるレジスタのセットは、メッセージ・データ構造に関連付けられた構成データ構造を格納するように構成され、構成データ構造は、メッセージ・データ構造の使用パラメータを定義し、使用パラメータは、メッセージ・データ構造のインデクスを備え、ハードウェア・デバイスは、インデクスの変更に応答して、メッセージ・データ構造に関して所定のアクションを実行する。したがって、構成データ構造における構成データ構造で提供される使用パラメータの１つは、インデクスとすることができ、たとえば、これは、メッセージ・チャネルにおいてキューに入れられたメッセージのセットに対して、書込インデクス又は読取インデクスの形式をとり得る。したがって、データ処理システムにおけるデータ処理エージェントが、メッセージ・データ構造においてキューに入れられたメッセージのセットにメッセージを追加する場合、書込インデクスをインクリメントして、次のメッセージが、後続してメッセージ・データ構造に追加されるべき場所を示すことができ、この書込インデクスの変更は、新たなメッセージが、メッセージ・データ構造に格納されたことをハードウェア・デバイスに通知するのに役立つ。或いは、インデクスは、読取インデクスであり得、データ処理システムにおけるデータ処理エージェントは、格納されたメッセージを取得すると、メッセージ・データ構造に関して読取インデクスを更新し、この読取インデクスの変更は、メッセージ・データ構造に以前に格納されたメッセージが取得されたというハードウェア・デバイスへの通知としても役立ち得る。通知（「ドアベル」）レジスタの上述した実例におけるように、インデクス・レジスタのポーリングや、応答を直接トリガするインデクス・レジスタへの接続のように、ハードウェア・デバイスからレジスタ内の値の変更へのこの応答が達成される様々な手法がある。
【００２４】
いくつかの実施例では、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、データ処理システムで実行するソフトウェア・タスクである。いくつかの実施例では、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、データ処理システムにおけるハードウェア・エージェントである。したがって、本技術を使用して、２つのソフトウェア・タスク間、ソフトウェア・タスクとハードウェア・デバイスと間、又は２つのハードウェア・デバイス間でメッセージを渡すことができる。
【００２５】
いくつかの実施例では、メッセージ・データ構造は、メッセージの順序付けされたキューである。これはリング・バッファであり得る。
【００２６】
いくつかの実施例では、メッセージ・チャネルは、第１のデータ処理エージェントから第２のデータ処理エージェントへの一方向メッセージ送信を提供する。
【００２７】
少なくともいくつかの実施例は、第１のデータ処理エージェントを操作することと、第２のデータ処理エージェントを操作することと、第１のデータ処理エージェントと第２のデータ処理エージェントとの間でコヒーレントに共有されたデータ・ストレージに、１つ又は複数のメッセージのメッセージ・データ構造を格納することと、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能な追加のデータ・ストレージに、メッセージ・チャネル・メタデータを格納することであって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納することと、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立することとを備える、データ処理の方法を提供する。
【００２８】
第１のデータ処理エージェントを操作する手段と、第２のデータ処理エージェントを操作する手段と、第１のデータ処理エージェントと第２のデータ処理エージェントとの間でコヒーレントに共有され、１つ又は複数のメッセージのメッセージ・データ構造を格納する手段と、第１のデータ処理エージェント及び第２のデータ処理エージェントにアクセス可能な、メッセージ・チャネル・メタデータを格納する手段であって、メッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つである、格納する手段と、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する手段とを備える、データ処理システムを提供する。
【００２９】
次に、いくつかの特定の実施例を、図を参照して説明する。
【００３０】
図１は、１つの実施例におけるデータ処理システム１０を概略的に例示する。一般に、データ処理システム１０は、データ処理システムが動作しているときに様々なデータ処理アクティビティを実行するいくつかのデータ処理コア１２〜１８（例示された実例では４つ）を備える。例示されたコア１２〜１８の各々は、代わりに、コアのクラスタであってもよい。データ処理アクティビティをサポートするために、データ処理システム１０は、データ処理コア１２〜１８の各々が、相互接続２２を介してアクセスするコヒーレント共有メモリ（たとえば、ＤＲＡＭ）を提供される。この実例では、システム・キャッシュ２４も、システム・パフォーマンスを向上させるために提供される。以下の図を参照してより詳細に説明するように、コヒーレント共有メモリ２０に格納される１つのアイテムは、データ処理システムにおける２つのデータ処理エージェント間のメッセージの受渡しをサポートするメッセージ・チャネルを提供するために使用されるメッセージ・データ構造２６である。メッセージ・チャネルの使用をサポートするためにデータ処理システムで定義されるメッセージ・データ構造２６及び他のデータ構造のさらなる詳細は、以下の図を参照してより詳細に説明され、ここでは、メッセージ・データ構造と他のデータ構造の構成の様々な可能性が記述される。ここで、様々なタイプの範囲を有するデータ処理システムにおけるデータ処理エージェント間のメッセージ受渡しをサポートするメッセージ・チャネルを動的に確立する能力が、データ処理システムに提供されていることを認識するだけで十分である。以下でさらに説明するように、考えられる様々なタイプのメッセージ・チャネルにおける所与のタイプのメッセージ・チャネルは、特定のデータ処理コンテキストに、より適している場合があり、したがって、データ処理システムにおいてメッセージ・チャネルが確立されると、現在のデータ処理要件に応じてメッセージ・チャネル・タイプが選択される。
【００３１】
図１は、アクセラレータ管理デバイス２８及び周辺機器デバイス３０をさらに図示する。データ処理システムにおいてメッセージ・チャネルが確立されると、メッセージ・データ構造２６に関連付けられたメッセージ・チャネル・メタデータがさらに、アクセラレータ管理デバイス２８のレジスタ３２又は周辺機器デバイス３０のストレージ３４などのような、データ処理システムの追加のデータ・ストレージに格納される。このメッセージ・チャネル・メタデータは、メッセージ・チャネルのメッセージ・ステータス情報を提供し、それを（コヒーレント共有メモリとは別個の）別の追加のデータ・ストアへ格納することにより、メッセージ・チャネルの管理がサポートされ、システムにおけるデータ処理エージェント間の通信がサポートされる。たとえば、メッセージ・チャネル・メタデータは、アクセラレータ管理デバイス２８のレジスタ３２に格納され得る。これらレジスタは、これらをメモリ・マッピングすることで、システムにおける（あらゆるタイプの）データ処理エージェントにアクセス可能となり得る。さらに、アクセラレータ管理デバイス２８は、確立されたメッセージ・チャネルを介して、システムにおけるデータ処理エージェント間の通信を容易にするための専用のハードウェア・デバイスとして提供され得る。メッセージ・チャネルのメッセージ・ステータス情報が、このハードウェア・デバイスのレジスタに格納されている場合、ハードウェア・デバイスはまた、この新たなメッセージを宛先に通信することに関して適切なアクションを講じることによって、メッセージ・チャネルのステータスの変化（メッセージ・データ構造２６における新たなメッセージの格納など）に応答するように構成され得る。それにも関わらず、この追加のストレージを、アクセラレータ管理デバイス２８などのハードウェア・デバイス内に物理的に配置する必要はなく、データ処理システム１０に実装できる変形実施例では、この目的のために、周辺機器デバイス３０におけるストレージ３４を利用できる。したがって、アクセラレータ管理デバイス２８は、「ステートレス」であると見なすことができ（それゆえ、レジスタ３２は提供されないか、又は、少なくともここで開示されている技術に直接関連しない目的にのみ使用される可能性があり）、実際には、図１の概略図において単一の自律型ユニット２８として例示されるが、様々な別個のコンポーネントによって提供される機能を備えたデータ処理システムに完全に分散させることができる。
【００３２】
図１の概略図から理解されるように、コア１２〜１８の各々は、アクセラレータ管理デバイス２８（及び、特にそのレジスタ３２）にアクセスでき、周辺機器デバイス３０にアクセスでき（及び、特にそのストレージ３４にアクセスし）、これらのうちの１つを使用して、メッセージ・チャネル・メタデータが格納される、上述した追加のデータ・ストレージを提供する。しかしながら、図１にも図示されているように、この実例におけるコア１２〜１８の各々には、それぞれのローカル周辺機器デバイス３６〜４２も提供される。このローカル周辺機器デバイスのセットは、メモリ・マッピングされたアドレスのローカル・ストレージに使用でき、少なくとも一部のメモリ・マッピングされたアドレスのエイリアスは許可され、エイリアス・メモリ・マッピングされたアドレスのセットの各アドレスが、システム内の（ローカル周辺機器デバイス３６〜４２のセットにわたる）複数の場所にマッピングされる。データ処理コア１２〜１８が、この方式で自身のローカル周辺機器内のメモリ・マッピングされたレジスタ・アドレスにアクセスできるようにすると、（たとえば、平均アクセス・レイテンシが減少するため）パフォーマンスが向上するが、システムにおけるすべての処理要素について、メモリ・マッピングされたレジスタのビューに一貫性がない場合、これは、コア間でのソフトウェア・スレッドの移行の容易さを制限する可能性がある。
【００３３】
図１はまた、コヒーレント共有メモリ２０に格納されたセッション・テーブル４０（ルーティング・テーブルとも称され得る）を図示し、これは、データ処理システムにおける各々の定義されたメッセージ・チャネルの送信元及び宛先を示す情報を格納するために使用される。以下の説明では、メッセージ・チャネルは、「セッション(session)」とも称され得、送信元又は宛先は、「ソケット(socket)」とも称され得る。この用語では、ソケットとセッションとの概念は互いに直接関連しており、セッションは、２つのソケット間の論理リンクを称し、逆に、ソケットは、１つの特定のセッションのエンドポイントである。セッションは、（スレッドと称され得る）２つのソフトウェア・タスク間、（アクセラレータ、及び互いから完全に独立したジョブの実行に必要な状態のグラニュールと見なすことができる）ハードウェアとソフトウェア・タスクとの間、又は２つのハードウェア・タスク間で確立され得る。セッションは、データ処理システムにおける「エージェント」のこれらタスク間でメッセージを転送するために使用される。
【００３４】
図２は、本技術のメッセージ・データ構造及びメッセージ・チャネル・メタデータがどのように格納されるかについてのいくつかのさらなる詳細を概略的に例示する。この図は、メッセージ・データ構造が格納されている共有コヒーレント・メモリ５０、及びメッセージ・チャネル・メタデータが格納されるアクセラレータ・ストレージ５２を図示する（このストレージは、アクセラレータ・デバイス自体の一部を形成し得る、又は、アクセラレータ・デバイスにアクセス可能な追加のシステム・ストレージであり得ることを理解されたい）。メッセージ・チャネル・メタデータとメッセージ・データ構造自体との両方が、メモリ・マップの一部を形成していることを図示する、対応するシステム・メモリ・マップ５４も例示され、したがって、システムにおける任意のデータ処理エージェントにコヒーレントにアクセス可能である。初期化時に、共有コヒーレント・メモリ５０におけるメッセージ・データ構造と、アクセラレータ・ストレージ５２におけるメッセージ・チャネル・メタデータとの両方がインスタンス化される。図２は、共有コヒーレント・メモリ５０に設定されたメッセージ・データ構造１で初期化されているメッセージ・チャネル１と、アクセラレータ・ストレージ５２を提供するレジスタ５８に格納されているメッセージ・チャネル１ステータス情報との実例を図示する。別個のメッセージ・チャネル０はすでに存在しており、共有コヒーレント・メモリ５０において対応するメッセージ・データ構造０と、アクセラレータ・ストレージ５２の一部としてレジスタ５６に格納されたメッセージ・チャネル０ステータス情報とを有する。これら２つのメッセージ・チャネルは、互いに独立しており、タイプが異なる場合がある。図２はまた、たとえば、図１に図示されるようなアクセラレータ管理デバイス２８の一部を形成し得る、アクセラレータ・メッセージ処理制御６０を図示する。ここに図示されるこの制御ユニット６０の１つの役割は、レジスタ５６及び５８のコンテンツの監視であり、これらレジスタの１つのコンテンツの変化に応答して、適切なメッセージ関連処理を実行することができる。この監視を実行するための２つの代替メカニズムが図２に図示される。第１のメカニズムでは、それぞれのレジスタと、アクセラレータ・メッセージ処理制御６０との間で接続が行われ、各レジスタは、「ドアベル」として機能して、アクセラレータ・メッセージ処理制御６０の応答をトリガし得る。第２のメカニズムにおいて、アクセラレータ・メッセージ処理制御６０は、レジスタをポーリングして、コンテンツの変化が発生したときを判定し、ここで、ポーリング・サイクルは、後続するアクションがその後従うべき速度と、このポーリングの提供に関連付けられたオーバ・ヘッドとの間のバランスに応じて設定される。
【００３５】
図３Ａ及び図３Ｂは、所与のメッセージ・チャネルのメッセージ・チャネル・メタデータ（メッセージ・ステータス情報を含む）の格納に使用される所与のレジスタ・アドレスのメモリ・マッピングの発行に戻る。図示される実例は、図１を参照して説明したようなデータ処理システムの構造に密接に基づいており、システムの様々なコンポーネントは、図３Ａ及び図３Ｂに再現され、同じ参照番号が与えられる（ただし、ここでは、図１のコア１２〜１６は、「処理要素」１２〜１６と称されることに注目されたい）。図３Ａの実例では、レジスタ・アドレス（０ｘ１００）が、システム内の複数の場所、つまり、ローカル周辺機器３６、３８、４０の各々にマッピングされていることがわかる。これは、メモリ・マッピングされたレジスタのビューが、処理要素１２〜１６の各々、特に、処理要素１２〜１６において実行するとしてそれぞれ例示されているスレッド７０〜７４の各々について、一貫していないことを意味する。それにも関わらず、これは、処理要素１２〜１６の各々が、そのローカル周辺機器３６〜４０におけるこのメモリ・マッピングされたレジスタ・アドレス０ｘ１００にアクセスできることも意味し、これにより、たとえば、平均アクセス・レイテンシが減少するため、パフォーマンスが向上し得る。対照的に、図３Ｂの実例では、メモリ・マッピングされたレジスタのビューは、処理要素１２〜１６の各々、特に、それぞれ、処理要素１２及び１６において現在実行しているものとしてそれぞれ例示されているスレッド７６及び７８の各々について一貫している。なぜなら、すべてのメモリ・マッピング（アドレス０ｘ１００）が、周辺機器スレーブ・デバイス３０において示されたレジスタ８０に一貫してマッピングされるためである。この一貫性のため、これは、１つの処理要素（たとえば、コア）において実行しているスレッドが、これを大幅に複雑にすることなく、異なる処理要素に移行できることを意味する。これは図３Ｂに概略的に例示されており、スレッド７６は、処理要素１２における実行から、処理要素１４における実行に移行している。図３Ａの検討に戻ると、ローカル周辺機器デバイス３６〜４０間のコヒーレンス・メカニズムの実装により、（たとえば、簡単なスレッド移行を可能にするために）代替的に、一貫性が達成され得る。これは、このコヒーレンス機構を実装するコヒーレンス制御８２の提供によって、図３Ａにおける代替（破線）として図示される。或いは、メッセージ・チャネルは、ここで説明されている第２のタイプのメッセージ・チャネル（ここでは、ＡＭＳテーブル全体が、共有コヒーレント・メモリに格納され、ソフトウェア・スレッド移行を容易にする）を使用して提供される。
【００３６】
上述したように、本技術は、異なるタイプのメッセージ・チャネルを、データ処理システムにおいて動的に確立できることを提供し、図４は、第１のタイプのメッセージ・チャネルが、いくつかの実施例において、どのように提供されるかについてのより詳細を概略的に例示し、ここでは、メッセージ・チャネルのメッセージを保持するメッセージ・データ構造は、共有コヒーレント・メモリに格納され、メッセージ・チャネルに関連付けられたすべてのメッセージ・チャネル・メタデータは、データ処理システムにおけるアクセラレータ・デバイスの内部ストレージに格納される。共有コヒーレント・メモリ１０２及びアクセラレータ・デバイス内部ストレージ１０４の実例のコンテンツが図示され、ここでは、このコンテンツのすべてが、メモリ・マッピングされ、メモリ・マップ１００も例示されている。
【００３７】
メモリ・マップ１００の上部には、ソフトウェア用のアクセラレータ・メッセージング・インターフェース（ＡＭＩ−ＳＷ）の３つの実例（ＡＭＩ−ＳＷ  ０、ＡＭＩ−ＳＷ  １、及びＡＭＩ−ＳＷ  ｎ）が図示される。最初の２つのインターフェースはどちらも、この第１のタイプのメッセージ・チャネルのグループを提供する（ここでは、メッセージ・チャネルに関連付けられたすべてのメッセージ・チャネル・メタデータは、共有コヒーレント・メモリの外部に格納され、この実例では、アクセラレータ・デバイスのレジスタにある）。図４に例示される実施例では、メッセージ・チャネルは、アクセラレータ・メッセージ・ソケット（ＡＭＳ）とも称され、ＡＭＳ毎に１つのメッセージ・キューがサポートされる。インターフェースＡＭＩ−ＳＷ  ｎによって提供されるＡＭＳタイプは図４から見ることはできず、実際、メッセージ・チャネル（ＡＭＳ）タイプの構成は、各インターフェースの粒度のレベルで決定されるため、インターフェースＡＭＩ−ＳＷ  ｎは、（図４に図示されるように）この第１のタイプのメッセージ・チャネルを提供することも、又は（図７を参照して後述する第２のタイプのような）システムによってサポートされる別のタイプのメッセージ・チャネルを提供することもできることが注目されるべきである。メモリ・マップ１００の下部には、２つの実例のリング・バッファのマッピングが図示される。
【００３８】
この第１のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの第１の階層レベルは、各ＡＭＩ−ＳＷに対して、ＴＸ＿ＤＩＧＥＳＴ及びＲＸ＿ＤＩＧＥＳＴレジスタと、このＡＭＩ−ＳＷが確立された場合に、対応するＡＭＩ−ＳＷパーティションに配置されたＴＸ及びＲＸ  ＡＭＳデータ構造とを備えたアイテム１０６として図４に図示される。ＡＭＩ−ＳＷパーティションは、ＡＭＳデータ構造に続くダイジェストを含む。パーティションのサイズは、ＡＭＩ毎にシステムにおいて定義されている送信（ＴＸ）及び受信（ＲＸ）ＡＭＳ（ＮＵＭ＿ＴＸ＿ＡＭＳ及びＮＵＭ＿ＲＸ＿ＡＭＳ）の数に応じて異なる。１つの実例では、各ＡＭＩ＿ＳＷに対して、送信用に６４個のＡＭＳ＿ＴＸ、及び受信用に６４個のＡＭＳ＿ＲＸがある。この実施例におけるＴＸ＿ＤＩＧＥＳＴ及びＲＸ＿ＤＩＧＥＳＴレジスタ、並びにＴＸ及びＲＸ  ＡＭＳデータ構造は、以下の表１で説明される。
【表１】
2020537235.tif 000003
【００３９】
リング・バッファ・データ構造ＴＸ＿ＡＭＳ＿ＴＡＢＬＥ及びＲＸ＿ＡＭＳ＿ＴＡＢＬＥは、図４においてソケット（ＡＭＳ）テーブルとしてラベル付けされる。ソケット・テーブルのコンテンツの詳細は、この第１のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの第２の階層レベルにおいて、アイテム１０８として図示され、これらは、このＡＭＩ−ＳＷパーティションにおけるＴＸソケット(TX socket)の各々のリング・バッファ・パラメータ、及び、それに続くこのＡＭＩ−ＳＷパーティションにおけるＲＸソケット(RX socket)の各々のリング・バッファ・パラメータである。（ＴＸ＿ＡＭＳ  ＃１の）リング・バッファ・パラメータの１つのセットの特定の詳細は、この第１のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの第３の階層レベルにおいて、アイテム１１０として図示される。これらリング・バッファ・パラメータは、このリング・バッファの現在の読取及び書込インデクス（基本的に、次のメッセージをリング・バッファから読み取る場所を示し、次のメッセージをリング・バッファに書き込む場所を示す）と、リング・バッファの要素サイズ定義（所与のメッセージが、１つ又は複数の要素を占有する場合がある）と、リング・バッファ・サイズを示すマスク値（ｎ２であり、ｎは、バイナリのマスク値で示される値）と、共有コヒーレント・メモリにおけるリング・バッファのベース・アドレスを示すベース・ポインタとを備える。
【００４０】
この第１のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータが使用される実例の手法について、図５及び図６を参照して説明する。これは、ソフトウェア・タスクがそれぞれ、ＴＸ＿ＡＭＳデータ構造の１つを介してメッセージを送信し、ＲＸ＿ＡＭＳデータ構造の１つを介してメッセージを受信するときに実行される実例の一連のステップを図示する。図５を用いて始めると、ソフトウェア・タスクからのメッセージの送信により、ステップ１５０において、ソフトウェア・タスクは、インデクス（ｉ，ｓ）を有するＡＭＳデータ構造にアクセスして、対応するリング・バッファのパラメータを取得する。次に、ステップ１５２において、ソフトウェア・タスクは、ＴＸ  ＤＩＧＥＳＴ値にアクセスすることによって、送信しようとしているメッセージのためのスペースが、リング・バッファに残っているか否かを判定する。関連するリング・バッファに対応するビットの値は、これをバイナリ（はい／いいえ）方式で示す。利用可能なスペースがない間、タスクは、ステップ１５４を介して循環して待機する。スペースが利用可能である場合、ステップ１５６において、ソフトウェア・タスクは、メッセージを、リング・バッファのインデクスＷＲＩＴＥ＿ＩＮＤＥＸに格納する。次に、ステップ１５８において、ソフトウェア・タスクは、バリア命令を発行して、すべての処理中の書込トランザクションが、宛先に到達したことを保証する。これは、共有コヒーレント・メモリへの書き込みは順序に制約がないため、バリア命令の前に発行された共有メモリへの他の書込トランザクションが、バリア命令の後に発行されるさらなるトランザクションの前に確実に実行されるためである。次に、ステップ１６０において、ソフトウェア・タスクは、（そのローカルＡＭＳテーブル内の）自身の書込インデクスをインクリメントし、この更新された値を、ＡＭＩ−ＳＷパーティションを介してＡＭＳ（ソケット）テーブルに書き込む。これで、ソフトウェア・タスクによって実行されるステップが完了する。後続するステップは、それに応じてアクセラレータ・マネジャによって実行される。ステップ１６２において、（ここではＡＭＵとも称される）アクセラレータ・マネジャは、ソケット＃ｓ、インターフェース＃ｉの書込インデクスへの更新を検出する。この検出は、ＷＲＩＴＥ＿ＩＮＤＥＸレジスタのポーリングする、又は、アクセラレータ・マネジャによるさらなるアクションをトリガするドアベルとして機能するようにＷＲＩＴＥ＿ＩＮＤＥＸレジスタを構成するなど、様々な手法で実装できることに注目されたい（このトピックに関する上記の図２の説明も参照されたい）。次に、ステップ１６４において、アクセラレータ・マネジャは、セッション・テーブルにアクセスして宛先ソケットを決定する（図１におけるアイテム４０参照）。ステップ１６６において、アクセラレータ・マネジャは、メッセージを、宛先ソケットに書き込むことができるか否か（すなわち、ＲＸ＿ＡＭＳのＲＸ＿ＤＩＧＥＳＴが、関連するリング・バッファにスペースがあることを示すか否か）を判定する。利用可能なスペースがない間、アクセラレータ・マネジャは、ステップ１６８を介して循環し���待機する。スペースが利用可能である場合、ステップ１７０において、アクセラレータ・マネジャは、ＴＸ＿ＡＭＳリング・バッファから、ＲＸ＿ＡＭＳリング・バッファへのメッセージのコピーを実行する。
【００４１】
次に図６に移って示すように、ソフトウェア・タスクがメッセージを受信したときに実行される実例の一連のステップが図示される。先ず、ステップ１８０において、ソフトウェア・タスクは、ＡＭＩ  ＃ｉのＲＸ＿ＤＩＧＥＳＴにアクセスすることにより、ＡＭＩ  ＃ｉのＲＸ＿ＡＭＳ  ＃ｓからのメッセージが利用可能であることを判定する。次に、ステップ１８２において、ソフトウェア・タスクは、インデクス（ｉ，ｓ）を有するＡＭＳデータ構造にアクセスして、関連するリング・バッファのパラメータを取得する。ステップ１８４において、ソフトウェア・タスクは、インデクスＲＥＡＤ＿ＩＮＤＥＸでリング・バッファから１つ（又は複数）のメッセージを読み取り、ステップ１８６において、ソフトウェア・タスクは、自身のローカル読取インデクスをインクリメントし、この更新された値を、ＡＭＩ−ＳＷパーティションを介してＡＭＳテーブルに書き込む。ソフトウェア・タスクによって実行されるステップはこれで完了し、最後のステップ１９０は、それに応じてアクセラレータ・マネジャによって行われる。ステップ１９０において、アクセラレータ・マネジャは、ＡＭＳ  ＃ｓ、ＡＭＩ  ＃ｉの読取インデクスへの更新を検出し、したがって、メッセージが、宛先ソフトウェア・タスクによって受信されたことを確認応答する。この確認応答は、必要に応じてメッセージの送信者に伝達できる。上記のように、書込インデクスの変更の検出について、この読取インデクスの変更の検出は、ＲＥＡＤ＿ＩＮＤＥＸレジスタをポーリングする、又は、アクセラレータ・マネジャによってさらなるアクションをトリガするドアベルとして機能するようにＲＥＡＤ＿ＩＮＤＥＸレジスタを構成するなど、様々な手法で実装され得ることに注目されたい（このトピックに関する上記の図２の説明も参照されたい）。
【００４２】
図７は、いくつかの実施例において、データ処理システムにおいて動的に確立することができる第２のタイプのメッセージ・チャネルがどのように提供されるかについて、より詳細を概略的に例示する。この第２のタイプのメッセージ・チャネルの場合、メッセージ・データ構造が、共有コヒーレント・メモリに格納されたメッセージ・チャネルのメッセージを保持しているだけでなく、メッセージ・チャネルに関連付けられているメッセージ・チャネル・メタデータのかなりの部分（実際、ＡＭＳテーブルのすべて）もそこに格納される。データ処理システムにおけるアクセラレータ・デバイスの内部ストレージには、小さなステータス・インジケーションのセット（通知レジスタ）のみが格納される。共有コヒーレント・メモリ２００及びアクセラレータ・デバイス内部ストレージ２０２の実例のコンテンツが図示され、このコンテンツのすべてが、メモリ・マッピングされ、メモリ・マップ２０４も例示される。
【００４３】
メモリ・マップ２０４の上部には、共有コヒーレント・メモリへのマッピングのために、ソフトウェア用のアクセラレータ・メッセージング・インターフェース（ＡＭＩ−ＳＷ）の２つの実例（ＡＭＩ−ＳＷ［０］及びＡＭＩ−ＳＷ［ｎ］）が図示される。これらインターフェースはどちらも、この第２のタイプのメッセージ・チャネルのグループを提供し、ここでは、メッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの大部分（ＡＭＳテーブルのすべて）は、共有コヒーレント・メモリに格納される。図７に例示される実施例では、メッセージ・チャネルは、ここではアクセラレータ・メッセージ・ソケット（ＡＭＳ）とも称され、ＡＭＳ毎に１つのメッセージ・キューがサポートされる。メッセージ・チャネル（ＡＭＳ）タイプの構成は、各インターフェースの粒度のレベルで決定されるため、追加のＡＭＩ−ＳＷインターフェースが、（図７に図示されるように）この第２のタイプのメッセージ・チャネルを提供できること、又は、システムでサポートされている別のタイプのメッセージ・チャネル（たとえば、図４を参照して上述した第１のタイプなど）を提供できることが注目されるべきである。メモリ・マップの中央部分に、（ＡＭＩ−ＳＷ毎に１つの）ＡＭＩ−ソフトウェア・パーティションのアクセラレータ・デバイス内部ストレージへのマッピングが図示され（ＡＭＩ−ＳＷパーティションのサイズは、指定されたＡＭＳの数に応じて異なり）、メモリ・マップ１００の最下部には、２つの実例のリング・バッファのマッピングが図示される。
【００４４】
この第２のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの第１の階層レベルは、（第１のタイプのメッセージ・チャネルと同様に、）各ＡＭＩ−ＳＷに対して、ＴＸ＿ＤＩＧＥＳＴ値及びＲＸ＿ＤＩＧＥＳＴ値と、ＡＭＩ−ＳＷが確立された場合に、コヒーレント共有メモリに配置されたＴＸ及びＲＸ  ＡＭＳデータ構造とを備えたアイテム２０６として図７に図示される。ダイジェストの後に、ＡＭＳデータ構造が続く。この第２のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータの第２の階層レベルは、図７において、アイテム２０８として図示され、第３の階層レベルは、アイテム２１０として図示される。これらは、図４で説明したアイテム１０８及び１１０と同じである。ＡＭＩ−ＳＷエントリのフォーマットを以下の表２に示す。ここで、Ｎ＝（ＮＵＭ＿ＴＸ＿ＡＭＳ−１）及びＭ＝（ＮＵＭ＿ＲＸ＿ＡＭＳ−１）である。ＡＭＩテーブルは、ＡＭＳ毎に１つのドアベル・レジスタを含む。
【表２】
2020537235.tif 000004
【００４５】
この実施例では、図７に例示されるように、各ドアベル・レジスタにおいて、ビット［１５：０］を使用して、リング・バッファ内の要素の数を指定し、ビット［３１：１６］は予約されている。他の実施例では、各ドアベル・レジスタのすべてのビットは、リング・バッファにおける要素に対応し得る。
【００４６】
この第２のタイプのメッセージ・チャネルに関連付けられたメッセージ・チャネル・メタデータを使用する実例の手法は、ソフトウェア・タスクが、それぞれ、ＴＸ＿ＡＭＳデータ構造の１つを介してメッセージを送信し、ＲＸ＿ＡＭＳデータ構造の１つを介してメッセージを受信する場合に採用される実例の一連のステップを図示する図８及び図９を参照して説明される。図８を用いて始めると、ソフトウェア・タスクからのメッセージの送信により、ステップ２５０において、ソフトウェア・タスクは、インデクス（ｉ，ｓ）を有するＡＭＳデータ構造にアクセスして、対応するリング・バッファのパラメータを取得する。その後、ステップ２５２において、ソフトウェア・タスクは、ＴＸ  ＤＩＧＥＳＴ値にアクセスすることによって、送信しようとしているメッセージのためのスペースがリング・バッファに残っているか否かを判定する。関連するリング・バッファに対応するビットの値は、これをバイナリ（はい／いいえ）方式で示す。利用可能なスペースがない間、タスクは、ステップ２５４を介して循環して待機する。スペースが利用可能である場合、ステップ２５６において、ソフトウェア・タスクは、メッセージを、リング・バッファのインデクスＷＲＩＴＥ＿ＩＮＤＥＸに格納する。次に、ステップ２５８において、ソフトウェア・タスクは、バリア命令を発行して、すべての処理中の書込トランザクションが、宛先に到達したことを保証する（共有コヒーレント・メモリにおける書込が、順序制約を受けない上記を参照）。次に、ステップ２６０において、ソフトウェア・タスクは、（そのローカルＡＭＳテーブル内の）自身の書込インデクスをインクリメントし、キューされたばかりの要素の番号を、ＡＭＳ  ＃ｓのドアベル・レジスタに書き込むことによって、アクセラレータ・マネジャ（ＡＭＵ）に通知する。これで、ソフトウェア・タスクによって実行されるステップが完了する。後続するステップは、それに応じてアクセラレータ・マネジャによって実行される。ステップ２６２において、アクセラレータ・マネジャ（ＡＭＵ）は、ソケット＃ｓ、インターフェース＃ｉのドアベル・レジスタへの更新を検出する。（上記の書込インデクス及び読取インデクスのように）この検出は、ドアベル・レジスタをポーリングする、又は、アクセラレータ・マネジャによるさらなるアクションをトリガするドアベルとして実際に機能するようにドアベル・レジスタを構成するなど、（「ドアベル・レジスタ」という便利な名前にも関わらず）様々な手法で実装できることに注目されたい（このトピックに関する上記の図２の説明も参照されたい）。次に、ステップ２６４において、アクセラレータ・マネジャは、セッション・テーブルにアクセスして宛先ソケットを決定する（図１におけるアイテム４０参照）。ステップ２６６において、アクセラレータ・マネジャは、メッセージを、宛先ソケットに書き込むことができるか否か（すなわち、ＲＸ＿ＡＭＳのＲＸ＿ＤＩＧＥＳＴが、関連するリング・バッファにスペースがあることを示すか否か）を判定する。利用可能なスペースがない間、アクセラレータ・マネジャはステップ２６８を介して循環して待機する。スペースが利用可能である場合、ステップ��７０において、アクセラレータ・マネジャは、ＴＸ＿ＡＭＳリング・バッファから、ＲＸ＿ＡＭＳリング・バッファへのメッセージのコピーを実行する。
【００４７】
次に図９に移って示すように、ソフトウェア・タスクがメッセージを受信したときに実行される実例の一連のステップが図示される。先ず、ステップ２８０において、ソフトウェア・タスクは、ＡＭＩ  ＃ｉのＲＸ＿ＤＩＧＥＳＴにアクセスすることにより、ＡＭＩ  ＃ｉのＲＸ  ＡＭＳ  ＃ｓからのメッセージが利用可能であることを判定する。次に、ステップ２８２において、ソフトウェア・タスクは、インデクス（ｉ，ｓ）を有するＡＭＳデータ構造にアクセスして、関連するリング・バッファのパラメータを取得する。ステップ２８４において、ソフトウェア・タスクは、インデクスＲＥＡＤ＿ＩＮＤＥＸでリング・バッファから１つ（又は複数）のメッセージを読み取り、ステップ２８６において、ソフトウェア・タスクは、それ自身のローカル読取インデクスをインクリメントし、デキューされたばかりの要素の番号を、ＡＭＳ  ＃ｓのドアベル・レジスタに書き込むことによって、アクセラレータ・マネジャ（ＡＭＵ）に通知する。ソフトウェア・タスクによって実行されるステップはこれで完了する。ステップ２９０において、アクセラレータ・マネジャは、ＡＭＳ  ＃ｓ、ＡＭＩ  ＃ｉのドアベル・レジスタへの更新を検出し、したがって、メッセージが、宛先ソフトウェア・タスクによって受信されたことを確認応答する。この確認応答は、必要に応じてメッセージの送信者に伝達できる。上記のように、書込インデクスの変更の検出について、このドアベル・レジスタの変更の検出は、ドアベル・レジスタをポーリングする、又は、アクセラレータ・マネジャによってさらなるアクションをトリガするドアベルとして機能するようにドアベル・レジスタを実際に構成するなど、様々な手法で実装され得ることに注目されたい（このトピックに関する上記の図２の説明も参照されたい）。最後に、ステップ２９２において、アクセラレータ・マネジャは、ＤＭＡ読取トランザクションを開始し、ＲＥＡＤ＿ＩＮＤＥＸの更新された値を取得する。
【００４８】
要約すると、データ処理システム及びデータ処理の方法が提供される。このシステムは、第１及び第２のデータ処理エージェントと、両データ処理エージェント間にコヒーレントに共有され、両データ処理エージェント間にメッセージ・チャネルを提供するメッセージ・データ構造を格納するデータ・ストレージとを備える。追加のデータ・ストレージは、メッセージ・チャネルのメッセージ・ステータス情報を提供するメッセージ・チャネル・メタデータを格納するために、両データ処理エージェントにアクセスできる。メッセージ・チャネル・メタデータは、第１のデータ処理エージェントと第２のデータ処理エージェントとの間の対応する複数のメッセージ・チャネル・タイプに対して定義された複数のメッセージ・チャネル・メタデータ・タイプのうちの１つであり、第１のデータ処理エージェントと第２のデータ処理エージェントとのうちの少なくとも一方は、初期化トリガに応答して、選択されたメッセージ・チャネル・タイプを用いてメッセージ・チャネルを確立する。
【００４９】
本願では、「〜ように構成された」という文言は、装置の要素が、定義された動作を実行できる構成を有することを意味するために使用される。この文脈において、「構成」は、ハードウェア又はソフトウェアの相互接続の構成又は方式を意味する。たとえば、装置は、定義された動作を提供する専用ハードウェアを有してもよく、又はプロセッサ若しくは他の処理デバイスが、機能を実行するようにプログラムされてもよい。「〜ように構成された」は、定義された動作を提供するために装置要素を何らかの手法で変更する必要があることを意味するものではない。
【００５０】
例示的な実施例を、添付図面を参照して本明細書で詳細に説明したが、本発明はそれら正確な実施例に限定されず、様々な変形、追加、及び変更が、添付の特許請求の範囲によって定義される本発明の範囲から逸脱することなく、当業者によって実施され得ることを理解されたい。たとえば、本発明の範囲から逸脱することなく、従属請求項の特徴の様々な組合せを、独立請求項の特徴と共に行うことができる。
【図１】
2020537235.tif 000005
【図２】
2020537235.tif 000006
【図３Ａ】
2020537235.tif 000007
【図３Ｂ】
2020537235.tif 000008
【図４】
2020537235.tif 000009
【図５】
2020537235.tif 000010
【図６】
2020537235.tif 000011
【図７】
2020537235.tif 000012
【図８】
2020537235.tif 000013
【図９】
2020537235.tif 000014
【国際調査報告】
2020537235.tif 000015
2020537235.tif 000016
2020537235.tif 000017