JP2023031710A - 通信装置及びその制御方法、並びにプログラム - Google Patents

Abstract

【課題】ＯＳカーネルに対する変更を行うことなく、ＭＡＣヘッダのキャッシュ情報の使用可否によらず、送信パケットを生成するための通信プロトコル処理の一部をオフロード処理により実現する。【解決手段】動的ロードソフトウェア２１１は、ＯＳカーネル２０１による通信プロトコル処理をフックすると、近傍エントリの状態を判定する。動的ロードソフトウェア２１１は、判定された近傍エントリの状態に基づいて、ヘッダ生成処理を制御する。動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持している場合、オフロード処理部１０６がＭＡＣ層より上位層のヘッダ及びＭＡＣヘッダを生成するよう制御する。一方、動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持していない場合、オフロード処理部１０６が上位層のヘッダを生成し、ＯＳカーネル２０１がＭＡＣヘッダを生成するよう制御する。【選択図】図２

Description

本発明は、データ通信を行うための通信装置及びその制御方法、並びにプログラムに関するものである。

通信装置において、ＴＣＰ／ＩＰ等の通信プロトコルによる処理では、バッファに格納された送信対象のユーザデータ（送信データ）のパケット化が行われる。例えば、送信データは、ＴＣＰにおけるＭＳＳ（最大セグメントサイズ）単位の分割データ（セグメントデータ）に分割される。その後、分割データ及び疑似ヘッダのチェックサムが計算されるとともに、分割データを含み、かつ、ＴＣＰヘッダ及びＩＰヘッダが付加されたＩＰパケットが生成される。更に、生成されたＩＰパケットにＭＡＣヘッダを付加することで、イーサネット(登録商標)フレーム等のＭＡＣフレームが生成され、生成されたＭＡＣフレームが伝送路へ送信される。

近年、ＣＰＵの処理負荷の軽減及び高速送信のために、上述のセグメントデータへの分割と、各通信プロトコルのヘッダの生成とを、ネットワークＩ／Ｆ（インタフェース）等のハードウェアを用いて行うオフロード技術が用いられることがある。例えば、特許文献１に記載のように、ＣＰＵに代えてネットワークＩ／ＦがＴＣＰのセグメント化処理の一部又は全部を行うＴＳＯ（TCP Segmentation Offload）が知られている。また、特許文献１には、通信デバイスがＴＳＯ機能を備えているか否かによらず、ＣＰＵとは異なるハードウェアを用いて、セグメントデータへの分割とＴＣＰ／ＩＰ／イーサネットヘッダの生成とを行う技術が記載されている。

特開２０１８－１９６０５３号公報

上述の従来技術では、送信データのパケット化（フレーム化）をオフロード処理により実現することには、ＯＳカーネルのプロトコルスタックに対する変更（例えば、ＯＳのソースコードに対する変更）が伴いうる。これは特にＬｉｎｕｘ(登録商標)等のＯＳＳ（オープンソースソフトウェア）のＯＳカーネルでは、ＯＳの保守性及び品質の観点で望ましくない。また、ＭＡＣヘッダのキャッシュ情報（宛先ＩＰアドレスと宛先ＭＡＣアドレスとの対応情報）を使用できない場合、ハードウェアを用いたオフロード処理ではＭＡＣヘッダを生成することはできず、送信パケット（送信フレーム）を生成することができないことがありうる。

そこで、本発明は、ＯＳカーネルに対する変更を行うことなく、ＭＡＣヘッダのキャッシュ情報の使用可否によらず、送信パケットを生成するための通信プロトコル処理の一部をオフロード処理により実現するための技術を提供することを目的とする。

本発明の一態様に係る通信装置は、前記通信装置において動作するＯＳカーネルによる通信プロトコル処理を、前記ＯＳカーネルの代わりに実行する処理手段であって、送信対象の送信データをセグメントデータに分割する分割処理と、前記分割処理で分割された各セグメントデータに対してヘッダを生成して付与するヘッダ生成処理とを行う、前記処理手段と、前記ＯＳカーネルによる前記通信プロトコル処理をフックするフック手段と、前記フック手段によって前記通信プロトコル処理がフックされると、前記送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する判定手段と、前記判定手段によって判定された前記近傍エントリの状態に基づいて、前記ヘッダ生成処理を制御する制御手段と、を備え、前記制御手段は、前記近傍エントリが有効なキャッシュ情報を保持している場合、前記処理手段がＭＡＣ層より上位層のヘッダ及び前記ＭＡＣヘッダを生成するよう制御し、前記近傍エントリが有効なキャッシュ情報を保持していない場合、前記処理手段が前記上位層のヘッダを生成し、前記ＯＳカーネルが前記ＭＡＣヘッダを生成するよう制御することを特徴とする。

本発明によれば、ＯＳカーネルに対する変更を行うことなく、ＭＡＣヘッダのキャッシュ情報の使用可否によらず、送信パケットを生成するための通信プロトコル処理の一部をオフロード処理により実現できる。

通信装置のハードウェア構成例を示すブロック図 通信装置の機能構成例を示すブロック図 動的ロードソフトウェアによる処理の手順を示すフローチャート データ判定処理（Ｓ３０２）の手順を示すフローチャート オフロード処理部１０６による処理の手順を示すフローチャート データ送信処理（Ｓ３１１）の手順を示すフローチャート ＭＡＣヘッダのキャッシュ情報が有効である場合のセグメント分割及びヘッダ生成の例を示す図 ＭＡＣヘッダのキャッシュ情報が無効である場合のセグメント分割及びヘッダ生成の例を示す図

以下、添付図面を参照して実施形態を詳しく説明する。なお、以下の実施形態は特許請求の範囲に係る発明を限定するものではない。実施形態には複数の特徴が記載されているが、これらの複数の特徴の全てが発明に必須のものとは限らず、また、複数の特徴は任意に組み合わせられてもよい。更に、添付図面においては、同一又は同様の構成に同一の参照番号を付し、重複した説明は省略する。

＜通信装置のハードウェア構成＞
図１は、本発明の一実施形態に係る通信装置１００のハードウェア構成例を示すブロック図である。通信装置１００は、通信機能を備える装置であり、例えば、カメラ、プリンタ、スマートフォン、タブレット、ＰＣ（パーソナルコンピュータ）、又はプロジェクタ等の装置でありうる。

通信装置１００は、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、通信デバイス１０５、及びオフロード処理部（オフロード処理ハードウェア）１０６を有する。システムバス１０１は、ＣＰＵ１０２、ＲＯＭ１０３、ＲＡＭ１０４、通信デバイス１０５及びオフロード処理部１０６を互いに接続しており、接続されたデバイス間の各種データの転送経路となる。

ＣＰＵ１０２は、ＯＳ又はデバイスドライバを介してハードウェアデバイス１０３～１０６を統括的に制御することで、通信装置１００を制御する。ＲＯＭ１０３は、ＣＰＵ１０２によって実行されるＯＳ及びデバイスドライバ等の制御プログラムを格納している。ＲＡＭ１０４は、ＣＰＵ１０２の主メモリ及びワークエリア等として機能し、プログラムやデータを一時的に格納しうる。

通信デバイス１０５は、ＭＡＣ（Media Access Control）モジュール１０７及びＰＨＹ（Physical Layer）モジュール１０８を有し、ネットワーク１１１を介して通信相手装置との通信を行う。ネットワーク１１１は、例えば、イーサネット(登録商標)規格に準拠した通信（有線ＬＡＮ通信）のためのネットワークである。ネットワーク１１１を介したデータの送受信は、ＣＰＵ１０２によってネットワークドライバが実行され、当該ネットワークドライバに応じてＭＡＣモジュール１０７が制御されることにより行われる。

