JP7567569B2 - 情報処理装置及び情報処理装置の制御方法 - Google Patents

Description

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

２者間で通信を行う場合、データの受信側の装置は受信バッファを用意し、送信側の装置は受信側の装置の受信バッファがオーバーフローしないようにフロー制御を行うことが一般的である。フローは、送信側の装置から受信側の装置への一連のデータパケットの流れを指す。

フロー制御の１つとして、ハードウェアによるクレジット方式がある。ハードウェアによるクレジット方式では、受信バッファ上の受信データが受信バッファから読み出されたときに、受信バッファが読み出された分空いたとして、受信側の装置が送信側の装置に読出し量を通知する。これにより、送信側の装置は、受信側の装置の受信バッファの空き状況を判断できる。送信側の装置は、送信量から通知された読出し量を減算した値が受信バッファサイズ以下であれば、受信側の装置の受信バッファに空きがあると判定できる。

一定の通信スループット性能を確保したい場合、基本的には、受信側の装置の受信バッファには、受信バッファサイズ＝受信バッファの読出し通知レイテンシ×目標スループットといった式で決定されるバッファサイズ以上のバッファサイズが予め設定される。これにより、送信側の装置が確保したいスループットで送信を続けても受信バッファが溢れない。ここで、受信バッファの読出し通知レイテンシとは、送信側の装置が送信したパケットが受信側の装置の受信バッファから読み出され、読み出されたことが送信側の装置に通知されるまでの時間である。

ただし、通信に使用可能な資源が限られている場合、必ずしも目的とする最大スループット性能に対して、常に十分な受信バッファサイズが確保できるとは限らない。例えば、送信元が複数存在する場合、受信側の装置は、送信元毎に受信バッファを有する。そのような場合に、送信元が多くなれば多くなるほど、受信側の装置がそれぞれの送信側の装置に対して十分な受信バッファを確保することが困難となる。そこで、通信負荷に応じて受信バッファサイズを動的に変える技術が提案されている。

通信負荷に応じて受信バッファのサイズを動的に変える技術として、例えば以下のようなものがある。通信開始時に予め受信側が決めた初期バッファサイズ、もしくは送信側から要求された受信バッファのサイズを受信側が確保する。この時、初期バッファサイズを受信側の装置が決定した場合は、送信側に確保したバッファサイズを通知する。その後、通信データ量が増加し、バッファが足りなくなった場合、もしくは足りなくなりそうな場合、受信側の装置の判断又は送信側の要求により、受信バッファのサイズが増加可能な場合はバッファサイズを増加させる。また、通信データが減少した場合、バッファサイズを減少させる。受信バッファのサイズを変更した場合、受信側の装置は、受信バッファのサイズの変更を送信側の装置に通知する。これにより、例えば、複数の送信側の装置と通信する受信側の装置は、通信量の多い相手用の受信バッファのサイズを大きくして、その他は受信バッファサイズを小さくするなど、トータルの資源を制限しながらスループット性能を確保することができる。

なお、受信側の装置が複数の送信側の装置と通信を行う技術として、送信側の装置が共有する受信器セルバッファを用いて送信側の装置の全体のフロー制御を行う技術がある。また、受信側ノードが複数の送信側ノードの各々に対する共有の通信バッファの割り当てを同報通信で各送信側ノードに通知して、送信側の装置は割り当てられた通信バッファを使用して通信を行う技術がある。

特表平１１－５１１３０３号公報 国際公開第２０１１／５８６４０号

例えば、コンピュータのメインメモリ上に受信バッファを確保して使用するような通信の場合、メインメモリは、十分に存在するためバッファサイズを要求に応じて増やすことは可能である。しかしながら、ＰＣＩｅ（Peripheral Component Interconnect Express）（登録商標）バスによる通信や同一チップ内のハード実装による通信では、チップ上に実装されたＳＲＡＭなどがバッファとして使用される。そのため、ＣＰＵやメモリコントローラなどともにＰＣＩｅコントローラが実装されるような高機能なＳｏＣ（System on a Chip）では、実装面積に限りがあり、十分な量のバッファを実装することが困難である。

そのようなケースで、１つの受信モジュールに対して複数の送信モジュールがデータを送信する場合、限られたサイズの受信バッファにおいてある送信モジュールへの割当量を増やすと、他の送信モジュールへの割当量を減らすことになり、際限無く割当量を増やすことは認められない。

例えば、１つの受信モジュールに対して第１送信モジュールと第２送信モジュールの２つがあり、初期状態では受信モジュールが有するトータルのバッファサイズの半分を、各送信モジュールに割り当てた場合を考える。第１送信モジュールが、受信モジュールにデータを送信しているときに、ある時点で第１送信モジュールに割り当てられた受信バッファが溢れると判定し、スループット性能を確保するために、受信バッファ割り当ての増加を受信モジュールに要求する。受信モジュールは、要求を受けて第２送信モジュールに割り当てた受信バッファの一部を第１送信モジュールに割り当て直す。この時、第２送信モジュールに割り当てていた受信バッファが空いていたとしても、第２送信モジュールがいつデータを送信してくるか分からないため、受信モジュールは、第２送信モジュールに受信バッファ割り当ての減少要求を送る。そして、第２送信モジュールから受信バッファの減少の許可を受けて初めて、受信モジュールは、第１送信モジュールに受信バッファの割り当ての増加を通知することができる。

この場合、受信バッファの割り当てサイズを変更するまでに、数なくとも受信モジュールと送信モジュールとの間の２往復分の通信時間がかかる。この遅延時間の間、第１送信モジュールは受信モジュールに目標スループットでデータを送り続けることが困難となり、スループットが目標性能に達するまでに遅延が生じる。また、スループットの立ち上がり遅延を許容したとしても、例えば第１送信モジュールと第２送信モジュールとが交互にある程度の量のデータを送信するようなケースなどでは、それぞれに対する受信バッファの割り当てが追い付かずに無駄な調整となるおそれがある。

また、送信側の装置が共有する受信器セルバッファを用いる技術や、受信側ノードが複数の送信側ノードの各々に対する共有の通信バッファの割り当てを同報通信で通知する技術を用いても、受信バッファの割り当てサイズの変更手順を短縮することは困難である。そのため、これらの従来技術を用いてもスループット性能を確保することは難しい。

開示の技術は、上記に鑑みてなされたものであって、スループット性能を確保する情報処理装置及び情報処理装置の制御方法を提供することを目的とする。

本願の開示する情報処理装置及び情報処理装置の制御方法の一つの態様において、情報処理装置は、受信モジュール、並びに、前記受信モジュールに対してパケットを送信する第１送信モジュール及び第２送信モジュールを有する。前記受信モジュールは、前記第１送信モジュールと前記第２送信モジュールとにより共有される、前記パケットを格納する受信バッファを有する。前記第１送信モジュールは、前記第１送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記第２送信モジュールに割り当てられた前記受信バッファの貸出依頼を前記第２送信モジュールに送信する貸出依頼判定部と、前記第２送信モジュールが前記貸出依頼に対して受諾応答を送信した場合、前記第１送信モジュールに対する前記受信バッファの割り当て量を増加させる第１空きバッファ計算部とを有する。前記第２送信モジュールは、前記貸出依頼を受信して、前記第２送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記受諾応答を前記第１送信モジュールへ送信する貸出依頼応答部と、前記貸出依頼応答部が前記受諾応答を送信した場合、前記第２送信モジュールに対する前記受信バッファの割り当て量を減少させる第２空きバッファ計算部とを有する。

