(57)【要約】【課題】パケットの統合処理をオフロードで行うためにバッファを確保することによる、メモリの利用効率を向上させる。【解決手段】通信部を有する通信装置は、プロトコルスタックへ提供するために、複数の受信パケットを統合するパケット処理部と、通信部における受信パケットの到来に応じて、パケット処理部が使用するためのバッファをメモリから確保し、確保されたバッファをパケット処理部が使用できるようにパケット処理部のバッファへのアクセスを設定し、確保されたバッファの利用の完了に応じて当該バッファを解放するバッファ処理部と、を有する。【選択図】図２
2019205064.tif 000002
【特許請求の範囲】
【請求項１】
通信部を有する通信装置であって、
プロトコルスタックへ提供するために、複数の受信パケットを統合する統合手段と、
前記通信部における受信パケットの到来に応じて、前記統合手段が使用するためのバッファをメモリから確保する確保手段と、
前記確保手段により確保された前記バッファを前記統合手段が使用できるように、前記統合手段のバッファへのアクセスを設定する設定手段と、
前記確保手段により確保された前記バッファの利用の完了に応じて前記バッファを解放する解放手段と、を備えることを特徴とする通信装置。
【請求項２】
前記確保手段が確保する前記バッファは、前記複数の受信パケットを取得するためのパケット情報を格納する設定バッファと、前記統合手段が前記複数の受信パケットを統合した結果を格納する結果バッファとの少なくとも何れかであることを特徴とする請求項１に記載の通信装置。
【請求項３】
前記統合手段は、前記複数の受信パケットをコネクションごとにグループ化し、シーケンス番号の順にソートして、コネクションごとに統合されたパケットを生成することを特徴とする請求項１に記載の通信装置。
【請求項４】
前記確保手段は、前記統合手段が一つの処理リクエストについて処理する受信パケットの数に応じて、前記統合手段が必要とするサイズのバッファを確保することを特徴とする請求項１に記載の通信装置。
【請求項５】
前記メモリは、第１のメモリと、前記第１のメモリよりも高速なアクセスが可能な第２のメモリと、を含み、
前記確保手段は、前記第２のメモリから前記バッファを確保することを優先することを特徴とする請求項１に記載の通信装置。
【請求項６】
前記通信部は複数の通信部を含み、
前記確保手段は、前記複数の通信部のそれぞれについて前記第１のメモリと前記第２のメモリのいずれからバッファを確保するかを切り替えることを特徴とする請求項５に記載の通信装置。
【請求項７】
前記通信部は、第１の通信部と、前記第１の通信部よりも高速な通信が可能な第２の通信部とを含み、
前記確保手段は、前記第２の通信部に対して前記第２のメモリから前記バッファを確保し、前記第１の通信部に対して前記第１のメモリから前記バッファを確保することを特徴とする請求項６に記載の通信装置。
【請求項８】
前記通信部は、第１の通信部と、前記第１の通信部よりも高速な通信が可能な第２の通信部とを含み、
前記確保手段は、前記第２の通信部から受信したパケットに対して優先して前記バッファを確保することを特徴とする請求項１に記載の通信装置。
【請求項９】
前記通信部で受信したパケットを一時的に格納するための受信キューを提供するパケット格納手段をさらに備えることを特徴とする請求項１に記載の通信装置。
【請求項１０】
前記パケット格納手段は、前記確保手段が前記バッファを確保することが可能になるまで、前記通信部で受信したパケットを前記受信キューに格納することを特徴とする請求項９に記載の通信装置。
【請求項１１】
前記統合手段は、ＬＲＯであることを特徴とする請求項１乃至１０のいずれか１項に記載の通信装置。
【請求項１２】
前記バッファは、ＬＲＯがパケットの解析とソートの処理に利用するディスクリプタのバッファと前記処理の結果を格納するためのバッファの少なくとも何れかを含むことを特徴とする請求項１１に記載の通信装置。
【請求項１３】
通信部を有する通信装置の制御方法であって、
プロトコルスタックへ提供するために、複数の受信パケットを統合する統合工程と、
前記通信部における受信パケットの到来に応じて、前記統合工程で使用されるバッファをメモリから確保する確保工程と、
前記確保工程により確保された前記バッファを前記統合工程が使用できるように、前記統合工程におけるバッファへのアクセスを設定する設定工程と、
前記確保工程により確保された前記バッファの利用の完了に応じて前記バッファを解放する解放工程と、を備えることを特徴とする通信装置の制御方法。
【請求項１４】
コンピュータに請求項１３に記載された制御方法の各工程を実行させるためのプログラム。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明は、通信装置およびその制御方法、プログラムに関する。
【背景技術】
【０００２】
一般に、パケット通信において、通信の信頼性を保証するため、送信側から送信されたパケットを受信した受信側がＡＣＫと呼ばれる確認応答を用いる通信方式が利用されている。例えば、インターネット通信において広く利用されているＴＣＰ／ＩＰ（Transmission Control Protocol/Internet Protocol）では、送信側の装置は、送信データをセグメントにチャンク化してパケット化して送信する。ＴＣＰ／ＩＰにおける受信側の装置は、セグメントをオクテット単位にシーケンス番号で管理し、受け取ったセグメントのシーケンス番号をＡＣＫとして応答する。
【０００３】
近年、ＴＣＰ／ＩＰのプロトコル処理では、ＣＰＵ（Central Processing Unit）による処理軽減と高速受信のために、ＬＲＯ（Large Receive Offload）の機能が使用されている（特許文献１）。通常、受信装置は、受信キューから取り出された通信パケットについて、通信ヘッダを解析しながら１つずつ受信処理を行う。これに対し、ＬＲＯ機能では、受信した通信パケットの解析を行い、ＯＳＩ参照モデルのトランスポート層のセッションが同一の通信パケットのペイロードを結合して１つのジャンボパケットを生成する。そして、ジャンボパケットに対して、ネットワークスタックが受信処理を行うことにより、受信した通信パケット数あたりの受信処理実施回数を減らし、効率的かつ高速に通信パケットを受信することができる技術である。一般的にＬＲＯ機能はＮＩＣ（Network Interface Card）に実装されている場合が多い。また、ＬＲＯ機能を用いてジャンボパケットを生成するには、受信した通信パケットを解析する必要があるため、通信パケットを格納するバッファが必要となる。
【先行技術文献】
【特許文献】
【０００４】
【特許文献１】特開２０１５−０３２８６５号公報
【発明の概要】
【発明が解決しようとする課題】
【０００５】
しかしながら、パケットをバースト的に受信することを想定し、ＬＲＯが複数パケットの解析処理に使用するバッファを静的に確保しておくと、頻繁に使用されていないバッファを効率的に使用できない。
【課題を解決するための手段】
【０００６】
本発明の一態様による通信装置は以下の構成を有する。すなわち、
通信部を有する通信装置であって、
プロトコルスタックへ提供するために、複数の受信パケットを統合する統合手段と、
前記通信部における受信パケットの到来に応じて、前記統合手段が使用するためのバッファをメモリから確保する確保手段と、
前記確保手段により確保された前記バッファを前記統合手段が使用できるように、前記統合手段のバッファへのアクセスを設定する設定手段と、
前記確保手段により確保された前記バッファの利用の完了に応じて前記バッファを解放する解放手段と、を備える。
【発明の効果】
【０００７】
本発明によれば、パケット解析処理、及びパケットソート処理で使用するバッファが必要なときにメモリを確保するため、効率的なメモリ使用ができる。
【図面の簡単な説明】
【０００８】
【図１】実施形態に係る通信装置のハードウェア構成例を示すブロック図。
【図２】第１実施形態に係る通信装置の機能構成例を示すブロック図。
【図３】第１実施形態における受信パケットの受信処理を説明するフローチャート。
【図４】第２実施形態における受信パケットの受信処理を説明するフローチャート。
【図５】第３実施形態における受信パケットの受信処理を説明するフローチャート。
【発明を実施するための形態】
【０００９】
以下、添付の図面を参照して、本発明をその好適な実施形態に基づいて詳細に説明する。なお、以下の実施形態において示す構成は一例に過ぎず、本発明は図示された構成に限定されるものではない。
【００１０】
［第１実施形態］
図１は、第１実施形態における通信装置１０のハードウェア構成例を示すブロック図である。ＤＲＡＭ（Dynamic Random Access Memory）１０１、ＳＲＡＭ（Static Random Access Memory）１０２は各種データの保存やワークメモリとして使用される。ＳＲＡＭ１０２は、高速アクセス可能なメモリ（以下、高速メモリ、高速バッファ）である。ＤＲＡＭ１０１はＳＲＡＭ１０２と比較し、アクセス性能が低速なメモリ（以下、通常メモリ、通常バッファ）である。高速メモリであるＳＲＡＭ１０２は高速バッファを、通常メモリであるＤＲＡＭ１０１は通常バッファを提供する。ＲＯＭ（Read Only Memory）１０４には、ＣＰＵ１０３により実行される各種プログラム等を記憶する。
【００１１】
ＣＰＵ１０３は、ＤＲＡＭ１０１、ＳＲＡＭ１０２をワークメモリとして用いて各種プログラムを実行し、各種処理を実現する。各種プログラムを格納するプログラム格納部としての記録媒体には、ＲＯＭ１０４または不図示のハードディスクなどが用いられ得る。なお、ワークメモリおよび／またはバッファとしてＤＲＡＭ１０１のみを使用するようにしてもよいし、高速アクセス可能なＳＲＡＭ１０２を優先的に使用し、ＳＲＡＭ１０２が使用できない場合にＤＲＡＭ１０１を使用するようにしてもよい。
【００１２】
第１通信部１１３は、ＭＡＣ（Media Access Control）モジュール１１１とＰＨＹ（Physical Layer）モジュール１１２を有し、イーサネット（商標登録）などのネットワークを介した、通信相手装置との通信を行う。同様に、第２通信部１１６は、ＭＡＣモジュール１１４とＰＨＹモジュール１１５を有し、第１通信部１１３と異なるネットワークを介した、通信相手装置との通信を行う。データの送受信は、ＣＰＵ１０３が実行するネットワークドライバによってＭＡＣモジュール１１１（および／またはＭＡＣモジュール１１４）が制御されることにより行われる。なお、本実施形態では、第１通信部１１３と第２通信部１１６は、イーサネット（登録商標）を介した通信を行うものとするがこれに限られるものではない。例えば、無線ＬＡＮ（Wi-Fi）など、ＩＰ通信可能な媒体を介して通信を行うように構成されてもよい。
【００１３】
バッファ処理部３００とパケット処理部４００は、例えばＬＲＯ（Large Receive Offload）を実現する。バッファ処理部３００は、第１通信部１１３（および／または第２通信部１１６）における受信パケットの到来に応じて、パケット処理部４００が使用するためのバッファをメモリから確保する。バッファとして確保された領域は、ＣＰＵ１０３（例えば、プロトコルスタックやアプリケーション）からのアクセスが制限される。そして、バッファ処理部３００は、確保したバッファをパケット処理部４００が使用できるように、パケット処理部４００のバッファへのアクセスを設定する。さらに、バッファ処理部３００は、確保されたバッファの利用の完了に応じてバッファを解放する。
【００１４】
また、パケット処理部４００は、第１通信部１１３（および／または第２通信部１１６）によって受信された複数のパケットを解析、ソートし統合する。より具体的には、パケット処理部４００は、パケットのイーサネットヘッダとＴＣＰ／ＩＰヘッダを解析し、同一コネクション毎にグループ化し、パケットのシーケンス番号によるソートを行う。さらに、パケット処理部４００は、受信パケットの整合性を検査するためのチェックサム計算も同時に行う。なお、パケット処理部４００は、同一コネクションの複数パケットを連結し、イーサネット標準の最大フレームサイズ超えるフレームサイズのジャンボフレーム（ジャンボパケット）にパケットを再構成してもよい。パケット格納部５００は、第２実施形態、第３実施形態で必要な構成であり、第１実施形態では省略可能である。パケット格納部５００については、第２実施形態、第３実施形態で説明する。
【００１５】
タイマ管理部１０５は、パケットの受信、及び送信に関して必要な所定時間を管理する。なお、以下に説明する（受信）パケットは、ＩＰ通信上で送受信されるデータの単位である。このパケットの組み立て方法は周知であり、本実施形態の本質でもないので、説明を省略する。
【００１６】
図２は、第１実施形態における通信装置１０の機能構成例を示すブロック図である。ＣＰＵ１０３の機能構成において、アプリケーション２０１は、ユーザアプリケーションを指す。プロトコルスタック２０２により、任意のサイズの、受信対象の受信データがアプリケーション２０１に入力される。プロトコルスタック２０２は、ネットワークバッファ管理部２０３、セグメント処理部２０４、通信プロトコル処理部２０５、コネクション管理部２０６、ＴＣＰウィンドウ制御部２０７、輻輳制御部２０８を備える。ＣＰＵ１０３は、例えばＲＯＭ１０４に格納された所定のプログラムを実行することにより、これら各機能部を実現する。
【００１７】
ネットワークバッファ管理部２０３は、受信データを例えばＤＲＡＭ１０１の受信バッファ（通常メモリ）に格納して管理する。ネットワークバッファ管理部２０３はまた、受信バッファに格納されている受信データのサイズを管理する。セグメント処理部２０４は、データの送信時に使用される。セグメント処理部２０４は、ネットワークバッファ管理部２０３により管理されているＤＲＡＭ１０１内の送信バッファに格納されている送信データを、ＭＳＳ（Maximum Segment Size）、輻輳ウィンドウサイズ等に基づいて決定された送信データサイズにセグメント化する。
【００１８】
コネクション管理部２０６は、通信装置１０の通信コネクションを管理する。例えば、コネクション管理部２０６は、アプリケーション２０１に対する通信コネクションにおけるＭＳＳ等のコネクション情報を管理する。ＴＣＰウィンドウ制御部２０７は、第１通信インタフェース制御部２０９および第２通信インタフェース制御部２１１を介して受信したパケットのシーケンス番号と、ネットワークバッファ管理部２０３の受信バッファをもとに、ＴＣＰコネクションの受信ウィンドウサイズを管理する。輻輳制御部２０８は、ＴＣＰコネクションにおける輻輳制御を管理する。例えば、輻輳制御部２０８は、アプリケーション２０１に対する通信コネクションにおける輻輳ウィンドウを管理する。
【００１９】
通信プロトコル処理部２０５は、受信パケットのＴＣＰヘッダやＩＰヘッダの解析と、それに伴うチェックサム計算等の処理を行い、受信パケットが正常な受信すべきパケットか否かを判断する。受信パケットが正常な受信すべきパケットであった場合、通信プロトコル処理部２０５は、受信可能なデータサイズ（受信ウィンドウサイズ）を決定し、対向通信装置に受信ウィンドウサイズを通知するために確認応答を送信する。なお、受信ウィンドウサイズは、例えば、
・ネットワークバッファ管理部２０３により管理されているＤＲＡＭ１０１内の受信バッファに格納されている受信データのサイズ、
・コネクション管理部２０６で管理されているＭＳＳ、
・ＴＣＰウィンドウ制御部２０７で管理されている受信ウィンドウサイズ、
・輻輳制御部２０８で管理されている輻輳ウィンドウサイズ、等に基づいて決定される。
【００２０】
第１通信インタフェース制御部２０９と第２通信インタフェース制御部２１１は、それぞれ、第１通信部１１３と第２通信部１１６を用いたパケットの送受信を制御する。
【００２１】
バッファ処理部３００はバッファ確保部３０２とバッファ設定部３０１を有する。バッファ確保部３０２は、第１通信インタフェース制御部２０９および第２通信インタフェース制御部２１１から受信したパケットに対して、パケット処理部４００の処理を実行するために必要なバッファを確保する。例えば、バッファ確保部３０２は、パケット処理部４００による処理の実行前に、パケット処理部４００が使用するバッファのサイズを動的に確保する。パケット処理部４００が使用するバッファとは、パケット情報をパケット処理部４００に設定するための設定バッファと、パケット解析ソート処理実行後の結果を格納する結果バッファである。
【００２２】
バッファ設定部３０１は、バッファ確保部３０２が確保した設定バッファと結果バッファとを、パケット処理部４００がアクセスするように設定する。なお、パケット情報とは、受信パケットが格納されているメモリ領域上の先頭メモリアドレス、受信パケットのソケット情報（ＩＰヘッダ）が確認できる先頭メモリアドレスなどを含む情報である。これにより、パケット処理部４００は、設定バッファに格納されているパケット情報に従って処理対象の受信パケットを取得し、結果バッファへ処理結果を格納することができる。すなわち、本実施形態の設定バッファは、ＬＲＯ処理のためのパケット解析・ソート処理に利用するディスクリプタのバッファであり、本実施形態の結果バッファはＬＲＯのための出力バッファである。
【００２３】
パケット処理部４００は、ヘッダ解析部４０１、パケットソート部４０２、チェックサム計算部４０３を備える。ヘッダ解析部４０１は、バッファ設定部３０１によりバッファに設定されたパケット情報をもとにイーサネットヘッダとＴＣＰ／ＩＰヘッダを取得、解析し、複数の受信パケットを同一コネクション毎のグループへグループ化する。パケットソート部４０２は、受信パケットのシーケンス番号をもとに、グループごとに受信パケットのソートを行う。チェックサム計算部４０３は、受信パケットの整合性を検査するためにチェックサム計算を行う。
【００２４】
第１実施形態では、第１通信インタフェース制御部２０９又は第２通信インタフェース制御部２１１から受信したパケットに応じて、通信プロトコル処理部２０５またはバッファ処理部３００とパケット処理部４００が受信処理をする。以下、図３を用いて受信パケットの処理方法について説明する。図３は、第１実施形態における受信パケットの受信処理を説明するフローチャートである。図３のフローチャートは、第１通信部１１３を用いて第１通信インタフェース制御部２０９が受信パケットを受信する際の処理を想定する。ただし、第１通信インタフェース制御部２０９と第２通信インタフェース制御部２１１の両方が使用される実施形態においても同様の処理である。
【００２５】
まず、ステップＳ１０１において、第１通信インタフェース制御部２０９が、第１通信部１１３を介してパケットを受信する。第１通信インタフェース制御部２０９がパケットを受信すると、ステップＳ１０２において、パケット処理部４００が処理リクエストを受け付けることが可能かどうかで処理が分岐する。処理リクエストの受付ができない場合、処理はステップＳ１０３へ進む。ステップＳ１０３において、本処理は、パケット処理部４００が処理リクエストを受け付けることが可能となるのを待機する状態となる。処理リクエストとは、パケット処理部４００に対して複数のパケットの解析、統合を要求する信号である。パケット処理部４００は、１つの処理リクエストにより所定数を上限とする複数のパケットを処理される。
【００２６】
ステップＳ１０２において、パケット処理部４００が処理リクエストを受け付けることができる場合、処理はステップＳ１０４へ進む。ステップＳ１０４において、バッファ処理部３００のバッファ確保部３０２が、ＳＲＡＭ１０２の高速バッファ（および／またはＤＲＡＭ１０１の通常バッファ）から、パケット処理部４００が使用するバッファを確保する。上述したように、パケット解析ソート処理を実行するためのパケット情報を設定するための設定バッファと、パケット解析ソート処理の実行結果が格納される結果バッファが確保される。ステップＳ１０５において、バッファ処理部３００のバッファ設定部３０１は、バッファ確保部３０２により確保された設定バッファへ、パケット処理部４００が１つの処理リクエストに応じて処理することが可能なパケット数の上限までのパケット情報を設定する。そして、ステップＳ１０６において、バッファ設定部３０１は、パケット解析ソート処理の実行結果が格納される設定バッファと結果バッファをパケット処理部４００がアクセスできるように設定する。
【００２７】
ステップＳ１０７において、パケット処理部４００は、設定バッファに設定されているパケット情報に従って、パケット解析ソート処理を行う。パケット解析ソート処理では、ヘッダ解析部４０１が設定バッファに格納されているパケット情報をもとに受信パケットのイーサネットヘッダとＴＣＰ／ＩＰヘッダを解析し、複数の受信パケットを同一コネクション毎のグループにグループ化する。パケットソート部４０２は、受信パケットのシーケンス番号をもとにグループごとに受信パケットのソートを行う。チェックサム計算部４０３は、受信パケットの整合性を検査するためにチェックサム計算の処理を実行する。以上のようにしてソートされた受信パケットのペイロードとチェックサム計算の結果に基づいて、パケット処理部４００は、ジャンボフレームのパケットを生成する。
【００２８】
ステップＳ１０８において、パケット処理部４００は、パケット解析ソート処理を完了すると、ステップ１０６で設定した結果バッファへその処理結果を格納する。なお、ステップＳ１０７において、パケット処理部４００は、複数の処理リクエストを実行可能としてもよい。その場合、ステップＳ１０８におけるパケット解析ソート処理の完了は、一つの処理リクエストに対する処理の完了でもよいし、全ての処理リクエストに対する処理の完了でもよい。ステップＳ１０９において、バッファ処理部３００は、パケット解析ソート処理に使用した設定バッファを解放する。
【００２９】
ステップＳ１１０において、プロトコルスタック２０２は、結果バッファに格納されているジャンボフレームのパケットについてネットワークプロトコル処理を実行する。より具体的には、プロトコルスタック２０２は、ジャンボフレームパケットのＴＣＰ／ＩＰヘッダの情報を解析し、その解析結果に応じた処理を行う。例えば、コネクション管理部２０６によって管理されているコネクションであると判定された場合、ジャンボフレームパケットをネットワークバッファ管理部２０３で管理されている受信バッファに受信データとして格納する。そして、通信プロトコル処理部２０５は、ＴＣＰウィンドウ制御部２０７で管理されている受信ウィンドウサイズ、輻輳制御部２０８で管理されている輻輳ウィンドウサイズ等に基づいて、受信可能なデータサイズを決定する。そして、通信プロトコル処理部２０５は、対向通信装置に決定された受信可能なデータサイズ、すなわち受信ウィンドウサイズを通知するために確認応答を送信する。
【００３０】
ステップＳ１１１において、プロトコルスタック２０２は、受信したデータをアプリケーション２０１に通知する。この処理は、パケット処理部４００の実行結果が存在する間、繰り返される。実行結果が存在しなくなると、ステップＳ１１２において、プロトコルスタック２０２は、パケット処理部４００の実行結果が格納される結果バッファを解放する。ステップＳ１１３において、パケット処理部４００の処理待ちの受信パケットが存在する場合、処理はステップＳ１０２へ戻り、新たな処理リクエストについて上述した処理が繰り返される。処理待ちの受信パケットが存在しなくなると、本処理は終了する。
【００３１】
以上のように、第１実施形態によれば、通信インタフェース制御部がパケットを受信した後の処理に対して、バッファ処理部３００とパケット処理部４００が受信パケットのパケット解析ソート処理（Ｓ１０２〜Ｓ１０９、Ｓ１１２）を実行している。このため、通信インタフェースに依存せずに、バッファ処理部３００とパケット処理部４００を使用でき、受信パケットをジャンボフレームに構成することができる。また、バッファ確保部３０２は、パケット処理部４００が受信パケットの解析を実行するときに、動的にバッファを確保する。したがって、パケット解析およびソート処理のためのバッファとして確保されていない間のメモリ領域は、受信処理以外の送信処理、または、暗号化処理などにも使用できる。
【００３２】
（変形例）
なお、１つの通信部（第１通信部１１３）からパケットを受信した場合の例を挙げたが、複数の通信部（第１通信部１１３と第２通信部１１６）から受信パケットを受信した場合にも上述の処理を適用できることは明らかである。また、複数の通信部は、複数種類のインタフェース（例えば、無線ＬＡＮインタフェースのμＡＰ、ＳＴＡ、有線ＬＡＮインタフェース）が混在しても構わない。
【００３３】
また、第１実施形態では、ＴＣＰ／ＩＰプロトコルを例にして説明したが、ＵＤＰ（User Datagram Protocol）プロトコル等の他のプロトコルを適用することも可能である。
【００３４】
また、第１実施形態において、バッファ確保部３０２が確保するバッファは、ＤＲＡＭ１０１の通常バッファでもＳＲＡＭ１０２の高速バッファのどちらでもよい。しかしながら、より高速な処理を実現するために、バッファ確保部３０２が、ＤＲＡＭ１０１の通常バッファよりもＳＲＡＭ１０２の高速バッファを優先して確保するようにしてもよい。また、複数種類の通信インタフェースが存在する場合に、高速処理を実行する必要がある通信インタフェースにはＳＲＡＭ１０２の高速バッファを、低速処理でもよい通信インタフェースにはＤＲＡＭ１０１の通常バッファを確保するようにしてもよい。
【００３５】
なお、バッファ処理部３００およびパケット処理部４００はハードウェア処理を想定しているが、これらはプロセッサーがソフトウェアを実行することにより実現されてもよいし、ハードウェアとソフトウェアの協働により実現されてもよい。
【００３６】
［第２実施形態］
次に、第２実施形態について説明する。第１実施形態では、バッファ処理部３００とパケット処理部４００により、第１通信部１１３または第２通信部が有するバッファに格納された受信パケットが処理され、統合されたパケット（ジャンボパケット）がプロトコルスタックに提供される。第２実施形態では、パケット格納部５００に設けた受信キューに受信パケットを保持する構成を説明する。なお、第２実施形態の通信装置１０のハードウェア構成例、機能構成例は第１実施形態（図１、図２）と同様である。図１において、パケット格納部５００は、バッファ確保部３０２によるバッファの確保が可能であるか否かによらず、第１通信部１１３（および／または第２通信部１１６）によって受信したパケットを受信キューに格納する。
【００３７】
図４は、第２実施形態におけるデータ受信処理を説明するフローチャートである。本フローチャートでは、第１通信インタフェース制御部２０９から受信パケットを受信する際の処理を想定するが、第１通信インタフェース制御部２０９と第２通信インタフェース制御部２１１の両方が使用される形態においても同様の処理を適用できる。
【００３８】
ステップＳ２０１において、第１通信インタフェース制御部２０９が、第１通信部１１３を介してパケットを受信する。ステップＳ２０２において、パケット格納部５００が、第１通信部１１３に到来した受信パケットを受信キューへ格納する。ステップＳ２０３において、パケット処理部４００が処理リクエストを受け付けることが可能かどうかで処理が分岐する。パケット処理部４００が処理リクエストを受け付けることができない場合、処理はステップＳ２０４へ進む。ステップＳ２０４において、本処理は、パケット処理部４００が処理リクエストを受け付けることが可能となるのを待機する状態となる。
【００３９】
パケット処理部４００が処理リクエストを受付可能な場合（ステップＳ２０３でＹＥＳ）、処理はステップＳ２０５に進む。ステップＳ２０５において、バッファ処理部３００のバッファ確保部３０２が、ＳＲＡＭ１０２の高速バッファ（および／またはＤＲＡＭ１０１の通常バッファ）から、パケット処理部４００が使用するバッファを確保可能かどうか判定する。第１実施形態により上述したように、パケット処理部４００が使用するバッファとは、パケット解析ソート処理を実行するためのパケット情報を設定するための設定バッファと、パケット解析ソート処理の実行結果が格納される結果バッファである。バッファの確保ができないと判定された場合、処理はステップＳ２０６へ進み、バッファ処理部３００は、パケット解析ソート処理に必要なバッファが解放されるのを待つ。
【００４０】
その後、バッファの確保ができるのになると、処理はステップＳ２０７へ進み、バッファ確保部３０２は、パケット処理部４００のための設定バッファと結果バッファを確保する。確保されるバッファのサイズは、１つの処理リクエストで処理が可能なパケット数に必要なバッファサイズ、または受信キューに格納されているパケット数に必要なバッファサイズ、あるいはそれらのうちの大きい方のバッファサイズである。ステップＳ２０８において、受信キューに格納されている受信パケットについてパケット情報を取得し、ステップＳ２０９へ進む。Ｓ２０９〜Ｓ２１７の処理は、図３のステップＳ１０５〜Ｓ１１３と同様の処理になるため、説明を省略する。なお、パケット処理部４００は、樹脂キューから受信パケットを取得し、処理することになる。
【００４１】
以上のように、第２実施形態によれば、通信インタフェース制御部がパケットを受信した後の処理に対して、バッファ処理部３００とパケット処理部４００が受信パケットのパケット解析ソート処理（Ｓ２０３〜Ｓ２１３、Ｓ２１６）を実行している。このため、第１実施形態と同様に、通信インタフェースに依存せずに、バッファ処理部３００とパケット処理部４００を使用でき、受信パケットをジャンボフレームに構成することができる。また、第１実施形態と同様に、バッファ確保部３０２が必要に応じて動的にバッファを確保するので、バッファとして確保されていない間のメモリを、受信処理以外の送信処理、暗号化処理などに利用でき、バッファが配置されているメモリを効率的に使用できる。
【００４２】
なお、第１実施形態の変形例において記載した変形例は、第２実施形態にも適用できることは明らかである。
【００４３】
［第３実施形態］
次に、第３実施形態について説明する。第２実施形態では、バッファ確保部３０２によるバッファの確保が可能であるか否かによらず、受信したパケットをパケット格納部５００に設けた受信キューに格納する構成を説明した。第３実施形態では、バッファ確保部３０２がバッファを確保できない場合に、パケット格納部５００が一時的にパケットを受信キューに格納する構成を説明する。なお、第３実施形態の通信装置１０のハードウェア構成例、機能構成例は第２実施形態（図１、図２）と同様である。
【００４４】
図５は、第３実施形態によるデータ受信処理を説明するフローチャートである。本フローチャートでは、第１通信インタフェース制御部２０９から受信パケットを受信する際の処理を想定するが、第１通信インタフェース制御部２０９と第２通信インタフェース制御部２１１の両方が使用される形態においても同様の処理を適用できる。
【００４５】
まず、ステップＳ３０１において、第１通信インタフェース制御部２０９が、第１通信部１１３を介してパケットを受信する。ステップＳ３０２において、パケット処理部４００が処理リクエストを受付可能かどうかにより処理が分岐する。パケット処理部４００による処理リクエストの受付ができない場合、処理はステップＳ３０３へ進み、本処理は、パケット処理部４００が処理リクエストの受付可能となるのを待機する状態となる。パケット処理部４００が処理リクエストを受付可能な場合、処理はステップＳ３０４へ進む。
【００４６】
ステップＳ３０４において、バッファ処理部３００のバッファ確保部３０２は、ＳＲＡＭ１０２の高速バッファ（および／またはＤＲＡＭ１０１の通常バッファ）から、パケット処理部４００が使用するバッファを確保可能かどうか判定する。第１、第２実施形態により上述したように、パケット処理部４００が使用するバッファとは設定バッファと結果バッファである。バッファの確保ができないと判定された場合、処理はステップＳ３０５へ進む。ステップＳ３０５において、パケット格納部５００は、受信キューへ受信パケットを格納する。ステップＳ３０６において、処理は、パケット解析ソート処理に必要なバッファが解放されるのを待つ待機状態となる。こうして、パケット格納部５００は、バッファ確保部３０２がバッファを確保することが可能になるまで、第１通信部１１３で受信したパケットを受信キューに格納する。バッファの確保ができると判定された場合、処理はステップＳ３０７へ進む。Ｓ３０７〜Ｓ３１７の処理は、図４のステップＳ２０７〜Ｓ２１７と同様の処理である。
【００４７】
ただし、ステップＳ３０８では、受信キューにパケットが格納されているか受信バッファにパケットが格納されているかにより、受信パケットの取得先（パケット情報）が変わる。すなわち、パケットの受信当初からバッファの確保が可能であった場合は、受信バッファに格納されている受信パケットについてのパケット情報が取得される。受信キューにパケットが格納された場合は、受信キューに格納されている受信パケットについてのパケット情報が取得される。
【００４８】
以上のように、第３実施形態によれば、通信インタフェース制御部がパケットを受信した後の処理に対して、バッファ処理部３００とパケット処理部４００が受信パケットのパケット解析ソート処理（Ｓ３０２〜Ｓ３１３、Ｓ３１６）を実行している。このため、第１実施形態と同様に、通信インタフェースに依存せずに、バッファ処理部３００とパケット処理部４００を使用でき、受信パケットをジャンボフレームに構成することができる。また、第１、第２実施形態と同様に、バッファが配置されているメモリを効率的に使用することができる。
【００４９】
なお、第１実施形態の変形例において記載した変形例は、第３実施形態にも適用できることは明らかである。また、上記各実施形態において、通信部を第１通信部１１３と第２通信部１１６の２つとしているが、３つ以上であっても構わない。また、バッファ確保部３０２は、複数の通信部のそれぞれについて通常メモリ（ＤＲＡＭ１０１）と高速メモリ（ＳＲＡＭ１０２）のいずれからバッファを確保するかを関連付けておき、通信部ごとにバッファを確保するメモリを切り替えるようにしてもよい。また、通信部は、通信速度の異なる複数種類の通信部を含んでもよい。例えば、第２通信部１１６が第１通信部１１３よりも高速な通信が可能であるようにしてもよい。そして、バッファ確保部３０２は、高速通信が可能な第２通信部１１６に対して高速メモリからバッファを確保し、第１通信部１１３に対して通常メモリからバッファを確保するようにしてもよい。また、バッファ確保部３０２は、高速通信を行う第２通信部１１６に対して優先してバッファを確保するようにしてもよい。
【００５０】
［その他の実施形態］
本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサーがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。
【符号の説明】
【００５１】
１０１：ＤＲＡＭ、１０２：ＳＲＡＭ、１０３：ＣＰＵ、１０４：ＲＯＭ、１０５：タイマ管理部、３００：：バッファ処理部、４００：パケット処理部、５００：パケット格納部、１１３：第１通信部、１１６：第２通信部
【図１】
2019205064.tif 000003
【図２】
2019205064.tif 000004
【図３】
2019205064.tif 000005
【図４】
2019205064.tif 000006
【図５】
2019205064.tif 000007