なお、通信デバイス１０５は、有線ＬＡＮ通信に代えて又は有線ＬＡＮ通信に加えて、無線ＬＡＮ（Ｗｉ－Ｆｉ(登録商標)）規格に準拠した通信（無線ＬＡＮ通信）を行う機能を有してもよい。通信デバイス１０５は、任意の有線又は無線通信規格に準拠して通信ＩＰ通信を行うことができるように構成されうる。

オフロード処理部１０６は、ＤＭＡＣ（ダイレクトメモリアクセスコントローラ（Direct Memory Access Controller））１０９及びプロトコル処理部（プロトコル処理ハードウェア）１１０を有するハードウェアユニットである。オフロード処理部１０６は、ＣＰＵ１０２からオフロードされた処理（例えば、セグメント分割処理及びヘッダ生成処理）を実行する。オフロード処理部１０６は、通信装置１００において動作するＯＳカーネル（図２のＯＳカーネル２０１）による通信プロトコル処理を、当該ＯＳカーネルの代わりに実行する。即ち、オフロード処理部１０６は、ＣＰＵ１０２からオフロードされた処理を実行する。具体的には、オフロード処理部１０６は、後述するように、送信対象の送信データをセグメントデータに分割する分割処理と、当該分割処理で分割された各セグメントデータに対してヘッダを生成して付与するヘッダ生成処理とを行う。

ＤＭＡＣ１０９は、ＲＡＭ１０４に格納されているデータのプロトコル処理部１１０への転送、及びプロトコル処理部１１０によって処理されたデータのＲＡＭ１０４への転送を行う。ＤＭＡＣ１０９によるデータ転送は、ＣＰＵ１０２により制御される。なお、図１には１つのＤＭＡＣ１０９のみが示されているが、オフロード処理部１０６に複数のＤＭＡＣ１０９が設けられてもよい。複数のＤＭＡＣには、例えば、ＲＡＭ１０４からデータを読み込むためのＤＭＡＣ、及びＲＡＭ１０４にデータを書き込むためのＤＭＡＣ等が含まれうる。

プロトコル処理部１１０は、ＴＣＰ／ＩＰ（Transmission Control Protocol／Internet Protocol）等の通信プロトコルによる処理（通信プロトコル処理）を実行する機能を有するハードウェアである。プロトコル処理部１１０は、例えば、ＴＣＰ又はＵＤＰのチェックサム計算、及びヘッダ生成処理等を行いうる。

なお、図１に示される構成例は一例にすぎず、通信装置１００は図１に示されていない構成要素を備えてもよい。例えば、通信装置１００はタイマ管理部を備えてもよい。タイマ管理部は、所定時間が経過したかを管理しうる。また、通信装置１００は、複数のＣＰＵを備えてもよいし、ＣＰＵ１０２が１つ又は複数のプロセッサで構成されてもよい。通信装置１００がカメラである場合、撮像部及び表示部を備えてもよい。

＜通信装置の機能構成＞
図２は、本実施形態における通信装置１００の機能構成例を示すブロック図である。通信装置１００は、本実施形態に関連する機能構成として、アプリケーション２００と、ＯＳカーネル２０１と、動的ロードソフトウェア２１１と、オフロード処理部１０６に設けられる第二セグメント分割部２１８及び第二ヘッダ生成部２１９とを有する。なお、本実施形態では、ＣＰＵ１０２が実行するＯＳカーネル２０１としてＬｉｎｕｘを想定しているが、Ｌｉｎｕｘに限定されず、Ｌｉｎｕｘ以外のＯＳカーネルが使用されてもよい。

（アプリケーション２００）
アプリケーション２００は、ユーザ空間に存在するユーザアプリケーションである。本実施形態では、アプリケーション２００は、ＴＣＰ／ＩＰｖ４通信を行うアプリケーションであるが、ＵＤＰ通信を行うアプリケーションであってもよい。任意のサイズの、送信対象のアプリケーションデータ（送信データ）が、アプリケーション２００からＯＳカーネル２０１（プロトコルスタック２０２）へ入力される。

（ＯＳカーネル２０１）
ＯＳカーネル２０１は、プロトコルスタック２０２、近傍エントリ処理部２０９、及び転送処理部２１０を有する。プロトコルスタック２０２は、コネクション管理部２０３、第一バッファ管理部２０４、第一セグメント分割部２０５、第一ヘッダ生成部２０６、ウィンドウ制御部２０７及びＩＰ処理フック部２０８を有する。

コネクション管理部２０３は、通信装置１００の通信コネクションを管理する。例えば、コネクション管理部２０３は、アプリケーション２００に対する通信コネクションのＭＳＳ（最大セグメントサイズ（Maximum Segment Size））及びオフロード設定情報等のソケット情報、及びＡＲＰ（Address Resolution Protocol）テーブルのエントリとして保持される近傍エントリ等を管理する。近傍エントリは、ＭＡＣアドレスとＩＰアドレスとの対応関係を示す対応情報（セグメント分割により得られたセグメントデータに付与されるＭＡＣヘッダのキャッシュ情報）を含む。このように、近傍エントリは、送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する。

第一バッファ管理部２０４は、カーネル空間で使用される送信バッファを管理するための管理データを生成する。送信バッファは、ＲＡＭ１０４の記憶領域に確保され、第一バッファ管理部２０４によって生成される管理データを用いて管理される。第一バッファ管理部２０４は、送信バッファの管理データとして、例えば、ＯＳカーネルがＬｉｎｕｘである場合、struct sk_buffで定義される構造体を生成する。管理データは、カーネル空間のデータアドレス及びソケット情報への参照、通信デバイス情報への参照等を含む。

第一セグメント分割部２０５は、アプリケーション２００によって生成された送信データをＭＳＳ単位で分割し、得られたセグメントデータをカーネル空間の送信バッファへ格納（コピー）する。送信バッファに格納されるセグメントデータのデータサイズは、ウィンドウ制御部２０７において管理されているＴＣＰ送信ウィンドウサイズ及び輻輳ウィンドウサイズ等に基づいて決定される。また、第一セグメント分割部２０５は、ＴＣＰセッションにおいてチェックサム計算のオフロード設定が行われていない場合、送信バッファへセグメントデータを格納する際に、当該セグメントデータに対するチェックサム値の計算を行う。

第一ヘッダ生成部２０６は、ＴＣＰ又はＵＤＰのトランスポート層の処理、及びＩＰのネットワーク層の処理（具体的には、各プロトコルのヘッダ生成処理）を行う。ウィンドウ制御部２０７は、ＴＣＰ送信ウィンドウサイズ及び輻輳ウィンドウを管理する。ＩＰ処理フック部２０８は、通信プロトコル処理（ＩＰプロトコル処理）として、第一ヘッダ生成部２０６がＩＰヘッダについてのヘッダ生成処理を行っている途中で、当該ＩＰプロトコル処理をフックするコールバックを登録する機能を有する。例えば、Ｌｉｎｕｘでは、Ｎｅｔｆｉｌｔｅｒと呼ばれるフレームワークで提供されるＡＰＩ（Application Programming Interface）を使ってＩＰ処理フック部２０８による処理が実現される。

近傍エントリ処理部２０９は、管理データが示すＩＰヘッダに含まれる送信先ＩＰアドレスに対応する近傍エントリを参照することで、ＭＡＣヘッダのキャッシュ情報を取得する。近傍エントリ処理部２０９は、取得したキャッシュ情報を用いて、セグメントデータに付与する、ＭＡＣアドレスを含むＭＡＣヘッダを生成する。なお、近傍エントリは、例えば、Ｌｉｎｕｘにおいては、struct neighbour構造体を用いて管理される。近傍エントリ処理部２０９は、送信先ＩＰアドレスに対応する近傍エントリが存在しない場合、又は近傍エントリは存在するが有効ではない場合、アドレス解決処理を行うことでアドレス情報（ＩＰアドレスに対応するＭＡＣアドレス）を取得する。このアドレス解決処理は、ＩＰｖ４通信の場合にはＡＲＰ（Address Resolution Protocol）処理であり、ＩＰｖ６通信の場合にはNeighbor Discovery処理である。このように、本実施形態の近傍エントリ処理部２０９は、送信データの送信先ＩＰアドレスに対応するＭＡＣアドレスを、アドレス解決処理により取得し、取得したＭＡＣアドレスを含むＭＡＣヘッダを生成する生成手段の一例として機能する。