１つの側面では、本発明は、スループット性能を確保することができる。

図１は、実施例１に係る情報処理装置の構成図である。 図２は、データパケットの送受信を行うルートポートのブロック図である。 図３は、実施例１に係る情報処理装置による空きバッファ管理処理のフローチャートである。 図４は、実施例３に係る情報処理装置の構成図である。 図５は、実施例４に係る情報処理装置の構成図である。

以下に、本願の開示する情報処理装置及び情報処理装置の制御方法の実施例を図面に基づいて詳細に説明する。なお、以下の実施例により本願の開示する情報処理装置及び情報処理装置の制御方法が限定されるものではない。

図１は、実施例１に係る情報処理装置の構成図である。本実施例に係る情報処理装置１は、図１に示すように、ＳｏＣ１００及びエンドポイント２０１～２０４を有する。

エンドポイント２０１～２０４は、ＰＣＩｅにおけるＩ／Ｏ（Input/Output）デバイスである。エンドポイント２０１～２０４は、例えば、ＧＰＵ（Graphics Processing Unit）や、ネットワークインタフェースや、ハードディスクなどである。

ＳｏＣ１００には、図示しないＣＰＵ及びメインメモリとともに、ＰＣＩｅの複数のルートポート１０１～１０４が搭載される。ルートポート１０１～１０４は、エンドポイント２０１～２０４に接続される。ルートポート１０１～１０４は、ＳｏＣ１００の外部のＰＣＩｅデバイスと、ＳｏＣ１００とを連携させるためのポートである。

ＰＩＣｅでは、ピアツーピア（Peer-to-Peer）と呼ばれる各ルートポート１０１～１０４に接続されたエンドポイント２０１～２０４同士が直接通信をする方式が定義されている。エンドポイント２０１～２０４のうち通信する２つが異なるルートポート１０１～１０４のいずれかに接続される場合の通信手順について、エンドポイント２０１が送信元でエンドポイント２０３が送信先である場合を例に説明する。送信元のエンドポイント２０１は、接続されたルートポート１０１にパケットを送信する。パケットを受信したルートポート１０１は、送信先のエンドポイント２０３に接続されたルートポート１０３にパケットを送信する。ルートポート１０３は、送信先のエンドポイント２０３へパケットを転送する。各エンドポイント２０１～２０４とそれぞれに接続されたルートポート１０１～１０４とは、ＰＣＩｅで定められた方式により通信する。各ルートポート１０１～１０４間の通信については、ＰＣＩｅでは明確には定義されていない。

本実施例では、ルートポート１０１～１０４は、エンドポイント２０１～２０４にＰＣＩｅの３２Ｇｂｐｓスピード、１６レーンで接続される。また、ＳｏＣ１の内部では、ルートポート１０１～１０４は、それぞれリングバス１０５によって相互通信が行えるように接続される。リングバス１０５の上には、リングストップ（ＲＳ：Ring Stop）１５０及び１５１～１５４が、ＳｏＣ１の内部で通信するユニットごとに配置される。ルートポート１０１～１０４は、それぞれの図１において最も近い位置に配置されたリングストップ１５１～１５４をリングバス１０５による通信の接続点とする。また、他のリングストップ１５０は、図示しないが、ＣＰＵコアやメモリコントローラなどの他のユニットに対応するように配置され、それぞれが対応するユニットのリングバス１０５による通信の接続点となる。以下の説明では、リングストップ１５０及び１５１～１５４を区別しない場合、まとめて「リングストップ１５０」と呼ぶ。

例えば、ルートポート１０１がルートポート１０３にパケットを送信する場合、ルートポート１０１は、リングストップ１５１からパケットを送信する。リングストップ１５１から送信されたパケットは、リングバス１０５上の各リングストップ１５０を経由して、リングストップ１５３まで運ばれる。ルートポート１０３は、リングストップ１５３に届いたパケットが自己宛てであれば、そのパケットを受信する。

ここで、パケットが通過するリングストップ１５０が多いほど、そのパケットが目的地に到達するまでの時間がかかる。本実施例では、簡単のためリングストップ１５０を用いた通信は、各ユニット間のリングストップ１５０の個数に比例し、あるリングストップ１５０から隣のリングストップ１５０までに３２ｎｓｅｃかかるものとして説明する。例えば、ルートポート１０１からルートポート１０３にパケットが届くまでには、１２８ｎｓｅｃかかる。

通常は、ルートポート１０３はエンドポイント２０３にデータパケットの送信を順次続けるが、例えばルートポート１０３とエンドポイント２０３との間のＰＣＩｅの伝送経路品質が少し不安定でパケットが一時的に送信できずに再送することがある。その時、一時的にルートポート１０３はルートポート１０１から受信し続けているデータパケットを順次送信できなくなる。そのため、ルートポート１０３は、ルートポート１０１から受信したデータパケットを受信バッファ１３０に溜めていく。そのような状況が続くと、受信バッファ１３０の空き領域がなくなり溢れて、ルートポート１０３は、データパケットの受信が困難となる。そこで、ルートポート１０１はルートポート１０３の受信バッファ１３０が溢れないように送信を制御する。

ここで、ルートポート１０１からルートポート１０３にデータパケットを送信するときの送信時間であるレイテンシは前述した通り１２８ｓｅｃである。ルートポート１０３からルートポート１０１への送信レイテンシも同様に１２８ｓｅｃである。ルートポート１０１が６４ＧＢ/ｓｅｃでパケットを送信し続けた場合、２５６ｎｓｅｃでルートポート１０３の受信バッファ１３０において６４ＧＢ/ｓｅｃ×２５６ｎｓｅｃ＝１６ｋＢの容量が消費される。ルートポート１０３の受信バッファ１３０を１６ｋＢとすると、ルートポート１０１はここで送信を止める。一方で、ルートポート１０３はエンドポイント２０３との通信が滞りない場合は、ルートポート１０１から受信したパケットをエンドポイント２０３に順次送信するため、受信バッファ１３０はその分すぐに空く。そして、ルートポート１０３は、受信バッファ１３０が空いたことをルートポート１０１に通知する。この場合、ルートポート１０１はデータパケットを送信した後、往復２５６ｎｓｅｃ後に空きを知ることになる。したがって、ルートポート１０１は、受信バッファ１３０の空きを知らなければ２５６ｎｓｅｃ後にデータパケットの送信を停止するが、２５６ｎｓｅｃ後のタイミングで受信バッファ１３０の空きを知るために、追加のパケットが送信可能となる。すなわち、ルートポート１０１は、継続してパケットを６４ＧＢ/ｓｅｃのスループットで送信できる。

