JP2021087172A

JP2021087172A - 通信装置、通信方法およびプログラム

Info

Publication number: JP2021087172A
Application number: JP2019216581A
Authority: JP
Inventors: 暁央木下; Akihisa Kinoshita
Original assignee: Canon Inc
Current assignee: Canon Inc
Priority date: 2019-11-29
Filing date: 2019-11-29
Publication date: 2021-06-03

Abstract

【課題】送信データのヘッダ又はパケットを生成する際、当該生成処理の完了待ちをポーリング又は割り込みで行うかを適切に選択できるようにすること。【解決手段】送信データを通信相手装置に送信する通信装置１０であって、送信データのパケット又はヘッダを生成する生成手段と、生成手段の処理内容に基づいて、生成手段の処理完了待ちをポーリングで行うか割り込みで行うかを選択する選択手段４０１と、生成手段により生成されたパケット又は生成手段により生成されたヘッダに対応するパケットを送信する送信手段と、を備える。【選択図】図２

Description

本発明は、パケットを送信する通信装置に関する。

ＴＣＰ／ＩＰのプロトコル処理では、ＣＰＵの処理軽減および高速送信のため、オフロード処理が用いられる。オフロード処理では、指定されたユーザデータをソケットＡＰＩ send()のコール毎にネットワークバッファへ転送する処理とチェックサム計算を同時にハードウェウェアオフロードで処理する。この場合、事前に計算したチェックサム値を用いて１ＭＳＳ以下のデータサイズを一つずつＣＰＵ処理でパケット化する。ＴＣＰ／ＩＰは、ＴｒａｎｓｍｉｓｓｉｏｎＣｏｎｔｒｏｌＰｒｏｔｏｃｏｌ/ＩｎｔｅｒｎｅｔＰｒｏｔｏｃｏｌの略である。ＣＰＵはＣｅｎｔｒａｌＰｒｏｃｅｓｓｉｎｇＵｎｉｔ（中央演算処理装置）の略である。ＡＰＩはＡｐｐｌｉｃａｔｉｏｎＰｒｏｇｒａｍｍｉｎｇＩｎｔｅｒｆａｃｅの略である。ＭＳＳはＭａｘｉｍｕｍＳｅｇｍｅｎｔＳｉｚｅの略である。

特許文献１には、リモートダイレクトメモリアクセスを使用して入力／出力処理をオフロードする技術が開示されている。特許文献１では、入力／出力処理が、ポーリングモード又は割り込みモードで完了する。

国際公開第２００５／０６７４３０号

しかしながら、特許文献１では、オフロード処理の内容に関係なく、入力／出力処理がポーリングモード又は割り込みモードで完了する。従って、ハードウェアオフロードを利用して送信データに対応するヘッダもしくはパケットを生成する際、例えば、ポーリングモード（あるいは割り込みモード）のみを使用したために通信効率が悪くなる場合も有り得る。例えば、ポーリングのみを使用して、オフロード処理の完了を応答性が高い周期で確認すると、ＣＰＵの処理負担が大きくなる。
本発明は上記した課題に鑑み、送信データのヘッダ又はパケットを生成する際、当該生成処理の完了待ちをポーリング又は割り込みで行うかを適切に選択できる技術を提供することを目的とする。

上記目的を達成するべく、本発明の１つの態様による通信装置は、送信データを通信相手装置に送信する通信装置であって、前記送信データのパケット又はヘッダを生成する生成手段と、前記生成手段の処理内容に基づいて、前記生成手段の処理完了待ちをポーリングで行うか割り込みで行うかを選択する選択手段と、前記生成手段により生成されたパケット又は前記生成手段により生成されたヘッダに対応するパケットを送信する送信手段と、を備える。

本発明によれば、送信データのヘッダ又はパケットを生成する際、当該生成処理の完了待ちをポーリング又は割り込みで行うかを適切に選択できる。

本発明の実施形態１に係る通信装置のハードウェア構成を示すブロック図。実施形態１の通信装置のソフトウェア構成を示すブロック図。実施形態１の通信装置が行うデータ送信処理を説明するフローチャート。実施形態２の通信装置が行うデータ送信処理を説明するフローチャート。

以下、添付図面を参照して本発明の実施形態を詳細に説明する。なお、以下の実施形態は本発明を限定するものではなく、また、実施形態で説明されている特徴の組み合わせの全てが本発明の解決手段に必須のものとは限らない。実施形態の構成は、本発明が適用される装置の仕様や各種条件（使用条件、使用環境等）によって適宜修正又は変更され得る。本発明の技術的範囲は、特許請求の範囲によって確定されるのであって、以下の個別の実施形態によって限定されない。

