(57)【要約】  あるＩ／Ｏデバイスのリクエストの処理によって、他のＩ／Ｏデバイスのリクエストの処理が阻害されないようにできる。パケット処理装置は、複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅ（登録商標）ファブリックを構成するパケット処理装置であって、Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理部および第２要求処理部と、ＰＣＩｅパケット発行要求のリクエスト種別、及び、Ｉ／Ｏデバイスへ送信されるパケットがＰＣＩｅファブリックに与える負荷に基づいて、複数の第１要求処理部又は第２要求処理部を選択する第１選択部を備え、第１選択部は、ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、ＰＣＩｅパケット発行要求が、第１要求処理部で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する第１判定部を有する。
2018003629.tif 000002
【特許請求の範囲】
【請求項１】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅ（登録商標）ファブリックを構成するパケット処理装置であって、
前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理手段および第２要求処理手段と、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理手段又は前記第２要求処理手段を選択する第１選択手段を備え、
前記第１選択手段は、
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理手段で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する第１判定手段を有する、
パケット処理装置。
【請求項２】
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子と同じトランザクション識別子を持つ他のＰＣＩｅパケット発行要求を処理中の前記第１要求処理手段が存在する場合、
前記第１判定手段は、前記処理中の第１要求処理手段を選択し、
前記処理中の第１要求処理手段が存在しない場合、
前記第１判定手段は、前記複数の第１要求処理手段のいずれかを選択する、
請求項１に記載のパケット処理装置。
【請求項３】
前記ＰＣＩｅパケット発行要求のリクエスト種別がコンプリーション以外の場合、
前記第１判定手段は、前記第２要求処理手段を選択する、
請求項１又は２に記載のパケット処理装置。
【請求項４】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置であって、
前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理手段および第４要求処理手段と、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理手段又は前記第４要求処理手段を選択する第２選択手段を備え、
前記第２選択手段は、
前記トランザクションパケットの種別が前記メモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理手段で処理中の他のメモリライトリクエストを追い越しできるか判定する第２判定手段を有する、
パケット処理装置。
【請求項５】
前記メモリライトリクエストに含まれるリクエスタ識別子と同じリクエスタ識別子を持つ他のメモリライトリクエストを処理中の前記第３要求処理手段が存在する場合、
前記第２判定手段は、前記処理中の第３要求処理手段を選択し、
前記処理中の第３要求処理手段が存在しない場合、
前記第２判定手段は、前記複数の第３要求処理手段のいずれかを選択する、
請求項４に記載のパケット処理装置。
【請求項６】
前記トランザクションパケットの種別がメモリライトリクエスト以外の場合、
前記第２判定手段は、前記第４要求処理手段を選択する、
請求項４又は５に記載のパケット処理装置。
【請求項７】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理手段および第２要求処理手段を備え、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理手段又は前記第２要求処理手段を選択し、
前記選択の際、
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理手段で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する、
パケット処理装置のパケット処理方法。
【請求項８】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理手段および第４要求処理手段を備え、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理手段又は前記第４要求処理手段を選択し、
前記選択の際、
前記トランザクションパケットの種別が前記メモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理手段で処理中の他のメモリライトリクエストを追い越しできるか判定する、
パケット処理装置のパケット処理方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、パケット処理装置等に関し、特にＩ／Ｏ（Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）デバイスのデータ転送に関する。
【背景技術】
【０００２】
ＰＣＩ  Ｅｘｐｒｅｓｓ（登録商標）（以下、ＰＣＩｅ（登録商標）と略す）は、サーバ又はＰＣ（Ｐｅｒｓｏｎａｌ  Ｃｏｍｐｕｔｅｒ）等のコンピュータにおいて、周辺機器又は周辺デバイス（以下、Ｉ／Ｏデバイスと呼称する）とＣＰＵ（Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）との接続に使用されている。【０００３】
図１８は、ＰＣＩｅを用いたコンピュータ１Ａの構成例を示したものである。図１８を参照すると、コンピュータ１Ａは、ＣＰＵ２と、メモリコントローラ３と、メモリ４と、ＰＣＩｅルートコンプレックス５Ａと、ＰＣＩｅスイッチ６と、Ｉ／Ｏデバイス７を備える。なお、メモリコントローラ３、及び、ＰＣＩｅルートコンプレックス５ＡはＣＰＵ２に組み込まれる構成であってもよい。【０００４】
ＰＣＩｅは、ＰＣＩｅルートコンプレックス５Ａをルートとするツリー型のネットワーク（以降、このネットワークをＰＣＩｅファブリックと呼称する）を構成する。このＰＣＩｅファブリックに、ＰＣＩｅパケットをスイッチングするＰＣＩｅスイッチ６及びＩ／Ｏデバイス７が接続される。なお、ＰＣＩｅルートコンプレックス５Ａ、ＰＣＩｅスイッチ６、又は、Ｉ／Ｏデバイス７をＰＣＩｅデバイスと呼称する場合もある。【０００５】
ＰＣＩｅでは、ＰＣＩｅプロトコルレイヤの第三層に位置するトランザクション層の情報を用いて、ＰＣＩｅルートコンプレックス５Ａ又はＰＣＩｅスイッチ６が、ＰＣＩｅパケットを宛先のＰＣＩｅデバイス（例えばＩ／Ｏデバイス７）に向けてスイッチングする。【０００６】
Ｉ／Ｏデバイス７には様々な種類がある。例えば、ネットワークを介してコンピュータ同士が通信を行うためのＮＩＣ（Ｎｅｔｗｏｒｋ  Ｉｎｔｅｒｆａｃｅ  Ｃａｒｄ）、ディスプレイに画像を表示するためのＧＰＵ（Ｇｒａｐｈｉｃｓ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ）、シリアル通信用のインタフェースであるＲＳ−２３２Ｃ（Ｒｅｃｏｍｍｅｎｄｅｄ  Ｓｔａｎｄａｒｄ  ２３２  ｖｅｒｓｉｏｎ  Ｃ）デバイスである。【０００７】
これらのＩ／Ｏデバイス７は、ＰＣＩｅファブリックに対して様々なデータ転送レートでデータを送受信する。例えば、イーサネット（登録商標）に対応したＮＩＣであれば、１Ｇｂｐｓ、２．５Ｇｂｐｓ、１０Ｇｂｐｓ、４０Ｇｂｐｓといった通信速度でコンピュータ１Ａ同士の通信を行う。そのため、ＮＩＣは、ＰＣＩｅルートコンプレックス５Ａ及びメモリコントローラ３を介して、ＰＣＩｅファブリック内も同程度のデータ転送レートでデータの送受信をメモリ４と行う。このデータの送受信は、ＤＭＡ（Ｄｉｒｅｃｔ  Ｍｅｍｏｒｙ  Ａｃｃｅｓｓ）と呼ばれ、ＣＰＵ２のリソースを使用することなく、メモリ４とＩ／Ｏデバイス７の間で行われる。【０００８】
ＤＭＡにはメモリ４からデータを読み出すＤＭＡ  Ｒｅａｄと、メモリ４へデータを書き込むＤＭＡ  Ｗｒｉｔｅの２種類が存在する。ＤＭＡ  Ｒｅａｄを行う場合、ＰＣＩｅにおいて、まず、Ｉ／Ｏデバイス７がメモリリードリクエストを発行する。このメモリリードリクエストには、メモリ４の、どこの領域から何バイトのデータを読み出すかを示すリードデータ長の情報が含まれている。【０００９】
メモリリードリクエストは、ＰＣＩｅルートコンプレックス５Ａを通じて、メモリコントローラ３に伝えられる。そして、メモリコントローラ３は、メモリ４から、メモリリードリクエストで指定された領域のデータを指定されたサイズを読み出し、ＰＣＩｅルートコンプレックス５Ａを通じて、メモリリードリクエストを発行したＩ／Ｏデバイス７に転送される。メモリ４から読み出されたデータは、ＰＣＩｅルートコンプレックス５Ａにて、ＰＣＩｅパケットのうち、コンプリーションという種別のパケットのヘッダが付加され、ＰＣＩｅファブリックに送出される。【００１０】
ＤＭＡ  Ｒｅａｄでメモリ４から読み出すデータサイズが、１つのＰＣＩｅパケットで運べるデータサイズを上回っていた場合、メモリ４から読み出されたデータは、複数のコンプリーションパケットに分割されて、メモリリードリクエストを発行したＩ／Ｏデバイス７に届けられる。【００１１】
つまり、ＤＭＡ  Ｒｅａｄにおいて、Ｉ／Ｏデバイス７からＰＣＩｅルートコンプレックス５Ａの方向（以降、Ｕｐ方向と呼称する）へは、１つのメモリリードリクエストのＰＣＩｅパケットが流れるのに対して、ＰＣＩｅルートコンプレックス５ＡからＩ／Ｏデバイス７の方向（以降、Ｄｏｗｎ方向と呼称する）へは、１つ以上のＰＣＩｅパケットが流れる。【００１２】
ＤＭＡ  Ｗｒｉｔｅの場合、Ｉ／Ｏデバイス７はメモリライトリクエストのＰＣＩｅパケットを発行する。このメモリライトリクエストには、書き込み先の領域を指すアドレス、転送サイズ、書き込むデータが含まれている。【００１３】
メモリ４に書き込むデータサイズが、１つのＰＣＩｅパケットで運べるデータサイズを上回っていた場合、複数のメモリライトリクエストのＰＣＩｅパケットを用いて、メモリ４にデータが届けられる。【００１４】
ところで、メモリライトリクエストは、ＰＣＩｅにおけるポステッドリクエストと呼ばれる種別のリクエストであり、リクエストを受けた側は応答を返す必要が無い。この応答は、ＤＭＡ  Ｒｅａｄの説明の際に触れたコンプリーションのことである。ＤＭＡ  Ｒｅａｄ時に発行されるメモリリードリクエストは、ノン・ポステッドリクエストという種別であり、ノン・ポステッドリクエストは、リクエストを受けた側が必ず応答（コンプリーション）を返す必要がある。【００１５】
つまり、ＤＭＡ  Ｗｒｉｔｅにおいては、Ｕｐ方向にＩ／Ｏデバイス７が必要とするだけの個数のＰＣＩｅパケットが流れ、Ｄｏｗｎ方向にはＰＣＩｅパケットは流れない。【００１６】
特許文献１には、メモリリードリクエストのヘッダを解析し、転送サイズ等に基づいてメモリリードリクエストの処理の優先度を決定し、優先度に応じたリクエストキューに入れることが可能なＩ／Ｏコントローラが開示されている。【００１７】
特許文献１のＩ／Ｏコントローラは、サーバ仮想化環境を対象とし、仮想マシンごとにＤＭＡの処理状況を監視する。そして、Ｉ／Ｏデバイスからメモリリードリクエスト又はメモリライトリクエストなどのＤＭＡを伴うリクエストが発行された場合、その転送先となる仮想マシンを特定し、その仮想マシンのＤＭＡ実行状況に応じて、そのリクエストを優先度が付されたリクエストキューに入れる。【００１８】
このように、ＰＣＩｅファブリックのリソース（この場合は帯域）を複数の仮想マシンからシェアして使用する場合に、特定の仮想マシンがＰＣＩｅファブリックのリソースを占有しないようにする技術が存在する。【００１９】
さらに、特許文献１では、ノン・ポステッドリクエストと、ポステッドリクエストと、コンプリーションと、に対し、それぞれ別々のリクエストキューを提供する。そして、これらのリクエストキューからリクエストを取り出す優先度を固定的にすることで、ＰＣＩｅの仕様で定められるリクエスト間のオーダリングルールを満たすようにしている。【００２０】
ＰＣＩｅにおけるリクエスト間のオーダリングルールとは、リクエスト間、リクエストとコンプリーション間で追い越しが可能かを定めたルールであり、例えば、ノン・ポステッドリクエストは基本的にポステッドリクエストを追い越すことができない。【００２１】
このオーダリングルールは、ほとんどの場合、コンプリーションを含むリクエスト種別と、ＰＣＩｅパケットのヘッダに含まれるオーダリングに関するフラグ又はリクエストの識別情報との組み合わせによって、追い越し可能かが判断される。【００２２】
ＰＣＩｅでは、ＰＣＩｅパケットのＴＬＰ（Ｔｒａｎｓａｃｔｉｏｎ  Ｌａｙｅｒ  Ｐａｃｋｅｔ）ヘッダの情報を利用して、Ｒｅｌａｘｅｄ  Ｏｒｄｅｒｉｎｇ（以下、ＲＯを記す）と、ＩＤ−Ｂａｓｅｄ  Ｏｒｄｅｒｉｎｇ（以下、ＩＤＯと記す）という２種類のオーダリングルールを決定する仕組みが存在する。【００２３】
ＲＯとＩＤＯは、いずれもＴＬＰヘッダのＡｔｔｒｉｂｕｔｅフィールドに適切な値を設定することで、どのオーダリングルールが適用されるかが決定される。ＲＯとＩＤＯはいずれか一方、または同時に両方を利用することができる。【００２４】
ＲＯを利用することで、あるポステッドリクエストが、先に発行されたポステッドリクエストを追い越したり、あるノン・ポステッドリクエストが、先に発行されたポステッドリクエストを追い越したり、あるコンプリーションが、先に発行されたポステッドリクエストを追い越したりすることが可能になる。【００２５】
また、ＩＤＯを利用すると、同じリクエスト識別子を持つポステッドリクエスト同士の追い越しなどが可能になる。このリクエスト識別子とは、ＴＬＰヘッダに備えられる、タグフィールドの情報と、リクエスタＩＤ（Ｉｄｅｎｔｉｆｉｃａｔｉｏｎ）の組み合わせから構成される。リクエスタＩＤとは、リクエストを発行したＰＣＩｅデバイスのＰＣＩｅファブリック内の識別子である。リクエスタＩＤは、バス（Ｂｕｓ）番号、デバイス（Ｄｅｖｉｃｅ）番号、ファンクション（Ｆｕｎｃｔｉｏｎ）番号という３つの値の組み合わせで構成され、それぞれの頭文字をとってＢＤＦ（登録商標）番号とも呼ばれる。【００２６】
また、特許文献２には、ＰＣＩｅの仕様におけるトランザクションの追い越しに関し、ポステッドトランザクションが高い優先度を持ち、ノン・ポステッドトランザクション又はコンプリーションを追い越すことが可能であることが記載されている。【００２７】
さらに、特許文献３には、ホスト・ブリッジ中で多数の混在するトランザクションをインバウンドおよびアウトバウンドの両方向で効率的に扱うために、インバウンドおよびアウトバウンドのトランザクション要求を、所定の状態機械の制御の下で、特定のタイプのトランザクションおよび定義された順序づけ規則に基づき、順次または非順次のいずれにも扱うことが記載されている。
【先行技術文献】
【特許文献】
【００２８】
【特許文献１】特許第４９９６９２９号公報
【特許文献２】特表２０１４−５０９４２７号公報
【特許文献３】特開平９−１４６８７８号公報
【発明の概要】
【発明が解決しようとする課題】
【００２９】
特許文献１に開示された技術では、同じリクエスト種別間、あるいはコンプリーション間のリクエストの追い越しができないという課題が存在する。これは、特許文献１で開示された技術が、Ｉ／Ｏデバイス間のリクエストのオーダリングを考慮していないためである。【００３０】
例えば、特許文献１に開示された技術では、コンプリーション間の追い越しができず、メモリリードリクエスト（＝ノン・ポステッドリクエスト）に対する応答（コンプリーション）が、コンプリーションを処理するためのキューに積まれた順番に処理される。【００３１】
そのため、例えば、特定のＩ／Ｏデバイス７が発行したメモリリードリクエストに対するコンプリーションが大量に発行されると、他のＩ／Ｏデバイスが発行したメモリリードリクエストに対するコンプリーションの処理が大きく遅れる可能性がある。【００３２】
本発明は、上述した問題点を鑑み、あるＩ／Ｏデバイスのリクエストの処理によって、他のＩ／Ｏデバイスのリクエストの処理が阻害されないパケット処理装置等を提供することを目的とする。
【課題を解決するための手段】
【００３３】
本発明のパケット処理装置は、複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置であって、
前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理部および第２要求処理部と、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理部又は前記第２要求処理部を選択する第１選択部を備え、
前記第１選択部は、
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理部で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する第１判定部を有する。【００３４】
本発明のパケット処理装置は、複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置であって、
前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理部および第４要求処理部と、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理部又は前記第４要求処理部を選択する第２選択部を備え、
前記第２選択部は、
前記トランザクションパケットの種別がメモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理部で処理中の他のメモリライトリクエストを追い越しできるか判定する第２判定部を有する。【００３５】
本発明のパケット処理方法は、複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理部および第２要求処理部を備え、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理部又は前記第２要求処理部を選択し、
前記選択の際、前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理部で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する。【００３６】
本発明のパケット処理方法は、複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理部および第４要求処理部を備え、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理部又は前記第４要求処理部を選択し、
前記選択の際、前記トランザクションパケットの種別がメモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理部で処理中の他のメモリライトリクエストを追い越しできるか判定する。
【発明の効果】
【００３７】
本発明によれば、あるＩ／Ｏデバイスのリクエストの処理によって、他のＩ／Ｏデバイスのリクエストの処理が阻害されないようにできる。
【図面の簡単な説明】
【００３８】
【図１】ＰＣＩ  Ｅｘｐｒｅｓｓを用いたコンピュータの構成を示すブロック図である。
【図２】第１の実施形態に係るＰＣＩｅルートコンプレックスの構成を示すブロック図である。
【図３】ＰＣＩｅルートコンプレックスのＤｏｗｎ方向選択部の構成を示すブロック図である。
【図４】Ｄｏｗｎ要求発行状況管理テーブルの構成例を示す表図である。
【図５】ＰＣＩｅルートコンプレックスのＵｐ方向選択部の構成を示すブロック図である。
【図６】Ｕｐ方向要求発行状況管理テーブルの構成例を示す表図である。
【図７】Ｉ／Ｏデバイステーブルの構成例を示す表図である。
【図８】Ｉ／Ｏデバイステーブルにエントリを追加する動作を示すフローチャートである。
【図９】Ｄｏｗｎ方向要求処理部を選択する際のＤｏｗｎ方向選択部の動作を示すフローチャートである。
【図１０】Ｕｐ方向要求処理部を選択する際のＵｐ方向選択部の動作を示すフローチャートである。
【図１１】第１の実施形態の変形例の構成を示すブロック図である。
【図１２】第２の実施形態に係るＰＣＩｅルートコンプレックスの構成を示すブロック図である。
【図１３】コンプリーションテーブルの構成例を示す表図である。
【図１４】第２の実施形態におけるＤｏｗｎ方向Ｉ／Ｏデバイステーブルの構成例を示す表図である。
【図１５】Ｕｐ方向選択部がコンプリーションテーブルにエントリを追加する際の動作を示すフローチャートである。
【図１６】Ｄｏｗｎ方向選択部がＤｏｗｎ方向要求処理部を選択する動作を示すフローチャートである。
【図１７】第３の実施形態に係るパケット処理装置の構成を示すブロック図である。
【図１８】一般のＰＣＩ  Ｅｘｐｒｅｓｓを用いたコンピュータの構成を示すブロック図である。
【発明を実施するための形態】
【００３９】
本発明の実施形態に係るパケット処理装置について、図面を参照して説明する。なお、以下の説明に付記する図面や参照符号は、理解を助けるための一例として各要素に便宜上、記したものであり、本発明を図示の態様に限定することを意図するものではない。
【００４０】
以下、実施形態に係るパケット処理装置を、コンピュータのＰＣＩｅルートコンプレックスに適用した例を用いて説明する。
【００４１】
図１は、ＰＣＩｅを用いたコンピュータ１の構成例を示したものである。図１を参照すると、コンピュータ１は、ＣＰＵ２と、メモリコントローラ３と、メモリ４と、ＰＣＩｅルートコンプレックス５と、ＰＣＩｅスイッチ６と、Ｉ／Ｏデバイス７を備える。なお、メモリコントローラ３、及び、ＰＣＩｅルートコンプレックス５がＣＰＵ２に組み込まれる構成であってもよい。ＣＰＵ２と、メモリコントローラ３と、メモリ４と、ＰＣＩｅルートコンプレックス５と、ＰＣＩｅスイッチ６と、Ｉ／Ｏデバイス７の詳細な説明については、図１８に示すコンピュータ１Ａの構成要素と同様のため同一の符号を付して詳細な説明は省略する。
【００４２】
また、説明を簡潔にするために、ＩＤＯを対象としたＰＣＩｅオーダリングルールを対象とする例を記載する。このことは、本実施形態をＩＤＯに限定するものではなく、ＲＯを対象としたコンピュータにも適用可能であることは言うまでもない。あるいは、ＩＤＯおよびＲＯの両方を利用するコンピュータ、または、同様の仕組みをオーダリングルールに使用するコンピュータにも同様の手法で適用可能である。
【００４３】
そして、ルートコンプレックスは、ＩＤＯをサポートし、利用可能な状態であるものとする。Ｉ／Ｏデバイスについては、ＩＤＯをサポート、未サポートのいずれでもよい。
【００４４】
［第１の実施の形態］
［構成の説明］
図２は、本発明の第１の実施形態に係る、ＰＣＩｅルートコンプレックス５の構成を示すブロック図である。図２を参照すると、ＰＣＩｅルートコンプレックス５は、Ｄｏｗｎ方向選択部５０と、複数のＤｏｗｎ方向コンプリーション処理部５１と、Ｄｏｗｎ方向低負荷要求処理部５２と、Ｄｏｗｎ方向出力部５３と、Ｕｐ方向選択部５４と、複数のＵｐ方向メモリライトリクエスト処理部５５と、Ｕｐ方向低負荷要求処理部５６と、Ｕｐ方向出力部５７と、Ｉ／Ｏデバイステーブル５８と、Ｉ／Ｏデバイステーブル設定インタフェース６０を備える。
【００４５】
まず、ＰＣＩｅルートコンプレックス５において、Ｄｏｗｎ方向（ＰＣＩｅルートコンプレックス５からＩ／Ｏデバイス７の方向）の処理を担う構成について説明する。
【００４６】
Ｄｏｗｎ方向選択部５０は、Ｄｏｗｎ方向のポステッドリクエスト発行要求、ノン・ポステッドリクエスト発行要求、あるいはコンプリーションの発行要求（以下、これらをまとめてＰＣＩｅパケット発行要求と呼称する）を、Ｄｏｗｎ方向コンプリーション処理部５１又はＤｏｗｎ方向低負荷要求処理部５２に処理させるかを選択する機能を有する。なお、Ｄｏｗｎ方向コンプリーション処理部５１、Ｄｏｗｎ方向低負荷要求処理部５２のそれぞれを、Ｄｏｗｎ方向要求処理部と呼称する場合がある。
【００４７】
Ｄｏｗｎ方向選択部５０は、ＰＣＩｅパケット発行要求のリクエスト種別と、Ｉ／Ｏデバイステーブル５８の情報を参照することで、Ｄｏｗｎ方向コンプリーション処理部５１、Ｄｏｗｎ方向低負荷要求処理部５２のいずれかを選択する。Ｄｏｗｎ方向選択部５０は、選択したＤｏｗｎ方向コンプリーション処理部５１、またはＤｏｗｎ方向低負荷要求処理部５２、に対して、ＣＰＵ２又はメモリコントローラ３からのＰＣＩｅパケット発行要求を通知する。
【００４８】
ＰＣＩｅパケット発行要求には、リクエスト種別、リクエスタＩＤ、タグ、転送データサイズ、転送するデータ、又は、メモリアドレスなど、ＴＬＰを構築するのに必要な情報が含まれる。ＴＬＰを構築するのに必要な情報は、リクエスト種別ごとに異なる。詳しくはＰＣＩｅの仕様書に開示されている。なお、コンプリーションのＴＬＰを構築する場合、コンプリータＩＤという、コンプリーションＴＬＰの発行元のＰＣＩｅデバイスを示す識別子の情報が必要である。第１の実施形態では、ＰＣＩｅルートコンプレックス５がコンプリーションＴＬＰの発行元となるため、コンプリータＩＤは、ＰＣＩｅルートコンプレックス５の識別子となる。
【００４９】
ＰＣＩｅルートコンプレックス５のＤｏｗｎ方向選択部５０の構成について説明する。図３は、Ｄｏｗｎ方向選択部５０の構成を示すブロック図である。図３を参照すると、Ｄｏｗｎ方向選択部５０は、Ｄｏｗｎ方向要求判定部５０２と、Ｄｏｗｎ方向外部テーブル参照部５０３と、Ｄｏｗｎ方向要求発行部５０４と、Ｄｏｗｎ方向要求発行状況管理テーブル５０５を備える。
【００５０】
Ｄｏｗｎ方向要求判定部５０２は、ＣＰＵ２などから発行されたＰＣＩｅパケット発行要求を、どのＤｏｗｎ方向要求処理部で処理するかを判定するモジュールである。Ｄｏｗｎ方向要求判定部５０２は、Ｉ／Ｏデバイステーブル５８、Ｄｏｗｎ方向要求発行状況管理テーブル５０５を参照して、要求を処理するＤｏｗｎ方向要求処理部を決定する。Ｄｏｗｎ方向要求判定部５０２は、ＰＣＩｅパケット発行要求を、要求を処理するＤｏｗｎ方向要求処理部の識別子とともに、Ｄｏｗｎ方向要求発行部５０４に渡す。
【００５１】
Ｄｏｗｎ方向外部テーブル参照部５０３は、Ｄｏｗｎ方向選択部５０の外部のテーブル（例えば、図２のＩ／Ｏデバイステーブル５８）を参照するためのインタフェースである。
【００５２】
また、Ｄｏｗｎ方向要求判定部５０２は、Ｄｏｗｎ方向外部テーブル参照部５０３を通じて、Ｄｏｗｎ方向選択部５０の外部のテーブルを参照し、ＰＣＩｅパケットの送信先となるＩ／Ｏデバイス７が、高負荷なデータ転送を伴うＩ／Ｏデバイスであるかを示す負荷情報を得る。
【００５３】
Ｄｏｗｎ方向要求発行部５０４は、Ｄｏｗｎ方向要求判定部５０２からＰＣＩｅパケット発行要求と、その要求を処理するＤｏｗｎ方向要求処理部の識別子を受け取り、当該識別子が示すＤｏｗｎ方向要求処理部にＰＣＩｅパケット発行要求を転送する。
【００５４】
Ｄｏｗｎ方向要求発行部５０４は、ＰＣＩｅパケット発行要求をＤｏｗｎ方向要求処理部に転送すると、Ｄｏｗｎ方向要求発行状況管理テーブル５０５に、送信したＰＣＩｅパケット発行要求の情報を記録する。また、Ｄｏｗｎ方向要求発行部５０４は、Ｄｏｗｎ方向要求処理部からＰＣＩｅパケット発行要求の処理を完了したことを示す処理完了通知を受け取ると、該当するＰＣＩｅパケット発行要求の情報を、Ｄｏｗｎ方向要求発行状況管理テーブル５０５から削除する。
【００５５】
Ｄｏｗｎ方向要求発行状況管理テーブル５０５は、Ｄｏｗｎ方向要求処理部が処理中のＰＣＩｅパケット発行要求の情報を管理するためのテーブルである。
【００５６】
図４は、Ｄｏｗｎ方向要求発行状況管理テーブル５０５の構成を示す図である。
【００５７】
図４を参照すると、Ｄｏｗｎ方向要求発行状況管理テーブル５０５は、Ｄｏｗｎ方向要求処理部の識別子（図４の要求処理部ＩＤ５０５０）と、トランザクションＩＤ（図４のトランザクションＩＤ５０５１）と、各Ｄｏｗｎ方向要求処理部が処理中のＰＣＩｅパケット発行要求のリクエスト種別（図４のリクエスト種別５０５２：ポステッドリクエスト、ノン・ポステッドリクエスト、及び、コンプリーションのいずれか）の対応をエントリとして保持するテーブルである。
【００５８】
図４において、要求処理部ＩＤ５０５０のコンプリーション処理部０、１、２は、複数のＤｏｗｎ方向コンプリーション処理部５１の識別子を示し、低負荷要求処理部は、Ｄｏｗｎ方向低負荷要求処理部５２の識別子を示す。
【００５９】
Ｄｏｗｎ方向要求発行部５０４がＰＣＩｅパケット発行要求をＤｏｗｎ方向要求処理部に発行するごとに、Ｄｏｗｎ方向要求発行部５０４は、発行した先のＤｏｗｎ方向要求処理部に対応するエントリとして、リクエスタＩＤとタグを含むトランザクションＩＤをＤｏｗｎ方向要求発行状況管理テーブル５０５に登録する。
【００６０】
また、Ｄｏｗｎ方向要求発行部５０４は、Ｄｏｗｎ方向要求処理部からＰＣＩｅパケット発行要求の処理を完了したことを示す処理完了通知を受け取ると、その処理完了通知を出したＤｏｗｎ方向要求処理部に対応するエントリのトランザクションＩＤとリクエスト種別と、をＤｏｗｎ方向要求発行状況管理テーブル５０５から削除する。
【００６１】
Ｄｏｗｎ方向要求処理部は、Ｄｏｗｎ方向選択部５０から通知されたＰＣＩｅパケット発行要求を元に、ＴＬＰを生成する。生成したＴＬＰは、Ｄｏｗｎ方向出力部５３へ転送される。
【００６２】
なお、特定のＤｏｗｎ方向コンプリーション処理部５１のみに処理が集中する状況を避けるため、Ｄｏｗｎ方向コンプリーション処理部５１の処理は、例えばラウンドロビンで順番に行ってもよい。また、仮想化技術によりソフトウェアでＰＣＩｅルートコンプレックスを実現する場合には、異なるＣＰＵリソースを割り当てる構成を採用してもよい。
【００６３】
次に、Ｄｏｗｎ方向出力部５３は、少なくとも１つの出力ポートを備える。各出力ポートの先には、Ｉ／Ｏデバイス７や、ＰＣＩｅスイッチ６などを１つ接続することができる。Ｄｏｗｎ方向出力部５３は、Ｄｏｗｎ方向要求処理部から転送されたＴＬＰを、ＴＬＰのヘッダに含まれる宛先情報を元に出力ポートを選択し、ＴＬＰを宛先のＩ／Ｏデバイス７に向けて出力する。
【００６４】
ＴＬＰのヘッダに含まれる宛先情報として、ＢＤＦ番号を使用する場合と、メモリアドレスを指定する場合がある。Ｄｏｗｎ方向出力部５３は、各出力ポートの先に、どのＢＤＦ番号を持つＩ／Ｏデバイス７又はＰＣＩｅスイッチ６が接続されているか、どの範囲のアドレスが割り当てられたＩ／Ｏデバイス７又はＰＣＩｅスイッチ６が接続されているかを管理する管理テーブルを有する。管理テーブルは、典型的には、ＢＤＦ番号やアドレスの範囲をキーとし、出力ポートの識別子をバリューとするテーブル構成である。
【００６５】
次に、ＰＣＩｅルートコンプレックス５におけるＵｐ方向（Ｉ／Ｏデバイス７からＰＣＩｅルートコンプレックス５の方向）の処理を担う構成について説明する。
【００６６】
Ｕｐ方向選択部５４は、Ｉ／Ｏデバイス７又はＰＣＩｅスイッチ６から送信されたＴＬＰのヘッダに含まれるリクエスト種別と、リクエスタＩＤの情報に基づいて、Ｕｐ方向メモリライトリクエスト処理部５５、又は、Ｕｐ方向低負荷要求処理部５６を選択する機能を有する。なお、Ｕｐ方向メモリライトリクエスト処理部５５とＵｐ方向低負荷要求処理部５６のそれぞれを、Ｕｐ方向要求処理部と呼称する場合がある。
【００６７】
Ｕｐ方向選択部５４の構成について説明する。図５は、Ｕｐ方向選択部５４の構成を示すブロック図である。Ｕｐ方向選択部５４は、Ｕｐ方向要求判定部５４２と、Ｕｐ方向外部テーブル参照部５４３と、Ｕｐ方向要求発行部５４４と、Ｕｐ方向要求発行状況管理テーブル５４５を備える。
【００６８】
Ｕｐ方向要求判定部５４２は、Ｉ／Ｏデバイス７又はＰＣＩｅスイッチ６から受信したＴＬＰを、どのＵｐ方向要求処理部に転送するかを判定するモジュールである。Ｕｐ方向要求判定部５４２は、Ｉ／Ｏデバイステーブル５８、Ｕｐ方向要求発行状況管理テーブル５４５を参照し、受信したＴＬＰをどのＵｐ方向要求処理部に転送するかを決定する。転送先のＵｐ方向要求処理部が決定されたＴＬＰは、当該Ｕｐ方向要求処理部の識別子とともに、Ｕｐ方向要求発行部５４４に渡される。
【００６９】
Ｕｐ方向外部テーブル参照部５４３は、Ｕｐ方向選択部５４の外部のテーブル（例えば、図２のＩ／Ｏデバイステーブル５８）を参照するためのインタフェースである。
【００７０】
Ｕｐ方向要求判定部５４２は、Ｕｐ方向外部テーブル参照部５４３を通じて、Ｕｐ方向選択部５４のＩ／Ｏデバイステーブル５８を参照し、ＴＬＰの送信元のＩ／Ｏデバイス７が、高負荷なデータ転送を伴うＩ／Ｏデバイスであるかを示す負荷情報を得る。
【００７１】
Ｕｐ方向要求発行部５４４は、Ｕｐ方向要求判定部５４２からＴＬＰと、そのＴＬＰを処理するＵｐ方向要求処理部の識別子を受け取り、このＵｐ方向要求処理部の識別子が示すＤｏｗｎ方向要求処理部にＴＬＰを転送する。
【００７２】
Ｕｐ方向要求発行部５４４は、ＴＬＰをＵｐ方向要求処理部に転送すると、Ｕｐ方向要求発行状況管理テーブル５４５に、転送したＴＬＰの情報を記録する。また、Ｕｐ方向要求発行部５４４は、Ｕｐ方向要求処理部からＴＬＰの処理を完了したことを示す処理完了通知を受取る場合、該当するＴＬＰの情報を、Ｕｐ方向要求発行状況管理テーブル５４５から削除する。
【００７３】
Ｕｐ方向要求発行状況管理テーブル５４５は、Ｕｐ方向要求処理部が処理中のＴＬＰの情報を管理するためのテーブルである。
【００７４】
図６は、Ｕｐ方向要求発行状況管理テーブル５４５の構成例を示す表図である。
【００７５】
図６を参照すると、Ｕｐ方向要求発行状況管理テーブル５４５は、Ｕｐ方向要求処理部の識別子（図６の要求処理部ＩＤ５４５０）と、リクエスタＩＤ（図４のリクエスタＩＤ５４５１）と、各Ｕｐ方向要求処理部が処理中のＰＣＩｅパケット発行要求のリクエスト種別（図６のリクエスト種別：ポステッドリクエスト、ノン・ポステッドリクエスト又はコンプリーションのいずれか）の対応をエントリとして保持するテーブルである。図６に示す要求処理部ＩＤ５４５０において、メモリライトリクエスト処理部０、１、２は、Ｕｐ方向メモリライトリクエスト処理部５５の識別子を示し、低負荷要求処理部は、Ｕｐ方向低負荷要求処理部５６の識別子を示す。
【００７６】
Ｕｐ方向要求発行状況管理テーブル５４５には、Ｕｐ方向要求発行部５４４がＴＬＰの処理要求をＵｐ方向要求処理部に発行するごとに、発行した先のＵｐ方向要求処理部に対応するエントリに、トランザクションＩＤとしてリクエスタＩＤが登録される。
【００７７】
また、Ｕｐ方向要求発行部５４４は、Ｕｐ方向要求処理部からＴＬＰの処理を完了したことを示す処理完了通知を受け取ると、その処理完了通知を出したＵｐ方向要求処理部に対応するエントリのトランザクションＩＤ及びリクエスト種別をＵｐ方向要求発行状況管理テーブル５４５から削除する。
【００７８】
Ｕｐ方向選択部５４は、少なくとも１つの入力ポートを備える。各入力ポートには、Ｉ／Ｏデバイス７又はＰＣＩｅスイッチ６などからのＴＬＰが入力される。このＴＬＰは、基本的にメモリ４へのデータの書き込み要求（メモリライトリクエスト）又はデータの読み出し要求（メモリリードリクエスト）である。
【００７９】
Ｕｐ方向選択部５４は、選択したＵｐ方向要求処理部に、Ｉ／Ｏデバイス７又はＰＣＩｅスイッチ６などからのＴＬＰを、処理要求として転送する。
【００８０】
Ｕｐ方向要求処理部であるＵｐ方向メモリライトリクエスト処理部５５又はＵｐ方向低負荷要求処理部５６は、Ｕｐ方向選択部５４から転送されたＴＬＰのヘッダを解析し、リクエスト種別に応じた処理を行う。
【００８１】
例えば、メモリライトリクエストであれば、Ｕｐ方向要求処理部は、メモリ４への書き込みであることを示す情報と、ＴＬＰのペイロード部と、ＴＬＰのヘッダ部に含まれる宛先アドレス情報を取り出し、取り出した情報をＵｐ方向出力部５７に転送する。
【００８２】
また、メモリリードリクエストであれば、Ｕｐ方向要求処理部は、メモリ４からの読み出しであることを示す情報と、ＴＬＰのヘッダ部に含まれる宛先アドレスと、ＴＬＰのヘッダ部で指定されたデータ長の情報を取り出し、取り出した情報をＵｐ方向出力部５７に転送する。
【００８３】
各Ｕｐ方向メモリライトリクエスト処理部５５での処理は、例えば、ラウンドロビンで交互に行うことで特定のＵｐ方向メモリライトリクエスト処理部５５に関わる処理を実行し続ける状況を避けることができる。なお、ソフトウェアでＰＣＩｅルートコンプレックスの機能を実現する場合には、異なるＣＰＵリソースを割り当てることで特定のＵｐ方向メモリライトリクエスト処理部５５に処理が集中すること避けることができる。
【００８４】
Ｕｐ方向要求処理部で、ＴＬＰに対する処理が完了すると、処理が完了した旨をＵｐ方向選択部５４に通知する。この処理完了通知には、少なくともＵｐ方向要求処理部の識別子（要求処理部ＩＤ）が含まれる。
【００８５】
Ｕｐ方向出力部５７は、Ｕｐ方向要求処理部から転送されたＴＬＰに含まれる情報を、メモリコントローラ３など、適切なモジュールに転送する。
【００８６】
Ｉ／Ｏデバイステーブル５８は、ＰＣＩｅファブリックに接続されたＩ／Ｏデバイス７の識別子と、そのＩ／Ｏデバイス７がＰＣＩｅファブリック中で高負荷なデータ転送を行うかを示す負荷情報と、を登録したテーブルである。
【００８７】
図７は、Ｉ／Ｏデバイステーブル５８の構成例を示す表図である。図７を参照すると、Ｉ／Ｏデバイステーブル５８は、Ｉ／ＯデバイスＩＤ（図７のＩ／ＯデバイスＩＤ５８０）をキーとし、Ｉ／ＯデバイスＩＤに対応するＩ／Ｏデバイス７が高負荷なデータ転送を行うかを示す負荷情報（図７の負荷５８１）、をバリューとするエントリを登録したテーブルである。
【００８８】
Ｉ／Ｏデバイステーブル設定インタフェース６０は、ＰＣＩｅルートコンプレックス５の外部から、Ｉ／Ｏデバイステーブル５８にエントリを登録するためのインタフェースである。
【００８９】
Ｉ／Ｏデバイステーブル設定インタフェース６０を利用したエントリの登録方法としては、次のようなものが挙げられる。例えば、ＰＣＩｅルートコンプレックス５に割り当てられたメモリ領域の特定のアドレスに対して、コンピュータ１上で稼働するソフトウェアによって、エントリ情報が書き込まれると、Ｉ／Ｏデバイステーブル設定インタフェース６０を通じて、Ｉ／Ｏデバイステーブル５８にエントリ情報が登録される。なお、ソフトウェアは、ＯＳ（Ｏｐｅｒａｔｉｎｇ  Ｓｙｓｔｅｍ）又はアプリケーションのいずれであってもよい。
［動作の説明］
次に、図面を参照して、本実施形態のＰＣＩｅルートコンプレックスの動作について説明する。
【００９０】
まず、ＰＣＩｅルートコンプレックス５のＩ／Ｏデバイステーブル５８にエントリを登録する動作について説明する。
【００９１】
図８は、Ｉ／Ｏデバイステーブル５８にエントリを登録する動作を示すフローチャートである。以下は、ＰＣＩｅルートコンプレックス５を備えるコンピュータ１で稼働するソフトウェア（ＯＳまたはアプリケーション）が、Ｉ／Ｏデバイステーブル５８にエントリを登録する例である。
【００９２】
まず、ソフトウェアは、コンピュータ１に備えられたＩ／Ｏデバイス７のデバイス情報を取得する（図８のステップＦ４８０）。デバイス情報には少なくとも、Ｉ／Ｏデバイス７の識別子（例えば、ＢＤＦ番号）と、Ｉ／Ｏデバイス７の種別と、このＩ／Ｏデバイス７のデータ転送速度が含まれる。これらのデバイス情報は、例えば、コンピュータ１のＯＳがＬｉｎｕｘ（登録商標）の環境であって、このＬｉｎｕｘで稼働するアプリケーションの場合、ｌｓｐｃｉコマンド又はｄｍｅｓｇコマンドの出力を利用することで得ることができる。
【００９３】
次に、ソフトウェアは、図８のステップＦ４８０で得たデバイス情報を元に、各Ｉ／Ｏデバイス７のデータ転送の負荷を判断する（図８のステップＦ４８１）。この判断は、Ｉ／Ｏデバイス７の種別、Ｉ／Ｏデバイスが必要とする転送速度又は転送頻度に基づいて行われる。例えば、Ｉ／Ｏデバイス７がＮＩＣ又はＧＰＵである場合、ＮＩＣ又はＧＰＵはデータの転送速度又は転送頻度が高いデバイスであることから、ソフトウェアはＮＩＣ又はＧＰＵに関するデータ転送は高負荷であると判断する。
【００９４】
次に、ソフトウェアは、Ｉ／Ｏデバイス７のＩＤと、図８のステップＦ４８１で判断したＩ／Ｏデバイス７のデータ転送等に基づく負荷情報をＩ／Ｏデバイステーブル５８に登録する（図８のステップＦ４８２）。
【００９５】
ソフトウェアは、所望のＩ／Ｏデバイス７に対して、図８のステップＦ４８２の処理を実行したかを判断する（図８のステップＦ４８３）。所望のＩ／Ｏデバイス７は、コンピュータ１に搭載された一部又は全部のＩ／Ｏデバイスであってもよい。
【００９６】
所望のＩ／Ｏデバイス７に対して、図８のステップＦ４８２の処理を実行していない場合（図８のステップＦ４８３のＮｏ）、これらの処理を実行していないＩ／Ｏデバイス７に対して、図８のステップＦ４８２の処理を実行する。
【００９７】
所望のＩ／Ｏデバイス７に対して、これらの処理を実行した後（図８のステップＦ４８３）、ソフトウェアはＩ／Ｏデバイステーブル５８へのエントリの登録を完了する（図８のステップＦ４８３のＹｅｓ）。
【００９８】
なお、Ｉ／Ｏデバイステーブル５８へのエントリの登録（ステップＦ４８１〜４８３）の動作については、エントリの登録後にＰＣＩｅルートコンプレックス５と接続されるＩ／Ｏデバイス７の変更（追加又は削除）がなければ、省略してもよい。
【００９９】
なお、コンピュータ１上のソフトウェア以外に、回路等のハードウェアによってエントリ登録が実行されてもよい。さらに、他の機器からＩ／Ｏデバイステーブル５８のエントリ情報を取得して登録してもよい。
【０１００】
次に、図面を用いて、ＰＣＩｅルートコンプレックス５がＤｏｗｎ方向送信処理要求を処理する場合の動作について説明する。
【０１０１】
図９は、Ｄｏｗｎ方向選択部５０が、Ｄｏｗｎ方向要求処理部を選択する動作を示すフローチャートである。
【０１０２】
Ｄｏｗｎ方向選択部５０は、ＣＰＵ２などから、Ｉ／Ｏデバイス７宛のＰＣＩｅパケット発行要求を受け取ると、ＰＣＩｅパケット発行要求のリクエスト種別をもとに、Ｉ／Ｏデバイステーブル５８と、Ｄｏｗｎ方向要求発行状況管理テーブル５０５と、を参照し、その要求を処理するＤｏｗｎ方向要求処理部を選択する。
【０１０３】
ＰＣＩｅパケット発行要求には、少なくとも送信するＰＣＩｅのリクエスト種別（例えば、メモリライトリクエスト、メモリリードリクエスト、コンフィギュレーションリードリクエスト、又は、コンプリーション）、宛先のＩ／Ｏデバイス７の識別子（例えば、ＢＤＦ番号またはメモリアドレス）、転送データサイズ、が含まれる。また、ＰＣＩｅパケット発行要求には、メモリリードリクエストに対するコンプリーションのトランザクション処理時などのタグ情報など、リクエスト固有に必要な情報も含まれる。
【０１０４】
Ｄｏｗｎ方向選択部５０が備えるＤｏｗｎ方向要求判定部５０２は、トランザクション種別がコンプリーションの場合に（図９のステップＦ５００のＹｅｓ）、Ｉ／Ｏデバイス７の識別子を用いて、Ｉ／Ｏデバイステーブル５８を参照し、ＰＣＩｅパケット送信先のＩ／Ｏデバイス７が、高負荷なデータ転送を伴うかを判定する（図９のステップＦ５０１）。
【０１０５】
ＰＣＩｅパケット送信先のＩ／Ｏデバイス７が、高負荷なデータ転送を伴うＩ／Ｏデバイスの場合（図９のステップＦ５０２のＹｅｓ）、Ｄｏｗｎ方向要求判定部５０２は、Ｄｏｗｎ方向要求発行状況管理テーブル５０５を参照する（図９のステップＦ５０３）。
【０１０６】
ＰＣＩｅパケット送信要求に含まれるリクエスタＩＤとタグの情報が一致するエントリがＤｏｗｎ方向要求発行状況管理テーブル５０５に存在する場合（図９のステップＦ５０４のＹｅｓ）、同じトランザクションＩＤを持つコンプリーションがＤｏｗｎ方向コンプリーション処理部５１で処理中であることを示す。この場合、Ｄｏｗｎ方向要求判定部５０２は、コンプリーション間の追い抜きが発生しないように、処理中のＤｏｗｎ方向コンプリーション処理部５１を選択する（図９のステップＦ５０５）。
【０１０７】
ＰＣＩｅパケット送信要求に含まれるリクエスタＩＤとタグの情報が一致するエントリが、Ｄｏｗｎ方向要求発行状況管理テーブル５０５に存在しない場合（図９のステップＦ５０４のＮｏ）、いずれかのＤｏｗｎ方向コンプリーション処理部５１を選択する（図９のステップＦ５０６）。
【０１０８】
なお、図９のステップＦ５０６におけるＤｏｗｎ方向コンプリーション処理部５１の選択方法として、例えば、要求を処理していないＤｏｗｎ方向コンプリーション処理部５１を優先的に選択する方法、ラウンドロビンでＤｏｗｎ方向コンプリーション処理部５１を順番に選択する方法、又は、各Ｄｏｗｎ方向コンプリーション処理部５１の負荷をモニタリングし、最も負荷の低いＤｏｗｎ方向コンプリーション処理部５１を選択する方法がある。
【０１０９】
一方、ＣＰＵ２などから受け取ったＰＣＩｅパケット発行要求のトランザクション種別がコンプリーションでない場合（図９のステップＦ５００のＮｏ）、Ｄｏｗｎ方向要求判定部５０２は、Ｄｏｗｎ方向低負荷要求処理部５２を選択する（図９のステップＦ５０７）。
【０１１０】
さらに、Ｄｏｗｎ方向要求判定部５０２は、ＰＣＩｅパケット発行要求を、図９のステップＦ５０５、ステップＦ５０６、又は、ステップＦ５０７で選択したＤｏｗｎ方向要求処理部に転送可能かを判定する（図９のステップＦ５０８）。
【０１１１】
この「転送可能」とは、図９のステップＦ５０５、ステップＦ５０６、又は、ステップＦ５０７で選択されたＤｏｗｎ方向要求処理部が、Ｄｏｗｎ方向要求発行状況管理テーブル５０５で何の処理も実行していない状態（図４のトランザクションＩＤ５０５１、リクエスト種別５０５２が「未割当」の状態）であることを指す。また、転送するＰＣＩｅパケット発行要求がコンプリーションの場合に、Ｄｏｗｎ方向低負荷要求処理部５２で、ポステッドリクエストが処理されていない状態であることを示す。
【０１１２】
そのため、ＰＣＩｅパケット発行要求を転送できない場合（図９のステップＦ５０８のＮｏ）、Ｄｏｗｎ方向要求判定部５０２は、一定時間待機後にＰＣＩｅパケット発行要求を再度転送可能か、Ｄｏｗｎ方向要求発行状況管理テーブル５０５を参照して判定する（図９のステップＦ５０８）。
【０１１３】
ＰＣＩｅパケット発行要求を転送可能な場合、Ｄｏｗｎ方向要求判定部５０２は、Ｄｏｗｎ方向要求発行部５０４に、ＰＣＩｅパケット発行要求と、この要求を処理するＤｏｗｎ方向要求処理部の識別子を送信する（図９のステップＦ５０９）。
【０１１４】
Ｄｏｗｎ方向要求発行部５０４は、Ｄｏｗｎ方向要求判定部５０２から受け取ったＰＣＩｅパケット発行要求を、指定されたＤｏｗｎ方向要求処理部に転送する。
【０１１５】
以上の処理により、適切なＤｏｗｎ方向要求処理部（Ｄｏｗｎ方向コンプリーション処理部５１又はＤｏｗｎ方向低負荷要求処理部５２）にＰＣＩｅパケット発行要求が転送される。
【０１１６】
図９のステップＦ５００において、Ｄｏｗｎ方向要求判定部５０２が、最初にトランザクション種別がコンプリーションであるかを判定する理由について述べる。
【０１１７】
Ｉ／Ｏデバイス７からのメモリリードリクエストに対して、実際にメモリ４から読み出されたデータをＩ／Ｏデバイス７に転送する際のトランザクション種別は、コンプリーションである。この場合のメモリリードリクエストはＤＭＡ転送によるものであり、Ｉ／Ｏデバイス７がＮＩＣ又はＧＰＵの場合、大量のデータがコンプリーションパケットによってＰＣＩｅファブリックを流れることになる。そのため、Ｄｏｗｎ方向要求判定部５０２は、例えば、データ転送による負荷の高いコンプリーションを判別するために、まずコンプリーションかを判定するように動作する。なお、コンプリーションの場合、宛先のＩ／Ｏデバイス７の識別子としてＢＤＦ番号が使用される。
【０１１８】
また、ＰＣＩｅの仕様上、メモリリードリクエストに対するコンプリーション、又はメモリライトリクエスト以外のＰＣＩｅパケットでは、１つのＰＣＩｅパケットで大量のデータを転送することができない。このため、これら以外のＰＣＩｅパケットでは、大きな負荷がＤｏｗｎ方向要求処理部にかからない。
【０１１９】
さらに、メモリライトリクエストをＤｏｗｎ方向で実行することは、ＣＰＵ２に大きな負荷がかかるため、一般的には行われない。あるいは、ＣＰＵ２などの仕様で１つのＴＬＰで大量のデータを転送できないように制限されているケースもある。
【０１２０】
そのため、Ｄｏｗｎ方向選択部５０は、コンプリーション以外のＰＣＩｅパケット発行要求に対して、Ｄｏｗｎ方向低負荷処理部を選択するように動作する。
【０１２１】
Ｄｏｗｎ方向要求処理部は、Ｄｏｗｎ方向選択部５０から転送されたＰＣＩｅパケット発行要求に含まれる情報からＴＬＰを構築し、Ｄｏｗｎ方向出力部５３に構築したＴＬＰを転送する。このＴＬＰには、ＩＤＯのフラグがセットされていてもよい。
【０１２２】
Ｄｏｗｎ方向要求処理部は、構築したＴＬＰをＤｏｗｎ方向出力部５３に転送し、処理完了通知をＤｏｗｎ方向選択部５０に通知する。この処理完了通知には少なくともＤｏｗｎ方向要求処理部の識別子が含まれる。
【０１２３】
Ｄｏｗｎ方向選択部５０が備えるＤｏｗｎ方向要求発行部５０４は、Ｄｏｗｎ方向要求処理部から処理完了通知を受け取り、処理完了通知に含まれるＤｏｗｎ方向要求処理部の識別子に該当するエントリのトランザクションＩＤとリクエスト種別を、Ｄｏｗｎ方向要求発行状況管理テーブル５０５から削除する。
【０１２４】
Ｄｏｗｎ方向出力部５３は、Ｄｏｗｎ方向要求処理部から転送されたＴＬＰを宛先情報に従って、ＴＬＰを適切な出力ポートに出力する。
【０１２５】
以上の処理により、ＰＣＩｅルートコンプレックス５で、Ｄｏｗｎ方向のＰＣＩｅパケット発行要求が処理される。そして、コンプリーションとそれ以外の種別のＰＣＩｅパケットは別のＤｏｗｎ方向要求処理部で処理されるため、ＤＭＡ転送等で大量にコンプリーションが発生した場合にも、コンプリーション以外の種別のＰＣＩｅパケットの送信が大きく遅れるようなことはない。
【０１２６】
さらに、この構成であれば、Ｄｏｗｎ方向のＰＣＩｅパケットのオーダリングルールを守ることができる。第１の実施形態では、次の３パターンのパケットの追い越しが起こりうる。
（パターン１）  コンプリーションがコンプリーションを追い越す。
（パターン２）  コンプリーションがコンプリーション以外のＰＣＩｅパケットを追い越す。
（パターン３）  コンプリーション以外のＰＣＩｅパケットがコンプリーションを追い越す。
【０１２７】
まず、（パターン１）について、コンプリーション同士は、トランザクションＩＤが異なれば追い越しが許可されている。しかし、図９のステップＦ５０４の処理で、２つのコンプリーションのトランザクションＩＤが同じであれば、同じＤｏｗｎ方向コンプリーション処理部５１で順に処理される。このため、コンプリーション同士の追い越しは起こらない。
【０１２８】
また、Ｄｏｗｎ方向コンプリーション処理部５１で処理中のコンプリーション（高負荷）と、Ｄｏｗｎ方向低負荷要求処理部５２で処理中のコンプリーション（低負荷）間で、追い越しが発生する可能性がある。しかし、Ｄｏｗｎ方向低負荷要求処理部５２で処理されるＰＣＩｅパケット発行要求は、Ｉ／Ｏデバイステーブル５８で「低負荷」と設定されたＩ／Ｏデバイス７であり、Ｄｏｗｎ方向低負荷要求処理部５２でコンプリーションが処理されるＩ／Ｏデバイス７とは、デバイスの識別子が異なる。このため、これらのコンプリーションのトランザクションＩＤは、必ず互いに異なる。従って、追い越しが発生しても問題ない。
【０１２９】
次に、（パターン２）について、ＰＣＩｅの仕様上、コンプリーションはノン・ポステッドリクエストを無条件で追い越すことが可能である。また、ＰＣＩｅの仕様上、コンプリーションは、ポステッドリクエストを、＜１＞ＲＯフラグが立っているコンプリーションは、追い越すことが可能である。さらに、コンプリーションは、ポステッドリクエストを、＜２＞ＩＤＯフラグが立っているコンプリーションは、コンプリーションのコンプリータＩＤと、ポステッドリクエストのリクエスタＩＤが異なる場合に、追い越しが可能である。
【０１３０】
第１の実施形態では、ＰＣＩｅルートコンプレックス５を対象にしているため、コンプリーションのコンプリータＩＤ、ポステッドリクエストのリクエスタＩＤは、ともにＰＣＩｅルートコンプレックス５を指すＩＤとなる。そのため、ＰＣＩｅルートコンプレックス５では、基本的にコンプリーションはポステッドリクエストを追い越すことができない。
【０１３１】
第１の実施形態では、図９のステップＦ５０８で、ＰＣＩｅパケット発行要求がコンプリーションの場合に、ポステッドリクエストがＤｏｗｎ方向低負荷要求処理部５２で処理中であるかを確認してからＰＣＩｅパケット発行要求を、Ｄｏｗｎ方向要求発行部に送信する。このため、コンプリーションがポステッドリクエストを追い越すことができない。つまり、（パターン２）の状況が発生しない。
【０１３２】
次に、（パターン３）について、ＰＣＩｅの仕様上、コンプリーション以外のＰＣＩｅパケットは、コンプリーションを追い越してもよく、特別なケアを行う必要が無い。
【０１３３】
次に、図面を用いて、Ｕｐ方向のＴＬＰをＰＣＩｅルートコンプレックス５で処理する場合の動作について説明する。
【０１３４】
図１０は、Ｕｐ方向選択部５４が、Ｕｐ方向要求処理部を選択する動作を示すフローチャートである。
【０１３５】
Ｕｐ方向選択部５４は、Ｉ／Ｏデバイス７又はＰＣＩｅスイッチ６からＴＬＰを受け取ると、ＴＬＰの種別をもとに、Ｉ／Ｏデバイステーブル５８と、Ｕｐ方向要求発行状況管理テーブル５４５を参照し、要求を処理するＵｐ方向要求処理部を選択する。
【０１３６】
Ｕｐ方向選択部５４が備えるＵｐ方向要求判定部５４２は、ＴＬＰの種別がメモリライトリクエスト（ポステッドリクエスト）の場合に（図１０のステップＦ５４０のＹｅｓ）、ＴＬＰのリクエスタＩＤを用いて、Ｉ／Ｏデバイステーブル５８を参照し、ＴＬＰの送信元のＩ／Ｏデバイス７が、高負荷なデータ転送を伴うＩ／Ｏデバイスかを判定する（図１０のステップＦ５４１）。
【０１３７】
次に、Ｕｐ方向要求判定部５４２は、ＴＬＰの送信元のＩ／Ｏデバイス７が、高負荷なデータ転送を伴うＩ／Ｏデバイスである場合（図１０のステップＦ５４２のＹｅｓ）、Ｕｐ方向要求発行状況管理テーブル５４５を参照する（図１０のステップＦ５４３）。
【０１３８】
Ｕｐ方向要求発行状況管理テーブル５４５を参照した結果、図１０のステップＦ５４０で受け取ったＴＬＰと同じリクエスタＩＤを持つメモリライトリクエストが、Ｕｐ方向要求処理部のうち、いずれかのＵｐ方向メモリライトリクエスト処理部５５で処理中である場合（図１０のステップＦ５４４のＹｅｓ）、そのＵｐ方向メモリライトリクエスト処理部５５を、図１０のステップＦ５４０で受け取ったメモリライトリクエストのＴＬＰを処理するＵｐ方向要求処理部として選択する（図１０のステップＦ５４５）。これにより、同じリクエスタＩＤを持つメモリライトリクエスト同士の追い越しが発生しないようにする。
【０１３９】
同じリクエスタＩＤを持つメモリライトリクエストが、いずれのＵｐ方向メモリライトリクエスト処理部５５でも処理されていない場合（図１０のステップＦ５４４のＮｏ）、いずれかのＵｐ方向メモリライトリクエスト処理部５５を選択する（図１０のステップＦ５４６）。
【０１４０】
図１０のステップＦ５４０で受け取ったＴＬＰの種別がメモリライトリクエストでない場合（図１０のステップＦ５４０のＮｏ）、Ｕｐ方向要求判定部５４２は、Ｕｐ方向低負荷要求処理部５６を選択する（図１０のステップＦ５４７）。
【０１４１】
次に、Ｕｐ方向要求判定部５４２は、図１０のステップＦ５４５、ステップＦ５４６、又は、ステップＦ５４７で選択したＵｐ方向要求処理部にＴＬＰを、転送可能かを判定する（図１０のステップＦ５４８）。
【０１４２】
ここで「転送可能」とは、次の条件を満たした状態であることを示す。
（条件１）  図１０のステップＦ５４５、ステップＦ５４６、又は、ステップＦ５４７で選択したＵｐ方向要求処理部が、Ｕｐ方向要求発行状況管理テーブル５４５で何の処理も実行していない（図６のリクエスタＩＤ５４５１、リクエスト種別５４５２が「未割当」の状態）。
（条件２）  図１０のステップＦ５４０で受け取ったＴＬＰにＩＤＯフラグが付与されていない場合に、いずれのＵｐ方向要求処理部でポステッドリクエストが処理中でない。
（条件３）  図１０のステップＦ５４０で受け取ったＴＬＰにＩＤＯフラグが付与されている場合に、いずれのＵｐ方向要求処理部でも、同じリクエスタＩＤを持つポステッドリクエストが処理中でない。
【０１４３】
そのため、Ｕｐ方向要求判定部５４２は、ＴＬＰを転送できない場合（図１０のステップＦ５４８のＮｏ）、一定時間待機後に再度ＴＬＰを転送可能か、Ｕｐ方向要求発行状況管理テーブル５４５を参照して判定する。
【０１４４】
ＴＬＰを転送可能な場合（図１０のステップＦ５４８のＹｅｓ）、Ｕｐ方向要求判定部５４２は、Ｕｐ方向要求発行部５４４に、ＴＬＰと、このＴＬＰを処理するＵｐ方向要求処理部の識別子を送信する（図１０のステップＦ５４９）。
【０１４５】
Ｕｐ方向要求発行部５４４は、Ｕｐ方向要求判定部５４２から受け取ったＴＬＰを、指定されたＵｐ方向要求処理部に転送する。以上の処理により、適切なＵｐ方向要求処理部にＴＬＰが転送される。
【０１４６】
Ｉ／Ｏデバイス７からのメモリライトリクエストはＤＭＡ転送によるものであり、Ｉ／Ｏデバイス７がＮＩＣ又はＧＰＵの場合、大量のデータがメモリライトリクエストのＴＬＰによってＰＣＩｅファブリックを流れることになる。図１０のステップＦ５４０において、まずＴＬＰがメモリライトリクエストかを判定するのは、高負荷なデータ転送を伴うメモリライトリクエストを判別するためである。
【０１４７】
また、ＰＣＩｅの仕様上、メモリリードリクエストに対するコンプリーション、またはメモリライトリクエスト以外のＰＣＩｅパケットでは、１つのＰＣＩｅパケットで大量のデータを転送することができないため、これら以外のＰＣＩｅパケットでは、大きな負荷がＵｐ方向要求処理部にかからない。そのため、Ｕｐ方向選択部５４は、メモリライトリクエスト以外のＴＬＰに対しては、Ｕｐ方向低負荷要求処理部５６を選択する。
【０１４８】
このように、各Ｕｐ方向要求処理部は、Ｕｐ方向選択部５４から転送されたＴＬＰから情報を取り出し、取り出した情報をＵｐ方向出力部５７に転送する。Ｕｐ方向出力部５７は、Ｕｐ方向要求処理部から転送されたＴＬＰパケットに含まれる情報を、メモリコントローラ３など、適切なモジュールに転送する。
【０１４９】
以上の処理により、Ｕｐ方向のＴＬＰがＰＣＩｅルートコンプレックス５で処理される。
【０１５０】
Ｕｐ方向要求処理部は、ＴＬＰに含まれる情報をＵｐ方向出力部５７に転送し、処理完了通知をＵｐ方向選択部５４に通知する。処理完了通知には少なくともＵｐ方向要求処理部の識別子が含まれる。
【０１５１】
Ｕｐ方向選択部５４が備えるＵｐ方向要求発行部５４４は、Ｕｐ方向要求処理部からの処理完了通知を受け取り、完了通知に含まれるＵｐ方向要求処理部の識別子に該当するエントリのトランザクションＩＤとリクエスト種別の情報を、Ｕｐ方向要求発行状況管理テーブル５４５から削除する。
【０１５２】
以上の処理により、ＰＣＩｅルートコンプレックス５で、Ｕｐ方向のＴＬＰが処理される。そして、メモリライトリクエストとそれ以外の種別のＴＬＰは別のＵｐ方向要求処理部で処理されるため、ＤＭＡ転送等で大量にメモリライトリクエストが発生した場合にも、メモリライトリクエスト以外の種別のＴＬＰの送信が大きく遅れることにはならない。
【０１５３】
さらに、この構成であれば、Ｕｐ方向のＴＬＰのオーダリングルールを守ることができる。第１の実施形態において、次の３パターンのパケットの追い越しが起こりうる。
（パターン１）  メモリライトリクエストのＴＬＰが、ポステッドリクエストのＴＬＰを追い越す。
（パターン２）  メモリライトリクエストのＴＬＰが、ポステッドリクエスト以外のＴＬＰを追い越す。
（パターン３）ポステッドリクエスト以外のＴＬＰが、ポステッドリクエストのＴＬＰを追い越す。
【０１５４】
まず、（パターン１）について、ＰＣＩｅの仕様上、ポステッドリクエスト同士は、ＲＯまたはＩＤＯのフラグが立っていない場合は、追い越しが認められていない（メモリライトリクエストはポステッドリクエストの一種である）。第１の実施形態では、ＩＤＯのフラグが立っていないポステッドリクエストは、図１０のステップＦ５４８で、ポステッドリクエストを処理しているＵｐ方向要求処理部が存在しなくなるまで待つため、ポステッドリクエスト間の追い越しは起こらない。
【０１５５】
また、ＩＤＯのフラグが立っている場合は、ポステッドリクエスト同士の追い越しが可能となるが、互いにリクエスタＩＤが異なることが条件である。第１の実施形態では、図１０のステップＦ５４８で、ＩＤＯのフラグが立っている場合には、同じリクエスタＩＤを持つポステッドリクエストを処理中のＵｐ方向要求処理部が存在しなくなるまで待つため、問題となる追い越しは発生しない。
【０１５６】
次に、（パターン２）について、ＰＣＩｅの仕様上、ポステッドリクエストはポステッドリクエスト以外のＴＬＰを追い越すことができるため、パターン２の追い越しは問題ない。
【０１５７】
次に、（パターン３）について、第１の実施形態では、ポステッドリクエスト以外のＴＬＰはＵｐ方向低負荷要求処理部５６で処理される。ＰＣＩｅの仕様上、ポステッドリクエスト以外のＴＬＰは、ＩＤＯのフラグが立っていない場合は、ポステッドリクエストの追い越しは認められていない。さらに、ＩＤＯのフラグが立っている場合でも、同じリクエスタＩＤを持つポステッドリクエスト（第１の実施形態ではメモリライトリクエストのみが対象）がＵｐ方向メモリライトリクエスト処理部５５で処理されていないことを、図１０のステップＦ５４９で確認してから、このＴＬＰがＵｐ方向要求処理部に転送されるため、問題となる追い越しは発生しない。第１の実施形態の例では、Ｕｐ方向低負荷要求処理部５６は１つしか備えないため、Ｕｐ方向低負荷要求処理部５６でのポステッドリクエスト以外のＴＬＰが、ポステッドリクエストのＴＬＰを追い越すことはない。
【０１５８】
（第１の実施形態の変形例）
なお、Ｉ／Ｏデバイステーブル５８を、Ｕｐ方向Ｉ／Ｏデバイステーブル、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブルと、トランザクションの方向ごとに設けることもできる。
【０１５９】
例えば、ＧＰＵでデータをディスプレイに表示する場合、Ｄｏｗｎ方向のデータ転送は多く発生するものの、Ｕｐ方向のデータ転送はさほど発生しない。これは、ＰＣＩｅルートコンプレックス５からＧＰＵへ転送されるデータはディスプレイに表示するためのものであり、そのデータをＧＰＵから取得して、ＧＰＵ以外のＩ／Ｏデバイス７が何らかの処理に使用することが少ないためである。これは、Ｕｐ方向とＤｏｗｎ方向のデータ転送量又はデータ転送頻度に差があることを意味する。
【０１６０】
図１１は、第１の実施形態の変形例の構成を示すブロック図である。図１１に示す第１の実施形態の変形例は、Ｕｐ方向とＤｏｗｎ方向それぞれに、Ｉ／Ｏデバイステーブルを備える。
【０１６１】
ＧＰＵのようにＵｐ方向のデータ転送があまり発生せず、Ｄｏｗｎ方向のデータ転送が多く発生するＩ／Ｏデバイス７の場合、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６１に、ＧＰＵのデバイスＩＤと、ＧＰＵが高負荷であることを示す情報をエントリとして登録する。さらに、Ｕｐ方向Ｉ／Ｏデバイステーブル６２に、ＧＰＵのデバイスＩＤと、ＧＰＵが低負荷であることを示す情報をエントリとして登録する。このようにすることで、Ｕｐ方向とＤｏｗｎ方向のデータ転送量又はデータ転送頻度に差があるＩ／Ｏデバイスに対して、Ｕｐ方向要求処理部とＤｏｗｎ方向要求処理部のぞれぞれで適切な選択が可能となる。
【０１６２】
Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６１と、Ｕｐ方向Ｉ／Ｏデバイステーブル６２へのエントリの登録方法は、図８に示すＩ／Ｏデバイステーブルにエントリを登録する方法と同様に実行可能である。
【０１６３】
なお、第１の実施形態の例では、Ｕｐ方向要求処理部およびＤｏｗｎ方向要求処理部のそれぞれにおいて、高負荷な要求を処理する処理部と、低負荷な要求を処理する処理部の２つに分ける構成を採用しているが、これに限られない。例えば、負荷をさらに細分化し、より多くの負荷レベルに対応する処理部をＵｐ方向、Ｄｏｗｎ方向のそれぞれに備える構成であってもよい。より具体的には、低負荷、中負荷１、中負荷２、高負荷のように４段階の処理部をＵｐ方向とＤｏｗｎ方向に備える場合、ＮＩＣであれば１００Ｍｂｐｓ以下、１Ｇｂｐｓ、２．５Ｇｂｐｓ、１０Ｇｂｐｓ以上のように、転送速度によって分類し、それぞれ異なる負荷レベルに対応する処理部（低負荷、中負荷１、中負荷２、高負荷）で処理する構成を採用してもよい。
【０１６４】
［効果の説明］
第１の実施形態では、要求処理部を高負荷な要求を処理する処理部と、低負荷な要求を処理する処理部に分け、転送先または転送元となっているＩ／Ｏデバイス７の識別子と、ＰＣＩｅパケット発行要求又はＴＬＰの種別に応じて、要求処理部を選択する。
【０１６５】
この選択に使用されるテーブルは、Ｉ／Ｏデバイス７の種別と、Ｉ／Ｏデバイス７が必要とするデータ転送速度に基づいてエントリが登録される。また、ＰＣＩｅの仕様で定められているオーダリングルールを考慮し、既に要求処理部で処理されているＰＣＩｅパケット発行要求またはＴＬＰの種別に応じて、次の処理要求の発行を待つように動作する。
【０１６６】
これによって、ＰＣＩｅの仕様で定められているオーダリングルールを守りつつ、ＮＩＣなどの高負荷なデータ転送を伴うＩ／Ｏデバイス７に対しては高負荷な要求を処理する処理部で処理を行い、ＲＳ−２３２ｃデバイスの低負荷なデータ転送を行うＩ／Ｏデバイス７に対しては低負荷な要求を処理する処理部で処理が行われるようになり、高負荷なデータ転送を行うＩ／Ｏデバイス７の処理によって、低負荷なデータ転送を行うＩ／Ｏデバイス７の処理が行われないという状況を防ぐことができる。
【０１６７】
［第２の実施の形態］
次に、本発明の第２の実施形態について、図面を参照して詳細に説明する。なお、第２の実施形態において、第１の実施形態と同様の構成要素に対しては、同じ符号を付し、詳細な説明を省略する。
【０１６８】
［構成の説明］
図１２は、本発明の第２の実施形態に係る、ＰＣＩｅルートコンプレックス５の構成を示すブロック図である。図１２を参照すると、第２の実施形態のＰＣＩｅルートコンプレックス５は、コンプリーションテーブル５９と、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３をさらに備える点で図２に示す第１の実施形態の構成と異なる。
【０１６９】
第２の実施形態のＰＣＩｅルートコンプレックス５において、コンプリーションテーブル５９、およびＤｏｗｎ方向Ｉ／Ｏデバイステーブル６３は、Ｄｏｗｎ方向選択部５０およびＵｐ方向選択部５４に接続される。Ｄｏｗｎ方向選択部５０は、Ｉ／Ｏデバイステーブル５８とは接続されない。
【０１７０】
コンプリーションテーブル５９には、Ｉ／Ｏデバイス７からのメモリリードリクエストに対して発生するコンプリーションの情報が登録される。
【０１７１】
図１３は、コンプリーションテーブル５９の構成を示す表図である。図１３を参照すると、コンプリーションテーブル５９は、トランザクションＩＤ（図１３のトランザクションＩＤ５９０）をキーとし、コンプリーションのＴＬＰによって転送される残りの転送サイズ（図１３の残りの転送サイズ５９１）と、コンプリーションのＴＬＰを処理するＤｏｗｎ方向要求処理部（図１３の処理部負荷５９２）をバリューとして得るテーブル構造である。
【０１７２】
図１３に示すようにトランザクションＩＤ５９０は、コンプリーションのＴＬＰに含まれるリクエスタＩＤおよびタグの組み合わせで構成される。
【０１７３】
コンプリーションテーブル５９のエントリは、Ｕｐ方向選択部５４がメモリリードリクエストのＴＬＰをＩ／Ｏデバイス７から受け取った際に、Ｕｐ方向選択部５４がメモリリードリクエストのＴＬＰに含まれる情報を元に登録する。
【０１７４】
図１４は、第２の実施形態におけるＤｏｗｎ方向Ｉ／Ｏデバイステーブル６３の構成例を示す表図である。図１４を参照すると、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３は、Ｉ／Ｏデバイス７のＩＤ（図１４のＩ／ＯデバイスＩＤ６３０）をキーとし、スレッショルド値（図１４のスレッショルド６３１）をバリューとするエントリを登録したテーブルである。このスレッショルド値は、そのＩ／Ｏデバイス７が発行したメモリリードリクエストのリードサイズが何バイト以上の時に、Ｄｏｗｎ方向選択部５０が、Ｄｏｗｎ方向コンプリーション処理部５１を選択するかを示す基準値となる。
【０１７５】
Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３にエントリを登録する際に、スレッショルド値の設定を変えることでＤｏｗｎ方向選択部５０によるＤｏｗｎ方向要求処理部の選択先を制御することが可能となる。例えば、スレッショルド値をゼロに設定することで、Ｄｏｗｎ方向選択部５０が特定のＩ／Ｏデバイス７に対して常にＤｏｗｎ方向コンプリーション処理部５１を選択するようにできる。
【０１７６】
また、スレッショルド値に予め定義された値を設定することで、Ｄｏｗｎ方向選択部５０が特定のＩ／Ｏデバイス７に対してＤｏｗｎ方向低負荷要求処理部５２を選択するようにできる。この予め定義された値の例として、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３に登録可能なスレッショルド値の最大値を用いることが考えられる。例えば、スレッショルド値が３２ビット幅の非負の整数値であれば、１６進数で０ｘＦＦＦＦＦＦＦＦに相当する値を設定する。
【０１７７】
Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３は、Ｉ／Ｏデバイステーブル設定インタフェース６０を通じて、図８と同様の手順で設定される。
【０１７８】
［動作の説明］
次に、図面を参照して、第２の実施形態におけるＰＣＩｅルートコンプレックスの動作を説明する。
【０１７９】
図１５は、ＰＣＩｅルートコンプレックス５のＵｐ方向選択部５４が、コンプリーションテーブル５９にエントリを追加する際の動作を示すフローチャートである。
【０１８０】
まず、Ｕｐ方向選択部５４が備えるＵｐ方向要求判定部５４２が、メモリリードリクエストのＴＬＰを受け取ると（図１５のステップＦ５４４のＹｅｓ）、Ｕｐ方向選択部５４は、受け取ったＴＬＰのリクエスタＩＤをキーとしてＤｏｗｎ方向Ｉ／Ｏデバイステーブル６３を参照する（図１５のステップＦ５４５）。
【０１８１】
メモリリードリクエストに含まれるリードサイズの情報と、Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル６３の該当するエントリのスレッショルド値を比較し（図１５のステップＦ５４７）、スレッショルド値よりもリードサイズが大きい場合（図１５のステップＦ５４７のＹｅｓ）、Ｄｏｗｎ方向コンプリーション処理部５１を選択し（図１５のステップＦ５４８）、リードサイズがスレッショルド値以下の場合（図１５のステップＦ５４７のＮｏ）、Ｄｏｗｎ方向低負荷要求処理部５２を選択する（図１５のステップＦ５４９）。
【０１８２】
次に、Ｕｐ方向選択部５４は、図１５のステップＦ５４８またはステップＦ５４９で取得した、いずれのＤｏｗｎ方向要求処理部で処理するかに関する情報と、受け取ったＴＬＰのヘッダ部に含まれているトランザクションＩＤ（リクエスタＩＤとタグのペア）と、同じくＴＬＰのヘッダ部に含まれている転送サイズに関する情報と、をコンプリーションテーブル５９に登録する（図１５のステップＦ５５０）。
【０１８３】
Ｕｐ方向選択部５４は、受け取ったＴＬＰがメモリリードリクエスト以外の場合（図１５のステップＦ５４４のＮｏ）、コンプリーションテーブル５９へのエントリを追加することなく、図１５の処理を終了する。
【０１８４】
以上の処理により、コンプリーションテーブル５９にエントリが追加される。
【０１８５】
なお、図１０の処理と図１５の処理は互いに独立であるため、Ｕｐ方向要求判定部５４２は、どちらから実行しても問題ない。
【０１８６】
次に、図面を用いて、Ｄｏｗｎ方向選択部５０が、ＰＣＩｅパケット発行要求を受け取った場合に、どのようにＤｏｗｎ方向要求処理部を選択するかについて説明する。
【０１８７】
図１６は、Ｄｏｗｎ方向選択部５０がＤｏｗｎ方向要求処理部を選択する動作を示すフローチャートである。具体的には、Ｄｏｗｎ方向選択部５０が、ＰＣＩｅパケット発行要求を受け取った場合に、コンプリーションテーブル５９を用いて、Ｄｏｗｎ方向要求処理部を選択する処理が示されている。図１６のフローチャートは、図９のステップＦ５００と、図９のステップＦ５０２の間に挿入される。このため、図９と共通の個所については説明を省略する。
【０１８８】
Ｄｏｗｎ方向選択部５０が、コンプリーションのトランザクション処理要求を受け取ると（図９のステップＦ５００のＹｅｓ）、Ｄｏｗｎ方向選択部５０は、トランザクションＩＤを用いてコンプリーションテーブル５９を参照し、Ｄｏｗｎ方向要求処理部を選択する（図１６のステップＦ５１０）。
【０１８９】
次に、Ｄｏｗｎ方向選択部５０は、トランザクション処理要求に含まれるデータ転送サイズの分だけ、コンプリーションテーブル５９の該当エントリの転送サイズの値を減らす（図１６のステップＦ５１２）。
【０１９０】
次に、Ｄｏｗｎ方向選択部５０は、該当エントリの残りの転送サイズがゼロになった場合に（図１６のステップＦ５１３のＹｅｓ）、コンプリーションテーブル５９から、該当エントリを削除する（図１６のステップＦ５１４）。
【０１９１】
Ｄｏｗｎ方向選択部５０は、該当エントリの残りの転送サイズがゼロでない場合（図１６のステップＦ５１３のＮｏ）、エントリを削除する処理を行わない。
【０１９２】
以上の処理により、Ｄｏｗｎ方向選択部５０は、コンプリーションテーブル５９を用いてＤｏｗｎ方向要求処理部を選択する。
【０１９３】
なお、第２の実施形態のように、Ｄｏｗｎ方向要求処理部がコンプリーションと低負荷の２種類の場合、コンプリーションテーブル５９には、Ｄｏｗｎ方向コンプリーション処理部５１を使用するコンプリーションの情報のみを登録することも考えられる。この場合、コンプリーションテーブル５９にエントリが存在しないコンプリーションの処理要求は、Ｄｏｗｎ方向低負荷要求処理部５２で処理されるように動作する。
【０１９４】
つまり、図１６のステップＦ５１０の前に、コンプリーションテーブル５９にエントリが存在するかを判定するステップが挿入されることになり、判定がＮｏ（エントリがコンプリーションテーブル５９に存在しない）場合には、図９のステップＦ５０７を次に実行することになる。
【０１９５】
この場合、コンプリーションテーブル５９から、処理部（図１３の処理部負荷５９２）の項目が不要になる。
【０１９６】
この構成の場合であっても、下記のＤｏｗｎ方向のＰＣＩｅパケットのオーダリングルールを守ることができる。第２の実施形態の例では、次の３パターンのパケットの追い越しが起こりうる。
（パターン１）  コンプリーションがコンプリーションを追い越す。
（パターン２）  コンプリーションがコンプリーション以外のＰＣＩｅパケットを追い越す。
（パターン３）  コンプリーション以外のＰＣＩｅパケットがコンプリーションを追い越す。
【０１９７】
第２の実施形態で影響を受けるパターンは（パターン１）である。つまり、同じＩ／Ｏデバイス７宛のコンプリーションであっても、Ｄｏｗｎ方向コンプリーション処理部５１と、Ｄｏｗｎ方向低負荷要求処理部５２のいずれでもコンプリーションが処理される可能性がある。
【０１９８】
しかしながら、コンプリーションテーブルはトランザクションＩＤでコンプリーションを識別するため、同じトランザクションＩＤを持つコンプリーションは同じＤｏｗｎ方向要求処理部で処理される。そのため、同じトランザクションＩＤを持つコンプリーション同士の追い越しは発生しない。
【０１９９】
一般に、Ｉ／Ｏデバイス７がメモリリードリクエストを発行する場合、リクエスト間でトランザクションＩＤ（のタグ情報）を変更して発行するため、このＩ／Ｏデバイス７について、Ｄｏｗｎ方向低負荷要求処理部５２で処理されるコンプリーションと、Ｄｏｗｎ方向コンプリーション処理部５１で処理されるコンプリーションのトランザクションＩＤは互いに異なる。
【０２００】
以上のことより、（１）のケースであっても、問題となる追い越しは発生しない。
【０２０１】
［効果の説明］
次に、第２の実施形態の効果について説明する。
【０２０２】
第２の実施形態では、Ｕｐ方向選択部５４が、メモリリードリクエストのＴＬＰを受け取った際に、メモリリードリクエストでリードするデータサイズに応じて選択したＤｏｗｎ方向要求処理部の情報とともに、メモリリードリクエストへの応答として発生するコンプリーションの情報をコンプリーションテーブル５９に登録する。
【０２０３】
これにより、高負荷なデータ転送を伴うＩ／Ｏデバイス７であっても、データサイズが小さければＤｏｗｎ方向低負荷要求処理部５２を選択できるようになり、よりきめ細かいＤｏｗｎ方向要求処理部の選択が可能となる。
【０２０４】
（その他）
ＰＣＩ  ＥｘｐｒｅｓｓのＰＣＩｅルートコンプレックス５相当の機能を、コンピュータ１上で動くプログラムとして実現する仮想化技術がある。
【０２０５】
サーバ仮想化環境を対象として、仮想マシンモニタ（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ  Ｍｏｎｉｔｏｒ：ＶＭＭ）が、ＶＭＭ上で稼働する仮想マシン（Ｖｉｒｔｕａｌ  Ｍａｃｈｉｎｅ：ＶＭ）からのＩ／Ｏデバイスへのアクセスをトラップし、ＰＣＩｅパケットを生成し、ＮＩＣを通じて汎用ネットワーク上に接続されたＩ／Ｏデバイスに送信する手法である。
【０２０６】
これまでハードウェアとして実現されてきたＰＣＩｅデバイスをソフトウェアで実現する手法が現れてきている。このことにより、高いデータレートを必要とするＩ／Ｏデバイス７のデータ転送により、低いデータレートでデータ転送を行うＩ／Ｏデバイス７のデータ転送が阻害される可能性が出てきている。
【０２０７】
先に述べたＮＩＣやＧＰＵでは、高いデータ転送レートでメモリ４とのデータ転送を行うが、シリアル通信用のインタフェースでは、６４Ｋｂｐｓなど、ＮＩＣやＧＰＵで求められるデータ転送レートに比べて１０００分の１以下のレートでしか通信を行わない。
【０２０８】
ＮＩＣやＧＰＵが絶え間なくメモリ４とＤＭＡによるデータ転送を行った場合、シリアル通信用のインタフェースのデータ転送が阻害され、このインタフェースを通じたシリアル通信が行えなくなる可能性がある。
【０２０９】
ハードウェアで実現されたＰＣＩｅデバイスの場合、ＮＩＣなどの高いレートでデータ転送を行うＩ／Ｏデバイス７が必要とする以上のデータレートでＰＣＩｅデバイス間を接続することができるため、このような問題は発生しなかった。
【０２１０】
一方、ソフトウェアでＰＣＩｅデバイスを実現してＰＣＩｅパケットの転送処理を実行する場合、ハードウェアで実現されたＰＣＩｅデバイスほどの性能は達成できない。
【０２１１】
第１、第２の実施形態によれば、ソフトウェアでＰＣＩｅルートコンプレックスを実現したコンピュータにおいて、特定のＩ／ＯデバイスにＰＣＩｅルートコンプレックスのリソースを占有させることを防ぐことができる。
【０２１２】
なお、本発明の構成は、ソフトウェア又はハードウェアで構成されたＰＣＩｅコンポーネントのいずれでも実現することは可能である。
【０２１３】
上記第１、第２の実施形態に係るＰＣＩｅルートコンプレックス５だけでなく、ＰＣＩｅスイッチ６にも適用することが可能である。この場合、Ｄｏｗｎ方向選択部はＰＣＩｅパケット発行要求ではなく、ＴＬＰを受け取ることになり、Ｄｏｗｎ方向要求処理部はＴＬＰの構築ではなく、ＴＬＰの転送処理を行うことになる。
【０２１４】
［第３の実施の形態］
第３の実施形態に係るパケット処理装置２０は、第１実施形態に係るＰＣＩｅルートコンプレックス５の構成に相当する装置である。以下、第３の実施形態のパケット処理装置の説明において、第１実施形態に係るＰＣＩｅルートコンプレックス５、及び、コンピュータ１と同様の構成については、同じ符号を付して詳細な説明は省略する。
【０２１５】
図１７は、第３の実施形態に係るパケット処理装置２０の構成を示すブロック図である。図１と図１７を参照すると、ＰＣＩｅルートコンプレックス５と同様に、パケット処理装置２０は、複数のＩ／Ｏデバイス７のルートとして接続され、ＰＣＩｅファブリックを構成する。
【０２１６】
パケット処理装置２０は、第１選択部１０と、複数の第１要求処理部１１と、第２要求処理部１２と、第１判定部１３と、第２選択部１４と、複数の第３要求処理部１５と、第４要求処理部１６と、第２判定部１７を備える。
【０２１７】
（Ｄｏｗｎ方向：パケット処理装置２０からＩ／Ｏデバイス７への方向）
複数の第１要求処理部１１および第２要求処理部１２は、Ｉ／Ｏデバイス７へのＰＣＩｅパケット発行要求を処理する。第１選択部１０は、ＰＣＩｅパケット発行要求のリクエスト種別、及び、Ｉ／Ｏデバイスへ送信されるパケットがＰＣＩｅファブリックに与える負荷に基づいて、複数の第１要求処理部１１又は第２要求処理部１２を選択する。第１選択部１０の第１判定部１３は、パケット処理要求に含まれるトランザクション識別子に基づいて、ＰＣＩｅパケット発行要求が、第１要求処理部で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する。
【０２１８】
ＰＣＩｅパケット発行要求に含まれるトランザクション識別子と同じトランザクション識別子を持つ他のＰＣＩｅパケット発行要求を処理中の第１要求処理部１１が存在する場合、第１判定部１３は、処理中の第１要求処理部を選択する。一方、処理中の第１要求処理部１１が存在しない場合、第１判定部１３は、複数の第１要求処理部１１のいずれかを選択する。
【０２１９】
また、ＰＣＩｅパケット発行要求のリクエスト種別がコンプリーション以外の場合、第１判定部１３は、第２要求処理部１２を選択する。
【０２２０】
（Ｕｐ方向：Ｉ／Ｏデバイス７からパケット処理装置２０への方向）
パケット処理装置２０の複数の第３要求処理部１５および第４要求処理部１６は、Ｉ／Ｏデバイス７からのトランザクションパケットを処理する。
【０２２１】
第２選択部１４は、トランザクションパケットの種別、及び、Ｉ／Ｏデバイス７からのトランザクションパケットがＰＣＩｅファブリックに与える負荷に基づいて、複数の第３要求処理部１５又は第４要求処理部１６を選択する。第２選択部１４の第２判定部１７は、トランザクションパケットの種別がメモリライトリクエストである場合、メモリライトリクエストに含まれるリクエスタ識別子に基づいて、メモリライトリクエストが第３要求処理部１５で処理中の他のメモリライトリクエストを追い越しできるか判定する。
【０２２２】
メモリライトリクエストに含まれるリクエスタ識別子と同じリクエスタ識別子を持つ他のメモリライトリクエストを処理中の第３要求処理部１５が存在する場合、第２判定部１７は、処理中の第３要求処理部を選択する。一方、処理中の第３要求処理部が存在しない場合、第２判定部１７は、複数の第３要求処理部１５のいずれかを選択する。
【０２２３】
トランザクションパケットの種別がメモリライトリクエスト以外の場合、第２判定部１７は、第４要求処理部１６を選択する。
【０２２４】
第３の実施形態に係るパケット処理装置によれば、あるＩ／Ｏデバイスのリクエストの処理によって、他のＩ／Ｏデバイスのリクエストの処理が阻害されないようにできる。その理由は、第１判定部１３が、ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、ＰＣＩｅパケット発行要求が、第１要求処理部で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定するからである。また、第２選択部１４の第２判定部１７が、トランザクションパケットの種別がメモリライトリクエストである場合、メモリライトリクエストに含まれるリクエスタ識別子に基づいて、メモリライトリクエストが第３要求処理部１５で処理中の他のメモリライトリクエストを追い越しできるか判定するからである。
【０２２５】
上記第１から第３の実施形態におけるパケット処理装置あるいはＰＣＩｅルートコンプレックス等の各構成要素の一部又は全部は、その他の汎用又は専用の回路、プロセッサ等、及び、これらの組み合わせによって実現される。これらは、単一のチップによって構成されてもよいし、バスを介して接続される複数のチップによって構成されてもよい。また、ＦＰＧＡ（Ｆｉｅｌｄ−Ｐｒｏｇｒａｍｍａｂｌｅ  Ｇａｔｅ  Ａｒｒａｙ）のようなプログラマブルロジックデバイスを用いてもよい。
【０２２６】
さらに、パケット処理装置の各構成要素の一部又は全部は、上述した回路等とプログラムとの組み合わせによって実現されてもよい。
【０２２７】
なお、パケット処理装置の各構成要素の一部又は全部が複数の情報処理装置又は回路等により実現される場合には、複数の情報処理装置や回路等は、集中配置されてもよいし、分散配置されてもよい。
【０２２８】
以上、実施形態を参照して本願発明を説明したが、本願発明は上記実施形態に限定されるものではない。本願発明の構成や詳細には、本願発明のスコープ内で当業者が理解し得る様々な変更をすることができる。
【０２２９】
この出願は、２０１６年６月２８日に出願された日本出願特願２０１６−１２７４１１を基礎とする優先権を主張し、その開示の全てをここに取り込む。
【符号の説明】
【０２３０】
１、１Ａ    コンピュータ
２    Ｃｅｎｔｒａｌ  Ｐｒｏｃｅｓｓｉｎｇ  Ｕｎｉｔ（ＣＰＵ）
３    メモリコントローラ
４    メモリ
５、５Ａ    ＰＣＩ  Ｅｘｐｒｅｓｓルートコンプレックス
６    ＰＣＩ  Ｅｘｐｒｅｓｓスイッチ
７    Ｉ／Ｏデバイス
５０    Ｄｏｗｎ方向選択部
５１    Ｄｏｗｎ方向コンプリーション処理部
５２    Ｄｏｗｎ方向低負荷要求処理部
５３    Ｄｏｗｎ方向出力部
５４    Ｕｐ方向選択部
５５    Ｕｐ方向メモリライトリクエスト処理部
５６    Ｕｐ方向低負荷要求処理部
５７    Ｕｐ方向出力部
５８    Ｉ／Ｏデバイステーブル
５９、６６    コンプリーションテーブル
６０    Ｉ／Ｏデバイステーブル設定インタフェース
６１、６３    Ｄｏｗｎ方向Ｉ／Ｏデバイステーブル
６２    Ｕｐ方向Ｉ／Ｏデバイステーブル
５０２    Ｄｏｗｎ方向要求判定部
５０３    Ｄｏｗｎ方向外部テーブル参照部
５０４    Ｄｏｗｎ方向要求発行部
５０５    Ｄｏｗｎ方向要求発行状況管理テーブル
５４２    Ｕｐ方向要求判定部
５４３    Ｕｐ方向外部テーブル参照部
５４４    Ｕｐ方向要求発行部
５４５    Ｕｐ方向要求発行状況管理テーブル
【図１】
2018003629.tif 000003
【図２】
2018003629.tif 000004
【図３】
2018003629.tif 000005
【図４】
2018003629.tif 000006
【図５】
2018003629.tif 000007
【図６】
2018003629.tif 000008
【図７】
2018003629.tif 000009
【図８】
2018003629.tif 000010
【図９】
2018003629.tif 000011
【図１０】
2018003629.tif 000012
【図１１】
2018003629.tif 000013
【図１２】
2018003629.tif 000014
【図１３】
2018003629.tif 000015
【図１４】
2018003629.tif 000016
【図１５】
2018003629.tif 000017
【図１６】
2018003629.tif 000018
【図１７】
2018003629.tif 000019
【図１８】
2018003629.tif 000020
【手続補正書】
【提出日】平成30年12月13日(2018.12.13)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅ（登録商標）ファブリックを構成するパケット処理装置であって、
前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理手段および第２要求処理手段と、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理手段又は前記第２要求処理手段を選択する第１選択手段を備え、
前記第１選択手段は、
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理手段で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する第１判定手段を有する、
パケット処理装置。
【請求項２】
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子と同じトランザクション識別子を持つ他のＰＣＩｅパケット発行要求を処理中の前記第１要求処理手段が存在する場合、
前記第１判定手段は、前記処理中の第１要求処理手段を選択し、
前記処理中の第１要求処理手段が存在しない場合、
前記第１判定手段は、前記複数の第１要求処理手段のいずれかを選択する、
請求項１に記載のパケット処理装置。
【請求項３】
前記ＰＣＩｅパケット発行要求のリクエスト種別がコンプリーション以外の場合、
前記第１判定手段は、前記第２要求処理手段を選択する、
請求項１又は２に記載のパケット処理装置。
【請求項４】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置であって、
前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理手段および第４要求処理手段と、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理手段又は前記第４要求処理手段を選択する第２選択手段を備え、
前記第２選択手段は、
前記トランザクションパケットの種別がメモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理手段で処理中の他のメモリライトリクエストを追い越しできるか判定する第２判定手段を有する、
パケット処理装置。
【請求項５】
前記メモリライトリクエストに含まれるリクエスタ識別子と同じリクエスタ識別子を持つ他のメモリライトリクエストを処理中の前記第３要求処理手段が存在する場合、
前記第２判定手段は、前記処理中の第３要求処理手段を選択し、
前記処理中の第３要求処理手段が存在しない場合、
前記第２判定手段は、前記複数の第３要求処理手段のいずれかを選択する、
請求項４に記載のパケット処理装置。
【請求項６】
前記トランザクションパケットの種別が前記メモリライトリクエスト以外の場合、
前記第２判定手段は、前記第４要求処理手段を選択する、
請求項４又は５に記載のパケット処理装置。
【請求項７】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／ＯデバイスへのＰＣＩｅパケット発行要求を処理する、複数の第１要求処理手段および第２要求処理手段を備え、
前記ＰＣＩｅパケット発行要求のリクエスト種別、及び、前記Ｉ／Ｏデバイスへ送信されるパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第１要求処理手段又は前記第２要求処理手段を選択し、
前記選択の際、
前記ＰＣＩｅパケット発行要求に含まれるトランザクション識別子に基づいて、前記ＰＣＩｅパケット発行要求が、前記第１要求処理手段で処理中の他のＰＣＩｅパケット発行要求を追い越しできるか判定する、
パケット処理装置のパケット処理方法。
【請求項８】
複数のＩ／Ｏデバイスのルートとして接続され、ＰＣＩｅファブリックを構成するパケット処理装置のパケット処理方法であって、
前記パケット処理装置は、前記Ｉ／Ｏデバイスからのトランザクションパケットを処理する、複数の第３要求処理手段および第４要求処理手段を備え、
前記トランザクションパケットの種別、及び、前記Ｉ／Ｏデバイスからの前記トランザクションパケットが前記ＰＣＩｅファブリックに与える負荷に基づいて、前記複数の第３要求処理手段又は前記第４要求処理手段を選択し、
前記選択の際、
前記トランザクションパケットの種別がメモリライトリクエストである場合、前記メモリライトリクエストに含まれるリクエスタ識別子に基づいて、前記メモリライトリクエストが前記第３要求処理手段で処理中の他のメモリライトリクエストを追い越しできるか判定する、
パケット処理装置のパケット処理方法。
【国際調査報告】
2018003629.tif 000021
2018003629.tif 000022