なお、実際にはルートポート１０３がパケットを受信してから送信するまでに内部処理時間が消費され、ルートポート１０１に受信バッファ１３０が空いたことを通知された後、送信制御回路にそれを反映するまでの内部遅延時間が消費される。ただし、ここでは、簡単のためそれらの消費時間をないものとして説明する。

ここで、本実施例において受信バッファ１３０のサイズは、例えば、１６ｋＢとして設定される。これは、ルートポート１０１が送信したデータパケットが受信バッファ１３０から読み出されたことすなわち空いたことを知るまでの時間２５６ｎｓｅｃ（片道通信レイテンシ１２８ｎｓｅｃ×２）と目標スループット性能である６４ＧＢ/ｓｅｃとを元に２５６ｎｓｅｃ × ６４ＧＢ/ｓｅｃ ＝ １６ｋＢと計算した値である。

次に、エンドポイント２０２がエンドポイント２０３にデータパケットを送信する場合について説明する。この場合は、ルートポート１０２とルートポート１０３との間の片道の通信レイテンシが１４４ｎｓｅｃであるが、それ以外は前述のエンドポイント２０１からエンドポイント２０３への送信の場合と同じように考えることができる。そこで、ルートポート１０３側が（１４４ｎｓｅｃ×２）×６４ＧＢ/ｓｅｃ＝１８ｋＢの受信バッファ１３０を有する場合、ルートポート１０２は、６４ＧＢ/ｓｅｃのスループット性能を得ることができる。

ただし、ルートポート１０３にデータパケットを送信する送信元の数が増えた場合、ルートポート１０３が、各送信元に対してこのような受信バッファ１３０を持つことは、実装面積の観点から現実的でない。なぜなら、ルートポート１０１とルートポート１０２が同時に６４ＧＢ/ｓｅｃのスループットでルートポート１０３に送信できるとしても、その先のルートポート１０３とエンドポイント２０３との間も６４ＧＢ/ｓｅｃのスループットしか出ないため、ルートポート１０１及びルートポート１０２からの送信のスループットは合計で６４ＧＢ/ｓｅｃを出すことができればよいためである。このことから、ルートポート１０３が、ルートポート１０１とルートポート１０３との間及びルートポート１０２とルートポート１０３との間で個別に６４ＧＢ/ｓｅｃを満たすようなサイズの受信バッファ１３０を別々に有することは効率が悪いといえる。

そこで、本実施例では、ルートポート１０１とルートポート１０２とが、ルートポート１０３にデータパケットを送信する場合に、ルートポート１０１に使用が限定された受信バッファ１３０の領域を４ｋＢとする。また、ルートポート１０２に使用が限定された受信バッファ１３０の領域を６ｋＢとする。そして、ルートポート１０１とルートポート１０２の双方が使える受信バッファ１３０の共用分の領域を１２ｋＢとして、状況に応じて共用分の１２ｋＢをルートポート１０１とルートポート１０２との間で融通し合うことで、ルートポート１０３の受信バッファ１３０のサイズを削減することが可能である。具体的には、初期では、受信バッファ１３０の共用分の領域を半分ずつ、ルートポート１０１及び１０２に割当て、ルートポート１０１用に合計１０ｋＢ、ルートポート１０２用に合計１２ｋＢが設定される。そして、ルートポート１０１とルートポート１０２とで、受信バッファ１３０の共用分の領域に使用量に応じて共用分の領域を融通し合うことで、スループットを確保する。以下に、受信バッファ１３０の共用分の領域に使用量に応じて共用分の領域を融通の処理について詳細に説明する。

図２は、データパケットの送受信を行うルートポートのブロック図である。図２では、ルートポート１０１～１０４におけるパケットを送信する側を送信モジュール１０とし、パケットを受信する側を受信モジュール２０として表した。ルートポート１０１～１０４は、パケットの送受信の方向によって送信モジュール１０又は受信モジュール２０のいずれにもなり得る。次に、図２を参照して、ルートポート１０１～１０４のパケット送信時の動作を説明する。

受信モジュール２０について説明する。受信モジュール２０は、送信モジュール１０から送信されたデータパケットを受信する。受信モジュール２０は、処理実行部２１、受信バッファ２２、送信部２３及び受信部２４を有する。

受信バッファ２２は、例えば、図１における受信バッファ１３０の共用分の領域である。受信バッファ２２は、各送信モジュール１０から送信されたデータパケットを一時的に格納する。受信バッファ２２のサイズは、受信バッファ２２の読み出しレイテンシと目標スループットとを基に決定される。

処理実行部２１は、データパケットを受信バッファ２２から取得する。そして、処理実行部２１は、取得したデータパケットに対する処理を実行する。

送信部２３は、受信バッファ２２からデータパケットが処理実行部２１により取り出されたときに、取り出されたデータパケットのサイズの情報を含むデータパケットの処理通知をそのデータパケットの送信元の送信モジュール１０へ送信する。

受信部２４は、データパケットを各送信モジュール１０から取得する。そして、受信部２４は、取得したデータパケットを受信バッファ２２に格納する。

送信モジュール１０は、受信モジュール２０に対してデータパケットの送信を行う。図２に示すように、送信モジュール１０は、受信部１１、送信部１２、空きバッファ管理部１３及び記憶部１４を有する。

記憶部１４は、貸出受諾閾値１４１、初期空きバッファ値１４２及び貸出依頼閾値１４３を記憶する。貸出受諾閾値１４１は、自己が搭載された送信モジュール１０に割り当てられた空きバッファを貸し出すことを許可するか否かを判定するための閾値である。初期空きバッファ値１４２は、起動時に空きバッファとして割り当てられる受信バッファ２２における割当量を表す。本実施例では、初期空きバッファ値１４２は、ルートポート１０１～１０４の全てで同一の値を用いる。すなわち、起動時には、受信モジュール２０の受信バッファ２２の領域は、パケットの送信元となる送信モジュール１０の間で等分割される。貸出依頼閾値１４３は、受信バッファ２２を共有する他の送信モジュール１０に対して割り当てられた空きバッファの貸し出しを要求するか否かを判定するための閾値である。貸出依頼閾値１４３は、貸出受諾閾値１４１よりも小さな値である。

受信部１１は、受信モジュール２０の受信バッファ２２に滞留するデータパケットが読み出されて処理されたために受信バッファ２２にその分の空きができたことを表すデータパケットの処理通知を受信モジュール２０の送信部２３から受信する。そして、受信部１１は、受信バッファ２２の割り当てられた領域において新たに増えた空きバッファのサイズを空きバッファ計算部１３２に通知する。

また、受信部１１は、受信バッファ２２を共有する他の送信モジュール１０の送信部１２から、受信バッファ２２の自己の割り当て分からの貸し出しを依頼する貸出依頼パケットを受信する。そして、受信部１１は、貸出可否の判定を貸出依頼応答部１３１に依頼する。

また、受信部１１は、貸出依頼パケットに対する応答である貸出応答を、受信バッファ２２を共有する他の送信モジュール１０の送信部１２から受信する。そして、受信部１１は、受信した貸出応答が貸出受諾を通知する内容の場合、貸出受諾の通知を空きバッファ計算部１３２へ出力する。また、受信した貸出応答が貸出拒否を通知する内容の場合、受信部１１は、貸出依頼の再送を送信部１２に依頼する。ただし、その時点で貸出依頼の条件が解消されている場合、受信部１１は、再送を依頼しなくてもよい。

