JP2008250496A - エンジン・プロセッサ連携システム及び連携方法 - Google Patents

Abstract

【課題】本発明は、プロセッサと高速エンジンの両方を有し、同一セッション内で高速エンジンとプロセッサでの実行を柔軟に変更可能なエンジン・プロセッサ連携技術を提供すること、また、高速エンジン動作中には性能を落とさないエンジン・プロセッサ連携技術を提供することを目的とする。
【解決手段】パケット受信部、送信部の両方が、ハードウェア、ソフトウェアの両方からアクセス可能なアクセス手段を提供し、ハードウェア処理部とソフトウェア処理部のどちらが処理を実施するか決定する処理選択部と、処理選択部の判断結果にしたがってコマンド処理対象を管理する処理管理部とを有する。
【選択図】図１

Description

本発明は、エンジン・プロセッサ連携技術に関し、特に入力されたコマンドおよびパケットに対してハードウェア又はソフトウェアにて演算処理を行った結果を送信データとして出力する、エンジン・プロセッサ連携システムに関する。

外部からのデータの入力に対して何かしらの演算を行い、外部にその結果を出力する演算システムの構成は大きく分類すると、図１２に示すように、外部からのデータを受信する受信部と、外部に対してデータを送信する送信部と、受信部から受信したデータに対して演算処理を実行し、送信回路に出力する演算部から構成される。

演算システムの例としては、図１３に示すようなＰｒｏｃｅｓｓｏｒ（プロセッサ）を利用したソフトウェア演算システムと、図１４に示すようなハードウェア演算システムが一般的である。

図１３に示したソフトウェア演算システムは、受信回路、送信回路、プロセッサ、メモリ、その他周辺機器、と各モジュールを接続するプロセッサバスとから構成される。すべてのモジュールがプロセッサバスを経由して接続することで、プロセッサバスの規格に一致するモジュールを自由に追加が可能な柔軟なアーキテクチャーである。

しかしながら、すべてのモジュール間のアクセスに関してプロセッサバスを経由してデータの送受信を行う必要があるため、一般的に演算処理性能は低い。特にプロセッサ自体がメモリデバイスに対して逐次アクセスを繰り返して処理を行う。このため、一般にソフトウェア演算システムは、柔軟に多様な処理を実現可能ではあるが、高い性能を実現することが困難という特徴がある。

図１４に示したハードウェア演算システムは、受信回路、送信回路、ハードウェア演算処理部から構成される。受信回路から受信されたデータはハードウェア演算部に直接入力され、ハードウェア演算処理部が、演算処理を実施した後で、送信回路に対して出力され、送信回路から送信データが外部へ出力される。

一般にハードウェア演算システムは、各モジュール間が固定的に接続され、演算に必要な処理を、並列・パイプライン処理が可能であるため、ソフトウェア演算システムに比べて高性能な処理を実現可能である。逆に、処理が固定的であることから、柔軟にシステムを構築することが困難であるとともに、処理に応じて専用のロジックを設計する必要があるため、回路規模の増大と開発期間の長期化という問題が存在し、複雑な論理を実現することが困難である。

このようにソフトウェア演算システムとハードウェア演算システムとは、それぞれ長所と短所とを有するがこの両方のメリットを生かした演算システムがＡｌｔｅｒａ（非特許文献１）より提案されている。

従来例１（非特許文献１）としてＡｌｔｅｒａのＣ２Ｈの例を図１５に示す。

従来例１の演算システムは、受信回路、送信回路、プロセッサ（Ｐｒｏｃｅｓｓｏｒ）、メモリ（Ｍｅｍｏｒｙ）、ＤＭＡエンジン（ＤＭＡ）、ハードウェアエンジン（ＨＷ Ｅｎｇｉｎｅ）から構成される。

受信回路に入力されたデータは、いったんプロセッサの汎用メモリ（Ｍｅｍｏｒｙ１）上に展開される。プロセッサは、受信したデータがハードウェアエンジンにて処理可能なデータであると判断した場合、ＤＭＡエンジンを利用して、処理対象のデータをメモリからハードウェアエンジンへと転送する。ハードウェアエンジンは、処理対象データが入力されると、該当データに対する演算処理を実行し、演算結果をＤＭＡエンジン経由で、プロセッサからアクセス可能なメモリ（Ｍｅｍｏｒｙ２）に対して転送する。

従来例１の演算システムを利用することで、複雑な処理はプロセッサを利用しつつも、処理のボトルネックとなっている単純処理をハードウェアエンジンで実現することが可能であり、プロセッサによる柔軟性とハードウェアエンジンにより高速性を両立することが可能である。

しかしながら、受信回路から入力した処理に対して、ハードウェアエンジンを利用するかどうかの判断、ハードウェアエンジンへのデータの送信指示などをプロセッサ経由で行う必要があり、ハードウェアエンジンを利用する場合も必ずプロセッサ処理が必要となる。よって、ハードウェアエンジンだけを利用した場合と比べると性能が低下してしまう。

一方、上記従来例１とは異なるプロセッサ・エンジン連携システムとして、特許文献１が提案されており、この技術は、ハードウェア処理部とソフトウェア処理部とを有し、パケット受信時にハードウェア処理部とソフトウェア処理部とのどちらで処理するかを判定する技術である。

