JP2020178182A - 通信装置、通信装置の制御方法およびプログラム - Google Patents

Abstract

【課題】高速メモリの容量が十分でない場合であっても、パケットの生成および送信における通信性能が低下することを有効に防止する。【解決手段】通信装置は、複数の領域を含む第１の送信バッファを取得して前記第１の送信バッファの前記複数の領域のそれぞれに送信データのペイロードを格納し、複数の領域を含む第２の送信バッファを第１のメモリに取得し、第１の送信バッファに格納されるペイロードに対応するヘッダを生成し、第２の送信バッファの複数の領域のそれぞれに生成されたヘッダを格納し、第１の送信バッファに格納されるペイロードを第２の送信バッファに格納されるヘッダに関連付ける情報を格納する領域を、第１のメモリと異なる第２のメモリに取得して、当該情報を当該領域に格納し、第１の送信バッファに格納されたペイロード、および第２の送信バッファに格納されたヘッダを入力として、第２のメモリの領域に格納される情報に基づいてパケットを生成する。【選択図】 図４

Description

本発明は、通信パケットの送信に伴う通信プロトコル処理を実行可能な通信装置に関する。

ＴＣＰ／ＩＰプロトコル（Ｔｒａｎｓｐｏｒｔ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ／Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ）処理では、送信側装置は、送信データのパケット化や再送処理にネットワークバッファを使用する。
このＴＣＰ／ＩＰプロトコル処理に伴うＣＰＵ（Ｃｅｎｔｒａｌ Ｐｒｏｃｅｓｓｉｎｇ Ｕｎｉｔ）の負荷を軽減し、パケット送信処理を高速化するため、ハードウエアオフロードを利用する技術がある。
こうしたハードウエアオフロード技術の１つに、送信データをセグメントへチャンク化する処理と、チャンク化されたセグメントをＩＰパケット化する処理を、ネットワークＩ／Ｆでハードウエアオフロードする技術がある。

上記のようなハードウエアオフロードを利用する技術は、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ）機能により実現できる。このＴＳＯ機能は、例えばＮＩＣ（Ｎｅｔｗｏｒｋ Ｉｎｔｅｒｆａｃｅ Ｃａｒｄ）等のハードウエアオフロードで実行される。
このＴＳＯ処理では、ネットワークバッファに転送されたデータを送信単位であるＭＳＳより大きなサイズで読み出してＴＣＰ／ＩＰプロトコル処理を行う。その後、ＴＣＰ／ＩＰプロトコル処理されたパケットをＭＳＳに基づいてパケット単位にチャンク化することで、複数のパケットを一度に生成し、連続送信することができる。ＴＳＯ処理により複数のパケットを一括生成することで、パケットごとに実行していたＴＣＰ／ＩＰプロトコル処理が、複数パケットに１回の実行に軽減されることとなり、ＣＰＵの負荷を軽減するとともにパケット送信処理を高速化することが実現できる。

特許文献１は、最大転送単位を超えるロングパケットを生成し、生成されたロングパケットのペイロードを分割するとともにロングパケットのヘッダを複製して、複数のパケットを同時に生成するネットワーク処理装置を開示する。
具体的には、特許文献１の技術では、ネットワーク処理装置は、最大転送単位を超えるデータ長のロングパケットをプロトコルスタックから受け取り、ロングパケットのペイロードを分割するとともに、ロングパケットのヘッダを複製する。複製されたヘッダを、分割されたペイロードにそれぞれ付加することで、最大転送単位以下のデータ長のショートパケットが複数一括して生成される。

特開２００７−２６６７５９号公報

ところで、特にハードウエアオフロードを用いたＴＣＰ／ＩＰプロトコル処理の場合、ユーザデータから複数のパケットを生成するのに複数回に亘りネットワークバッファが使用される。具体的には、ユーザデータをネットワークバッファへコピーする処理、ネットワークプロセッサがユーザデータをＭＳＳ以下のペイロードに分割する処理、ヘッダを複製および編集する処理等で、ネットワークバッファへの書き込みおよび読み出しが発生する。これらの処理で使用されるネットワークバッファを高速メモリ上に構築すれば、パケット生成および送信処理も高速化できる。

しかしながら、上記の処理のすべてで、ネットワークバッファの構築先として高速メモリを使用すると、高速メモリのメモリ容量が不十分な場合、ネットワークバッファの獲得やアクセスがパケット生成および送信処理のボトルネックになりかねない。このように、ネットワークバッファの構築先である高速メモリの容量が不足することで、ＴＣＰ／ＩＰプロトコル処理におけるパケットの生成処理の処理効率を低下させ、パケットの送信処理全体の通信性能も低下させるおそれがある。

本発明は、上述の課題に鑑みてなされたものであり、送信パケットの生成に用いられる１つのメモリの容量が十分でない場合であっても、送信パケットの生成に係る性能が低下することを抑制することを目的とする。