送信部１２は、データパケットを送信する際に、その時点での空きバッファ値の通知要求を空きバッファ計算部１３２に行う。そして、送信部１２は、その時点での受信バッファ２２における空きバッファ値が送信するデータパケットのサイズ以上の場合、そのデータパケットを受信モジュール２０の受信部２４へ送信する。さらに、送信部１２は、受信モジュール２０へのデータパケットの送信をそのデータパケットのサイズとともに空きバッファ計算部１３２に通知する。これに対して、その時点での空きバッファ値が、送信するデータパケットのサイズ未満の場合、送信部１２は、空きバッファ値の通知要求を空きバッファ計算部１３２に行いつつ、送信するデータパケット以上の空きバッファが確保できるまで待機する。

また、送信部１２は、貸出依頼パケットの送信の指示を貸出依頼判定部１３３から受ける。そして、送信部１２は、取得した貸出依頼パケットを、受信バッファ２２を共有する他の送信モジュール１０の受信部１１へ送信して貸出依頼を行う。

その後、貸出依頼に対して貸出拒否を通知する貸出応答を受信部１１が受信した場合、送信部１２は、貸出依頼の再送の依頼を受信部１１から受ける。そして、送信部１２は、貸出依頼パケットを、受信バッファ２２を共有する他の送信モジュール１０の受信部１１へ再度送信する。だだし、送信部１２は、直ぐに貸出依頼パケットを再送しなくてもよく、予め決められた時間待機してから貸出依頼パケットを再送信してもよい。また、その時点で貸出依頼の条件が解消されている場合、送信部１２は、再送を依頼しなくてもよい。

また、送信部１２は、貸出応答の送信の指示を貸出依頼応答部１３１から受ける。そして、送信部１２は、貸出依頼応答部１３１から取得した貸出応答を、受信バッファ２２を共有する貸出依頼の送信元である送信モジュール１０の受信部１１へ送信する。

空きバッファ管理部１３は、自己が搭載された送信モジュール１０に対する受信バッファ２２の割り当て分における空きバッファを管理する。空きバッファ管理部１３は、貸出依頼応答部１３１、空きバッファ計算部１３２及び貸出依頼判定部１３３を有する。

貸出依頼応答部１３１は、受信バッファ２２を共有する他の送信モジュール１０からの貸出依頼パケットを受信部１１から取得する。そして、貸出依頼応答部１３１は、空きバッファ値の通知要求を空きバッファ計算部１３２に対して行い、その時点での空きバッファ値を取得する。次に、貸出依頼応答部１３１は、記憶部１４に格納された貸出受諾閾値１４１を取得する。

そして、貸出依頼応答部１３１は、その時点の空きバッファ値と貸出受諾閾値１４１とを比較する。その時点の空きバッファ値が貸出受諾閾値１４１以上の場合、貸出依頼応答部１３１は、貸出受諾を通知する貸出応答を作成する。ここで、貸出受諾閾値１１４から貸出依頼閾値１４３を減算した値は、貸出依頼に対して貸し出す予め決められた空きバッファのサイズである貸出単位量より大きい値である。

また、その時点の空きバッファ値が貸出依頼受諾閾値１４１未満の場合、貸出依頼応答部１３１は、貸出拒絶を通知する貸出応答を作成する。貸出受諾閾値１４１は、例えば、初期空きバッファ値１４２のサイズを１００とした場合の２０や３０といった割合にあたる値である。その後、貸出依頼応答部１３１は、貸出依頼の送信元の送信モジュール１０に対する、貸出依頼応答の送信を送信部１２へ指示する。ここで、貸出依頼応答が貸出受諾の内容である場合、貸出依頼応答部１３１は、空きバッファの貸し出しを空きバッファ計算部１３２に通知する。

空きバッファ計算部１３２は、パケットの送信先となる受信モジュール２０の受信バッファ２２における初期空きバッファ値１４２を起動時に取得して、初期の空きバッファ値として設定する。

空きバッファ計算部１３２は、送信部１２により受信モジュール２０に対してデータパケットが送信されると、データパケットのサイズとともにデータパケットの送信通知を送信部１２から受ける。そして、空きバッファ計算部１３２は、その時点での空きバッファ値から通知されたデータパケットのサイズを減算して新たな空きバッファ値とする。そして、空きバッファ計算部１３２は、空きバッファ値を減らした場合、その時点での空きバッファ値を貸出依頼判定部１３３に通知するとともに貸出依頼判定を指示する。

また、空きバッファ計算部１３２は、空きバッファ値の通知要求を送信部１２から受ける。そして、空きバッファ計算部１３２は、その時点での空きバッファ値を送信部１２に通知する。

また、空きバッファ計算部１３２は、処理実行部２１により受信バッファ２２からデータパケットが取り出された場合、新たに増えた空きバッファのサイズの通知を受信部１１から受ける。そして、空きバッファ計算部１３２は、その時点での空きバッファ値に新たに増えた空きバッファのサイズを加算して、新たな空きバッファ値とする。

また、空きバッファ計算部１３２は、空きバッファ値の通知要求を貸出依頼応答部１３１から受ける。そして、空きバッファ計算部１３２は、その時点での空きバッファ値を貸出依頼応答部１３１に通知する。

また、貸出依頼応答部１３１が貸出受諾を通知する貸出依頼応答を送信した場合、空きバッファ計算部１３２は、空きバッファの貸し出しの通知を貸出依頼応答部１３１から受ける。そして、貸出依頼応答部１３１は、予め決められた貸出単位量をその時点での空きバッファ値から減差して、新たな空きバッファ値とする。

また、他の送信モジュール１０に対して行った貸出依頼に対する応答が貸出受託を通知する内容の場合、空きバッファ計算部１３２は、貸出受諾の通知を受信部１１から受ける。そして、空きバッファ計算部１３２は、予め決められた貸出単位量をその時点での空きバッファ値に加算して、新たな空きバッファ値とする。

貸出依頼判定部１３３は、その時点での空きバッファ値の通知とともに貸出依頼判定の指示を空きバッファ計算部１３２から受ける。次に、貸出依頼判定部１３３は、貸出依頼閾値１４３を記憶部１４から取得する。

そして、貸出依頼判定部１３３は、その時点での空きバッファ値と貸出依頼閾値１４３とを比較する。その時点での空きバッファ値が貸出依頼閾値１４３以上の場合、貸出依頼判定部１３３は、貸出依頼不要と判定する。

これに対して、その時点での空きバッファ値が貸出依頼閾値１４３未満の場合、貸出依頼判定部１３３は、既に貸出依頼を行っている最中か否かを判定する。貸出依頼を行っている最中でなければ、貸出依頼判定部１３３は、受信バッファ２２を共有する他の送信モジュール１０に対する空きバッファの貸し出しを依頼する貸出依頼パケットを生成する。そして、貸出依頼判定部１３３は、生成した貸出依頼パケットの送信を送信部１２に指示する。貸出依頼閾値１４３は、貸出受諾閾値１４１よりも小さい値であり、例えば、初期空きバッファ値１４２のサイズを１００とした場合の１０や２０といった割合にあたる値である。