本実施形態において、近傍エントリが有効である有効状態とは、アドレス解決が成功した状態、アドレス解決成功後のアドレス情報の有効期限内の状態、及びアドレス情報が静的に設定されている状態（アドレス解決が不要な状態）を指す。一方、近傍エントリが無効である無効状態とは、上記以外の状態（例えば、アドレス未解決状態、アドレス情報の有効期限が切れた状態、及びアドレス解決中の状態を指す。近傍エントリが有効状態である場合、近傍エントリは、ＭＡＣヘッダ（ＭＡＣアドレス）の有効なキャッシュ情報を保持している。この場合、近傍エントリ処理部２０９は、このキャッシュ情報に基づいてＭＡＣヘッダを生成し、生成したＭＡＣヘッダを、管理データが管理する送信バッファに格納する。その後、送信バッファの管理データ（即ち、送信バッファに格納された、ＴＣＰ／ＩＰ／ＭＡＣヘッダが付与された送信データ）は、近傍エントリ処理部２０９から転送処理部２１０へ送られる。

転送処理部２１０は、入力された管理データ（即ち、送信バッファに格納された、ＴＣＰ／ＩＰ／ＭＡＣヘッダが付与された送信データ）を通信デバイス１０５へ転送する機能を有する。転送処理部２１０には、通信デバイス１０５のドライバも含まれる。なお、通信デバイス１０５のドライバは、ＯＳカーネル２０１に含まれていてもよいし、動的ロードソフトウェア２１１として実現されてもよい。実施形態の転送処理部２１０は、送信データを分割して得られた各セグメントデータにＭＡＣヘッダを付与して得られたＭＡＣフレームを、通信デバイス１０５へ転送する転送手段の一例として機能する。

（動的ロードソフトウェア２１１）
動的ロードソフトウェア２１１は、ＯＳカーネル２０１の起動後に動的にロードされるソフトウェアであり、ＯＳカーネル２０１とは独立して動作する。動的ロードソフトウェア２１１は、コールバック登録部２１２、処理判定部２１３、プロトコル処理返付部２１４、ソケット情報書換部２１５、第二バッファ管理部２１６及びデータリンク（ＤＬ）層入力部２１７を有する。なお、動的ロードソフトウェア２１１が実行する処理の手順については図３のフローチャートを用いて後述する。

コールバック登録部２１２は、ＩＰ処理フック部２０８が提供する機能を用いて、ＯＳカーネル２０１によるＩＰプロトコル処理（通信プロトコル処理）をフックするコールバックを登録する。つまり、本実施形態において、コールバック登録部２１２は、ＩＰプロトコル処理をフックする機能を有する。コールバック登録部２１２によるコールバックの登録は、動的ロードソフトウェア２１１がロードされたタイミングで実行される。

処理判定部２１３は、コールバック登録部２１２によって登録されたコールバック内で、ＩＰヘッダが生成された管理データの中身を解析し、当該管理データについて処理判定（管理データの処理方法の決定）を行う。処理判定部２１３は、例えば以下の判定（決定）を行いうる。
●管理データを、ＩＰプロトコル処理のフック元であるプロトコルスタック２０２の処理に戻すという判定。
●管理データのソケット情報を書き換えるという判定。
●管理データについてオフロード処理を行うという判定。
なお、処理判定部２１３による処理判定の詳細については図４のフローチャートを用いて後述する。

プロトコル処理返付部２１４は、処理判定部２１３により、管理データをプロトコルスタック２０２の処理に戻すと判定された場合に、当該管理データを、プロトコルスタック２０２に戻す。あるいは、プロトコル処理返付部２１４は、ソケット情報書換部２１５によるソケット情報の書き換えが行われた管理データを、プロトコルスタック２０２に戻す。

ソケット情報書換部２１５は、処理判定部２１３により、管理データのソケット情報を書き換えると判定された場合、当該管理データのソケット情報の書き換えを行う。書換対象のソケット情報は、例えば、ＭＳＳのキャッシュ値、及びチェックサム計算をオフロード（ハードウェアオフロード）するためのオフロード設定である。

ソケット情報内のＭＳＳのキャッシュ値を、実際のＭＳＳ値よりも大きい値に設定することで、第一セグメント分割部２０５による分割後のセグメントデータサイズを大きくすることが可能である。これにより、１つの管理データで管理されるセグメントデータのサイズが大きくなる。また、セグメントオフロードを行うように設定することで、セグメントデータサイズを大きくすることも可能である。セグメントオフロードを行うように設定する場合、最大セグメントサイズ及び最大セグメント数の設定も行う。また、チェックサム計算をオフロードするように設定することで、第一セグメント分割部２０５によるチェックサム計算を不要にすることが可能であり、プロトコルスタック２０２における処理負荷が軽減される。

ソケット情報の書き換えが行われた管理データは、プロトコル処理返付部２１４によってプロトコルスタック２０２に戻される。ソケット情報の書き換えが行われた通信コネクションについては、それ以降、例えば大きなサイズのセグメントデータについてチェックサム計算が行われていない管理データが、動的ロードソフトウェア２１１で処理される。

第二バッファ管理部２１６は、処理判定部２１３により、管理データ（第一の管理データ）についてオフロード処理を行うと判定された場合に、別の送信バッファを管理するための新たな管理データ（第二の管理データ）を確保（生成）する。なお、本実施形態においてオフロード処理の対象となる処理は、セグメント分割処理及びヘッダ生成処理である。確保される管理データの個数は、元の管理データ（第一の管理データ）が管理しているセグメントデータサイズを、実際のＴＣＰセッションのＭＳＳで除算することによって算出される。この除算において剰余が発生した場合には切り上げが行われうる。例えば、元の管理データが管理しているセグメントデータサイズが１５０００バイトであり、ＭＳＳが１４６０バイトである場合、１１個の送信バッファに対応する１１個の管理データが確保される。なお、管理データによって管理される送信バッファは、ＲＡＭ１０４に記憶領域に確保される。

また、第二バッファ管理部２１６は、元の管理データ（第一の管理データ）及び新たに確保した管理データ（第二の管理データ）を、オフロード処理のためにオフロード処理部１０６へ出力する。なお、第二の管理データは、第一の管理データ（ＯＳカーネル２０１からＩＰプロトコル処理がフックされた際の元の管理データ）とは異なるものである。

ＤＬ層入力部２１７は、オフロード処理部１０６によるオフロード処理（セグメント分割処理及びヘッダ生成処理）が行われた送信データに対応する管理データを受信し、ＩＰプロトコル処理のフック元であるＯＳカーネル２０１のＤＬ層へ送信する。より具体的には、ＤＬ層入力部２１７は、近傍エントリが有効状態である場合には、管理データを転送処理部２１０に送信し、近傍エントリが無効状態である場合には、管理データを近傍エントリ処理部２０９へ送信する。なお、ＤＬ層入力部２１７が実行する処理の手順については図６のフローチャートを用いて後述する。なお、ＤＬ層入力部２１７による処理は、上述のコールバック処理内で行われる。

（オフロード処理部１０６）
オフロード処理部１０６は、その機能構成として、第二セグメント分割部２１８及び第二ヘッダ生成部２１９を有する。