特許文献１では、ＴＣＰヘッダ等から識別可能なセッションの種別に基づき、ハードウェア処理とソフトウェア処理とのどちらで処理するかを判定する。セッション単位でハードウェア処理とソフトウェア処理とのどちらで処理するかの識別されるため、セッション情報を管理するためのテーブルをハードウェア処理部とソフトウェア処理部とで共有する必要がない。反面、セッション内で、セッションの状態に応じて、ハードウェア処理とソフトウェア処理とを変更するような柔軟な処理の実現は困難である。
Ａｌｔｅｒａ Ｃ２Ｈ（ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｉｐ／ｐｒｏｃｅｓｓｏｒｓ／ｎｉｏｓ２／ｔｏｏｌｓ／ｃ２ｈ／ｎｉ２−ｃ２ｈ．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｉｐ／ｐｒｏｃｅｓｓｏｒｓ／ｎｉｏｓ２／ｂｅｎｅｆｉｔｓ／ｐｅｒｆｏｒｍａｎｃｅ／ｎｉ２−ａｃｃｅｌｅｒａｔｉｏｎ．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｌｉｔｅｒａｔｕｒｅ／／ｗｐ／ｗｐ−ａｇｈｒｄｗｒ．ｐｄｆ） 特開２００２−３５４０６４

本発明が解決しようとする課題は、上記問題点を解決することであり、プロセッサ（ソフトウェアでの処理）と高速エンジン（ハードウェアでの処理）の両方を有し、同一セッション内で高速エンジンとプロセッサでの実行を柔軟に変更可能なエンジン・プロセッサ連携システムを提供することである。

また、プロセッサと高速エンジンとの間でセッションの状況を示す情報を保持するセッションメモリの内容の同期を取りながら、高速エンジン動作中には性能を落とさないエンジン・プロセッサ連携システムを提供することを目的とする。

上記課題を解決するための本発明は、エンジン・プロセッサ連携システムであって、セッションの通信状況を示すセッションデータをセッション毎に管理しているセッションデータメモリと、入力されたデータが属するセッションのセッションデータを前記セッションデータメモリから読み出す読出部と、前記入力されたデータとセッションデータとを蓄積する蓄積部と、前記蓄積されている入力データとセッションデータとを、ハードウェア処理部がアクセスできる形式に展開する展開部と、前記読み出したセッションデータに基づいて、前記蓄積されている入力データをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定部と、前記処理決定部がハードウェア処理部で処理すると決定した場合に、前記展開された入力データを処理する高速エンジンとを有するハードウェア処理部と、前記処理決定部がソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力データを処理するソフトウェア処理部と、前記入力データの処理が終了すると、この入力データが属するセッションのセッションデータを更新する更新部とを有することを特徴とする。

上記課題を解決するための本発明は、エンジンとプロセッサとの連携方法であって、入力されたデータが属するセッションのセッションデータを、セッションの通信状況を示すセッションデータをセッション毎に管理しているセッションデータメモリから読み出す読出ステップと、前記入力されたデータとセッションデータとを蓄積部に蓄積さする蓄積ステップと、前記蓄積された入力データとセッションデータとを、ハードウェア処理部がアクセスできる形式に展開する展開ステップと、前記読み出したセッションデータに基づいて、前記蓄積された入力データをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定ステップと、前記処理ステップで、ハードウェア処理部で処理すると決定された場合に、前記展開された入力データを高速エンジンで処理する高速エンジン処理ステップと、前記処理ステップで、ソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力データをソフトウェアで処理するソフトウェア処理ステップと、前記入力データの処理が終了すると、この入力データが属するセッションのセッションデータを更新する更新ステップとを有することを特徴とする。

本発明のエンジン・プロセッサ連携システムでは、受信回路および送信回路がソフトウェア処理部からアクセス可能なプロセッサバス経由のインタフェースと、ハードウェア処理部から展開されたデータを利用してアクセス可能な高速ハードウェアインタフェースとの両方を有し、ハードウェア処理部内の処理選択部において、ソフトウェア処理部と高速エンジンのどちらで処理すべきかを決定し、処理管理部が、ハードウェア処理部とソフトウェア処理部の片方だけが、演算処理を実施することを保証する。

これにより、ハードウェアエンジンにて処理を実現する場合は、全処理がソフトウェア処理部を経由せずに処理が実施されるため、ソフトウェア処理が介入することにより性能劣化を招くことなく、ハードウェアエンジンの持つ最大限の性能を用いることが実現可能である。

さらに、本発明のエンジン・プロセッサ連携システムでは、受信回路部内のデータ展開処理部は、受信データ蓄積メモリ内の先頭データを展開し、ハードウェアインタフェースに受け渡すと共に、受信データ蓄積メモリ内に次のコマンドが到着している場合には、あらかじめ受信データ蓄積メモリからの読み出しを行い、データ展開処理部内でデータの展開を実施し、処理完了通知が入力されるとすぐに、ハードウェアインタフェースにデータの受け渡すことにより、高速エンジンの処理を高速化する。

さらに、本発明のエンジン・プロセッサ連携システムでは、プロセッサが、プロセッサバス経由でセッションデータメモリにアクセス可能とし、セッションデータ読み出し処理部が読み出しを行うデータは、処理選択部、高速エンジンの必要なデータのみとし、プロセッサが必要なデータは、セッションデータメモリからアクセスをする。セッションデータ読み出し処理部が読み出しに必要なデータ量を削減することで、セッションデータ読み出し処理部でのセッションデータの読み出しにかかる時間、データ展開処理部内での読み出しデータの展開にかかる時間を削減可能である。

本発明によると、ハードウェアエンジンにて処理を実現する場合は、全処理がソフトウェア処理部を経由せずに処理が実施されるため、ソフトウェア処理が介入することにより性能劣化を招くことなく、ハードウェアエンジンの持つ最大限の性能を用いることが可能である。

更に、本発明によると、データ展開処理部が、受信データ蓄積メモリ内の先頭データを展開してハードウェアインタフェースに受け渡した後、受信データ蓄積メモリ内に次のコマンドが到着している場合には、あらかじめ受信データ蓄積メモリからの読み出しを行い、データ展開処理部内でデータの展開を実施し、処理完了通知が入力されるとすぐに、ハードウェアインタフェースにデータの受け渡す構成であるため、高速エンジンの処理を高速化することが可能である。