上記課題を解決するため、本発明に係るある態様の通信装置は、複数の領域を含み、前記複数の領域のそれぞれに送信データのペイロードを格納する第１の送信バッファと、前記第１の送信バッファに格納される前記ペイロードに対応するヘッダを生成する第１の生成手段と、複数の領域を含み、前記複数の領域のそれぞれに前記第１の生成手段により生成された前記ヘッダを格納する第２の送信バッファと、前記第１の送信バッファに格納される前記ペイロードを前記第２の送信バッファに格納される前記ヘッダに関連付ける情報を格納する格納手段と、前記第２の送信バッファを第１のメモリにおいて取得し、前記格納手段のための領域を前記第１のメモリと異なる第２のメモリにおいて取得する取得手段と、前記第１の送信バッファに格納された前記ペイロード、および前記第２の送信バッファに格納された前記ヘッダを入力として、前記格納手段に格納される前記情報に基づいてパケットを生成する第２の生成手段とを備える。

本発明によれば、送信パケットの生成に用いられる１つのメモリの容量が十分でない場合であっても、送信パケットの生成に係る性能が低下することを抑制することができる。

本実施形態に係る通信装置１のハードウエア構成の一例を示すブロック図 通信装置１の機能構成の一例を示すブロック図 バッファ管理部２５が管理する送信バッファの構成の一例を示す図 実施形態１に係る通信装置１が実行するパケット生成および送信処理の詳細処理手順の一例を示すフローチャート 実施形態２に係る通信装置１が実行するパケット生成および送信処理の詳細処理手順の一例を示すフローチャート

以下、添付図面を参照して、本発明を実施するための実施形態について詳細に説明する。なお、以下に説明する実施形態は、本発明の実現手段としての一例であり、本発明が適用される装置の構成や各種条件によって適宜修正又は変更されるべきものであり、本発明は以下の実施形態に必ずしも限定されるものではない。また、本実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。なお、同一の構成については、同じ符号を付して説明する。

（実施形態１）
本実施形態において、通信装置は、高速メモリおよび通常メモリを備え、送信データからパケットを生成する際に、高速メモリおよび通常メモリのいずれかにパケット送信用のバッファを取得してよい。また、この送信データからパケットを生成する処理の少なくとも一部は、例えば、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ）技術を使用してオフロード実行されてよい。
以下では、通信装置が、ＴＣＰ／ＩＰの通信プロトコルに従ってＴＣＰ／ＩＰパケットを生成する例を説明するが、本実施形態は、ＵＤＰ（Ｕｓｅｒ Ｄｉａｇｒａｍ Ｐｒｏｔｏｃｏｌ）等の他の通信プロトコルを適用することも可能である。
また、通信装置が生成するパケットの通信ヘッダは、ＴＣＰヘッダ、ＩＰヘッダ（ＩＰｖ４ヘッダ、ＩＰｖ６ヘッダ）、およびイーサネット（登録商標）ヘッダを含んでよい。

＜本実施形態のハードウエアおよび機能構成＞
図１は、本実施形態に係る通信装置のハードウエア構成の一例を示す図である。
通信装置１は、ＲＡＭ１１、ＣＰＵ１２、ＲＯＭ１３、タイマ管理部１４、通信部１５、バッファ管理部１６、データ転送部１７、チェックサム計算部１８、フレーム生成部１９、およびパケット生成部２０を備える。ＲＡＭ１１、ＣＰＵ１２、ＲＯＭ１３、タイマ管理部１４、通信部１５、バッファ管理部１６、データ転送部１７、チェックサム計算部１８、フレーム生成部１９、およびパケット生成部２０は、システムバス１０を介して相互に接続されている。

ＲＡＭ（Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）１１は、システムバス１０を介して、通信装置１内の各ブロックが共有して利用可能な記憶領域であり、各種データの保存やワークメモリとして使用される。ＲＡＭ１１は、通信装置１が送受信するデータを格納して管理するためのネットワークバッファが取得されるメモリであり、通常メモリ１１ａと高速メモリ１１ｂとを有する。
通常メモリ１１ａは、例えば主としてＤＲＡＭ（Ｄｙｎａｍｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の半導体メモリで構成されてよい。
高速メモリ１１ｂは、データ転送要求からデータ転送完了までの遅延時間であるアクセスレイテンシが通常メモリ１１ａより小さいメモリである。高速メモリ１１ｂは、例えば主としてＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）等の半導体メモリで構成されてよい。

ＣＰＵ１２は、通信装置１における動作を統括的に制御するものであり、システムバス１０を介して各構成部（１２〜２０）を制御する。ＣＰＵ１２は、ＲＡＭ１１をワークメモリとして、ＲＯＭ１３、または外部メモリやハードディスク等の各種記録媒体（不図示）に格納された各種プログラムを実行する。
ＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１３は、ＣＰＵ１２が各種処理を実行するために必要な制御プログラム等を記憶する不揮発性メモリである。なお、これら制御プログラム等は、外部メモリやハードディスク等の着脱可能な記憶媒体に記憶されていてもよい。

タイマ管理部１４は、通信装置１がパケット生成および送信処理を実行するために必要となる所定時間を計測および管理する。
通信部１５は、例えばイーサネット（登録商標）等のネットワークとのインタフェースを提供し、ネットワークを介して外部装置との通信を実行する。通信部１５は、データリンク層（ＭＡＣ層）の通信制御を担うＭＡＣモジュール１５ａと、物理層（ＰＨＹ層）の通信制御を担うＰＨＹモジュール１５ｂとを有する。

