JP6273972B2 - 情報処理装置、送受信装置、及び情報処理装置の制御方法 - Google Patents

Description

本発明は、情報処理装置、送受信装置、及び情報処理装置の制御方法に関する。

情報処理装置に搭載された演算処理装置としてのＣＰＵ（Central Processing Unit）は、入出力装置としてのＩＯ（Input Output）装置からデータを取得して処理を行う。情報処理装置では、ＣＰＵとＩＯ装置間の通信は、その通信用のデバイス（以降「通信装置」と表記）を介して行わせるのが普通である。その通信装置とは、具体的には、ブリッジ、或いはスイッチ等である。

各通信装置は、採用された規格に従って通信を行う。高速な処理の実現には、高速なデータ伝送が要求される。このことから、最近では、高速なデータ伝送が可能なＰＣＩｅ（PCI Express）規格が採用される場合がある。

ＰＣＩｅではスプリット・トランザクション方式によりデータ通信を行う。スプリット・トランザクション方式では、データを要求する側のデバイス（リクエスタ）は、ある要求のためのパケット（リクエスト）を送信した後、その応答（例えばリード要求の応答であるコンプリーション）を応答者（コンプリータ）から受信するのを待たずに別のリクエストを送信することが可能である。そのため、パケットを用いた通信をより効率的に行うことができる。応答者は、通常ＩＯ装置である。

スプリット・トランザクション方式では、１台のＩＯ装置が処理すべきリクエストの数が複数になる場合がある。それらリクエストがリード要求のためのリクエストであった場合、それらリクエストのコンプリーションはリクエスト送信順とは異なる順序で送信されることがある。このため、リクエスタは、リクエストとコンプリーションの対応関係を特定しなければならない。それらの対応関係は、リクエストにタグと呼ばれる識別子を格納することで対応可能となっている。

タグは有限な資源である。使用可能なタグの数は例えば３２、或いは２５６である。そのため、リクエスタは、使用可能なタグの中から一つを選択し、リクエストに付加する。一方のコンプリータは、リクエストに含まれるタグと同一のタグをコンプリーションに付加する。これにより、リクエスタは、リクエストとコンプリーションを一意に対応付けることができる。

リクエストに付加されたタグは、そのタグが付与されたコンプリーションが返信された時点で返却され、再び使用可能となる。しかし、タグは有限な資源であることから、使用可能なタグが無くなった場合、リクエスタはリクエストを生成できなくなり、新たなリクエストの発行は停止する。

伝送エラー等、何らかの原因によりコンプリーションが返信されない場合がある。コンプリーションの未返信を検出するために、ＰＣＩｅ規格にはＣＴＯ（Completion Timeout）と呼ぶメカニズム（オプション）がある。このＣＴＯは、あらかじめ定められた時間内にコンプリーションが返信されなかった場合に、そのコンプリーションの未返信をエラーとして検出する。ＣＴＯが発生した場合、当該リクエストは破棄され、そのリクエストに付加されていたタグは返却される。以降、ＣＴＯはエラー種別を表す意味でも用いる。

ＣＴＯは、伝送エラー等によりリクエスト、或いはコンプリーションが消失した場合に発生する。しかし、別の要因によっても発生する可能性がある。その別の要因として、コンプリータ側の高負荷状態による応答の遅延が挙げられる。つまり、高負荷状態のコンプリータは、リクエスタ側がＣＴＯを検出した後に、コンプリーションを送信することがある。

リクエスタ側は、ＣＴＯの検出により、再度リクエストを発行する。そのリクエスタ側がＣＴＯを検出した時点で、そのＣＴＯが発生したリクエストのタグは使用可能となる。そのため、その時点で使用可能なタグの数、及びその時点以降に発行されるリクエストの数の関係等により、ＣＴＯが発生したリクエストのタグがそのリクエストとは異なるリクエストに使用される可能性がある。しかし、リクエスタ側がＣＴＯを検出した後、コンプリーションが返信される可能性がある。これらは、要求内容が異なり、且つ短時間内に発行される少なくとも２つのリクエストに同一のタグが付与される可能性があることを意味する。

コンプリータ側は、上記のように、コンプリーションをリクエスト送信順とは異なる順序で送信することがある。このため、要求内容が異なり、且つ短時間内に発行した少なくとも２つのリクエストに同一のタグを付与した場合、リクエスタ側はリクエストとコンプリーションを適切に一意に対応付けることができない。処理結果を確認できない以上、リクエスタ側はリクエストを再発行しなければならない。そのようなリクエストの再発行は、単位時間当たりに有効なリクエストをリクエスタが発行できる数を減少させることから、性能を低下させる要因となる。

