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

Description

本発明は、エンジン・プロセッサ連携システムにおいて、特に、タイムアウト監視を並列実行可能なエンジン・プロセッサ連携システムに関する

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

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

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

しかしながら、すべてのモジュール間のアクセスに関してプロセッサバスを経由してデータの送受信を行う必要があるため、一般的に演算処理性能は低い。特にプロセッサ自体がメモリデバイスに対して逐次アクセスを繰り返して処理を行う。

このため、一般にソフトウェア演算システムは、柔軟に多様な処理を実現可能ではあるが、高い性能を実現することが困難という特徴がある。

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

一般にハードウェア演算システムは、各モジュール間が固定的に接続され、演算に必要な処理を、並列・パイプライン処理が可能であるため、ソフトウェア演算システムに比べて高性能な処理を実現可能である。

逆に、処理が固定的であることから、柔軟にシステムを構築することが困難であるとともに、処理に応じて専用のロジックを設計する必要があるため、回路規模の問題と設計期間の問題が存在し、複雑な論理を実現することが困難である。

このようにソフトウェア演算システムとハードウェア演算システムはそれぞれ長所と短所を有するが、この両方のメリットを生かした演算システムがAlteraより提案されている。

従来例1（非特許文献１）としてAlteraのC2Hの例を図１２に示す。

従来例１の演算システムは、受信回路、送信回路、プロセッサ、メモリ、DMAエンジン、ハードウェアエンジンから構成される。

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

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

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

また、従来例１でタイムアウト処理を実現する場合、やはり、ハードウェアエンジンを利用するかどうかの判断、ハードウェアエンジンへのデータの送信指示などをプロセッサ経由で行うため、ハードウェアエンジンを利用する場合も必ずプロセッサ処理が必要となり、性能が低下してしまう。
Altera C2H（ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｉｐ／ｐｒｏｃｅｓｓｏｒｓ／ｎｉｏｓ２／ｔｏｏｌｓ／ｃ２ｈ／ｎｉ２−ｃ２ｈ．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｐｒｏｄｕｃｔｓ／ｉｐ／ｐｒｏｃｅｓｓｏｒｓ／ｎｉｏｓ２／ｂｅｎｅｆｉｔｓ／ｐｅｒｆｏｒｍａｎｃｅ／ｎｉ２−ａｃｃｅｌｅｒａｔｉｏｎ．ｈｔｍｌ，ｈｔｔｐ：／／ｗｗｗ．ａｌｔｅｒａ．ｃｏ．ｊｐ／ｌｉｔｅｒａｔｕｒｅ／／ｗｐ／ｗｐ−ａｇｈｒｄｗｒ．ｐｄｆ）

本発明は以上の問題点を鑑み発案されたものであり、複雑かつ高い性能の必要の無い演算処理はプロセッサで実施し、単純かつ高い性能の必要な演算処理をハードウェアエンジンで実施するエンジン・プロセッサ連携システムにおいて、タイムアウト監視処理を実現するに当たり、タイムアウトイベントが発生しない限りはハードウェア処理回路の動作をとめずに高速に処理をし続けるエンジン・プロセッサ連携システムを実現することを目的とする。

上記課題を解決するための本発明は、エンジン・プロセッサ連携システムであって、セッションに関する情報であるセッションデータをセッション毎に管理しているセッションデータメモリと、入力されたコマンドが属するセッションのセッションデータを前記セッションデータメモリから読み出す読出部と、前記入力されたコマンドとセッションデータとを蓄積する蓄積部と、前記読み出したセッションデータに基づいて、前記蓄積されている入力コマンドとセッションデータをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定部と、前記処理決定部がハードウェア処理部で処理すると決定した場合に、前記入力コマンドを処理し、更に現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定する高速エンジンとを有するハードウェア処理部と、前記処理決定部がソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力コマンドを処理し、更に現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定するソフトウェア処理部とを有し、前記ソフトウェア処理部は、前記セッションデータに設定されたタイムアウトの時刻を監視してタイムアウトが発生したかを検出することを特徴とする。

