特表 2024-500477 ネットワーク通信リンク上の要求パケットのためのタグ

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】公表特許公報(A)

(11)【公表番号】

(43)【公表日】2024-01-09

(54)【発明の名称】ネットワーク通信リンク上の要求パケットのためのタグ

(51)【国際特許分類】

   G06F 13/36 20060101AFI20231226BHJP

   G06F 13/38 20060101ALI20231226BHJP

   G06F 13/42 20060101ALI20231226BHJP

【ＦＩ】

G06F13/36 310E

G06F13/38 330Z

G06F13/42 310

G06F13/42 320A

G06F13/36 510

【審査請求】未請求

【予備審査請求】未請求

(21)【出願番号】P 2023538664

(86)(22)【出願日】2021-12-06

(85)【翻訳文提出日】2023-06-21

(86)【国際出願番号】 US2021062063

(87)【国際公開番号】W WO2022125467

(87)【国際公開日】2022-06-16

(31)【優先権主張番号】17/120,208

(32)【優先日】2020-12-13

(33)【優先権主張国・地域又は機関】US

(81)【指定国・地域】

【公序良俗違反の表示】

（特許庁注：以下のものは登録商標）

１．ＶＥＲＩＬＯＧ

(71)【出願人】

【識別番号】591016172

【氏名又は名称】アドバンスト・マイクロ・ディバイシズ・インコーポレイテッド

【氏名又は名称原語表記】ＡＤＶＡＮＣＥＤ ＭＩＣＲＯ ＤＥＶＩＣＥＳ ＩＮＣＯＲＰＯＲＡＴＥＤ

(74)【代理人】

【識別番号】100108833

【弁理士】

【氏名又は名称】早川 裕司

(74)【代理人】

【識別番号】100162156

【弁理士】

【氏名又は名称】村雨 圭介

(72)【発明者】

【氏名】ゴードン キャルック

(57)【要約】

電子デバイスは、リクエスタと、リクエスタとリンクとの間に結合されたリンクインターフェースと、を含む。リクエスタは、リンクインターフェースを介してリンク上のコンプリータに要求パケットを送信するように構成されている。要求パケットをコンプリータに送信する場合に、リクエスタは、要求パケットがコンプリータの内部要素内にある前にコンプリータの内部要素内にあるリクエスタからの他の要求パケット内のタグに対して一意ではないが、要求パケットがコンプリータの内部要素内にある間にコンプリータの内部要素内にあるリクエスタからの他の要求パケット内のタグに対して一意であるタグを有する要求パケットを、リンクインターフェースを介してコンプリータに送信する。
【選択図】図５

【特許請求の範囲】

【請求項1】

電子デバイスであって、
リクエスタと、
前記リクエスタとリンクとの間に結合されたリンクインターフェースと、を備え、
前記リクエスタは、
要求パケットがコンプリータの内部要素内にある前に前記コンプリータの前記内部要素内にある前記リクエスタからの他の要求パケット内のタグに対して一意ではないが、前記要求パケットが前記コンプリータの前記内部要素内にある間に前記コンプリータの前記内部要素内にある前記リクエスタからの他の要求パケット内のタグに対して一意であるタグを有する前記要求パケットを、前記リンクインターフェースを介して前記コンプリータに送信することによって、前記リンクインターフェースを介して前記リンク上の前記コンプリータに前記要求パケットを送信するように構成されている、
電子デバイス。

【請求項2】

前記リクエスタは、
タグ値レコードから前記タグの値を取得し、前記タグの値を有する前記タグを前記要求パケットに含めることと、
前記タグ値レコードを次の値に進めることであって、前記進めることは、前記タグ値レコードをシーケンス内の次の値に設定することと、前記タグ値レコードが前記シーケンス内の最後のタグ値にある場合に、前記タグ値レコードを前記シーケンス内の第１の値に戻すことと、を含む、ことと、
を行うように構成されている、
請求項１の電子デバイス。

【請求項3】

前記コンプリータの前記内部要素は、タグ値カウンタの最大許容値未満の数の要求パケットを保持するための容量を有する、
請求項２の電子デバイス。

【請求項4】

前記リクエスタは、
前記要求パケットが前記コンプリータに到着した場合に、前記コンプリータの内部要素が、前記コンプリータの前記内部要素内の前記リクエスタからの他の要求パケット内のタグに対して一意のタグを有する前記リクエスタからの要求パケットで満たされることを決定したことに基づいて、前記要求パケットを送信するように構成されている、
請求項１の電子デバイス。

【請求項5】

前記リクエスタは、
前記リクエスタによって前記コンプリータに送信され、前記コンプリータから応答パケットが未だ受信されていないインフライト要求パケットの数に少なくとも部分的に基づいて、前記コンプリータの前記内部要素が満たされることを決定するように構成されている、
請求項４の電子デバイス。

【請求項6】

前記リクエスタは、
前記リンク上のネットワークデバイスのタイプ及び／若しくは配置、並びに／又は、前記リクエスタ内の内部要素のタイプ及び／若しくは配置に少なくとも部分的に基づいて、前記コンプリータの前記内部要素が満たされることを決定するように構成されている、
請求項４の電子デバイス。

【請求項7】

前記コンプリータの前記内部要素は、
要求パケットを受信するための受信要素と、
要求パケットを処理するための処理要素と、
応答パケットを送信するための送信要素と、
のうち一部又は全てを含む、
請求項６の電子デバイス。

【請求項8】

前記リクエスタは、
前記タグを含む応答パケットを、前記リンクインターフェースを介して前記コンプリータから受信することと、
前記応答パケットの前記タグを使用して、前記応答パケットが、前記応答パケットの後続処理のために前記要求パケットと関連付けられていることを決定することと、
を行うように構成されている、
請求項１の電子デバイス。

【請求項9】

前記リンク上で使用される通信仕様はＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ Ｅｘｐｒｅｓｓ）規格であり、
前記タグはＰＣＩｅタグである、
請求項１の電子デバイス。

【請求項10】

前記リクエスタは、
非一意のタグの使用が許容されていることを示す入力を受信したことに基づいて、前記決定する動作及び前記送信する動作を実行するように構成されている、
請求項１の電子デバイス。

【請求項11】

前記リクエスタ内のリンクインターフェースを介してリンク上でリクエスタからコンプリータに要求パケットを送信するための方法であって、
前記リクエスタが、前記要求パケットが前記コンプリータの内部要素内にある前に前記コンプリータの前記内部要素内にある前記リクエスタからの他の要求パケット内のタグに対して一意ではないが、前記要求パケットが前記コンプリータの前記内部要素内にある間に前記コンプリータの前記内部要素内にある前記リクエスタからの他の要求パケット内のタグに対して一意であるタグを有する前記要求パケットを送信することを含む、
方法。

【請求項12】

前記リクエスタが、タグ値レコードから前記タグの値を取得し、前記タグの値を有する前記タグを前記要求パケットに含めることと、
前記リクエスタが、前記タグ値レコードを次の値に進めることであって、前記進めることは、前記タグ値レコードをシーケンス内の次の値に設定することと、前記タグ値レコードが前記シーケンス内の最後のタグ値にある場合に、前記タグ値レコードを前記シーケンス内の第１の値に戻すことと、を含む、ことと、を含む、
請求項１１の方法。

【請求項13】

前記コンプリータの前記内部要素は、タグ値カウンタの最大許容値未満の数の要求パケットを保持するための容量を有する、
請求項１２の方法。

【請求項14】

前記リクエスタが、前記要求パケットが前記コンプリータに到着した場合に、前記コンプリータの内部要素が、前記コンプリータの前記内部要素内の前記リクエスタからの他の要求パケット内のタグに対して一意のタグを有する前記リクエスタからの要求パケットで満たされることを決定したことに基づいて、前記要求パケットを送信することを含む、
請求項１１の方法。

【請求項15】

前記リクエスタが、前記リクエスタによって前記コンプリータに送信され、前記コンプリータから応答パケットが未だ受信されていないインフライト要求パケットの数に少なくとも部分的に基づいて、前記コンプリータの前記内部要素が満たされることを決定することを含む、
請求項１４の方法。

【請求項16】

前記リクエスタが、前記リンク上のネットワークデバイスのタイプ及び／若しくは配置、並びに／又は、前記リクエスタ内の内部要素のタイプ及び／若しくは配置に少なくとも部分的に基づいて、前記コンプリータの前記内部要素が満たされることを決定することを含む、
請求項１４の方法。

【請求項17】

前記コンプリータの前記内部要素は、
要求パケットを受信するための受信要素と、
要求パケットを処理するための処理要素と、
応答パケットを送信するための伝送要素と、
のうち一部又は全てを含む、
請求項１６の方法。

【請求項18】

前記リクエスタが、前記タグを含む応答パケットを、前記リンクインターフェースを介して前記コンプリータから受信することと、
前記リクエスタが、前記応答パケットの前記タグを使用して、前記応答パケットが、前記応答パケットの後続処理のために前記要求パケットと関連付けられていることを決定することと、を含む、
請求項１１の方法。

【請求項19】

前記リンク上で使用されている通信仕様はＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ Ｅｘｐｒｅｓｓ）規格であり、
前記タグはＰＣＩｅタグである、
請求項１１の方法。

【請求項20】

前記リクエスタが、非一意のタグの使用が許容されていることを示す入力を受信したことに基づいて、前記決定する動作及び前記送信する動作を実行することを含む、
請求項１１の方法。

【発明の詳細な説明】

【背景技術】

【0001】

（関連技術）
いくつかの電子デバイスでは、機能ブロック、デバイス及び要素は、情報（すなわち、データ、メッセージ、制御値等）を交換し、他の動作を実施するためにネットワーク通信リンクを使用する。例えば、グラフィックス処理ユニット（graphics processing unit、ＧＰＵ）は、ネットワーク通信リンクを使用して、メモリアクセス要求をメモリに伝送することができ、メモリは、ネットワーク通信リンクを介してデータをＧＰＵに（必要な場合に）返すことができる。ネットワーク通信リンクを使用する通信は、通常、通信がネットワーク通信リンク上でどのように実行されるかを規定する通信仕様（又はプロトコル、規格等）のルール及び要件に従って実施される。例えば、通信仕様は、パケット、メッセージ等のタイミング、パケット、メッセージ等の情報の配置及びフォーマット、エンドポイント（例えば、機能ブロック、デバイス若しくは要素）によってサポートされる動作、又は、中間デバイス（例えば、スイッチ、リピータ等）等を規定し得る。ネットワーク通信リンクに使用される１つの周知の通信仕様は、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ Ｅｘｐｒｅｓｓ（ＰＣＩ Ｅｘｐｒｅｓｓ又はＰＣＩｅ）仕様であり、これは、Ｂｅａｖｅｒｔｏｎ、ＯＲのＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｆａｃｅ Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ（ＰＣＩ ＳＩＧ）によって開発されたものであり、維持されている。ＰＣＩｅ仕様は、ＰＣＩｅリンクを使用するＰＣＩｅエンドポイント及び中間デバイスのための動作の詳細なルール及び要件を含む。例えば、ＰＣＩｅリンクを使用するためのルールのうちいくつかは、２０１９年５月２２日にＰＣＩ ＳＩＧによってリリースされたＰＣＩ Ｅｘｐｒｅｓｓ Ｂａｓｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｖｉｓｉｏｎ ５．０ Ｖｅｒｓｉｏｎ １．０に含まれている。