［実施形態１］
図１は、実施形態１における通信装置１０のハードウェア構成例を示すブロック図である。
実施形態１では、通信プロトコルとしてＴＣＰ／ＩＰを使用する。ＴＣＰ／ＩＰのプロトコル処理では、送信側（図１の通信装置１０）は、送信データのパケット化や再送処理のために、ネットワークバッファ（送信バッファ）を用意する。送信側におけるＴＣＰ／ＩＰパケットの送信処理において、ソケットＡＰＩ send()によって指定された送信データ（ユーザデータ）が送信バッファに転送され、ＭＴＵ（最大伝送単位）でチャンク化される。そして、チャンク化されたデータと擬似ヘッダのチェックサムが計算され、ＴＣＰヘッダとＩＰヘッダが追加されたＴＣＰ／ＩＰパケットが生成される。伝送経路がイーサネット（登録商標）の場合、これらヘッダに加えて、イーサネットヘッダが付加されたイーサネットフレームが生成され、送信される。ＭＴＵはＭａｘｉｍｕｍＴｒａｎｓｍｉｓｓｉｏｎＵｎｉｔの略である。

また、ＴＣＰ／ＩＰのプロトコル処理では、送信側のパケット送信の度に受信側がＡＣＫ（Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を送信することによる通信速度の低下を回避するために、所定のウィンドウサイズを利用するウィンドウ制御が行われる。ＴＣＰ／ＩＰのウィンドウ制御では、受信側（図１の通信相手装置１１３）は、受信バッファの残りサイズをウィンドウサイズに設定したＡＣＫを送信し、送信側は、ウィンドウサイズになるまでＡＣＫを待つことなく送信データを送信することができる。更に、ＴＣＰ／ＩＰのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側はパケットを受信する度にＡＣＫを送信し、送信側は最初のＡＣＫを受信するとウィンドウをスライドさせて、ＡＣＫを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。

通信装置１０は、ＲＡＭ１０１、ＣＰＵ１０２、ＲＯＭ１０３、記録媒体１０４および通信部１０５を有する。ＲＡＭはＲａｎｄｏｍＡｃｃｅｓｓＭｅｍｏｒｙの略である。ＲＯＭはＲｅａｄＯｎｌｙＭｅｍｏｒｙの略である。通信装置１０は、例えば、通信機能を備えるパーソナルコンピュータ、タブレット端末、スマートフォン、カメラ、プリンタ、プロジェクタなどである。
ＲＡＭ１０１は、各種データを保存したり、ワークメモリ（ワークエリア）として使用される。ＲＡＭ１０１は送受信データを格納して管理するためのメモリ領域１０１ａを有する。
ＣＰＵ１０２は、ＲＡＭ１０１をワークメモリとして、ＲＯＭ１０３や記録媒体１０４に格納された各種プログラムを実行する。
ＲＯＭ１０３は、ＣＰＵ１０２により実行される各種プログラム等を記憶する。
記録媒体１０４は、ハードディスクなどのプログラム格納部である。

通信部１０５は、ＭＡＣ（ＭｅｄｉａＡｃｃｅｓｓＣｏｎｔｒｏｌ）モジュール１０９とＰＨＹ（ＰｈｙｓｉｃａｌＬａｙｅｒ）モジュール１１０を有し、イーサネット（商標登録）などのネットワーク１１２を介して通信相手装置１１３との通信を行う。通信装置１０のデータの送受信は、ＣＰＵ１０２によりネットワークドライバが実行され、これに応じてＭＡＣモジュール１０９が制御されることにより行われる。なお、本実施形態では、通信部１０５は、イーサネット（登録商標）を介した通信を行うものとするが、イーサネットに替えて、無線ＬＡＮ（Ｗｉ−Ｆｉ）などのＩＰ通信可能な媒体を介して通信を行うことも可能である。ＬＡＮはＬｏｃａｌＡｒｅａＮｅｔｗｏｒｋの略である。

本実施形態の通信装置１０は更に、バッファ管理部１１４、データ転送部１１５、フレーム生成部１１６、パケット生成部１１７、チェックサム計算部１１８およびタイマ管理部１１９を有する。
バッファ管理部１１４は、ヘッダ又はパケットを格納するバッファと関連付けた管理情報の取得を行う。
データ転送部１１５は、例えばＤＭＡ（ＤｉｒｅｃｔＭｅｍｏｒｙＡｃｃｅｓｓ）を行うＤＭＡコントローラにより構成され、ＲＡＭ１０１に記憶されているデータを、ＤＭＡでフレーム生成部１１６やパケット生成部１１７に転送する。なお、データ転送部１１５は、データを転送する際にＣＰＵ１０２により制御されてもよい（ＤＭＡ転送でなくてもよい）。