ＣＴＯが発生したリクエストのタグの使用を一定時間、禁止にすれば、要求内容が異なり、且つ短時間内に発行される少なくとも２つのリクエストへの同一のタグの付与は回避させることができる。しかし、タグは有限の資源であるため、タグを一定時間、使用できなくすることは、同時に発行可能なリクエストの数を減少させることに相当する。従い、タグを一定時間、使用できなくすることは、性能を低下させる要因となりうる。

このようなことから、タグの使用の制限を抑制しつつ、言い換えれば、同時に発行可能なリクエストの数の減少を抑制しつつ、リクエストとコンプリーションの対応関係を適切に特定可能にすることが重要と思われる。

なお、特許文献１及び２には、以下の内容が開示されている。
PCI-Expressによって接続される各モジュールに固有のノードＩＤを設定する。また、相手モジュールにデータを書き込む（ＰＵＴ転送）、相手モジュールからデータを読み出す（ＧＥＴ転送）のそれぞれに専用のチャネルを設け、各チャネルにチャネルＩＤを設定する。そして、PCI-Expressに従って転送されるトランザクションレイヤパケットのヘッダのアドレス部内に、前記ノードＩＤとチャネルＩＤを設定するとともに、リクエストであるかレスポンスであるのかを識別するパケットタイプを設定する。

そしてデータ転送には、アドレスルーティングでルーティングされるメモリライトリクエストパケットのみを使用する。また、リクエストの場合には必ずレスポンスパケット（レスポンスタイプのメモリライトリクエストパケット）により応答する。

特開２００６−３０２２５０号公報 特開２００７−３１６７５５号公報

一側面では、本発明は、タグの使用の制限を抑制しつつ、リクエストとコンプリーションの対応関係を適切に特定可能にするための技術を提供することを目的とする。

本発明を適用した１システムは、演算処理装置と、複数の入出力装置と、演算処理装置と複数の入出力装置間の通信をそれぞれ行う複数の通信装置とを備え、複数の通信装置のうち、第１のパケットを送信する第１の通信装置は、第１のパケットの識別用に割り当てられる第１の識別子毎に、第１の識別子と共に割り当てる第２の識別子を表す状況情報を記憶した記憶部と、第１の通信装置宛のパケットを受信する受信部と、第１のパケットが要求する処理の実行結果を表す第２のパケットの受信部による受信結果に基づき、記憶部に記憶された状況情報を更新する更新部と、記憶部に記憶された状況情報に基づき、第１のパケットに割り当てる第１の識別子と第２の識別子を決定する決定部と、決定部が決定した第１の識別子と第２の識別子とを格納した第１のパケットを生成して送信する第１の送信部とを有し、複数の通信装置のうち、第１のパケットの送信先となる第２の通信装置は、第１の通信装置が送信した第１のパケットへの応答として第２のパケットを送信する場合、第１のパケットに格納されている第２の識別子を第２のパケットに格納して送信する第２の送信部とを有する。

本発明を適用した場合には、タグの使用の制限を抑制しつつ、リクエストとコンプリーションの対応関係を適切に特定することができる。

本実施形態による情報処理装置の構成例を説明する図である。 パケット送受信装置の構成例を説明する図である。 ＣＴＯテーブルの構成例を説明する図である。 ＣＴＯが検出される場合に、リクエスタとコンプリータ間で行われる通信例を説明するシーケンス図である。 リクエストパケットの構成を説明する図である。 コンプリーションパケットの構成を説明する図である。 ＣＴＯ検出時のリクエスタの動作の流れを表すフローチャートである。

以下、本発明の実施形態について、図面を参照しながら詳細に説明する。
図１は、本実施形態による情報処理装置の構成例を説明する図である。本実施形態による情報処理装置１は、図１に表すように、演算処理装置としてのＣＰＵ（Central Processing Unit）１１、メモリ（メモリモジュール）１２、スイッチ１３、及び複数のエンドポイント１４（１４−０〜１４−３）を備えている。図１に表す構成例は１例であり、情報処理装置１の構成は図１に表す構成例に限定されない。

ＣＰＵ１１は、１つ以上のＣＰＵコア１１０、及びルートコンプレックス１１１を備える。図１には、ＣＰＵ１１の主要な構成要素のみを表している。ＣＰＵ１１の構成も図１に表す構成例に限定されない。

エンドポイント１４は、ＩＯ装置との接続用のインターフェースとなるデバイスである。具体的には、エンドポイント１４は、グラフィックカード、ＬＡＮ（Local Area Network）カード、或いは他のコントローラ等である。図１では、エンドポイント１４と接続されているＩＯ装置は省略している。