【0002】

ＰＣＩｅ仕様におけるルールの中には、完了を必要とする要求を識別するために使用されるトランザクション記述子が要求に（すなわち、要求パケットのヘッダに）含まれなければならないというルールがある。例えば、ＧＰＵは、メモリに送信され、それぞれの要求されたデータと共にメモリからＧＰＵに送信される応答パケットの形態で完了を必要とする読み取りメモリアクセス要求内にトランザクション記述子を含まなければならない。トランザクション記述子は、２つの異なるサブフィールド、すなわち、Ｍビットの要求元ＩＤ、及び、Ｎビットのタグから形成される（ここで、Ｍ＝１６、２０又は別の数であり、Ｎ＝１０、１６又は別の数である）。要求元ＩＤは、リクエスタのバス番号、デバイス番号及びファンクション番号の指定された組み合わせ等のエンドポイントのセットの中から要求元を識別する固定識別子である。タグは、リクエスタに対してその要求パケットを識別するために各要求パケットに対して所定の要求元によって生成される値である。ＰＣＩｅ仕様によれば、完了を必要とする所定のリクエスタからの各未処理の要求（すなわち、コンプリータからの応答パケット）内のタグは、一意であるべきである。

【0003】

場合によっては、各未処理の要求内のリクエスタによって含まれるタグが一意であるという上記の要件は、非効率的な動作につながる可能性がある。これは、より高速のリクエスタ（すなわち、エンドポイント等）及び／又はより高レイテンシのトポロジ（例えば、複数のリンク及び／又は中間デバイス等を有する）におけるリクエスタが、タグ値を使い果たすのに十分な未処理の要求を伝送することができるために起こり得る。言い換えれば、場合によっては、要求元は、要求に対する応答、ひいては、それと関連付けられたタグがコンプリータから返され始める前にタグ値を使い果たすために、異なるＮビットタグ値を有する十分な要求パケットを送信することができる。これが発生すると、リクエスタは、強制的に停止される。リクエスタは、それぞれのタグを有する要求に対する応答がコンプリータから返されるまで停止されたままである。応答してタグがリクエスタに返されると、リクエスタは、後続の要求においてタグを再使用することによって要求の送信を再開することができる。

【0004】

タグがなくなると停止することは、リクエスタのパフォーマンスを妨げるので、設計者は、回避策を提案してきた。例えば、ＰＣＩｅ仕様は、「ファントムファンクション番号（phantom function numbers）」を使用することを記載しており、これは、上述したリクエスタＩＤの代わりにトランザクション記述子内の請求されていないファンクション番号を使用するリクエスタを含む。多数の要求パケットが送信されることを可能にするが、ファントムファンクション番号を使用することは、リクエスタが関連する制御及び処理動作を実施するための回路を含むことを必要とする。別の例として、いくつかのリクエスタ／コンプリータのペアは、タグを「再利用」することができる。このような電子デバイスでは、コンプリータ側及びリクエスタ側の両方が、重複タグを認識し処理するための回路を含まなければならない。提案された機構は、少なくともいくつかの停止の回避を可能にするが、それらは、処理オーバーヘッド、設計の複雑さ及び／又は他の複雑化と関連付けられる。

【図面の簡単な説明】

【0005】

【図1】いくつかの実施形態による、ネットワーク通信リンクを示すブロック図である。

【図2】いくつかの実施形態による、トポロジを示すブロック図である。

【図3】いくつかの実施形態による、要求パケットを示すブロック図である。

【図4】いくつかの実施形態による、タグを伴う要求パケットをコンプリータからリクエスタに送信するためのプロセスを示すフローチャートである。

【図5】いくつかの実施形態による、リクエスタからコンプリータに送信される要求パケットを示すブロック図である。

【図6】いくつかの実施形態による、タグを伴う要求パケットをコンプリータからリクエスタに送信するためのプロセスを示すフローチャートである。

【発明を実施するための形態】

【0006】

図面及び記載を通して、同様の符号は、同じ図面要素を指す。

【0007】

以下の記載は、任意の当業者が記載の実施形態を生成及び使用することを可能にするために提示され、特定の用途及びその要件のコンテキストにおいて提供される。記載の実施形態に対する様々な変更が当業者には容易に明らかであり、本明細書に記載の一般原理は、他の実施形態及び用途に適用され得る。これにより、記載の実施形態は、示される実施形態に限定されず、本明細書に記載の原理及び特徴と一致する最も広い範囲を与えられるべきである。

【0008】

（用語）
以下の記載では、実施形態を説明するために様々な用語が使用される。以下は、用語のうち何れかの簡略化された一般的な説明である。この用語が明確さ及び簡潔さのために本明細書に記載されない重要な更なる態様を有する場合があり、したがって、説明がこの用語を限定しようとするものではないことに留意されたい。

【0009】

機能ブロック：機能ブロックは、集積回路構成、ディスクリート回路等の一組の相互に関連する回路を指す。回路は、回路内の回路要素が少なくとも１つの特性を共有することに「相互に関連している」。例えば、回路は、特定の集積回路チップ、基板、回路基板又はその一部に含まれ、その上に製造され、或いはさもなければ、結合されてもよく、特定の動作（例えば、計算動作、制御動作、メモリ動作等）の実行に関与してもよく、共通制御要素及び／又は共通クロックによって制御される等してもよい。機能ブロックの回路は、単一の回路要素（例えば、単一の集積回路論理ゲート又はディスクリート回路要素）から数百万又は数十億個の回路要素（例えば、集積回路メモリ）までの任意の数の回路要素を有することができる。いくつかの実施形態では、機能ブロックは、プログラムコードを実行することなく動作を実行する回路を使用して「ハードウェアでの」動作を実行する。

【0010】

Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ：Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（すなわち、ＰＣＩ Ｅｘｐｒｅｓｓ、ＰＣＩｅ等）は、ネットワーク通信リンク又は「ＰＣＩｅリンク」上の通信のための仕様である。ＰＣＩｅ仕様（多数の個別の仕様で構成されている）は、例えば、ＰＣＩｅリンク上で通信するためのハードウェア及び／又はソフトウェア要素に必要な機能及び互換性に関するルール、ＰＣＩｅリンク上で伝送される要求パケット及び応答パケットの内容及び配置に関するルール等のような、ＰＣＩｅリンク上で通信するためのルール及びガイドラインを規定する。例えば、ＰＣＩｅリンク上で通信するための多くの基本ルール及びガイドラインを含むＰＣＩｅ「ベース」仕様は、２０１９年５月にＢｅａｖｅｒｔｏｎ，ＯＲのＰＣＩ Ｓｐｅｃｉａｌ Ｉｎｔｅｒｅｓｔ Ｇｒｏｕｐ（ＰＣＩ ＳＩＧ）によって発行されたＰＣＩ Ｅｘｐｒｅｓｓ Ｂａｓｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｖｉｓｉｏｎ ５．０ Ｖｅｒｓｉｏｎ １．０に見出すことができ、これは参照により本明細書に組み込まれる。別の例として、ドラフトＰＣＩｅベース仕様は、２０２０年２月２４日にＰＣＩ ＳＩＧによって発行されたＰＣＩ Ｅｘｐｒｅｓｓ Ｂａｓｅ Ｓｐｅｃｉｆｉｃａｔｉｏｎ Ｒｅｖｉｓｉｏｎ ６．０ Ｖｅｒｓｉｏｎ ０．５に見出すことができ、これは参照により本明細書に組み込まれる。

【0011】

エンドポイント：エンドポイントは、ネットワーク通信リンクを介して他のエンドポイントと通信することができるネットワーク通信リンク（例えば、ＰＣＩｅリンク等）上の又はそれに接続された、実際の若しくは仮想の機能ブロック、デバイス及び／又は他の要素である。例えば、エンドポイントは、ネットワーク通信リンク上の他のエンドポイントを含むトランザクションのイニシエータ又はコンプリータであり得る。場合によっては、単一の機能ブロック、デバイス又は要素が、場合によっては仮想化された機能を含む複数の機能を提供又は実施し、その各々をそれ自体のエンドポイントとみなすことができる。

【0012】

（概要）
説明される実施形態では、エンドポイントは、ネットワーク通信リンク、又は、より単純に「リンク」を使用して互いに通信する。例えば、いくつかの実施形態では、一対のエンドポイントは、単一のＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ）リンクを介して互いに通信する。別の例として、いくつかの実施形態では、２つ以上のエンドポイントが２つ以上の個別のＰＣＩｅリンクを介して通信する。更に別の例として、いくつかの実施形態では、２つ以上のエンドポイントは、少なくとも１つのＰＣＩｅリンクを含む２つ以上の個別のネットワーク通信リンク上で、１つ以上の中間機能ブロック又はデバイス（例えば、スイッチ、リピータ、ルートコンプレックス等）を介して互いに通信する。リンクを使用して通信するために、エンドポイントは、エンドポイント間の情報転送の基礎である「トランザクション」を実施する。トランザクションは、メモリトランザクション、入出力（input-output、ＩＯ）トランザクション、構成トランザクション、メッセージングトランザクション等のような、様々な形式の情報転送を含む。トランザクションは、要求側エンドポイント又は「リクエスタ」が、１つ以上のリンクを介して、完了側エンドポイント又は「コンプリータ」に要求を伝送して、コンプリータからアクションを要求し、及び／又は、コンプリータに情報を通信することを含む。要求が応答（例えば、返されたデータ、肯定応答等）を伴う場合、コンプリータは、１つ以上のリンクを介して、リクエスタに応答を返す。

【0013】