第二セグメント分割部２１８は、ＤＭＡＣ１０９を備えている。第二セグメント分割部２１８は、第一の管理データを用いて管理されるセグメントデータのアドレスを、データの読み出し元、第二の管理データを用いて管理されるセグメントデータ領域を、データの書き出し先として、セグメント分割処理を行う。

第二ヘッダ生成部２１９は、第二の管理データが示す、セグメント分割処理が行われた送信データに付与すべきＴＣＰヘッダ及びＩＰヘッダの生成を行う。ここで、第一の管理データが示す送信データには、ＩＰプロトコル処理により得られたＩＰヘッダを示すヘッダデータが含まれている。このため、第二ヘッダ生成部２１９は、このヘッダデータに基づいて、第二の管理データに対応する送信データに対するヘッダ生成処理を行う。また、第二ヘッダ生成部２１９は、近傍エントリの状態（有効状態又は無効状態）に応じて、ＭＡＣヘッダを生成する処理も行う。なお、オフロード処理部１０６（第二セグメント分割部２１８及び第二ヘッダ生成部２１９）が実行する処理の手順については図５のフローチャートを用いて後述する。

本実施形態では、第二セグメント分割部２１８と第二ヘッダ生成部２１９はオフロード処理部１０６で実現されるが、ソフトウェアにより実現されてもよい。また、図２に示される構成は一例であり、図２に示される複数の機能部が１つの機能部に統合されてもよいし、いずれかの機能部が複数の機能部に分けられてもよい。また、図２に示される機能部に含まれる一部又は全部の機能部が、ＡＳＩＣ（Application Specific Integrated Circuit）等のハードウェアにより実現されてもよい。

＜動的ロードソフトウェアの処理手順＞
図３は、本実施形態における動的ロードソフトウェア２１１によって実行される処理の手順を示すフローチャートである。動的ロードソフトウェア２１１は、ＩＰ処理フック部２０８によりプロトコルスタック２０２からフックされる通信プロトコル処理（ＩＰプロトコル処理）に関連する第一の管理データに対する処理方法を判定（決定）し、判定結果に基づいて処理を実行する。図３の各ステップの処理は、例えば、ＲＯＭ１０３に格納されているプログラムをＣＰＵ１０２が読み出して実行することによって実現される。

Ｓ３０１で、動的ロードソフトウェア２１１は、処理判定部２１３により、プロトコルスタック２０２から、ＯＳカーネル２０１による通信プロトコル処理（ＩＰプロトコル処理）をフックし、コールバック登録部２１２によって登録されたコールバック処理を開始する。次にＳ３０２で、動的ロードソフトウェア２１１は、通信プロトコル処理がフックされると、処理判定部２１３により、フックされた通信プロトコル処理に関連する第一の管理データについて判定処理を行う。当該判定処理は、図４を用いて後述する手順で実行される。後述するように、当該判定処理は、送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する処理を含む。

Ｓ３０３で、動的ロードソフトウェア２１１は、Ｓ３０２の判定処理により、第一の管理データについてオフロード処理（ハードウェアオフロード）を行うとの判定結果が得られたか否かを判定する。動的ロードソフトウェア２１１は、オフロード処理を行わないとの判定結果が得られた場合、処理をＳ３０４へ進め、オフロード処理を行うとの判定結果が得られた場合、処理をＳ３０７へ進める。

Ｓ３０４で、動的ロードソフトウェア２１１は、Ｓ３０２の判定処理により、第一の管理データのソケット情報を書き換えるとの判定結果が得られたか否かを判定する。動的ロードソフトウェア２１１は、ソケット情報を書き換えるとの判定結果が得られた場合、Ｓ３０５へ処理を進め、ソケット情報を書き換えないとの判定結果が得られた場合、Ｓ３０６へ処理を進める。Ｓ３０５で、動的ロードソフトウェア２１１は、ソケット情報書換部２１５により、第一の管理データのソケット情報を、上述したように書き換え、Ｓ３０６へ処理を進める。Ｓ３０６で、動的ロードソフトウェア２１１は、第一の管理データについての処理を、フック元のプロトコルスタック２０２に戻し、コールバック処理を終了する。動的ロードソフトウェア２１１は、コールバックの返り値として、例えば、Netfilterフレームワークにおいては、NF_ACCEPTで定義された定数を返す。

一方、Ｓ３０７で、動的ロードソフトウェア２１１は、第二バッファ管理部２１６により、上述の演算により、オフロード処理部１０６（第二セグメント分割部２１８）によるセグメント分割処理において生成されるパケット数（セグメント数）を算出する。このように、動的ロードソフトウェア２１１は、送信データのサイズと所定サイズ（本実施形態では、ＴＣＰにおけるＭＳＳ）、セグメント分割処理で送信データから得られるセグメントデータの数を示すセグメント数を算出する。

次にＳ３０８で、動的ロードソフトウェア２１１は、第二バッファ管理部２１６により、Ｓ３０７で算出した生成パケット数に対応する第二の管理データを確保する。即ち、生成パケット数分の第二の管理データが確保される。例えば、Ｌｉｎｕｘにおいては、生成するパケットの数（セグメント数）に等しい回数、alloc_skb()を呼び出すことで、第二の管理データが確保される。このようにして、動的ロードソフトウェア２１１は、送信データを格納するための送信バッファとは別に、セグメントデータを格納するための、セグメント数に等しい数の送信バッファを管理する管理データ（第二の管理データ）を生成する。

更にＳ３０９で、動的ロードソフトウェア２１１は、オフロード処理部１０６に対して、オフロード処理の実行を指示する。例えば、メモリマップドＩ／Ｏとして登録されたオフロード処理部１０６のレジスタに対して、オフロード処理に必要な情報を書き込むとともに、オフロード処理の実行の開始を指令する。オフロード処理に必要な情報には、例えば、第一の管理データのアドレス情報、及び第二の管理データのアドレス情報等が含まれる。このようにして、動的ロードソフトウェア２１１は、第一の管理データ（のアドレス情報）及び第二の管理データ（のアドレス情報）を、オフロード処理部１０６へ送る。

次にＳ３１０で、動的ロードソフトウェア２１１は、オフロード処理部１０６によるオフロード処理が完了したか否かを判定する。この判定は、例えば、オフロード処理部１０６による処理の実行状態を示す、オフロード処理部１０６のレジスタ値を読み出し、読み出した値に基づいて行われる。動的ロードソフトウェア２１１はオフロード処理処理が完了していない場合、Ｓ３１１の判定処理を繰り返し（例えば、所定時間経過するごとに）実行し、オフロード処理処理が完了した場合、Ｓ３１１へ処理を進める。

Ｓ３１１で、動的ロードソフトウェア２１１は、オフロード処理部１０６のオフロード処理によりセグメント分割処理及びヘッダ生成処理が行われた送信データに対応する第二の管理データを、フック元であるＯＳカーネル２０１へ送信する処理を行う。この送信処理は、図６を用いて後述する手順で実行される。最後にＳ３１２で、動的ロードソフトウェア２１１は、フックされた通信プロトコル処理に関連する第一の管理データ（元の管理データ）のメモリ領域を解放し、コールバック処理を終了する。動的ロードソフトウェア２１１は、例えば、Ｌｉｎｕｘにおいては、kfree_skb()を呼び出すことで、第一の管理データのメモリ領域を解放する。また、動的ロードソフトウェア２１１は、コールバックの返り値として、例えば、Netfilterフレームワークにおいては、NF_STOLENで定義された定数を返す。

＜データ判定処理＞
図４は、本実施形態におけるデータ判定処理（Ｓ３０２）の手順を示すフローチャートである。データ判定処理では、処理判定部２１３が、プロトコルスタック２０２からフックされる通信プロトコル処理に関連する第一の管理データを解析し、当該データに対する処理方法を決定する。