データの送受信は、ＣＰＵ１２によりネットワークドライバが実行され、これに応じてＭＡＣ１５ａのモジュールが制御されることにより行われる。なお、本実施形態では、通信部１５は、イーサネット（登録商標）等の通信規格に準拠する有線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を介した通信を実行するものとして説明する。ただし、本実施形態で利用可能なネットワークはこれに限定されず、無線ネットワークで構成されてもよい。この無線ネットワークは、Ｂｌｕｅｔｏｏｔｈ（登録商標）、ＺｉｇＢｅｅ（登録商標）、ＵＷＢ（Ｕｌｔｒａ Ｗｉｄｅ Ｂａｎｄ）等の無線ＰＡＮ（Ｐｅｒｓｏｎａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）を含む。また、Ｗｉ−Ｆｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）（登録商標）等の無線ＬＡＮ（Ｌｏｃａｌ Ａｒｅａ Ｎｅｔｗｏｒｋ）や、ＷｉＭＡＸ（登録商標）等の無線ＭＡＮ（Ｍｅｔｒｏｐｏｌｉｔａｎ Ａｒｅａ Ｎｅｔｗｏｒｋ）を含む。さらに、ＬＴＥ／３Ｇ等の無線ＷＡＮ（Ｗｉｄｅ Ａｒｅａ Ｎｅｔｗｏｒｋ）を含む。なお、ネットワークは、各機器を相互に通信可能に接続し、ＩＰ通信が可能であればよく、通信の規格、規模、構成は上記に限定されない。
なお、本実施形態に係る通信装置１が送信するパケットは、ＩＰ通信上で送受信されるデータの単位である。

バッファ管理部１６は、ＲＡＭ１１の通常メモリ１１aまたは高速メモリ１１ｂのいずれか１つ以上に、パケット送信用のバッファを取得して管理する。バッファ管理部１６がＲＡＭ１１で管理するバッファは、ペイロード用のバッファ、ペイロードに対応するヘッダ用のバッファを含む。
本実施形態において、バッファ管理部１６はまた、ペイロード用のバッファに格納されるペイロードとヘッダ用のバッファに格納されるヘッダとを関連付けるバッファ管理情報（以下、単に「管理情報」という。）を格納するための領域も取得する。本実施形態において、この管理情報用の領域は、ヘッダ用のバッファが取得されるメモリと異なるメモリに取得されてよい。
この管理情報は、ペイロード用のバッファに格納される送信データのペイロードをヘッダ用のバッファに格納されるヘッダに関連付けて連結するためのポインタ情報と、それぞれのヘッダを生成するための情報、例えばヘッダ長の情報を含む。

データ転送部１７は、例えば、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）により構成され、ＲＡＭ１１に記憶されているデータを、フレーム生成部１９やパケット生成部２０に転送する。データ転送部１７によるデータ転送は、ＣＰＵ１２により制御されてもよい。
チェックサム計算部１８は、第１チェックサム計算部１８ａおよび第２チェックサム計算部１８ｂを有し、ＲＡＭ１１に記憶されている送信データに対して、チェックサムを計算する。第１チェックサム計算部１８ａは、ＭＳＳ単位にチャンク化された送信データのセグメントに対して、複数のヘッダ生成に先立って事前にチェックサムを計算する。第２チェックサム計算部１８ｂは、第１チェックサム計算部１８ａにより事前に計算されたチェックサムが複数のヘッダを生成する際にそのまま使用できないと判断された場合に、チェックサムを再計算する。

フレーム生成部１９は、ネットワークへ送信する送信データサイズを決定し、決定されたサイズの送信データに対して付加されるべきヘッダを生成するためのヘッダ情報を生成する。
パケット生成部２０は、フレーム生成部１９により決定された送信データサイズと、フレーム生成部１９により生成されたヘッダ情報に基づいて、送信データをチャンク化してセグメントを生成するとともにヘッダを生成する。パケット生成部２０は、当該セグメントとヘッダから送信すべきパケットを生成する。

図２は、本実施形態に係る通信装置１の機能構成の一例を示す図である。
図２に示す通信装置１の各機能モジュールのうち、ソフトウエアにより実現される機能については、各機能モジュールの機能を提供するためのプログラムがＲＯＭ等のメモリに記憶され、ＲＡＭに読み出してＣＰＵが実行することにより実現される。ハードウエアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからＦＰＧＡ上に自動的に専用回路を生成すればよい。ＦＰＧＡとは、Ｆｉｅｌｄ Ｐｒｏｇｒａｍｍａｂｌｅ Ｇａｔｅ Ａｒｒａｙの略である。また、ＦＰＧＡと同様にしてＧａｔｅ Ａｒｒａｙ回路を形成し、ハードウエアとして実現するようにしてもよい。また、ＡＳＩＣ（Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）により実現するようにしてもよい。なお、図２に示した機能ブロックの構成は一例であり、複数の機能ブロックが１つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。

通信装置１は、アプリケーション２１、プロトコルスタック２２、データ転送部２３、パケット生成部２４、バッファ管理部２５、通信Ｉ／Ｆ制御部２６、および通信Ｉ／Ｆ２７を備える。
アプリケーション２１は、通信装置１上で稼動する各種ユーザアプリケーションである。アプリケーション２１は、送信されるべき、任意のサイズのユーザデータ（送信データ）を、プロトコルスタック２２に入力する。
プロトコルスタック２２は、送信データ管理部２２１、コネクション管理部２２２、ウィンドウ制御部２２３、輻輳制御部２２４、セグメント処理部２２５、および通信プロトコル処理部２２６を備える。
アプリケーション２１から入力された送信データは、ＲＡＭ１１の通常メモリ１１ａと高速メモリ１１ｂのいずれかに取得されるパケット送信用のバッファ（以下、「送信バッファ」という）に格納されて、バッファ管理部２５により管理される。