貸出受諾閾値１４１や貸出依頼閾値１４３は、頻繁に貸したり、借りたりしないような値に設定するなど、実行される通信の性格によって固有に決められてもよい。また、貸出受諾閾値１４１や貸出依頼閾値１４３としていくつかの設定値を記憶するレジスタを用意し、情報処理装置１においてどの程度の貸し借りを行わせたいかによりソフトウェアにより、貸出受諾閾値１４１や貸出依頼閾値１４３の値を選択させて設定させてもよい。

ここで、送信モジュール１０がＮ個（Ｎ＞２）の場合の貸出依頼要求を行う送信モジュール１０の決定方法について説明する。例えば、貸出依頼要求をする送信モジュール１０は、他の送信モジュール１０の中から１つ選択して貸出依頼要求を行い、貸出拒否の貸出応答を受信した場合は、別の他の送信モジュール１０に貸出依頼要求を行う。貸出依頼要求をする送信モジュール１０は、貸出受諾の貸出応答がくるまで、順次１つずつ未選択の他の送信モジュール１０を選択して貸出依頼要求を繰り返す。

他にも、ある送信モジュール１０が貸出依頼を拒否する場合は、その送信モジュール１０は貸出依頼要求元以外の他の送信モジュール１０に貸出依頼要求を転送し、貸出受諾ができる送信モジュール１０に至るまで順番に転送する。そして、貸出受諾ができる送信モジュール１０に転送されたときに、その送信モジュール１０が貸出受諾の貸出応答を、貸出依頼元の送信モジュール１０に送信してもよい。

図３は、実施例１に係る情報処理装置による空きバッファ管理処理のフローチャートである。次に、図３を参照して、実施例１に係る情報処理装置１によるデータパケットの送信処理の流れを説明する。以下に説明する空きバッファ管理処理は、送信部１２による受信モジュール２０へのデータパケットの送信と並行して行われる。

空きバッファ計算部１３２は、初期空きバッファ値１４２を記憶部１４から取得して、空きバッファ値に初期値として設定する（ステップＳ１）。

その後、空きバッファ計算部１３２は、送信部１２からのデータパケット送信の通知の有無により、送信部１２がデータパケットを受信モジュール２へ送信したか否かを判定する（ステップＳ２）。送信部１２がデータパケットを受信モジュール２へ送信していない場合（ステップＳ２：否定）、空きバッファ管理処理は、ステップＳ４へ進む。

これに対して、送信部１２がデータパケットを受信モジュール２へ送信した場合（ステップＳ２：肯定）、空きバッファ計算部１３２は、送信されたデータパケットのサイズ分、空きバッファ値を減少させる（ステップＳ３）。

貸出依頼判定部１３３は、空きバッファ値が貸出依頼閾値１４３未満であり、且つ、他の送信モジュール１０に対して貸出依頼中でないかを判定する（ステップＳ４）。空きバッファ値が貸出依頼閾値１４３以上もしくは貸出依頼中の場合（ステップＳ４：否定）、空きバッファ管理処理は、ステップＳ６へ進む。

これに対して、空きバッファ値が貸出依頼閾値１４３未満であり、且つ、貸出依頼中でない場合（ステップＳ４：肯定）、貸出依頼判定部１３３は、貸出依頼パケットの送信を送信部１２に指示する。送信部１２は、貸出依頼判定部１３３からの指示を受けて、貸出依頼パケットを、受信バッファ２２を共有する他の送信モジュール１０へ送信する（ステップＳ５）。

また、空きバッファ計算部１３２は、受信部１１からの新たに増えた空きバッファのサイズの通知の有無により、データパケットの処理通知を受信したか否かを判定する（ステップＳ６）。データパケットの処理通知を受信していない場合（ステップＳ６：否定）、空きバッファ管理処理は、ステップＳ８へ進む。

これに対して、データパケットの処理通知を受信した場合（ステップＳ６：肯定）、空きバッファ計算部１３２は、通知された新たに増えた空きバッファのサイズ分、空きバッファ値を増加させる（ステップＳ７）。

また、空きバッファ計算部１３２は、貸出受諾の貸出応答を他の送信モジュール１０から受信したか否かを判定する（ステップＳ８）。貸出受諾の貸出応答を受信していない場合（ステップＳ８：否定）、空きバッファ管理処理は、ステップＳ１０へ進む。

これに対して、貸出受諾の貸出応答を受信した場合（ステップＳ８：肯定）、空きバッファ計算部１３２は、空きバッファ値を貸出単位量増加させる（ステップＳ９）。

また、貸出依頼応答部１３１は、受信バッファ２２を共有する他の送信モジュール１０から貸出依頼要求を受信したか否かを判定する（ステップＳ１０）。貸出依頼要求を受信していない場合（ステップＳ１０：否定）、空きバッファ管理処理は、ステップＳ１４へ進む。

これに対して、貸出依頼要求を受信した場合（ステップＳ１０：肯定）、貸出依頼応答部１３１は、空きバッファ値が貸出受諾閾値１４１以上か否かを判定する（ステップＳ１１）。

空きバッファ値が貸出受諾閾値１４１以上の場合（ステップＳ１１：肯定）、貸出依頼応答部１３１は、貸出受諾を通知する貸出応答を作成して貸出応答の送信を送信部１２に指示するとともに、貸出受諾を空きバッファ計算部１３２に通知する。空きバッファ計算部１３２は、空きバッファ値を貸出単位量減少させる。また、送信部１２は、貸出受諾の貸出応答を貸出依頼の送信元である送信モジュール１０へ送信する（ステップＳ１２）。

これに対して、空きバッファ値が貸出受諾閾値１４１未満の場合（ステップＳ１１：否定）、貸出依頼応答部１３１は、貸出拒否を通知する貸出応答を作成して貸出応答の送信を送信部１２に指示する。送信部１２は、貸出拒否の貸出応答を貸出依頼の送信元である送信モジュール１０へ送信する（ステップＳ１３）。

その後、空きバッファ管理部１３は、情報処理装置１の電源が落とされるといった操作者による動作停止指示の有無などにより、動作を停止させるか否かを判定する（ステップＳ１４）。情報処理装置１の動作が継続する場合（ステップＳ１４：否定）、空きバッファ管理処理は、ステップＳ２へ進む。これに対して、情報処理装置１の動作が停止される場合（ステップＳ１４：肯定）、空きバッファ管理部１３は、空きバッファ管理処理を終了する。

ここで、本実施例では、貸し出しを受けた受信バッファ２２の割り当て分の返却については記載していないが、返却方法は以下に示す方法を採用することが可能である。例えば、空きバッファ管理部１３は、空きバッファ値が所定の返却閾値を超えた場合に、貸出元の送信モジュール１０に対して返却の通知を行い空きバッファ値を減らす。他にも、返却処理をなくして貸出自体を授与として、空きバッファ管理部１３は、貸出依頼要求が来た場合に貸し出してもよい。