更に、セッションデータ読み出し処理部が読み出しに必要なデータ量を削減することで、セッションデータ読み出し処理部でのセッションデータの読み出しにかかる時間、データ展開処理部内での読み出しデータの展開にかかる時間を削減可能である。

図１に、本発明のエンジン・プロセッサ連携システム８の構成例を示す。

エンジン・プロセッサ連携システム８は、受信回路１、送信回路２（セッション送信回路２−１、外部送信回路２−２）、ハードウェア処理部３、ソフトウェア処理部４、セッションメモリ管理部５、プロセッサバス６、及びＭＵＸ回路７を有する。

ハードウェア処理部３は、処理選択部３１、処理管理部３２、及び高速エンジン３０を有する。

ソフトウェア処理部４は、プロセッサ４０、メモリ４１、及び周辺回路４２を有し、プロセッサバス６と接続して、各種ソフトウェア処理を実施する。

セッションメモリ管理部５は、セッションデータ書込処理部５３、セッションデータ読出処理部５２、セッションデータメモリ５０、及びセッションロックメモリ５１を有する。

セッションメモリ管理部５は、セッションデータメモリ５０に各セッションの固有データ（セッションデータ）を蓄積・管理する。

セッションデータメモリ５０に蓄積されているセッション毎のセッションデータは、セッションデータ読出処理部５２経由で、セッションデータの読み出しが行われ、セッションデータ書込処理部５３経由で、セッションデータの更新が行われる。

また、セッションロックメモリ５１において、セッションデータの読み出し後、書込処理が実行されるまでの間、セッションデータの読み出しをロックすることで、セッションデータ更新前に、同一セッションのセッションデータが読み出しされることを防止する。また、セッションデータメモリ５０は、プロセッサバス６とも接続しており、プロセッサ４０はセッションデータメモリ５０の内容にアクセス可能なものとする。

プロセッサバス６は、受信回路１、各送信回路２、プロセッサ４０、メモリ４１、周辺回路４２、処理管理部３２、セッションデータメモリ５０と接続されている。これにより、プロセッサ４０は、各ブロックにアクセスしてソフトウェア処理を実行可能なものとする。

ＭＵＸ回路７は、外部より受信したパケット及びコマンドから一つのコマンドを選択して、セッションデータ読出処理部５２に転送する。読み出し方法としては、固定的に優先順序を決める方法や、ラウンドロビンで決める方法と、読み出し比率に従って読み出す等の方法があるが、どの方法を用いても良い。

セッションデータ読出処理部５２は、ＭＵＸ回路７からコマンドを受信すると、セッションロックメモリ５１の状態を識別して該当セッションのセッションデータがロックされていなければ、セッションデータメモリ５０よりセッションデータの読み出し処理を行う。該当セッションのセッションデータがロック状態の時は、ロック状態が解除されるまでセッションデータの読み出しを停止する。該当セッションのセッションデータのロック状態の解除は、セッションデータ書込処理部５３が、セッション送信回路２−１よりコマンドを受信した際に実行される。

セッションデータ読出処理部５２は、セッションデータを読み出すと、コマンドの内容（パケット・コマンドデータ）と共に、受信回路１へ転送する。

受信回路１は、セッションデータ読出処理部５２から入力されるデータを一時的に保持する。受信回路１は、受信したコマンドデータとセッションデータとをハードウェア処理部３と、ソフトウェア処理部４との両方から読み出し可能なインタフェースを提供するものである。

処理選択部３１は、受信回路１に蓄積されたコマンドとセッションデータとを参照し、ハードウェアで処理する高速エンジン３０とソフトウェアで処理するプロセッサ４０のどちらで処理するかを決定する。

高速エンジン３０で処理する場合は、高速エンジン３０に通知され、高速エンジン３０は、受信回路１からのデータ読み出しを行い、処理を実行した後で、実行結果を各送信回路２に出力する。一方、プロセッサ４０で処理する場合は、プロセッサ４０は、処理管理部３２経由でプロセッサ４０によるコマンド処理の対象であることを識別し、そのコマンドの処理を実行し、実行結果を各送信回路２に出力する。

セッション送信回路２−１は、セッションデータ書込処理部５３と接続されており、プロセッサ４０もしくは高速エンジン３０からのコマンド処理を実行した結果を受信して、セッションデータの更新情報をセッション送信回路２−１に出力する。

セッションデータ書込処理部５３は、セッション送信回路２−１からのセッションデータの更新情報に基づいてセッションデータメモリ５０を更新し、セッションロックメモリ５１のロックを解除する。

ここで、受信回路１について詳細に説明する。

図２は、受信回路１の構成例である。

受信回路１は、受信データ蓄積メモリ１０、受信データ管理部１１、受信ソフトウェアインタフェース１２、及びデータ展開処理部１３を有する。

受信回路１に入力されたパケット・コマンドデータとセッションデータ（入力データ）は、受信データ蓄積メモリ１０に蓄積される。

受信データ管理部１１は、受信データ蓄積メモリ１０に蓄積された入力データを管理する。

受信回路１は、受信データ蓄積メモリ１０に蓄積された入力データを読み出す手段として、ハードウェアインタフェースとソフトウェアインタフェースの２つを有する。

データ展開処理部１３は、読み出し対象のデータとして、受信データ蓄積メモリ１０に入力された入力データを読み出し、ハードウェアインタフェースから一度にアクセス可能な形式に展開する。入力データが展開されると、受信データ管理部１１は、ハードウェアインタフェースに対して受信パケット通知信号を出力する。また、ハードウェアでの処理が完了し、ハードウェアインタフェース部から処理完了通知が入力されると、読み出し対象データの処理が完了したことを認識し、読み出し対象データを破棄する。ハードウェアインタフェース部から処理完了通知が入力されるまで、受信データ蓄積メモリ１０を監視し、次の読み出し対象データが存在する場合は、次の読み出し対象データを受信データ蓄積メモリ１０より読み出して展開する。