スイッチ１３は、例えばＰＣＩｅ規格に沿ってデータ（パケット）伝送を行う通信装置である。ルートコンプレックス１１１、及び各エンドポイント１４もＰＣＩｅ規格に沿った通信を行う通信装置である。

ルートコンプレックス１１１、及び各エンドポイント１４は共に、状況により、処理を要求するリクエスタ、及び要求された処理を実行するコンプリータの何れの役割も担う通信装置である。つまり、ＰＣＩｅ規格に沿って送信されるパケットの起点、或いは終点となる通信装置である。ルートコンプレックス１１１、及び各エンドポイント１４には、本実施形態による送受信装置であるパケット送受信装置２０が搭載されている。

図２は、パケット送受信装置の構成例を説明する図である。図２に表すように、そのパケット送受信装置２０は、パケット受信モジュール２１、送信パケット生成モジュール２２、及びタグ管理モジュール２３を備えている。タグ管理モジュール２３は、記憶部２３１、ＣＴＯテーブル更新部（図２中「CTO-Table更新」と表記）２３２、及び使用可能タグ管理部２３３を備えている。

パケット受信モジュール２１は、スイッチ１３から送信されたパケットを受信するためのモジュールであり、ＣＴＯを検出するためのタイマ（図２中「CTO TIMER」と表記）２１ａを備えている。このタイマ２１ａは、送信パケット生成モジュール２２の制御により計時をスタートする。

送信パケット生成モジュール２２は、パケットを生成して送信するモジュールである。パケットの生成指示は、リクエスタがルートコンプレックス１１１であった場合、ＣＰＵコア１１０が主に行う。リクエスタがエンドポイント１４であった場合、主に接続されているＩＯ装置の指示により、パケットが生成される。パケット受信モジュール２１が受信したパケットは、パケットの生成を指示可能なＣＰＵコア１１０、或いはＩＯ装置に出力される。以降、便宜的に、リクエスタ、或いはコンプリータにパケットの送信を指示するものを「マスタデバイス」と表記する。

パケットが処理の要求のためのパケット（以降「リクエストパケット」と表記）であった場合、そのリクエストパケットには識別子とする番号であるタグが付与される。タグ管理モジュール２３は、リクエストパケットに付与されるタグを管理するモジュールである。記憶部２３１には、タグを管理するためのＣＴＯテーブル（図２中「CTO-Table」と表記）が記憶されている。

図３は、ＣＴＯテーブルの構成例を説明する図である。図３中、「tag」の右側に表記の「０」〜「２」、及び「ｎ」は、それぞれタグの実際の番号を表している。それにより、ＣＴＯテーブルは、タグ毎に、「TagBusy」と表記の使用状況情報、「CTOinfo1」及び「CTOinfo2」と表記の２つのＣＴＯ状況情報を１エントリ（レコード）に格納した構成となっている。

TagBusy（使用状況情報）、CTOinfo1及びCTOinfo2の各ＣＴＯ状況情報は全て１ビットの情報である。TagBusyは、対応するタグが使用中か否かを表す情報である。図３中に表記の「０」は、対応するタグが未使用であることを表している。対応するタグが使用中であった場合、TagBusyの値は１となる。

CTOinfo1は、対応するタグを付与したリクエストパケットがＣＴＯを発生させたか否かを表す情報である。本実施形態では、ＣＴＯの発生により、再送するリクエストパケットに対し、タグとは別の識別子とする１ビットのフラグ（以降「CTO-Flag」と表記）を付与するようにしている。その1ビットのCTO-Flagの値は１である。CTOinfo2は、CTO-Flagを付与したリクエストパケットがＣＴＯを発生させたか否かを表す情報である。

CTO-Flagが付与されたリクエストパケットを受信したコンプリータは、その応答であるパケット（以降「コンプリーションパケット」と表記）にも同じCTO-Flagを付与する。そのため、リクエスタは、同一のタグを付与した２つのリクエストパケットに対するコンプリーションパケットをそれぞれ受信したとしても、CTO-Flagによって、リクエストパケットとコンプリーションパケットの対応関係を適切に特定することができる。ＣＴＯが発生したリクエストパケットのタグは直ちに再利用が可能であり、同時に発行可能なリクエストパケットの数の減少は回避、或いは抑制させることができる。このようなことから、リクエストパケットを発行できないことによる情報処理装置１の性能劣化も回避、或いは抑制される。リクエストパケットとコンプリーションパケットの対応関係の特定はパケット受信モジュール２１によって行われる。

ＣＴＯテーブル更新部２３２は、パケット受信モジュール２１から入力する情報により、ＣＴＯテーブルを更新する。