次に、図１に戻って、本実施例に係る情報処理装置１による受信バッファ１３０の共用分の融通と、受信側を介して受信バッファ１３０の共用分の融通を行う場合との比較について説明する。

まず、受信側を介して受信バッファ１３０の共用分の融通を行う場合について説明する。ルートポート１０１が最初にエンドポイント２０１からのデータパケットを受信してルートポート１０３にそれを送信するときと同時に、ルートポート１０３に受信バッファ１３０の共用分の割り当てサイズの増の要求パケットを送信する。この場合、ルートポート１０３は、データパケットをルートポート１０３が受信してエンドポイント２０３に送信した時に、受信バッファ１３０の空きを通知するパケットをルートポート１０１に送信する。ここで、受信バッファ１３０の空きを通知するパケットよりも早く、ルートポート１０３からルートポート１０１への受信バッファ１３０の割り当ての増加を通知するパケットがルートポート１０１に先に届くことはない。なぜなら、ルートポート１０３は、ルートポート１０２に割り当てた共用分の領域を減らしてよいかを問い合わせるパケットをルートポート１０２に送信してその応答を受け取ることになり、その時間分遅くなるからである。このように、ルートポート１０３を介して受信バッファ１３０の共用分の割り当ての増減を調整しようとするとスループット性能がでないことになる。この場合は、ルートポート１０１とルートポート１０３との間の割り当て増要求＋応答の往復２５６ｎｓｅｃとルートポート１０３とルートポート１０２との間の割り当て減少要求＋応答の往復２８８ｎｓｅｃの合計である５４４ｎｓｅｃの間、性能が出ない。

これに対して、本実施例では、ルートポート１０１が直接ルートポート１０２にルートポート１０３が有するルートポート１０２に割り当てられたバッファの融通を要求できる。そのため、ルートポート１０１とルートポート１０２との間の通信遅延３２ｎｓｅｃの往復６４ｎｓｅｃで受信バッファサイズを増加させることができる。ルートポート１０３ではルートポート１０１とルートポート１０２とから受信するデータパケットの量が１０ｋＢ＋１２ｋＢ＝２２ｋＢを超えない限り遅延が発生しない。そのため、ルートポート１０３は、ルートポート１０１とルートポート１０２との間のバッファ量の増減に関知しなくてもよい。

このように、この実施例では６４ｎｓｅｃ後にはルートポート１０１への受信バッファ１３０の割り当て量を増加できる。そして、その６４ｎｓｅｃの間に６４ＧＢ/ｓｅｃのスループットでルートポート１０１がルートポート１０３に送信する量は６４ｎｓｅｃ×６４ＧＢ/ｓｅｃ＝４ｋＢである。これは、受信バッファ１３０のうちの初期にルートポート１０１に割り当てられたサイズである１０ｋＢを十分に下回っている。したがって、受信バッファ１３０が満杯になって送信を止める前に、受信バッファ１３０におけるルートポート１０１に割り当てたサイズを増量できる。すなわち、受信バッファサイズがスループットのネックとなることがない。逆に、ルートポート１０２からルートポート１０３へのデータパケットの送信時も、ルートポート１０２がルートポート１０１との間で受信バッファ１３０の割り当てを融通することで、受信バッファ１３０のサイズの影響を受けずにスループット性能を出せる。ルートポート１０１とルートポート１０２との双方がデータパケットを送信する場合は、お互いがお互いに要求するため、ルートポート１０１とルートポート１０２は、調整できる共用分の１２ｋＢを分けて使う。

以上に説明したように、本実施例に係る情報処理装置において、受信バッファの割り当て領域の使用量に応じて、受信モジュールを経由せずに空きバッファの貸し借りを送信モジュール同士で行う。これにより、送信モジュールが要求するスループットの確保と受信バッファの調整を容易に行うことが可能となる。すなわち、複数の送信元が１つの送信先に対してデータパケットを送信する通信形態において、少ない受信バッファ資源でスループット性能を確保することが可能となる。特に、送信モジュールと受信モジュールとの間の距離が遠いために通信レイテンシが大きい場合に、本実施例に係る情報処理装置による送信モジュール同士での受信バッファの融通はスループット性能の向上に有効である。さらに、受信バッファを融通し合う送信モジュール間の距離が短ければ、よりスループット性能の向上が見込まれる。

次に、実施例２について説明する。本実施例に係る情報処理装置１も図１で表される。また、本実施例に係る情報処理装置１の空きバッファの管理についてのブロック図も図２で表される。以下の説明では、実施例１と同じ各部の動作については説明を省略する。

図１において、ルートポート１０１とルートポート１０２は、調整できる共用分の１２ｋＢを分けて使う場合、ルートポート１０１及び１０２がそれぞれルートポート１０３宛てとして６４ＧＢ/ｓｅｃのスループットで送信しようとすると、ルートポート１０１及び１０２に設定された一時バッファ（不図示）にパケットが溜まる。例えば、この溜まった量をルートポート１０１とルートポート１０２との間でルートポート１０３の受信バッファ１３０の共用分の割り当てを要求する際に通知しあうことで、どちらがどれだけのルートポート１０３の受信バッファ１３０の共用分を使うかを決めれば、エンドポイント２０１とルートポート１０１との間、エンドポイント２０２とルートポート１０２との間の通信負荷に応じたルートポート１０３の受信バッファ１３０の割当てをすることも可能である。そこで、本実施例に係る情報処理装置１は、エンドポイント２０２とルートポート１０２との間の通信負荷に応じて受信バッファ１３０の共用分の割り当てを行う。以下に、図２を参照して、本実施例に係る情報処理装置１による受信バッファ２２の割り当て処理を説明する。

送信部１２は、受信モジュール２０に送信するデータパケットが供給されるが、何らかの理由で受信モジュール２０に対して送信ができない場合は、送信モジュール１０が有する一時バッファ（不図示）にデータパケットを蓄積する。

貸出依頼判定部１３３は、この一時バッファに溜まったデータパケットのパケット量からその時点の空きバッファ値を減算した値が、予め設定された貸出依頼閾値１４３以上か否か判定する。そして、求めた値が貸出依頼閾値１４３以上になったときに、貸出依頼判定部１３３は、受信バッファ２２を共有する他の送信モジュール１０に送信部１２を介して貸出依頼パケットを送信して貸出依頼要求を行う。以下では、一時バッファに溜まったデータパケットのパケット量を「一時バッファ量」と呼び、一時バッファ量からその時点の空きバッファ値を減算した値を「差分量」とよぶ。

貸出依頼応答部１３１は、貸出依頼要求を受けた場合、自己が搭載された送信モジュール１０における差分量が、予め設定された貸出受諾閾値１４１を下回っている時に貸出受諾の貸出応答を作成する。そして、貸出依頼応答部１３１は、送信部１２を介して貸出依頼パケットの送信元の送信モジュール１０に作成した貸出応答を送信する。

（変形例）
他の第１の方法として、以下のような構成を用いることもできる。貸出依頼判定部１３３は、空きバッファ値が貸出依頼閾値１４３を下回った場合に貸出要求を出す。この時、貸出依頼判定部１３３は、一時バッファ量又は差分量の情報を供給パケットに情報を付加して送信する。