上記課題を解決するための本発明は、エンジンとプロセッサとの連携方法であって、入力されたコマンドが属するセッションのセッションデータを、セッションに関する情報であるセッションデータをセッション毎に管理しているセッションデータメモリから読み出す読出ステップと、前記入力されたコマンドとセッションデータとを蓄積させる蓄積ステップと、前記読み出されたセッションデータに基づいて、前記蓄積させた入力コマンドとセッションデータをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定ステップと、前記処理決定ステップにおいてハードウェア処理部で処理すると決定した場合にハードウェア処理部で処理し、前記処理決定ステップにおいてソフトウェア処理部で処理すると決定した場合にソフトウェア処理部で処理する処理ステップと、現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定するタイムアウト設定ステップと、前記セッションデータに設定されたタイムアウトの時刻を監視してタイムアウトが発生したかを検出する検出ステップとを有することを特徴とする。

本発明によると、タイムアウト監視処理の実行時には、セッションデータに対するロック処理を行わないため、タイムアウトイベントが実際に発生しない限りは、高速エンジンよりハードウェア処理を性能劣化無く実現することが可能である。

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

符号の説明

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

本発明のエンジン・プロセッサ連携システムは、ソフトウェアで処理するプロセッサとハードウェアで処理する高速エンジンの双方がタイマ部から現在時刻を取得できる構成となっている。

高速エンジン、及び、プロセッサは、各セッションにおける一連のフロー処理を実行する間、該当するセッションデータをロックして読み出しが出来ないようにする。更に、取得した現在時刻を利用して各タイマのタイムアウト時刻を算出して、セッションデータメモリに格納する。

プロセッサは、タイムアウトが発生しているかどうかを各セッションに関してチェックするにあたり、セッションデータのロック状態に関係なく、セッションデータのタイムアウト時刻を読み出し、タイムアウトが発生しているかどうかを監視する。

プロセッサが該当セッションデータを読み出している間に対してのロックはかけていない。そのため、タイムアウト時刻の読み出し中に高速エンジン及びプロセッサが各セッションにおける一連のフロー処理を終了して、セッションデータが更新されることもありうる。しかしながら、セッションメモリ管理部は、タイムアウト時刻の読み出しがアトミックである、すなわち、セッションデータの更新タイミングと、タイムアウト時刻の読み出しタイミングがほぼ同時であった場合、更新前のタイムアウト時刻か、更新後のタイムアウト時刻のどちらかが読まれることを保証する。

以上のように、本発明のエンジン・プロセッサ連携システムは、タイムアウト監視処理の実行時には、セッションデータに対するロック処理を行わないため、タイムアウトイベントが実際に発生しない限りは、高速エンジンよりハードウェア処理を性能劣化無く実現することが可能である。

プロセッサは、タイムアウト監視により、タイムアウトが発生したことを確認すると、タイマ送信回路経由で、セッションの読み出しを実施し、タイムアウト処理を実行する。プロセッサが、タイムアウト状態を検出してから、セッションの読み出しを実施するまでの間に、セッションデータが更新されることもある。よって、プロセッサ、もしくは、処理選択部は、タイムアウト処理用のセッションデータが読み出された際に、タイムアウトが発生しているかどうかを再チェックする。タイムアウト処理対象タイマのタイマ監視がキャンセルされていたり、タイムアウト時刻が再設定されていたりする場合は、タイムアウト処理の実施をキャンセルする。本キャンセル処理により、タイマ監視時にセッションのロックを行わなくても、該当セッションに対する処理の不整合を防止できる。

本発明の特徴を詳細に説明するために、以下において、図面を参照して具体的に述べる。

図１に、発明を実施するための最良の形態におけるエンジン・プロセッサ連携システム８の構成例を示す。

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

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

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

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