送信パケット生成モジュール２２は、リクエストパケットを生成・送信する場合、タイマ２１ａをスタートさせ、そのリクエストパケットに付与したタグ、及びCTO-Flagの有無をパケット受信モジュール２１に通知する。それにより、パケット受信モジュール２１は、ＣＴＯを検出した場合、ＣＴＯを検出したリクエストパケットに付与されたタグ、及びCTO-Flagの有無を特定する。パケット受信モジュール２１は、ＣＴＯテーブル更新部２３２に対し、ＣＴＯを検出した旨を通知すると共に、特定したタグ、及びCTO-Flagの有無を通知する。コンプリーションパケットを受信した場合、パケット受信モジュール２１は、返却する（利用可能にする）タグとして、受信したコンプリーションパケットのタグを通知する。

ＣＴＯテーブル更新部２３２は、パケット受信モジュール２１からＣＴＯの検出が通知された場合、通知されたCTO-Flagの有無に応じて、通知されたタグのエントリに格納されているCTOinfo1、及びCTOinfo2を更新する。その更新は、以下のようにして行われる。

（１）CTO-Flag無し、且つ（CTOinfo1，CTOinfo2）=（０，０）の場合
（CTOinfo1，CTOinfo2）=（１，０）
（２）CTO-Flag有り、且つ（CTOinfo1，CTOinfo2）=（１，０）の場合
（CTOinfo1，CTOinfo2）=（１，１）

ケース（１）は、CTO-Flagを格納していないリクエストパケットにＣＴＯが検出されたケースである。本実施形態では、コンプリーションパケットの受信によりタグを利用可能にするとき、つまりTagBusyの値を０にするとき、CTOinfo1、及びCTOinfo2の値を共に０に更新するようにしている。そのため、CTO-Flagを格納していないリクエストパケットにＣＴＯが検出された場合、CTOinfo1、及びCTOinfo2の各値は必ず０となっている。

ケース（２）は、ＣＴＯを検出した後、CTO-Flagを格納していないリクエストパケットのコンンプリーションを受信することなく、CTO-Flagを格納したリクエストパケットに更にＣＴＯを検出したケースである。

ケースとしては、他に、ＣＴＯを検出した後、CTO-Flagを格納していないリクエストパケットのコンンプリーションを受信し、更にその後、CTO-Flagを格納したリクエストパケットにＣＴＯを検出したケースが考えられる。しかし、コンプリーションの受信により、タグは利用可能とされ、その後のＣＴＯの検出、或いはコンプリーションパケットの受信により、CTOinfo1、及びCTOinfo2の更新は行われない。そのため、このケースは対象外となる。

本実施形態では、（CTOinfo1，CTOinfo2）=（１，１）となったタグは一時的に利用禁止にしている。これは、コンプリーションの受信を遅延させる要因以外の要因が考えられるためである。

一方、パケット受信モジュール２１から返却する（利用可能にする）タグが通知された場合、ＣＴＯテーブル更新部２３２は、通知されたタグのエントリに格納されたTagBusyを０に更新する。CTOinfo1及びCTOinfo2の各値は、上記のように、それまでの値に係わらず、全て０に更新される。

送信パケット生成モジュール２２は、マスタデバイスからの要求により、リクエストパケットを生成し、パケット受信モジュール２１によるＣＴＯの検出により、再送するリクエストパケットを生成する。また、マスタデバイスからの要求により、コンプリーションパケットを生成する。

マスタデバイスからリクエストパケットの送信を要求された送信パケット生成モジュール２２は、使用可能タグ管理部２３３に、使用可能なタグを問い合わせる。使用可能タグ管理部２３３は、その問い合わせにより、使用可能なタグ、及びCTO-Flagの付与の有無を送信パケット生成モジュール２２に通知する。このため、送信パケット生成モジュール２２は、リクエストパケットに対して、使用可能タグ管理部２３３から指示されたタグを付与し、CTO-Flagを必要に応じて付与する。使用可能なタグが存在しない場合、使用可能タグ管理部２３３からその旨が送信パケット生成モジュール２２に通知され、リクエストパケットは生成されない。

パケット受信モジュール２１がＣＴＯを検出した場合、その旨が例えばタグと共に送信パケット生成モジュール２２に通知される。その通知により、送信パケット生成モジュール２２は、必要に応じてリクエストパケットの再送を行う。そのリクエストパケットの再送のために、送信パケット生成モジュール２２は、例えばＣＴＯが検出されたリクエストパケットのタグを使用可能タグ管理部２３３に通知し、CTO-Flagの付与の有無を使用可能タグ管理部２３３に問い合わせる。このため、送信パケット生成モジュール２２は、使用可能タグ管理部２３３からCTO-Flagの付与を指示された場合に、リクエストパケットにCTO-Flagを付与する。