Ｓ４０１で、処理判定部２１３は、第一の管理データが示すＩＰヘッダからトランスポート層の通信プロトコルを確認し、当該通信プロトコルがオフロード処理対象の通信プロトコルであるか否かを判定する。本実施形態では、一例として、ＴＣＰがオフロード処理の対象となることを想定する。つまり、Ｓ４０１の判定は、通信プロトコルの種類に基づいて行われる。処理判定部２１３は、トランスポート層の通信プロトコルがＴＣＰであればＳ４０２へ処理を進め、ＴＣＰでなければＳ４０９へ処理を進める。

Ｓ４０２で、処理判定部２１３は、第一の管理データのＴＣＰヘッダからポート番号を確認し、当該ポート番号がオフロード処理対象のポート番号であるか否かを判定する。本実施形態では、オフロード処理の対象とすべきアプリケーションのポート番号（対象ポート番号）が予め指定（入力）されている。処理判定部２１３は、ポート番号が対象ポート番号であればＳ４０３へ処理を進め、対象ポート番号でなければＳ４０９へ処理を進める。なお、Ｓ４０２の処理（ポート番号によるフィルタリング）は、例えば、特定のアプリケーションのみを対象としてオフロード処理を行いたい場合に実行されればよく、それ以外の場合には省略されてもよい。

Ｓ４０３で、処理判定部２１３は、ソケット情報が書き換え済みであるか否かを判定する。具体的には、処理判定部２１３は、ソケット情報内のＭＳＳのキャッシュ値及びオフロード設定情報を確認する。処理判定部２１３は、ソケット情報が書き換え済みであればＳ４０４へ処理を進め、書き換え済みでなければＳ４１１へ処理を進める。

Ｓ４０４で、処理判定部２１３は、次に送信すべきセグメントデータに関連する近傍エントリ（ＭＡＣヘッダのキャッシュ情報）が存在するか否かを判定する。処理判定部２１３は、近傍エントリがなければＳ４０９へ処理を進め、近傍エントリがあればＳ４０５へ処理を進める。Ｓ４０５で、処理判定部２１３は、第一の管理データのセグメントデータサイズがＭＳＳより大きいか否かを判定する。処理判定部２１３は、セグメントデータサイズがＭＳＳよりも大きければＳ４０６へ処理を進め、ＭＳＳ以下であればＳ４０９へ処理を進める。

この判定処理により、動的ロードソフトウェア２１１（処理判定部２１３）は、送信データのサイズが所定サイズ（本実施形態では、ＴＣＰにおけるＭＳＳ）を超える場合に、当該送信データを所定サイズのセグメントデータに分割する分割処理を、オフロード処理部１０６に実行させる制御を行う。また、動的ロードソフトウェア２１１（処理判定部２１３）は、送信データのサイズが所定サイズを超えない場合には、フックされた通信プロトコル処理をＯＳカーネル２０１に戻すことで、当該通信プロトコル処理をＯＳカーネル２０１に実行させる制御を行う。

Ｓ４０６で、処理判定部２１３は、近傍エントリが有効状態であるか否かを判定する。処理判定部２１３は、近傍エントリが有効状態である場合（即ち、近傍エントリが有効なキャッシュ情報を保持している場合）、Ｓ４０７へ処理を進める。一方、処理判定部２１３は、近傍エントリが有効状態でない場合（即ち、近傍エントリが有効なキャッシュ情報を保持していない場合）、Ｓ４０８へ処理を進める。なお、近傍エントリの状態に関しては、図２を参照して上述したとおりである。このように、Ｓ４０４及びＳ４０６において、処理判定部２１３は、送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する。

Ｓ４０７で、処理判定部２１３は、動的ロードソフトウェア２１１内で保持されているＭＡＣヘッダ生成フラグをＯＮに設定する。一方、Ｓ４０８で、処理判定部２１３は、当該ＭＡＣヘッダ生成フラグをＯＦＦに設定する。ＭＡＣヘッダ生成フラグは、オフロード処理部１０６の第二ヘッダ生成部２１９によってＭＡＣヘッダを生成するか否かを示すフラグである。当該フラグがＯＮに設定されている場合、第二ヘッダ生成部２１９がＭＡＣヘッダを生成する。当該フラグがＯＦＦに設定されている場合、第二ヘッダ生成部２１９がＭＡＣヘッダを生成しない。Ｓ４０７又はＳ４０８におけるＭＡＣヘッダ生成フラグの設定が完了すると、処理判定部２１３は、Ｓ４１０へ処理を進める。

Ｓ４０９で、処理判定部２１３は、第一の管理データ（に対応する送信データ）がオフロード処理対象ではなく、当該データをプロトコルスタック２０２のプロトコル処理へ戻すと判定する。この場合、動的ロードソフトウェア２１１は、図３のＳ３０６において当該管理データをプロトコル処理返付部２１４に送る。

Ｓ４１０で、処理判定部２１３は、第一の管理データについてオフロード処理を行う（第一の管理データがオフロード処理対象である）と判定する。この場合、動的ロードソフトウェア２１１は、図３のＳ３０７において当該管理データを第二バッファ管理部２１６に送る。

Ｓ４１１で、処理判定部２１３は、第一の管理データのソケット情報を書き換えると判定する。この場合、動的ロードソフトウェア２１１は、図３のＳ３０５において当該管理データをソケット情報書換部２１５に送る。

＜オフロード処理部１０６の処理手順＞
オフロード処理部１０６は、通信装置１００において動作するＯＳカーネル２０１による通信プロトコル処理を、ＯＳカーネル２０１の代わりに実行する。具体的には、オフロード処理部１０６は、送信対象の送信データをセグメントデータに分割するセグメント分割処理と、セグメント分割処理で分割された各セグメントデータに対してヘッダを生成して付与するヘッダ生成処理とを行う。オフロード処理部１０６は、近傍エントリが有効なキャッシュ情報を保持している場合、ＭＡＣ層より上位層のヘッダ（本例では、ＴＣＰ／ＩＰヘッダ）及びＭＡＣヘッダを生成するよう、動的ロードソフトウェア２１１によって制御される。一方、オフロード処理部１０６は、近傍エントリが有効なキャッシュ情報を保持していない場合、ＭＡＣ層より上位層のヘッダ（本例では、ＴＣＰ／ＩＰヘッダ）を生成するよう、動的ロードソフトウェア２１１によって制御される。この場合、動的ロードソフトウェア２１１は、ＯＳカーネル２０１（近傍エントリ処理部２０９）がＭＡＣヘッダを生成するよう制御する。

図５は、オフロード処理部１０６によって実行される処理の手順を示すフローチャートである。オフロード処理部１０６は、動的ロードソフトウェア２１１からの実行指示（Ｓ３０９）に従って、オフロード処理を実行する。オフロード処理部１０６は、第一の管理データに対応する送信バッファに格納されたセグメントデータを分割し、分割後のセグメントデータを、第二の管理データに対応する送信バッファに格納する。オフロード処理部１０６は更に、第一の管理データに対応するＴＣＰ／ＩＰヘッダから、第二の管理データに対応する（即ち、分割後のセグメントデータに付与されるべき）ＴＣＰ／ＩＰヘッダを生成する。

オフロード処理部１０６は、Ｓ５０１～Ｓ５０５の処理を、生成パケット数分、繰り返す。まずＳ５０１で、オフロード処理部１０６は、第二セグメント分割部２１８によってセグメント分割処理を行う。具体的には、第二セグメント分割部２１８は、第一の管理データによって管理されているセグメントデータのアドレスを読み出し元アドレスとして用いて、ＤＭＡＣ１０９によりセグメントデータを取得する。第二セグメント分割部２１８は、取得したセグメントデータを、ＭＳＳ単位のセグメントデータに分割することで、セグメント分割処理を行う。より詳しくは、第二セグメント分割部２１８は、第二バッファ管理部２１６で確保した第二の管理データに対し、管理されるデータ領域を書き出し先としてＭＳＳ単位でセグメントデータをメモリコピーすることでセグメント分割処理を行う。