受信ソフトウェアインタフェース１２は、ソフトウェア処理部４に対して、プロセッサバス６を介して、受信データ蓄積メモリ１０に蓄積されている入力データにアクセス可能なインタフェースである。受信ソフトウェアインタフェース１２では、受信データ蓄積メモリ１０に読み出し対象データが存在するかどうかを通知する手段、読み出しデータが存在する場合は読み出し対象データの長さ、読み出し対象データへのリードアクセス手段、ソフトウェア処理部４から受信回路１に対して、読み出し対象データの処理が完了したことを受信データ管理部１１に通知する手段を提供する。

このように受信回路１では、ハードウェアインタフェースと、ソフトウェアインタフェースとの両方に対して、読み出し対象データが存在するかどうか、存在する場合はデータ長、読み出し対象データへのアクセス手段、および、受信回路１に対して、読み出し対象データの処理が完了したことを通知するための手段を提供する。

続いて、送信回路２−１について説明する。

図３は、送信回路２−１の構成例である。

送信回路２−１は、送信データ蓄積メモリ２０、送信データ管理部２１、送信ソフトウェアインタフェース２２、及び展開データ書き込み部２３を有する。

送信回路２−１は、ハードウェアインタフェースもしくはソフトウェアインタフェースから送信された入力データを、一時的に送信データ蓄積メモリ２０に格納し、外部から入力データを受信可能かどうかの通知信号に従って入力データの出力を行う。外部から入力データを受信可能かどうかの通知信号としては、データ読み出しを細かく外部から制御する方法と、外部側でコマンドを受信できないときだけ、バックプレッシャー信号により受信できないことを通知する方法とがあり、本発明においてはどちらの方法を用いても良い。

送信データ管理部２１は、送信データ蓄積メモリ２０のデータ蓄積量および送信データ蓄積メモリ２０のアクセス管理を行う。送信データ管理部２１は、送信データ蓄積メモリ２０の空きバッファ量をハードウェアインタフェース部および送信ソフトウェアインタフェース２２に通知する。

高速エンジン３０は、ハードウェアインタフェース部を介して、送信データの送出を通知する。高速エンジン３０は、送出対象の入力データをあらかじめ展開し、展開データとして準備する。展開データの準備が完了すると、送出対象データのデータ長と通知された空きバッファ量とを比較し、送出対象データのデータ長よりも空きバッファ量の方が大きくなると、送出対象データのデータ長分のパケット転送を通知する。

展開データ書込部２３は、パケット転送通知が入力されると、展開データを、送信データ蓄積メモリ２０に書き込む。通常、送信データ蓄積メモリ２０に一度に書き込みが可能なデータ幅は、展開データのデータ幅よりも小さいため、展開データは複数クロックかけて書き込みが行われる。

送信データ管理部２１は、展開データ書込部２３が送信データ蓄積メモリ２０に展開データの書き込みを行っている間は、次の展開データの書き込みがされないことを保証する。一つの実現例は、展開データ書込部２３のデータ書き込み中は、空きバッファ通知量を０として、ハードウェアインタフェース部および送信ソフトウェアインタフェース２２に通知することで、新たなアクセス要求を発生させないようにすることである。

送信ソフトウェアインタフェース２２は、ソフトウェア処理部４に対して、プロセッサバス６を介して、送出データの転送を要求するためのインタフェースである。送信ソフトウェアインタフェース２２は、送信データ蓄積メモリ２０の空きバッファ量確認する手段、送信データの内容を設定する手段、送信データの送出を要求する手段を有する。

このように送信回路２−１では、ハードウェアインタフェースとソフトウェアインタフェースの両方に対して、送信データ蓄積メモリ２０の空きバッファ量を確認する手段、送信対象データの中身を設定する手段、実際のデータ送出を要求する手段を提供する。

次に、本発明のエンジン・プロセッサ連携システム８の動作に関して説明する。

まず、入力データが高速エンジン３０にて処理される際の動作例を示す。図４は、入力データが高速エンジン３０にて処理される場合の、入力データの流れを説明するための図である。

ＭＵＸ回路７は、パケット・コマンドデータを受信すると、セッションデータ読出処理部５２へコマンドを転送する。

セッションデータ読出処理部５２は、セッションデータメモリ５０からそのパケット・コマンドデータが送信されて来たセッションのセッションデータを読み出し、読み出したセッションデータとパケット・コマンドデータとを受信回路１へ出力する。

受信回路１は、パケット・コマンドデータとセッションデータとを受信すると、データ展開処理部１３でその受信データを展開した後、処理選択部３１に対して、パケット受信を通知する。

処理選択部３１では、展開された受信データを参照し、あらかじめ決められた演算ルールに基づいて、高速エンジン３０が処理をすべきか、ソフトウェア処理部が処理をすべきかを判断して、処理管理部３２に通知する。

処理管理部３２は、処理状態を高速エンジン３０処理状態とすることで、ソフトウェア処理部４が処理管理部３２の処理状態をチェックした際に、ソフトウェア処理部４が処理すべきデータが存在しないことを通知する。

処理選択部３１は、展開された受信データを高速エンジン３０が処理すべきであることを高速エンジン３０に対して通知することで、高速エンジン３０は、展開された受信データに対して演算処理を実行し、演算結果に基づいて送出するデータを決定して各送信回路２にデータ送出通知を出力する。

高速エンジン３０は、データ送出通知を出力すると、処理管理部３２に対して高速エンジン３０の処理が完了したことを通知する。ただし、高速エンジン３０内の処理が固定サイクルで完了することが決まっているシステム構成では、処理管理部３２が自立的に高速エンジン３０の処理完了を認識してもよい。