セッションメモリ管理部５は、セッションデータメモリ５０に各セッションの固有データ（セッションデータメモリ）を蓄積・管理する。セッションデータメモリ５０が保持しているセッションデータメモリは、セッションデータ読出処理部５２経由で読み出しが行われ、セッションデータ書込処理部５３経由で更新が行われる。

また、セッションロックメモリ５１において、セッションデータのロックをかけることで、セッションデータメモリ５０の該当セッションデータへのアクセスを禁止する機能を有する。具体的には、セッションデータの読み出し後、書込処理が実行されるまでの間、そのセッションデータをロックすることで、次に同一のセッションに対するセッションデータの読み出しコマンドを受信しても、セッションデータ読出部５２は、該当セッションのセッションデータのロックが解除されるまでは該当セッションのセッションデータの読み出しを待ち合わせする。

以上により、前のコマンドの処理が完了してセッションデータが更新される前に、同一セッションの次のコマンドによりセッションデータが読み出しされて、セッションデータの不整合が発生することを防止する。また、セッションデータメモリ５０は、プロセッサバス６とも接続しており、これによりプロセッサ４０はセッションデータメモリ５０のセッションデータにアクセス可能である。

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

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

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

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

受信回路１は、セッションデータ読出処理部５２から入力されるデータを一時的に保持する。

受信回路１は、受信したコマンドデータとセッションデータとをハードウェア処理部３と、ソフトウェア処理部４の両方から読み出しできるためのインタフェースを提供する。

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

ここで、高速エンジン３０で処理すると決定された場合は、高速エンジン３０に通知され、高速エンジン３０は、受信回路１からコマンドデータとセッションデータとを読み出して処理を実行した後で、実行結果を各送信回路２に出力する。

一方、プロセッサ４０で処理すると決定された場合は、プロセッサ４０は、処理管理部３２経由でプロセッサ４０によるコマンド処理の対象であることを識別し、コマンド処理を実行し、実行結果を各送信回路に出力する。

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

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

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

プロセッサ４０は、受信回路１に一時的に保持されているコマンドデータとセッションデータとを処理する以外に、タイマ監視の処理を実施しており、タイムアウトイベントが発生した際には、タイマ送信回路２−３経由でコマンドを送出し、タイマ送信回路２−３は、ＭＵＸ送信回路に対してコマンドを送出する。

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

次に、本発明のエンジン・プロセッサ連携システム８の受信コマンドを処理する動作に関して説明する。図４は、入力された受信コマンドが高速エンジン３０にて処理される場合の、受信コマンドの流れを説明するための図である。

まず、受信コマンドが高速エンジン３０にて処理される際の動作例を示す。

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

セッションデータ読出処理部５２は、セッションデータメモリ５０からセッションデータの読み出しを行い、受信回路１へ出力する。

受信回路１は、パケット・コマンドデータを受信すると、処理選択部３１に対して、パケット受信を通知する。

処理選択部３１では、その受信データを参照し、例えばセッションデータに記述されているセッション状況等に応じてあらかじめ決められた演算ルールに基づいて、高速エンジン３０が処理をすべきか、ソフトウェア処理部４が処理をすべきかを判断して、処理管理部３２に通知する。

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

処理選択部３１は、受信データを高速エンジン３０が処理すべきであることを高速エンジン３０に対して通知することで、高速エンジン３０は、受信データに対して、演算処理を実行し、演算結果に基づいて送出するデータを決定して、各送信回路にデータ送出通知を出力する。ここでの演算処理には、タイムアウト時刻の設定・解除・更新も含まれる。高速エンジン３０は、タイマ部３３より現在時刻を取得し、設定の必要なタイマに関して、タイムアウト時刻を計算してセッションデータを更新する。

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

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

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

本発明のエンジン・プロセッサ連携システム８において、低速なソフトウェア処理を実行するのは、ソフトウェア処理部４である。受信データが高速エンジン３０にて処理される場合は、低速なソフトウェア処理部４を経由することなく、ハードウェア動作だけで動作するため、ソフトウェア処理の介在しない高速処理が可能であることが特徴である。

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

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

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

