(57)【要約】【課題】受信バッファの利用効率を向上させる。【解決手段】  受信バッファ１２と、データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定すると共に、前記割り当て容量の初期値を前記受信バッファの開放に伴って更新する第１のバッファ制御手段１３と、前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する第２のバッファ制御手段１３とを具備したことを特徴とする。【選択図】      図１
2006189937.tif 000002
【特許請求の範囲】
【請求項１】
受信バッファと、
データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定すると共に、前記割り当て容量の初期値を前記受信バッファの開放に伴って更新する第１のバッファ制御手段と、
前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する第２のバッファ制御手段とを具備したことを特徴とする受信装置。
【請求項２】
前記第２のバッファ制御手段は、前記データタイプ毎のトラフィック統計に基づいて前記割り当て容量の動的な更新を行うことを特徴とする請求項１に記載の受信装置。
【請求項３】
前記第１のバッファ制御手段による前記受信バッファの開放に伴う前記割り当て容量の更新時に、開放された容量よりも小さい容量だけ前記割り当て容量を増加させるか又は割り当て容量を変更しない第３のバッファ制御手段を更に具備したことを特徴とする請求項１に記載の受信装置。
【請求項４】
前記第３のバッファ制御手段は、前記受信バッファに蓄積されないダミーデータを送信側に送信させるための命令を出力することを特徴とする請求項３に記載の受信装置。
【請求項５】
受信側において、
受信バッファと、
データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定すると共に、前記割り当て容量の初期値を前記受信バッファの開放に伴って更新する第１のバッファ制御手段と、
前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する第２のバッファ制御手段と、を具備し、
送信側において、
送信したデータの総データ量の情報を保持する送信量記憶手段と、
受信側の受信バッファにおけるデータタイプ毎の割り当て容量に関する情報が与えられ、前記総データ量及び送信しようとするデータのデータ量との比較によって前記送信しようとするデータの送信の可否を決定する送信制御手段とを具備したことを特徴とする送受信装置。
【請求項６】
前記受信側において、
前記受信バッファに蓄積されないダミーデータを送信側に送信させるための命令を出力すると共に、前記第１のバッファ制御手段による前記受信バッファの開放に伴う前記割り当て容量の更新時に、開放された容量よりも小さい容量だけ前記割り当て容量を増加させるか又は割り当て容量を変更しない第３のバッファ制御手段を更に具備し、
前記送信側において、前記ダミーデータを送信するダミーデータ送信手段を更に具備したことを特徴とする請求項５に記載の送受信装置。
【請求項７】
送信側において、前記第３のバッファ制御手段による前記ダミーデータの送信命令に先立って、データタイプ毎に前記割り当て容量を増加させるための命令を出力する手段を更に具備したことを特徴とする請求項６に記載の送受信装置。
【請求項８】
データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定する手順と、
受信したデータを前記受信バッファのデータタイプ毎に割り当てられた領域に記憶させる手順と、
前記割り当て容量の初期値を前記受信バッファの開放に伴って更新する手順と、
前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する手順とを具備したことを特徴とする受信方法。
【請求項９】
受信側において、データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定する手順と、
送信側において、送信したデータの総データ量の情報と前記割り当て容量の初期値とに基づいて、送信しようとするデータの送信の可否を決定する手順と、
受信側において、前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する手順と、
送信側において、前記割り当て容量の初期値又は更新後の割り当て容量の情報が与えられ、前記総データ量及び送信しようとするデータのデータ量との比較によって前記送信しようとするデータの送信の可否を決定する手順とを具備したことを特徴とする送受信方法。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、高速伝送を可能にする例えばＰＣＩ  Ｅｘｐｒｅｓｓ規格等に好適な受信装置、送受信装置、受信方法及び送受信方法に関する。
【背景技術】
【０００２】
近年、高速なデータ伝送に対応した機器が開発されている。例えば、コンピュータシステムにおいては、ＣＰＵ、メモリ、グラフィックコントローラ、ストレージ機器、周辺機器相互間等のデータ伝送に用いる高速バスとして、ＰＣＩ  Ｅｘｐｒｅｓｓが規格化されている。
【０００３】
一般的には、送受信機相互間では、データ伝送を確実に行うために、フロー制御が実施される。フロー制御は、受信バッファがオーバーフローしないように、送信データのデータ量（伝送速度）を決定するものである。
【０００４】
例えば、特許文献１においては、動的にフロー制御を行う手法が開示されている。特許文献１の手法は、アプリケーション毎にフロー制御を行うものである。即ち、将来的に受信するパケットを各アプリケーションが管理し、優先度が高いアプリケーションプロトコルに受信バッファの割り当てを大きくするように動的な制御を行うものである。
【０００５】
しかしながら、特許文献１の手法では、各アプリケーションにおいてフロー制御をサポートする必要がある。また、パケットタイプ等の種々のデータ種類毎にフロー制御することはできず、バッファを十分に活用していない。
【０００６】
これに対し、ＰＣＩ  Ｅｘｐｒｅｓｓ規格では、非特許文献１に記載されているように、各パケットタイプ毎に受信バッファの割り当てを行うようになっている。ＰＣＩ  Ｅｘｐｒｅｓｓ規格では、送信側において、受信側バッファ（受信パッファ）の各パケットタイプ毎の割り当て容量の情報（クレジット値）と送信したデータ量とを比較する。即ち、先ず、受信側からバッファの容量の情報を送信側に通知することで、送信側のフロー制御の初期化が行われる。送信側は、クレジット値と送信データ量との比較によって、送信の可否を判断するのである。
【特許文献１】特開平１１−３２７９３８号公報
【非特許文献１】PCI Express Base Specification 1.0a, PCI-SIG  2.6. Ordering and Receive Buffer Flow Control, pp.100
【発明の開示】
【発明が解決しようとする課題】
【０００７】
しかしながら、受信バッファの各パケットタイプ毎の割り当てが妥当でないこともある。即ち、比較的伝送するデータ量が大きいパケットタイプに比較的少ない容量が割り当てられ、比較的伝送するデータ量が小さいパケットタイプに比較的大きい容量を割り当てられる場合がある。この場合には、割り当て容量の初期値に従ったフロー制御を実施すると、受信パッファに空きがあるにも拘わらず、データを送信することができなくなることがあり、受信バッファの利用効率が低下してしまうという問題点があった。
【０００８】
本発明はかかる問題点に鑑みてなされたものであって、受信バッファの各データタイプ毎の割り当てを柔軟に変更可能にすることにより、受信バッファの利用効率を向上させて、データ伝送を効率化することができる受信装置、送受信装置、受信方法及び送受信方法を提供することを目的とする。
【課題を解決するための手段】
【０００９】
本発明に係る受信装置は、受信バッファと、データタイプ毎に前記受信バッファにおける割り当て容量の初期値を決定すると共に、前記割り当て容量の初期値を前記受信バッファの開放に伴って更新する第１のバッファ制御手段と、前記割り当て容量の初期値又は更新後の割り当て容量を動的に更新する第２のバッファ制御手段とを具備したことを特徴とする。
【００１０】
本発明において、送信側は例えば受信バッファの割り当て容量の初期値及び送信した総データ量に基づいて、送信の可否を決定する。割り当て容量は、第１のバッファ制御手段によって、受信バッファが開放されることによって更新される。更に、第２のバッファ制御手段は、割り当て容量の初期値又は更新後の割り当て容量を動的に更新する。これにより、初期値の設定が必ずしも適切でない場合でも、受信バッファの利用効率は向上する。
【発明の効果】
【００１１】
本発明によれば、受信バッファの各データタイプ毎の割り当てを柔軟に変更可能にすることにより、受信バッファの利用効率を向上させて、データ伝送を効率化することができるという効果を有する。
【発明を実施するための最良の形態】
【００１２】
以下、図面を参照して本発明の実施の形態について詳細に説明する。図１は本発明の第１の実施の形態に係る送受信装置を示すブロック図である。本実施の形態はＰＣＩ  Ｅｘｐｒｅｓｓ規格に適用させたものであるが、受信側の受信バッファの空き容量に応じて送信側でフロー制御を行う種々のシステムに適用可能である。
【００１３】
送信装置１及び受信装置１１は例えばＰＣＩ  Ｅｘｐｒｅｓｓ規格に対応したものである。送信装置１はＰＣＩ  Ｅｘｐｒｅｓｓ規格のルートコンプレックス（Root Complex）に相当し、受信装置１１はエンドポイント（End Point）に相当する。
【００１４】
なお、図１においては、送信装置１及び受信装置１１のフロー制御に関する構成のみを示しており、他の機能を実現するための構成については図示及び説明を省略する。
【００１５】
ＰＣＩ  Ｅｘｐｒｅｓｓのアーキテクチャは、トランザクション層、データリンク層及び物理層からなる階層構造を有する。送信装置１は階層構造の最上位のトランザクション層のパケット（トランザクションパケット：ＴＬＰ）を送信する。ＴＬＰはＰｏｓｔｅｄ，Ｎｏｎ−ｐｏｓｔｅｄ及びＣｏｍｐｌｅｔｉｏｎの３つのパケットタイプを有している。ＴＬＰはヘッダとデータとが配列されて構成されており、ヘッダ及びデータには夫々これらの３つのパケットタイプが設定される。即ち、ＴＬＰは６種類のデータタイプを有する。
【００１６】
また、ＰＣＩ  Ｅｘｐｒｅｓｓにおいては、仮想チャネル（ＶＣ：Virtual Channel）と呼ばれる独立した複数の仮想通信パスが設定可能である。各仮想チャネルには、独立した受信バッファが設定され、相互に独立したフロー制御が行われる。図１の受信装置１１は１つの仮想チャネルについて示すものであり、受信装置が複数の仮想チャネルを備える場合には、各仮想チャネル毎に図１に示す受信装置１１と同様の構成が設けられる。
【００１７】
送信装置１は各仮想チャネル毎に、６種類のデータタイプのＴＬＰを出力することができる。例えば、仮想チャネル数が８である場合には、送信装置１が出力するデータタイプの種類は４８個となる。
【００１８】
送信装置１からのＴＬＰは受信装置１１において受信される。受信装置１１は受信バッファ１２を有している。受信バッファ１２は、受信したＴＬＰ中のヘッダを格納する領域１２ａ及びＴＬＰ中のデータを格納する領域１２ｂを有する。領域１２ａは、Ｐｏｓｔｅｄタイプのヘッダを格納する領域ＰＨ、Ｎｏｎ−ｐｏｓｔｅｄタイプのヘッダを格納する領域ＮＰＨ及びＣｏｍｐｌｅｔｉｏｎタイプのヘッダを格納する領域ＣｐｌＨを含む。また、領域１２ｂは、Ｐｏｓｔｅｄタイプのデータを格納する領域ＰＤ、Ｎｏｎ−ｐｏｓｔｅｄタイプのデータを格納する領域ＮＰＤ及びＣｏｍｐｌｅｔｉｏｎタイプのデータを格納する領域ＣｐｌＤを含む。
【００１９】
受信装置１１は、データタイプに応じて、受信したデータを受信バッファ１２の各領域に格納するようになっている。受信バッファ１２に格納されたデータは、エンドポイント側のソフトウェアによって順次読出されるようになっている。
【００２０】
第１及び第２のバッファ制御手段としてのバッファ制御回路１３は、受信バッファ１２の各領域ＰＨ，ＮＰＨ，ＣｐｌＨ，ＰＤ，ＮＰＤ，ＣｐｌＤのサイズの割り当てを行う。即ち、バッファ制御回路１３によって、各データタイプ毎の容量の割り当てが行われる。バッファ制御回路１３は、各データタイプ毎に割り当てた容量をフロー制御の初期値として管理する。
【００２１】
バッファ制御回路１３は各データタイプに割り当てた領域の容量をクレジット値の初期値として送信装置１に送信するようになっている。クレジット値の送信には、データリンク層において生成するパケット（データリンクレイヤパケット：ＤＬＬＰ）が用いられる。
【００２２】
また、バッファ制御回路１３は、受信バッファ１２に格納されたデータの読み出しが行われて、受信バッファ１２の領域が開放されると、開放された領域のクレジット値を開放された容量分だけ増加させるアップデート処理を行う。バッファ制御回路１３はアップデートしたクレジット値を送信装置１に送信するようになっている。
【００２３】
送信装置１はＤＬＬＰによって伝送されたクレジット値を受信する。送信装置１の送信量メモリ３には、送信装置１が送信したデータ量の総計（消費したクレジットの合計）が記憶されている。送信制御回路２は受信したクレジット値と送信した総データ量との比較によって、送信の可否を判定する。即ち、送信装置１の送信制御回路２は、受信装置１１に送信すべきデータがある場合には、受信装置１１からのクレジット値と既に送信したデータの総量とを比較し、受信したクレジット値−送信した総データ量（消費したクレジット合計値）が送信すべきデータのデータ量よりも大きい場合に、送信すべきデータを受信装置１１にＴＬＰとして送信するようになっている。クレジット値と消費したクレジット合計値との差分が送信すべきデータのデータ量よりも小さい場合には、送信制御回路２は送信すべきデータを送信しないようになっている。
【００２４】
本実施の形態においては、バッファ制御回路１３は、受信バッファ１２における各データタイプ毎の領域の割り当てを変更することができるようになっている。図１の斜線部は各データタイプに割り当てられた領域の初期値を示している。領域１２ａ内の無地の領域ＰＨは、データタイプＰＨに対して初期状態から増大させた領域を示している。また、領域１２ｂ内の無地の領域ＰＤは、データタイプＰＤに対して初期状態から増大させた領域を示している。
【００２５】
バッファ制御回路１３は、受信したＴＬＰのデータタイプの統計、即ち、トラフィックの統計を求める。バッファ制御回路１３は、求めたトラフィック統計に基づいて、受信バッファ１２の各領域の容量を増大させるか否かの決定及び増大させる量の決定を行うようになっている。
【００２６】
バッファ制御回路１３は、受信バッファ１２の各領域に割り当てる容量を変化させる毎に、増大させた領域の大きさに応じてクレジット値を更新し、更新したクレジット値を送信装置１に送信する。なお、ＤＬＬＰにはフロー制御は適用されず、常時送受信可能である。
【００２７】
次に、このように構成された実施の形態の動作について図２及び図３のフローチャートを参照して説明する。図２は受信装置１１におけるフロー制御を示し、図３は送信装置１におけるフロー制御を示している。
【００２８】
受信装置１１はフロー制御の初期化時において、送信装置１からのデータ伝送に最低限必要な容量を受信バッファ１２に設定する。この場合には、バッファ制御回路１３は、データタイプ毎の伝送量の予測が可能であれば、その予測に従って特定のデータタイプのクレジット値及び受信バッファの確保領域を他のデータタイプのものよりも大きく設定してもよい。バッファ制御回路１３は、設定した初期値のクレジット値をＤＬＬＰによって送信装置１に伝送する（ステップＳ１）。
【００２９】
ここで、送信装置１が所定のＴＬＰを送信するものとする。例えば、受信装置１１がメモリを有するものであって、送信装置１がそのメモリへの書込みのためのＴＬＰを送信するものとする。メモリ書込みのＴＬＰはＰｏｓｔｅｄタイプのパケットである。
【００３０】
フロー制御の初期化直後は、受信バッファ１２にはデータが格納されておらず、送信装置１はＴＬＰの送信が可能である。送信装置１がメモリ書込みのＴＬＰを送信すると、Ｐｏｓｔｅｄタイプについての消費したクレジット合計値は送信量だけ増大する。この消費したクレジット合計値が送信量メモリ３に格納される。
【００３１】
一方、送信装置１からのＴＬＰを受信した受信装置１１は、受信したデータ量だけＰｏｓｔｅｄタイプの受信したクレジット合計値を増大させる。なお、受信したクレジット合計値は送信側の消費したクレジット合計値と同じ値である。この受信したクレジット合計値は、受信バッファ１２のオーバーフロー等の監視に用いられる。受信装置１１において受信されたＴＬＰは、受信バッファ１２内のＰｏｓｔｅｄタイプの領域ＰＨ，ＰＤに格納される。
【００３２】
更に、送信装置１がメモリ書込みのためのＴＬＰを送信するものとする。この場合には、送信装置１の送信制御回路２は、受信装置１１から送られたクレジット値と送信量メモリ３に記憶されている消費したクレジット合計値とを比較し（ステップＳ１１）、受信したクレジット値−消費したクレジット合計値が、送信しようとするデータのデータ量よりも大きい場合にはデータの送信を行い、小さい場合にはデータを送信しない（ステップＳ１２）。
【００３３】
いま、（受信したクレジット値−消費したクレジット合計値）＞（送信しようとするデータのデータ量）とすると、送信装置１はこのデータを受信装置１１に送信する（ステップＳ１３）。送信制御回路２は、送信量メモリ３に記憶させている消費したクレジット合計値に送信したデータのデータ量を加算して、新たな消費したクレジット合計値とする（ステップＳ１４）。
【００３４】
一方、受信装置１１は、受信したデータを受信バッファ１２内の対応するデータタイプの格納領域に記憶させる。ここで、エンドポイント側のアプリケーションによって、受信バッファ１２に格納されているデータが読出されるものとする。これにより、受信バッファ１２の対応する領域は開放され、この領域に対応するデータタイプのデータを記憶させることが可能となる。バッファ制御回路１３は、ステップＳ２において受信バッファ１２の記憶領域が開放されたものと判定すると、読出されて空いた容量分だけ、対応するデータタイプのクレジット値をアップデートする。バッファ制御回路１３は、増加させたクレジット値をＤＬＬＰによって送信装置１に通知する（ステップＳ３）。
【００３５】
クレジット値のアップデート及びアップデートされたクレジット値の送信は、受信バッファ１２からデータが読出されて、受信バッファ１２の記憶領域が開放される毎に行われる。これにより、送信装置１は、伝送可能なデータ容量を把握することができる。
【００３６】
ここで、受信装置１１は、特定のデータタイプの割り当て容量を増大させるものとする。例えば、送信装置１からＰｏｓｔｅｄタイプのデータが多く送信される場合には、受信装置１１のバッファ制御回路１３は、例えばＴＬＰのトラフィック統計を参照することで（ステップＳ４）、Ｐｏｓｔｅｄタイプのデータを格納する領域ＰＤの容量を増大させるか否かを決定する（ステップＳ５）。割り当てる領域を増大させた場合には、バッファ制御回路１３は、増大させた分だけクレジット値を更新して、更新したクレジット値を送信装置１に通知する（ステップＳ６）。なお、この通知は、受信バッファ１２の記憶領域の開放に伴うクレジット値のアップデート時と同時に行ってもよい。即ち、この場合には、クレジット初期値に、（開放された記憶領域分のクレジット値＋受信バッファの割り当ての増大分のクレジット値）が加算されたクレジット値が通知される。
【００３７】
これにより、以後、送信装置１はＰｏｓｔｅｄタイプのデータについては、十分なデータ量のデータを受信装置１１に対して送信することが可能となる。同様にして、バッファ制御回路１３は各データタイプ毎に、受信バッファ１２の容量が許す限り、各データタイプに割り当てる領域（クレジット値）を増大させることができる。従って、例えば、各データタイプ毎のクレジット初期値が実際に伝送されるデータタイプ毎のデータ量に対応していない場合でも、各データタイプ毎の割り当てを動的に変更させることによって、受信バッファ１２の利用効率を向上させることができる。
【００３８】
このように本実施の形態においては、受信バッファの各データタイプ毎の容量の割り当てを、動的に変更することができるので、受信バッファの利用効率を向上させ、データ伝送の一層の高速化を図ることができる。
【００３９】
例えば、予め用意する受信バッファの割り当ては各データタイプについて少ない割り当て容量に抑え、実際にＴＬＰとして流れるトラフィックの統計から新たに受信バッファの確保を行い、動的に受信バッファを変化させる。これにより、受信バッファの利用効率の向上を図り、スループットの向上に貢献することができる。なお、本実施の形態は、ＰＣＩ Ｅｘｐｒｅｓｓ規格の範囲内で実現することが可能である。。
【００４０】
また、上記実施の形態においては、送信装置１はＰＣＩ  Ｅｘｐｒｅｓｓ規格のルートコンプレックスに相当し、受信装置１１はエンドポイントに相当するものとして説明したが、実際のルートコンプレックス及びエンドポイントは、相互に送信及び受信が可能であり、いずれも送信装置１及び受信装置１１と同様の構成を有する。
【００４１】
図４は本発明の第２の実施の形態を示すブロック図である。図４において図１と同一の構成要素には同一符号を付して説明を省略する。第１の実施の形態においては、各データタイプ毎に受信バッファの割り当て容量を増大させるものであった。これに対し、各データタイプ毎の受信バッファの割り当て容量を減少させることを可能にしたものである。
【００４２】
本実施の形態においては、バッファ制御回路１３に代えて第１乃至第３のバッファ制御手段としてのバッファ制御回路２３を有する受信装置２１を採用した点が第１の実施の形態と異なる。
【００４３】
ＰＣＩ  Ｅｘｐｒｅｓｓ規格においては、仕様上、一旦設定したクレジット初期値の値を減少させることはできない。そこで、本実施の形態においては、受信バッファ１２の記憶領域が開放された場合にクレジット値をアップデートしないことによって、等価的、開放された領域に対応するデータタイプの割り当て容量を減少させるものである。
【００４４】
即ち、バッファ制御回路２３は、割り当て容量を減らす対象のデータタイプについては、受信バッファ１２に格納されているデータが読出されて、受信バッファ１２の対応する領域が開放された場合でも、クレジット値をアップデートしない。あるいは、バッファ制御回路２３は、割り当て容量を減らす対象のデータタイプについて、受信バッファ１２の対応する領域が開放された場合には、開放された容量に拘わらず、開放された記憶領域分のクレジット値として０を設定するか又は開放された容量よりも小さい容量を設定するようになっている。
【００４５】
なお、受信バッファの割り当て容量を増加させる場合の処理は、第１の実施の形態と同様である。
【００４６】
他の構成は第１の実施の形態と同様である。
【００４７】
次に、このように構成された実施の形態の動作について図５のフローチャートを参照して説明する。図５において図２と同一の手順には同一符号を付して説明を省略する。
【００４８】
いま、図５のステップＳ２において、受信バッファ１２の記憶領域から読み出しが行われて、受信バッファ１２の記憶領域が読出された分だけ開放されるものとする。バッファ制御回路２３は、次のステップＳ１１において、開放された領域がトラフィック統計に基づいて割り当て容量を減少させるデータタイプに対応したものであるか否かを判定する。割り当て容量を減少させない場合には、次のステップＳ１２において、バッファ制御回路２３は開放された記憶領域分のクレジット値を加算して、クレジット値をアップデートする。このアップデートされたクレジット値は、送信装置１に送信される。
【００４９】
これにより、この場合には、開放された領域に対応するデータタイプのデータについて、送信装置１の送信可能なデータ量が増大する。
【００５０】
一方、開放された領域が割り当て容量を減少させるデータタイプに対応したものである場合には、ステップＳ１３において、バッファ制御回路２３は、開放された記憶領域分よりも小さいクレジット値を加算してクレジット値をアップデートするか、又は記憶領域が開放されていないものとしてクレジット値をアップデートしない。
【００５１】
これにより、この場合には、開放された領域に対応するデータタイプのデータであっても、送信可能なデータ量は変化しない。また、領域が開放されていることから、第１の実施の形態と同様のバッファ制御を行うことで、開放された領域を他のデータタイプの領域に割り当てることができ、受信バッファ１２を一層効果的に利用することが可能となる。
【００５２】
図４の例では、斜線部は各データタイプに割り当てられた領域の初期値を示している。領域１２ａ内の破線の領域ＰＨは、データタイプＰＨに対して初期状態又は直前の状態から減少させた領域を示している。また、領域１２ｂ内の破線の領域ＰＤは、データタイプＰＤに対して初期状態又は直前の状態から減少させた領域を示している。更に、図４の領域１２ａ，１２ｂ内の網線領域は、データタイプＣｐｌＨ，ＣｐｌＤに対して初期状態又は直前の状態から増加させた領域を示している
図６は本発明の第３の実施の形態を示すブロック図である。図６において図４と同一の構成要素には同一符号を付して説明を省略する。第２の実施の形態においては、受信バッファの開放時に、クレジット値をアップデートしないことによって、等価的に割り当て容量を減少させた。しかしながら、第２の実施の形態においては、一旦受信側において受信して受信バッファに格納されたデータについてのみ割り当て容量を減少させることが可能である。しかしながら、受信バッファの割り当て容量を減らす必要があるデータタイプのデータが、送信装置１からＴＬＰとして送信される可能性は低く、受信バッファの割り当て容量を減らすことができるチャンスは多くない。そこで、本実施の形態においては、能動的に受信バッファの割り当て容量を減少させることを可能にするものである。
【００５３】
本実施の形態においては、バッファ制御回路２３に代えてバッファ制御回路３３を有する受信装置３１を採用した点が第２の実施の形態と異なる。
【００５４】
ＰＣＩ  Ｅｘｐｒｅｓｓ規格においては、コンポーネントに影響を与えないＴＬＰ（以下、ダミーＴＬＰという）を送信可能である。送信装置１は、このようなダミーＴＬＰを受信装置３１に対して送信することができる。受信装置３１は、ダミーＴＬＰを受信しても、受信バッファ１２に受信されたダミーＴＬＰを記憶させない。
【００５５】
即ち、受信装置３１のバッファ制御回路３３は、ダミーＴＬＰが記憶されるべき受信バッファ１２の領域が実際には開放状態であっても、対応するデータタイプのクレジット値を増加させることはない。即ち、ダミーＴＬＰを送信した送信装置１においては、ダミーＴＬＰと同一のデータタイプについては、送信可能なデータ量が、ダミーＴＬＰの容量分だけ低減されることになる。
【００５６】
本実施の形態においては、送信装置１からダミーＴＬＰを出力させるために、受信装置３１のバッファ制御回路３３は、受信バッファの割り当て容量を削減する対象のデータタイプに対応するダミーＴＬＰを送信装置１から強制的に送信させるための命令を、送信装置１に対して送信するようになっている。
【００５７】
このような命令としては、例えば、Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰがある。このＤＬＬＰには、割り当て容量を減少させるべきデータタイプ、ヘッダ/データ、ＶＣ、および削減量の情報を格納する。一方、送信装置１は、受信装置３１からのＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰの情報を基に、受信バッファの割り当て容量削減対象のデータタイプのＴＬＰを受信装置３１に送信する。
【００５８】
なお、受信バッファの割り当て容量を増加させる場合の処理は、第１の実施の形態と同様である。
【００５９】
次に、このように構成された実施の形態の動作について図７のフローチャートを参照して説明する。図７において図５と同一の手順には同一符号を付して説明を省略する。
【００６０】
いま、図７のステップＳ１１において、バッファ制御回路３３は、トラフィック統計に基づいて割り当て容量を減少させるデータタイプがあるか否かを判定する。割り当て容量を減少させるデータタイプがある場合には、ステップＳ２３において、バッファ制御回路３３は、Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを用いて、削減対象のデータタイプのダミーパケットを送信させる命令を送信装置１に出力する。この命令には、割り当て容量の削減量の情報も含まれる。
【００６１】
送信装置１はこのＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを受信すると、対応するデータタイプのダミーＴＬＰを送信する（ステップＳ２４）。これにより、ダミーＴＬＰのデータタイプについては、送信量メモリ３に記憶される消費したクレジット合計値がダミーＴＬＰのデータ量だけ増加する。
【００６２】
一方、ダミーＴＬＰを受信すると、受信装置３１のバッファ制御回路３３は、ダミーＴＬＰのデータタイプについては、クレジット値のアップデートを行わない（ステップＳ２５）。即ち、送信装置１においては、消費したクレジット合計値はダミーＴＬＰのデータ量だけ増加するのに対し、クレジット値は受信バッファ１２が開放されているにも拘わらず変化しない。従って、等価的に、ダミーＴＬＰと同一のデータタイプのデータについては、送信装置１から送信可能なデータ量が低減されることなる。
【００６３】
なお、バッファ制御回路３３が、ダミーＴＬＰのデータ量よりも少ない容量だけクレジット値に加算して、アップデートしたクレジット値を送信するようにしてもよい。この場合でも、ダミーＴＬＰと同一のデータタイプのデータについては、送信装置１から送信可能なデータ量が低減されることなる。
【００６４】
また、領域が開放されていることから、第１の実施の形態と同様のバッファ制御を行うことで、開放された領域を他のデータタイプの領域に割り当てることができ、受信バッファ１２を一層効果的に利用することが可能となる。
【００６５】
図６の例では、斜線部は各データタイプに割り当てられた領域の初期値を示している。領域１２ａ内の破線の領域ＰＨは、データタイプＰＨに対して初期状態又は直前の状態から減少させた領域を示している。また、領域１２ｂ内の破線の領域ＰＤは、データタイプＰＤに対して初期状態又は直前の状態から減少させた領域を示している。更に、図６の領域１２ａ，１２ｂ内の網線領域は、データタイプＣｐｌＨ，ＣｐｌＤに対して初期状態又は直前の状態から増加させた領域を示している
ところで、ダミーＴＬＰとしては、コンポーネントに影響を及ぼすようなＴＬＰであってはならないため、例えば、Ｐｏｓｔｅｄクレジットの場合にはＶｅｎｄｏｒ Ｄｅｆｉｎｅｄ Ｍｅｓｓａｇｅを用いることが望ましい。また、Ｎｏｎ-Ｐｏｓｔｅｄクレジットの場合には影響の無いアドレス領域に対するＭｅｍｏｒｙ Ｒｅａｄ Ｒｅｑｕｅｓｔ等を用いることが望ましい。
【００６６】
図６の例では、Ｐｏｓｔｅｄタイプのデータを格納する領域ＰＤの割り当てを減らすために、送信装置１はデータ付きのＶｅｎｄｏｒ Ｄｅｆｉｎｅｄ Ｍｅｓｓａｇｅを送信している。
【００６７】
また、ＰＣＩ  Ｅｘｐｒｅｓｓ規格においては、Ｃｏｍｐｌｅｔｉｏｎクレジットの場合には、リクエスト（Request）無しのＣｏｍｐｌｅｔｉｏｎタイプのデータは許可されていない。そこでこの場合には、受信装置３１から特定のＮｏｎ-Ｐｏｓｔｅｄタイプのリクエストを発行させ、送信装置１からのＣｏｍｐｌｅｔｉｏｎを生成することで、能動的な割り当て容量の削減を実現する。また、ダミーで送信するＮｏｎ-Ｐｏｓｔｅｄタイプのリクエストのような、特定のＴＬＰが送信される場合には、通常のトラフィックを流れるＴＬＰとは区別し、ＴＬＰのトラフィック統計の考慮外にした方が望ましい。
【００６８】
ところで、上記各実施の形態においては、各データタイプ毎の受信バッファの割り当て容量の増減は、伝送されるＴＬＰのトラフィック統計に基づいて行った。図８乃至図１０はこのようなトラフィック統計に基づく受信バッファの割り当て容量の増減方法を説明するための図表である。
【００６９】
トラフィック統計は、受信装置において受信履歴をとることで算出可能である。図８は受信装置においてＦＩＦＯメモリを用いて、記録したトラフィック統計の一例を示している。図８の例では、ＦＩＦＯメモリはアドレス（Ａｄｄｒｅｓｓ）０〜Ｆまでの１６の領域を有し、各領域には、仮想チャネル（ＶＣ）、データタイプ（Ｔｙｐｅ）及びデータ量（Ｄａｔａ）の情報を含む。
【００７０】
図９はＦＩＦＯメモリに図８の情報が保持されているタイミングにおいて、受信バッファ１２の領域１２ａに書込まれるヘッダのデータ量を示している。図８では各仮想チャネル（ＶＣ）毎に、データタイプ（Ｔｙｐｅ）及び容量比を示している。ＰＣＩ  Ｅｘｐｒｅｓｓでは、１ＴＬＰ内に１つのヘッダと１つ以上のデータとを含む。従って、ヘッダについては、容量比はＦＩＦＯメモリに保持されている各データタイプのデータ数に一致する。
【００７１】
図１０はＦＩＦＯメモリに図８の情報が保持されているタイミングにおいて、受信バッファ１２の領域１２ｂに書込まれるデータのデータ量を示している。図１０においても各仮想チャネル（ＶＣ）毎に、データタイプ（Ｔｙｐｅ）及び容量比を示している。データについては、容量比はＦＩＦＯメモリに保持されている各データタイプのデータ量の和である。
【００７２】
受信装置中のバッファ制御回路は、図９及び図１０の結果に基づいて、各データタイプ毎の受信バッファ１２の割り当て容量の増減を決定する。例えば、バッファ制御回路は、図９及び図１０の容量比に比例した容量の割り当てを行う。例えば、図１０に示す結果から、仮想チャネル（０）については、Ｐｏｓｔｅｄタイプのデータを格納する領域ＰＤとＣｏｍｐｌｅｔｉｏｎタイプのデータを格納する領域ＣｐｌＤとの割り当て容量を、１４：１９の割り合いで割り当てる。
【００７３】
なお、バッファ制御回路は、必ずしも容量比に比例した容量の割り当てを行う必要はない。バッファ制御回路は、求めた受信バッファ容量比を基に、現状のバッファ割り当てと比較し、実際のバッファ割り当ての増減を行えばよい。
【００７４】
なお、ＴＬＰの受信バッファの管理を行うのは受信装置であるので、受信装置において受信されるＴＬＰについての統計を取るのが効率的である。
【００７５】
このように、上記各実施の形態においては、実際のＴＬＰのトラフィックの傾向に応じて各データタイプ毎の受信バッファの割り当て容量を更新しているので、受信バッファの利用効率を向上させ、スループットを大きくすることができる。
【００７６】
図１１は本発明の第４の実施の形態を示すブロック図である。図１１において図６と同一の構成要素には同一符号を付して説明を省略する。第３の実施の形態においては、送信装置１からコンポーネントに影響を与えないダミーＴＬＰを送信可能とさせることによって、各データタイプ毎の受信バッファ１２の割り当て容量の増減を能動的に実施することを可能にした。しかしながら、このような受信バッファの割り当て容量の更新を行う場合であっても、急激にバーストアクセスが発生したときには、割り当て容量が不足して（クレジットが不足して）、ＴＬＰの送信が停止する可能性も考えられる。
【００７７】
そこで、本実施の形態においては、送信装置１から受信装置に対して、クレジット値の影響を受けない命令、例えばＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰ等を用いて、受信バッファの割り当て容量を強制的に変更させるようになっている。
【００７８】
本実施の形態は送信装置１及び受信装置１１に夫々代えて送信装置４１及び受信装置５１を採用した点が図６と異なる。送信装置４１の送信制御回路４２は受信バッファの割り当て容量を増加させるために、例えば、Ｖｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを受信装置５１に送信することができる。受信装置５１のバッファ制御回路５２は、このＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを受信すると、受信バッファ１２中の対応するデータタイプの格納領域を優先的に確保する。そして、この容量の割り当てに応じて更新したクレジット値を送信装置４１に通知するようになっている。
【００７９】
なお、受信バッファ１２の割り当て容量をトラフィック統計に基づいて増加させる通常の処理及び受信バッファ１２の割り当て容量を減少させる処理は、第３の実施の形態と同様である。
【００８０】
次に、このように構成された実施の形態の動作について図１２のフローチャートを参照して説明する。図１２において図７と同一の手順には同一符号を付して説明を省略する。
【００８１】
いま、送信装置４１がＣｏｍｐｌｅｔｉｏｎタイプのデータのＴＬＰをクレジット不足で送信することができないものとする。この場合には、図１２のステップＳ３０から処理をステップＳ３１に移行して、送信装置４１の送信制御回路４２は、受信バッファ確保要求のためにＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを受信装置５１に送信する。
【００８２】
受信装置５１のバッファ制御回路５２は、受信した受信バッファ確保要求に応じて、優先的にＣｏｍｐｌｅｔｉｏｎタイプのデータを格納する領域ＣｐｌＤの割り当て容量を大きくする。また、同時に、バッファ制御回路５２は、現在使用頻度が小さいＰｏｓｔｅｄタイプのデータを格納する領域を領域ＣｐｌＤに割り当て変更するために、Ｐｏｓｔｅｄタイプのデータ格納領域についてのバッファ削減要求のＶｅｎｄｏｒ Ｓｐｅｃｉｆｉｃ ＤＬＬＰを送信装置４１に送信する（ステップＳ３２）。
【００８３】
図１２は、受信バッファ確保要求に応じた領域を受信バッファ１２中に確保することができない場合の例を示しており、この場合には、領域の確保に先だって、バッファ削減を実施する。
【００８４】
送信装置４１は、バッファ削減要求に応じて、ダミーのＰｏｓｔｅｄメッセージである、Ｖｅｎｄｏｒ Ｄｅｆｉｎｅｄ Ｍｅｓｓａｇｅを受信装置５１に送信する（ステップＳ３４）。これにより、受信装置５１のバッファ制御回路５２は、Ｐｏｓｔｅｄタイプのデータの格納領域を削減する（ステップＳ２５）。
【００８５】
このように、本実施の形態においては、クレジット不足のデータタイプの受信バッファの割り当てを送信装置側から強制的に増加させることができ、特定のＴＬＰが送信できない問題を回避することができる。これにより、ＴＬＰのトランザクションレイテンシを短縮し、効率的な転送を実現することができる。
【００８６】
図１３は上記各実施の形態における送信装置及び受信装置をコンピュータに組み込んだ場合の外観を示す説明図である。
【００８７】
メイン基板６１上には上記各実施の形態の送信装置に対応するルートコンプレックス（ＲＣ）６２がＩＣチップ化されて搭載されている。ＲＣ６２の近傍には、ＩＣ化されたプロセッサ６３、メモリコントローラ６４、I/Oコントローラ６５等がパラレル及びシリアルのバス等６６によって接続されている。
【００８８】
ＲＣ６２のポート（図示省略）は、伝送路６８を介してスロット６７に接続される。スロット６７には、エンドポイントデバイス７１が接続されている。エンドポイントデバイス７１上には、上記各実施の形態の受信装置に対応するエンドポイント（ＥＰ）７２が搭載される。例えば、エンドポイントデバイス７１がグラフィックデバイスの場合には、ＥＰ７２の他に、更にグラフィックコントローラ７３及びグラフィックメモリ７４等も搭載される。プロセッサ６３とグラフィックコントローラ７３とのデータ伝送は、ＲＣ６２及びＥＰ７２によって、高速且つ効率的に行われる。
【００８９】
図１４は上記各実施の形態における送信装置及び受信装置の階層構造をＰＣＩ  Ｅｘｐｒｅｓｓの階層構造に対応させて示す説明図である。
【００９０】
本実施の形態においては、ＰＣＩ Ｅｘｐｒｅｓｓの階層構造と同様に、メカニカル層、物理層の下位レイヤから、アプリケーションとのインタフェースまでの上位レイヤまでの階層構造を採用している。一般的なシステムの実装と同じように、上位レイヤの実装においてはソフトウェア、下位レイヤの実装においてはハードウェアを用いることが多いが、本実施の形態においても、図１４（ａ）に示すように、アプリケーションインタフェースまでの大部分をハードウェアで実装することができる。
【００９１】
更に、図１４（ｂ）に示すように、物理層の下位レイヤまでのみをハードウェア実装し、パケット/プロトコル関連層は全てソフトウェア実装を利用することも考えられる。  本発明は、トランザクション層の前後のレイヤに関し、主にトランザクション層のバッファ管理に関するものである。図１４（ａ）の例では、上記各実施の形態におけるバッファ管理は、ハードウェア実装されることになり、図１４（ｂ）の例では、上記各実施の形態におけるバッファ管理は、ソフトウェア実装されることになる。即ち、上記各実施の形態は、ハードウェア・ソフトウェアのいずれの実装方法も可能である。
【図面の簡単な説明】
【００９２】
【図１】本発明の第１の実施の形態に係る送受信装置を示すブロック図。
【図２】受信装置１１におけるフロー制御を示すフローチャート。
【図３】送信装置１におけるフロー制御を示すフローチャート。
【図４】本発明の第２の実施の形態を示すブロック図。
【図５】第２の実施の形態の動作を説明するためのフローチャート。
【図６】本発明の第３の実施の形態を示すブロック図。
【図７】第３の実施の形態の動作を説明するためのフローチャート。
【図８】トラフィック統計に基づく受信バッファの割り当て容量の増減方法を説明するための図表。
【図９】トラフィック統計に基づく受信バッファの割り当て容量の増減方法を説明するための図表。
【図１０】トラフィック統計に基づく受信バッファの割り当て容量の増減方法を説明するための図表。
【図１１】本発明の第４の実施の形態を示すブロック図。
【図１２】第４の実施の形態の動作を説明するためのフローチャート。
【図１３】各実施の形態における送信装置及び受信装置をコンピュータに組み込んだ場合の外観を示す説明図。
【図１４】各実施の形態における送信装置及び受信装置の階層構造をＰＣＩ  Ｅｘｐｒｅｓｓの階層構造に対応させて示す説明図。
【符号の説明】
【００９３】
１…送信装置、２…送信制御回路、３…送信量メモリ、１１…受信装置、１２…受信バッファ、１３…バッファ制御回路。  
代理人      弁理士      伊  藤    進
【図１】
2006189937.tif 000003
【図２】
2006189937.tif 000004
【図３】
2006189937.tif 000005
【図４】
2006189937.tif 000006
【図５】
2006189937.tif 000007
【図６】
2006189937.tif 000008
【図７】
2006189937.tif 000009
【図８】
2006189937.tif 000010
【図９】
2006189937.tif 000011
【図１０】
2006189937.tif 000012
【図１１】
2006189937.tif 000013
【図１２】
2006189937.tif 000014
【図１３】
2006189937.tif 000015
【図１４】
2006189937.tif 000016