フレーム生成部１１６は、送信する送信データサイズを決定し、決定したサイズの送信データと、送信データに対するヘッダ情報を生成するためのヘッダ情報生成処理を行う。
パケット生成部１１７は、フレーム生成部１１６により生成された送信データとヘッダ情報に基づいて、送信データのセグメント化およびヘッダの生成を行い、当該セグメントとヘッダから送信パケットを生成する。
チェックサム計算部１１８は、ＲＡＭ１０１に記憶されているデータに対してチェックサム計算を行う。
タイマ管理部１１９は、パケット送信に関して必要な所定時間を管理する。
なお、以下に説明するパケットは、ＩＰ通信上で送受信されるデータの単位である。パケットの組み立て方法については、本実施形態の本質ではないので、説明を省略する。

図２は、本実施形態における通信装置１０の機能構成例を示すブロック図である。アプリケーション２０１は、ユーザアプリケーションを指す。アプリケーション２０１により、任意のサイズの、送信対象のアプリケーションデータ（送信データ）がプロトコルスタック２０２に入力される。プロトコルスタック２０２は、ネットワークバッファ管理部２０３、セグメント処理部２０４、通信プロトコル処理部２０５、コネクション管理部２０６、ＴＣＰウィンドウ制御部２０７および輻輳制御部２０８から構成される。

プロトコルスタック２０２は、アプリケーション２０１から入力された送信データ（ＲＡＭ１０１のメモリ領域１０１ａに格納されている送信バッファ）を、ネットワークバッファ管理部２０３により管理する。
ネットワークバッファ管理部２０３は、図１のバッファ管理部１１４に対応している。ネットワークバッファ管理部２０３は、図１のＲＡＭ１０１のメモリ領域１０１ａに格納されている送信バッファにヘッダ又はパケットを格納する。また、ネットワークバッファ管理部２０３は、メモリ領域１０１ａに格納している送信データのサイズを管理する。
コネクション管理部２０６は、通信装置１０の通信コネクションを管理する。例えば、コネクション管理部２０６は、アプリケーション２０１に対する通信コネクションにおけるＭＳＳ等のコネクション情報を管理する。
ＴＣＰウィンドウ制御部２０７は、通信インタフェース制御部２０９を介して受信した確認応答から、ＴＣＰコネクションの送信ウィンドウサイズを取得し、管理する。
輻輳制御部２０８は、ＴＣＰコネクションにおける輻輳制御を管理する。例えば、輻輳制御部２０８は、アプリケーション２０１に対する通信コネクションにおける輻輳ウィンドウ（輻輳ウィンドウサイズ）を管理する。

セグメント処理部２０４は、ネットワークバッファ管理部２０３により管理される。セグメント処理部２０４は、メモリ領域１０１ａに格納されている送信バッファの送信データのサイズ、コネクション管理部２０６で管理されているＭＳＳ、ＴＣＰウィンドウ制御部２０７で管理されている送信ウィンドウサイズ、輻輳制御部２０８で管理されている輻輳ウィンドウサイズ等に基づいて、送信データサイズを決定する。
通信プロトコル処理部２０５は、ＴＣＰセグメントのＴＣＰヘッダやＵＤＰヘッダやＩＰヘッダの生成と、それに伴うチェックサム計算等の処理を行い、送信パケットを生成する。

パケット生成処理部３００は、パケット生成完了通知選択部４０１、データ転送部４０２、イーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３、パケット生成部４０４から構成される。パケット生成処理部３００は、オフロード処理部（ハードウェア）である。
パケット生成完了通知選択部４０１は、データ転送部４０２とイーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３とパケット生成部４０４によるパケット化処理の完了通知を、割り込みで行うかポーリングで行うかの選択をする。
データ転送部４０２は図１のデータ転送部１１５に対応し、データのチャンク機能、チェックサム計算機能、転送機能を持つ。チャンク機能は、送信データをデータ転送する際、所定の単位（例えばＭＳＳ単位）にチャンク化する。チェックサム計算機能は図１のチェックサム計算部１１８に対応する。チェックサム計算機能は、所定の単位にチャンク化した各データに対するチェックサム計算を行う。

イーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３は、所定のヘッダ情報に基づいて、ネットワークバッファ管理部２０３が管理しているメモリ領域１０１ａのバッファを用いて、ＴＣＰ／ＩＰヘッダ、ＵＤＰ／ＩＰヘッダ、イーサネットヘッダを生成する。
パケット生成部４０４は、データ転送部４０２とイーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３から出力されたデータを用いて、パケット化処理を行う。

本実施形態では、セグメント処理部２０４により決定された送信データサイズに応じて、通信プロトコル処理部２０５又はパケット生成処理部３００が、ネットワークバッファ管理部２０３が管理するバッファを用いて送信パケットを生成する。送信パケットの生成手法については、図３を用いて後述する。パケット生成処理部３００による処理は、ハードウェアオフロード処理である。

通信プロトコル処理部２０５又はパケット生成処理部３００により生成された送信パケットは、通信インタフェース制御部２０９に入力される。通信インタフェース制御部２０９は、プロトコルスタック２０２と通信インタフェース２１０との間でデータや情報のやり取りを行う。通信インタフェース２１０は、図１のＭＡＣモジュール１０９、ＰＨＹモジュール１１０に対応し、ネットワーク１１２と通信を行う。送信パケットの送信は、タイマ管理部１１９により一定時間以上経過したことが通知された場合に、行われてもよい。

次に、図３を参照して、本実施形態の通信装置１０により行われるデータ送信処理を説明する。図３のフローチャートでは、ソケットＡＰＩ send()によるデータ送信処理を説明する。なお、sendto()、sendmsg()、sendmmsg()によるデータ送信処理の場合も、図３と同様なフローチャートを用いることができる。
本実施形態では、ウィンドウサイズを使用するプロトコルのデータ送信処理において、パケット生成処理の完了待ちに割り込み又はポーリングを選択し、パケット送信を行う。ＳはＳｔｅｐの略である。

まず、Ｓ１０１において、ソケットＡＰＩの呼び出しを行う。より詳しくは、ＣＰＵ１０２により、ＲＯＭ１０３に格納されている所定のプログラムが実行されることに応じて、アプリケーション２０１は、send()を呼び出す。
send()が呼び出されると、データ転送部１１５は、Ｓ１０２で、不図示のユーザバッファのデータ転送先であるＲＡＭ１０１内の送信バッファへ送信データを転送しチャンク化を行う。送信データは送信バッファに格納される。ゼロコピーでsend()が呼び出された場合は、データ転送部１１５は、ユーザバッファの格納場所の情報を送信バッファへ転送する。

Ｓ１０３において、セグメント処理部２０４は、送信バッファに格納されている送信データのサイズが、ＴＣＰウィンドウ制御部２０７により管理されている送信ウィンドウサイズを超えるかどうかを判定する。Ｓ１０３の判定結果がＮｏの場合、処理はＳ１０４に進む。Ｓ１０３の判定結果がＹｅｓの場合、処理はＳ１０５に進む。
Ｓ１０４において、セグメント処理部２０４は、送信バッファに格納されている送信データのサイズを、送信データサイズとして決定する。
Ｓ１０５において、セグメント処理部２０４は、送信ウィンドウサイズを送信データサイズとして決定する。

Ｓ１０６において、通信プロトコル処理部２０５は、Ｓ１０４又はＳ１０５で決定した送信データサイズが、コネクション管理部２０６で管理されているＭＳＳを超えるかどうか判定する。決定した送信データサイズがＭＳＳ以下の場合は（Ｓ１０６：Ｎｏ）、処理はＳ１０７に進む。
Ｓ１０７において、通信プロトコル処理部２０５は、パケット生成部１１７を制御してチェックサムを計算してＴＣＰ／ＩＰヘッダを生成し、ＴＣＰ／ＩＰヘッダを用いて送信データをパケット化し、ＴＣＰ／ＩＰパケットを生成する。通信プロトコル処理部２０５は、更に、イーサネットヘッダを生成し、当該イーサネットヘッダを用いて、ＴＣＰ／ＩＰパケットをイーサネットフレーム化し、Ｓ１１４に進む。