処理管理部３２は、処理選択部３１から、対象データがソフトウェアの処理対象であることが通知されると、処理状態をソフトウェア処理可能状態に変更する。

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

プロセッサ４０は、受信回路１からパケット・コマンドデータとセッションデータとを読み出して必要な演算処理を実行する。ここでの演算処理には、タイムアウト時刻の設定・解除・更新も含まれる。プロセッサ４０は、タイマ部３３より現在時刻を取得し、設定の必要なタイマに関して、タイムアウト時刻を計算してセッションデータを更新する。

プロセッサ４０は、演算実行後、対象データの処理を行った受信回路１に対して、処理が完了したことをプロセッサバス６経由、若しくは処理管理部３２経由で通知するとともに、各送信回路２に対して、必要なコマンドの送信処理を通知する。

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

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

次に、本発明のエンジン・プロセッサ連携システム８におけるタイムアウト監視処理の動作に関して説明する。

図７は、セッションデータメモリ５０が保持しているセッションデータのセッションエントリの一例を説明知るための図である。尚、セッションデータは、このセッションエントリ以外に、セッション状況等のセッション固有の情報を保持している。

セッションデータメモリ５０のセッションデータのセッションエントリは、セッション番号毎に、セッションデータそのものと、各種タイマのタイムアウト時刻が格納される。図７の例では、タイマ０、タイマ１、タイマ２の３種類のタイマが動作しているものとする。

プロセッサ４０は、タイマ監視機能を有し、一定周期毎にタイマ監視処理を実行する。以下、プロセッサ４０のタイマ監視機能について説明する。

プロセッサ４０は、タイマ部３３より現在時刻を取得する。

プロセッサ４０は、セッションデータメモリ５０にアクセスし、利用中のセッションデータのセッションエントリを参照し、タイマ０，タイマ１、タイマ２のいずれかが、現在時刻よりも小さい値、すなわち、タイムアウトイベントが発生した状態になっていないかをチェックする。

プロセッサ４０は、タイムアウトイベントの発生したセッションが存在すると、タイムアウト処理を実行する。

続いて、タイムアウト処理について説明する。タイムアウト処理は、以下の手順で実行される。

プロセッサ４０は、タイマ送信回路２−３に対して、タイムアウトの発生したセッションに対するタイムアウト処理コマンドの送出を通知するだけである。

タイマ送信回路２−３は、タイムアウト処理コマンドをＭＵＸ回路７に送出し、ＭＵＸ回路７は、コマンドをセッションデータ読出処理部５２に送出する。以降は、上記受信コマンドの処理と同様の動作であり、高速エンジン３０もしくはソフトウェア処理部４にて該当セッションに対するタイムアウト処理が実行される。

タイムアウト処理を、高速エンジン３０とソフトウェア処理部４のどちらで実行するかは、タイムアウトイベントの発生頻度と、処理の複雑度、要求される処理性能といったタイムアウトに関する情報に依存する。タイムアウトイベントは、頻繁に発生する訳ではなく、処理も例外的で複雑であるため、ソフトウェア処理部４で実行されるように設定する。逆に、比較的頻繁にタイムアウトイベントの発生するタイムアウト監視処理、もしくは、高速エンジン３０による高性能プロセッシングで実現する性能を落としたくない状況においては、高速エンジン３０にてタイムアウト処理を実施するように設定する。

次に、上述したタイムアウト処理をソフトウェア処理で実施する場合の動作に関して説明する。

処理選択部３１は、受信回路１から出力されたパケット・コマンドデータとセッションデータとを参照して、タイムアウト処理の要求コマンドであることを識別し、処理管理部３２に対して、プロセッサ４０の処理対象であることを通知する。