処理管理部３２は、現在の処理対象データの処理が完了したことを認識し、受信回路１及び処理選択部３１に対して処理が完了したことを通知する。

受信回路１の受信データ管理部１１は、コマンド処理の完了が通知されるまでの間、次のコマンドが蓄積されているかどうかを関しする。次のコマンドが蓄積されている場合は、再度、データ展開処理部１３で受信データを展開し、コマンド処理の完了が通知された後、処理選択部３１に対してパケット受信を通知する。

本発明のエンジン・プロセッサ連携システム８において、低速なソフトウェア処理を実行するのは、ソフトウェア処理部４のみである。

受信データが高速エンジン３０にて処理される場合は、低速なソフトウェア処理部を経由することなく、ハードウェア動作だけで動作するため、ソフトウェア処理の介在しない高速処理が可能であることが特徴である。

続いて、入力データがソフトウェア処理部４のプロセッサ４０にて処理される際の動作例を示す。図５及び図６は、入力データがプロセッサ４０にて処理される場合の、入力データの流れを説明するための図である。尚、図５は受信回路１に対して処理管理部３２経由で処理完了を通知する場合の図であり、図６は受信回路１に対して直接、処理完了の通知を送信する場合の図である。

ＭＵＸ回路７は、パケット・コマンドデータを受信すると、セッションデータ読出処理部５２へコマンドを転送する。セッションデータ読出処理部５２は、セッションデータメモリ５０からセッションデータの読み出しを行い、受信回路１へ出力する。

受信回路１が、入力データを受信したことを処理選択部３１に通知し、処理選択部３１で高速エンジン３０とソフトウェア処理部４のプロセッサ４０のどちらで処理すべきかを判断して、処理管理部３２に通知するところまでは同一動作である。

処理管理部３２は、処理選択部３１から、入力データがソフトウェアの処理対象であることが通知されると、処理状態をソフトウェア処理可能状態に変更する。ソフトウェア処理部内のプロセッサ４０は、プロセッサバス６経由で、処理管理部３２の処理状態レジスタをポーリングにより読み出しを実施し、対象データがソフトウェア処理部で実行すべきコマンドであることを認識する。

プロセッサ４０は、受信回路１の受信ソフトウェアインタフェース１２を介して受信データ蓄積メモリ１０から対象データの読み出しを行い、必要な演算処理を実行する。プロセッサ４０は、演算実行後、受信回路１の受信ソフトウェアインタフェース１２に対して、処理が完了したことをプロセッサバス６経由、若しくは処理管理部３２経由で通知するとともに、各送信回路２に対して、必要なコマンドの送信処理を通知する。

プロセッサ４０は、処理が完了したことをプロセッサバス６経由で通知した場合、処理管理部３２に対して対象データの処理完了を通知する。

処理管理部３２は、ソフトウェア処理部４から対象データの処理完了が通知されると、処理状態レジスタをアイドル状態にし、次のコマンドの処理が可能であることを、処理選択部３１に通知する。

次に、本発明のエンジン・プロセッサ連携システム８における高速エンジン３０動作時の動作タイミング例について説明する。

図７は、本発明のエンジン・プロセッサ連携システム８における高速エンジン３０動作時の動作タイミング例を説明するための図である。

高速エンジン３０動作時には、パケット・コマンドデータは、ＭＵＸ回路７、セッションデータ読出処理部５２、受信回路１、処理選択部３１、高速エンジン３０、セッション送信回路２、セッションデータ書込処理部５３の順番で処理される。図７の四角内の数字はセッションを一意に識別するための識別情報を意味するものとする。

各処理ブロックはパイプライン化されており、セッション１のパケット・コマンドデータ受信後にセッション２のコマンドを受信した場合、各ブロックはパケット・コマンドデータを連続して処理可能なものとする。セッション１に対する３番目のコマンドは、セッション１に対する２番目のコマンド処理が完了し、セッションデータ書込処理部５３が該当セッションのロックが解除するまでセッションデータ読み出し処理の待ち合わせを行う。

このように、各ブロックの処理がパイプライン化されていても、短い時間間隔で同一セッションのコマンドが入力される状況では、セッションデータ読出処理部５２での待ち合わせ処理により処理性能の劣化が発生する。

処理性能の劣化を防止するためには、セッションデータ読出処理部５２でセッションのデータを読み出してから、セッションデータ書込処理部５３でセッションデータを更新するまでの時間を短くすることが重要である。

ここで、セッションロックメモリ５１に関してより詳しく説明する。

セッションロックメモリ５１では、セッションを一意に識別可能なセッション番号毎にセッションロック状態かどうかを管理する。

セッションがロック状態とは、セッションデータメモリ５０内の該当セッションデータが読み出し中であり、新たな読み出しを禁止している状態である。セッションがロック状態でなければ該当セッションデータの読み出しが可能ということになる。

セッションデータ読出処理部５２は、セッションデータをセッションデータメモリ５０から読み出しする際にセッションロックメモリ５１内の該当セッション番号をロック状態に書き込む。

セッションデータ読出処理部５２は、ロック状態のセッション番号に関するコマンドを受信した場合は、該当セッションの読み出しが禁止されているので、ロック状態が解除されるまで待ち合わせを行う。ロック状態が解除されるのは、セッションデータ書込処理部５３が更新されたセッションデータエントリをセッションデータメモリ５０に書き込むタイミングである。

セッションデータ読出処理部５２は、ロック状態が解除されるタイミングで更新後のセッションデータをセッションデータとして受信コマンドと共に受信回路へ送信すると共に、セッションロックメモリ５１の該当セッション番号を再度ロック状態に設定する。

図７の例では、セッション１に対する３番目のコマンド受信時のみ、セッションがロック状態（値１）になっているため、ロック解除の待ち合わせが発生している。