送信データ管理部２２１は、送信バッファに格納されている送信データのサイズを管理する。
図３を参照して、送信データは、ＲＡＭ１１内の通常メモリ１１ａに取得されるペイロード用バッファ３１または高速メモリ１１ｂに取得されるペイロード用バッファ３２のいずれかに格納される。ペイロードバッファ３１、３２には、複数のバッファ領域のそれぞれの管理情報が付加される。
図２に戻り、コネクション管理部２２２は、通信装置１がネットワークを介して対向通信装置と通信するための通信コネクションを管理する。コネクション管理部２２２は例えば、アプリケーション２１に対応する通信コネクションにおけるＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）等のコネクション情報を管理する。
ウィンドウ制御部２２３は、通信Ｉ／Ｆ制御部２６を介して受信された確認応答（ＡＣＫ）から、ＴＣＰコネクションの送信ウィンドウサイズを取得して管理する。
輻輳制御部２２４は、ＴＣＰコネクションにおける輻輳制御を管理する。輻輳制御部２２４は例えば、アプリケーション２１に対応する通信コネクションにおける輻輳ウインドウを管理する。

セグメント管理部２２５は、送信データサイズを決定する。
具体的には、セグメント管理部２２５は、送信データ管理部２２１により管理される、通常メモリ１１ａまたは高速メモリ１１ｂの送信バッファ中の送信データのサイズに基づいて、送信データサイズを決定する。セグメント管理部２２５はまた、コネクション管理部２２２が管理するＭＳＳ、ウインドウ制御部２２３が管理する送信ウインドウサイズ、および輻輳制御部２２４が管理する輻輳ウインドウサイズ等に基づいて送信データサイズを決定する。
ＴＣＰ／ＩＰプロトコル処理では、送信側のパケット送信の度に受信側がＡＣＫを送信することによる通信速度の低下を回避するため、所定のウィンドウサイズを利用するウィンドウ制御が行われる。ＴＣＰ／ＩＰのウィンドウ制御では、受信側は、受信バッファの残りサイズをウィンドウサイズに設定したＡＣＫを送信し、送信側は、ウィンドウサイズになるまでＡＣＫを待つことなく送信データを送信することができる。さらに、ＴＣＰ／ＩＰのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側はパケットを受信する度にＡＣＫを送信し、送信側は最初のＡＣＫを受信するとウィンドウをスライドさせて、次のＡＣＫを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。

通信プロトコル処理部２２６は、ＴＣＰセグメントのＴＣＰヘッダやＩＰヘッダを生成するとともに、ヘッダに書き込むべきチェックサムの計算処理を行い、送信すべきパケットを生成する。
データ転送部２３は、図１のデータ転送部１７に対応し、通常メモリ１１aまたは高速メモリ１１ｂの送信バッファに格納される送信データをプロトコルスタック２２へデータ転送する。
データ転送部２３は、チャンク化部２３１、およびチェックサム計算部２３２を備える。チャンク化部２３１は、送信バッファに格納される送信データがプロトコルスタック２２へ転送される際に、送信データを所定の単位（例えば、ＭＳＳ単位）にチャンク化してセグメントを生成する。
チェックサム計算部２３２は、図１のチェックサム計算部１８に対応し、チャンク化部２３１によりチャンク化された送信データのセグメントのそれぞれに対して、チェックサムを計算する。

パケット生成部２４は、図１のパケット生成部２０に対応し、データ転送部２４１、ヘッダ生成部２４２、およびパケット化部２４３を有する。パケット生成部２４の機能の全部または一部は、ハードウエアオフロードされてよい。
データ転送部２４１は、送信バッファに格納される送信データを所定の単位（例えば、ＭＳＳ単位）にチャンク化するとともに、チェックサムを計算する。データ転送部２４１は特に、データ転送部２３により実行された送信データのチャンク化およびチェックサム事前計算を、例えば他の通信装置との通信状況等により、再度実行しなければならない場合に呼び出されてよい。
ヘッダ生成部２４２は、フレーム生成部１９により生成されたヘッダ情報に基づいて、ＴＣＰ／ＩＰヘッダ、およびイーサネットヘッダを生成する。具体的には、ヘッダ生成部２４２は、図１のバッファ管理部１６に対応するバッファ管理部２５が管理する管理情報に基づき、高速メモリ１１ｂまたは通常メモリ１１ａのいずれかに取得されるヘッダ用バッファを用いて、ヘッダを生成する。