Ｓ５０２で、オフロード処理部１０６は、第二ヘッダ生成部２１９によってＴＣＰヘッダの生成を行う。第二ヘッダ生成部２１９は、第一の管理データに対応するＴＣＰヘッダを取得し、第二の管理データに対して、ポート番号情報及びコントロールフラグ等はそのまま使用し、シーケンス番号及びチェックサム等の計算を行う。

Ｓ５０３で、オフロード処理部１０６は、第二ヘッダ生成部２１９によってＩＰヘッダの生成を行う。第二ヘッダ生成部２１９は、第一の管理データに対応するＩＰヘッダを取得し、第二の管理データに対して、アドレス情報及びプロトコル情報等をそのまま使用し、第二の管理データごとに異なる値（パケット長、識別子、及びチェックサム等）の計算を行う。

Ｓ５０４で、オフロード処理部１０６は、動的ロードソフトウェア２１１から入力されるＭＡＣヘッダ生成フラグがＯＮに設定されているか否かを判定する。オフロード処理部１０６は、ＭＡＣヘッダ生成フラグがＯＮに設定されている場合にはＳ５０５へ処理を進め、ＭＡＣヘッダ生成フラグがＯＦＦに設定されている場合にはＭＡＣヘッダの生成を行わずにＳ５０６へ処理を進める。

Ｓ５０５で、オフロード処理部１０６は、第二ヘッダ生成部２１９によってＭＡＣヘッダの生成を行う。オフロード処理部１０６は、動的ロードソフトウェア２１１から入力される、近傍エントリに含まれるＭＡＣヘッダのキャッシュ情報を用いてＭＡＣヘッダを生成する。具体的には、キャッシュ情報に含まれる、宛先ＭＡＣアドレス及び送信元ＭＡＣアドレス等を、第二の管理データに対応するＭＡＣヘッダ領域にコピーすることで、ＭＡＣヘッダを生成する。

このようにして、Ｓ５０１による分割後のセグメントデータに対してＴＣＰヘッダ、ＩＰヘッダ及びＭＡＣヘッダが付与されたパケット（ＭＡＣフレーム）が、送信データとして生成される。生成されたパケット（ＭＡＣフレーム）は、第二の管理データによって管理される送信バッファに格納される。一方、Ｓ５０５におけるＭＡＣヘッダの生成が行われない場合には、Ｓ５０１による分割後のセグメントデータに対してＴＣＰヘッダ及びＩＰヘッダが付与されたパケットが、送信データとして生成される。この場合、ＭＡＣヘッダは、ＯＳカーネル２０１の近傍エントリ処理部２０９によって生成され、送信データに対して付与されることでＭＡＣフレームが生成される。

Ｓ５０６で、オフロード処理部１０６は、Ｓ５０１～Ｓ５０５の処理について、生成パケット数分の繰り返しが完了したか否かを判定し、完了していなければＳ５０１へ処理を戻し、完了したらＳ５０７へ処理を進める。

Ｓ５０７で、オフロード処理部１０６は、パケット生成のためのオフロード処理が完了したことを通知する処理を行う。この完了通知は、種々の方法で実現可能である。例えば、オフロード処理部１０６の状態を示すレジスタに処理完了を示す値が書き込まれてもよいし、あるいは、ＣＰＵ１０２に対して処理完了を示すハードウェア割り込み信号が出力されてもよい。また、ＣＰＵ１０２に対して直接信号を出力せず、別途、割り込みコントローラを介して完了通知が行われてもよい。また、動的ロードソフトウェア２１１から入力されたアドレス領域（ＲＡＭ１０４の記憶領域）の特定のビットに、処理完了を示す情報が書き込まれてもよい。

＜データ送信処理＞
図６は、本実施形態における、フック元（ＯＳカーネル２０１）へ管理データ（第二の管理データ）を送信するデータ送信処理（Ｓ３１１）の手順を示すフローチャートである。動的ロードソフトウェア２１１のＤＬ層入力部２１７は、ＭＡＣヘッダ生成フラグがＯＮに設定されている場合には、オフロード処理部１０６によって生成されたパケット（送信データ）に対応する第二の管理データを、転送処理部２１０に送信する。ＤＬ層入力部２１７は、ＭＡＣヘッダ生成フラグがＯＦＦに設定されている場合には、オフロード処理部１０６によって生成されたパケット（送信データ）に対応する第二の管理データを、近傍エントリ処理部２０９に送信する。

Ｓ６０１で、ＤＬ層入力部２１７は、ＭＡＣヘッダ生成フラグがＯＮに設定されているか否かを判定する。ＤＬ層入力部２１７は、ＭＡＣヘッダ生成フラグがＯＮに設定されている場合にはＳ６０２へ処理を進め、ＭＡＣヘッダ生成フラグがＯＦＦに設定されている場合にはＳ６０５へ処理を進める。以下では、ＤＬ層入力部２１７は、Ｓ６０２～Ｓ６０３の処理又はＳ６０５～Ｓ６０６の処理を、オフロード処理部１０６によって生成されたパケット数分（第二の管理データ数分）、繰り返す。

Ｓ６０２で、ＤＬ層入力部２１７は、第二の管理データ内のチェックサム計算済フラグをＯＮに設定する。これにより、第二の管理データ内のＴＣＰ／ＩＰチェックサム値が計算済みであることを示す。次にＳ６０３で、ＤＬ層入力部２１７は、第二の管理データを転送処理部２１０に入力（送信）する。Ｓ６０３における第二の管理データの入力は、ＯＳカーネル２０１の機能を用いて行われる。例えば、Ｌｉｎｕｘにおいては、転送処理部２１０への第二の管理データの入力は、dev_queue_xmit()を呼び出すことで実現されうる。このようにして、ＤＬ層入力部２１７は、オフロード処理部１０６によって生成された、上位層のヘッダ（ＴＣＰ／ＩＰヘッダ）及びＭＡＣヘッダを各セグメントデータに付与して得られたＭＡＣフレームを、転送処理部２１０へ送る。

その後、Ｓ６０４で、ＤＬ層入力部２１７は、Ｓ６０２～Ｓ６０３の処理について、オフロード処理部１０６によって生成されたパケット数分の繰り返しが完了したか否かを判定し、完了していなければＳ６０２へ処理を戻す。一方、ＤＬ層入力部２１７は、完了したら図６の手順による処理を終了する。

一方、Ｓ６０５で、ＤＬ層入力部２１７は、Ｓ６０２と同様、ＤＬ層入力部２１７は、第二の管理データ内のチェックサム計算済フラグをＯＮに設定する。次にＳ６０６で、ＤＬ層入力部２１７は、第二の管理データを近傍エントリ処理部２０９に入力（送信）する。Ｓ６０６における第二の管理データの入力は、ＯＳカーネル２０１の機能を用いて行われる。例えば、Ｌｉｎｕｘにおいては、近傍エントリ処理部２０９への第二の管理データの入力は、neigh_resolve_output()を呼び出すことで実現されうる。このようにして、ＤＬ層入力部２１７は、オフロード処理部１０６によって生成された、上位層のヘッダ（ＴＣＰ／ＩＰヘッダ）を各セグメントデータに付与して得られたパケットを、近傍エントリ処理部２０９へ送る。

その後、Ｓ６０７で、ＤＬ層入力部２１７は、Ｓ６０５～Ｓ６０６の処理について、オフロード処理部１０６によって生成されたパケット数分の繰り返しが完了したか否かを判定し、完了していなければＳ６０５へ処理を戻す。一方、ＤＬ層入力部２１７は、完了したら図６の手順による処理を終了する。