一方、決定した送信データサイズがＭＳＳを超える場合は（Ｓ１０６：Ｙｅｓ）、処理はＳ１０８へ進む。Ｓ１０８において、フレーム生成部１１６は、ＴＣＰ／ＩＰヘッダとイーサネットヘッダを生成するための情報としてヘッダ情報を生成し、Ｓ１０９へ進む。
Ｓ１０９において、パケット生成完了通知選択部４０１は、パケット生成が所定のパケット数以下か、又はヘッダ生成のみかを判定する。send()が呼び出された際に送信データがＲＡＭ１０１のメモリ領域１０１ａ内の送信バッファに転送された場合には、パケット生成が行われる。ゼロコピーでsend()が呼び出された際にユーザバッファの格納場所の情報を転送した場合には、ヘッダ生成になる。所定のパケット数には、通信インタフェース制御部２０９が一度に送信できる最大数(イーサネットコントローラのＦＩＦＯのサイズ、又は無線ＬＡＮモジュールの内部バッファサイズ)が設定される。ＦＩＦＯはＦｉｒｓｔＩｎ，ＦｉｒｓｔＯｕｔの略である。

Ｓ１０９において、生成されるパケットの数が所定数を超えた場合(Ｓ１０９：Ｎｏ)、又はヘッダ生成ではない場合(Ｓ１０９：Ｎｏ)、Ｓ１１１に進む。
Ｓ１１１において、パケット生成完了通知選択部４０１は、処理完了待ちに割り込みを選択し、処理はＳ１１２に進む。
Ｓ１０９において、生成されるパケットの数が所定数以下の場合(Ｓ１０９：Ｙｅｓ)、又はヘッダ生成の場合(Ｓ１０９：Ｙｅｓ)、Ｓ１１０に進む。
Ｓ１１０において、パケット生成完了通知選択部４０１は、処理完了待ちにポーリングを選択し、Ｓ１１２に進む。
このように、Ｓ１０９〜Ｓ１１１では、パケット生成処理部３００の処理内容に基づいて、処理完了待ちをポーリングで行うか割り込みで行うかを選択する。

Ｓ１１２は、パケット生成部１１７に対応するパケット生成処理部３００が行う処理である。Ｓ１１２において、データ転送部４０２は、送信データがチャンク化されていない場合にはチャンク化とチェックサム計算を行い、チャンク化されている場合にはチェックサム計算を行う。また、Ｓ１１２において、イーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３は、Ｓ１０８で生成されたヘッダ情報を使用し、送信データがＭＳＳ単位にチャンク化されて得られる各セグメントに対してＴＣＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。send()が呼び出された際に送信データがＲＡＭ１０１内の送信バッファに転送された場合には、パケット生成によりイーサネットフレーム化される。ゼロコピーでsend()が呼び出されている場合には、生成されたＴＣＰ／ＩＰヘッダとイーサネットヘッダとユーザバッファの格納場所の情報とを関連付けし、イーサネットフレーム化する。

Ｓ１１３において、プロトコルスタック２０２は、Ｓ１１２の処理が完了しているかを判定する。つまり、Ｓ１１３において、Ｓ１１２の処理の処理完了待ちを割り込み又はポーリングで行う（ＣＰＵ１０２は、オフロードによるパケット処理の完了通知を、割り込み又はポーリングで待つ）。Ｓ１１２の処理が完了していない場合（Ｓ１１３：Ｎｏ）、Ｓ１１３を繰り返す。Ｓ１１２の処理が完了した場合（Ｓ１１３：Ｙｅｓ）、Ｓ１１４に進む。
Ｓ１１４において、通信プロトコル処理部２０５は、イーサネットフレームを通信インタフェース制御部２０９に送信し、Ｓ１１５に進む。
Ｓ１１５において、送信すべき全てのパケットについてパケット生成処理が完了しているかどうかを判定する。パケット生成処理がすべて完了していない場合は(Ｓ１１５：Ｙｅｓ)、Ｓ１１３に戻り処理を繰り返す。パケット生成処理がすべて完了した場合は(Ｓ１１５：Ｎｏ)、データ送信処理を終了する。

このように、各送信データとＴＣＰ／ＩＰヘッダ生成とイーサネットフレーム化を実施するパケット生成処理部３００の処理を処理データサイズに応じて（Ｓ１０９〜Ｓ１１２の処理）、処理完了待ちに割り込みか、ポーリングかを選択することができる。つまり、一度に生成するパケット数が少ない場合（またはヘッダ生成の場合）、パケット生成オフロードの処理完了が速いので、本実施形態では、ポーリングによる処理完了通知を使用する（Ｓ１０９Ｙｅｓで、Ｓ１１０）。一方、一度に生成するパケット数が多い場合、他のタスクと並行して処理をさせるためにハード割り込みによる処理完了通知を使用する（Ｓ１０９Ｎｏで、Ｓ１１１）。このような完了待ち選択により、通信装置１０の処理効率を上げることができる。