説明される実施形態では、リンク上で使用されている通信仕様（又は規格、プロトコル等）は、リクエスタが、要求がリンクを介してコンプリータに伝送される指定された要求パケット内にタグを含むことを規定する。タグは、リクエスタ側から伝送される２つ以上の要求パケットの中から要求パケットを識別するために使用されるリクエスタが要求パケット内（例えば、要求パケットのヘッダ内）に含むマルチビット／バイト値である。通信仕様は、リクエスタからのタグを有する全ての未処理の要求パケットが、リクエスタからの他の未処理の要求パケット内のタグに対して一意のタグを有するべきであることを更に規定する。言い換えれば、ネットワークリンク上、中間デバイスの内部要素内（例えば、バッファ／キュー、処理要素内等）、コンプリータの内部要素内等でインフライト中／伝送中の全ての要求パケット、及び、対応する応答パケットは、一意のタグを有するべきである。したがって、所定のタグを有する要求パケットがリクエスタで生成されてから、応答パケットが所定のタグと共に返されるまで、要求パケットは未処理であると見なされ、通信規格は、リクエスタが所定のタグを再使用すべきではないと規定している。一般に、未処理の要求パケット内のタグは、コンプリータが要求パケットを順不同に処理し、それぞれの要求パケットからのタグを含む応答パケットを、対応する要求パケットが送信された順序に対して順不同に返すことができるように、一意であるべきである。次に、リクエスタは、リクエスタから返された応答パケット内のタグが特定の要求パケットと関連付けられており、リクエスタが同じタグを再使用した後続の要求パケットと関連付けられていないことを保証することができる。

【0014】

通信仕様によれば、任意の所定の時間におけるリクエスタからの未処理の要求パケットは一意のタグを有するはずであるが、問題は、同時にコンプリータの内部要素内にある要求パケットに関してより大きい。リクエスタ及び／又はコンプリータの動作の正確さは、リクエスタとコンプリータとの間でインフライト中の要求パケットが、コンプリータの内部要素内の要求パケットに関して一意のタグを有していない場合に影響を受けるべきではない。言い換えれば、リクエスタ内の要求パケット（例えば、生成されているが未だ送信されていない）、並びに、リクエスタとコンプリータとの間の中間デバイス及びリンク内の要求パケット（すなわち、「インフライト」要求パケット）は、リクエスタ及び／又はコンプリータの誤った動作を引き起こすことなく、コンプリータ内の要求パケットと同じタグを有することができる。これは、インフライト要求パケットがコンプリータの内部要素内に存在せず、したがって、コンプリータの内部要素内の他の要求パケットに関してコンプリータによって再順序付けすることができないために当てはまる。したがって、上述した再順序付けの問題は、そのような複製されたタグを有するインフライトパケットに対しては生じない。したがって、リクエスタからコンプリータに伝送される要求パケットの任意の十分に長いシーケンス内に要求パケットの移動「ウィンドウ」が存在し、要求パケットの各々は、互いに対して一意のタグを有するはずである。要求パケットのウィンドウは、コンプリータの内部要素を満たす／占有するのに十分な要求パケットを含む。例えば、コンプリータがその内部要素に最大１００個の要求パケットを保持／記憶することができる場合、ウィンドウは、１００個の要求パケット（すなわち、１００個の要求パケット「ワイド」又は「ロング」である）を含む。しかしながら、所定のウィンドウの外側にある要求パケット内のタグは、リクエスタ及び／又はコンプリータの誤った動作を引き起こすことなく、所定のウィンドウの内側のタグの複製であり得る。

【0015】

説明される実施形態では、リクエスタは、インフライト要求パケットのタグが、コンプリータ内の内部要素内のタグの複製であり得る、すなわち、それに関して一意である必要がないという事実を利用して、既存のリクエスタが強制的に停止させられる状況において、要求パケットをコンプリータに送信し続ける。リクエスタは、通信規格のルールに違反して、要求パケットが送信されている間、すなわち要求パケット自体がコンプリータの内部要素内にある前に、コンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに関して一意ではないタグを有するコンプリータに要求パケットを送信し続けることによって、これを行う。しかしながら、要求パケット内のタグに関する上述した通信仕様ルールによって対処される再順序付け問題を回避するために、リクエスタは、要求パケット内のタグが、要求パケットと共にコンプリータの内部要素内にある他の要求パケット内のタグに対して一意であることを確実にする。言い換えれば、移動ウィンドウの例を続けると、説明される実施形態では、所定のウィンドウ内の要求パケット内のタグは互いに対して一意であるが、所定のウィンドウ外の要求パケット内のタグは、所定のウィンドウ内の要求パケット内のタグに対して一意であることが確実ではない。

【0016】

いくつかの実施形態では、リクエスタは、要求パケット内のタグが、要求パケットと同時にコンプリータの内部要素内にある他の要求パケット内のタグに対して一意であることを確実にするために、順次タグ（sequential tags）を使用する。これらの実施形態では、リクエスタは、タグを有する要求パケットを保持／記憶するためのコンプリータの内部要素の容量が、許容可能なタグの数よりも小さいことを知っているか又は仮定している。したがって、要求パケットをコンプリータに送信する場合に、リクエスタは、それぞれの順次タグを有する要求パケットのシーケンスで要求パケットを送信し、最も高い許容可能なタグが要求パケットに含まれると、最も低い許容可能なタグからやり直すか、さもなければ、（例えば、グレイコード等を使用して）パケットのタグのシーケンスを再開する。例えば、３ビットタグが使用される実施形態では、タグ０００、００１、０１０、．．．１１０、１１１を有する要求パケットは、リクエスタにとって未処理であり得るが、リクエスタは、０００から開始するタグを有する要求パケットを送信し続けることができる。換言すれば、リクエスタは、各許容可能なタグが未処理の要求パケットに含まれているにもかかわらず、要求パケットの送信を中止しないが、その代わりに、タグを有する要求パケットを順次自動的に送信し続ける。要求パケットを保持／記憶するためのコンプリータの内部要素の容量は、許容可能なタグの数よりも小さいので、これらの実施形態は、任意の所定の時間におけるコンプリータの内部要素内のタグのシーケンス／順次タグが、互いに対して一意であることを確実にするか又は仮定することができる。

【0017】

いくつかの実施形態では、順次タグを使用する上記の実施形態とは異なり、要求パケットをコンプリータに送信する場合に、リクエスタは、何れのタグが要求パケット内で使用され得るかを決定する。一般的には、この動作のために、リクエスタは、要求パケットがコンプリータに到着した場合（すなわち、要求パケットがコンプリータの内部要素に取り込まれる直前）に、コンプリータの内部要素がリクエスタからの要求パケットで満たされるかどうかを決定する。移動ウィンドウの例を続けると、リクエスタは、したがって、要求パケットの全ウィンドウが要求パケットの到着時にコンプリータにあるかどうかを決定する。そうである場合、リクエスタは、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないタグを有する要求パケットを送信することができる。そうでない場合、リクエスタは、要求パケットがコンプリータの内部要素内にある間にコンプリータの内部要素内にあるリクエスタからの他の要求パケット内のタグに対して一意であるタグを有する要求パケットを送信する。すなわち、リクエスタは、所定のウィンドウ内で要求パケットを生成して送信する。

【0018】

いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、所定の数の要求パケットが、対応する応答パケットを受信することなくコンプリータに送信されたかどうかを決定する。いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、要求パケットの送信リンク／内部要素待ち時間に関する情報を使用する。これらの実施形態における送信リンク／内部要素待ち時間は、要求パケットが送信リンク及びコンプリータの内部要素を通過する／そこに存在すると予想される最大合計又は平均典型的時間である。いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、コンプリータ内の中間ネットワークデバイス及び／又は内部要素の配置又は構成に関する情報を使用する。例えば、リクエスタは、中間ネットワークデバイス及び／又はコンプリータの内部要素（すなわち、要求パケットが中間ネットワークデバイス及び／又はコンプリータの内部要素に記憶され得る回路）に要求パケットを記憶又はバッファリングするための最大容量又は今／現在の容量に関する情報を使用することができる。

【0019】

いくつかの実施形態では、リクエスタは、本明細書で説明するように、要求パケット内のタグを使用するように選択的に構成され得る。言い換えれば、要求パケットにおける非一意のタグの上記の使用は、例えば、インストール時、製造時、ランタイム時及び／又は別の時に、有効及び無効にすることができる。これらの実施形態では、リクエスタは、要求パケット内のそのようなタグの使用を有効又は無効にするハードウェア又はソフトウェアスイッチ又は構成設定を提供する。例えば、いくつかの実施形態では、ハードウェアスイッチは、スイッチ回路、ヒューズ等であるか、又は、それらを含む。ハードウェア又はソフトウェアスイッチ又は構成設定が無効にされる場合に、リクエスタは、既存のデバイスにおけるように要求パケットのためのタグを使用し、したがって、未処理のままである要求パケット内の許容可能なタグの全てを使用すると、要求パケットの伝送を停止する。対照的に、ハードウェア又はソフトウェアスイッチが有効にされる場合に、リクエスタは、本明細書で説明するように、未処理の要求パケットに対して非一意のタグを使用することができる。

【0020】

いくつかの実施形態では、リクエスタは、十分に高いレートで要求パケットを送信し、及び／又は、リクエスタとコンプリータとの間のリンクの待ち時間は、本明細書で説明されるような非一意のタグを使用して要求パケットを送信し続けるためにインフライトパケットを利用することが、リクエスタが送信することができる要求パケットの数の増加につながり得るほど（例えば、より多くの中間デバイス、より長い物理リンク長等に起因して）十分に長い。リクエスタがより多くの要求パケットを送信することができる（したがって、メモリからデータを取得し、より迅速にＩＯデバイスにデータを送信し、又は、ＩＯデバイスからデータを受信することができる等）場合に、リクエスタの性能が向上する。リクエスタの性能の向上は、リクエスタが含まれる電子デバイスの全体的な性能を向上させることができ、それによって、ユーザ満足度を向上させる。

【0021】

（ネットワーク通信リンク）
説明される実施形態では、リクエスタ及びコンプリータは、ネットワーク通信リンクを介してトランザクションを実施する。図１は、いくつかの実施形態による、ネットワーク通信リンク１００を示すブロック図である。図１に見られるように、ネットワーク通信リンク１００は、リンク１０６を介して接続されたリクエスタ１０２及びコンプリータ１０４を含む。リクエスタ１０２及びコンプリータ１０４は、リンク１０６上でトランザクションを実施する機能ブロック、デバイス及び／又は他の要素であるか、又は、それらに組み込まれるエンドポイントである。例えば、いくつかの実施形態では、リクエスタ１０２は、グラフィックス処理ユニット（ＧＰＵ）又は中央処理ユニット（central processing unit、ＣＰＵ）等の機能ブロックであり、コンプリータ１０４は、メモリコントローラ又はネットワークインターフェース等の機能ブロックである。これらの実施形態のいくつかにおいて、リクエスタ１０２及びコンプリータ１０４は、同じ又は個別の半導体チップ上の集積回路に実装される。別の例として、いくつかの実施形態では、リクエスタ１０２は、電子デバイス（例えば、デスクトップコンピュータ、サーバコンピュータ等）内のバス又はインターフェースに差し込まれるか接続されたグラフィックスカード又は周辺カードであり、コンプリータ１０４は、同様にバス又はインターフェースに差し込まれるか接続されたメモリコントローラである。