CTO-Flagの付与の有無は、CTOinfo1、及びCTOinfo2から、以下のように使用可能タグ管理部２３３は判定する。ここでは、“CTO-Flag＝０”は、CTO-Flagを付与しないことを表し、“CTO-Flag＝１”はCTO-Flagを付与することを表している。

（ａ）（CTOinfo1，CTOinfo2）=（０，０）の場合、CTO-Flag＝０
（ｂ）（CTOinfo1，CTOinfo2）=（０，１）の場合、CTO-Flag＝０
（ｃ）（CTOinfo1，CTOinfo2）=（１，０）の場合、CTO-Flag＝１
（ｄ）（CTOinfo1，CTOinfo2）=（１，１）の場合、タグの利用禁止

本実施形態では、リクエストパケットの再送は１回のみ行うようにさせている。２回目のリクエストパケットを再送する状況では、つまり２回、送信したリクエストパケットの全てにＣＴＯが発生した状況では、（CTOinfo1，CTOinfo2）=（１，１）となる。このことから、（CTOinfo1，CTOinfo2）=（１，１）となったタグは一時的に利用が禁止される。（CTOinfo1，CTOinfo2）=（１，１）となっている場合、使用可能タグ管理部２３３はリクエストパケットの送信の中止を送信パケット生成モジュール２２に通知する。

使用可能タグ管理部２３３は、送信パケット生成モジュール２２から使用可能なタグが問い合わせられた場合、記憶部２３１のＣＴＯテーブルを参照し、TagBusyの値が０となっているエントリを探索する。その探索により、TagBusyの値が０となっているエントリを抽出できなかった場合、使用可能タグ管理部２３３は、その旨を送信パケット生成モジュール２２に通知する。この結果、送信パケット生成モジュール２２は、リクエストパケットの生成を停止する。

一方、探索によってTagBusyの値が０となっているエントリを抽出できた場合、使用可能タグ管理部２３３は、抽出できたエントリのタグを送信パケット生成モジュール２２に通知し、そのエントリのTagBusyの値を１に更新する。使用可能タグ管理部２３３は、そのエントリのCTOinfo1、及びCTOinfo2から、CTO-Flagの付与の有無を判定し、その判定結果を送信パケット生成モジュール２２に通知する。このとき、CTOinfo1、及びCTOinfo2の各値は共に０であることから、CTO-Flagは付与しないと判定される。

このようにして、リクエストパケットには、タグの他にCTO-Flagが状況に応じて割り当てられ付与（格納）される。そのため、同じタグを短時間内に複数のリクエストパケットに付与させたとしても、リクエスタは、リクエストパケットとコンプリーションパケット間の対応関係を適切に特定することができる。

図４は、ＣＴＯが検出される場合に、リクエスタとコンプリータ間で行われる通信例を説明するシーケンス図である。次に図４を参照し、ＣＴＯが検出される場合のリクエスタとコンプリータの動作について具体的に説明する。上記のように、未使用のタグｍのエントリには、それぞれ値が０のTagBusy、CTOinfo1、CTOinfo2が格納されている。

リクエスタは、マスタデバイスからの要求により、CTO-Flagを格納していないリクエストパケットである第１のリクエストパケット４０１を生成・送信する。その第１のリクエストパケット４０１に付与されたのはタグｍである。このため、ＣＴＯテーブルのタグｍのエントリ中のTagBusyの値は、使用可能タグ管理部２３３によって０から１に更新される。

第１のリクエストパケット４０１が伝送エラー等の遅延の要因以外の要因によりコンプリータに受信されないか、或いはコンプリータが送信したコンプリーションが何らかの要因によりリクエスタに受信されない場合、リクエスタはＣＴＯを検出する。その結果、ＣＴＯテーブルのタグｍのエントリでは、ＣＴＯテーブル更新部２３２によってCTOinfo1の値は０から１に更新される。その更新後、リクエスタは、CTO-Flagを格納したリクエストパケットである第２のリクエストパケット４０２を生成・送信する。その第２のリクエストパケット４０２のコンプリーションがリクエスタに受信されない場合、リクエスタはＣＴＯを検出する。その結果、ＣＴＯテーブルのタグｍのエントリ中のCTOinfo2の値は、使用可能タグ管理部２３３によって０から１に更新される。

コンプリータは、第２のリクエストパケット４０２を受信した場合、マスタデバイスに対し、マスタデバイスに対応のプロトコルで第２のリクエストパケット４０２を送信する。その結果、マスタデバイスがコンプリーションの送信を要求した場合、コンプリータはコンプリーション４０３を送信する。このコンプリーション４０３には、タグｍ、及びCTO-Flagが付与される。