なお、パケット生成処理部３００のハードウェアによる処理をソフトウェアで実行した場合においても、本実施形態を適用できる。
本実施形態では、通信インタフェース２１０が一つであったが、通信インタフェースが複数ある場合にも本実施形態を適用することができる。
上記した実施形態では、ＴＣＰ／ＩＰプロトコルを使用したが、ＵＤＰプロトコル等の他のプロトコルを使用することも可能である。

Ｓ１０９で用いる所定のパケット数は、無線ＬＡＮモジュール、無線ＬＡＮの規格に応じて変更してよい。
Ｓ１０９の「所定のパケット数以下か」は「所定のデータサイズ以下か」にしてもよい。１パケット毎のデータサイズが小さい場合もパケット生成オフロードの処理完了が速いので、ポーリングによる処理完了通知を使用する。
Ｓ１０９の「所定のパケット数以下か」は「送信先の通信インタフェースが有線ＬＡＮ側か」、又は「送信先の通信インタフェースが無線ＬＡＮ側か」にしてもよい。通信インタフェースによっては割り込み通知によるオーバーヘッドを軽減するため、ポーリングによる処理完了通知を使用する。
本実施形態によれば、ハードウェアオフロードを使用した場合に処理時間に応じて割り込み通知又はポーリングを選択できるため、送信処理の効率が改善される。

［実施形態２］
以下、図１、図２および図４を用いて、本発明の実施形態２の通信装置による通信処理を説明する。なお、実施形態２において、実施形態１と同様の構成および機能については、同一符号を付して、その詳細な説明は省略する。
実施形態２では通信プロトコルとしてＵＤＰを使用する。通信プロトコル処理部２０５は、ＵＤＰ／ＩＰヘッダおよびＵＤＰ／ＩＰパケットを生成する。ＵＤＰはＵｓｅｒＤａｔａｇｒａｍＰｒｏｔｏｃｏｌの略である。ＵＤＰは、ＴＣＰ／ＩＰと異なり、ハンドシェイクを省いたコネクションレスのプロトコルである。ＵＤＰのデータ転送は、送受信されるデータの順序性の保障なく、送信先からの確認応答がないため信頼性を保障していない。しかし、通信の処理にかかるコストが少ないため、途中でデータが抜け落ちても問題が少ないストリーミング、及び通信処理のオーバーヘッドを軽減したいリアルタイムシステム通信でよく使われている。

図４は、実施形態２におけるデータ送信処理を説明するフローチャートである。本フローチャートでは、ソケットＡＰＩによる複数データのデータ送信処理を想定している（例えば、sendmmmsg()によるデータ送信）。
実施形態２では、複数の送信データを一度にソケットＡＰＩで指定するデータ送信処理において、パケット生成処理の完了待ちに割り込み又はポーリングを選択し、パケット送信を行う。

まず、Ｓ２０１において、ＣＰＵ１０２により、ＲＯＭ１０３に格納されている所定のプログラムが実行されることに応じて、アプリケーション２０１は、ソケットＡＰＩを呼び出す。
ソケットＡＰＩが呼び出されると、データ転送部１１５は、Ｓ２０２で、不図示のユーザバッファのデータ転送先であるＲＡＭ１０１内の送信バッファへ送信データを転送しチャンク化を行う。送信データは送信バッファに格納される。ゼロコピーでソケットＡＰＩが呼び出された場合は、データ転送部１１５は、ユーザバッファの格納場所の情報を送信バッファへ転送する。

Ｓ２０３において、ソケットＡＰＩにより一度に複数のデータを送信ソケットに指定したかどうかを判定する。ソケットＡＰＩに一度に１つのデータを指定した場には（Ｓ２０３：Ｎｏ）、処理はＳ２０４に進む。
Ｓ２０４において、通信プロトコル処理部２０５は、パケット生成部１１７を制御してチェックサムを計算してＵＤＰ／ＩＰヘッダを生成し、ＵＤＰ／ＩＰヘッダを用いて送信データをパケット化し、ＵＤＰ／ＩＰパケットを生成する。通信プロトコル処理部２０５は、更に、イーサネットヘッダを生成し、当該イーサネットヘッダを用いて、ＵＤＰ／ＩＰパケットをイーサネットフレーム化し、Ｓ２１１に進む。