このように、本発明のエンジン・プロセッサ連携システム８では、送信回路、受信回路１が、ハードウェア処理部３用に展開されたデータを受け渡す高速インタフェースを有し、また、送信回路は、高速エンジン３０でのコマンド処理中に、あらかじめ次のコマンドのデータを展開しておくことで、全体遅延を削減する。

次に本発明のエンジン・プロセッサ連携システムの実施例について説明する。

図８は、本発明のエンジン・プロセッサ連携システム８を利用したＴＣＰオフロード処理部１１０を適用したサーバシステム１１０の構成例である。

サーバ装置１００は、ＴＣＰオフロード処理部１１０、ＣＰＵ１０１、メインメモリ１０２、バス１０３より構成される。サーバ装置１００は、外部ネットワークと接続し、ＴＣＰを利用して対向ホスト（サーバ、パソコン、その他）と通信を行う。ＣＰＵ１０１は、ＴＣＰオフロード処理部１１０経由で対向ホストからのパケットを送受信する。

ＴＣＰオフロード処理部１１０は、ネットワーク送受信部１１１、パケット受信部１１２、パケット送信部１１３、ホスト接続部１１４、エンジン・プロセッサ連携システム８より構成される。

対向ホストからサーバ装置１００へＴＣＰパケットが送信される場合の動作例に関して説明する。

対向ホストからサーバ装置１００へ送信されたパケットは、ネットワーク送受信部１１１経由でパケット受信部１１２に入力される。

パケット受信部１１２は、受信したパケットがどのセッションに属するかの識別を行う。具体的には、ＴＣＰセッションの場合、送信ＩＰアドレス・送信ＴＣＰポート・受信ＩＰアドレス・受信ＴＣＰポートの組み合わせでセッションを識別する。サーバ装置は、識別したセッションを一意に区別するためのセッション番号によりセッションを管理する。新規のセッションの場合は、パケット受信部１１２にて新しいセッション番号の割り当てを行う。

パケット受信部１１２は、受信パケットを一時的に蓄積すると共に、ＴＣＰヘッダを抽出して、セッション番号・新規セッションかどうかのフラグ・ＴＣＰヘッダを一つの受信パケットコマンドとしてエンジン・プロセッサ連携システム８に転送する。

エンジン・プロセッサ連携システム８は、受信パケットコマンドを受信すると、該当する受信パケットコマンドに対する処理を実行し、受信パケット処理結果をパケット受信部１１２に転送する。

パケット受信部１１２は、エンジン・プロセッサ連携システム８より受信パケット処理結果を受信すると、受信パケット処理結果の内容に従って、受信パケットのペイロードデータをホスト接続部１１４、バス１０２経由で、メインメモリに転送すると共に、必要に応じてデータを受信したことをＣＰＵ１０１に通知する。ＣＰＵ１０１への通知方法としては、割り込みを利用する方法やメインメモリの特定領域にデータを書き込んで、ＣＰＵ１０１から該当メモリ領域をポーリングアクセスする方法などがあるが、本発明においてはどちらを用いても良い。

次に、サーバ装置１００から対向ホストへＴＣＰパケットを送信する場合の動作例に関して説明する。

ＣＰＵ１０１は、送信ペイロードデータをメインメモリ１０２に書き込むと共に、ＴＣＰオフロード処理部１１０に対して送信要求することを通知する。この送信要求は、送信要求コマンドとしてＴＣＰオフロード処理部１１０のホスト接続部１１４に入力される。送信要求コマンドの転送法としては、ＣＰＵ１０１が直接コマンドをホスト接続部１１４に転送する方法と、コマンド自体はメインメモリ１０２に書き込み、ＣＰＵ１０１は送信要求コマンドが存在することをホスト接続部１１４に通知することで、ホスト接続部１１４がメインメモリ１０２から送信要求コマンドの読み出しを実行する方法があるが、本発明においてはどちらを用いても良い。

送信要求コマンドは、ホスト接続部１１４経由で、本発明のエンジン・プロセッサ連携システム８に入力される。

エンジン・プロセッサ連携システム８は、送信要求コマンドの処理を実施し、送信するペイロードデータを決定しパケット送信要求をパケット送信部１１２に通知する。

パケット送信部１１２は、パケット送信要求を受信すると、メインメモリ１０２から要求されたペイロードデータを読み出すと共に送出パケットを生成して、ネットワーク送受信部１１１経由で外部に送信パケットを送出する。

接続先のサーバ装置（対向ホスト）は、サーバ装置１００からのペイロード付きパケットを受信すると、どこまで受信したかという情報をＡＣＫパケットとしてサーバ装置１００に対して送出する。対向ホストからサーバ装置１００へ送出されたＡＣＫパケットは、ネットワーク送受信部１１１経由で、パケット受信部１１３に入力される。

パケット受信部１１３は、通常のデータパケット受信時と同様にセッション番号を解決し、セッション番号・新規セッションフラグ（ここでは新規になることはない）・ＴＣＰヘッダを含む受信パケットコマンドをエンジン・プロセッサ連携システム８に対して出力する。

エンジン・プロセッサ連携システム８は、該当セッション番号のセッションに対して、ＴＣＰヘッダの内容からどこまでのペイロードデータを対向ホストが受信したかを判定して、送信完了コマンドをホスト接続部１１４経由でメインメモリ１０２に書き込み、ＣＰＵ１０１に通知する。

ＣＰＵ１０１は、送信完了コマンドを参照することで、送信要求したデータがどこまで送信完了したかを識別し、完了分のデータに関しては解放する。なお、エンジン・プロセッサ連携システム８は、ＣＰＵ１０１から送信要求コマンドを受信した際に、指定された送信ペイロードデータの全てを一度に送信するとは限らない。ＴＣＰには、フロー制御機構が存在し、一度に送出可能なデータは限られる。よって、送出可能な量のデータを送出し、対向ホストからＡＣＫパケットが入力されパケット受信コマンドを受信した際に、新たに送出可能となる送信ペイロードデータが存在しないかどうかをチェックし、存在する場合は送出可能となったペイロードデータ部分を読み出してパケット化し、対向ホストに送出する。