図３を参照して、ヘッダ生成部２４２が用いるヘッダ用バッファは、ＲＡＭ１１の高速メモリ１１ｂに取得されるヘッダ用バッファ３５、または通常メモリ１１aに取得されるヘッダ用バッファ３３のいずれかである。
管理情報３４は、送信バッファに格納されるペイロードを、高速メモリ１１ｂ内のヘッダ用バッファ３５に格納されるヘッダに関連付ける。管理情報３４により高速メモリ１１ｂ内のヘッダに関連付けられるペイロードは、通常メモリ１１ａ内のペイロード用バッファ３１または高速メモリ１１ｂ内のペイロード用バッファ３２に格納される。
パケット化部２４３は、データ転送部２４１から出力されるチャンク化されたセグメントと、ヘッダ生成部２４２から出力されるヘッダとをパケット化して、パケットを生成する。
バッファ管理部２５は、通常メモリ１１ａまたは高速メモリ１１ｂに取得されるバッファを管理する。通常メモリ１１ａには、ペイロード用バッファ３１、ヘッダ用バッファ３３、および管理情報３４用のバッファ領域が取得されてよい。高速メモリ１１ｂには、ペイロード用バッファ３２、およびヘッダ用バッファ３５が取得されてよい。

本実施形態では、セグメント処理部２２５により決定された送信データサイズに応じて、通信プロトコル処理部２２６またはパケット生成部２４が、バッファ管理部２５により管理される各種送信バッファを用いて、パケットを生成する。パケットの具体的な生成手順は、図４を参照して後述する。
通信プロトコル処理部２２６またはパケット生成部２４により生成されたパケットは、通信Ｉ／Ｆ制御部２６に入力される。
通信Ｉ／Ｆ制御部２６は、プロトコルスタック２２と通信Ｉ／Ｆ２７との間で、各種データや制御情報のやり取りを担う。
通信Ｉ／Ｆ２７は、図１のＭＡＣモジュール１０８、およびＰＨＹモジュール１０９に対応し、ネットワークと通信を行う。パケットの送信は、タイマ管理部１４により一定時間以上経過したことが通知された場合に実行されてもよい。

＜通信装置１のパケット送信処理の処理フロー＞
図３は、本実施形態に係る通信装置１が実行するパケット送信処理の詳細処理手順の一例を示すフローチャートである。図３に示すフローチャートは、アプリケーション２１がソケットＡＰＩ ｓｅｎｄ（）を呼び出した場合を想定するが、パケット送信処理を起動するトリガは、アプリケーション２１からの呼び出しに限定されない。
Ｓ１で、ＣＰＵ１２によりＲＯＭ１３に格納されている所定のプログラムが実行されることに応じて、アプリケーション２１は、ソケットＡＰＩ ｓｅｎｄ（）を呼び出す。

ソケットＡＰＩ ｓｅｎｄ（）が呼び出されると、Ｓ２で、データ転送部１７は、バッファ管理部１６を介して、送信データを格納するペイロード用バッファをＲＡＭ１１内に取得する。Ｓ２では、データ転送部１７は、ペイロード用バッファを、通常メモリ１１ａのペイロード用バッファ３１、または高速メモリ１１ｂのペイロード用バッファ３２のいずれかから取得する。
Ｓ３で、データ転送部１７は、Ｓ２で取得されたペイロード用バッファへ、Ｓ１で受け渡された送信データを転送する。ユーザデータの転送先は、ＲＡＭ１１内の通常メモリ１１ａのペイロード用バッファ３１、または高速メモリ１１ｂのペイロード用バッファ３２のいずれかである。
ユーザデータをペイロード用バッファ３１、３２へ転送する際、データ転送部１７は、送信データをＭＳＳ単位にチャンク化し、チャンク化された送信データに対して、チェックサムを事前に計算する。

Ｓ４で、データ転送部１７は、チャンク化された送信データを、チャンク化された送信データに対して計算されたチェックサム値に関連付けるとともに、チャンク化された送信データ（ペイロード）を、ペイロード用バッファ３１、３２に格納する。ペイロード用バッファ３１、３２中の複数のバッファ領域に格納されるチャンク化された送信データは、送信データ管理部２２１により管理される送信データのサイズで、送信バッファ内で連結される。

Ｓ５で、セグメント処理部２２５は、送信バッファに連結される送信データについて、送信データ管理部２２１により管理される送信データサイズが、ウインドウ制御部２２３により管理される送信ウインドウサイズを超えるか否かを判定する。
送信データ管理部２２１が管理する送信データサイズが、送信ウインドウサイズを超えない場合（Ｓ５：Ｎ）、Ｓ６に進み、セグメント処理部２２５は、送信バッファに格納されている送信データの送信データサイズをそのまま送信データサイズに決定する。一方、送信データサイズが、送信ウインドウサイズを超える場合（Ｓ５：Ｙ）、Ｓ７に進み、セグメント処理部２２５は、送信バッファに格納されている送信データの送信データサイズを、送信ウインドウサイズに変更する。

Ｓ８で、通信プロトコル処理部２２６は、Ｓ６またはＳ７で決定された送信データサイズが、コネクション管理部２２２により管理されるＭＳＳを超えるか否かを判定する。決定された送信データサイズが、ＭＳＳを超えない場合（Ｓ８：Ｎ）、Ｓ９に進み、一方、決定された送信データサイズが、ＭＳＳを超える場合（Ｓ８：Ｙ）、Ｓ１１へ進む。
決定された送信データサイズがＭＳＳを超えない場合、Ｓ９で、通信プロトコル処理部２２６は、バッファ管理部２５を介して、ＲＡＭ１１内の通常メモリ１１ａのヘッダ用バッファ３３から送信バッファを取得し、Ｓ１０に進む。
Ｓ１０で、通信プロトコル処理部２２６は、通常メモリ１１ａのヘッダ用バッファ３３から取得された送信バッファに対して、ＣＰＵ１２によりＲＯＭ１３に格納されている所定のプログラムを実行する。具体的には、通信プロトコル処理部２２６は、送信バッファの送信データに対して、パケット生成部２０を制御してチェックサムを計算し、ＴＣＰ／ＩＰヘッダを生成し、ＴＣＰ／ＩＰヘッダを用いて送信データをパケット化して、ＴＣＰ／ＩＰパケットを生成する。
通信プロトコル処理部２２６はさらに、ＴＣＰ／ＩＰパケットに対するイーサネットヘッダを生成し、生成したイーサネットヘッダを用いて、ＴＣＰ／ＩＰパケットをイーサネットフレーム化して、Ｓ１７へ進む。