＜セグメント分割及びヘッダ生成の例（近傍エントリが有効状態の場合）＞
図７は、ＭＡＣヘッダのキャッシュ情報が有効である場合（近傍エントリが有効状態である場合）の、オフロード処理部１０６によるセグメント分割及びヘッダ生成の例を示す図である。本実施形態のオフロード処理部１０６において、セグメント分割処理は第二セグメント分割部２１８によって行われ、ヘッダ生成処理は第二ヘッダ生成部２１９によって行われる。図７では、管理データ７００～７０９によって管理される（ＲＡＭ１０４の記憶領域に確保された）送信バッファの状態の例を示している。

管理データ７００は、プロトコルスタック２０２から通信プロトコル処理がフックされた際の第一の管理データの例である。管理データ７００に対応する送信バッファに格納された送信データ（パケット）は、セグメントデータ７０１、ＴＣＰヘッダ７０２及びＩＰヘッダ７０３で構成されている。なお、送信バッファにおいて、ＭＡＣヘッダを格納するためのＭＡＣヘッダ領域７０４が確保されている。

セグメントデータ７０１は、ＭＳＳより大きいセグメントサイズを有する場合に、オフロード処理部１０６によるオフロード処理の対象となる。ＴＣＰヘッダ７０２及びＩＰヘッダ７０３は、セグメントデータ７０１に対して第一ヘッダ生成部２０６によって生成されたヘッダである。なお、本実施形態では、第一ヘッダ生成部２０６がヘッダ生成処理を行っている途中でＩＰ処理フック部２０８によるフック処理が行われることで、ＴＣＰ／ＩＰチェックサム値は未計算である状態を想定する。

ＭＡＣヘッダ領域７０４は、送信データ（パケット）に付与されるＭＡＣヘッダを格納するための領域である。管理データ７００に対応する送信データ（送信パケット）にはＭＡＣヘッダは付与されていない。キャッシュ情報７０５は、近傍エントリが保持しているＭＡＣヘッダのキャッシュ情報である。動的ロードソフトウェア２１１は、近傍エントリが保持しているキャッシュ情報７０５をＭＡＣヘッダ領域７０４にコピー（メモリコピー）し、当該キャッシュ情報についてのメモリアドレス情報をオフロード処理部１０６のレジスタに書き込む。これにより、オフロード処理部１０６が、キャッシュ情報７０５を参照することが可能となる。

管理データ７０６～７０９は、動的ロードソフトウェア２１１（第二バッファ管理部２１６）によって生成（確保）される管理データ（第二の管理データ）である。なお、図７には、セグメント分割処理において生成されるパケット数が４であり、それに応じて４つの管理データ７０６～７０９が生成される例を示している。管理データ７０６～７０９はそれぞれ、分割されたセグメントデータ（送信データ）を格納するための送信バッファを管理する。

オフロード処理部１０６では、第二セグメント分割部２１８は、セグメントデータ７０１を、ＭＳＳ単位のセグメントデータ７１０～７１３に分割する。セグメントデータ７１０～７１３は、管理データ７０６～７０９によって管理されているセグメントデータ領域に格納される。

第二ヘッダ生成部２１９は、管理データ７００によって示されるＴＣＰヘッダ７０２に基づいて、ＴＣＰヘッダ７１４～７１７を生成し、それぞれセグメントデータ７１０～７１３に付与する。また、第二ヘッダ生成部２１９は、管理データ７００によって示されるＩＰヘッダ７０３に基づいて、ＩＰヘッダ７１８～７２１を生成し、それぞれＴＣＰヘッダ７１４～７１７より前に付与する。第二ヘッダ生成部２１９は更に、キャッシュ情報７０５に含まれるＭＡＣヘッダを複製することによって、ＭＡＣヘッダ７２２～７２５を生成し、それぞれＩＰヘッダ７１８～７２１より前に付与する。このように、オフロード処理部１０６（第二ヘッダ生成部２１９）は、セグメント分割処理で分割された各セグメントデータに対して付与するＭＡＣヘッダを、近傍エントリが保持しているキャッシュ情報７０５に基づいて生成する。

このようにして、セグメント分割処理により分割された各セグメントデータに対してＴＣＰヘッダ、ＩＰヘッダ及びＭＡＣヘッダを付与して得られたパケット（ＭＡＣフレーム）が生成される。生成された各パケットは、管理データ８０６～８０９によって管理される、対応する送信バッファに格納される。

＜セグメント分割及びヘッダ生成の例（近傍エントリが無効状態の場合）＞
図８は、ＭＡＣヘッダのキャッシュ情報が無効である場合（近傍エントリが無効状態である場合）の、オフロード処理部１０６によるセグメント分割及びヘッダ生成の例を示す図である。ここでは、図７に示される、ＭＡＣヘッダのキャッシュ情報が有効である場合と異なる点について説明する。

近傍エントリに保持されているＭＡＣヘッダのキャッシュ情報８０５が無効である場合、第二ヘッダ生成部２１９はキャッシュ情報８０５を使用してＭＡＣヘッダを生成することができない。このため、第二ヘッダ生成部２１９による、ＭＡＣヘッダの生成及びＭＡＣヘッダ領域８２２～８２５へのＭＡＣヘッダの付与は行われない。この場合、ＭＡＣヘッダは、ＯＳカーネル２０１の近傍エントリ処理部２０９によって生成及び付与される。

＜まとめ＞
以上説明したように、本実施形態の通信装置１００において、動的ロードソフトウェア２１１は、ＯＳカーネル２０１による通信プロトコル処理をフックする。動的ロードソフトウェア２１１は、通信プロトコル処理がフックされると、送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する。動的ロードソフトウェア２１１は、判定された近傍エントリの状態に基づいて、ヘッダ生成処理を制御する。動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持している場合、オフロード処理部１０６がＭＡＣ層より上位層のヘッダ及びＭＡＣヘッダを生成するよう制御する。一方、動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持していない場合、オフロード処理部１０６が上位層のヘッダを生成し、ＯＳカーネル２０１がＭＡＣヘッダを生成するよう制御する。

例えば、動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持している場合、オフロード処理部１０６がＴＣＰヘッダ、ＩＰヘッダ及びＭＡＣヘッダを生成するよう制御する。一方、動的ロードソフトウェア２１１は、近傍エントリが有効なキャッシュ情報を保持していない場合、オフロード処理部１０６がＴＣＰヘッダ及びＩＰヘッダを生成し、ＯＳカーネル２０１がＭＡＣヘッダを生成するよう制御する。

このように、ＯＳカーネル２０１とは独立した動的ロードソフトウェア２１１により（即ち、ＯＳカーネル２０１に対する変更を行うことなく）、送信パケットを生成するための通信プロトコル処理の一部をオフロード処理によって実現可能になる。また、ＭＡＣヘッダのキャッシュ情報を使用可能な場合にはオフロード処理部１０６にヘッダ生成処理を行わせ、キャッシュ情報を使用不可能な場合にはＯＳカーネル２０１にヘッダ生成処理を行わせることで、適切に送信パケットを生成できる。即ち、ＭＡＣヘッダのキャッシュ情報の使用可否によらず、送信パケットを生成するための通信プロトコル処理の一部をオフロード処理により実現可能になる。通信プロトコル処理に伴うＣＰＵ１０２（プロトコルスタック２０２）における処理負荷の軽減を、簡易な構成で実現できる。

なお、上述の実施形態は種々の変更が可能である。例えば、図４のＳ４０２で使用されるポート番号は、宛先／送信元ポート番号である。また、このポート番号の代わりに、宛先ＩＰアドレスを使用して、宛先ＩＰアドレスがオフロード処理対象の宛先ＩＰアドレスであれば、Ｓ４０３に処理を進めるようにしてもよい。また、処理判定部２１３は、ＴＣＰウインドウスケールのシフトカウント（３ウェイシェイクハンド後）が、所定値（例えば、１）以上であれば、フックした通信プロトコル処理に関連する管理データのソケット情報を書き換えるという判定をしてもよい。また、Ｓ４０９の処理の実行完了時点で、チェックサム計算がオフになっているならば、プロトコル処理返付部２１４は、チェックサム計算を行った後に、管理データをプロトコルスタック２０２に戻してもよい。この場合、プロトコル処理返付部２１４は、管理データをＩＰ層に戻す。