プロセッサ４０は、処理管理部３２にアクセスし、プロセッサ４０の処理対象コマンドを受信したことを認識すると、受信回路１内のコマンド内のタイムアウト時刻情報をチェックする。タイムアウトイベントが発生している、すなわち、現在時刻がいずれかのタイマのタイムアウト時刻を超過している場合には、該当するタイマに対するタイムアウト処理を実行する。

一方、どのタイマもタイムアウトイベントが発生していない場合は、タイムアウト処理自体をキャンセルする。タイムアウト処理のキャンセルを実現するには、セッション情報を更新せず、外部送信回路２−２から外部に対してコマンドを出力しなければよい。ここではセッション情報の更新はしないが、該当セッションの読み出しがロック状態になっているため、プロセッサ４０はセッション送信回路２−１経由で、該当セッションの読み出しのロックを解除する会場要求コマンドを送出する。

タイマ監視では、タイムアウト状態を検出したにも関わらず、実際にタイムアウト処理を行う際に、タイムアウト状態が解消されているのは、タイムアウト状態を検出してから、タイムアウト処理実行開始までの間に、セッションデータメモリ５０内の該当セッションエントリが更新されたためである。

タイムアウト監視実行時に該当セッションのセッションエントリをロックすれば、このような問題は、発生しないが、セッションエントリをロックしてしまうと、ロック状態の間は、高速エンジン３０が、該当セッションを処理できなくなってしまうために処理性能が劣化したり、処理遅延にばらつきが発生したりする。

本発明のエンジン・プロセッサ連携システム８では、タイムアウト監視時には、セッションエントリにロックをかけず、タイムアウトの検出を行い、実際にタイムアウト処理を実行する際に、セッションエントリのロックを行い、再度、タイムアウトイベントが発生しているかどうかを再チェックすることで、セッションエントリの整合を取っている。

次に、タイムアウト処理を実行するに当たり、タイマ種別によりプロセッサ４０で実行するのか、高速エンジン３０で実行するのかを切り替える場合の動作に関して説明する。

処理選択部３１は、受信回路１から出力されたコマンドを参照して、タイムアウト処理の要求コマンドであることを識別し、さらに、高速エンジン３０の処理条件をチェックする。

高速エンジン３０の処理条件は、例えば、以下のような条件になる。
・タイマ２でタイムアウトが発生している、もしくは、タイマ３でタイムアウトが発生している、ただし、タイマ２とタイマ３の両方のタイムアウトが同時には発生していない。

上記の例では、タイマ２、もしくは、タイマ３のどちらか片方だけがタイムアウトが発生している場合は、高速エンジン３０にてタイムアウト処理が実行され、その他の条件、例えば、タイマ１でタイムアウトが発生したり、タイマ２とタイマ３の両方でタイムアウトが発止していたり、いずれのタイマもタイムアウトが発生していない異常処理のような場合は、プロセッサ４０にて処理が実行される。

次に、タイムアウト処理を実行するに当たり、タイマ種別によりプロセッサ４０で実行するのか、高速エンジン３０で実行するのかを切り替えるが、タイムアウトがどのタイマでも発生していない異常処理を高速エンジンで処理する場合の動作例に関して説明する。

処理選択部３１は、受信回路１から出力されたコマンドを参照して、タイムアウト処理の要求コマンドであることを識別し、さらに、高速エンジン３０の処理条件をチェックする。

高速エンジン３０の処理条件は、例えば、以下のような条件になる。
・タイマ２でタイムアウトが発生している、もしくは、どのタイマもタイムアウトが発生していない。

高速エンジン３０は、タイマ２のタイムアウトが発生している場合は、タイマ２に対するタイムアウト処理を実施する。どのタイマもタイムアウトが発生していない場合は、タイムアウト処理をキャンセルするために、セッション送信回路２−１経由で、セッションデータ書込処理部に対して、該当セッションのロック解除要求コマンドを送出する。

次に、エンジン・プロセッサ連携システム８の動作タイミングについて説明する。