Ｓ８に戻り、一方、決定された送信データサイズがＭＳＳを超える場合、Ｓ１１で、フレーム生成部１９は、ＴＣＰ／ＩＰヘッダ、およびイーサネットヘッダを生成するための情報として、ヘッダ情報を生成する。
Ｓ１２で、バッファ管理部２５は、ＲＡＭ１１内の高速メモリ１１ｂのヘッダ用バッファ３５から、ヘッダ用のバッファを取得する。バッファ管理部２５はまた、ＲＡＭ１１内の通常メモリ１１ａの領域に、管理情報３４を格納する領域を取得する。この管理情報３４は、通常メモリ１１ａまたは高速メモリ１１ｂのペイロード用バッファに格納される送信データのセグメントに、高速メモリ１１ｂのヘッダ用バッファ３５に格納されるヘッダを関連付け連結するための情報（関連付け情報）である。

Ｓ１３で、データ転送部２３は、チャンク化された各送信データと関連付けられているチェックサム値が使用可能か否かを判定する。
各送信データと関連付けられているチェックサム値が使用可能である場合（Ｓ１３：Ｙ）、Ｓ１４に進み、一方、チェックサム値が使用可能でない場合（Ｓ１３：Ｎ）、Ｓ１５に進む。
チェックサム値が使用可能である場合、Ｓ１４で、ヘッダ生成部２４２は、各送信データと関連付けられる、事前計算されたチェックサム値を利用し、データ転送部２４１は、チェックサム値の再計算や送信データの再チャンク化を行わない。
ヘッダ生成部２４２は、Ｓ１１で生成されたヘッダ情報を使用し、ＴＣＰ／ＩＰヘッダとイーサネットヘッダとを、ＲＡＭ１１の高速メモリ１８ｂのヘッダ用バッファ３５に自動的に生成する。また、パケット生成部２４は、管理情報３４を生成して、Ｓ１２で取得された通常メモリ１８ａ内の管理情報３４用の領域に格納する。

一方、各送信データと関連付けられているチェックサム値が使用可能でない場合、Ｓ１５で、パケット生成部２４のデータ転送部２４１は、チャンク化された各送信データのチェックサム値を再計算する。また、ヘッダ生成部２４２は、Ｓ１１で生成されたヘッダ情報を使用して、ＴＣＰ／ＩＰヘッダとイーサネットヘッダとを、ＲＡＭ１１の高速メモリ１８ｂのヘッダ用バッファ３５に自動的に生成する。また、パケット生成部２４は、管理情報３４を生成して、Ｓ１２で取得された通常メモリａ内の管理情報３４用の領域に格納する。
上記Ｓ１３〜Ｓ１５の処理は、図１のパケット生成部２０に対応する図２のパケット生成部２４により実行される処理である。

Ｓ１６で、パケット化部２４３は、Ｓ１４またはＳ１５で生成されたイーサネットヘッダと、ＴＣＰ／ＩＰヘッダと、送信データのセグメントとを、管理情報３４により連結し、ＴＣＰ／ＩＰパケットを生成して、イーサネットフレーム化する。なお、一度に連結できるセグメントの数は、輻輳制御部２２４により管理される輻輳ウインドウサイズに基づいて決定されてよい。
Ｓ１７で、通信プロトコル処理部２２６は、生成されたイーサネットフレームを、通信Ｉ／Ｆ制御部２６に送信して、処理を終了する。通信Ｉ／Ｆ制御部２６は、通信Ｉ／Ｆ２７を介して、イーサネットフレームをネットワークへ送信する。

以上説明したように、本実施形態によれば、通信装置１は、送信データをパケット化する処理において、送信データサイズがＭＳＳを超える場合、ヘッダを生成するために使用するバッファを高速メモリに取得する。一方、通信装置１は、ペイロード用のバッファに格納される送信データのセグメントを対応するヘッダに関連付けて連結する管理情報は、高速メモリよりアクセスレイテンシが小さい通常メモリに格納する。
ＭＳＳより大きいサイズの送信データから複数のパケットを一括して生成する際に、アクセス頻度の高いヘッダ用バッファを高速メモリに取得することで、ハードウエアオフロードによる高速処理に追従してパケット生成することができる。一方、セグメントをヘッダに連結する際に参照されればよい管理情報を通常メモリに格納することで、高速メモリの容量が十分でない場合であっても、パケット生成および送信における通信性能の低下が有効に防止される。