ソケットＡＰＩにより一度に複数のデータを指定した場合（Ｓ２０３：Ｙｅｓ）、処理はＳ２０５へ進む。
Ｓ２０５において、フレーム生成部１１６は、ＵＤＰ／ＩＰヘッダとイーサネットヘッダを生成するための情報としてヘッダ情報を生成し、Ｓ２０６へ進む。
Ｓ２０６において、パケット生成完了通知選択部４０２は、パケット生成が所定のパケット数以下か、又はヘッダ生成のみかを判定する。ソケットＡＰＩが呼び出された際に送信データがＲＡＭ１０１内の送信バッファに転送された場合にはパケット生成が行われる。ゼロコピーでソケットＡＰＩが呼び出された際にユーザバッファの格納場所の情報を転送した場合には、ヘッダ生成になる。所定のパケット数には、通信インタフェース制御部２０９が一度に送信できる最大数(イーサネットコントローラのＦＩＦＯのサイズ、又は無線ＬＡＮモジュールの内部バッファサイズ)が設定される。

Ｓ２０６において、パケット生成が所定のパケット数を超えた場合(Ｓ２０６：Ｎｏ)、又はヘッダ生成ではない場合(Ｓ２０６：Ｎｏ)、処理はＳ２０８に進む。
Ｓ２０８において、パケット生成完了通知選択部４０１は、処理完了待ちに割り込みを選択し、処理はＳ２０９に進む。
Ｓ２０６において、パケット生成が所定のパケット数以下の場合(Ｓ２０６：Ｙｅｓ)、又はヘッダ生成の場合(Ｓ２０６：Ｙｅｓ)、処理はＳ２０７に進む。
Ｓ２０７において、パケット生成完了通知選択部４０１は、処理完了待ちにポーリングを選択し、処理はＳ２０９に進む。

Ｓ２０９は、パケット生成部１１７に対応するパケット生成処理部３００による処理である。Ｓ２０９において、データ転送部４０２は、送信データがチャンク化されていない場合にはチャンク化とチェックサム計算を行い、チャンク化されている場合にはチェックサム計算を行う。また、Ｓ２０９において、イーサネット／ＴＣＰ／ＵＤＰ／ＩＰヘッダ生成部４０３は、Ｓ２０５で生成されたヘッダ情報を使用し、送信データがＭＴＵ単位にチャンク化されて得られる各送信データに対してＵＤＰ／ＩＰヘッダとイーサネットヘッダを（自動）生成する。ソケットＡＰＩが呼び出された際に送信データがＲＡＭ１０１内の送信バッファに転送された場合には、パケット生成によりイーサネットフレーム化される。ゼロコピーでソケットＡＰＩが呼び出されている場合には、生成されたＵＤＰ／ＩＰヘッダとイーサネットヘッダとユーザバッファの格納場所の情報とを関連付けし、イーサネットフレーム化する。

Ｓ２１０において、プロトコルスタック２０２は、Ｓ２０９の処理が完了しているかを判定する。つまり、Ｓ２１０において、Ｓ２０９の処理の処理完了待ちを割り込み（Ｓ２０８）又はポーリング（Ｓ２０７）で行う。Ｓ２０９の処理が完了していない場合（Ｓ２１０：Ｎｏ）、Ｓ２１０を繰り返す。Ｓ２０９の処理が完了した場合（Ｓ２１０：Ｙｅｓ）、Ｓ２１１に進む。
Ｓ２１１において、通信プロトコル処理部２０５は、イーサネットフレームを通信インタフェース制御部２０９に送信し、Ｓ２１２に進む。
Ｓ２１２において、送信すべき全てのパケットについてパケット生成処理が完了しているかどうかを判定する。パケット生成処理がすべて完了していない場合は(Ｓ２１２：Ｙｅｓ)、Ｓ２１０へ戻り処理を繰り返す。パケット生成処理がすべて完了した場合は(Ｓ２１２：Ｎｏ)、データ送信処理を終了する。

このように、各送信データとＵＤＰ／ＩＰヘッダ生成とイーサネットフレーム化を実施するパケット生成処理部３００の処理を処理データサイズに応じて（Ｓ２０６〜Ｓ２１０の処理）、処理完了待ちに割り込みか、ポーリングかを選択することができる。なお、パケット生成処理部３００のハードウェアによる処理をソフトウェアで実行した場合においても、本実施形態を適用可能である。また、通信インタフェース２１０が一つ存在する例を挙げたが、通信インタフェースが複数の場合にも本発明を適用することができる。また、本実施形態では、ＵＤＰ／ＩＰプロトコルを例にして説明したが、ＴＣＰプロトコル等の他のプロトコルを適用することも可能である。なお、Ｓ２０６で用いる所定のパケット数は、無線ＬＡＮモジュール、無線ＬＡＮの規格に応じて変更してよい。
Ｓ２０６の「所定のパケット数以下か」は「送信先の通信インタフェースが有線ＬＡＮ側か」、又は「送信先の通信インタフェースが無線ＬＡＮ側か」にしてもよい。通信インタフェースによっては割り込み通知によるオーバーヘッドを軽減するため、ポーリングによる処理完了通知を使用する。