コンプリーション４０３を受信したリクエスタは、そのコンプリーション４０３に付与されているタグｍ、及びCTO-Flagから、そのコンプリーション４０３が第２のリクエストパケット４０２に対応付ける。この結果、ＣＴＯテーブルのタグｍのエントリでは、ＣＴＯテーブル更新部２３２によって、TagBusy、CTOinfo1、及びCTOinfo2の各値は全て０に更新される。

コンプリーション４０３として、CTO-Flagが格納されていないコンプリーションをリクエスタが受信した場合、CTO-Flagが存在しないことにより、受信したコンプリーションは第１のリクエストパケット４０１と対応付けられる。

ＰＣＩｅ規格では、リクエストパケットとコンプリーションパケットの順序に関するルールが規定されている。その規定では、同一タグのコンプリーションパケットは受信した順番を変えることができない。そのため、第１のリクエストパケット４０１のコンプリーションパケットはパケットの伝送経路上に存在しない、つまり何かの原因で存在しないことが分かる。再送するリクエストパケットに同一のタグを付与するのは、このためである。前に送信したリクエストパケットに対するコンプリーションパケットの存在の確認を合わせて行えるためである。

CTO-Flagの付与により、要求内容の異なる複数のリクエストパケットにも同一のタグを付与したとしても、リクエスタは、リクエストパケットとコンプリーションパケット間の対応関係は適切に特定することができる。しかし、リクエストパケットとコンプリーションパケット間の対応関係を適切に特定できるようにするには、各リクエストパケットに付与させたタグ、及びCTO-Flagの組み合わせを表す情報を保存させておく必要がある。そのような情報をリクエストパケットとコンプリーションパケット間の対応関係の特定に用いる場合、制御が複雑になって、パケット送受信装置２０の負荷は重くなる。このようなことからも、本実施形態では、再送するリクエストパケットには同一のタグを付与するようにしている。

図５は、リクエストパケットの構成を説明する図であり、図６は、コンプリーションパケットの構成を説明する図である。ここで、図５、及び図６を参照し、本実施形態によるCTO-Flagのリクエストパケット、及びコンプリーションパケットへの付与（格納）方法について具体的に説明する。

図５、及び図６には、リクエストパケット、及びコンプリーションパケットの一部であるヘッダ部分のみ表している。図５、及び図６中に表記の「Ｒ」は予約語を意味する「Reserved」の略記である。

本実施形態では、図５、及び図６にそれぞれ丸を付して表したように、ヘッダ（ＴＬＰ(Transaction Layer Packet)ヘッダ）の先頭から１６ビット目に予約語として確保されている１ビットにCTO-Flagを格納するようにしている。このビットの値は通常は０であることから、CTO-FLAGの値は１としている。

コンプリーションパケットのヘッダの生成には、通常、リクエストパケットのヘッダの内容が用いられる。リクエストパケットのヘッダ中の予約語は、コンプリーションパケットのヘッダにそのまま格納されるのが普通である。このことから、コンプリータに特別の機能を追加することなく、CTO-Flagが格納されたリクエストパケットに対するコンプリーションパケットにはCTO-Flagが格納される。

コンプリーションパケットには、リクエストパケットから、“Completer ID”フィールド、及び“Status”フィールド等が追加されている。“Completer ID”フィールドには、処理を行ったデバイスを表すデータが格納され、“Status”フィールドには、処理結果を表すデータが格納される。そのため、リクエスタは、コンプリーションパケットから、処理を行ったデバイス、及びその処理結果を確認することができる。

図７は、ＣＴＯ検出時のリクエスタの動作の流れを表すフローチャートである。最後に図7を参照し、ＣＴＯの検出を契機にしたリクエスタの一連の動作について詳細に説明する。この図７では、同一のタグが付与されたリクエストパケットに着目し、最初のＣＴＯ検出後のリクエスタの動作の流れを抜粋する形で表している。

発生したＣＴＯは、パケット受信モジュール２１によって検出され、タグ管理モジュール２３のＣＴＯテーブル更新部２３２に、ＣＴＯが発生したリクエストパケットに付与されたタグ、及びCTO-Flagの有無と共に通知される。その通知により、ＣＴＯテーブル更新部２３２は、記憶部２３１に格納されているＣＴＯテーブルの通知されたタグのエントリの更新をケース（１）のように行う（Ｓ１）。

ＣＴＯの検出により、送信パケット生成モジュール２２は、そのＣＴＯが発生したリクエストパケット（図４に表す第１のリクエストパケット４０１）に付与されたタグを再送するリクエストパケット（図４に表す第２のリクエストパケット４０２）に再利用すべきタグとして決定する（Ｓ２）。