図８は、エンジン・プロセッサ連携システム８の動作タイミングの一例である。

ＭＵＸ回路７に入力されたパケット・コマンドデータは、セッション読出処理部５２での処理、高速エンジン３０での処理、セッションデータ更新処理部５３での処理という順に実行されていく。

図８の各処理内の数字は、セッション番号とパケット番号を意味する。例えば、１−２は、セッション番号１の２番目のパケットである。

タイマ監視処理は、ソフトウェア処理部４で実行されるため、ハードウェア処理部３で実行されるセッション読み出し、高速エンジン３０での演算処理、セッションデータ更新処理部５３でのセッションデータ更新の処理よりも遅いのが普通である。尚、図８の例では、高速エンジン３０の処理に比べて7倍の時間を要している場合を示しているが、実際の処理では数十倍から数百倍の差があることも珍しくない。

本発明のエンジン・プロセッサ連携システム８では、セッション１のタイマ監視を実現するに当たり、セッションデータメモリに対するロック処理を行わないので、セッション1のタイマ監視中に、受信したセッション１のコマンドに対する高速エンジン３０の処理を停止する必要がない。よって、タイマ監視処理の影響により、性能が劣化したり、処理遅延量が増加したり、更に、処理遅延量が揺らいでしまったりというような現象を防止することが可能である。

上述したとおり、本発明のエンジン・プロセッサ連携システムでは、プロセッサと高速エンジンの双方が現在時刻を取得可能なタイマ部を有し、高速エンジン、及び、プロセッサは、セッション処理を実行する際に、前記現在時刻を利用して各タイマのタイムアウト時刻を算出して、セッションメモリに格納する。プロセッサ部は、タイムアウトが発生しているかどうかを各セッションに関してチェックするにあたり、セッションデータのロック状態に関係なく、セッションエントリ内のタイムアウト時刻の読み出しを行い、タイムアウトが発生しているかどうかを確認する。該当セッションデータに対してロックをかけていないため、タイムアウト時刻の読み出し中にセッション情報が更新されることもありうるが、セッションメモリ管理部は、タイムアウト時刻の読み出しがアトミックである、すなわち、セッションデータの更新タイミングと、タイムアウト時刻の読み出しタイミングがほぼ同時であった場合、更新前のタイムアウト時刻か、更新後のタイムアウト時刻のどちらかが読まれることを保証する。以上のように、本発明のエンジン・プロセッサ連携システムは、タイムアウト監視処理の実行時には、セッションデータに対するロック処理を行わないため、タイムアウトイベントが実際に発生しない限りは、高速エンジンよりハードウェア処理を性能劣化無く実現することが可能である。

また、プロセッサは、タイムアウト監視により、タイムアウトが発生したことを確認すると、タイマ送信回路経由で、セッションの読み出しを実施し、タイムアウト処理を実行する。プロセッサが、タイムアウト状態を検出してから、セッションの読み出しを実施するまでの間に、セッションデータが更新されることもある。

よって、プロセッサ、もしくは、処理選択部は、タイムアウト処理用のセッションデータが読み出された際に、タイムアウトが発生しているかどうかを再チェックする。タイムアウト処理対象タイマのタイマ監視がキャンセルされていたり、タイムアウト時刻が再設定されていたりする場合は、タイムアウト処理の実施をキャンセルする。

本キャンセル処理により、タイマ監視時にセッションのロックを行わなくても、該当セッションに対する処理の不整合を防止できる。

本出願は、２００７年３月２９日に出願された日本出願特願２００７−０８９００９号を基礎とする優先権を主張し、その開示の全てをここに取り込む。

Claims (8)