【0022】

説明する実施形態では、リクエスタ１０２及びコンプリータ１０４は、リンク１０６を介して要求パケット及び／又は応答パケット等のパケットを送信及び受信するための内部要素、すなわち回路、デバイス等を含む。例えば、内部要素は、要求及び／又は応答パケットを受信するための受信要素と、要求及び／又は応答パケットを処理するための処理要素と、要求及び／又は応答パケットを伝送するための伝送要素と、を含むことができる。内部要素に含まれる特定の回路、デバイス等は、内部要素によって扱われ処理されるパケットの性質、及び、内部要素によって実施される動作に依存する。例えば、いくつかの実施形態では、要求及び／又は応答パケットを受信するための受信要素は、パケットを記憶するためのバッファ又はメモリ回路、パケット情報をチェックし、後続の処理動作のためにパケットを準備するための処理回路、パケット（又はその一部）をその中で処理するために処理回路に方向付けるためのステアリング回路、パケット（又はその一部）を処理又は取り扱うための処理回路等を含むことができる。

【0023】

リンク１０６は、リクエスタ１０２とコンプリータ１０４との間でパケットを伝送するために使用される信号経路（例えば、ワイヤ、ガイド、バス等）を含む。例えば、いくつかの実施形態では、リクエスタ１０２及びコンプリータ１０４は、集積回路を使用して半導体チップに実装された機能ブロックであり、リンク１０６は、半導体チップに実装されたワイヤ、ガイド又はトレースを含む。別の例として、いくつかの実施形態では、リクエスタ１０２及びコンプリータ１０４は、データセンタ内の機能ブロック又はデバイスであり、リンク１０６は、１つ以上の回路基板及び／若しくはパッケージ上のワイヤ、ガイド若しくはトレース、並びに／又は、回路基板及び／若しくはパッケージ間のワイヤ、ガイド若しくはトレースを含む。

【0024】

図１に示す実施形態では、リンク１０６は、送信方向にパケットを伝送し、受信方向にパケットを受信するための別々の単方向シグナリング経路を含む（なぜなら、各方向に単方向信号経路が存在し、２つのシグナリング経路の何れが送信／受信方向にあるかは、視点がリクエスタ１０２からであるかコンプリータ１０４からであるかに依存するからである）。例えば、いくつかの実施形態では、信号経路の各々は、単方向差動リンクである。リクエスタ１０２及びコンプリータ１０４の各々は、それぞれの伝送リンク又は受信リンク上でパケットを伝送又は受信するための回路（例えば、バッファ、ドライバ、センス増幅器等）を含む、それぞれのリンクインターフェース１０８又は１１０を含む。

【0025】

ネットワーク通信リンク１００は、特定の要素と共に図１に示されているが、いくつかの実施形態では、ネットワーク通信リンク１００は、異なる要素又は異なって配置された要素を含む。例えば、単一の伝送及び受信リンク対で示されているが、いくつかの実施形態では、リンク１０６は、リクエスタ１０２とコンプリータ１０４との間でパケットを伝送するために一緒に又は別々に使用することができる、２つ以上の伝送及び受信リンク対（各送信及び受信リンク対は「レーン」と呼ぶことができる）を含む。別の例として、いくつかの実施形態では、図１ではリクエスタ及びコンプリータとラベル付けされているが、リクエスタ１０２は、コンプリータであってもよく、コンプリータ１０４は、リクエスタであってもよい。概して、説明する実施形態では、ネットワーク通信リンク１００は、本明細書で説明する動作を実施するように適切に構成された十分な機能ブロック及び要素を含む。

【0026】

ネットワーク通信リンク１００は、本明細書に記載された動作を実施する任意のデバイスに全体的又は部分的に含まれ得る。例えば、ネットワーク通信リンク１００の一部又は全ては、デスクトップコンピュータ、ラップトップコンピュータ、ウェアラブルコンピューティングデバイス、タブレットコンピュータ、ネットワーク、通信サブシステム若しくはチャネル、仮想現実若しくは拡張現実機器の一部、仮想若しくは拡張現実機器、スマートフォン、人工知能（artificial intelligence、ＡＩ）若しくは機械学習デバイス、サーバ、ネットワーク機器、玩具、視聴覚機器、家電、車両等、及び／又は、それらの組み合わせであってもよいし、それらに含まれてもよい。言い換えれば、これらのデバイスは、（例えば、半導体チップ内又は半導体チップ間に）ネットワーク通信リンク１００を完全に含むことができ、又は、ネットワーク通信リンク１００上のリクエスタ及び／若しくはコンプリータとすることができる。

【0027】

（トポロジ）
いくつかの実施形態では、エンドポイント（すなわち、機能ブロック、デバイス及び他の要素）は、いくつかのエンドポイントを含むネットワークトポロジの一部であり、エンドポイントのうち少なくともいくつかは、トポロジ内の他のエンドポイントに対してリクエスタ及び／又はコンプリータとして機能する。また、トポロジは、エンドポイント及び／又は他の中間デバイスの間のいくつかの中間デバイスを含み得る。図２は、いくつかの実施形態による、トポロジ２００を示すブロック図である。図２に見られるように、トポロジ２００は、計算、制御、メモリアクセス、入出力及び他の動作を実施するマイクロプロセッサ又はマイクロプロセッサコア等の機能ブロック又はデバイスである中央処理装置（ＣＰＵ）２０２を含む。また、トポロジ２００は、データ（「データ」は、実際のデータ、命令、制御値等を記述するための総称である）を記憶するためのダイナミックランダムアクセスメモリ（dynamic random access memory、ＤＲＡＭ）等のメモリ回路と、メモリ回路におけるデータのアクセスを制御するための制御回路と、を含む機能ブロック又はデバイスであるメモリ２０４を含む。

【0028】

トポロジ２００は、グラフィックス処理ユニット（ＧＰＵ）又はグラフィックス処理ユニットコア、入出力（ＩＯ）デバイス又はそれへのインターフェース（例えば、ネットワークインターフェース、ディスクコントローラ等）、レガシーデバイス等の機能ブロック、デバイス又は要素を含むエンドポイント２０６～２１４を更に含む（「レガシー」デバイスは、トポロジ２００内の他のリンク上で使用されている通信仕様とは異なる通信仕様（又は規格、プロトコル等）を使用することができることに留意されたい）。いくつかの実施形態では、エンドポイント２０６～２１４の一部又は全てが考慮される自発的に又は他のデバイス（例えば、ＵＳＢコントローラ等）（図示せず）に代わって、トランザクションのリクエスタ及び／又はコンプリータであり得る「機能」。これらの実施形態のうちいくつかにおいて、単一の機能ブロック、デバイス又は要素は、複数の機能（仮想化された機能を含む）を提供又は実施し、その各々は、それ自体のエンドポイントと見なされ得る。

【0029】

トポロジ２００は、中央処理装置２０２及びメモリ２０４が、それぞれのエンドポイント２０６～２１４及びトポロジ２００内の他のデバイスを含む様々なドメインに接続される階層の「ルート」又は最下位レベルにおける機能ブロック又はデバイスであるルートコンプレックス２１６を更に含む。いくつかの実施形態において、ルートコンプレックス２１６は、スイッチ又はルータの動作を実施し、中央処理装置２０２、メモリ２０４及びエンドポイント２０６～２１４の間で（エンドポイント２０８～２１４に対するスイッチ２１８～２２０の一方又は両方を介して）パケットをルーティング及び他の方法で制御／処理し、その逆も同様である。いくつかの実施形態では、ルートコンプレックス２１６は、他の中間デバイス（すなわち、スイッチ、ルータ、リピータ等）によって実施されることが許可されない動作、例えば、前方送信のためにパケットを再分割すること等を実施することが許可される。いくつかの実施形態では、ルートコンプレックス２１６は、メモリのためのコンプリータであり、メモリの代わりにメモリアクセストランザクションを処理する。

【0030】

トポロジ２００は、中央処理装置２０２、メモリ２０４及びエンドポイント２０６～２１４の間でパケットをスイッチング又はルーティングするための動作を実施する機能ブロック、デバイス又は他の要素であるスイッチ２１８及び２２０を更に含む。いくつかの実施形態では、スイッチング／ルーティング動作を実施するとともに、スイッチ２１８及び２２０の一方又は両方は、レガシー及び／又は互換性のないエンドポイントからのパケット、メッセージ又は他のネットワークトラフィックが、ルートコンプレックス２１６で使用されている通信仕様に変換されるブリッジ動作又は変換動作を実施する。例えば、いくつかの実施形態では、エンドポイント２０８は、レガシーＰｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔデバイスであり、ルートコンプレックス２１６は、ＰＣＩｅを使用し、スイッチ２１８は、エンドポイント２０８とルートコンプレックス２１６との間の通信のために、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ ＩｎｔｅｒｃｏｎｎｅｃｔパケットをＰＣＩｅパケットに変換又はブリッジし、逆も同様である。

【0031】

トポロジ２００は、トポロジ２００内の各機能ブロック、デバイス又は要素の間のリンク２２２を更に含む（図２で双頭矢印を使用して示されているリンク２２２のうち２つだけが、明確にするためにラベル付けされている）。各リンク２２２は、リンク１０６に示されているような単方向送信及び受信リンクの少なくとも１つの対、場合によっては複数の個別の対を含む。例えば、いくつかの実施形態では、エンドポイント２０６は、１６レーンリンク２２２によってルートコンプレックス２１６に接続されたＧＰＵであり、したがって、１６個の個別の単方向送受信対を有する。

【0032】

いくつかの実施形態では、トポロジ２００において伝送される場合、通信（すなわち、要求パケット、応答パケット等）は、リクエスタからコンプリータに及びその逆に横断（トラバース）する場合に、複数のリンク２２２を横断し得る。例えば、リクエスタとしてのエンドポイント２１２が、コンプリータとしてのメモリ２０４からのメモリアクセスを要求している場合、要求パケットは、エンドポイント２１２とスイッチ２２０との間、スイッチ２２０とスイッチ２１８との間、スイッチ２１８とルートコンプレックス２１６との間、及び、ルートコンプレックス２１６とメモリ２０４との間のリンク２２２を横断する。メモリアクセスがメモリ読み取りである（ひいては、メモリ２０４からのデータの返信を要求する）場合、メモリ２０４からの応答パケットは、エンドポイント２１２までリンク２２２を逆に横断する。いくつかの実施形態では、複数のリンクを横断するための待ち時間は、比較的長い。例えば、エンドポイント２１２とメモリ２０４との間等のようなリクエスタとコンプリータとの間にいくつかの中間デバイスがあってもよい。別の例として、リクエスタとコンプリータとの間のリンクの一部又は全ては、パケットが移動しなければならない（例えば、より大きなサーバファーム内のサーバボックス／エンドポイント間等）例えば、より長いワイヤ、ケーブル等を有して、物理的に長くてもよい。いくつかの実施形態では、リクエスタは、要求パケットが比較的長い時間にわたってインフライト中であり得る（すなわち、中間デバイス及び／又はリンク内にある）という事実を利用して、本明細書で説明されるように、非一意のタグを用いて要求パケットをコンプリータに送信し続ける。