貸出依頼応答部１３１は、貸出依頼要求を受けた場合、自己が搭載された送信モジュール１０における一時バッファ量又は差分量と貸出依頼元の送信モジュール１０における一時バッファ量又は差分量とを比較する。そして、例えば、その差が予め設定された貸出受諾閾値１４１を超えた時に、貸出依頼応答部１３１は、貸出受諾の貸出応答を生成して、送信部１２を介して貸出依頼元の送信モジュール１０へ送信する。

また、他の第２の方法として、以下のような構成を用いることもできる。例えば、貸出依頼要求に対して貸出受諾の応答を受けて空きバッファ計算部１３２により空きバッファ値に貸出単位量を加算してもなお貸出依頼を行う条件が満たされた場合について考える。その場合に、貸出依頼判定部１３３は、受信バッファ２２を共有する他の送信モジュール１０に貸出要求を１回目と同じ手順で再度行ってもよい。また、予め設定された上限数の貸し出しを受けた場合、貸出依頼判定部１３３は、以降貸出要求の条件を満たしても貸出要求を行わなくてもよい。貸出依頼応答部１３１は、２回目の貸出依頼要求に対しても同じように貸出受諾の判定を行う。

また、他の第３の方法として、以下のような構成を用いることもできる。貸出要求が受諾され空きバッファ計算部１３２により空きバッファ値が増加された後、通信負荷が下がり空きバッファ値が予め設定された返却閾値を上回った場合、空きバッファ計算部１３２は、空きバッファ値から貸出単位量を減算する。さらに、空きバッファ計算部１３２は、送信部１２を介して貸出元の送信モジュール１０に返却を通知する。

返却通知を受けた送信モジュール１０の空きバッファ計算部１３２は、返却通知を受信した場合、空きバッファ値に貸出単位量を加算する。その後、空きバッファ計算部１３２は、応答を貸出先であった送信モジュール１０に送信する。ここで、空きバッファ計算部１３２は、返却通知中は貸出要求を行わないなどのルールを加えてもよい。

ここで、貸出先の送信モジュール１０と貸出元の送信モジュール１０とに割り当てられた受信バッファ２２のトータルの空きバッファ値が受信バッファ２２のサイズの上限を超えないように、返却元での減算が先に行われ、その後に返却先での加算が行われる。

以上に説明したように、実施例１以外の貸出依頼や貸出応答を行う構成であっても、送信モジュール同士の間で直接、受信バッファの共有分の割り当てを融通し合うことができる。その場合も、送信モジュールが要求するスループットの確保と受信バッファの調整を容易に行うことが可能となる。

図４は、実施例３に係る情報処理装置の構成図である。以下の説明では、実施例１と同じ各部の動作については説明を省略する。

本実施例に係る情報処理装置１は、ルートポート１０１及び１０２を搭載したＳｏＣ１１１とルートポート１０３及び１０４を搭載したＳｏＣ１１２を接続して使うシステムである。片方のＳｏＣ１１１に実装されたルートポート１０１及び１０２からもう片方のＳｏＣ１１２のルートポート１０３へ送信する場合を考える。ここで、ＳｏＣ１１１とＳｏＣ１１２との２個が存在する形態であっても、ルートポート１０１及びルートポート１０２がルートポート１０３と間に他の通信接続を挟まずに通信を行う構成であれば、動作は実施例１と同様となる。

ここでは、ＳｏＣ１１１とＳｏＣ１１２とを繋ぐ別の通信接続が存在し、その通信はソケットコネクト３０１とソケットコネクト３０２との間で行われる。このＳｏＣ１１１とＳｏＣ１１２との間の通信接続は、実施例１で述べたルートポート１０３とエンドポイント２０３との間の通信と同様に通信品質の問題で一時的に通信できない状態が存在しうる。そのため、ソケットコネクト３０１及び３０２は、ルートポート１０１又は１０２ら受け取るデータパケットを貯めておく受信バッファ３１１及び３２１をそれぞれが有する。この受信バッファ３１１及び３２１をルートポート１０１とルートポート１０２とで使用する場合について説明する。

この場合、ソケットコネクト３０１が有する受信バッファ３１１の一部をルートポート１０１とルートポート１０２とで共有する。そして、ルートポート１０１とルートポート１０２同士で、実施例１における受信バッファ２２の融通と同様に、受信バッファ３１１の共有分の割り当てを融通し合う。これは、ソケットコネクト３０２が有する受信バッファ３２１についても同様である。

以上に説明したように、本実施例に係る情報処理装置のように送信モジュールと受信モジュールとの間に他の通信接続が存在する場合、その通信接続を行うユニットを受信モジュールとして、そのユニットが有する受信バッファの共有分の割り当てを送信モジュール同士で受信モジュールを介さずに融通し合うことができる。これにより、送信モジュールが要求するスループットの確保と受信バッファの調整を容易に行うことが可能となる。

図５は、実施例４に係る情報処理装置の構成図である。以下の説明では、実施例１と同じ各部の動作については説明を省略する。

本実施例に係る情報処理装置１は、ＳｏＣ１００上の各ユニットの配置や通信の形態は実施例１と同じである。本実施例に係る情報処理装置１は、受信側のルートポート１０３がパケットの種類により複数の異なる受信バッファを有する。

ＰＣＩｅでは、パケットの種別としてPostedパケット、Non-Postedパケット、Completionパケットの３つが存在し、それらの通信経路上の順序保証について規定されている。例えば、データの書き換え順序の保証等などを目的に、Postedパケットが送信され、その後に送信されたパケットが最終的な送信先に到着するまでの間に、先に送信されたPostedパケットを追い抜くことが禁止される。また、Postedパケットに対する条件に加えて、通信上のデッドロックを回避するために、PostedパケットはNon-PostedパケットおよびCompletionパケットを追い越せるようにすることが規定されている。これはNon-PostedパケットやCompletionパケットが通信経路上に詰まったとしても、後から送信されたPostedパケットが通信経路上でNon-Postedパケット及びCompletionパケットを追い越して送信先に到着しなければいけないことを規定する。

これらの規定を実現するために、本実施例では、ルートポート１０１とルートポート１０３とで通信する際に、ルートポート１０３は、パケットの種類毎に、Postedバッファ２２１、Non-Postedバッファ２２２及びCompletionバッファ２２３を有する。

これにより、例えばNon-PostedパケットとCompletionパケットとの両方が詰まったとしても、Postedパケット用のPostedバッファ２２１が確保されているので、ルートポート１０１はルートポート１０３にPostedパケットを送信可能である。これにより、ルートポート１０３は、Non-Postedパケット及びCompletionパケットを追い越させてPostedパケットをエンドポイント２０３に送信することが可能である。

ここで、PostedパケットとCompletionパケットはデータを伴うことがあり、両方とも高いスループット性能を出せることが期待される。しかし、実施例１での説明と同様に、ルートポート１０３とエンドポイント２０３との間は全てのパケットのトータルのスループットとして上限が６４ＧＢ/ｓｅｃである。そのため、PostedパケットとCompletionパケットが同時に６４ＧＢ/ｓｅｃとなることはなく、両方の合計のスループットが６４ＧＢ/ｓｅｃを達成すればよい。しかし、どちらか一方のパケットのみの場合は、それぞれ６４ＧＢ/ｓｅｃを達成することが期待である。この状況は、実施例１及び２のルートポート１０１及び１０２からルートポート１０３へデータパケットを送信するケースと同じ状況である。