図９にセッションデータメモリ５０が保持するセッションデータのエントリ例を示す。

セッションデータメモリ５０は、セッション番号により識別されるセッション毎に以下のようなセッションデータを管理する。
・state: セッションの状態。セッション確率途中(SYN_RECEIVED、SYN_SENT)、セッション確立状態(SYN_ESTABLISHED)、セッション切断途中等、セッション未使用状態(CLOSED)
・rcv_nxt: 対向ホストからどこまでデータを受信したかを示す
・rcv_wnd: rcv_nxtに加えてどこまでデータを受信可能の受信可能データ量を示す
・snd_una: サーバ装置１００の送信対象データを、対向ホストがどこまで受信したかを示す。
・snd_nxt: サーバ装置１００の送信対象データを、どこまで送信したかを示す。
・snd_wnd: 送信可能なデータサイズ（厳密にはいくつかのパラメータの複合要因により決まる値であるが簡易化して一つのパラメータとする）
・snd_req: サーバ装置１００の送信対象データのデータ末尾の位置

図１０にセッションデータパラメータの関係イメージ図を示す。

まず、送信データ管理パラメータに関して説明する。

図９のセッションデータメモリにおけるセッション番号３の例を当てはめると、1500byte(0-1499byte)の送信要求データの中で、399byte目までのデータは対向ホストでの受信が完了し、400byteから999byte目までのデータは送信完了したがまだＡＣＫが返ってきておらず、1000byteから1499byte目までは未送信状態であることを意味する。400-999byteまでの600byteしかデータを送っていない理由は、snd_wndにより送信可能なデータ量が600byteに制限されているからである。

続いて、受信データ管理パラメータに関して説明する。699byte目まではデータを受信しており700byte目以降の受信を待っている状態である。400byte分のデータが受信可能であることから、699+4000= 4699byte目まで受信可能な状態であることが分かる。なお、これらのセッションデータパラメータは、ＴＣＰのSEQ番号やＡＣＫ番号に対応する相対的な値であり、初期値が0から始まるとは限らない。

なお、上記は、ＴＣＰセッションに含まれるセッションデータの一部にすぎず、実際にはより多くの種類のセッションデータが存在する。

図１１に受信処理におけるセッションデータメモリのエントリ更新例を示す。図１１は、セッションデータメモリ５０において、外部からセッション番号３のＴＣＰパケットを受信した場合のセッションデータメモリエントリの更新例を示している。

処理選択部３１は、rcv_nxtと受信ＴＣＰヘッダの先頭バイト位置が一致する場合のみ高速エンジン３０での処理を選択し、一致しない場合はプロセッサ４０での処理を選択するものとする。

図９のセッションデータメモリの状態において、セッション番号３では、699byte目まではデータを受信しており、700byte目以降を受信待ちの状態である。

最初に受信したＴＣＰパケットが700-1199byte目までのデータを含んでいたとする。

ＴＣＰヘッダを含むＴＣＰパケットコマンドとセッションデータ読出処理部５２経由で読み出されたセッションデータは、受信回路１へ入力される。

処理選択部３１は、ＴＣＰパケットの先頭バイト位置の値とrcv_nxtの値とが一致することから、高速エンジン３０にてコマンドを処理することを選択する。

高速エンジン３０は、700-1199byte目を受信したことを識別し、rcv_nxt=1200、rcv_wnd=3500に更新することをセッション送信回路２−１に伝え、外部送信回路２−２経由で700-1199byte目のデータをメインメモリ１０２に転送することを通知する。

新しいセッションデータは、セッション送信回路２−１より送信され、セッションデータ書込処理部５３においてセッションデータの更新が行われる。

次に、受信したＴＣＰパケットが900-1399bye目までのデータを含んでいたとする。

ＴＣＰヘッダと更新されたセッションデータが同様に受信回路１経由で処理選択部３１に入力される。

処理選択部３１は、ＴＣＰパケットの先頭バイト位置の値とrcv_nxtの値とが一致しないことからプロセッサ４０での処理を選択する。

プロセッサ４０は、受信パケットの900-1199byte部分はすでに受信したデータであり1200-1399byte目までが新たに受信したデータであることを認識する。

rcv_nxt=1400、rcv_wnd=3300に更新することをセッション送信回路２−１に伝え、外部送信回路２−２経由で1200-1399byte目のデータのみをメインメモリ１０２に転送することを通知する。

次にＣＰＵ１０１より受信領域拡張コマンドとして、1000byte分受信領域の拡張が可能であるというコマンドが入力されたとする。

受信領域拡張コマンドとセッションデータが受信回路経由で処理選択部に入力され、処理選択部３１は、高速エンジン３０での処理を選択（受信領域拡張コマンドは常に高速エンジンで処理する設定になっているものとする）する。

高速エンジン３０は、rcv_wndの値を4300に拡張し、セッション送信回路経由でセッションデータエントリを更新する。

上述したように、本発明によると、ハードウェアエンジンにて処理を実現する場合は、全処理がソフトウェア処理部を経由せずに処理が実施されるため、ソフトウェア処理が介入することにより性能劣化を招くことなく、ハードウェアエンジンの持つ最大限の性能を用いることが可能である。

更に、本発明によると、データ展開処理部が、受信データ蓄積メモリ内の先頭データを展開してハードウェアインタフェースに受け渡した後、受信データ蓄積メモリ内に次のコマンドが到着している場合には、あらかじめ受信データ蓄積メモリからの読み出しを行い、データ展開処理部内でデータの展開を実施し、処理完了通知が入力されるとすぐに、ハードウェアインタフェースにデータの受け渡す構成であるため、高速エンジンの処理を高速化することが可能である。