【0033】

トポロジ２００は、機能ブロック、デバイス及び／又は他の要素の特定の配置で示されているが、いくつかの実施形態では、トポロジ２００は、異なる機能ブロック、デバイス及び／若しくは他の要素、並びに／又は、異なるように配置された機能ブロック、デバイス及び／若しくは他の要素を含む。例えば、いくつかの実施形態では、トポロジ２００は、図１に示されるようなエンドポイント間の単純なエンドポイントツーエンドポイント接続であるか、又は、（図２の省略記号を介して示されるように）より多くのエンドポイント及び／又は中間デバイスを有する複雑なトポロジである。別の例として、いくつかの実施形態では、トポロジ２００は、複数の層及び／又はスイッチ若しくは他の中間デバイスの他の配置（例えば、より大きなクロスバースイッチ等を有する）を含む。概して、説明される実施形態では、トポロジ２００は、本明細書で説明されるように、要求パケットにタグを含めるための動作を実施する１つ以上のリクエスタエンドポイントを含む。

【0034】

（トランザクション）
説明される実施形態では、リクエスタ（例えば、リクエスタ１０２、エンドポイント２０６等）は、リンク（例えば、リンク１０６、リンク２２２等）を介してコンプリータ（例えば、コンプリータ１０４、エンドポイント２１２等）とのトランザクションを開始し、コンプリータは、トランザクションを実施又は「完了」する。概して、トランザクションは、リクエスタとコンプリータとの間で情報を転送するための動作である。例えば、いくつかの実施形態では、リクエスタ及びコンプリータは、メモリトランザクションを実施し、そのために、リクエスタは、コンプリータ内の又はコンプリータと関連付けられたメモリ（例えば、ダイナミックランダムアクセスメモリすなわちＤＲＡＭ）からデータを読み取るか、メモリにデータを書き込む。別の例として、いくつかの実施形態では、リクエスタ及びコンプリータは、入出力（ＩＯ）トランザクションを実施し、そのために、リクエスタは、コンプリータ内の若しくはコンプリータと関連付けられたＩＯ機能ブロック若しくはデバイス（例えば、ディスクコントローラ、ネットワークインターフェース等）からデータを取得するか、ＩＯ機能ブロック若しくはデバイスにデータを送信する。更に他の例として、いくつかの実施形態では、リクエスタ及びコンプリータは、構成及び／又はメッセージングトランザクションを実施し、そのために、リクエスタは、構成情報及び／又はメッセージ情報をコンプリータに通信する。

【0035】

トランザクションの場合、リクエスタは、１つ以上のリンクを介してコンプリータに要求を伝送して、コンプリータからアクションを要求し及び／又はコンプリータに情報を通信する。例えば、リクエスタがグラフィックス処理ユニットであり、コンプリータがメモリと関連付けられたメモリコントローラであり、トランザクションがメモリアクセスであると仮定すると、グラフィックス処理ユニットは、１つ以上のリンクを介してメモリコントローラに、メモリ内の場所から指定されたデータを読み取るか又はメモリ内の場所に指定されたデータを書き込むためのメモリアクセス要求を含む要求パケットを伝送することができる。いくつかの実施形態では、要求パケットをコンプリータに伝送することは、要求パケットが１つ以上の中間デバイス（例えば、エンドポイント２１０からメモリ２０４への要求パケットのためのルートコンプレックス２１６及びスイッチ２１８等）及びそれぞれのリンクを通過する（すなわち、それらによって受信及び転送される）ことを含む。要求が応答を伴う場合、コンプリータは、１つ以上のリンクを介して、リクエスタに応答を返す。グラフィックス処理ユニット／メモリコントローラの例を続け、及び、メモリアクセス要求がメモリ内の場所から指定されたデータを読み取る要求であったと仮定すると、メモリコントローラは、１つ以上のリンクを介して、メモリからの要求されたデータを含む応答パケットをグラフィックス処理ユニットに伝送することができる。

【0036】

（要求及び応答パケット内のタグ）
説明される実施形態では、トポロジ（例えば、トポロジ２００）内のリンク上で使用されている通信仕様（又は規格、プロトコル等）が、リクエスタが、コンプリータに要求を通信するために使用される指定された要求パケット内にタグを含むことを規定する。例えば、いくつかの実施形態では、リクエスタは、（例えば、メモリアクセス、ＩＯデータアクセス等のために）コンプリータがリクエスタに応答を送信するためのタグを要求パケットに含める。これらの実施形態のいくつかにおいて、要求パケットからのタグのコピーは、コンプリータによって、リクエスタに送信される対応する応答パケットに含まれる。タグは、応答パケットが関連付けられる要求パケットを識別すること、２つ以上の異なる応答パケット間の順序又は他の関係を決定すること、応答パケットが受信された要求パケットを決定すること等のような動作のために、リクエスタ及び／又はコンプリータによって使用され得る。

【0037】

図３は、いくつかの実施形態による、要求パケット３００を示すブロック図である。図３から分かるように、要求パケット３００は、ヘッダ情報（information、ＩＮＦＯ）３０４及びタグ３０６を有するヘッダ３０２を含む。（例えば、要求パケット３００の第１のバイトから始まる）要求パケット３００の第１の部分に含まれ得るヘッダ３０２は、概して、要求パケット３００のタイプ及び特性を識別するために、コンプリータ、すなわち、受信機能ブロック、デバイス及び／又は要素、並びに、他のネットワークデバイスによって使用される情報を含む。ヘッダ情報３０４は、要求パケットの可能なタイプのセットの中の要求パケットのタイプ、要求パケットを処理又は取り扱うための制御値、通信仕様バージョン値、サービス品質値等、要求パケット３００のタイプ及び特性を識別する情報を含む。リクエスタは、要求パケット３００を生成する場合に、要求パケット３００のタイプ及び特性を識別する情報を生成、決定又は取得し、ヘッダ情報３０４内の対応するフィールド／特定のビットに情報を記憶する。例えば、要求パケットのタイプは、ヘッダ情報３０４の第１のバイトから始まる１つ以上の連続又は非連続バイトに記憶され、したがって、コンプリータ又は他のネットワークデバイスによってヘッダ情報３０４から読み取られる第１の又は初期の情報であり得る。

【0038】

タグ３０６は、所定のリクエスタからコンプリータに送信される複数の要求パケットの中から要求パケットを識別するために使用される値であるか、それを含む。例えば、いくつかの実施形態では、タグ３０６は、ヘッダ３０２内のバイト及び／又はビットの連続又は非連続シーケンス内に含まれる許容可能なＮビット値（ここで、Ｎ＝１０、１６又は別の数）のセットの中からのＮビット値である。例えば、いくつかの実施形態では、要求パケット３００は、ＰＣＩｅ要求パケットであり、タグ３０６は、トランザクション記述子の一部としてヘッダ３０２に含まれ、トランザクション記述子は、タグ３０６と、ネットワークトポロジ内のエンドポイント間でリクエスタを識別するリクエスタ識別子（identifier、ＩＤ）と、を含む。要求パケット３００を生成する場合に、リクエスタは、タグ３０６の値を生成、決定又は取得し、タグ３０６をヘッダ３０２内の対応するバイト及び／又はビットに記憶する。タグ３０６は、図３では単一のブロック又はフィールドとして示されているが、タグ３０６又はその一部は、ヘッダ３０２内の他のブロック又はフィールド間に分散又はインターリーブされてもよいことに留意されたい。

【0039】

また、要求パケット３００は、ペイロード３０８を含み、これは、完了デバイスに宛てられたデータ及び／又は情報が含まれる要求パケット３００の一部又はセクションである。例えば、要求パケット３００が、メモリコントローラコンプリータに宛てられたメモリ書き込みの要求である場合、ペイロード３０８は、メモリに書き込まれる１バイト以上のデータを含むことができる。要求パケット３００はペイロード３０８と共に示されているが、特定のパケットは、ペイロードを含まない。例えば、コンプリータが要求パケット３００を処理又は取り扱うために必要な情報の全てをヘッダ３０２が含む要求パケット３００は、ペイロードを欠く場合がある。

【0040】

要求パケットとともに、いくつかの実施形態では、通信仕様は、コンプリータが、リクエスタに応答を通信するために使用される特定の応答パケット内にタグを含むことを規定する。例えば、いくつかの実施形態では、（例えば、メモリアクセス、ＩＯデータアクセス等のための）所定の要求パケットに応じてリクエスタに応答パケットを伝送する場合に、コンプリータは、所定の要求パケット（又はそれに基づく情報）から取得されるタグのコピーを応答パケットに含めることになる。上述したように、これにより、リクエスタが応答パケット／応答を要求パケット／要求と関連付けることを可能にすることができる。応答パケットが図３に示されていないが、いくつかの実施形態では、応答パケットは、要求パケット３００と同様に構成されている。言い換えれば、応答パケットは、要求パケット３００に示される同じフィールド及び情報並びに／又はフィールド及び情報の配列の一部又は全てを含む。例えば、いくつかの実施形態では、応答パケットは、図３に示されるものに類似するそのヘッダ内のタグ、ペイロード等を含むことができる。

【0041】

ここで、通信仕様によって規定されるようなタグの使用に戻ると、説明される実施形態では、通信仕様は、リクエスタからのタグを含む全ての未処理の要求パケットが、そのリクエスタからの他の未処理の要求パケット内のタグに対して一意のタグを有するべきであることを更に規定する。例えば、４ビットタグが要求パケットにおいて使用される場合、０１１０（又は任意の他の許容可能な４ビット値）のタグを伴う要求パケットが未処理である場合、他の未処理の要求パケットは、０１１０のタグを有するべきではない。言い換えれば、任意の所定の時間に、通信仕様に従って、リクエスタからの各未処理の要求パケットは、そのリクエスタからの他の要求パケット内のタグとは異なるタグを有するはずである。本明細書で使用されるように、要求パケットは、リクエスタが要求パケットを生成する（すなわち、要求パケット内にタグを含む）ときと、タグが応答パケット内でコンプリータからリクエスタに返されるときとの間で「未処理」である。これは、要求パケットがリクエスタによって生成され、リクエスタの内部要素内にある（例えば、送信を待っている）後のリクエスタとコンプリータとの間のリンク上でインフライト中、中間デバイスの内部要素内、コンプリータの内部要素内等を含む。更に、本明細書で使用される場合、「内部要素」は、要求パケットを受信するための受信要素／回路、要求パケットを処理し、方向付け又は他の方法で処理するための処理要素／回路、及び、応答パケットを送信するための伝送要素／回路（例えば、インターフェース回路、バッファリング回路、ルーティング回路、スケジューリング回路、処理回路等）の一部又は全てを含む。