そこで、本実施例に係るルートポート１０１は、Postedバッファ２２１の一部とCompletionバッファ２２３の一部とを共有分とすることで、ルートポート１０３の受信バッファのトータルサイズを削減することが可能である。本実施例ではPostedパケットとCompletionパケットを送信する際に、ルートポート１０１が、内部でルートポート１０１のPostedバッファ２２１とCompletionバッファ２２３の使用量の割合を調整する。

すなわち、ルートポート１０１が、図２における２つの送信モジュール１０の機能を内蔵する状態と考えることができる。その場合、一方の送信モジュール１０がPostedパケットを、受信モジュール２０であるルートポート１０３のPostedバッファ２２１へ送信し、他方の送信モジュール１０がCompletionパケットを、Completionバッファ２２３へ送信する。

なお、PostedパケットはCompletionパケットを追い越せることが規定されている。そのため、Postedバッファ２２１の一部とCompletionバッファ２２３の一部とを共有分とすることはできるが、Postedバッファ２２１とCompletionバッファ２２３との間での融通状態に関わらず、それぞれ最低限のバッファが割り当たっていることが望ましい。

以上に説明したように、本実施例に係る情報処理装置は、１つのルートポートの内部でPostedパケットへの受信バッファの割り当てとCompletionパケットへの受信バッファの割り当てを調整する。すなわち、本実施例に係る情報処理装置では、受信バッファの割り当ての調整のディレイはほぼゼロであり、受信バッファのサイズを小さく抑えることができる。これにより、パケットの種類毎に要求されるスループットの確保と受信バッファの調整を容易に行うことが可能となる。

１ 情報処理装置
１０ 送信モジュール
１１ 受信部
１２ 送信部
１３ 空きバッファ管理部
１４ 記憶部
２０ 受信モジュール
２１ 処理実行部
２２ 受信バッファ
２３ 送信部
２４ 受信部
１０１～１０４ ルートポート
１０５ リングバス
１３０ 受信バッファ
１３１ 貸出依頼応答部
１３２ 空きバッファ計算部
１３３ 貸出依頼判定部
１４１ 貸出受諾閾値
１４２ 初期空きバッファ値
１４３ 貸出依頼閾値
１５０、１５１～１５４ リングストップ
２０１～２０４ エンドポイント
２２１ Postedバッファ
２２２ Non-Postedバッファ
２２３ Completionバッファ

Claims (6)

1. 受信モジュール、並びに、前記受信モジュールに対してパケットを送信する第１送信モジュール及び第２送信モジュールを有する情報処理装置あって、
   前記受信モジュールは、
   前記第１送信モジュールと前記第２送信モジュールとにより共有される、前記パケットを格納する受信バッファを備え、
   前記第１送信モジュールは、
   前記第１送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記第２送信モジュールに割り当てられた前記受信バッファの貸出依頼を前記第２送信モジュールに送信する貸出依頼判定部と、
   前記第２送信モジュールが前記貸出依頼に対して受諾応答を送信した場合、前記第１送信モジュールに対する前記受信バッファの割り当て量を増加させる第１空きバッファ計算部とを備え、
   前記第２送信モジュールは、
   前記貸出依頼を受信して、前記第２送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記受諾応答を前記第１送信モジュールへ送信する貸出依頼応答部と、
   前記貸出依頼応答部が前記受諾応答を送信した場合、前記第２送信モジュールに対する前記受信バッファの割り当て量を減少させる第２空きバッファ計算部とを備えた
   ことを特徴とする情報処理装置。
2. 前記貸出依頼判定部は、前記第１送信モジュールに割り当てられた前記受信バッファの未使用量が、予め決められた貸出依頼閾値未満の場合に、前記貸出依頼を送信することを特徴とする請求項１に記載の情報処理装置。
3. 前記貸出依頼応答部は、前記第２送信モジュールに割り当てられた前記受信バッファの未使用量が、予め決められた貸出受諾閾値以上の場合に、前記受諾応答を送信することを特徴とする請求項１又は２に記載の情報処理装置。
4. 前記第１送信モジュール及び前記第２送信モジュールと前記受信モジュールとの間に、前記第１送信モジュールと前記第２送信モジュールとにより共有される、前記パケットを格納する他の受信バッファを有し、前記第１送信モジュール及び前記第２送信モジュールから送信された前記パケットを受信して前記他の受信バッファに格納し、前記受信モジュールへ転送する中継装置を有し、
   前記貸出依頼判定部は、前記第１送信モジュールに割り当てられた前記他の受信バッファの使用量を基に、前記第２送信モジュールに対して割り当てられた前記他の受信バッファの他の貸出依頼を前記第２送信モジュールに送信し、
   前記第１空きバッファ計算部は、前記第２送信モジュールが前記他の貸出依頼に対して他の受諾応答を送信した場合、前記第１送信モジュールに対する前記他の受信バッファの割り当て量を増加させ、
   前記貸出依頼応答部は、前記他の貸出依頼を受信して、前記第２送信モジュールに割り当てられた前記他の受信バッファの使用量を基に、前記他の受諾応答を前記第１送信モジュールへ送信し、
   前記第２空きバッファ計算部は、前記貸出依頼応答部が前記他の受諾応答を送信した場合、前記第２送信モジュールに対する前記他の受信バッファの割り当て量を減少させる
   ことを特徴とする請求項１～３のいずれか一つに記載の情報処理装置。
5. 前記第１送信モジュールは、第１パケットを送信し、
   前記第２送信モジュールは、前記第１パケットとは異なる種類であり、且つ、通信経路上での前記第１パケットに対する振る舞いが規定された第２パケットを送信する
   ことを特徴とする請求項１～４のいずれか一つに記載の情報処理装置。
6. 受信モジュール、並びに、前記受信モジュールに対してパケットを送信する第１送信モジュール及び第２送信モジュールを有する情報処理装置の制御方法であって、
   前記受信モジュールが有し、且つ、前記第１送信モジュールと前記第２送信モジュールとにより共有される、前記パケットを格納する受信バッファにおいて、前記第１送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記第２送信モジュールに割り当てられた前記受信バッファの貸出依頼を前記第２送信モジュールに送信させ、前記第２送信モジュールが前記貸出依頼に対して受諾応答を送信した場合、前記第１送信モジュールに対する前記受信バッファの割り当て量を増加させる処理を前記第１送信モジュールに行わせ
   前記貸出依頼を受信して、前記第２送信モジュールに割り当てられた前記受信バッファの使用量を基に、前記受諾応答を前記第１送信モジュールへ送信させ、前記受諾応答を送信した場合、前記第２送信モジュールへの前記受信バッファの割り当て量を減少させる処理を前記第２送信モジュールに行わせる
   ことを特徴とする情報処理装置の制御方法。

Images