その後、送信パケット生成モジュール２２は、決定したタグをタグ管理モジュール２３の使用可能タグ管理部２３３に通知して、CTO-Flagの付与の有無を問い合わせる。ここでは、ＣＴＯが検出されたリクエストパケットは第１のリクエストパケット４０１であるため、使用可能タグ管理部２３３は、CTO-Flagの付与を通知する。その結果、送信パケット生成モジュール２２は、CTO-Flag、及び同一のタグを付与したリクエストパケット（図４に表す第２のリクエストパケット４０２）を生成して送信する（以上Ｓ３）。

パケット受信モジュール２１は、送信パケット生成モジュール２２とは独立して動作し、タイマ２１ａを用いて、ＣＴＯの検出を行う（Ｓ４）。そのＣＴＯを検出した場合（Ｓ４のＹＥＳ）、パケット受信モジュール２１は、ＣＴＯの発生、そのＣＴＯが発生したリクエストパケットに付与されているタグ、及びCTO-Flagの有無をＣＴＯテーブル更新部２３２に通知する。その結果、（CTOinfo1，CTOinfo2）=（１，１）の組み合わせが確定し、ＣＴＯテーブル更新部２３２に通知されたタグの使用が一時的に禁止される（Ｓ５）。それにより、一連の動作が終了する。

一方、ＣＴＯが検出されなかった場合（Ｓ４のＮＯ）、パケット受信モジュール２１は、コンプリーションパケットが受信されたか否かの確認を行う（Ｓ６）。コンプリーションパケットを受信した場合（Ｓ６のＹＥＳ）、パケット受信モジュール２１は、返却する（利用可能にする）タグとして、受信したコンプリーションパケットのタグをＣＴＯテーブル更新部２３２に通知する。その結果、通知されたタグが利用可能になるように、そのタグのエントリ中のTagBusy、CTOinfo1、及びCTOinfo2の各値は０に更新される（Ｓ７）。それにより、一連の動作が終了する。

コンプリーションパケットを受信していない場合（Ｓ６のＮＯ）、パケット受信モジュール２１は、タイマ２１ａを用いて、ＣＴＯの検出を行う（Ｓ４）。それにより、リクエスタは、ＣＴＯが検出されるか、或いはコンプリーションパケットが受信されるのを待つ。

なお、本実施形態では、CTO-Flagのビット数は１ビットとしているが、そのビット数は２ビット以上であっても良い。また、CTO-Flagは再送するリクエストパケットに無条件に付与するようにしているが、タグの利用情報に応じて、例えば利用可能なタグの数に応じて、リクエストパケットに付与するタグ、CTO-Flagの付与を決定するようにしても良い。

本実施形態では、タグとは異なる識別子であるCTO-Flagの数は１つとしているが、CTO-Flagのような識別子は複数であっても良い。使用するCTO-Flagのような識別子の数、或いはビット数は、状況に応じて変更できるようにしても良い。

第１のリクエストパケット４０１では、CTO-Flagが事実上、付与されていない。しかし、第１のリクエストパケット４０１にも、CTO-Flagのような識別子を付与させるようにしても良い。

上記以外にも、様々な変形を行うことができる。

１ 情報処理装置
１１ ＣＰＵ
１３ スイッチ
１４、１４−０〜１４−３ エンドポイント
２０ パケット送受信装置
２１ パケット受信モジュール
２１ａ タイマ
２２ 送信パケット生成モジュール
２３ タグ管理モジュール
１１０ ＣＰＵコア
１１１ ルートコンプレックス
２３１ 記憶部
２３２ ＣＴＯテーブル更新部
２３３ 使用可能タグ管理部

Claims (4)

