(57)【要約】【課題】メモリ使用効率を向上させ、フレームのレイテンシを小さくし、かつ、ＣＰＵの負荷を低減することができる、受信フレーム処理装置および受信フレーム処理システムを提供する。【解決手段】ネットワーク２から可変長のフレームを受信し、システムメモリ４上に設けられＣＰＵ５との共有領域であるバッファ群４２にフレームを転送する受信フレーム処理装置であって、バッファ４２は複数のバッファから構成されており、第１のフレームを第１のバッファに転送してから一定時間が経過する前に第２のフレームを受信した場合には、第２のフレームを第１のバッファに転送し、第１のフレームを第１のバッファに転送してから一定時間以上経過した後に第２のフレームを受信した場合には、第１のバッファの所有権をＣＰＵ５に譲渡した後に第２のフレームを第２のバッファに転送することを特徴とする。【選択図】図１
2008252748.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークから可変長のフレームを受信し、システムメモリ上に設けられＣＰＵとの共有領域であるバッファ領域に前記フレームを転送する受信フレーム処理装置であって、
前記バッファ領域は複数のバッファから構成されており、第１のフレームを第１のバッファに転送してから一定時間が経過する前に第２のフレームを受信した場合には、前記第２のフレームを前記第１のバッファに転送し、前記第１のフレームを前記第１のバッファに転送してから一定時間以上経過した後に前記第２のフレームを受信した場合には、前記第１のバッファの所有権を前記ＣＰＵに譲渡した後に前記第２のフレームを第２のバッファに転送することを特徴とする、受信フレーム処理装置。
【請求項２】
前記第１のフレームを格納した後の前記第１のバッファの空き容量が、前記第２のフレームの長さよりも小さい場合、前記第１のバッファの所有権を前記ＣＰＵに譲渡した後に前記第２のフレームを前記第２のバッファに転送することを特徴とする、請求項１に記載の受信フレーム処理装置。
【請求項３】
前記第１のフレームを格納した後の前記第１のバッファの空き容量が、前記ネットワークの規格の仕様上のフレームの最小長さよりも小さい場合、前記第１のバッファの所有権を前記ＣＰＵに譲渡した後に前記第２のフレームを前記第２のバッファに転送することを特徴とする、請求項１叉は請求項２に記載の受信フレーム処理装置。
【請求項４】
前記ＣＰＵに一定数の前記バッファの所有権を譲渡した時点で割り込みを発生させることを特徴とする、請求項１乃至請求項３のいずれか一項に記載の受信フレーム処理装置。
【請求項５】
ＣＰＵと、
システムメモリと、
ネットワークから可変長のフレームを受信し、システムバスを介して前記システムメモリ上に設けられ前記ＣＰＵとの共有領域であるバッファ領域に前記フレームを転送するネットワークコントローラと
から構成される受信フレーム処理システムであって、
前記バッファ領域は複数のバッファから構成されており、第１のフレームを第１のバッファに転送してから一定時間が経過する前に第２のフレームを受信した場合には、前記第２のフレームを前記第１のバッファに転送し、前記第１のフレームを前記第１のバッファに転送してから一定時間以上経過した後に前記第２のフレームを受信した場合には、前記第１のバッファの所有権を前記ＣＰＵに譲渡した後に前記第２のフレームを第２のバッファに転送することを特徴とする、受信フレーム処理システム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、受信フレーム処理装置および受信フレーム処理システムに関し、特に、ネットワークから受信した可変長のフレームを処理する、受信フレーム処理装置および受信フレーム処理システムに関する。
【背景技術】
【０００２】
イーサネット（登録商標）やＩＥＥＥ１３９４、ＵＳＢといった通信方式では、可変長のフレームを単位としたデータの送受信により通信を行っている。一般的に、コンピュータシステム（以下、単にシステムと示す）がネットワークからデータを取り込む際には、受信したフレームをシステムメモリに設けられたバッファに一時的に格納し、バッファから必要なフレームを所定の規則に従って読み出す方式を用いている。
【０００３】
従来の代表的なバッファ管理方法としては、１つのバッファに１つのフレームのみを格納する管理方法（以下、アンパックモードと示す）と、１つのバッファに１つ以上のフレームを格納する管理方法（以下、パックモードと示す）とが挙げられる。
【０００４】
従来のアンパックモードでは、バッファごとに１つのフレームのみを格納し、空き容量があったとしても次のフレームを詰めて格納することをしない。従って、バッファメモリの使用効率が低下してしまうという問題があった。
【０００５】
従来のアンパックモードでも、バッファサイズを小さくすることで、バッファメモリの使用効率を向上させることは可能である。しかし、バッファサイズが小さくなることによってバッファ数が増えるために、逆にバッファ管理領域は大きくなってしまうという別の問題が発生する。
【０００６】
また、従来のパックモードでは、１つのバッファに１つ以上のフレームを詰めて格納する。そのため、フレームを格納中のバッファは、十分な空き容量がある場合には開放されない（システム側に所有権が譲渡されない）。従って、特に、フレームの受信間隔が長い場合には、フレームを受信してから処理するまでの遅延時間（以下、レイテンシと示す）が大きくなってしまうという問題があった。
【０００７】
従来のパックモードでも、システム側でタイムアウト処理を行い、フレーム受信が一定時間発生しない時点で、バッファの所有権を無視して強制的にバッファに格納されているフレームの内容を読み込むことでレイテンシを小さくすることは可能ではある。しかし、その際は、システム側で、タイムアウトの機構を用意する必要があり、所有権を取得していないバッファから読み取ったフレーム箇所をシステム側で記憶しておく必要がある。
【０００８】
さらに、次回、所有権がシステム側に譲渡されたときに、同じバッファを読み込む際は、すでに読み取ったフレームについては、読み飛ばす等の処理が必要となる。バッファの所有権に関わらずシステム側からバッファを読み出すことでパックモードであっても、レイテンシを小さくすることは可能であるが、システム側での処理が複雑になってしまうという別の問題が発生する。
【０００９】
更に、従来のバッファ管理技術では、割り込みの発生によってフレームの到着をシステムに通知する場合、フレーム毎に割り込みを発生させることが多い。フレームの受信毎に割り込みを発生させると、フレームの受信頻度が高くなるにともない、割り込み頻度が高くなり、ＣＰＵの負荷が高くなるという問題もあった。
【００１０】
また、従来、可変長のフレームを扱う受信フレーム処理装置として、長さの異なる複数のバッファを具備しておき、受信したフレームの長さに応じて格納するバッファを切り替える受信フレーム処理装置が提案されている（例えば、特許文献１参照）。
【００１１】
特許文献１に記載された提案によれば、１つのバッファに１つのフレームを格納することを前提として、事前に受信するフレームの長さを予測してバッファの長さと個数とを準備しておく。しかしながら、実際に受信したフレームの長さが準備されたバッファの長さと大きく異なる場合、例えば、長いフレームを受信することを予測しての長いバッファを多数用意しておいたにも関わらず、短いフレームを多数受信した場合、長いバッファに短いフレームを格納することとなり、バッファメモリの使用効率が低下してしまうという問題があった。また、短いバッファを多数準備する場合、バッファ数が増加するために、バッファの情報を格納してバッファを管理するためのメモリ領域が増大してしまうという問題があった。
【００１２】
更に、異なるサイズの連続したフレームを受信した際に、それぞれのフレーム格納場所が、システムメモリ上で飛び飛びの位置に分散してしまう。フレームがシステムメモリ上に連続して配置される場合と比較して、フレームが飛び飛びの位置に配置された場合には、ＣＰＵのキャッシュが効率よく機能せず、ＣＰＵの負荷が高くなってしまうという問題があった。また、他にも、空いているバッファのうちから適切なサイズのバッファを選択するための仕組みが必要になるといった問題があった。
【特許文献１】特開２００２−１８５４６６号公報
【発明の開示】
【発明が解決しようとする課題】
【００１３】
本発明は、以上の点に鑑みてなされたもので、メモリ使用効率を向上させ、フレームのレイテンシを小さくし、かつ、ＣＰＵの負荷を低減することができる、受信フレーム処理装置および受信フレーム処理システムを提供することを目的とする。
【課題を解決するための手段】
【００１４】
本発明の一形態に係る受信フレーム処理装置は、ネットワークから可変長のフレームを受信し、システムメモリ上に設けられＣＰＵとの共有領域であるバッファ領域に前記フレームを転送する受信フレーム処理装置であって、前記バッファ領域は複数のバッファから構成されており、第１のフレームを第１のバッファに転送してから一定時間が経過する前に第２のフレームを受信した場合には、前記第２のフレームを前記第１のバッファに転送し、前記第１のフレームを前記第１のバッファに転送してから一定時間以上経過した後に前記第２のフレームを受信した場合には、前記第１のバッファの所有権を前記ＣＰＵに譲渡した後に前記第２のフレームを第２のバッファに転送することを特徴とする。
【発明の効果】
【００１５】
メモリ使用効率を向上させ、フレームのレイテンシを小さくし、かつ、ＣＰＵの負荷を低減することができる。
【発明を実施するための最良の形態】
【００１６】
以下、図面を参照して本発明の実施の形態を説明する。
【００１７】
（第１の実施の形態）
始めに、本発明の第１の実施の形態に係わる受信フレーム処理装置１の構成について、図１を用いて説明する。図１は、本発明の実施の形態に係わる受信フレーム処理装置１の構成を説明するブロック図である。
【００１８】
本実施の形態の受信フレーム処理装置１は、図１に示すように、イーサネット（登録商標）などの通信方式を使用して可変長フレームを通信するネットワーク２、及び、コンピュータシステムとの間でデータを送受信するためのシステムバス３と電気的に接続されている。システムバス３には、受信フレーム処理装置１を介してネットワーク２から受信したフレームや、各種データを格納するためのシステムメモリ４と、これらのフレーム、データを用いて各種処理を行うＣＰＵ５とも接続されている。
【００１９】
受信フレーム処理装置１では、ネットワーク２から受信したフレームが、フレーム処理部１２を介して小容量メモリ１１に一時的に格納される。この小容量メモリ１１は、一般的にＦＩＦＯなどで構成されており、主にシステムバス３を経由してシステムメモリ４へバースト転送（フレームを連続的にシステムバス３に送り出す転送方法）を行うためのバッファとして利用される。ネットワーク２から到着したフレームがあっても、システムバス３が混んでいる状態では、すぐにフレームをシステムメモリ４に転送できない。このような場合に、一度、小容量メモリ１１にフレームを一時的に格納し、バースト転送を行う。
【００２０】
また、ネットワーク２とシステムバス３とでクロック(動作周波数)が異なる場合が多いため、異なるクロックドメイン間でフレームをやりとりするための緩衝用メモリとしても小容量メモリ１１が利用される。
【００２１】
また、ネットワーク２から受信したフレームは、フレーム処理部１２に出力されて解析され、フレーム長やフレーム間隔などが検出・測定される。なお、小容量メモリ１１に格納するフレームは、フレーム処理部１２を介さずに直接ネットワーク２から受信するような構成にしてもよい。
【００２２】
フレーム処理部１２で解析されたフレームに関する情報は、主制御部１３に出力される。主制御部１３では、取得したフレームに関する情報、特に、フレーム長やフレームの受信間隔と、レジスタ部１５に格納されている各種制御情報・ステータス情報とに基づき、システムメモリ４におけるフレームの格納方法を決定する。すなわち、次に出力するフレームを、直前に出力したフレームと同じバッファに格納するのか、別のバッファに格納するのかを決定する。なお、主制御部１３には、カウンタ２１も接続されており、フレームの受信間隔などの測定は、このカウンタ２１を利用することができるように構成されている。
【００２３】
主制御部１３は、決定したフレームの格納方法に基づき、小容量メモリ１１に一時的に格納されているフレームを、ＤＭＡ制御部１４、システムバス３を介してシステムメモリ４の所定のバッファに出力する。
【００２４】
また、主制御部１３には割り込み制御部１６も接続されている。割り込み制御部１６は、図示しない割り込みコントローラなどに接続されており、所定のタイミングで、割り込みコントローラを介してＣＰＵ５に対して割り込みの発生を通知する。なお、図示しない割り込みコントローラを介さずに、割り込みコントローラを内蔵したＣＰＵ５に直接割り込みの発生を通知する場合もある。
【００２５】
システムメモリ４には、図２に示すように、受信フレーム処理装置１から受信したフレームを格納するためのバッファ群４２の領域と、バッファ群４２に関する情報を格納するためのバッファ管理情報群４１の領域とが予め確保されている。図２は、システムメモリ４の構成を説明する概略図である。なお、バッファ管理情報群４１と、バッファ群４２との領域は、受信フレーム処理装置１とＣＰＵ５との間で共有されている。
【００２６】
バッファ群４２は、複数のバッファ４２ａ〜４２ｄから構成されており、各バッファ４２ａ〜４２ｄには受信フレーム処理装置１から受信したフレームが格納される。バッファ管理情報群４１は、バッファ群４２に含まれるバッファと同じ個数のバッファ管理情報４１ａ〜４１ｄから構成されており、各バッファ管理情報４１ａ〜４１ｄには、対応するバッファ４２ａ〜４２ｄに関する各種情報（所有権、格納モード、格納されているフレームの位置、など）が格納されている。
【００２７】
ここで、バッファの所有権とは、対応するバッファのアクセス権（更新権）が受信フレーム処理装置１とＣＰＵ５とのどちらにあるのかを表わす情報である。バッファの所有権を有する側が、当該バッファと対応するバッファ管理情報に対するアクセス権（更新権）を持っており、当該バッファ及びバッファ管理情報に対する処理が完了すると、もう一方の側に所有権が譲渡される。このようにして、受信フレーム処理装置１とＣＰＵ５とは、システムメモリ４を介して互いに情報を送受信する仕組みになっている。
【００２８】
また、格納モードとは、対応するバッファに複数のフレームを格納できるモード（以下、パックモードと示す）なのか、１つのフレームしか格納できないモード（以下、アンパックモードと示す）なのかを表わす情報である。
【００２９】
バッファ管理情報４１ａは、様々な表わし方が可能であるが、例えば次のように具体的に表わすことができる。まず、受信するフレームがすべて固定長であり、オフセット値として別の箇所に格納されている場合について、図３を用いて説明する。図３は、フレームが固定長の場合のバッファ管理情報の具体例を説明する図である。図３は、１つのバッファにフレームを最大４つまで格納できる場合を示している。
【００３０】
まず、対応するバッファ４２ａの格納モードがパックモードかアンパックモードかを示すモード情報４１０が先頭に書き込まれる。続いて、バッファ４２ａに格納されているフレームについて、開始オフセット値４１１ａと終了オフセット値４１１ｂとが書き込まれる。フレームが複数格納されている場合は、格納された順に、それぞれのフレームについて開始オフセット値４１２ａ，４１３ａ，４１４ａと終了オフセット値４１２ｂ，４１３ｂ，４１４ｂとが書き込まれる。最後に、対応するバッファ４２ａの所有権を有するのが受信フレーム処理装置１であるかＣＰＵ５であるかを示す所有ビット４１５が書き込まれる。
【００３１】
なお、当該バッファ４２ａに格納されるフレーム数が２個、または３個の場合、これ以降はフレームが格納されていないことを示す仕組みが設けられている。例えば、フレームが格納されない部分の開始オフセット値（格納されるフレーム数が２個の場合は３個目のフレームの開始オフセット値４１３ａ、格納されるフレーム数が３個の場合は４個目のフレームの開始オフセット値４１４ａ）に０などの予め定められた値が書き込まれる。
【００３２】
次に、受信するフレームが可変長である場合について、図４と図５とを用いて説明する。図４は、フレームが可変長で格納モードがアンパックモードの場合のバッファ管理情報の具体例を説明する図であり、図５は、フレームが可変長で格納モードがパックモードの場合のバッファ管理情報の具体例を説明する図である。
【００３３】
格納モードがアンパックモードであり、対応するバッファ４２ａに１つのフレームしか格納されていない場合、図４に示すように、バッファ管理情報４１ａには、対応するバッファ４２ａの格納モードがアンパックモードであることを示すモード情報４１０が先頭に書き込まれる。続いて、バッファ４２ａに格納されているフレームのフレーム長４１６が書き込まれる。
【００３４】
更に、当該フレームの先頭部分が含まれているか否かを示すフレーム先頭ビット４１７と、当該フレームの末尾部分が含まれているか否かを示すフレーム末尾ビット４１８が書き込まれる。フレームの長さがバッファの長さより大きい場合、フレームが複数のバッファに分割されて格納されることになる。しかし、ＣＰＵ５がフレームを用いて処理を行う場合にはフレーム全体にアクセスする必要があるため、フレーム先頭ビット４１７とフレーム末尾ビット４１８とを参照して、フレームが格納されたバッファを識別する。
【００３５】
例えば、フレーム先頭ビット４１７とフレーム末尾ビット４１８の両方がオンの場合、当該バッファ４２ａには１つのフレーム全体が格納されていると識別される。また、例えば、フレーム先頭ビット４１７はＯＮであるが、フレーム末尾ビット４１８はＯＦＦの場合、当該バッファ４２ａにはフレームの一部分が格納されており、続くバッファ４２ｂ以降にフレームの残り部分が格納されていると識別される。
【００３６】
バッファ管理情報４１ａの最後には、当該バッファ４２ａの所有権の所在を示す所有ビット４１５が書き込まれる。
【００３７】
格納モードがパックモードであり、対応するバッファ４２ａに複数のフレームが格納されている可能性がある場合、システムメモリ４にはフレーム管理情報群４３を格納する領域が設けられており、バッファ４２ａに関する情報は、図５に示すように、バッファ管理情報４１ａとフレーム管理情報群４３とに格納される。
【００３８】
バッファ管理情報４１ａには、対応するバッファ４２ａの格納モードがアンパックモードであることを示すモード情報４１０が先頭に書き込まれる。続いて、フレーム管理情報４３において、バッファ４２ａに格納されているフレームに関する情報の記載位置を特定するために、フレーム管理情報群４３の先頭アドレス４１９（以下、フレーム情報先頭アドレスと示す）が書き込まれる。
【００３９】
図５には、対応するバッファ４２ａに３つの可変長フレームが格納されている例を示しており、各フレームはフレーム管理情報４３ａ〜４３ｃとしてフレーム管理情報群４３に格納されている。この場合、バッファ管理情報４１ａのフレーム情報先頭アドレス４１９には、フレーム管理情報４３ａの先頭のアドレスが書き込まれる。
【００４０】
フレーム情報４３ａ〜４３ｃには、格納されているフレームの長さ４１６と、当該フレーム管理情報の所有権を有するのが受信フレーム処理装置１であるかＣＰＵ５であるかを示す、フレーム管理所有ビット４１７と、当該フレームがバッファ４２ａに格納されている最後のフレームであるか否かを示す終端ビット４１８とが書き込まれる。図５に示す例の場合、バッファ４２ａには３つのフレームが格納されているので、フレーム情報４３ａ，４３ｂの終端ビット４１８はＯＦＦであり、フレーム情報４３ｃの終端ビットはＯＮと書き込まれる。
【００４１】
バッファ管理情報４１ａの最後には、当該バッファ４２ａの所有権の所在を示す所有ビット４１５が書き込まれる。
【００４２】
なお、アンパックモードでも、図５に示すようなバッファ管理情報を用いることができる。例えば、バッファ４２ａがアンパックモードで可変長フレームが格納されている場合、フレーム情報４３ａには、格納されているフレームの長さ４１６と、当該フレーム管理情報の所有権を有するのが受信フレーム処理装置１であるかＣＰＵ５であるかを示す、フレーム管理所有ビット４１７と、当該フレームがバッファ４２ａに格納されている最後のフレームであるか否かを示す終端ビット４１８とが書き込まれる。図５に示す例の場合、バッファ４２ａには１つのフレームが格納されているので、フレーム情報４３ａの終端ビットはＯＮと書き込まれる。
【００４３】
次に、上述した受信フレーム処理装置１における受信フレーム処理方法（受信したフレームをバッファ群４２に格納する方法）について、図６を用いて説明する。図６は、本発明の第１の実施の形態に係わる受信フレームの処理手順を説明するフローチャートである。
【００４４】
まず、ステップＳ１において、受信フレーム処理装置１の各部を初期化する。この初期化の具体的な作業としては、例えば、ＣＰＵ５によって各種設定値が書き込まれる作業が挙げられる。
【００４５】
なお、このステップＳ１と同時に、ＣＰＵ５は、システムメモリ４内からバッファ群４２やバッファ管理情報群４１のための領域を確保し、所有権を受信フレーム処置装置１にセットする。この作業と各設定値の書き込みが終わった時点で、ＣＰＵ５が、レジスタ部１５のある場所に書き込みを行うことで、受信フレーム処置装置１に動作開始の合図を送る。動作開始の合図を受け取った受信フレーム処置装置１は、主制御部１３によってカウンタ２１などをリセットして、動作を開始する。
【００４６】
次に、ステップＳ２において、システムメモリ４のバッファ管理情報群４１から最初のバッファ管理情報４１ａを参照し、対応するバッファ４２ａのアドレスを取得する。続いて、ステップＳ３において、ネットワーク２からフレームの到着を待機する。
【００４７】
フレームが到着すると、ステップＳ４に進んでフレームの受信を開始する。本ステップにおいては、受信したフレームは逐次小容量メモリ１１に書き込まれる。また、当該フレームと、直前に受信したフレーム（以下、前フレームと示す）との間の時間間隔（具体的には、前フレームの受信終了時から、当該フレームの受信開始時までの時間、以下、フレーム間隔と示す）を、フレーム処理部１２で算出する。なお、当該フレームがネットワーク２から最初に受信するフレームであり、前フレームが存在しない場合、フレーム間隔はゼロとする。
【００４８】
次に、ステップＳ５に進み、主制御部１３において、ステップＳ４で算出したフレーム間隔と、予め設定されている閾値Ｔｔｈとを比較する。ここで、閾値Ｔｔｈは受信したフレームの格納モードを切り替えるために用いる値であり、ネットワーク速度、ネットワークの最小フレームギャップ、単位時間当たりのＣＰＵ５の処理の負荷が最も大きくなるフレームサイズ、ＣＰＵ５の処理時間、などから決定される。閾値Ｔｔｈはレジスタ部１５などに格納されており、必要に応じて適宜再設定可能になされている。
【００４９】
ステップＳ５において、フレーム間隔が閾値Ｔｔｈ未満であると判定された場合、主制御部１３は受信したフレームをパックモードで格納することを決定する。この場合、ステップＳ６に進み、フレームの格納先としてアドレスを取得しているバッファに対し、受信したフレームを転送開始する。具体的には、主制御部１３の制御に従って、小容量メモリ１１に書き込まれたフレームをＤＭＡ制御部１４を介してシステムバス３に出力し、システムメモリ４に準備されたバッファに書き込む。
【００５０】
なお、本ステップは、通常、小容量メモリ１１がネットワーク２からフレームを受信している最中に実行される。すなわち、小容量メモリ１１は、ネットワーク２からフレームを受信しつつ、受信したフレームを逐次主制御部１３，ＤＭＡ制御部１４を介してシステムバス３に出力する。
【００５１】
一方、ステップＳ５において、フレーム間隔が閾値Ｔｔｈ以上であると判定された場合、主制御部１３は受信したフレームをアンパックモードで格納することを決定する。この場合、ステップＳ７に進み、バッファ管理情報４１ａの必要な部分を更新し、所有権をＣＰＵ５に返却する。続いてステップＳ８に進み、システムメモリ４のバッファ管理情報群４１から次のバッファ管理情報４１ｂを参照し、対応するバッファ４２ｂのアドレスを取得してステップＳ６に進む。
【００５２】
ステップＳ６において、システムメモリ４の適切なバッファへフレームの転送を開始し、所定時間が経過すると、ネットワーク２から小容量メモリ１１へのフレームの書き込みが終了する（ステップＳ９）。ステップＳ９においては、当該フレームと、当該フレームの直後に到着するフレーム（以下、次フレームと示す）との間のフレーム間隔を測定するために、小容量メモリ１１でのフレームの受信が終了した時点で、カウンタ２１に設けられたフレーム間隔タイマ用のカウンタが主制御部１３によってリセットされ、直ちにフレーム間隔の測定を開始する。
【００５３】
続いて、ステップＳ１０において、システムメモリ４の適切なバッファへフレームの転送が終了すると、フレームを格納したバッファの対応するバッファ管理情報に受信ステータス（正常にフレームが転送された、フレームの転送中にエラーが発生した、などを識別する情報）を書き込む。
【００５４】
続いて、ステップＳ１１において、当該フレームが書き込まれたバッファに空き容量があるか否かを判定する。ステップＳ１１において、バッファ境界に達しておらず、当該バッファに空き容量があると判定された場合、ステップＳ１２に進み、次フレームが到着するのを待機する。
【００５５】
一方、ステップＳ１１において、バッファ境界に達しており、当該バッファに空き容量がないと判定された場合、ステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。続いてステップＳ２に戻り、システムメモリ４のバッファ管理情報群４１から次のバッファ管理情報を参照し、対応するバッファのアドレスを取得して、次フレームの到着を待機する。
【００５６】
ステップＳ１２において、フレームが到着した場合、ステップＳ４に戻ってフレームの受信を開始する。一方、フレームが到着しない場合、ステップＳ１４に進み、ステップＳ９において測定を開始したフレーム間隔タイマがタイムアウトしたか否かを判定する。具体的には、その時点でのフレーム間隔タイマの値と閾値Ｔｔｈとを比較し、タイマの値が閾値Ｔｔｈ以上の場合にタイムアウトしたものと判定する。
【００５７】
ネットワーク２から受信するフレームの受信間隔が長い場合、パックモードでバッファにフレームを格納していると、バッファのメモリを使い切ってしまうまで当該バッファの所有権がＣＰＵ５の譲渡されないためにフレームのレイテンシが低下してしまう。そこで、フレーム間隔タイマを用い、一定時間フレームが受信されない場合にはタイムアウトとしてサインを発生させることで、バッファの所有権をＣＰＵ５に譲渡してフレームのレイテンシを向上させることができる。
【００５８】
ステップＳ１４において、フレーム間隔タイマがタイムアウトしていないと判定された場合、ステップＳ１２に戻り、次フレームの到着を待機する。一方、ステップＳ１４において、フレーム間隔タイマがタイムアウトしたと判定された場合、ステップＳ１５に進み、フレーム間隔タイマ用のカウンタを主制御部１３によってリセットする。続いてステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。
【００５９】
受信フレーム処理装置１が動作中は、上述のステップＳ２〜ステップＳ１５の処理が繰り返し実行され、ネットワーク２から受信したフレームをシステムメモリ４のバッファ群４２の適切なバッファに書き込んでいく。
【００６０】
図６のフローチャートを用いて説明した受信フレーム処理方法を、図７及び図８に示す具体的な例を用いて更に詳しく説明する。図７は、ネットワーク２からフレームを受信している状況の一例を説明するタイムチャートである。図７において、横軸は受信フレーム処理装置１が動作開始してからの経過時間ｔを示している。また、図８は、受信したフレームをバッファ群４２に格納する際の格納位置を説明する概略図である。
【００６１】
まず、受信フレーム処理装置１が動作を開始し、初期化（ステップＳ１）が完了すると、システムメモリ４のバッファ管理情報群４１から最初のバッファ管理情報４１ａを参照し、最初に到着するフレームの格納先として、対応するバッファ４２ａのアドレスを取得する（ステップＳ２）。続いて、ステップＳ３において、ネットワーク２からフレームの到着を待機する。
【００６２】
フレーム０が受信フレーム処理装置１に到着し、ステップＳ４において時間ｔ０ｓに受信を開始すると、フレーム間隔が測定される。ここで、フレーム０は最初に受信フレーム処理装置１に到着するフレームであり、前フレームが存在しないため、フレーム間隔はゼロとなる。次に、ステップＳ５において、ステップＳ４で算出したフレーム間隔（＝ゼロ）と、予め設定されている閾値Ｔｔｈとを比較する。
【００６３】
ここでは、０＜Ｔｔｈであるので、ステップＳ６へ進み、フレームの格納先としてアドレスを取得しているバッファ４２ａに対し、受信したフレーム０を転送開始する。所定時間が経過して時間ｔ０ｅになると、ネットワーク２からフレーム０の受信が終了する（ステップＳ９）。
【００６４】
ステップＳ９においては、当該フレーム（＝フレーム０）と、次フレーム（=フレーム１）との間のフレーム間隔（＝Ｔｇ１０）を測定するために、カウンタ２１に設けられたフレーム間隔タイマ用のカウンタが主制御部１３によってリセットされ、直ちにフレーム間隔の測定を開始する。
【００６５】
続いて、ステップＳ１０において、バッファ４２ａへフレーム０の転送が終了すると、バッファ管理情報４１ａに受信ステータスを書き込む。続いて、ステップＳ１１において、フレーム０が書き込まれたバッファ４２ａに空き容量があるか否かを判定する。図７の例の場合、図８に示すように、バッファ４２ａにはフレーム０を格納した後にも空き容量があるので、ステップＳ１２に進み、次フレーム（＝フレーム１）が到着するのを待機する。
【００６６】
図７の例ではすぐに次フレーム（＝フレーム１）が到着しないので、ステップＳ１４に進み、ステップＳ９において測定を開始したフレーム間隔タイマがタイムアウトしたか否かを判定する。図７の例では、フレーム０の受信を終了してからＴｔｈが経過してもフレーム１が到着しないため、時間ｔ＝ｔ０ｅ＋Ｔｔｈの時点でフレーム間隔タイマがタイムアウトしたと判定され、ステップＳ１５に進んでフレーム間隔タイマ用のカウンタを主制御部１３によってリセットする。続いてステップＳ１３に進み、バッファ管理情報４１ａの必要な部分を更新し、バッファ４２ａの所有権をＣＰＵ５に返却する。
【００６７】
続いてステップＳ２に戻り、バッファ管理情報群４１から次のバッファ管理情報４２ｂを参照し、次フレーム（＝フレーム１）の格納先としてバッファ４２ｂのアドレスを取得して、次フレームの到着を待機する（ステップＳ３）。
【００６８】
フレーム１が受信フレーム処理装置１に到着し、ステップＳ４において時間ｔ１ｓに受信を開始すると、フレーム間隔が測定される。フレーム１と前フレーム（=フレーム０）とのフレーム間隔はＴｇ１０であるが、ステップＳ１５においてフレーム間隔タイマ用のカウンタがリセットされているため、フレーム間隔はゼロとなる。
【００６９】
次に、ステップＳ５において、ステップＳ４で算出したフレーム間隔（＝ゼロ）と、予め設定されている閾値Ｔｔｈとを比較する。ここでは、０＜Ｔｔｈであるので、ステップＳ６へ進み、フレームの格納先としてアドレスを取得しているバッファ４２ｂに対し、受信したフレーム１を転送開始する。所定時間が経過して時間ｔ１ｅになると、ネットワーク２からフレーム１の受信が終了する（ステップＳ９）。
【００７０】
ステップＳ９においては、当該フレーム（＝フレーム１）と、次フレーム（=フレーム２）との間のフレーム間隔（＝Ｔｇ２１）を測定するために、カウンタ２１に設けられたフレーム間隔タイマ用のカウンタが主制御部１３によってリセットされ、直ちにフレーム間隔の測定を開始する。
【００７１】
続いて、ステップＳ１０において、バッファ４２ｂへフレーム１の転送が終了すると、バッファ管理情報４１ｂに受信ステータスを書き込む。続いて、ステップＳ１１において、フレーム１が書き込まれたバッファ４２ｂに空き容量があるか否かを判定する。図７の例の場合、図８に示すように、バッファ４２ｂにはフレーム１を格納した後にも空き容量があるので、ステップＳ１２に進み、次フレーム（＝フレーム２）が到着するのを待機する。
【００７２】
図７の例ではすぐに次フレーム（＝フレーム２）が到着しないので、ステップＳ１４に進み、ステップＳ９において測定を開始したフレーム間隔タイマがタイムアウトしたか否かを判定する。図７の例では、フレーム１の受信を終了してからＴｔｈが経過する前にフレーム２が到着するため（ｔ２ｓ＜ｔ１ｅ＋Ｔｔｈ）、ステップＳ１４からステップＳ１２、ステップＳ４に進む。
【００７３】
フレーム２が受信フレーム処理装置１に到着し、ステップＳ４において時間ｔ２ｓに受信を開始すると、フレーム間隔Ｔｇ２１が測定される。ステップＳ５において、ステップＳ４で算出したフレーム間隔Ｔｇ２１と、予め設定されている閾値Ｔｔｈとを比較する。ここでは、Ｔｇ２１＜Ｔｔｈであるので、ステップＳ６へ進み、フレームの格納先としてアドレスを取得しているバッファ４２ｂに対し、受信したフレーム２を転送開始する。すなわち、フレーム２はフレーム１と同じバッファ４２ｂに格納される。
【００７４】
所定時間が経過して時間ｔ２ｅになると、ネットワーク２からフレーム２の受信が終了する（ステップＳ９）。ステップＳ９においては、当該フレーム（＝フレーム２）と、次フレーム（=フレーム３）との間のフレーム間隔（＝Ｔｇ３２）を測定するために、カウンタ２１に設けられたフレーム間隔タイマ用のカウンタが主制御部１３によってリセットされ、直ちにフレーム間隔の測定を開始する。
【００７５】
続いて、ステップＳ１０において、バッファ４２ｂへフレーム２の転送が終了すると、バッファ管理情報４１ｂに受信ステータスを書き込む。続いて、ステップＳ１１において、フレーム２が書き込まれたバッファ４２ｂに空き容量があるか否かを判定する。図７の例の場合、図８に示すように、バッファ４２ｂにはフレーム２を格納した後にも空き容量があるので、ステップＳ１２に進み、次フレーム（＝フレーム３）が到着するのを待機する。
【００７６】
図７の例ではすぐに次フレーム（＝フレーム３）が到着しないので、ステップＳ１４に進み、ステップＳ９において測定を開始したフレーム間隔タイマがタイムアウトしたか否かを判定する。図７の例では、フレーム２の受信を終了してからＴｔｈが経過してもフレーム３が到着しないため、時間ｔ＝ｔ２ｅ＋Ｔｔｈの時点でフレーム間隔タイマがタイムアウトしたと判定され、ステップＳ１５に進んでフレーム間隔タイマ用のカウンタを主制御部１３によってリセットする。続いてステップＳ１３に進み、バッファ管理情報４１ｂの必要な部分を更新し、バッファ４２ｂの所有権をＣＰＵ５に返却する。
【００７７】
続いてステップＳ２に戻り、バッファ管理情報群４１から次のバッファ管理情報４２ｃを参照し、次フレーム（＝フレーム３）の格納先としてバッファ４２ｃのアドレスを取得して、次フレームの到着を待機する（ステップＳ３）。
【００７８】
フレーム３が受信フレーム処理装置１に到着し、ステップＳ４において時間ｔ３ｓに受信を開始すると、フレーム間隔が測定される。フレーム３と前フレーム（=フレーム２）とのフレーム間隔はＴｇ３２であるが、ステップＳ１５においてフレーム間隔タイマ用のカウンタがリセットされているため、フレーム間隔はゼロとなる。
【００７９】
次に、ステップＳ５において、ステップＳ４で算出したフレーム間隔（＝ゼロ）と、予め設定されている閾値Ｔｔｈとを比較する。ここでは、０＜Ｔｔｈであるので、ステップＳ６へ進み、フレームの格納先としてアドレスを取得しているバッファ４２ｃに対し、受信したフレーム３を転送開始する。所定時間が経過して時間ｔ３ｅになると、ネットワーク２からフレーム３の受信が終了する（ステップＳ９）。
【００８０】
ステップＳ９においては、当該フレーム（＝フレーム３）と、次フレームとの間のフレーム間隔を測定するために、カウンタ２１に設けられたフレーム間隔タイマ用のカウンタが主制御部１３によってリセットされ、直ちにフレーム間隔の測定を開始する。
【００８１】
続いて、ステップＳ１０において、バッファ４２ｃへフレーム３の転送が終了すると、バッファ管理情報４１ｃに受信ステータスを書き込む。続いて、ステップＳ１１において、フレーム３が書き込まれたバッファ４２ｃに空き容量があるか否かを判定する。図７の例の場合、図８に示すように、バッファ４２ｃにはフレーム３を格納した後にも空き容量があるので、ステップＳ１２に進み、次フレームが到着するのを待機する。
【００８２】
このようにして、受信フレーム処理装置１が動作中は、上述のステップＳ２〜ステップＳ１５の処理が繰り返し実行され、ネットワーク２から受信したフレームをシステムメモリ４のバッファ群４２の適切なバッファに書き込んでいく。すなわち、図７の例では、フレーム０はバッファ４２ａに、フレーム３はバッファ４２ｃにそれぞれアンパックモードで格納され、フレーム１，２はバッファ４２ｂにパックモードで格納される（図８参照）。
【００８３】
図９に示すように、全てのフレーム０〜３をアンパックモードでバッファ４２ａ〜４２ｄに格納した場合、使用済みのバッファ（＝バッファ４２ａ〜４２ｄ）においてフレームが格納されていない未使用のメモリ領域の総和は、図８に示すように、本実施の形態における使用済みのバッファ（＝バッファ４２ａ〜４２ｃ）においてフレームが格納されていない未使用のメモリ領域の総和より大きい。図９は、受信したフレームを全てアンパックモードでバッファ群４２に格納する際の格納位置を説明する概略図である。
【００８４】
これより、本実施の形態の受信フレーム処理装置１では、従来のアンパックモードでフレームをバッファに格納する受信フレーム処理装置よりメモリ使用効率が向上していることがわかる。
【００８５】
一方、図１０に示すように、全てのフレーム０〜３をパックモードでバッファ４２ａに格納した場合、使用済みのバッファ（＝バッファ４２ａ）においてフレームが格納されていない未使用のメモリ領域の総和は、図８に示すように、本実施の形態における使用済みのバッファ（＝バッファ４２ａ〜４２ｃ）においてフレームが格納されていない未使用のメモリ領域の総和より小さい。図１０は、受信したフレームを全てパックモードでバッファ群４２に格納する際の格納位置を説明する概略図である。
【００８６】
ここで、図１１と図１２を用い、レイテンシの観点で本実施の形態の受信フレーム処理装置１と、全てパックモードでバッファ群４２にフレームを格納する従来の受信フレーム処理装置とを比較してみる。
【００８７】
図１１は、パックモードにおけるフレーム０のレイテンシを説明するタイムチャートであり、図１２は、本実施の形態におけるフレーム０のレイテンシを説明するタイムチャートである。ここで、レイテンシとは、小容量メモリ１１でフレームの末尾を受信完了してから、システムメモリ４内へのフレームのコピーがすべて完了し、さらにバッファの所有権がＣＰＵ５に譲渡された時点までの時間をいう。（所有権の移動という観点からみた場合、レイテンシは、システムメモリ４にフレームの転送が完了してからバッファの所有権がＣＰＵ５に移動するまでの時間と言うこともできる。）
図１１と図１２においては、ネットワーク２から受信フレーム処理装置１の小容量メモリ１１にフレームを書き込むタイミングを上段に、受信フレーム処理装置１からシステムメモリ４のバッファ管理情報群４１及びバッファ群４２にフレームや各種情報を書き込むタイミングを下段に示している。
【００８８】
図１１に示すように、全てのフレームをパックモードでバッファ群４２に格納する場合、フレーム０〜フレーム３の４つのフレームは全て１つのバッファ４２ａに書き込まれるため、フレーム３の書き込みが終了するまでバッファ４２ａの所有権がＣＰＵ５に譲渡されない。従って、フレーム０のレイテンシＴｌ０´は、小容量メモリ１１がネットワーク２からフレーム０の受信を完了した時点（＝ｔ０ｅ）から、フレーム３が受信フレーム処理装置１からバッファ４２ａに書き込まれ、更に、対応するフレーム管理情報４１ａに受信ステータスなどの情報が書き込まれ、バッファ４２ａの所有権がＣＰＵ５に譲渡される時点（＝ｔ３ｂｅ´）までの間の経過時間となる。
【００８９】
一方、本実施の形態においては、フレーム０はアンパックモードでバッファ４２ａに書き込まれ、フレーム１以降は別のバッファ４２ｂ，４２ｃに書き込まれる。従って、図１２に示すように、フレーム０のレイテンシＴｌ０は、小容量メモリ１１がネットワーク２からフレーム０の受信を完了した時点（＝ｔ０ｅ）から、タイムアウトの閾値Ｔｔｈが経過して、バッファ４２ａの所有権がＣＰＵ５に譲渡される時点（＝ｔ０ｂｅ）までの間の経過時間となる。
【００９０】
これより、Ｔｌ０＜Ｔｌ０´であり。本実施の形態の受信フレーム処理装置１では、従来のパックモードでフレームをバッファに格納する受信フレーム処理装置よりレイテンシが小さくなっていることがわかる。また、レイテンシがバッファ４２ａ〜４２ｄのサイズに依存しないため、バッファ４２ａ〜４２ｄのサイズを大きくしてバッファ群４２に含まれるバッファの数を少なくすることができる。これにより、バッファ管理情報群４１に含まれるバッファ管理情報の数も削減されるため、バッファ管理情報群４１に割り当てるメモリ領域を低減することができ、メモリ使用効率を向上させることができる。
【００９１】
また、パックモードでフレームを格納する場合、アンパックモードでフレームを格納する場合に比べてフレーム管理情報の量が多くなることなどから、ＣＰＵ５の処理量が増え、負荷が大きくなる。本実施の形態の受信フレーム処理装置１では、パックモードとアンパックモードを混在させているので、全てをパックモードで処理する場合に比べてＣＰＵの負荷を低減することができる。
【００９２】
このように、本実施の形態においては、予め設定された閾値Ｔｔｈよりもフレームの到着間隔が短い場合にはパックモードで、フレームの到着間隔が長い場合にはアンパックモードでフレームをバッファに格納するようにしたので、全てのフレームをアンパックモードで格納する場合よりもメモリ使用効率を向上させることができ、また、全てのフレームをパックモードで格納する場合よりも、メモリ使用効率を向上させることができ、フレームのレイテンシを小さくし、ＣＰＵの負荷を低減させることができる。
【００９３】
なお、本実施の形態においては、ネットワーク２からフレームの受信を終了した際に、受信ステータスなどの情報をフレーム管理情報に書き込んでから次のフレームを書き込むバッファのアドレスを読み出す順番で処理を行うように説明したが、処理の順番を逆にし、バッファのアドレスを読み出してから受信ステータスなどの情報を書き込むようにしてもよい。
【００９４】
（第２の実施の形態）
次に、本発明の第２の実施の形態に係わる受信フレーム処理装置について、具体的に説明する。
【００９５】
上述した第１の実施の形態では、ある一のフレームと、次フレームとのフレーム間隔が一定時間を超える場合、及び、バッファの空き容量がなくなった場合に、一のフレームを格納したバッファの所有権をＣＰＵ５に譲渡し、次のバッファに次フレームを格納するようにしたが、本実施の形態では、バッファの空き容量が、次フレームのフレーム長よりも小さい場合にも、一のフレームを格納したバッファの所有権をＣＰＵ５に譲渡し、次のバッファに次フレームを格納するようにしたものである。
【００９６】
例えば、バッファ４２ａにフレーム０を格納した時点でバッファの空き容量がＬａである状況で、フレーム０の受信を完了してから閾値Ｔｔｈを経過する前にフレーム長がＬｆ（＞Ｌａ）のフレーム１が受信フレーム処理装置１に到着した場合、上述した第１の実施の形態では、図１３に示すように、フレーム１がバッファ４２ａとバッファ４２ｂとにまたがって格納されることになる。図１３は、受信フレームが複数のバッファにまたがって格納される例を説明する概略図である。
【００９７】
図１３のようにフレーム１が複数のバッファ４２ａ，４２ｂにまたがって格納されている場合、詳しくは、フレーム１の一部分であるフレーム１−０がバッファ４２ａに格納され、フレーム１の残り部分であるフレーム１−１がバッファ４２ｂに格納されている場合、フレーム１を受信した時点でバッファ４２ａの所有権をＣＰＵ５に譲渡しても、バッファ４２ｂの所有権は受信フレーム処理装置が保有しているため、ＣＰＵ５はフレーム１の全体を処理できない。従って、フレーム１のように複数のバッファにまたがって格納されるフレームのレイテンシは、１つのバッファに格納されるフレームよりも大きくなってしまう。
【００９８】
また、複数のバッファにまたがって格納されるフレームの全体を処理するために、ＣＰＵ５は該フレームが格納されている全部のバッファのアドレスを取得したり、前後関係を構築したりするために、処理の負荷が大きくなってしまう。
【００９９】
そこで、本実施の形態では、次フレームを格納しようとしているバッファの空き容量が次フレームのフレーム長よりも小さい場合には、フレームの格納先を次バッファに切り替えることで、フレームが複数のバッファにまたがって格納される割合を低減する。
【０１００】
本実施の形態における受信フレーム処理装置の構成は、図１を用いて説明した第１の実施の形態の受信フレーム処理装置１と同様であるため、ここでは受信フレーム処理方法についてのみ説明し、同一の構成要素については、同一の符号を付して説明を省略する。
【０１０１】
図６を用いて説明した第１の実施の形態の受信フレーム処理方法では、フレームの受信を開始し（ステップＳ４）、フレーム間隔を閾値Ｔｔｈと比較した後（ステップＳ５）、フレーム間隔が閾値Ｔｔｈ未満である場合には該フレームを格納予定であるバッファにフレームを転送する（ステップＳ６）。
【０１０２】
一方、本実施の形態においては、図１４に示すように、フレーム間隔を閾値Ｔｔｈと比較した後（ステップＳ５）、バッファの空き容量と受信中のフレームのフレーム長とを比較し（ステップＳ２１）、バッファの空き容量がフレーム長以上である場合に初めて該フレームを格納予定であるバッファにフレームを転送する（ステップＳ６）。図１４は、本発明の第２の形態に係わる受信フレームの処理手順を説明するフローチャートである。
【０１０３】
ステップＳ２１において、バッファの空き容量がフレーム長未満であると判定された場合には、フレーム間隔が閾値Ｔｔｈ以上である場合と同様にステップＳ７に進み、バッファ管理情報の必要な部分を更新して所有権をＣＰＵ５に返却する。続いてステップＳ８に進み、システムメモリ４のバッファ管理情報群４１から次のバッファ管理情報を参照し、対応するバッファのアドレスを取得してステップＳ６に進む。
【０１０４】
このように、本実施の形態においては、受信中のフレームのフレーム長が該フレームを格納しようとしているバッファの空き容量より大きい場合に、次バッファに切り替えて格納することで、フレームが複数のバッファをまたがって格納される割合を低減することができるので、フレームのレイテンシをより小さくし、ＣＰＵの処理の負荷をより低減することができる。
【０１０５】
（第３の実施の形態）
次に、本発明の第３の実施の形態に係わる受信フレーム処理装置について、具体的に説明する。
【０１０６】
上述した第１の実施の形態では、ある一のフレームと、次フレームとのフレーム間隔が一定時間を超える場合、及び、バッファの空き容量Ｌａがなくなった場合に、一のフレームを格納したバッファの所有権をＣＰＵ５に譲渡し、次のバッファに次フレームを格納するようにしたが、本実施の形態では、バッファの空き容量Ｌａが、ネットワーク規格の仕様上の最小フレームサイズＬｍｉｎより小さい場合にも、一のフレームを格納したバッファの所有権をＣＰＵ５に譲渡し、次のバッファに次フレームを格納するようにしたものである。
【０１０７】
ある一のフレームをバッファに格納した時点で、該バッファの空き容量Ｌａがネットワーク規格の仕様上の最小フレームサイズＬｍｉｎより小さく、かつ、一のフレームと次フレームとのフレーム間隔が閾値Ｔｔｈよりも小さい場合、第１の実施の形態においては、次フレームはパックモードでバッファに格納されるため、次フレームはフレーム長にかかわらず該バッファと次のバッファとにまたがって格納されることになる。複数のバッファにまたがって格納されたフレームのレイテンシは、１つのバッファに格納されたフレームのレイテンシよりも大きくなり、ＣＰＵの処理の負荷は増大する。
【０１０８】
そこで、本実施の形態では、次フレームを格納しようとしているバッファの空き容量がネットワーク規格の仕様上の最小フレームサイズＬｍｉｎより小さい場合には、フレームの格納先を次バッファに切り替えることで、フレームが複数のバッファにまたがって格納される割合を低減する。
【０１０９】
本実施の形態における受信フレーム処理装置の構成は、図１を用いて説明した第１の実施の形態の受信フレーム処理装置１と同様であるため、ここでは受信フレーム処理方法についてのみ説明し、同一の構成要素については、同一の符号を付して説明を省略する。
【０１１０】
図６を用いて説明した第１の実施の形態の受信フレーム処理方法では、システムメモリ４の適切なバッファへフレームの転送が終了し、フレームを格納したバッファの対応するバッファ管理情報に受信ステータスを書き込んだ後（ステップＳ１０）、当該フレームが書き込まれたバッファに空き容量があるか否かを判定し（ステップＳ１１）。バッファ境界に達しておらず当該バッファに空き容量があると判定された場合には次フレームが到着するのを待機する（ステップＳ１２）。
【０１１１】
一方、ステップＳ１１において、バッファ境界に達しており、当該バッファに空き容量がないと判定された場合、ステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。続いてステップＳ２に戻り、システムメモリ４のバッファ管理情報群４１から次のバッファ管理情報を参照し、対応するバッファのアドレスを取得して、次フレームの到着を待機する。
【０１１２】
一方、本実施の形態においては、図１５に示すように、バッファへフレームの転送が終了してバッファ管理情報に受信ステータスを書き込んだ後（ステップＳ１０）、当該フレームが書き込まれたバッファに空き容量があるか否か、及び、バッファの空き容量Ｌａが最小フレームサイズＬｍｉｎよりも小さいか否かを判定する（ステップＳ３１）。バッファ境界に達しておらず当該バッファに最小フレームサイズＬｍｉｎ以上の空き容量があると判定された場合には次フレームが到着するのを待機する（ステップＳ１２）。図１５は、本発明の第３の形態に係わる受信フレームの処理手順を説明するフローチャートである。
【０１１３】
ステップＳ３１において、当該フレームが書き込まれたバッファに空き容量がない（＝バッファ境界に達した）、もしくは、バッファの空き容量Ｌａが最小フレームサイズＬｍｉｎよりも小さいと判定された場合、ステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。続いてステップＳ２に戻り、システムメモリ４のバッファ管理情報群４１から次のバッファ管理情報を参照し、対応するバッファのアドレスを取得して、次フレームの到着を待機する。
【０１１４】
このように、本実施の形態においては、ある一のフレームを格納したバッファの空き容量が、ネットワーク規格の仕様上の最小フレームサイズよりも小さい場合、次フレームの格納先を次バッファに切り替えることで、フレームが複数のバッファをまたがって格納される割合を低減することができるので、フレームのレイテンシをより小さくし、ＣＰＵの処理の負荷をより低減することができる。
【０１１５】
また、該フレームをバッファに格納した後、該フレームを格納したバッファの空き容量Ｌａとネットワーク規格の仕様上の最小フレームサイズＬｍｉｎとをただちに比較し、Ｌａ＜Ｌｍｉｎの場合、次フレームの格納先を次バッファに切り替えて次フレームの到着を待機することで、該フレームを格納したバッファの所有権がＣＰＵに早く返却されるため、該フレームのレイテンシをより小さくすることができる。
【０１１６】
（第４の実施の形態）
次に、本発明の第４の実施の形態に係わる受信フレーム処理装置について、具体的に説明する。
【０１１７】
上述した第１の実施の形態では、受信フレーム処理装置１からＣＰＵ５に対して割り込みを発生させるタイミングに関しては明言していないが、通常は一つのフレームの受信を完了した時点、もしくはシステムメモリ４に一つのフレームを転送完了した時点で割り込みを発生させる。本実施の形態では、一つのバッファの所有権が受信フレーム処理装置からＣＰＵ５に譲渡された時点で割り込みを発生させる。
【０１１８】
パックモードでバッファが管理されている場合、一つのフレームの受信を完了した時点、もしくはバッファへの書き込みが完了した時点で割り込みを発生させても、当該バッファの所有権はＣＰＵ５に譲渡されていないため、割り込みを発生させたフレーム全体を処理できない。しかし、ＣＰＵ５は割り込みが発生するとこれに応答する必要があるため、ＣＵ５に無駄な処理をさせ、結果として処理の負荷を増大させてしまうことになる。
【０１１９】
また、フレーム単位で割り込みを発生させると、フレームの到着頻度が高い場合には割り込み発生頻度も高くなる。すると、割り込みの回数の増加に伴いＣＰＵ５の処理の負荷も増大してしまう。
【０１２０】
そこで、本実施の形態では、フレーム単位でなくバッファ単位に割り込みを発生させる（バッファの所有権がＣＰＵ５に譲渡された時点で割り込みを発生させる）ことで、ＣＰＵ５が応答してもフレーム全体を処理することができない割り込み（以下、無駄な割り込みと示す）の発生を抑制し、ＣＰＵ５の処理の負荷を低減する。
【０１２１】
本実施の形態における受信フレーム処理装置の構成は、図１を用いて説明した第１の実施の形態の受信フレーム処理装置１と同様であるため、ここでは受信フレーム処理方法についてのみ説明し、同一の構成要素については、同一の符号を付して説明を省略する。
【０１２２】
本実施の形態における受信フレーム処理方法は、図６を用いて説明した第１の実施の形態の受信フレーム処理方法のステップＳ７，ステップＳ１３において、バッファの所有権をＣＰＵ５に返却した後に、割り込み制御部１６から割り込みコントローラなどを介してＣＰＵ５に割り込みを発生させる。
【０１２３】
図７の例において、フレーム単位で割り込みを発生させる場合、フレーム０〜３の４つのフレームがそれぞれバッファ４２ａ〜４２ｄに格納された時点で割り込みを発生させる。これは、計４回の割り込みを発生させることになる。
【０１２４】
全てのフレームをアンパックモードでバッファに格納する場合、このうち無効な割り込みは０回である。しかし、全てのフレームをパックモードでバッファに格納する場合は、フレーム０〜２が格納された時点で発生した割り込みは、バッファ４２ａの所有権がＣＰＵ５に譲渡されていないため、それぞれのフレームが処理できず、無効な割り込みである。すなわち、計４回の割り込みのうち３回の割り込みが無効な割り込みである。
【０１２５】
これに対し、本実施の形態では、図７の例において、フレーム０を格納したバッファ４２ａの所有権がＣＰＵ５に返却された時点（＝図１２におけるｔ０ｂｅ）と、フレーム１，２を格納したバッファ４２ｂの所有権がＣＰＵ５に返却された時点（＝図１２におけるｔ２ｂｅ）と、フレーム３を格納したバッファ４２ｃの所有権がＣＰＵ５に返却された時点（＝図１２におけるｔ３ｂｅ）で割り込みを発生させる。
【０１２６】
これは、計３回の割り込みを発生させることになり、このうち無効な割り込みは０回である。すなわち、割り込みの発生回数を１回減らすことができ、また、バッファ４２ｂのようにパックモードでフレームを格納しても無駄な割り込みを発生させることがない。
【０１２７】
このように、本実施の形態においては、バッファ単位に割り込みを発生させることで、割り込みの発生回数、及び、無駄な割り込みの発生を抑制し、ＣＰＵ５の処理の負荷を低減することができる。また、割り込みの発生回数を抑制することで、ＣＰＵ５の占有率を下げることができ、ＣＰＵ５が他の処理を行うことができるようになるため、ＣＰＵ５の処理効率が向上する効果も期待できる。
【０１２８】
（第５の実施の形態）
次に、本発明の第５の実施の形態に係わる受信フレーム処理装置について、具体的に説明する。
【０１２９】
上述した第４の実施の形態では、一つのバッファの所有権がＣＰＵ５に返却される都度、割り込みを発生させるが、本実施の形態では、二つ以上の所定数のバッファの所有権がＣＰＵ５に返却された時点で割り込みを発生させるようにしたものである。これにより、フレームの受信頻度が高い場合に、ＣＰＵ５の処理の負荷を更に低減する効果が期待できる。
【０１３０】
図６を用いて説明した第４の実施の形態の受信フレーム処理方法では、ステップＳ７、及びステップＳ１３において、バッファの所有権をＣＰＵ５に返却した後に、割り込み制御部１６から割り込みコントローラなどを介してＣＰＵ５に割り込みを発生させ、それぞれステップＳ８、及びステップＳ２に進んで、フレームを格納するバッファのアドレスをバッファ管理情報から読み込む。
【０１３１】
一方、本実施の形態においては、図１６に示すように、ステップＳ７、及びステップＳ１３において、バッファの所有権をＣＰＵ５に返却した後に、ＣＰＵ５に所有権を返却したバッファ数（以下、バッファ返却数と示す）に１を足す（ステップＳ４１，Ｓ４４）。図１６は、本発明の第５の形態に係わる受信フレームの処理手順を説明するフローチャートである。ここで、バッファ返却数とは、直前の割り込みが発生した後にＣＰＵ５に所有権を返却したバッファの数であり、例えばカウンタ２１で計測される。
【０１３２】
続くステップＳ４２、もしくはステップＳ４５において、バッファ返却数が設定数より大きい場合、それぞれステップＳ４３，Ｓ４６に進み、割り込み制御部１６から割り込みコントローラなどを介してＣＰＵ５に割り込みを発生させ、バッファ返却数をリセットした後、それぞれステップＳ８，Ｓ２に進んで、フレームを格納するバッファのアドレスをバッファ管理情報から読み込む。
【０１３３】
一方、ステップＳ４２、もしくはステップＳ４５において、バッファ返却数が設定数以下である場合、割り込みは発生させず、それぞれステップＳ８，Ｓ２に進んで、フレームを格納するバッファのアドレスをバッファ管理情報から読み込む。
【０１３４】
なお、設定数、すなわち割り込みを発生させるバッファ数は、受信フレーム処理装置のコンフィギュレーション時やレジスタ部１５などで、システムに応じた値に設定可能である。
【０１３５】
このように、本実施の形態においては、複数のバッファの所有権がＣＰＵ５に返却された場合に割り込みを発生させることで、割り込みの発生回数を更に抑制し、ＣＰＵ５の処理の負荷をより低減することができる。また、割り込みの発生回数を更に抑制することで、ＣＰＵ５の占有率を下げることができ、ＣＰＵ５が他の処理を行うことができるようになるため、ＣＰＵ５の処理効率が向上する効果も更に期待できる。
【０１３６】
（第６の実施の形態）
次に、本発明の第６の実施の形態に係わる受信フレーム処理装置について、具体的に説明する。本実施の形態の受信フレーム処理装置の構成は、図１を用いて説明した第１の実施の形態の受信フレーム処理装置１と同様であるため、ここでは受信フレーム処理方法についてのみ説明し、同一の構成要素については、同一の符号を付して説明を省略する。
【０１３７】
本実施の形態の受信フレーム処理方法は、上述した第１〜第３，第５の実施の形態を組み合わせたものである。具体的な方法を図１７を用いて説明する。図１７は、本発明の第６の形態に係わる受信フレームの処理手順を説明するフローチャートである。
【０１３８】
まず、第１の実施の形態と同様に、装置の各部を初期化し（ステップＳ１）、最初のフレームを格納するバッファのアドレスをバッファ管理情報から読み込む（ステップＳ２）。続くステップＳ３において、フレームが到着すると、フレームの受信を開始し、フレーム間隔を取得する（ステップＳ４）。
【０１３９】
続くステップＳ５において、フレーム間隔が予め設定した閾値より小さい場合、第２の実施の形態と同様に、ステップＳ２１に進み、バッファの空き容量と受信中のフレームのフレーム長とを比較し、空き容量がフレーム長以上である場合にステップＳ６に進んでフレームの転送を開始する。
【０１４０】
一方、ステップＳ５においてフレーム間隔が閾値以上の場合、もしくはステップＳ２１においてバッファの空き容量がフレーム長未満である場合、ステップＳ７に進んで該バッファの対応するバッファ管理情報を更新し、該バッファの所有権をＣＰＵ５に返却する。続いて、第５の実施の形態と同様に、ステップＳ４１に進み、バッファ返却数に１を加え、設定数と比較する（ステップＳ４２）。
【０１４１】
バッファ返却数が設定数より大きい場合、ステップＳ４３に進んで割り込みを発生させ、バッファ返却数をリセットしてステップＳ８に進んでフレームの格納先となる次のバッファのアドレスを読み込む。一方、バッファ返却数が設定数以下である場合、割り込みを発生させずにステップＳ８に進む。続いてステップＳ６に進み、フレームの転送を開始する。
【０１４２】
第１の実施の形態と同様に、フレームの転送を開始した後（ステップＳ６）、フレームの受信を終了すると、フレーム間隔タイマのカウンタをリセットし、直ちにフレーム間隔の測定を開始する（ステップＳ９）。続いて、フレームの転送を終了すると、バッファ管理情報に受信ステータスなどを書き込む（ステップＳ１０）。
【０１４３】
次に、第３の実施の形態と同様に、ステップＳ３１に進み、当該フレームが書き込まれたバッファに空き容量があるか否か、及び、バッファの空き容量Ｌａが最小フレームサイズＬｍｉｎよりも小さいか否かを判定する。バッファ境界に達しておらず当該バッファに最小フレームサイズＬｍｉｎ以上の空き容量があると判定された場合には次フレームが到着するのを待機する（ステップＳ１２）。
【０１４４】
ステップＳ３１において、当該フレームが書き込まれたバッファに空き容量がない（＝バッファ境界に達した）、もしくは、バッファの空き容量Ｌａが最小フレームサイズＬｍｉｎよりも小さいと判定された場合、ステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。
【０１４５】
続いて、第５の実施の形態と同様に、ステップＳ４４に進み、バッファ返却数に１を加え、設定数と比較する（ステップＳ４５）。バッファ返却数が設定数より大きい場合、ステップＳ４６に進んで割り込みを発生させ、バッファ返却数をリセットしてステップＳ２に進んでフレームの格納先となる次のバッファのアドレスを読み込む。一方、バッファ返却数が設定数以下である場合、割り込みを発生させずにステップＳ２に進む。
【０１４６】
以下、第１の実施の形態と同様に、ステップＳ１２において、フレームが到着した場合、ステップＳ４に戻ってフレームの受信を開始する。一方、フレームが到着しない場合、ステップＳ１４に進み、ステップＳ９において測定を開始したフレーム間隔タイマがタイムアウトしたか否かを判定する。
【０１４７】
ステップＳ１４において、フレーム間隔タイマがタイムアウトしていないと判定された場合、ステップＳ１２に戻り、次フレームの到着を待機する。一方、ステップＳ１４において、フレーム間隔タイマがタイムアウトしたと判定された場合、ステップＳ１５に進み、フレーム間隔タイマ用のカウンタを主制御部１３によってリセットする。続いてステップＳ１３に進み、当該バッファに対応するバッファ管理情報の必要な部分を更新し、所有権をＣＰＵ５に返却する。
【０１４８】
受信フレーム処理装置１が動作中は、上述した各ステップの処理が繰り返し実行され、ネットワーク２から受信したフレームをシステムメモリ４のバッファ群４２の適切なバッファに書き込んでいく。
【０１４９】
このように、本実施の形態においては、第１〜第３，及び第５の実施の形態を組み合わせることで、それぞれの効果を重畳させることができ、特に、ＣＰＵの処理の負荷をよりいっそう低減することができる。
【図面の簡単な説明】
【０１５０】
【図１】本発明の実施の形態に係わる受信フレーム処理装置１の構成を説明するブロック図。
【図２】システムメモリ４の構成を説明する概略図。
【図３】フレームが固定長の場合のバッファ管理情報の具体例を説明する図。
【図４】フレームが可変長で格納モードがアンパックモードの場合のバッファ管理情報の具体例を説明する図。
【図５】フレームが可変長で格納モードがパックモードの場合のバッファ管理情報の具体例を説明する図。
【図６】本発明の第１の実施の形態に係わる受信フレームの処理手順を説明するフローチャート。
【図７】ネットワーク２からフレームを受信している状況の一例を説明するタイムチャート。
【図８】受信したフレームをバッファ群４２に格納する際の格納位置を説明する概略図。
【図９】受信したフレームを全てアンパックモードでバッファ群４２に格納する際の格納位置を説明する概略図。
【図１０】受信したフレームを全てパックモードでバッファ群４２に格納する際の格納位置を説明する概略図。
【図１１】パックモードにおけるフレーム０のレイテンシを説明するタイムチャート。
【図１２】本実施の形態におけるフレーム０のレイテンシを説明するタイムチャート。
【図１３】受信フレームが複数のバッファにまたがって格納される例を説明する概略図。
【図１４】本発明の第２の形態に係わる受信フレームの処理手順を説明するフローチャート。
【図１５】本発明の第３の形態に係わる受信フレームの処理手順を説明するフローチャート。
【図１６】本発明の第５の形態に係わる受信フレームの処理手順を説明するフローチャート。
【図１７】本発明の第６の形態に係わる受信フレームの処理手順を説明するフローチャート。
【符号の説明】
【０１５１】
１…受信フレーム処理装置、２…ネットワーク、３…システムバス、４…システムメモリ、５…ＣＰＵ、１１…小容量メモリ、１２…フレーム処理部、１３…主制御部、１４…ＤＭＡ制御部、１５…レジスタ部、１６…割り込み制御部、２１カウンタ
【図１】
2008252748.tif 000003
【図２】
2008252748.tif 000004
【図３】
2008252748.tif 000005
【図４】
2008252748.tif 000006
【図５】
2008252748.tif 000007
【図６】
2008252748.tif 000008
【図７】
2008252748.tif 000009
【図８】
2008252748.tif 000010
【図９】
2008252748.tif 000011
【図１０】
2008252748.tif 000012
【図１１】
2008252748.tif 000013
【図１２】
2008252748.tif 000014
【図１３】
2008252748.tif 000015
【図１４】
2008252748.tif 000016
【図１５】
2008252748.tif 000017
【図１６】
2008252748.tif 000018
【図１７】
2008252748.tif 000019