1. エンジン・プロセッサ連携システムであって、
   セッションに関する情報であるセッションデータをセッション毎に管理しているセッションデータメモリと、
   入力されたコマンドが属するセッションのセッションデータを前記セッションデータメモリから読み出す読出部と、
   前記入力されたコマンドとセッションデータとを蓄積する蓄積部と、
   前記読み出したセッションデータに基づいて、前記蓄積されている入力コマンドとセッションデータをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定部と、前記処理決定部がハードウェア処理部で処理すると決定した場合に、前記入力コマンドを処理し、更に現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定する高速エンジンとを有するハードウェア処理部と、
   前記処理決定部がソフトウェア処理部で処理すると決定した場合に、前記蓄積されている入力コマンドを処理し、更に現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定するソフトウェア処理部と
   を有し、
   前記ソフトウェア処理部は、前記セッションデータに設定されたタイムアウトの時刻を監視してタイムアウトが発生したかを検出する
   ことを特徴とするエンジン・プロセッサ連携システム。
2. 前記ソフトウェア処理部がタイムアウトを検出すると、タイムアウトに関する処理を行うためのタイムアウトコマンドを前記読出部に送信するタイムアウトコマンド送信部を有することを特徴とする請求項１に記載のエンジン・プロセッサ連携システム。
3. 前記読出部は、前記高速エンジン又は前記ソフトウェア処理部で前記蓄積されている入力コマンドを処理している間は、その入力コマンドが属するセッションのセッションデータを読み出さないように読出禁止の設定をすることを特徴とする請求項１又は請求項２に記載のエンジン・プロセッサ連携システム。
4. 前記処理決定部は、前記入力コマンドがタイムアウトに関する処理を行うためのタイムアウトコマンドである場合、前記ソフトウェア処理部で処理することを決定し、
   前記ソフトウェア処理部は、タイムアウトコマンドを処理する際に、現在時刻と前記設定されたタイムアウト時刻とを比較してタイムアウトが発生しているかを監視し、タイムアウトが発生していない場合は、前記設定された読出禁止の設定を解除することを特徴とする請求項３に記載のエンジン・プロセッサ連携システム。
5. 前記処理決定部は、前記入力コマンドがタイムアウトに関する処理を行うためのタイムアウトコマンドである場合、現在時刻と前記設定されたタイムアウト時刻とを比較してタイムアウが発生しているかを監視し、タイムアウトが発生していない場合は、前記ソフトウェア処理部がその入力コマンドを処理することを決定することを特徴とする請求項３に記載のエンジン・プロセッサ連携システム。
6. 前記処理決定部は、前記入力コマンドがタイムアウトに関する処理を行うためのタイムアウトコマンドである場合、現在時刻と前記設定したタイムアウト時刻とを比較してタイムアウトが発生しているかを監視し、タイムアウトが発生していない場合は、前記高速エンジンが前記設定された読出禁止の設定を解除することを特徴とする請求項３に記載のエンジン・プロセッサ連携システム。
7. 前記設定された読出禁止の設定を解除する際、セッションデータの更新は行わないことを特徴とする請求項４から請求項６のいずれかに記載のエンジン・プロセッサ連携システム。
8. エンジンとプロセッサとの連携方法であって、
   入力されたコマンドが属するセッションのセッションデータを、セッションに関する情報であるセッションデータをセッション毎に管理しているセッションデータメモリから読み出す読出ステップと、
   前記入力されたコマンドとセッションデータとを蓄積させる蓄積ステップと、
   前記読み出されたセッションデータに基づいて、前記蓄積させた入力コマンドとセッションデータをソフトウェアで処理するかハードウェア処理部で処理するかを決定する処理決定ステップと、
   前記処理決定ステップにおいてハードウェア処理部で処理すると決定した場合にハードウェア処理部で処理し、前記処理決定ステップにおいてソフトウェア処理部で処理すると決定した場合にソフトウェア処理部で処理する処理ステップと、
   現在の時刻を取得してタイムアウト時刻を算出して、前記セッションデータにタイムアウトの時刻を設定するタイムアウト設定ステップと、
   前記セッションデータに設定されたタイムアウトの時刻を監視してタイムアウトが発生したかを検出する検出ステップと
   を有することを特徴とする連携方法。
   

Images