更に、セッションデータ読み出し処理部が読み出しに必要なデータ量を削減することで、セッションデータ読み出し処理部でのセッションデータの読み出しにかかる時間、データ展開処理部内での読み出しデータの展開にかかる時間を削減可能である。

図１は、本発明のエンジン・プロセッサ連携システムのブロック図である。 図２は、受信回路のブロック図である。 図３は、送信回路のブロック図である。 図４は、ハードウェアにて処理を行う場合の入力データの流れを説明するための図である。 図５は、ソフトウェアにて処理を行う場合の入力データの流れを説明するための図である。 図６は、ソフトウェアにて処理を行う場合の入力データの流れを説明するための図である。 図７は、本発明における動作タイミング例である。 図８は、本発明を適用した装置のブロック図である。 図９は、セッションデータの一例を示す図である。 図１０は、セッションデータパラメータの関係を説明するためのイメージ図である。 図１１は、受信処理におけるセッションデータメモリのエントリ更新例を説明するための図である。 図１２は、従来の演算システムのブロック図である。 図１３は、従来のソフトウェア演算システムのブロック図である。 図１４は、従来のハードウェア演算システムのブロック図である。 図１５は、従来例１のブロック図である。

符号の説明

１ 受信回路
２ 送信回路
２−１ セッション送信回路
２−２ 外部送信回路
３ ハードウェア処理部
４ ソフトウェア処理部
５ セッションデータ読出処理部
６ プロセッサバス
７ ＭＵＸ回路
８ エンジン・プロセッサ連携システム
１０ 受信データ蓄積メモリ
１１ 受信データ管理部
１２ 受信ソフトウェアインタフェース
１３ データ展開処理部
２０ 送信データ蓄積メモリ
２１ 送信データ管理部
２２ 送信ソフトウェアインタフェース
２３ 展開データ書込部
３０ 高速エンジン
３１ 処理選択部
３２ 処理管理部
４０ プロセッサ
４１ メモリ
４２ 周辺回路
５０ セッションデータメモリ
５１ セッションロックメモリ
５２ セッションデータ読出処理部
５３ セッションデータ書込処理部

Claims (8)

1. エンジン・プロセッサ連携システムであって、
   セッションの通信状況を示すセッションデータをセッション毎に管理しているセッションデータメモリと、
   入力されたデータが属するセッションのセッションデータを前記セッションデータメモリから読み出す読出部と、
   前記入力されたデータとセッションデータとを蓄積する蓄積部と、
   前記蓄積されている入力データとセッションデータとを、ハードウェア処理部がアクセスできる形式に展開する展開部と、
   前記読み出したセッションデータに基づいて、前記蓄積されている入力データをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定部と、前記処理決定部がハードウェア処理部で処理すると決定した場合に、前記展開された入力データを処理する高速エンジンとを有するハードウェア処理部と、
   前記処理決定部がソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力データを処理するソフトウェア処理部と、
   前記入力データの処理が終了すると、この入力データが属するセッションのセッションデータを更新する更新部と
   を有することを特徴とするエンジン・プロセッサ連携システム。
2. 前記読出部は、前記高速エンジン又は前記ソフトウェア処理部で前記蓄積されている入力データを処理している間は、その入力データが属するセッションのセッションデータを読み出さないことを特徴とする請求項１に記載のエンジン・プロセッサ連携システム。
3. 前記展開部は、前記蓄積部の先頭データを展開して、ハードウェア処理部から一度にアクセス可能なように構成されていることを特徴とする請求項１又は請求項２に記載のエンジン・プロセッサ連携システム。
4. 前記ソフトウェア処理部に、前記蓄積されている入力データにアクセスするための情報を提供する提供部を有することを特徴とする請求項１から請求項３のいずれかに記載のエンジン・プロセッサ連携システム。
5. 前記展開部は、
   前記高速エンジンが前記展開したデータを処理している間に、次の入力データが前記蓄積部に蓄積されているかどうかを監視し、次の入力データが蓄積されている場合にはそれを読み出し、前記高速エンジンからの処理完了通知を受信すると読み出した入力データを展開することを特徴とする請求項１から請求項４のいずれかに記載のエンジン・プロセッサ連携システム。
6. 前記高速エンジンからの処理完了通知を受けると、前記高速エンジンによって処理された展開データを一度に受信し、送信データ蓄積部の末尾に書き込む展開データ書込部を有することを特徴とする請求項１から請求項６のいずれかに記載のエンジン・プロセッサ連携システム。
7. 前記ソフトウェア処理部は、前記入力データを処理する際に、読み出しされていないセッションデータにアクセスするために、プロセッサバス経由で直接前記セッションデータメモリにアクセスすることを特徴とする請求項１から請求項６のいずれかに記載のエンジン・プロセッサ連携システム。
8. エンジンとプロセッサとの連携方法であって、
   入力されたデータが属するセッションのセッションデータを、セッションの通信状況を示すセッションデータをセッション毎に管理しているセッションデータメモリから読み出す読出ステップと、
   前記入力されたデータとセッションデータとを蓄積部に蓄積させる蓄積ステップと、
   前記蓄積された入力データとセッションデータとを、ハードウェア処理部がアクセスできる形式に展開する展開ステップと、
   前記読み出したセッションデータに基づいて、前記蓄積された入力データをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定ステップと、
   前記処理ステップで、ハードウェア処理部で処理すると決定された場合に、前記展開された入力データを高速エンジンで処理する高速エンジン処理ステップと、
   前記処理ステップで、ソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力データをソフトウェアで処理するソフトウェア処理ステップと、
   前記入力データの処理が終了すると、この入力データが属するセッションのセッションデータを更新する更新ステップと
   を有することを特徴とする連携方法。

Images