本発明は、上述の実施形態の１以上の機能を実現するプログラムを、ネットワーク又は記憶媒体を介してシステム又は装置に供給し、そのシステム又は装置のコンピュータにおける１つ以上のプロセッサがプログラムを読出し実行する処理でも実現可能である。また、１以上の機能を実現する回路（例えば、ＡＳＩＣ）によっても実現可能である。

図１および図２に示した構成は一例であり、複数の機能部が１つの機能部に統合されてもよいし、いずれかの機能部が複数の機能部に分けられてもよい。また、図１および図２に示した機能部（例えば、バッファ管理部１１４、データ転送部１１５、フレーム生成部１１６、パケット生成部１１７）に含まれる一部又は全部の機能がハードウェア化されていてもよい。ハードウェア化は、例えばＡＳＩＣ（ＡｐｐｌｉｃａｔｉｏｎＳｐｅｃｉｆｉｃＩｎｔｅｇｒａｔｅｄＣｉｒｃｕｉｔ）により実現される。

１０２：ＣＰＵ、１０５：データ転送部、１０６：フレーム生成部、１０７：パケット生成部、１０９：ＭＡＣモジュール、１１３：通信相手装置、２０２：プロトコルスタック、３００：パケット生成処理部、４０１：パケット生成完了通知選択部、４０２：データ転送部、４０４：パケット生成部

Claims

送信データを通信相手装置に送信する通信装置であって、
前記送信データのパケット又はヘッダを生成する生成手段と、
前記生成手段の処理内容に基づいて、前記生成手段の処理完了待ちをポーリングで行うか割り込みで行うかを選択する選択手段と、
前記生成手段により生成されたパケット又は前記生成手段により生成されたヘッダに対応するパケットを送信する送信手段と、
を備えることを特徴とする通信装置。
前記選択手段は、前記生成手段が処理するデータのサイズに基づいて、前記ポーリング又は前記割り込みを選択することを特徴とする請求項１に記載の通信装置。
前記生成手段は、前記送信データのゼロコピーが設定されている場合には、前記ヘッダを生成し、前記送信データのゼロコピーが設定されていない場合には、前記パケットを生成することを特徴とする請求項１又は２に記載の通信装置。
前記選択手段は、前記生成手段が前記ヘッダを生成する場合、前記ポーリングを選択することを特徴とする請求項１から３のいずれか１項に記載の通信装置。
前記選択手段は、前記生成手段が生成する前記パケットの数が所定数以下の場合、前記ポーリングを選択し、前記生成手段が生成する前記パケットの数が前記所定数を超える場合、前記割り込みを選択することを特徴とする請求項１から３のいずれか１項に記載の通信装置。
前記通信装置は中央演算処理装置を備え、前記生成手段は、前記中央演算処理装置とは別のハードウェアを含むことを特徴とする請求項１から５のいずれか１項に記載の通信装置。
前記送信データのサイズが所定のサイズを超えない場合、前記生成手段は前記パケットの生成を行わず、前記中央演算処理装置が前記パケットの生成を行い、前記送信手段は、前記中央演算処理装置が生成したパケットを送信することを特徴とする請求項６に記載の通信装置。
前記送信データを１つだけ送信ソケットに指定した場合、前記生成手段は前記パケットの生成を行わず、前記中央演算処理装置が前記パケットの生成を行い、前記送信手段は、前記中央演算処理装置が生成したパケットを送信することを特徴とする請求項６に記載の通信装置。
送信データを通信相手装置に送信する通信方法であって、
前記送信データのパケット又はヘッダを生成する生成ステップと、
前記生成ステップの処理内容に基づいて、前記生成ステップの処理完了待ちをポーリングで行うか割り込みで行うかを選択する選択ステップと、
前記生成ステップにより生成されたパケット又は前記生成ステップにより生成されたヘッダに対応するパケットを送信する送信ステップと、
を有することを特徴とする通信方法。
コンピュータを請求項１から８のいずれか１項に記載の通信装置として動作させるためのプログラム。