また、上述の実施形態では、動的ロードソフトウェア２１１によるコールバック処理内で、オフロード処理部１０６の処理完了を待つ例を説明したが、コールバック処理内で待たなくてもよい。例えば、図３のＳ３０９において、動的ロードソフトウェア２１１は、オフロード処理部１０６にオフロード処理の実行指示をした後に、Ｓ３１０及びＳ３１１の処理をスキップし、Ｓ３１２に処理を進める。更に、図５のＳ５０７において、オフロード処理部１０６は、処理完了をＣＰＵ１０２に対してハードウェア割り込み信号により通知する。動的ロードソフトウェア２１１は、予めハードウェア割り込み信号に対するハンドラ（Top Half）を登録しておき、ハンドラ内で遅延実行処理（Bottom Half）をスケジュールしておき、当該遅延実行処理としてデータ送信処理（Ｓ３１１）を実行する。遅延実行処理としては、例えば、Ｌｉｎｕｘにおいてはソフトウェア割り込み又はTasklet等により実現することができる。このような構成にすることで、オフロード処理部１０６がオフロード処理を行っている間に、ＣＰＵ１０２が別の処理を実行することが可能となり、並列処理性能を高めることが可能になる。

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

発明は上記実施形態に制限されるものではなく、発明の精神及び範囲から離脱することなく、様々な変更及び変形が可能である。従って、発明の範囲を公にするために請求項を添付する。

１００：通信装置、１０２：ＣＰＵ、１０５：通信デバイス、１０６：オフロード処理部、２０１：ＯＳカーネル、２０２：プロトコルスタック、２１１：動的ロードソフトウェア、２１３：処理判定部

Claims (11)

1. 通信装置であって、
   前記通信装置において動作するＯＳカーネルによる通信プロトコル処理を、前記ＯＳカーネルの代わりに実行する処理手段であって、送信対象の送信データをセグメントデータに分割する分割処理と、前記分割処理で分割された各セグメントデータに対してヘッダを生成して付与するヘッダ生成処理とを行う、前記処理手段と、
   前記ＯＳカーネルによる前記通信プロトコル処理をフックするフック手段と、
   前記フック手段によって前記通信プロトコル処理がフックされると、前記送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する判定手段と、
   前記判定手段によって判定された前記近傍エントリの状態に基づいて、前記ヘッダ生成処理を制御する制御手段と、を備え、
   前記制御手段は、前記近傍エントリが有効なキャッシュ情報を保持している場合、前記処理手段がＭＡＣ層より上位層のヘッダ及び前記ＭＡＣヘッダを生成するよう制御し、前記近傍エントリが有効なキャッシュ情報を保持していない場合、前記処理手段が前記上位層のヘッダを生成し、前記ＯＳカーネルが前記ＭＡＣヘッダを生成するよう制御する
   ことを特徴とする通信装置。
2. 前記制御手段は、前記近傍エントリが有効なキャッシュ情報を保持している場合、前記処理手段がＴＣＰヘッダ、ＩＰヘッダ及び前記ＭＡＣヘッダを生成するよう制御し、前記近傍エントリが有効なキャッシュ情報を保持していない場合、前記処理手段が前記ＴＣＰヘッダ及び前記ＩＰヘッダを生成し、前記ＯＳカーネルが前記ＭＡＣヘッダを生成するよう制御することを特徴とする請求項１に記載の通信装置。
3. 前記制御手段は更に、前記送信データのサイズが所定サイズを超える場合に、前記送信データを前記所定サイズのセグメントデータに分割する分割処理を前記処理手段に実行させることを特徴とする請求項１又は２に記載の通信装置。
4. 前記制御手段は更に、前記送信データのサイズが前記所定サイズを超えない場合には、前記フック手段によってフックされた前記通信プロトコル処理を前記ＯＳカーネルに戻すことで、当該通信プロトコル処理を前記ＯＳカーネルに実行させることを特徴とする請求項３に記載の通信装置。
5. 前記制御手段は、前記送信データのサイズと前記所定サイズとに基づいて、前記分割処理で前記送信データから得られるセグメントデータの数を示すセグメント数を算出し、前記送信データを格納するための送信バッファとは別に、セグメントデータを格納するための、前記セグメント数に等しい数の送信バッファを管理する管理データを生成し、当該管理データを前記処理手段に送ることを特徴とする請求項３又は４に記載の通信装置。
6. 前記所定サイズは、ＴＣＰにおける最大セグメントサイズであることを特徴とする請求項３乃至５のいずれか１項に記載の通信装置。
7. ネットワークを介して通信相手装置との通信を行う通信手段を更に備え、
   前記ＯＳカーネルは、
   前記送信データの送信先ＩＰアドレスに対応するＭＡＣアドレスを、アドレス解決処理により取得し、取得したＭＡＣアドレスを含むＭＡＣヘッダを生成する生成手段と、
   前記送信データを分割して得られた各セグメントデータに前記ＭＡＣヘッダを付与して得られたＭＡＣフレームを、前記通信手段へ転送する転送手段と、を有し、
   前記制御手段は、
   前記近傍エントリが有効なキャッシュ情報を保持している場合、前記処理手段によって生成された、前記上位層のヘッダ及び前記ＭＡＣヘッダを各セグメントデータに付与して得られたＭＡＣフレームを、前記転送手段へ送り、
   前記近傍エントリが有効なキャッシュ情報を保持していない場合、前記処理手段によって生成された、前記上位層のヘッダを各セグメントデータに付与して得られたパケットを、前記生成手段へ送る
   ことを特徴とする請求項１乃至６のいずれか１項に記載の通信装置。
8. 前記処理手段は、前記分割処理で分割された各セグメントデータに対して付与するＭＡＣヘッダを、前記近傍エントリが保持している前記キャッシュ情報に基づいて生成することを特徴とする請求項１乃至７のいずれか１項に記載の通信装置。
9. 前記近傍エントリは、前記ＯＳカーネルによって管理されていることを特徴とする請求項１乃至８のいずれか１項に記載の通信装置。
10. 通信装置において動作するＯＳカーネルによる通信プロトコル処理を、前記ＯＳカーネルの代わりに実行する処理手段であって、送信対象の送信データをセグメントデータに分割する分割処理と、前記分割処理で分割された各セグメントデータに対してヘッダを生成して付与するヘッダ生成処理とを行う、前記処理手段を備える通信装置の制御方法であって、
    前記ＯＳカーネルによる前記通信プロトコル処理をフックするフック工程と、
    前記フック工程で前記通信プロトコル処理がフックされると、前記送信データに付与されるＭＡＣヘッダのキャッシュ情報を保持する近傍エントリの状態を判定する判定工程と、
    前記判定工程で判定された前記近傍エントリの状態に基づいて、前記ヘッダ生成処理を制御する制御工程と、を備え、
    前記制御工程では、前記近傍エントリが有効なキャッシュ情報を保持している場合、前記処理手段がＭＡＣ層より上位層のヘッダ及び前記ＭＡＣヘッダを生成するよう制御し、前記近傍エントリが有効なキャッシュ情報を保持していない場合、前記処理手段が前記上位層のヘッダを生成し、前記ＯＳカーネルが前記ＭＡＣヘッダを生成するよう制御する
    ことを特徴とする通信装置の制御方法。
11. 請求項１０に記載の通信装置の制御方法の各工程をコンピュータに実行させるためのプログラム。

Images