(57)【特許請求の範囲】
【請求項１】
情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、受信メッセージまたは受信関数の引数の全部または一部に相当する受信情報を格納する複数の受信バッファと、
前記受信メッセージが有している受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、
前記受信情報を、前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納する格納手段と、
受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じて、前記受信情報を前記ハッシュ値に係る前記受信バッファの先頭からバースト転送する出力手段と、
を備えることを特徴とする通信制御装置。
【請求項２】
情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、分散メモリ型並列処理におけるメッセージ交換のためのライブラリが取り扱う受信メッセージの全部または一部を格納する複数の受信バッファと、
前記受信メッセージが有している前記受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、
前記受信メッセージを、当該受信メッセージが有している前記受信キーから生成された前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納するメッセージ格納手段と、
受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じて、前記受信関数に応じた前記受信メッセージの一つ以上の候補を、当該受信関数で指定される受信キーから生成される前記ハッシュ値に係る前記受信バッファの先頭からバースト転送するメッセージ出力手段と、
を備えることを特徴とする通信制御装置。
【請求項３】
前記受信メッセージを、当該受信メッセージの所定の位置より前に位置して前記受信キーを含む前半メッセージと、前記前半メッセージに続く後半メッセージとに分割する分割手段を備え、
前記メッセージ格納手段は、前記後半メッセージが格納される大容量の第２メモリと比較して小容量、かつ、データの転送要求などのリクエストを発してからリクエストの結果が返ってくるまでにかかる遅延時間が短い低遅延な第１メモリが有している前記受信バッファに、前記分割手段により得られた前記前半メッセージを格納する、
ことを特徴とする請求項２記載の通信制御装置。
【請求項４】
前記ハッシュ値生成手段の前記ハッシュ値生成規則を変更可能とする変更手段を備える、
ことを特徴とする請求項２記載の通信制御装置。
【請求項５】
前記変更手段は、前記受信メッセージ内に含まれる情報に応じて使用する前記ハッシュ値生成規則を変更可能である、
ことを特徴とする請求項４に記載の通信制御装置。
【請求項６】
情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、分散メモリ型並列処理におけるメッセージ交換のためのライブラリで用いられる受信関数の引数の全部または一部に相当する受信要求情報を格納する複数の受信バッファと、
受信メッセージが有している受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、
受信キーの一致判定により受信を行なう受信手段からの前記受信関数に係る受信要求情報を、当該受信関数に係る受信メッセージが届くまで、当該受信関数の前記受信キーから生成された前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納する受信要求格納手段と、
前記受信メッセージが届いた場合であって、当該受信メッセージが有している前記受信キーから生成される前記ハッシュ値に係る前記受信バッファ内に前記受信要求情報がある場合、前記受信メッセージをバースト転送するメッセージ出力手段と、
を備えることを特徴とする通信制御装置。
【請求項７】
前記キーハッシュ値生成手段の前記ハッシュ値生成規則を変更可能とする規則変更手段を備える、
ことを特徴とする請求項６記載の通信制御装置。
【請求項８】
前記規則変更手段は、前記受信メッセージ内に含まれる情報に応じて使用する前記ハッシュ値生成規則を変更可能である、
ことを特徴とする請求項７記載の通信制御装置。
【請求項９】
請求項１ないし８のいずれか一に記載の通信制御装置と、
前記通信制御装置が備えるハッシュ値生成手段で用いられるハッシュ値生成規則を有しており、受信関数で指定される受信キーを入力として得られるハッシュ値に基づいて前記通信制御装置の所望の受信バッファに格納されている受信情報を当該通信制御装置から取得するホスト部と、
を備えることを特徴とする情報処理装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信制御装置および情報処理装置に関する。
【背景技術】
【０００２】
従来から、ＰＣクラスタや並列計算機において、メッセージ交換方式の通信が用いられている。特に、並列アプリケーションにおいては、分散メモリ型並列処理におけるメッセージ交換のためのライブラリであるＭＰＩ（Ｍｅｓｓａｇｅ  Ｐａｓｓｉｎｇ  Ｉｎｔｅｒｆａｃｅ）を代表とするメッセージ交換ライブラリを用いた通信が多用されている。
【０００３】
従来からＰＣクラスタ用のネットワークインタフェースとしては、Ｍｅｌｌａｎｏｘ  Ｔｅｃｈｎｏｌｏｇｉｅｓ社のＩｎｆｉｎｉｂａｎｄ ＨＣＡやＭｙｒｉｃｏｍ社のＭｙｒｉｎｅｔやＱｕａｄｒｉｃｓ社のＱｓＮＥＴ  ＩＩなどが、多くの利用形態でＭＰＩと組み合わせて用いられている（例えば「非特許文献１」参照）。
【０００４】
国内においては、試作レベルの例として、ＲＨｉＮＥＴ−２上にＭＰＩを実装した例が報告されている（例えば「非特許文献２」参照）。また、メモリスロットに装着されるＤＩＭＭｎｅｔ−２上にＭＰＩを実装したものが報告されている（例えば「非特許文献３」参照）。
【０００５】
これらはネットワーク側から受信するデータを、いったんネットワークインタフェース基板上のメモリや、ホストコンピュータ上の主記憶上に設けられたスワップアウト対象外に予約された領域に形成されるバッファに蓄えられるような構造になっている。
【０００６】
ところで、並列システムにおいては、必ずしも受信側がメッセージ到着前に対応する受信関数を起動するという保証はない。また、並列システムにおいては、複数の相手からネットワーク越しに到着するメッセージが、必ずしも受信側が望んだ到着順序で受信側に届く保証はない。このため、上述のＭＰＩなどのメッセージ交換ライブラリでは、受信関数を実行した場合には、まず、Ｕｎｅｘｐｅｃｔｅｄ  ｍｅｓｓａｇｅ  ｑｕｅｕｅと呼ばれるバッファの中から必要なメッセージを探しに行く。そして、受信キーに一致するメッセージを見つけるまで、一致しなかったメッセージを別のバッファに退避する。
【０００７】
上述したＤＩＭＭｎｅｔ−２は、ＩＰＵＳＨ機構というハード的に制御されるポインタによりＦＩＦＯ動作を行う。また、ＤＩＭＭｎｅｔ−２は、送信元グループで分類された受信バッファに書き込む。このような動作により、ＤＩＭＭｎｅｔ−２は、受信側でのファームウェアの介在を防止している。また、ＤＩＭＭｎｅｔ−２においては、バッファ検索成功確率向上によりＭＰＩの通信遅延の短縮を図ることが報告されている（例えば、「非特許文献４」参照）。
【０００８】
一方、ＭＰＩのＵｎｅｘｐｅｃｔｅｄ  ｍｅｓｓａｇｅ  ｑｕｅｕｅ内のメッセージ検索の高速化をハードで支援する従来例が存在する。具体的には、ランダムロジックで比較器とレジスタからなるＡＬＰＵという論理ブロックを構成し、これを大量に並べてシフトレジスタ状に接続し、列の途中からキーにマッチするエントリを引き抜くことができるＵｎｅｘｐｅｃｔｅｄ  ｍｅｓｓａｇｅ  ｑｕｅｕｅを構成することでメッセージ検索の高速化を行っている（例えば、「非特許文献５」参照）。
【０００９】
さらに、ＬＨＳ機構というメッセージの前半と後半を分別して異なる特性を持つメモリに格納して、メッセージの前半にありがちなＭＰＩのマッチングに必要な情報を低遅延でホストに取り込めるようにすることで、ＭＰＩの通信遅延の短縮を図ることが報告されている（例えば、「非特許文献６」参照）。
【００１０】
【非特許文献１】“Ｐｅｒｆｏｒｍａｎｃｅ  ｃｏｍｐａｒｉｓｏｎｓ  ｏｆ  ＭＰＩ  ｉｍｐｌｅｍｅｎｔａｔｉｏｎｓ  ｏｖｅｒ  ＩｎｆｉｎｉＢａｎｄ，  Ｍｙｒｉｎｅｔ  ａｎｄ  Ｑｕａｄｒｉｃｓ”, ＩＥＥＥ  Ｐｒｏｃｅｅｄｉｎｇｓ  ｏｆ  ＳＣ‘０３， （２００３年１１月）
【非特許文献２】“分散並列処理用ネットワークＲＨｉＮＥＴ−２の性能評価”, 先進的計算基盤システムシンポジウムＳＡＣＳＩＳ２００３, ＩＳＳＮ１３４４−０６４０  （２００３年５月）
【非特許文献３】“ＤＩＭＭｎｅｔ−２における通信ライブラリＭＰＩ−２の実現”，情報処理学会計算機アーキテクチャ研究会研究報告ＩＳＳＮ０９１９−６０７２  （２００６年２月）
【非特許文献４】“メッセージパッシングモデルを支援するパケット受信機構の実装”，情報処理学会計算機アーキテクチャ研究会研究報告ＩＳＳＮ０９１９−６０７２  （２００５年１１月）
【非特許文献５】Ｋ. Ｄ. Ｕｎｄｅｒｗｏｏｄ， Ｋ. Ｓ. Ｈｅｍｍｅｒｔ, Ａ． Ｒｏｄｒｉｇｕｅｓ， Ｒ． Ｍｕｒｐｈｙ ａｎｄ Ｒ． Ｂｒｉｇｈｔｗｅｌｌ ： “Ａ Ｈａｒｄｗａｒｅ  Ａｃｃｅｌｅｒａｔｉｏｎ  Ｕｎｉｔ ｆｏｒ ＭＰＩ  Ｑｕｅｕｅ Ｐｒｏｃｅｓｓｉｎｇ”， １９ｔｈ  Ｉｎｔｅｒｎａｔｉｏｎａｌ  Ｐａｒａｌｌｅｌ ａｎｄ  Ｄｉｓｔｒｉｂｕｔｅｄ  Ｐｒｏｃｅｓｓｉｎｇ  Ｓｙｍｐｏｓｉｕｍ  （ＩＰＤＰＳ‘０５）  （２００５年４月）
【非特許文献６】“ＤＩＭＭｎｅｔ−３ネットワークインタフェースにおけるＭＰＩ支援機能”，情報処理学会計算機アーキテクチャ研究会研究報告ＩＳＳＮ０９１９−６０７２  （２００７年３月）
【発明の開示】
【発明が解決しようとする課題】
【００１１】
しかしながら、上述のバッファ検索操作は、例えば非特許文献５のようにハードウェアでサポートをしない限り、ソフトウェアによる大容量のメモリ間のコピーを伴う。したがって、受信側が望んだ順番に所望のメッセージが届かない限りメッセージ受信にかかる遅延時間が大きくなってしまう、という問題がある。
【００１２】
例えば、Ｍｙｒｉｎｅｔ等のようにネットワークインタフェース基板上のメモリ容量が小さい場合は、ＭＰＩの受信バッファ全部を基板上のメモリに搭載できるだけの容量がない。このため、ネットワークから流入するメッセージは速やかにＰＣＩバスなどの入出力バスを経由してホストの主記憶上に吐き出す必要がある。メッセージがネットワークインタフェース基板上に滞っているとネットワーク側が詰まり、輻輳の原因となるためである。メッセージは、ＰＣＩバス等を経由して数回のＤＭＡを繰り返してホストの主記憶に設けられたＭＰＩの受信バッファに常時運ばれるため、通信遅延時間が大きくなってしまう。
【００１３】
また、ＤＩＭＭｎｅｔ−２のようにネットワークインタフェース基板上のメモリがＤＲＡＭベースになっていてホストの主記憶並みに容量が大きい場合は、ネットワーク側からリモートアクセスさせるデータをネットワークインタフェース基板上のメモリに配置することができる。さらに、ＭＰＩの受信バッファ全部をネットワークインタフェース基板上のメモリに配置することができる。このため、受信側がメッセージ到着前に対応する受信関数を起動していない場合はネットワークインタフェース基板上のメモリ上に設けられたＭＰＩバッファに受信メッセージを格納できる。
【００１４】
しかしながら、ネットワークインタフェース基板上のメモリはホストの主記憶よりもホストからのアクセスに時間がかかるため、受信キーに一致するメッセージの検索に時間がかかってしまう。したがって、必ずしもＭＰＩの受信遅延が短くならない、という問題がある。
【００１５】
さらに、非特許文献５に記載されたハードウェアでバッファの検索をサポートする方式のようにＡＬＰＵと呼ばれる回路ブロックをランダムロジックで組み上げた場合には、論理回路の規模が大きくなる、という問題がある。このことはＬＳＩ内のその他の回路やバッファ量を圧迫したり、周波数を制限したり、消費電力が上げるなどの副作用を伴う。さらに、大規模な並列システムにおいては十分な個数のＡＬＰＵをＬＳＩ内に実装することができず、そのあふれをソフトウェア的に救済しなければならないため、その場合、大きな性能低下が発生する。
【００１６】
さらにまた、非特許文献６に記載されたＬＨＳは、メッセージ前半部を格納する１つの低遅延メモリにメッセージが届いた順番に格納されていく。このため、ＭＰＩの受信関数で指定された受信キーと一致しない受信キーを有するメッセージが、一致する受信キーを有するメッセージより先に大量に届いた場合は、先頭から順番に多数回比較していかねばならないため、その場合、大きな性能低下が発生する、という問題がある。
【００１７】
本発明は、上記に鑑みてなされたものであって、受信関数で指定された受信キーと一致する受信キーに係る受信情報を検索する時間を従来に比べて大幅に短縮させることができる通信制御装置および情報処理装置を提供することを目的とする。
【課題を解決するための手段】
【００１８】
上述した課題を解決し、目的を達成するために、本発明の通信制御装置は、情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、受信メッセージまたは受信関数の引数の全部または一部に相当する受信情報を格納する複数の受信バッファと、前記受信メッセージが有している受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、前記受信情報を、前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納する格納手段と、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じて、前記受信情報を前記ハッシュ値に係る前記受信バッファの先頭からバースト転送する出力手段と、を備えることを特徴とする。
【００１９】
また、本発明の通信制御装置は、情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、分散メモリ型並列処理におけるメッセージ交換のためのライブラリが取り扱う受信メッセージの全部または一部を格納する複数の受信バッファと、前記受信メッセージが有している前記受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、前記受信メッセージを、当該受信メッセージが有している前記受信キーから生成された前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納するメッセージ格納手段と、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じて、前記受信関数に応じた前記受信メッセージの一つ以上の候補を、当該受信関数で指定される受信キーから生成される前記ハッシュ値に係る前記受信バッファの先頭からバースト転送するメッセージ出力手段と、を備えることを特徴とする。
【００２０】
また、本発明の通信制御装置は、情報の先入れ先出しを行なうＦＩＦＯ（First  In  First  Out）バッファとして機能し、分散メモリ型並列処理におけるメッセージ交換のためのライブラリで用いられる受信関数の引数の全部または一部に相当する受信要求情報を格納する複数の受信バッファと、受信メッセージが有している受信キーからハッシュ値生成規則に応じてハッシュ値を生成するハッシュ値生成手段と、受信キーの一致判定により受信を行なう受信手段からの前記受信関数に係る受信要求情報を、当該受信関数に係る受信メッセージが届くまで、当該受信関数の前記受信キーから生成された前記ハッシュ値をハード的に制御されるポインタとし、前記複数の受信バッファの中から一の前記受信バッファを選択してエントリとして格納する受信要求格納手段と、前記受信メッセージが届いた場合であって、当該受信メッセージが有している前記受信キーから生成される前記ハッシュ値に係る前記受信バッファ内に前記受信要求情報がある場合、前記受信メッセージをバースト転送するメッセージ出力手段と、を備えることを特徴とする。
【００２１】
また、本発明の情報処理装置は、請求項１ないし８のいずれか一に記載の通信制御装置と、前記通信制御装置が備えるハッシュ値生成手段で用いられるハッシュ値生成規則を有しており、受信関数で指定される受信キーを入力として得られるハッシュ値に基づいて前記通信制御装置の所望の受信バッファに格納されている受信情報を当該通信制御装置から取得するホスト部と、を備える。
【発明の効果】
【００２５】
本発明によれば、受信メッセージが有している受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して受信情報を格納し、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じてハッシュ値に係る受信バッファから受信情報を出力することにより、受信関数で指定された受信キーと一致するか一致しないかで受信情報は別の受信バッファに分別保持されている可能性が高いので、受信関数で指定された受信キーと一致する受信キーに係る受信情報を検索する時間を従来に比べて大幅に短縮させることができる、という効果を奏する。
【００２６】
本発明によれば、受信メッセージが有している受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して受信情報を格納し、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じてハッシュ値に係る受信バッファから受信関数に応じた受信メッセージの一つ以上の候補を出力することにより、受信関数で指定された受信キーと一致する受信キーを有する受信メッセージより先に一致しない受信キーを有する受信メッセージが大量に届いた場合であっても、受信関数で指定された受信キーと一致するか一致しないかで受信メッセージは別の受信バッファに分別保持されている可能性が高いので、受信関数で指定された受信キーと一致する受信キーを有する受信メッセージを検索する時間を従来に比べて大幅に短縮させることができる、という効果を奏する。
【００２７】
本発明によれば、受信キーの一致判定により受信を行なう受信手段からの受信関数に係る受信要求情報を、当該受信関数に係る受信メッセージが届くまで、当該受信関数の受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して格納する。このようにして、受信情報に対するアクセスがし易いように分類された受信バッファ内では受信関数起動順に順序づけられた状態で保持することができる。その結果、受信メッセージが届いた際に、当該受信メッセージが有している受信キーから生成されるハッシュ値に係る受信バッファ内に受信要求情報がある場合、受信キーが一致する受信要求情報（ここに最終的な格納場所が記載されている）を検索する時間の短縮ができ、結果として最終的な格納場所に短い時間で受信メッセージを出力することができる、という効果を奏する。
【発明を実施するための最良の形態】
【００２８】
以下に添付図面を参照して、この発明にかかる通信制御装置、情報処理装置およびプログラムの最良な実施の形態を詳細に説明する。
【００２９】
［第１の実施の形態］
本発明の第１の実施の形態を図１ないし図９に基づいて説明する。本実施の形態は通信制御装置としてＮＩＣ（Network Interface Card）上のＬＳＩ（Large Scale Integration）を適用し、情報処理装置としてＰＣ（Personal Computer）を適用した例である。
【００３０】
図１は、本発明の第１の実施の形態にかかるＰＣクラスタの構成を示す模式図である。図１に示すように、ＰＣクラスタは、複数台のＰＣ（Personal Computer）をネットワークで結合することにより構築した並列計算機の一種である。ＰＣクラスタは、実際に計算を行う複数台の計算ノードとなるＰＣ１と、全体を管理するマスタノードとなるＰＣ２とで構成されている。なお、本実施の形態のＰＣクラスタは、全ての計算ノードとなるＰＣ１がディスクを有しているディスククラスタである。マスタノードとなるＰＣ２と計算ノードとなるＰＣ１とはスイッチングハブ３を介して内部ネットワーク４で接続されており、マスタノードとなるＰＣ２のみが外部ネットワーク５に接続されている。なお、内部ネットワーク４は、コマンド／ＮＦＳ用のみならず、ＭＰＩ（Message Passing Interface）用のネットワークとしても利用される。ＭＰＩは、ＣＰＵ（Central Processing Unit）間でメッセージを交信しながら並列処理を実現する並列ライブラリである。
【００３１】
次に、本実施の形態の特徴である計算ノードとなるＰＣ１について説明する。図２は、ＰＣ１の構成を示すブロック図である。図２に示すように、ＰＣ１は、ＮＩＣ（Network Interface Card）１０と、後述する受信関数で指定される受信キーの一致判定により受信を行なう受信手段として機能するホスト部２０とを備えている。
【００３２】
図３は、ホスト部２０の構成を示すブロック図である。図３に示すように、ホスト部２０は、ＰＣ１における各種処理を実行するものであって、一般的なパーソナルコンピュータと同様に、コンピュータの主要部であって各部を集中的に制御するＣＰＵ（Central Processing Unit）５１を備えている。このＣＰＵ５１には、ＢＩＯＳなどを記憶した読出し専用メモリであるＲＯＭ（Read Only Memory）５２と、ＣＰＵ５１の作業エリアとして機能するＲＡＭ（Random Access Memory）５３とがバス５４で接続されている。さらにバス５４には、各種のプログラム等を格納するＨＤＤ（Hard Disk Drive）５５が、図示しないＩ／Ｏを介して接続されている。ＣＰＵ５１は、このシステムの主記憶装置として使用されるＨＤＤ５５上にロードされたプログラムに基づいて各種処理を実行する。
【００３３】
ＨＤＤ５５に格納されるプログラムは、インストール可能な形式又は実行可能な形式のファイルでＣＤ−ＲＯＭ、フレキシブルディスク（ＦＤ）、ＤＶＤ等のコンピュータで読み取り可能な記録媒体に記録されて提供されてもよい。この場合には、プログラムは、上記記録媒体から読み出して実行することにより主記憶装置であるＨＤＤ５５に上にロードされ、各種処理を実行する各機能構成部が主記憶装置上に生成されるようになっている。また、プログラムを、インターネット等のネットワークに接続されたコンピュータ上に格納し、ネットワーク経由でダウンロードさせることにより提供するように構成してもよい。
【００３４】
ＮＩＣ１０は、コンピュータ間の通信を行うために使用されるハードウェアの１つである。本実施の形態においては、図２に示すように、ＮＩＣ１０は、ＬＳＩ（Large Scale Integration）である通信制御装置１００と第２メモリ２００とを備えている。
【００３５】
第２メモリ２００は、ＤＲＡＭ（Dynamic Random Access Memory）ベースのメモリである。第２メモリ２００は、図２に示すように、ＮＩＣ１０上の通信制御装置１００の外部に設置されている。第２メモリ２００は、通信制御装置１００が備える第１メモリ１６０に比べて大容量であって、かつ、データの転送要求などのリクエストを発してからリクエストの結果が返ってくるまでにかかる遅延時間が長い高遅延のメモリである。
【００３６】
なお、他の例としては、第２メモリ２００は通信制御装置１００の内部に設けられてもよい。また、第２メモリ２００は、ＮＩＣ１０の外部に設けられてもよい。また、ホスト部２０の主記憶上に形成されてもよい。さらに、第２メモリ２００は、ＤＲＡＭベース以外の構成であってもよい。
【００３７】
図２に示すように、通信制御装置１００は、ネットワーク制御部１１０と、分割制御部１２０と、設定部１３０と、第１メモリ制御部１４０と、第２メモリ制御部１５０と、第１メモリ１６０と、ホストインタフェース部１７０と、プリフェッチバッファ１８０と、ハッシュ値生成部１９０とを備えている。
【００３８】
ネットワーク制御部１１０は、フロー制御や再送制御などのＯＳＩ参照モデルにおけるトランスポート層以下の層での処理を行う。ネットワーク制御部１１０は、内部ネットワーク４からメッセージを受信し、受信メッセージ（受信情報）として取得する。そして、受信したメッセージ、すなわち受信メッセージの誤りを検出して訂正し、誤りのない受信メッセージを分割制御部１２０に渡す。
【００３９】
分割制御部１２０は、分割位置レジスタ１２２と、サイズ位置レジスタ１２４と、キー位置レジスタ１２６とを有しており、受信メッセージを分割する。
【００４０】
分割位置レジスタ１２２は、受信メッセージの分割位置情報を保持している。分割位置情報とは、受信メッセージを分割する場合の分割位置を示す情報である。分割位置情報は、具体的には、先頭から何バイトの位置という情報である。
【００４１】
サイズ位置レジスタ１２４は、受信メッセージのサイズ位置情報を保持している。サイズ位置情報とは、受信メッセージにおいて、当該受信メッセージのデータサイズを示すサイズ情報が格納されている位置を示す情報である。
【００４２】
キー位置レジスタ１２６は、受信メッセージのキー位置情報を保持している。ここで、キー位置情報とは、受信メッセージにおいて、受信キーが格納されている位置に関する情報である。キー位置情報は、具体的には、例えば先頭から何バイトの位置という情報である。受信キーとは、受信関数で指定され、当該受信メッセージを受信するか否かを一致比較によって判定するための情報である。例えば、受信キーとは、ＭＰＩにおいては受信関数MPI_Irecv（）の引数であるｔａｇ（メッセージタグ）やｃｏｍｍ（コミュニケータ）やｓｏｕｒｃｅ（送信元のランク）が相当し、受信メッセージの前半メッセージに格納されているエンベロープ（ｅｎｖｅｌｏｐｅ）と呼ばれる部分に含まれる情報である。
【００４３】
このような構成により、分割制御部１２０は、分割位置レジスタ１２２に保持されている分割位置情報およびサイズ位置レジスタ１２４に保持されているサイズ位置情報を利用して、適宜、受信メッセージを前半メッセージと後半メッセージとに分割する。本実施の形態にかかる分割制御部１２０は、分割手段として機能する。
【００４４】
分割制御部１２０は、さらに前半メッセージを第１メモリ制御部１４０に渡し、後半メッセージを第２メモリ制御部１５０に渡す。なお、分割制御部１２０は、比較的容量の小さい受信メッセージ、すなわち分割する必要のない小受信メッセージも、第１メモリ制御部１４０に渡す。
【００４５】
ここで、前半メッセージは、ホスト部２０が受信処理においてはじめに利用すべきデータを含んでいる。ここで、受信処理とは、内部ネットワーク４から受信メッセージを取得した際に行う処理である。例えばＭＰＩにおいては、受信処理においてはじめに受信関数によって指定された受信キーとエンベロープとが一致するか否かが判定される。すなわち、エンベロープは、受信処理においてはじめに利用される情報である。前半メッセージまたは小受信メッセージは、はじめに利用すべきデータとしてエンベロープを含んでいる。後半メッセージは、受信メッセージのうち前半メッセージ以外の部分である。
【００４６】
また、分割制御部１２０は、受信メッセージ（前半メッセージまたは小受信メッセージ）中のエンベロープの受信キーをハッシュ値生成部１９０に渡す。
【００４７】
ハッシュ値生成部１９０は、分割制御部１２０から入力される受信キーから所定のハッシュ関数（ハッシュ値生成規則）によりハッシュ値を生成し、生成したハッシュ値を第１メモリ制御部１４０と第２メモリ制御部１５０とに対して出力する。本実施の形態にかかるハッシュ値生成部１９０は、ハッシュ値生成手段として機能する。
【００４８】
設定部１３０は、ユーザからの指示等により分割位置情報を分割位置レジスタ１２２に設定する。これにより、分割位置を調整することができる。また、サイズ位置情報をサイズ位置レジスタ１２４に設定する。これにより、受信可能なメッセージのフォーマットを柔軟に変更することができる。すなわち、多様なフォーマットのメッセージを処理対象とすることができる。
【００４９】
なお、分割位置レジスタ１２２、サイズ位置レジスタ１２４、キー位置レジスタ１２６および設定部１３０は、必ずしも必須の構成ではない。他の例としては、分割位置情報およびサイズ位置情報およびキー位置情報として、適切な固定値を予め設定しておくこととしてもよい。
【００５０】
第１メモリ１６０は、第２メモリ２００に比べて小容量であって、かつ、データの転送要求などのリクエストを発してからリクエストの結果が返ってくるまでにかかる遅延時間が短い低遅延のメモリである。第１メモリ１６０は、典型的にはＬＳＩに内蔵される高速ＳＲＡＭである。
【００５１】
例えば、ＭＰＩのシステムバッファ全体を通信制御装置１００に設置するのは容量的に困難である。しかし、第１メモリ１６０は必ずしもＬＳＩ内蔵でなければならないというものではない。そこで、本実施の形態においては、第１メモリ１６０と第２メモリ２００という容量や遅延の異なる２種類のメモリをメッセージ交換の高速化という観点で使い分けている。
【００５２】
第１メモリ１６０は、複数のエントリを保持可能なバッファを有している。受信メッセージ（前半メッセージなど）を受信したにも関わらずそのメッセージを受信するべき受信関数がホスト部２０からコールされていない場合には、受信関数がコールされるまで受信メッセージ（前半メッセージ）をバッファリングしておく必要がある。このように受信関数がコールされるまで受信メッセージ（前半メッセージなど）をバッファリングするためのキューは、Unexpected message queueと呼ばれている。すなわち、第１メモリ１６０に形成される複数のバッファは、ＭＰＩ用に用いられる場合において、受信キーが一致する受信関数をコールする前に届いてしまった受信メッセージ（前半メッセージなど）を一時的に格納するバッファである。本実施の形態においては、Unexpected message queueにより受信メッセージ（前半メッセージなど）を一時的に格納する受信バッファを、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４と称している。
【００５３】
第１メモリ制御部１４０は、小容量かつ低遅延である第１メモリ１６０を制御する。具体的には、分割制御部１２０から受け取った前半メッセージまたは小受信メッセージの全体を第１メモリ１６０に格納する。また、第１メモリ制御部１４０は、第１メモリ１６０に格納されているデータを読み出し、ホストインタフェース部１７０に渡す。
【００５４】
このように、前半メッセージまたは小受信メッセージを小容量かつ低遅延である第１メモリ１６０に格納することにより、大容量かつ高遅延である第２メモリ２００に格納する場合に比べて少ない遅延で前半メッセージや小受信メッセージをホスト部２０に提供することができる。
【００５５】
また、第２メモリ２００は、第１メモリ１６０に格納しきれなかったデータを格納する。具体的には、受信メッセージのうち後半メッセージを格納する。第１メモリ１６０と同様に、第２メモリ２００も、複数のエントリを保持可能なバッファを有している。このバッファは、ＭＰＩ用に用いられる場合において、受信キーが一致する受信関数をコールする前に届いてしまった受信メッセージ（後半メッセージ）を一時的に格納するバッファである。本実施の形態においては、Unexpected message queueにより受信メッセージ（後半メッセージ）を一時的に格納するバッファを、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４と称している。
【００５６】
第２メモリ制御部１５０は、大容量かつ高遅延である第２メモリ２００を制御する。具体的には、分割制御部１２０から受け取った後半メッセージを第２メモリ２００に格納する。また、第２メモリ制御部１５０は、第２メモリ２００に格納されているデータを読み出し、ホストインタフェース部１７０またはプリフェッチバッファ１８０に渡す。
【００５７】
ここで、第１メモリ１６０および第２メモリ２００のデータ構造について図４を参照して説明する。
【００５８】
図４に示すように、第１メモリ１６０のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４は、前半メッセージまたは小受信メッセージの全体をエントリとして保持する。前半メッセージは、後続ポインタ（図４で点線で示されるアドレス情報）とともに同一のエントリに格納される。ここで、後続ポインタとは、前半メッセージに続く後半メッセージのアドレスを示す情報である。
【００５９】
第１メモリ１６０上のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４は、第１メモリ制御部１４０によりリング状に管理される。つまり、第１メモリ１６０上のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４は、先入れ先出しバッファ（ＦＩＦＯ）として機能するリングバッファである。すなわち、第１メモリ制御部１４０は、使用中領域（図４で網掛けで示されるメモリ領域）の先頭ポインタ（図４において一点鎖線で示されるアドレス情報）と末尾ポインタ（図４において鎖線で示されるアドレス情報）を保持している。先頭ポインタや末尾ポインタはランダムロジックのレジスタ上に格納しても良いし、大規模化に対応するならばメモリ上に格納しても良い。
【００６０】
なお、前半メッセージまたは小受信メッセージの全体は、ハッシュ値生成部１９０により生成されるハッシュ値によって選択されるリングバッファ（Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４の何れか）にエントリとして格納される。ここに、メッセージ格納手段および格納手段の機能が実行される。
【００６１】
また、リングバッファ（Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４の何れか）に前半メッセージまたは小受信メッセージの全体を書き込む処理は、例えば、ＩＰＵＳＨ機構を用いることによりハードウェアで実現することができる。ＩＰＵＳＨ機構については、非特許文献４に記載されている。
【００６２】
さらに、各エントリのデータサイズは予め定められている。例えば、エントリのデータサイズは、３２バイトである。エントリのデータサイズは、ホスト部２０のＣＰＵ５１のラインサイズに対応して決定される。ホスト部２０にできるだけ早くデータを送る観点からは、第１メモリ１６０になるべく多くのデータを格納することが望ましい。しかし、各エントリのデータサイズを大きくした場合には、空きが問題となる。このようなトレードオフに伴う実行性能最適点をエントリのデータサイズとするのが望ましい。
【００６３】
さらにまた、エントリのデータサイズは、エンベロープなどの制御情報が必ず含まれるようなデータサイズとすることが望ましい。さらには、例えば制御などに用いられるメッセージのように比較的容量の小さい小受信メッセージの全体を格納可能なデータサイズとすることが望ましい。これにより、エンベロープを含むエントリをホスト部２０に転送するのと同時にこの小受信メッセージのデータ部もホスト部２０に転送される。
【００６４】
このような小受信メッセージは、遅延時間が短いことが要求されるデータである場合が多い。内部ネットワーク４から長いメッセージを受信した後にこのような小受信メッセージを受信した場合でも、ホスト部２０は、小受信メッセージを先に要求する場合が多い。上述のように、小受信メッセージを第１メモリ１６０に格納することにより低遅延で転送することができる。
【００６５】
また、後続ポインタのデータサイズも予め定められている。例えば、４バイトである。この場合、各エントリに格納される前半メッセージのデータサイズは、エントリのデータサイズ３２バイトからポインタのデータサイズ４バイトを差し引いた残りのデータサイズ、すなわち２８バイトである。そこで、分割位置レジスタ１２２には、分割位置として、先頭から２８バイトを示す分割位置情報が格納されている。
【００６６】
小受信メッセージは、図４に示すＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６３の先頭に格納されているエントリのように、後半メッセージが無く、受信メッセージの全体がエントリに格納される。この場合には、ポインタを格納する必要がない。このため、エントリのデータサイズ３２バイト以下であれば、前半メッセージのデータサイズ２８バイトよりも大きいデータであっても格納することができる。
【００６７】
一方、第２メモリ２００上のＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４も、図４に示すように、第２メモリ制御部１５０によりリング状に管理される。より詳細には、第２メモリ２００には、エントリサイズが可変長のＦＩＦＯの構造を有したリングバッファが複数形成され、後半メッセージはハッシュ値生成部１９０により生成されるハッシュ値によって選択されるリングバッファ（Ｕｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４の何れか）にエントリとして格納される。
【００６８】
上述したように、本実施の形態においては、第１メモリ制御部１４０は、第１メモリ１６０のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４の１つをそのメッセージの一時格納場所としている。また、第２メモリ制御部１５０は、このハッシュ値入力に対応する、第２メモリ２００上のＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４の１つをそのメッセージの一時格納場所としている。
【００６９】
ここで、受信メッセージの一時格納場所として、第１メモリ１６０の上に例えば４個の上のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４を形成する場合、および、第２メモリ２００上に４個のＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４を形成する場合においては、ハッシュ値生成部１９０は、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４およびＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４の１つを特定できる情報、すなわち実質２ビットの情報を上記のハッシュ値として出力する。
【００７０】
なお、本実施の形態においては、Ｕｎｅｘｐｅｃｔｅｄ受信バッファの個数は４個としているが、必ずしも４個である必要は無く、キーが一致するメッセージの検索に要するＵｎｅｘｐｅｃｔｅｄ受信バッファの読み出し回数が少なくなる確率が高くなるため、性能の観点からは、この個数は第１メモリ１６０に割り当てられるメモリ容量や第１メモリ制御部１４０に保持できるポインタなどのバッファ管理情報の記憶容量が許す範囲で多い方が良い。
【００７１】
また、ＭＰＩにおいては送信元が同じメッセージは先に送信されたメッセージが先に届くようにする必要があるため、個々のＵｎｅｘｐｅｃｔｅｄ受信バッファは先入れ先出しバッファ（ＦＩＦＯ）として動作するように制御されることが望ましい。よって、内部ネットワーク４から受信されるメッセージのエンベロープ上のｓｏｕｒｃｅ（送信元のランク）およびｃｏｍｍ（コミュニケータ）が同一ならば上記ハッシュ関数は同じハッシュ値を出力するようにすることにより、それらは同じＵｎｅｘｐｅｃｔｅｄ受信バッファに格納される。したがって、ＦＩＦＯ制御されたＵｎｅｘｐｅｃｔｅｄ受信バッファの先頭から読み出していけば、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４中に滞在するキーが一致するメッセージのうちで一番先に送信されたものを先に読み出せるようになる。よって、ＭＰＩにおいてはｓｏｕｒｃｅとｃｏｍｍをハッシュ値生成部１９０の入力とすることが望ましい。しかし、ｃｏｍｍ（コミュニケータ）は１種類しか用いないアプリケーションも多いので、実用的にはｓｏｕｒｃｅをハッシュ値生成部１９０の入力とすることが望ましい。
【００７２】
図２に戻り、プリフェッチバッファ１８０は、第２メモリ制御部１５０を介して第２メモリ２００から後半メッセージを取得し、格納する。また、プリフェッチバッファ１８０は、後半メッセージをホストインタフェース部１７０に渡す。なお、ホストインタフェース部１７０に渡された後半メッセージは、プリフェッチバッファ１８０から削除される。
【００７３】
ホストインタフェース部１７０は、受信関数をコールしたホスト部２０からの送信要求に応じて、第１メモリ１６０上の当該受信関数に応じた前半メッセージをホスト部２０に渡す。本実施の形態にかかるホストインタフェース部１７０は、メッセージ出力手段および出力手段として機能する。ホスト部２０は、受信関数の受信キーに対応した前半メッセージに対応する後半メッセージの格納場所（後続ポインタ）を検索する。次に、ホスト部２０はその場所（後続ポインタ）に対応する第２メモリ２００またはプリフェッチバッファ１８０上にある受信メッセージ（後半メッセージ）を、ホストインタフェース部１７０を介してアクセスする。
【００７４】
一方、ホスト部２０では、ＣＰＵ５１で実行されるプログラム（例えば、ＭＰＩのシステム）が上記のハッシュ値生成部１９０で用いられるハッシュ関数を共有していて、受信関数（例えば、MPI_Irecv（））をコールした時に引数として指定された受信キーを入力として上記のハッシュ関数を実行し、ハッシュ値を得ることができる。これにより、ホスト部２０は、上記の仕組みによって、受信関数によって受信されるべきメッセージが第１メモリ１６０上のどのＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４に格納されているのかを知ることができる。
【００７５】
ところで、ＭＰＩなどの２ｓｉｄｅｄな通信であるメッセージパッシングモデルに基づく通信ライブラリを実装する際には、受信側で受信したいメッセージと受信側ノードへのメッセージ到着順序が必ずしも一致しない、という問題がある。
【００７６】
従来の手法（例えば、特許文献１参照）によれば、ホスト部２０による第１メモリ１６０上のエンベロープ部分の読み出しと比較を受信キーが一致するまで繰り返すことにより、受信キーが一致するメッセージをＵｎｅｘｐｅｃｔｅｄ受信バッファから検索することができるようにしている。しかしながら、例えばNAS  Parallel  Benchmarks（ＮＰＢ）のＦＴやＩＳなどにおいては、ノード数に近い多くのメッセージがＵｎｅｘｐｅｃｔｅｄ受信バッファに滞留するため、その検索時間の増加により通信遅延が増加する。よって、多くのノード数からなる並列システム上でＮＰＢ  ＦＴやＩＳを実行すると、図５に示されるように、大量の先着メッセージの中から所望のメッセージＢを掘り出さねばならない状況が発生する。この場合のメッセージＢの検索時間は先に届いた「全ての」メッセージのエンベロープ部転送時間とキー比較時間の総和となる。図５に示す例では、受信メッセージａ→ｂ→…→ｋ→Ａ→ｌ→ｍ→…→ｙ→Ｂの順序でメッセージが到着したとする。この状態において、ホスト部２０が受信メッセージＢを受信する関数を実行したとする。この場合には、従来の処理においては、メッセージＢより先に届いた２８個の受信メッセージのｅｎｖｅｌｏｐｅを元にＭＰＩの処理系は受信バッファからメッセージＢを先頭から順番に検索して抽出することになる。
【００７７】
これに対して、本実施の形態においては、上述のように、エンベロープがホスト部２０から低遅延でアクセスできる第１メモリ１６０に形成された複数のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４にハッシュ値に基づいて分類されて先入れ先出しの順序を保持した状態で保持されている。
【００７８】
ホスト部２０は、ホストインタフェース部１７０と第１メモリ制御部１４０を介して、第１メモリ１６０に形成されたＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４を先頭から読み出し、受信関数で指定した受信キーと一致するまで読み出しと比較を繰り返す。
【００７９】
図６に示す例においては先着のメッセージＡと後着のメッセージＢのエンベロープ中の受信キーが同じハッシュ値に対応するため、図６に示すようなハッシュ値計算時間に加えて、同一のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４内に滞留するメッセージＡのエンベロープを読み出して受信キーを比較して不一致を検出する時間と、再び先ほど計算したハッシュ値に対応するＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４を読み出して受信キーを比較して一致を検出する時間と、を加えたものがメッセージＢを受信する際の検索に要する時間となる。より詳細には、図６に示すように、メッセージＡおよびメッセージＢ以外のメッセージは全て別のハッシュ値を持つため別のＵｎｅｘｐｅｃｔｅｄ受信バッファに格納されるため、従来の方法で消費されていたこれらのメッセージに関わる処理の時間がメッセージＢの受信時にはかからなくなるため大幅な高速化が期待できる。例えば、図６に示すように、受信メッセージａ→ｂ→…→ｋ→Ａ→ｌ→ｍ→…→ｙ→Ｂの順序でメッセージが到着し、メッセージＡとメッセージＢが同じハッシュ値３に対応したとする。この場合、これらはメッセージＡ、メッセージＢの順序で同一のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６３に格納される。したがって、図６に示すように、ホスト部２０がハッシュ関数を計算してハッシュ値３を得て、ハッシュ値３に対応するＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６３から受信メッセージＡ，Ｂのエンベロープを取得するだけで、メッセージＢのエンベロープを抽出することができる。したがって、ホスト部２０が受信メッセージＢを検索するまでの遅延時間を大幅に短縮させることができる。
【００８０】
ここで、図７は通信制御装置１００によるメッセージ受信処理を示すフローチャートである。ネットワーク制御部１１０が内部ネットワーク４を介してメッセージを受信すると（ステップＳ１０１のＹｅｓ）、分割制御部１２０は、受信したメッセージ、すなわち受信メッセージを前半メッセージと後半メッセージとに分割し（ステップＳ１０２）、前半メッセージ（または小受信メッセージ）を第１メモリ制御部１４０に渡し（ステップＳ１０３）、後半メッセージを第２メモリ制御部１５０に渡す（ステップＳ１０４）。
【００８１】
また、ハッシュ値生成部１９０は、分割された前半メッセージ（または小受信メッセージ）のハッシュ値を生成して第１メモリ制御部１４０に渡すとともに（ステップＳ１０５）、後半メッセージのハッシュ値を生成して第２メモリ制御部１５０に渡す（ステップＳ１０６）。
【００８２】
そして、第１メモリ制御部１４０は、前半メッセージ（または小受信メッセージ）をハッシュ値に応じて第１メモリ１６０上のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４のいずれかに分類して格納する（ステップＳ１０７）。
【００８３】
また、第２メモリ制御部１５０は、後半メッセージをハッシュ値に応じて第２メモリ２００上のＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４のいずれかに分類して格納する（ステップＳ１０８）。
【００８４】
以上により、通信制御装置１００によるメッセージ受信処理が完了する。
【００８５】
次に、通信制御装置１００からホスト部２０への受信メッセージ転送処理について説明する。図８は、ホスト部２０の機能構成を示すブロック図である。ホスト部２０は、ＣＰＵ５１がＨＤＤ５５上にロードされたプログラムに従うことにより、受信メッセージ要求部２０１と、後半メッセージ要求部２０２と、キャッシュメモリ２０４と、制御情報管理部２０６とを備えている。
【００８６】
受信メッセージ要求部２０１は、所定のアドレスのデータがキャッシュメモリ２０４に存在しない場合には、通信制御装置１００に対し、アドレスを指定して受信メッセージの要求を行う。そして、通信制御装置１００から前半メッセージまたは小受信メッセージを取得し、キャッシュメモリ２０４に格納する。なお、受信メッセージ要求部２０１は、キャッシュラインサイズで前半メッセージまたは小受信メッセージを取得する。後半メッセージ要求部２０２は、通信制御装置１００に対し後半メッセージの要求を行う。そして、通信制御装置１００から後半メッセージを取得する。
【００８７】
制御情報管理部２０６は、受信メッセージ要求部２０１が取得した前半メッセージまたは小受信メッセージに含まれる制御情報、すなわちエンベロープを抽出する。そして、受信関数によって指定された受信キーと一致することを確認する。これにより、このメッセージを受信するか否かを検査する。
【００８８】
制御情報管理部２０６は、さらに受信メッセージ要求部２０１が取得したデータが前半メッセージである場合に、後半メッセージ要求部２０２に対し後半メッセージの要求を指示する。なお、取得したデータが前半メッセージであるか否かは、前半メッセージ中に格納されているサイズ情報が示すデータサイズがこの前半メッセージのデータサイズよりも大きいか否かにより判定する。
【００８９】
後半メッセージ要求部２０２は、通信制御装置１００に対して、後半メッセージの要求を行う。そして、通信制御装置１００から後半メッセージを取得する。
【００９０】
ホスト部２０は、キャッシュベースのシステムである。したがって、ホスト部２０のキャッシュミスヒットやプリフェッチ命令に伴うアクセスにより第１メモリ１６０に格納されている前半メッセージや小受信メッセージがホスト部２０にバースト転送される。これにより、低遅延かつ高バンド幅での転送が可能になる。
【００９１】
図９は、通信制御装置１００からホスト部２０への受信メッセージ転送処理を示すフローチャートである。図７に示すメッセージ受信処理により通信制御装置１００が内部ネットワーク４を介して受信したメッセージをホスト部２０からの要求によりホスト部２０に提供する際の処理である。
【００９２】
まず、ホスト部２０の受信メッセージ要求部２０１は、受信メッセージ要求を通信制御装置１００に送る（ステップＳ２００）。通信制御装置１００においては、ホストインタフェース部１７０が受信メッセージ要求を受け取ると、第１メモリ制御部１４０は、ハッシュ値に応じてホスト部２０により指定されている第１メモリ１６０のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４の何れかに格納されているデータを読み出す（ステップＳ２０２）。具体的には、小受信メッセージまたは前半メッセージを読み出す。次に、ホストインタフェース部１７０は、読み出したデータをホスト部２０に送信する（ステップＳ２０４）。
【００９３】
このとき、例えば、エントリに、前半メッセージとともに後半メッセージが存在することを示すフラグを格納しておき、フラグの有無から後半メッセージの有無を判断するようにする。
【００９４】
そして、後半メッセージがある場合には（ステップＳ２１０のＹｅｓ）、第２メモリ制御部１５０は、第メモリ２００からポインタに示される後半メッセージを読み出す（ステップＳ２１２）。そして、読み出した後半メッセージをプリフェッチバッファ１８０に格納する（ステップＳ２１４）。
【００９５】
ホスト部２０においては、受信メッセージ要求部２０１は、前半メッセージまたは小受信メッセージを取得し、これらのデータをキャッシュメモリ２０４に格納する。このとき、制御情報管理部２０６は、データからエンベロープを抽出する。そして、受信関数によって指定された受信キーと一致することを確認する。そして、一致が確認できたデータが前半メッセージであるか否か、すなわち後半メッセージがあるか否かを判定する。
【００９６】
ステップＳ２０２において、前半メッセージの後続ポインタにより後半メッセージがあると判断した場合には（ステップＳ２２０のＹｅｓ）、後半メッセージ要求部２０２は、後半メッセージ要求を通信制御装置１００に送る（ステップＳ２２２）。
【００９７】
通信制御装置１００のホストインタフェース部１７０は、要求されている後半メッセージがプリフェッチバッファ１８０に存在する場合には（ステップＳ２３０のＹｅｓ）、プリフェッチバッファ１８０から後半メッセージを読み出す（ステップＳ２３２）。一方、要求されている後半メッセージがプリフェッチバッファ１８０に存在しない場合には（ステップＳ２３０のＮｏ）、第２メモリ制御部１５０を介して第２メモリ２００から後半メッセージを読み出す（ステップＳ２３４）。
【００９８】
なお、プリフェッチバッファ１８０に後半メッセージが存在しない場合としては、ホストが高速でプリフェッチが追いつかなかった場合や、後半メッセージがプリフェッチバッファ１８０に一旦格納されたが、後半メッセージ要求を取得したときには、空き容量不足で既に削除されていた場合が考えられる。また、プリフェッチバッファ１８０が新たなデータを書き込む分の空きがない場合には、書き込まない構造である場合には、後半メッセージが書き込まれなかった場合が考えられる。
【００９９】
次に、ホストインタフェース部１７０は、後半メッセージをホスト部２０に送信する（ステップＳ２３６）。以上で、受信メッセージ転送処理が完了する。
【０１００】
以上のように、ホスト部２０から要求されたデータに対応する後半メッセージが第２メモリ２００に格納されている場合には、ホスト部２０から後半メッセージの要求を取得する前に予めホスト部２０への転送にかかる遅延の比較的小さいプリフェッチバッファ１８０に後半メッセージを読み出しておく。これにより、ホスト部２０から後半メッセージを要求された際に後半メッセージがプリフェッチバッファ１８０に存在する確率を高めることができる。したがって、低遅延で後半メッセージをホスト部２０に転送することができる。
【０１０１】
これにより、ホスト部２０における後半メッセージを有する受信メッセージの受信遅延を短縮することができる。さらに、小容量の第１メモリ１６０には全体を格納することができないが、遅延のバンド幅への影響が大きい中程度のデータサイズの受信メッセージにおけるバンド幅を向上させることができる。
【０１０２】
このように本実施の形態によれば、受信メッセージが有している受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して受信情報を格納し、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じてハッシュ値に係る受信バッファから受信情報を出力することにより、受信関数で指定された受信キーと一致するか一致しないかで受信情報は別の受信バッファに分別保持されている可能性が高いので、受信関数で指定された受信キーと一致する受信キーに係る受信情報を検索する時間を従来に比べて大幅に短縮させることができる、という効果を奏する。
【０１０３】
より詳細には、受信メッセージが有している受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して受信情報を格納し、受信関数で指定される受信キーの一致判定により受信を行なう受信手段からの送信要求に応じてハッシュ値に係る受信バッファから受信関数に応じた受信メッセージの一つ以上の候補を出力することにより、受信関数で指定された受信キーと一致する受信キーを有する受信メッセージより先に一致しない受信キーを有する受信メッセージが大量に届いた場合であっても、受信関数で指定された受信キーと一致するか一致しないかで受信メッセージは別の受信バッファに分別保持されている可能性が高いので、受信関数で指定された受信キーと一致する受信キーを有する受信メッセージを検索する時間を従来に比べて大幅に短縮させることができる、という効果を奏する。
【０１０４】
また、このような効果の実現においては、ハードウェア量が多くなりがちな連想メモリ（ＣＡＭ）や、ＡＬＰＵのような滞留可能メッセージ数に比例する分量のランダムロジックを用いないので、少ないハードウェア量で大量の滞留可能メッセージ数に対応可能になる、という効果を奏する。
【０１０５】
なお、本実施の形態においては、第１メモリ１６０においては、エンベロープを含む３２バイトのデータを前半メッセージとして格納したが、これに限るものではなく、エンベロープのみを格納することとしてもよい。すなわち、１つのエントリには、エンベロープと、受信メッセージの内、エンベロープ以外の部分を含むデータを格納する第２メモリ２００のアドレスを示すポインタと、を格納する。
【０１０６】
この場合には、分割制御部１２０は、受信メッセージのデータサイズがエントリのデータサイズに比べて大きい場合には、前半メッセージと後半メッセージとに分割する処理にかえて、エンベロープのみを抽出する。そして、エンベロープを第１メモリ制御部１４０に渡し、残りのデータを第２メモリ制御部１５０に渡す。
【０１０７】
また、ハッシュ値生成部１９０は、ハッシュ値生成規則を変更できるようになっていても良い。最も単純なハッシュ値生成規則の例として、２のＮ乗個のバッファを切り替える場合にはエンベロープ中のｓｏｕｒｃｅの最下位Ｎビットをそのままハッシュ値とすることもできる。
【０１０８】
しかし、その規則では並列システムの結合トポロジーやアプリケーションの通信パターンによっては偏ったハッシュ値が出力される頻度が高くなり、複数のバッファに分類することで得られる効果が薄れてしまう可能性がある。このような状況における解決策として、例えばハッシュ値生成部１９０は複数のハッシュ値生成規則を内在して、設定部１３０からの入力により、そのうちの一つを選択的に使用したり、ハッシュ値生成用のパラメータ等を変更したりすることにより、より適切なハッシュ値を得られるようにすることが可能になる。すなわち、設定部１３０は、変更手段および規則変更手段として機能する。
【０１０９】
また、設定部１３０からの入力だけでなく、受信メッセージ内にハッシュ値生成規則を指定する情報を設け、その情報からハッシュ値生成規則を選択することにより、アプリケーションごとに適切なハッシュ値を得られるようにすることが可能になる。
【０１１０】
なお、本実施の形態においては、通信制御装置１００をＬＳＩ（Large Scale Integration）で構成したが、これに限るものではなく、通信制御装置１００を必ずしもハードワイヤドロジックで実現しなくても良い。例えば、ホスト部２０上のＣＰＵ５１をプログラムで動作させることにより、通信制御装置１００の機能の全部または一部が実現されていても良い。
【０１１１】
［第２の実施の形態］
次に、本発明の第２の実施の形態を図１０および図１１に基づいて説明する。なお、前述した第１の実施の形態と同じ部分は同じ符号で示し説明も省略する。
【０１１２】
図１０は、本発明の第２の実施の形態にかかるＰＣ１の構成を示すブロック図である。第１の実施の形態においては、第１メモリ１６０上に形成されてハッシュ値によって制御されるＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４に、分割制御部１２０から受け取った前半メッセージまたは小受信メッセージの全体を第１メモリ１６０に格納するようにした。本実施の形態においては、ハッシュ値によって制御されるバッファは必ずしも複数のＵｎｅｘｐｅｃｔｅｄ受信バッファでなくても良く、図１０に示すように、格納部である第１メモリ１６０上に形成される複数のＰｏｓｔｅｄ受信要求バッファ３６１〜３６４を、ハッシュ値によって制御される受信バッファとしている。なお、個々のＰｏｓｔｅｄ受信要求バッファは先入れ先出しバッファ（ＦＩＦＯ）として動作するように制御されることが望ましい。
【０１１３】
ここで、Ｐｏｓｔｅｄ受信要求バッファとは、ＭＰＩにおいて受信キーが一致するメッセージが届いていない状態で受信関数が先にコールされた場合にその受信キーや受信時のメッセージ格納先などの受信関数の引数として与えられる受信要求情報（受信情報）を保持しておくバッファである。このバッファに格納される場合、メッセージ本体は届いていないのでＰｏｓｔｅｄ受信バッファには後半部は不要である。ここに、受信要求格納手段および格納手段の機能が実行される。
【０１１４】
ここで、先行受信要求検索部３１０は、受信メッセージの受信キーとハッシュ値を受信メッセージ分割制御部１２０やハッシュ値生成部１９０から受け取り、Ｐｏｓｔｅｄ受信要求バッファ３６１〜３６４のいずれかからハッシュ値に対応するものを選択して受信キーが一致する先行受信要求があるかどうかを検索する。
【０１１５】
先行受信要求検索部３１０は、最短通信遅延短縮の観点からはハードワイヤドロジックで実現されている方が望ましいが、必ずしもハードワイヤドロジックで実現されていなくても良い。また、本実施の形態においては、先行受信要求検索部３１０は、通信制御装置１００上に配置しているが、必ずしも通信制御装置１００上に配置しなくても良い。例えば、ホスト部２０上のＣＰＵ５１をプログラムで動作させることにより、先行受信要求検索部３１０の機能の全部または一部が実現されていても良い。本実施の形態の場合は、先行受信要求検索部３１０へのメッセージ出力手段は第１メモリ制御部１４０となる。一方、先行受信要求検索部３１０がホスト部２０上のプログラムで動作する場合、メッセージ出力手段はホストインタフェース部１７０となる。
【０１１６】
ここで、図１１は通信制御装置１００によるメッセージ受信処理を示すフローチャートである。ネットワーク制御部１１０が内部ネットワーク４を介してメッセージを受信すると（ステップＳ１０１のＹｅｓ）、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４の検索前に、先行受信要求検索部３１０が、第１メモリ制御部１４０を介してＰｏｓｔｅｄ受信要求バッファ３６１〜３６４内に、受信したメッセージに対応する受信要求情報があるか否かを検索する（ステップＳ２０１）。
【０１１７】
先行受信要求検索部３１０による判定の結果、Ｐｏｓｔｅｄ受信要求バッファ３６１〜３６４内に受信キーが一致するエントリがある場合は（ステップＳ２０２のＹｅｓ）、ホストインタフェース部１７０が、分割制御部１２０中で滞留している受信したメッセージのペイロード部を、プリフェッチバッファ１８０経由でホスト部２０へ送信する（ステップＳ２０３）。ここに、メッセージ出力手段および出力手段の機能が実行される。その際、ホストインタフェース部１７０がホスト部２０の主記憶にＤＭＡ転送する機能を有するならば、先行受信要求検索部３１０にあるペイロード部を書き込むべきアドレスやそのデータサイズを用いてペイロード部をＤＭＡ転送しても良い。また、ＤＭＡ転送機能が無い場合には、ホスト部２０に割り込みをかけたり、ホスト部２０からリードできるステータスフラグを変更するなどしてホスト部２０にメッセージ到着を通知し、ホスト部２０上のプログラムによってホスト部２０の主記憶にペイロード部のコピーを行なうようにしたりしても良い。
【０１１８】
一方、一致するエントリがない場合には（ステップＳ２０２のＮｏ）、Ｕｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４に受信メッセージが格納されるように制御される。すなわち、分割制御部１２０は、受信したメッセージ、すなわち受信メッセージを前半メッセージと後半メッセージとに分割し（ステップＳ１０２）、前半メッセージ（または小受信メッセージ）を第１メモリ制御部１４０に渡し（ステップＳ１０３）、後半メッセージを第２メモリ制御部１５０に渡す（ステップＳ１０４）。
【０１１９】
また、ハッシュ値生成部１９０は、分割された前半メッセージ（または小受信メッセージ）のハッシュ値を生成して第１メモリ制御部１４０に渡すとともに（ステップＳ１０５）、後半メッセージのハッシュ値を生成して第２メモリ制御部１５０に渡す（ステップＳ１０６）。
【０１２０】
そして、第１メモリ制御部１４０は、前半メッセージ（または小受信メッセージ）をハッシュ値に応じて第１メモリ１６０上のＵｎｅｘｐｅｃｔｅｄ受信バッファ前半部１６１〜１６４のいずれかに分類して格納する（ステップＳ１０７）。
【０１２１】
また、第２メモリ制御部１５０は、後半メッセージをハッシュ値に応じて第２メモリ２００上のＵｎｅｘｐｅｃｔｅｄ受信バッファ後半部２０１〜２０４のいずれかに分類して格納する（ステップＳ１０８）。
【０１２２】
以上により、通信制御装置１００によるメッセージ受信処理が完了する。
【０１２３】
このように本実施の形態によれば、受信キーの一致判定により受信を行なう受信手段からの受信関数に係る受信要求情報を、当該受信関数に係る受信メッセージが届くまで、当該受信関数の受信キーから生成されたハッシュ値に応じて、複数の受信バッファの中から一の受信バッファを選択して格納する。このようにして、受信情報を先行受信要求検索部３１０がアクセスし易いように、受信バッファが分類され、受信バッファ内では受信関数起動順に順序づけられた状態で保持することができる。その結果、受信メッセージが届いた際に、当該受信メッセージが有している受信キーから生成されるハッシュ値に係る受信バッファ内に受信要求情報がある場合、受信キーの一致する受信要求情報（ここに最終的な格納場所が記載されている）を先行受信要求検索部３１０が検索する時間を短縮することができ、結果として最終的な格納場所に短い時間で受信メッセージを出力することができる、という効果を奏する。
【図面の簡単な説明】
【０１２４】
【図１】本発明の第１の実施の形態にかかるＰＣクラスタの構成を示す模式図である。
【図２】ＰＣの構成を示すブロック図である。
【図３】ホスト部の構成を示すブロック図である。
【図４】第１メモリおよび第２メモリのデータ構造を示す模式図である。
【図５】従来のメッセージの検索時間を示す説明図である。
【図６】メッセージの検索時間を示す説明図である。
【図７】メッセージ受信処理を示すフローチャートである。
【図８】ホスト部の機能構成を示すブロック図である。
【図９】受信メッセージ転送処理を示すフローチャートである。
【図１０】本発明の第２の実施の形態にかかるＰＣの構成を示すブロック図である。
【図１１】メッセージ受信処理を示すフローチャートである。
【符号の説明】
【０１２５】
１        情報処理装置
２０      ホスト部、受信手段
１００    通信制御装置
１２０    分割手段
１３０    変更手段、規則変更手段
１４０    メッセージ出力手段
１６０    第１メモリ
１６１〜１６４    受信バッファ
１７０    出力手段、メッセージ出力手段
１９０    ハッシュ値生成手段、キーハッシュ値生成手段
２００    第２メモリ
３６１〜３６４    受信バッファ
【図１】
0004621747.tif 000002
【図２】
0004621747.tif 000003
【図３】
0004621747.tif 000004
【図４】
0004621747.tif 000005
【図５】
0004621747.tif 000006
【図６】
0004621747.tif 000007
【図７】
0004621747.tif 000008
【図８】
0004621747.tif 000009
【図９】
0004621747.tif 000010
【図１０】
0004621747.tif 000011
【図１１】
0004621747.tif 000012