また、各送信データのセグメントに連結されるべき複数のＴＣＰ／ＩＰヘッダをハードウエアオフロードにより一括生成する際に、事前に計算されたチェックサム値を利用することができる。ただし、ハードウエアオフロードによる処理をＣＰＵにより実行されるソフトウエアで処理した場合であっても、本実施形態を適用することができる。
さらに、通信Ｉ／Ｆ２７が１つ存在する例を説明したが、複数の通信Ｉ／Ｆを有する通信装置であっても本実施形態を適用することができる。

（実施形態２）
以下、実施形態２を、図５を参照して、上記の実施形態１と異なる点についてのみ詳細に説明する。実施形態２は、送信データサイズがＭＳＳを超える場合、さらに、管理情報と、高速メモリ上にヘッダ用バッファが取得できるか否かを判定して、ヘッダ生成およびパケット化をハードウエアオフロードするかソフトウエア処理で実行するかを決定する。

実施形態２に係る通信装置１のハードウエア構成および機能構成は、図１および図２にそれぞれ示される実施形態１と同様である。
図５は、実施形態２に係る通信装置１が実行するパケットの生成および送信処理の処理手順の一例を示すフローチャートである。図５では、図４のフローチャートに対して、Ｓ１８および図１９が追加されている。
Ｓ１〜Ｓ１１までの各処理は、図４に示すＳ１〜Ｓ１１までの処理と同様である。

Ｓ８で送信データサイズがＭＳＳを超えると判定され（Ｓ８：Ｙ）、Ｓ１１で複数ヘッダを一括生成するためのヘッダ情報が生成されると、Ｓ１８で、管理情報３４と、高速メモリ１８ｂ上にヘッダ用バッファ３５が取得できるか否かが判定される。
管理情報３４と、高速メモリ１８ｂ上にヘッダ用バッファ３５が取得できないと判定された場合（Ｓ１８：Ｎ）、Ｓ１９に進む。
Ｓ１９で、バッファ管理部２５は、ＲＡＭ１１内の通常メモリ１８ａのヘッダ用バッファ３３からバッファを取得し、Ｓ１３に進む。
Ｓ１３〜Ｓ１７の処理は、図４に示される実施形態１のＳ１３〜Ｓ１７と同様である。ただし、本実施形態では、ＣＰＵ１２により所定のプログラムを実行するソフトウエア処理により、Ｓ１３〜Ｓ１５で、各セグメントに対するＴＣＰ／ＩＰヘッダおよびイーサネットヘッダを通常メモリ１８ａ内のヘッダ用バッファ３３に生成する。また、Ｓ１６で、パケット化部２４３は、ヘッダ用バッファ３３内のヘッダに対応して生成された管理情報に基づいて、通常メモリ１８ａ内のヘッダ用バッファ３３に生成されたヘッダを送信データのセグメントに連結してイーサネットフレーム化する。

一方、Ｓ１８で、管理情報３４と、高速メモリ１８ａ上にヘッダ用バッファ３５が取得できると判定された場合（Ｓ１８：Ｙ）、Ｓ１２に進む。
Ｓ１２〜Ｓ１７の処理は、図４に示される実施形態１のＳ１２〜Ｓ１７と同様である。すなわち、Ｓ１２で、バッファ管理部２５は、ＲＡＭ１１内の高速メモリ１１ｂのヘッダ用バッファ３５から、ヘッダ用のバッファを取得する。バッファ管理部２５はまた、ＲＡＭ１１内の通常メモリ１１ａの領域に、管理情報３４を格納する領域を取得する。
また、Ｓ１３〜Ｓ１５で、ハードウエアオフロードにより、各セグメントに対するＴＣＰ／ＩＰヘッダおよびイーサネットヘッダを高速メモリ１８ｂ内のヘッダ用バッファ３５に生成する。また、Ｓ１６で、パケット化部２４３は、通常メモリ１８ａ内の領域に格納された管理情報に基づいて、高速メモリ１８ｂ内のヘッダ用バッファ３５に生成されたヘッダを送信データのセグメントに連結してイーサネットフレーム化する。
なお、一度に連結できるセグメントの数は、輻輳ウインドウサイズに基づいて決定されてよい。

以上説明したように、本実施形態によれば、通信装置１は、送信データサイズがＭＳＳを超える場合、さらに、管理情報と、高速メモリ上にヘッダ用バッファが取得できるか否かを判定する。通信装置１は、管理情報と、高速メモリ上にヘッダ用バッファが取得可能な場合にハードウエアオフロードで複数パケットを一括生成し、取得できない場合にソフトウエア処理でパケットを生成する。
これにより、高速メモリの容量が十分でない場合であっても、ヘッダ用バッファ取得に失敗することによるパケット生成処理の遅延が回避され、パケット生成および送信における通信性能の低下が有効に防止される。

なお、上述した各実施形態は、その複数を組み合わせて実現することが可能である。
また、本発明は、上述の実施形態の一部または１以上の機能を実現するプログラムによっても実現可能である。すなわち、そのプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータ（またはＣＰＵやＭＰＵ等）における１つ以上のプロセッサがプログラムを読出し実行する処理により実現可能である。また、そのプログラムをコンピュータ可読な記録媒体に記録して提供してもよい。
また、コンピュータが読みだしたプログラムを実行することにより、実施形態の機能が実現されるものに限定されない。例えば、プログラムの指示に基づき、コンピュータ上で稼働しているオペレーティングシステム（ＯＳ）などが実際の処理の一部または全部を行い、その処理によって上記した実施形態の機能が実現されてもよい。