【0042】

説明される実施形態では、リクエスタからのコンプリータの内部要素内の要求パケットが互いに対して一意のタグを有するという通信仕様の上記の要件が、特定の誤った／不正確な動作を回避するために使用される。例えば、いくつかの実施形態では、コンプリータは、順序が狂った要求パケットを処理し、したがってそれに応答することができる。したがって、同一のタグを有する２つの要求パケットがコンプリータの内部要素に存在する場合、コンプリータは、第２の／後の要求パケットを第１の要求パケットに対して順序をずらして処理することが可能である。この場合、コンプリータが要求パケットからのタグを応答パケットに含めるので、リクエスタは、第２の要求パケットに対する応答パケットを第１の要求パケットに誤って関連付ける可能性がある。しかしながら、リクエスタとコンプリータとの間で「インフライト中」である要求パケット及び対応する応答パケットは、コンプリータの内部要素内に未だ存在せず、したがって、コンプリータによる再順序付けの可能性にさらされない。したがって、インフライト中の要求パケットは、コンプリータの内部要素内の要求パケットに関して一意のタグを有する必要はない。要求パケットは、要求パケットが生成されたがリクエスタによって未だ伝送されていない場合、要求パケットがリンク上で伝送されている場合、及び／又は、リクエスタとコンプリータとの間の送信経路のリンク上の中間デバイスの内部要素内にある場合に、インフライト中であると見なされる。したがって、リクエスタから送信された要求パケットの十分に長いシーケンス内に要求パケットの移動「ウィンドウ」（又はセット、ブロック、部分等）があり、要求パケットの各々は、上述した再順序付け問題を回避するために、他の要求パケットに対して一意のタグを有するべきである。「ウィンドウ」は、コンプリータの内部要素を満たすのに十分な所定の数の要求パケットを含む。例えば、コンプリータの内部要素が２５個の要求パケットを保持することができると仮定すると、ウィンドウは、２５個の要求パケットのサイズである。したがって、２５０個の要求パケットのシーケンスでは、ウィンドウはシーケンスの約１０％を占める。要求パケットは最終的にコンプリータによって処理され、対応する応答パケット（タグ付き）がリクエスタに返されるので、ウィンドウは「移動」している。ウィンドウ内の要求パケットが処理され、したがって、もはやコンプリータの内部要素内に存在しなくなると、コンプリータは、異なるウィンドウ内の後続の要求パケットをその場所で受信することができる。しかしながら、各ウィンドウの外側の要求パケット内のタグは、そのウィンドウの内側のタグに対して一意である必要はない。

【0043】

説明される実施形態では、リクエスタは、既存のリクエスタがタグを使い果たし、強制的に停止させられる状況において要求パケットを送信し続けるために、インフライト要求パケットのタグがコンプリータ内の内部要素内のタグに対して非一意であり得るという事実を利用する。既存の要求元では、例えば、各許容可能なタグを含む要求パケットのシーケンス（例えば、１０ビットタグに対して１０２４個の要求パケット等）がコンプリータに伝送され、対応する応答が受信されなかった場合、リクエスタは、後続の要求パケットを伝送する際に再使用するためにタグ値を解放するために、リクエスタからの応答の返信を待つために停止する。対照的に、説明される実施形態では、各許容可能なタグを含む要求パケットのシーケンスがコンプリータに伝送された場合に、リクエスタは、要求パケットが最初にコンプリータに到着したとき（すなわち、要求パケット自体がコンプリータの内部要素内にある直前）に、コンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに関して一意ではないタグを有する要求パケットをコンプリータに送信し続けることができる。しかしながら、リクエスタがコンプリータに送信する要求パケット内のタグは、要求パケットがコンプリータの内部要素内にある場合にコンプリータの内部要素内にあるリクエスタからの他の要求パケット内のタグに対して一意である。言い換えれば、移動ウィンドウの例を上記から続けると、任意の所定のウィンドウ内の要求パケット内のタグは互いに一意であるが、一方で、所定のウィンドウ外のタグは、その所定のウィンドウ内のタグに対して一意であることが確実にされない。通信規格のルールに違反する一方で、リクエスタは、複製されたタグを有する要求パケットの再順序付けの問題を回避し、要求パケットのインフライト時間（すなわち、リクエスタ及びリンク及び中間デバイスの待ち時間）を利用して、追加の要求パケットを伝送する。

【0044】

いくつかの実施形態では、要求パケットをコンプリータに送信する前に、リクエスタは、通信仕様に従って様々な情報（例えば、ヘッダ情報、ペイロード（必要な場合）等）を含む要求パケットを生成する。リクエスタは、要求パケットを生成する一環として、要求パケットに含めるべきタグを選択する。例えば、タグを選択することは、リクエスタによって保持されるタグカウンタを次の値に進め、タグカウンタの値をタグとして使用すること、又は、タグの値のシーケンス内の次の値（例えば、グレイコード等）を使用することを意味し得る。別の例として、タグを選択することは、１つ以上のルール又はアルゴリズム（例えば、最低の利用可能なタグ値等）に従って、利用可能な「プール」又はタグのセットからタグを取得することを意味し得る。タグのプールが使用される実施形態では、応答パケット内でリクエスタに返されるタグは、タグのプールに返され、それによって、後続の要求パケット内での使用のために自由に利用可能にされる（すなわち、全ての要求パケット内での使用のために利用可能にされる）。

【0045】

いくつかの実施形態では、タグを選択するためのプロセスの一部として、リクエスタは、タグが要求パケットにおける使用のために許可されるかどうかを決定する。タグが許容されるかどうかを決定するために、リクエスタは、要求パケットがコンプリータに到着した場合に（すなわち、要求パケット自体がコンプリータの内部要素に取り込まれる直前に）、コンプリータの内部要素がコンプリータの内部要素内のリクエスタからの他の要求パケット内のタグに対して一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定する。移動ウィンドウの例を続けると、リクエスタは、要求パケットの全ウィンドウが要求パケットの到着時にコンプリータ内にあるかどうかを決定する。コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされる場合、リクエスタは、コンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないタグを有する要求パケットを送信することができる。したがって、リクエスタは、後続のウィンドウに対するタグを有する要求パケットを生成し、送信する。一方、他の要求パケットがコンプリータに到着した場合に、コンプリータの内部要素がリクエスタからの要求パケットで満たされない場合、リクエスタは、コンプリータの内部要素内にあるリクエスタからの他の要求パケット内のタグに対して一意であるタグを有する要求パケットを送信する。すなわち、リクエスタは、所定のウィンドウ内にあるタグを有する要求パケットを生成し、送信する。

【0046】

（要求パケット内のタグを使用するためのプロセス）
説明される実施形態では、リクエスタは、リクエスタとコンプリータとの間のトランザクションを開始又は継続するための要求パケットをコンプリータに送信する。リクエスタは、リクエスタがコンプリータに送信する要求パケットのうち要求パケットを識別するために使用されるタグを要求パケットに含める。図４は、いくつかの実施形態による、タグを伴う要求パケットをコンプリータからリクエスタに送信するためのプロセスを示すフローチャートである。図４は、いくつかの実施形態においてリクエスタによって実施される動作の一般的な例として提示される。しかしながら、いくつかの実施形態では、リクエスタは、異なる動作を実施し、及び／又は、異なる順序で動作を実施する。

【0047】

図４の動作は、リクエスタが、コンプリータに、要求パケットがコンプリータの内部要素内にある前にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないが、要求パケットがコンプリータの内部要素内にある間にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意であるタグを有する要求パケットを送信すること（ステップ４００）を含む。この動作のために、リクエスタ、例えば、リクエスタによって実行されるハードウェア回路及び／又はソフトウェア／ファームウェアは、コンプリータとのトランザクションを開始するために要求パケットがコンプリータに送信されるべきであると決定する。例えば、リクエスタは、グラフィックス処理ユニット又は入出力デバイスであってもよく、リクエスタは、コンプリータ内のメモリ又はコンプリータと関連付けられたメモリに記憶されたデータにアクセスする必要がある場合がある。したがって、リクエスタは、トランザクションを識別し実施するためにコンプリータによって使用される情報を含む要求パケット（例えば、要求パケット３００）を生成する。次に、リクエスタは、リクエスタとコンプリータとの間のネットワークリンクを介して、要求パケットをコンプリータに送信する。

【0048】

ステップ４００について説明したように、リクエスタによって要求パケット内に含まれるタグは、要求パケットと同時にコンプリータの内部要素内にある他の要求パケット内のタグに対して一意であるが、要求パケットがコンプリータの内部要素内にある前にコンプリータの内部要素内にある他の要求パケット内のタグに対しては一意ではない。図５は、いくつかの実施形態による、リクエスタ５００からコンプリータ５０２に送信される要求パケットを示すブロック図である。要求パケットを記憶／保持するための特定のタグ値、デバイス／要素及び内部容量が図５に例として示されているが、いくつかの実施形態では、要求パケットを記憶／保持するための異なるタグ値、デバイス／要素、及び／又は、内部容量が使用される。

【0049】

図５の例では、３つのビットタグが使用されると仮定される。換言すれば、各要求パケットは、３ビット長のタグを含み、したがって、８つの可能なタグ値がある。コンプリータ５０２の内部要素は、７つの要求パケットを同時に保持／記憶する容量を有すると更に仮定する。言い換えれば、コンプリータ５０２内のバッファ、処理回路及び／又は他の回路は、最大７つの要求パケット（すなわち、本明細書で説明するようにコンプリータ５０２によって順不同で処理され／再順序付けされ得る７つの要求パケット）を同時に保持することができる。したがって、要求パケットが互いに対して一意のタグを有するための移動ウィンドウは、長さが７つの要求パケットである。

【0050】