1. 演算処理装置と、複数の入出力装置と、前記演算処理装置と前記複数の入出力装置間の通信をそれぞれ行う複数の通信装置とを備えた情報処理装置において、
   前記複数の通信装置のうち第１の通信装置は、複数の識別子の中から選択された識別子と、前記識別子を有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを示すフラグとが割り当てられた、第１のパケットを送信し、
   前記第１の通信装置は、
   前記複数の識別子それぞれに対応付けて、タイムアウトが発生したことを示すフラグを有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを表す状況情報を記憶した記憶部と、
   前記第１の通信装置宛のパケットを受信する受信部と、
   前記第１のパケットが要求する処理の実行結果を表す第２のパケットの前記受信部による受信結果に基づき、前記記憶部に記憶された状況情報を更新する更新部と、
   前記記憶部に記憶された状況情報に基づき、第１のパケットに割り当てる識別子とフラグの値とを決定する決定部と、
   前記決定部が決定した識別子とフラグとを格納した第１のパケットを生成して送信する第１の送信部とを有し、
   前記複数の通信装置のうち、前記第１のパケットの送信先となる第２の通信装置は、
   前記第１の通信装置が送信した前記第１のパケットへの応答として前記第２のパケットを送信する場合、前記第１のパケットに格納されている前記フラグを前記第２のパケットに格納して送信する第２の送信部を有し、
   前記決定部は、前記受信部がタイムアウトを検出した第１のパケットの識別子を再利用する場合、タイムアウトを検出した第１のパケットとは要求内容が異なる送信対象の第１のパケットの識別子として、タイムアウトを検出した第１のパケットの識別子と同一の識別子を割り当てるとともに、送信対象の第１のパケットのフラグとして、タイムアウトが発生したことを示すフラグを割り当てることを特徴とする情報処理装置。
2. 前記受信部は、
   前記第１のパケットが送信された後、前記第２のパケットを所定時間内に受信しない場合、タイムアウトを検出し、
   前記更新部は、
   前記受信部によるタイムアウトの検出を契機として、状況情報の更新を行う、
   ことを特徴とする請求項１記載の情報処理装置。
3. 複数の識別子それぞれに対応付けて、タイムアウトが発生したことを示すフラグを有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを表す状況情報を記憶した記憶部と、
   パケットを受信する受信部と、
   前記複数の識別子の中から選択された識別子と、前記選択された識別子を有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを示すフラグとが割り当てられた、第１のパケットが要求する処理の実行結果を表す第２のパケットの前記受信部による受信結果に基づき、前記記憶部に記憶された状況情報を更新する更新部と、
   前記記憶部に記憶された状況情報に基づき、第１のパケットに割り当てる識別子とフラグの値とを決定する決定部と、
   前記決定部が決定した識別子とフラグとを格納した第１のパケットを生成して送信する第１の送信部とを有し、
   前記第１のパケットの送信先となる通信装置は、前記第１の送信部が送信した前記第１のパケットへの応答として前記第２のパケットを送信する場合、前記第１のパケットに格納されている前記フラグを前記第２のパケットに格納して送信し、
   前記決定部は、前記受信部がタイムアウトを検出した第１のパケットの識別子を再利用する場合、タイムアウトを検出した第１のパケットとは要求内容が異なる送信対象の第１のパケットの識別子として、タイムアウトを検出した第１のパケットの識別子と同一の識別子を割り当てるとともに、送信対象の第１のパケットのフラグとして、タイムアウトが発生したことを示すフラグを割り当てることを特徴とする送受信装置。
4. 演算処理装置と、複数の入出力装置と、前記演算処理装置と前記複数の入出力装置間の通信をそれぞれ行う複数の通信装置とを備えた情報処理装置の制御方法において、
   前記複数の通信装置のうち、複数の識別子それぞれに対応付けて、タイムアウトが発生したことを示すフラグを有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを表す状況情報を記憶した記憶部を有し、前記複数の識別子の中から選択された識別子と、前記選択された識別子を有するパケットに対する応答の受信待ちにおいてタイムアウトが発生したか否かを示すフラグとが割り当てられた、第１のパケットを送信する第１の通信装置が有する受信部が、前記第１の通信装置宛のパケットを受信し、
   前記第１の通信装置が有する更新部が、前記第１のパケットが要求する処理の実行結果を表す第２のパケットの前記受信部による受信結果に基づき、前記記憶部に記憶された状況情報を更新し、
   前記第１の通信装置が有する決定部が、前記記憶部に記憶された状況情報に基づき、第１のパケットに割り当てる識別子とフラグの値とを決定し、
   前記第１の通信装置が有する第１の送信部が、前記決定部が決定した識別子とフラグとを格納した第１のパケットを生成して送信し、
   前記複数の通信装置のうち、前記第１のパケットの送信先となる第２の通信装置が有する第２の送信部が、前記第１の通信装置が送信した前記第１のパケットへの応答として前記第２のパケットを送信する場合、前記第１のパケットに格納されている前記フラグを前記第２のパケットに格納して送信し、
   前記第１の通信装置が有する決定部は、前記受信部がタイムアウトを検出した第１のパケットの識別子を再利用する場合、タイムアウトを検出した第１のパケットとは要求内容が異なる送信対象の第１のパケットの識別子として、タイムアウトを検出した第１のパケットの識別子と同一の識別子を割り当てるとともに、送信対象の第１のパケットのフラグとして、タイムアウトが発生したことを示すフラグを割り当てることを特徴とする情報処理装置の制御方法。

Images