１…通信装置、１０…システムバス、１１…ＲＡＭ、１１ａ…通常メモリ、１１ｂ…高速メモリ、１２…ＣＰＵ、１３…ＲＯＭ、１４…タイマ管理部、１５…通信部、１５ａ…ＭＡＣ、１５ｂ…ＰＨＹ、１６…バッファ管理部、１７…データ転送部、１８…チェックサム計算部、１９…フレーム生成部、２０…パケット生成部

Claims (11)

1. 複数の領域を含み、前記複数の領域のそれぞれに送信データのペイロードを格納する第１の送信バッファと、
   前記第１の送信バッファに格納される前記ペイロードに対応するヘッダを生成する第１の生成手段と、
   複数の領域を含み、前記複数の領域のそれぞれに前記第１の生成手段により生成された前記ヘッダを格納する第２の送信バッファと、
   前記第１の送信バッファに格納される前記ペイロードを前記第２の送信バッファに格納される前記ヘッダに関連付ける情報を格納する格納手段と、
   前記第２の送信バッファを第１のメモリにおいて取得し、前記格納手段のための領域を前記第１のメモリと異なる第２のメモリにおいて取得する取得手段と、
   前記第１の送信バッファに格納された前記ペイロード、および前記第２の送信バッファに格納された前記ヘッダを入力として、前記格納手段に格納される前記情報に基づいてパケットを生成する第２の生成手段と、
   を備えることを特徴とする通信装置。
2. 前記第２の送信バッファが取得される第１のメモリは、前記格納手段のための領域が取得される第２のメモリより小さいアクセスレイテンシを有することを特徴とする請求項１に記載の通信装置。
3. 前記送信データのサイズに基づいて、前記第２の送信バッファを前記第１のメモリと前記第２のメモリのいずれに取得するかを判定する判定手段をさらに備え、
   前記取得手段は、前記判定手段により、前記第２の送信バッファを前記第２のメモリに取得すると判定された場合、前記第２の送信バッファを、前記第１のメモリに替えて前記第２のメモリに取得することを特徴とする請求項１または２に記載の通信装置。
4. 前記判定手段は、前記送信データのサイズが、ＭＳＳ（Ｍａｘｉｍｕｍ Ｓｅｇｍｅｎｔ Ｓｉｚｅ）を超えない場合、前記第２の送信バッファを前記第２のメモリに取得すると判定することを特徴とする請求項３に記載の通信装置。
5. 前記送信データを前記ペイロードに分割して前記第１の送信バッファへ転送する転送手段と、
   前記転送手段により前記ペイロードが前記第１の送信バッファへ転送される際に、前記ペイロードに対するチェックサムを計算する計算手段と、
   をさらに備えることを特徴とする請求項１から４のいずれか１項に記載の通信装置。
6. 前記第１の生成手段は、前記手段により計算された前記チェックサムが使用可能か否かを判定し、前記チェックサムが使用可能でない場合、前記チェックサムを再計算し、再計算されたチェックサムを含むヘッダを生成することを特徴とする請求項５に記載の通信装置。
7. 前記第１の生成手段は、前記第２の送信バッファを前記第１のメモリに取得可能か否かを判定し、
   前記取得手段は、前記第１の生成手段により、前記第２の送信バッファを前記第１のメモリに取得できないと判定された場合、前記第２の送信バッファを、前記第１のメモリに替えて前記第２のメモリに取得することを特徴とする請求項１から６のいずれか１項に記載の通信装置。
8. 前記第１の生成手段は、前記第１の送信バッファに格納される前記ペイロードに対応するＴＣＰ／ＩＰヘッダを生成することを特徴とする請求項１から７のいずれか１項に記載の通信装置。
9. 前記第１の生成手段および前記第２の生成手段は、ＴＳＯ（ＴＣＰ Ｓｅｇｍｅｎｔａｔｉｏｎ Ｏｆｆｌｏａｄ）により、複数のパケットを一括して生成することを特徴とする請求項１から８のいずれか１項に記載の通信装置。
10. 通信装置の制御方法であって、
    複数の領域を含む第１の送信バッファを取得して前記第１の送信バッファの前記複数の領域のそれぞれに送信データのペイロードを格納するステップと、
    複数の領域を含む第２の送信バッファを第１のメモリにおいて取得するステップと、
    前記第１の送信バッファに格納される前記ペイロードに対応するヘッダを生成するステップと、
    前記第２の送信バッファの前記複数の領域のそれぞれに生成された前記ヘッダを格納するステップと、
    前記第１の送信バッファに格納される前記ペイロードを前記第２の送信バッファに格納される前記ヘッダに関連付ける情報を格納する領域を、前記第１のメモリと異なる第２のメモリにおいて取得して、前記情報を前記領域に格納するステップと、
    前記第１の送信バッファに格納された前記ペイロード、および前記第２の送信バッファに格納された前記ヘッダを入力として、前記第２のメモリの前記領域に格納される前記情報に基づいてパケットを生成するステップと、
    を含むことを特徴とする制御方法。
11. コンピュータを、請求項１から９のいずれか１項に記載の通信装置の各手段として機能させるためのプログラム。

Images