図５に見られるように、リクエスタ５００は、タグ０００～１１１を有する８つの要求パケットをコンプリータ５０２に既に送信しており（明確にするために、図５では要求パケットのうちいくつかのみにラベルが付けられている）、８つの要求パケット全てが未処理のままである。８つの要求パケットのうち５つ、すなわち、タグ０００～１００を有する要求パケットは、コンプリータの内部要素内に保持／記憶される（内部要素内に２つの追加パケットを記憶するための容量は、コンプリータ５０２内の破線ボックスによって示されるように、現在未使用である）。タグ１０１～１１０を有する要求パケットは、中間デバイス５０４の内部要素内に保持／記憶されるか又は中間デバイス５０４の内部要素を通過し、例えば、中間デバイス５０４による転送を待つバッファ内にある。タグ１１１を有する要求パケットは、リンク５０６上で伝送されている。リクエスタ５００は、タグ０００を有する第９の要求パケットを生成しており、リンク５０６上で第９の要求パケットをコンプリータ５０２に伝送する準備をしている。上述したように、第９の要求パケットは、第９の要求パケットと同時にコンプリータの内部要素内にある他のタグに対して一意であるが、現在コンプリータ５０２内にある要求パケット内のタグに対して一意ではないタグ（０００）を有する。言い換えれば、コンプリータ５０２の内部要素は、７つの要求パケットを記憶することに限定されているので、タグ０００を有する第１の要求パケットは、タグ０００を有する第２の要求パケットがコンプリータ５０２の内部要素内に記憶され得る前に処理され、それによって、コンプリータ５０２の内部要素から除去される必要がある。しかしながら、その内部要素の容量を考慮すると、コンプリータ５０２は、タグ０００を有する第２の要求パケットがコンプリータ５０２の内部要素に到着した場合に、タグ０１０～１１１を有する要求パケットを最大でも記憶する。このようにしてタグを有する要求パケットを送信することは、使用されている通信仕様の規定とは反対に動作するが、本明細書の他の場所で説明されるような再順序付け問題は、０００タグ値を有する第１及び第２の要求パケットに影響を及ぼさないため、リクエスタ５００及びコンプリータ５０２は正しい動作を継続する。

【0051】

図５に示される実施形態を含むいくつかの実施形態では、リクエスタは、要求パケット内のタグが、要求パケットと同時にコンプリータの内部要素内にある他の要求パケット内のタグに対して一意であることを確実にするために、順次タグを使用する。これらの実施形態では、リクエスタは、タグを有する要求パケットを保持／記憶するためのコンプリータの内部要素の容量が、許容可能なタグの数よりも小さいことを知っているか又は仮定している。例えば、リクエスタは、要求パケットを保持／記憶するためのコンプリータの内部要素の容量に関する情報を有するか又は取得することができる。例えば、設計者、インストーラ、別の機能ブロック等によって、リクエスタをプログラムしたり、又は、リクエスタにコンプリータの内部要素の容量に関する情報を提供したりすることができる。別の例として、リクエスタは、例えば、許容可能なタグの数（例えば、１６ビットタグ、３２ビットタグ）が十分に大きく、実際のコンプリータが、許容可能なタグの各々を有する要求パケットを保持／記憶するのに十分な内部要素を有する可能性が非常に低いという事実に基づいて、要求パケットを保持／記憶するためのコンプリータの内部要素の容量について仮定を行うようにプログラムされ、設計され、構成され得る。したがって、要求パケットをコンプリータに送信する場合に、リクエスタは、それぞれの順次タグを有する要求パケットのシーケンス内で要求パケットを送信し、シーケンスの終わりに達するとシーケンスの始めからシーケンスを開始する（例えば、最も高い許容可能なタグが要求パケットに含まれた後、最も低い許容可能なタグから開始する）。これは図５の例に示されており、ここでは、リクエスタ５００は、コンプリータ５０２の内部要素がタグ０００を有する要求パケットを現在保持／記憶／含むにもかかわらず、タグ０００を有する要求パケットを送信する準備をしており、すなわち、タグ０００を有する要求パケットは依然として未処理である。換言すれば、リクエスタは、各許容可能なタグが未処理の要求パケットに含まれているにもかかわらず要求パケットの送信を中止しないが、その代わりに、タグを有する要求パケットを順次自動的に送信し続ける。要求パケットを保持／記憶するためのコンプリータの内部要素の容量は、許容可能なタグの数よりも小さいので、これらの実施形態は、任意の所定の時間におけるコンプリータの内部要素内（すなわち、対応するウィンドウ内）のタグのシーケンス／順次タグが、互いに対して一意であることを確実にするか又は仮定することができる。これらの実施形態のうちいくつかでは、リクエスタは、タグを順に生成するためにカウンタを使用し、最高値（例えば、４ビットタグに対して１１１１）を含む要求パケットがコンプリータに送信されると、カウンタを最低値（例えば、４ビットタグに対して００００）に戻す。

【0052】

図６は、いくつかの実施形態による、タグを伴う要求パケットをコンプリータからリクエスタに送信するためのプロセスを示すフローチャートである。リクエスタがタグを有する要求パケットを順次自動的に送信する図４及び図５に示す例とは異なり、図６の実施形態では、リクエスタは、先ず、コンプリータの内部要素が満たされるかどうかを決定し、次いで、それに応じてタグを有する要求パケットを送信する。図６は、いくつかの実施形態においてリクエスタによって実施される動作の一般的な例として提示される。しかしながら、いくつかの実施形態では、リクエスタは、異なる動作を実施し、及び／又は、異なる順序で動作を実施する。

【0053】

図６の動作は、リクエスタが、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素がコンプリータの内部要素内のリクエスタからの他の要求パケット内のタグに対して一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定した場合（ステップ６００）に開始する。この動作のために、いくつかの実施形態では、リクエスタは、コンプリータ内のバッファ、処理回路等の内部要素が一意のタグを有する要求パケットで満たされるかどうかを決定する。言い換えれば、リクエスタは、コンプリータが以前の要求パケットの処理で完全に占有され、したがって、要求パケットがコンプリータによる処理のために受け入れられ得るように内部要素内の空間を解放するために以前の要求パケットの処理を完了する必要があるかどうかを決定する。このようにして、リクエスタは、要求パケットに含まれ得るタグの性質を決定する。すなわち、リクエスタは、要求パケットが、コンプリータの内部要素内の要求パケットのセット内に、したがって、コンプリータの内部要素内の要求パケットの「ウィンドウ」内に含まれることになるかどうか、又は、要求パケットのウィンドウの外側にあるかどうかを決定する。

【0054】

いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、所定の数の要求パケットが、対応する応答パケットを受信することなくコンプリータに送信されたかどうかを決定する。例えば、Ｎビットのタグが使用されていると仮定すると、リクエスタは、対応する応答パケットを未だ受信することなく、２^Ｎ個の要求パケットがコンプリータに送信されたかどうかを決定することができる。この場合、全ての利用可能なタグが未処理／保留中の要求パケット内で使用された場合に、リクエスタは、コンプリータの内部要素が要求パケットで満たされることを決定することができる。

【0055】

いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、要求パケットの送信リンク／内部要素待ち時間に関する情報を使用する。これらの実施形態における送信リンク／内部要素待ち時間は、要求パケットが送信リンク及びコンプリータの内部要素を通過する、及び／又は、そこに存在すると予想される合計又は平均時間である。これらの実施形態では、リクエスタは、コンプリータの内部要素が満たされるかどうかを決定するために、未処理の要求パケット（すなわち、対応する応答パケットが未だ受信されていない要求パケット）の数に関する情報と共に、要求パケットの送信リンク／内部要素待ち時間に関する情報を使用する。例えば、いくつかの実施形態では、リクエスタは、要求パケットに対する送信リンク／内部要素待ち時間を未処理の要求パケットの数（例えば、フライト時間を乗じたもの）と比較して、コンプリータの内部要素が満たされるかどうかを決定することができる。これらの実施形態のいくつかにおいて、リクエスタは、どのくらいの長さのパケットがインフライト中であったかを追跡し、比較においてこの情報を使用する。

【0056】

いくつかの実施形態では、要求パケットがコンプリータに到着した場合に、コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされるかどうかを決定するために、リクエスタは、コンプリータ内の中間ネットワークデバイス及び／又は内部要素の配置又は構成に関する情報を使用する。例えば、リクエスタは、中間ネットワークデバイス及び／又はコンプリータの内部要素に要求パケットを記憶又はバッファリングするために、最大容量若しくは今／現在の容量、又は、「搬送容量」に関する情報を使用することができる。これらの実施形態では、リクエスタは、中間ネットワークデバイス及び／又はコンプリータ内の内部要素の配置又は構成に関する情報を、未処理の要求パケットの数に関する情報と共に使用して、コンプリータの内部要素が満たされるかどうかを決定する。例えば、いくつかの実施形態では、リクエスタは、未処理の要求パケットの数の搬送容量を比較して、コンプリータの内部要素が満たされるかどうかを決定することができる。これらの実施形態のいくつかにおいて、リクエスタは、どのくらいの長さのパケットがインフライト中であったかを追跡し、比較においてこの情報を使用する。

【0057】

コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされる場合（ステップ６０２）、リクエスタは、パケットがコンプリータに到着した場合に、要求パケットが、コンプリータの内部要素内のタグに対して一意であるタグを有する必要がないことを認識する。したがって、リクエスタは、コンプリータに、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないタグを有する要求パケットを送信する（ステップ６０４）。この動作のために、（簡略化された例として）２ビットタグが使用され、コンプリータの内部要素が４つの要求パケットを保持することができると仮定すると、リクエスタが、図６で説明した要求パケットを送信する直前に、タグ００、０１、１０、１１を有する要求パケットを順に送信した場合、コンプリータは、例えば、コンプリータ内の要素の配置及び送信された要求パケットの数に基づいて、要求パケットがコンプリータに到着した場合（及び要求パケットが送信された場合）に、コンプリータの内部要素が、互いに対して一意であるタグを有する要求パケットで満たされることを決定することができる。次に、リクエスタは、ステップ６０４において、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないタグを有するパケットを送信することができる。例えば、いくつかの実施形態において、リクエスタは、１１から００に戻り、タグ００を有する要求パケットを送信する。

【0058】

上記の例では、要求パケットがコンプリータに到着する前に、タグ００は、コンプリータの内部要素内の以前に送信された要求パケット、すなわち、リクエスタからコンプリータに以前に送信された４つの要求パケットのうち第１の要求パケット内のタグによって複製される。しかしながら、タグ００を有する以前に送信された要求パケットは、要求パケットがコンプリータの内部要素内に受け入れられ得る前に処理を完了する。したがって、００タグを有する以前に送信された要求パケットは、００タグを有する要求パケットがコンプリータの内部要素内にあるのと同時に、コンプリータの内部要素内に存在しない。

【0059】

ステップ６０４では、リクエスタは、コンプリータに、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意ではないタグを有する要求パケットを送信するが、要求パケット内のタグは、要求パケットがコンプリータの内部要素内にある間にコンプリータの内部要素内にあるリクエスタからの他の要求パケットに対して一意である。移動ウィンドウの例を上記から続けると、要求パケット内のタグは、要求パケットと同じウィンドウ内の他の要求パケット内のタグに対して一意である。このようにしてタグを有する要求パケットを送信することは、使用されている通信仕様の規定に反して動作するが、本明細書で説明されるような再順序付け問題は、重複タグ値を有する要求パケットに影響を及ぼさないため、リクエスタ及びコンプリータは正しい動作を継続する。

【0060】

コンプリータの内部要素が、一意のタグを有するリクエスタからの要求パケットで満たされない場合（ステップ６０２）、リクエスタは、要求パケットがコンプリータに到着した場合に、要求パケットがコンプリータの内部要素内の他の要求パケット内のタグに対して一意であるタグを有するべきであることを認識する。したがって、リクエスタは、コンプリータに、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意であるタグを有する要求パケットをコンプリータに送信する（ステップ６０６）。この動作のために、再び、２ビットタグが使用され、コンプリータの内部要素が４つの要求パケットを保持することができると仮定すると、リクエスタが、図６で説明した要求パケットを送信する直前に、タグ００、０１、１０を有する要求パケットを順に送信した場合、コンプリータは、例えば、コンプリータ内の要素の配置及び送信された要求パケットの数に基づいて、要求パケットがコンプリータに到着した場合（及び要求パケットが送信された場合）に、コンプリータの内部要素が要求パケットで満たされないことを決定することができる。次に、コンプリータは、ステップ６０６において、要求パケットがコンプリータに到着した場合にコンプリータの内部要素内にあるリクエスタからの要求パケット内のタグに対して一意であるタグを有するパケットを送信することができる。例えば、いくつかの実施形態において、リクエスタは、タグ１１を有する要求パケットを送信する。

【0061】

いくつかの実施形態では、図４及び図６には示されていないが、リクエスタは、その後、図４及び図６で説明したタグを含む応答パケットをコンプリータから受信する。応答パケットを受信すると、リクエスタは、応答パケットからのタグを使用して、応答パケットが図４及び図６で説明した要求パケットと関連付けられていることを決定し、それに応じて後続の動作を実施する。例えば、要求パケットがＩＯデバイスからデータを取得する要求である場合、応答パケットにはデータが含まれる。リクエスタは、応答パケットからデータを取得し、後続の動作（例えば、ＩＯデバイスからのデータの処理又は記憶等）を実施するためにデータを使用する。

【0062】

（タグ使用の有効化及び無効化）
いくつかの実施形態では、リクエスタは、上述したように要求パケット内のタグを使用するように構成され、可能にされ得る。言い換えれば、リクエスタは、既存のデバイスにおけるようにタグを使用する（例えば、リクエスタにおいてタグがなくなった場合に停止することを意味し得る）か、図４及び図６等に示されているようなインフライト要求パケット用のタグを使用し続ける間で切り替えることができる。これらの実施形態では、リクエスタは、ハードウェア若しくはソフトウェアのスイッチ、又は、リクエストパケットに対する非一意のタグの使用を有効若しくは無効にする構成設定を提供する。ハードウェア又はソフトウェアのスイッチ又は構成設定が無効にされ、ディアサートされる等の場合、リクエスタは、既存のデバイスと同様に要求パケットのタグを使用する。対照的に、ハードウェア若しくはソフトウェアスイッチ又は構成設定が有効にされる場合に、リクエスタは、上述したように要求パケットのためのタグを使用することができる。

【0063】

いくつかの実施形態では、上述したスイッチは、製造時又はインストール時等に、要求パケット内の非一意のタグの使用を有効又は無効にするように永続的に設定される。例えば、これらの実施形態のいくつかにおいて、スイッチは、ヒューズ、ＲＯＭストラップ、及び／又は、上述したようにリクエスタが非一意のタグを使用することを一度有効化（又は無効化）するように構成された別のデバイス等の回路を含むハードウェアスイッチである。例えば、ヒューズは、非一意のタグの使用が有効にされるように完全なままにされ得るか、非一意のタグの使用が無効にされるように（例えば、ヒューズにわたって特定の電流を流すことによって）焼き切られ得る。しかしながら、いくつかの実施形態では、上述したスイッチは、再構成可能であり、したがって、例えば、製造時又は設置時、起動時、実行時等に１回以上設定及びリセットされ得る。例えば、これらの実施形態のいくつかにおいて、リクエスタは、集積回路チップ上に実装されてもよく、「スイッチ」は、集積回路チップがパッケージされたパッケージ（例えば、ボールグリッドアレイパッケージ等）のピン又は入力に配線された回路を有効化することを含むことができ、ピン又は入力上の信号は、要求パケット内の非一意のタグの使用を有効化又は無効化する。

【0064】

いくつかの実施形態では、少なくとも１つの電子デバイス（例えば、リクエスタ１０２等）は、非一時的なコンピュータ可読記憶媒体に記憶されたコード及び／又はデータを使用して、本明細書に記載の動作の一部又は全てを実施する。より詳細には、少なくとも１つの電子デバイスは、コンピュータ可読記憶媒体からコード及び／又はデータを読み取り、記載の動作を実行する場合にコードを実行し及び／又はデータを使用する。コンピュータ可読記憶媒体は、電子デバイスによって使用されるコード及び／又はデータを格納する任意のデバイス、媒体又はそれらの組み合わせであり得る。例えば、コンピュータ可読記憶媒体は、フラッシュメモリ、ランダムアクセスメモリ（例えば、ｅＤＲＡＭ、ＲＡＭ、ＳＲＡＭ、ＤＲＡＭ、ＤＤＲ４ ＳＤＲＡＭ等）、不揮発性ＲＡＭ（例えば、位相変化メモリ、強誘電性ランダムアクセスメモリ、スピントランスファーランダムアクセスメモリ、磁気抵抗ランダムアクセスメモリ等）、読み取り専用メモリ（read-only memory、ＲＯＭ）、及び／又は、磁気若しくは光学格納媒体（例えば、ディスクドライブ、磁気テープ、ＣＤ、ＤＶＤ等）を含む揮発性及び／又は不揮発性メモリを含むことができるが、これらに限定されない。

【0065】

いくつかの実施形態では、１つ以上のハードウェアモジュールが、本明細書に記載の動作を実行する。例えば、ハードウェアモジュールは、１つ以上の中央処理ユニット（ＣＰＵ）／ＣＰＵコア、グラフィック処理ユニット（ＧＰＵ）／ＧＰＵコア、特定用途向け集積回路（application-specific integrated circuit、ＡＳＩＣ）チップ、フィールドプログラマブルゲートアレイ（field-programmable gate array、ＦＰＧＡ）、コンプレッサ又はエンコーダ、計算ユニット、埋め込みプロセッサ、加速処理ユニット（accelerated processing unit、ＡＰＵ）、コントローラ、リクエスタ、コンプリータ、ネットワーク通信リンク、及び／又は、他の機能ブロックを含むことができるが、これらに限定されない。そのようなハードウェアモジュール内の回路（例えば、集積回路要素、ディスクリート回路要素等）がアクティブ化されると、回路は、動作の一部又は全てを実行する。いくつかの実施形態において、ハードウェアモジュールは、命令（例えば、プログラムコード、ファームウェア等）の実行時に動作を実行する実行パイプライン、計算又は処理ユニット等の汎用回路を含む。いくつかの実施形態では、ハードウェアモジュールは、動作を実行する特定用途向け又は専用の回路を含み、場合によっては、命令を実行することなく「ハードウェア内の」動作の一部又は全てを実行する回路を含む。

【0066】

いくつかの実施形態において、本明細書に記載される機能ブロック及び回路要素（例えば、リクエスタ１０２、コンプリータ１０４、ネットワーク通信リンク１００、又は、そのいくつかの部分）の一部又は全てを表わすデータ構造は、電子デバイスによって読み取られて機能ブロック及び回路要素を含むハードウェアを製造するために直接的又は間接的に使用され得るデータベース又は他のデータ構造を含む持続性コンピュータ可読記憶媒体に記憶される。例えば、データ構造は、Ｖｅｒｉｌｏｇ又はＶＨＤＬ等の高レベル設計言語（high-level design language、ＨＤＬ）におけるハードウェア機能の行動レベルの記述又はレジスタ転送レベル（register-transfer level、ＲＴＬ）の記述であり得る。記述は、記述を合成して、上記の機能ブロック及び回路要素を含むハードウェアの機能を表す合成ライブラリからのトランジスタ／回路要素のリストを含むネットリストを生成することができる合成ツールによって読み取られ得る。ネットリストは、次いで、マスクに適用される幾何学的形状を記述するデータセットを生成するように設置及びルーティングされ得る。マスクは、次いで、上記の機能ブロック及び回路要素に対応する半導体回路又は回路（例えば、集積回路）を製造するために、様々な半導体加工ステップで使用され得る。代替的に、コンピュータアクセス可能格納媒体上のデータベースは、所望に応じて、ネットリスト（合成ライブラリの有無にかかわらず）若しくはデータセット、又は、グラフィックデータシステム（Graphic Data System、ＧＤＳ）ＩＩデータであり得る。

【0067】

この記載では、変数又は不特定の値（すなわち、値の特定の例を含まない値の一般的な説明）は、Ｎ、Ｍ、Ｘ等の文字によって表される。本明細書で使用されるように、この記載において異なる場所で類似の文字を使用する可能性があるにもかかわらず、各場合における変数及び不特定の値は、必ずしも同じではなく、すなわち、一般的な変数及び不特定値のいくつか又は全てに対して意図される変数及び値が存在し得る。言い換えれば、Ｎの特定の値の例、及び、この記載における変数及び指定されていない値を表すために使用される任意の他の文字は、必ずしも互いに関連しない。

【0068】

本明細書で使用される場合、「その他（et cetera）」又は「等（etc.）」という表現は、及び／又は（and/or）の場合、すなわち、「等（etc.）」が関連付けられるリスト内の要素「のうち少なくとも１つ（at least one of）」の等価物を提示することが意図される。例えば、「電子デバイスが第１の動作、第２の動作等を実行する」という記述では、電子デバイスは、第１の動作、第２の動作及び他の動作のうち少なくとも１つを実行する。加えて、１つ等に関連付けられたリスト内の要素は、一組の例の中からの例に過ぎず、実施例の少なくともいくつかは、いくつかの実施形態では現れない場合がある。

【0069】

実施形態の上記の説明は、例示及び説明の目的でのみ提示されている。それらは、網羅的であること、又は、実施形態を開示された形態に限定することを意図するものではない。したがって、多くの修正及び変形が当業者には明らかであろう。更に、上記の開示は、実施形態を限定することを意図するものではない。実施形態の範囲は、添付の特許請求の範囲によって定義される。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6】

【国際調査報告】