図面 (/)

技術 通信装置、通信装置の制御方法およびプログラム

出願人 キヤノン株式会社
発明者 木下暁央
出願日 2019年4月16日 (1年10ヶ月経過) 出願番号 2019-077786
公開日 2020年10月29日 (3ヶ月経過) 公開番号 2020-178182
状態 未査定
技術分野 通信制御 広域データ交換
主要キーワード ネットワーク処理装置 セグメント管 対向通信装置 セグメント処理 TSO ウィンドウサイズ分 バッファ管理情報 残りサイズ
関連する未来課題
重要な関連分野

この項目の情報は公開日時点(2020年10月29日)のものです。
また、この項目は機械的に抽出しているため、正しく解析できていない場合があります

図面 (6)

課題

高速メモリの容量が十分でない場合であっても、パケットの生成および送信における通信性能が低下することを有効に防止する。

解決手段

通信装置は、複数の領域を含む第1の送信バッファを取得して前記第1の送信バッファの前記複数の領域のそれぞれに送信データペイロードを格納し、複数の領域を含む第2の送信バッファを第1のメモリに取得し、第1の送信バッファに格納されるペイロードに対応するヘッダを生成し、第2の送信バッファの複数の領域のそれぞれに生成されたヘッダを格納し、第1の送信バッファに格納されるペイロードを第2の送信バッファに格納されるヘッダに関連付ける情報を格納する領域を、第1のメモリと異なる第2のメモリに取得して、当該情報を当該領域に格納し、第1の送信バッファに格納されたペイロード、および第2の送信バッファに格納されたヘッダを入力として、第2のメモリの領域に格納される情報に基づいてパケットを生成する。

概要

背景

TCP/IPプロトコル(Transport Control Protocol/Internet Protocol)処理では、送信側装置は、送信データパケット化再送処理ネットワークバッファを使用する。
このTCP/IPプロトコル処理に伴うCPU(Central Processing Unit)の負荷を軽減し、パケット送信処理高速化するため、ハードウエアオフロードを利用する技術がある。
こうしたハードウエアオフロード技術の1つに、送信データをセグメントチャンク化する処理と、チャンク化されたセグメントをIPパケット化する処理を、ネットワークI/Fでハードウエアオフロードする技術がある。

上記のようなハードウエアオフロードを利用する技術は、TSO(TCP Segmentation Offload)機能により実現できる。このTSO機能は、例えばNIC(Network Interface Card)等のハードウエアオフロードで実行される。
このTSO処理では、ネットワークバッファに転送されたデータを送信単位であるMSSより大きなサイズで読み出してTCP/IPプロトコル処理を行う。その後、TCP/IPプロトコル処理されたパケットをMSSに基づいてパケット単位にチャンク化することで、複数のパケットを一度に生成し、連続送信することができる。TSO処理により複数のパケットを一括生成することで、パケットごとに実行していたTCP/IPプロトコル処理が、複数パケットに1回の実行に軽減されることとなり、CPUの負荷を軽減するとともにパケット送信処理を高速化することが実現できる。

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

概要

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

目的

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

効果

実績

技術文献被引用数
0件
牽制数
0件

この技術が所属する分野

ライセンス契約や譲渡などの可能性がある特許掲載中! 開放特許随時追加・更新中 詳しくはこちら

請求項1

複数の領域を含み、前記複数の領域のそれぞれに送信データペイロードを格納する第1の送信バッファと、前記第1の送信バッファに格納される前記ペイロードに対応するヘッダを生成する第1の生成手段と、複数の領域を含み、前記複数の領域のそれぞれに前記第1の生成手段により生成された前記ヘッダを格納する第2の送信バッファと、前記第1の送信バッファに格納される前記ペイロードを前記第2の送信バッファに格納される前記ヘッダに関連付ける情報を格納する格納手段と、前記第2の送信バッファを第1のメモリにおいて取得し、前記格納手段のための領域を前記第1のメモリと異なる第2のメモリにおいて取得する取得手段と、前記第1の送信バッファに格納された前記ペイロード、および前記第2の送信バッファに格納された前記ヘッダを入力として、前記格納手段に格納される前記情報に基づいてパケットを生成する第2の生成手段と、を備えることを特徴とする通信装置

請求項2

前記第2の送信バッファが取得される第1のメモリは、前記格納手段のための領域が取得される第2のメモリより小さいアクセスレイテンシを有することを特徴とする請求項1に記載の通信装置。

請求項3

前記送信データのサイズに基づいて、前記第2の送信バッファを前記第1のメモリと前記第2のメモリのいずれに取得するかを判定する判定手段をさらに備え、前記取得手段は、前記判定手段により、前記第2の送信バッファを前記第2のメモリに取得すると判定された場合、前記第2の送信バッファを、前記第1のメモリに替えて前記第2のメモリに取得することを特徴とする請求項1または2に記載の通信装置。

請求項4

前記判定手段は、前記送信データのサイズが、MSS(MaximumSegmentSize)を超えない場合、前記第2の送信バッファを前記第2のメモリに取得すると判定することを特徴とする請求項3に記載の通信装置。

請求項5

前記送信データを前記ペイロードに分割して前記第1の送信バッファへ転送する転送手段と、前記転送手段により前記ペイロードが前記第1の送信バッファへ転送される際に、前記ペイロードに対するチェックサムを計算する計算手段と、をさらに備えることを特徴とする請求項1から4のいずれか1項に記載の通信装置。

請求項6

前記第1の生成手段は、前記手段により計算された前記チェックサムが使用可能か否かを判定し、前記チェックサムが使用可能でない場合、前記チェックサムを再計算し、再計算されたチェックサムを含むヘッダを生成することを特徴とする請求項5に記載の通信装置。

請求項7

前記第1の生成手段は、前記第2の送信バッファを前記第1のメモリに取得可能か否かを判定し、前記取得手段は、前記第1の生成手段により、前記第2の送信バッファを前記第1のメモリに取得できないと判定された場合、前記第2の送信バッファを、前記第1のメモリに替えて前記第2のメモリに取得することを特徴とする請求項1から6のいずれか1項に記載の通信装置。

請求項8

前記第1の生成手段は、前記第1の送信バッファに格納される前記ペイロードに対応するTCP/IPヘッダを生成することを特徴とする請求項1から7のいずれか1項に記載の通信装置。

請求項9

前記第1の生成手段および前記第2の生成手段は、TSO(TCPSegmentationOffload)により、複数のパケットを一括して生成することを特徴とする請求項1から8のいずれか1項に記載の通信装置。

請求項10

通信装置の制御方法であって、複数の領域を含む第1の送信バッファを取得して前記第1の送信バッファの前記複数の領域のそれぞれに送信データのペイロードを格納するステップと、複数の領域を含む第2の送信バッファを第1のメモリにおいて取得するステップと、前記第1の送信バッファに格納される前記ペイロードに対応するヘッダを生成するステップと、前記第2の送信バッファの前記複数の領域のそれぞれに生成された前記ヘッダを格納するステップと、前記第1の送信バッファに格納される前記ペイロードを前記第2の送信バッファに格納される前記ヘッダに関連付ける情報を格納する領域を、前記第1のメモリと異なる第2のメモリにおいて取得して、前記情報を前記領域に格納するステップと、前記第1の送信バッファに格納された前記ペイロード、および前記第2の送信バッファに格納された前記ヘッダを入力として、前記第2のメモリの前記領域に格納される前記情報に基づいてパケットを生成するステップと、を含むことを特徴とする制御方法。

請求項11

コンピュータを、請求項1から9のいずれか1項に記載の通信装置の各手段として機能させるためのプログラム

技術分野

0001

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

背景技術

0002

TCP/IPプロトコル(Transport Control Protocol/Internet Protocol)処理では、送信側装置は、送信データパケット化再送処理ネットワークバッファを使用する。
このTCP/IPプロトコル処理に伴うCPU(Central Processing Unit)の負荷を軽減し、パケット送信処理高速化するため、ハードウエアオフロードを利用する技術がある。
こうしたハードウエアオフロード技術の1つに、送信データをセグメントチャンク化する処理と、チャンク化されたセグメントをIPパケット化する処理を、ネットワークI/Fでハードウエアオフロードする技術がある。

0003

上記のようなハードウエアオフロードを利用する技術は、TSO(TCP Segmentation Offload)機能により実現できる。このTSO機能は、例えばNIC(Network Interface Card)等のハードウエアオフロードで実行される。
このTSO処理では、ネットワークバッファに転送されたデータを送信単位であるMSSより大きなサイズで読み出してTCP/IPプロトコル処理を行う。その後、TCP/IPプロトコル処理されたパケットをMSSに基づいてパケット単位にチャンク化することで、複数のパケットを一度に生成し、連続送信することができる。TSO処理により複数のパケットを一括生成することで、パケットごとに実行していたTCP/IPプロトコル処理が、複数パケットに1回の実行に軽減されることとなり、CPUの負荷を軽減するとともにパケット送信処理を高速化することが実現できる。

0004

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

先行技術

0005

特開2007−266759号公報

発明が解決しようとする課題

0006

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

0007

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

0008

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

課題を解決するための手段

0009

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

発明の効果

0010

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

図面の簡単な説明

0011

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

実施例

0012

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

0013

(実施形態1)
本実施形態において、通信装置は、高速メモリおよび通常メモリを備え、送信データからパケットを生成する際に、高速メモリおよび通常メモリのいずれかにパケット送信用のバッファを取得してよい。また、この送信データからパケットを生成する処理の少なくとも一部は、例えば、TSO(TCP Segmentation Offload)技術を使用してオフロード実行されてよい。
以下では、通信装置が、TCP/IPの通信プロトコルに従ってTCP/IPパケットを生成する例を説明するが、本実施形態は、UDP(User Diagram Protocol)等の他の通信プロトコルを適用することも可能である。
また、通信装置が生成するパケットの通信ヘッダは、TCPヘッダIPヘッダ(IPv4ヘッダ、IPv6ヘッダ)、およびイーサネット登録商標)ヘッダを含んでよい。

0014

<本実施形態のハードウエアおよび機能構成>
図1は、本実施形態に係る通信装置のハードウエア構成の一例を示す図である。
通信装置1は、RAM11、CPU12、ROM13、タイマ管理部14、通信部15、バッファ管理部16、データ転送部17、チェックサム計算部18、フレーム生成部19、およびパケット生成部20を備える。RAM11、CPU12、ROM13、タイマ管理部14、通信部15、バッファ管理部16、データ転送部17、チェックサム計算部18、フレーム生成部19、およびパケット生成部20は、システムバス10を介して相互に接続されている。

0015

RAM(Random Access Memory)11は、システムバス10を介して、通信装置1内の各ブロックが共有して利用可能な記憶領域であり、各種データの保存やワークメモリとして使用される。RAM11は、通信装置1が送受信するデータを格納して管理するためのネットワークバッファが取得されるメモリであり、通常メモリ11aと高速メモリ11bとを有する。
通常メモリ11aは、例えば主としてDRAM(Dynamic Random Access Memory)等の半導体メモリで構成されてよい。
高速メモリ11bは、データ転送要求からデータ転送完了までの遅延時間であるアクセスレイテンシが通常メモリ11aより小さいメモリである。高速メモリ11bは、例えば主としてSRAM(Static Random Access Memory)等の半導体メモリで構成されてよい。

0016

CPU12は、通信装置1における動作を統括的に制御するものであり、システムバス10を介して各構成部(12〜20)を制御する。CPU12は、RAM11をワークメモリとして、ROM13、または外部メモリハードディスク等の各種記録媒体(不図示)に格納された各種プログラムを実行する。
ROM(Read Only Memory)13は、CPU12が各種処理を実行するために必要な制御プログラム等を記憶する不揮発性メモリである。なお、これら制御プログラム等は、外部メモリやハードディスク等の着脱可能な記憶媒体に記憶されていてもよい。

0017

タイマ管理部14は、通信装置1がパケット生成および送信処理を実行するために必要となる所定時間を計測および管理する。
通信部15は、例えばイーサネット(登録商標)等のネットワークとのインタフェースを提供し、ネットワークを介して外部装置との通信を実行する。通信部15は、データリンク層MAC層)の通信制御を担うMACモジュール15aと、物理層PHY層)の通信制御を担うPHYモジュール15bとを有する。

0018

データの送受信は、CPU12によりネットワークドライバが実行され、これに応じてMAC15aのモジュールが制御されることにより行われる。なお、本実施形態では、通信部15は、イーサネット(登録商標)等の通信規格準拠する有線LAN(Local Area Network)を介した通信を実行するものとして説明する。ただし、本実施形態で利用可能なネットワークはこれに限定されず、無線ネットワークで構成されてもよい。この無線ネットワークは、Bluetooth(登録商標)、ZigBee(登録商標)、UWB(Ultra Wide Band)等の無線PAN(Personal Area Network)を含む。また、Wi−Fi(Wireless Fidelity)(登録商標)等の無線LAN(Local Area Network)や、WiMAX(登録商標)等の無線MAN(Metropolitan Area Network)を含む。さらに、LTE/3G等の無線WAN(Wide Area Network)を含む。なお、ネットワークは、各機器を相互に通信可能に接続し、IP通信が可能であればよく、通信の規格規模、構成は上記に限定されない。
なお、本実施形態に係る通信装置1が送信するパケットは、IP通信上で送受信されるデータの単位である。

0019

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

0020

データ転送部17は、例えば、DMA(Direct Memory Access)により構成され、RAM11に記憶されているデータを、フレーム生成部19やパケット生成部20に転送する。データ転送部17によるデータ転送は、CPU12により制御されてもよい。
チェックサム計算部18は、第1チェックサム計算部18aおよび第2チェックサム計算部18bを有し、RAM11に記憶されている送信データに対して、チェックサムを計算する。第1チェックサム計算部18aは、MSS単位にチャンク化された送信データのセグメントに対して、複数のヘッダ生成に先立って事前にチェックサムを計算する。第2チェックサム計算部18bは、第1チェックサム計算部18aにより事前に計算されたチェックサムが複数のヘッダを生成する際にそのまま使用できないと判断された場合に、チェックサムを再計算する。

0021

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

0022

図2は、本実施形態に係る通信装置1の機能構成の一例を示す図である。
図2に示す通信装置1の各機能モジュールのうち、ソフトウエアにより実現される機能については、各機能モジュールの機能を提供するためのプログラムがROM等のメモリに記憶され、RAMに読み出してCPUが実行することにより実現される。ハードウエアにより実現される機能については、例えば、所定のコンパイラを用いることで、各機能モジュールの機能を実現するためのプログラムからFPGA上に自動的に専用回路を生成すればよい。FPGAとは、Field Programmable Gate Arrayの略である。また、FPGAと同様にしてGate Array回路を形成し、ハードウエアとして実現するようにしてもよい。また、ASIC(Application Specific IntegratedCircuit)により実現するようにしてもよい。なお、図2に示した機能ブロックの構成は一例であり、複数の機能ブロックが1つの機能ブロックを構成するようにしてもよいし、いずれかの機能ブロックが複数の機能を行うブロックに分かれてもよい。

0023

通信装置1は、アプリケーション21、プロトコルスタック22、データ転送部23、パケット生成部24、バッファ管理部25、通信I/F制御部26、および通信I/F27を備える。
アプリケーション21は、通信装置1上で稼動する各種ユーザアプリケーションである。アプリケーション21は、送信されるべき、任意のサイズのユーザデータ(送信データ)を、プロトコルスタック22に入力する。
プロトコルスタック22は、送信データ管理部221、コネクション管理部222、ウィンドウ制御部223、輻輳制御部224、セグメント処理部225、および通信プロトコル処理部226を備える。
アプリケーション21から入力された送信データは、RAM11の通常メモリ11aと高速メモリ11bのいずれかに取得されるパケット送信用のバッファ(以下、「送信バッファ」という)に格納されて、バッファ管理部25により管理される。

0024

送信データ管理部221は、送信バッファに格納されている送信データのサイズを管理する。
図3を参照して、送信データは、RAM11内の通常メモリ11aに取得されるペイロード用バッファ31または高速メモリ11bに取得されるペイロード用バッファ32のいずれかに格納される。ペイロードバッファ31、32には、複数のバッファ領域のそれぞれの管理情報が付加される。
図2戻り、コネクション管理部222は、通信装置1がネットワークを介して対向通信装置と通信するための通信コネクションを管理する。コネクション管理部222は例えば、アプリケーション21に対応する通信コネクションにおけるMSS(Maximum Segment Size)等のコネクション情報を管理する。
ウィンドウ制御部223は、通信I/F制御部26を介して受信された確認応答ACK)から、TCPコネクション送信ウィンドウサイズを取得して管理する。
輻輳制御部224は、TCPコネクションにおける輻輳制御を管理する。輻輳制御部224は例えば、アプリケーション21に対応する通信コネクションにおける輻輳ウインドウを管理する。

0025

セグメント管理部225は、送信データサイズを決定する。
具体的には、セグメント管理部225は、送信データ管理部221により管理される、通常メモリ11aまたは高速メモリ11bの送信バッファ中の送信データのサイズに基づいて、送信データサイズを決定する。セグメント管理部225はまた、コネクション管理部222が管理するMSS、ウインドウ制御部223が管理する送信ウインドウサイズ、および輻輳制御部224が管理する輻輳ウインドウサイズ等に基づいて送信データサイズを決定する。
TCP/IPプロトコル処理では、送信側のパケット送信の度に受信側がACKを送信することによる通信速度の低下を回避するため、所定のウィンドウサイズを利用するウィンドウ制御が行われる。TCP/IPのウィンドウ制御では、受信側は、受信バッファ残りサイズをウィンドウサイズに設定したACKを送信し、送信側は、ウィンドウサイズになるまでACKを待つことなく送信データを送信することができる。さらに、TCP/IPのウィンドウ制御では、通信速度をより向上させるために、スライディングウィンドウが用いられる。スライディングウィンドウでは、受信側はパケットを受信する度にACKを送信し、送信側は最初のACKを受信するとウィンドウスライドさせて、次のACKを待つことなくウィンドウサイズ分のデータを連続的に送信することが可能となる。

0026

通信プロトコル処理部226は、TCPセグメントのTCPヘッダやIPヘッダを生成するとともに、ヘッダに書き込むべきチェックサムの計算処理を行い、送信すべきパケットを生成する。
データ転送部23は、図1のデータ転送部17に対応し、通常メモリ11aまたは高速メモリ11bの送信バッファに格納される送信データをプロトコルスタック22へデータ転送する。
データ転送部23は、チャンク化部231、およびチェックサム計算部232を備える。チャンク化部231は、送信バッファに格納される送信データがプロトコルスタック22へ転送される際に、送信データを所定の単位(例えば、MSS単位)にチャンク化してセグメントを生成する。
チェックサム計算部232は、図1のチェックサム計算部18に対応し、チャンク化部231によりチャンク化された送信データのセグメントのそれぞれに対して、チェックサムを計算する。

0027

パケット生成部24は、図1のパケット生成部20に対応し、データ転送部241、ヘッダ生成部242、およびパケット化部243を有する。パケット生成部24の機能の全部または一部は、ハードウエアオフロードされてよい。
データ転送部241は、送信バッファに格納される送信データを所定の単位(例えば、MSS単位)にチャンク化するとともに、チェックサムを計算する。データ転送部241は特に、データ転送部23により実行された送信データのチャンク化およびチェックサム事前計算を、例えば他の通信装置との通信状況等により、再度実行しなければならない場合に呼び出されてよい。
ヘッダ生成部242は、フレーム生成部19により生成されたヘッダ情報に基づいて、TCP/IPヘッダ、およびイーサネットヘッダを生成する。具体的には、ヘッダ生成部242は、図1のバッファ管理部16に対応するバッファ管理部25が管理する管理情報に基づき、高速メモリ11bまたは通常メモリ11aのいずれかに取得されるヘッダ用バッファを用いて、ヘッダを生成する。

0028

図3を参照して、ヘッダ生成部242が用いるヘッダ用バッファは、RAM11の高速メモリ11bに取得されるヘッダ用バッファ35、または通常メモリ11aに取得されるヘッダ用バッファ33のいずれかである。
管理情報34は、送信バッファに格納されるペイロードを、高速メモリ11b内のヘッダ用バッファ35に格納されるヘッダに関連付ける。管理情報34により高速メモリ11b内のヘッダに関連付けられるペイロードは、通常メモリ11a内のペイロード用バッファ31または高速メモリ11b内のペイロード用バッファ32に格納される。
パケット化部243は、データ転送部241から出力されるチャンク化されたセグメントと、ヘッダ生成部242から出力されるヘッダとをパケット化して、パケットを生成する。
バッファ管理部25は、通常メモリ11aまたは高速メモリ11bに取得されるバッファを管理する。通常メモリ11aには、ペイロード用バッファ31、ヘッダ用バッファ33、および管理情報34用のバッファ領域が取得されてよい。高速メモリ11bには、ペイロード用バッファ32、およびヘッダ用バッファ35が取得されてよい。

0029

本実施形態では、セグメント処理部225により決定された送信データサイズに応じて、通信プロトコル処理部226またはパケット生成部24が、バッファ管理部25により管理される各種送信バッファを用いて、パケットを生成する。パケットの具体的な生成手順は、図4を参照して後述する。
通信プロトコル処理部226またはパケット生成部24により生成されたパケットは、通信I/F制御部26に入力される。
通信I/F制御部26は、プロトコルスタック22と通信I/F27との間で、各種データや制御情報のやり取りを担う。
通信I/F27は、図1のMACモジュール108、およびPHYモジュール109に対応し、ネットワークと通信を行う。パケットの送信は、タイマ管理部14により一定時間以上経過したことが通知された場合に実行されてもよい。

0030

<通信装置1のパケット送信処理の処理フロー
図3は、本実施形態に係る通信装置1が実行するパケット送信処理の詳細処理手順の一例を示すフローチャートである。図3に示すフローチャートは、アプリケーション21がソケットAPI send()を呼び出した場合を想定するが、パケット送信処理を起動するトリガは、アプリケーション21からの呼び出しに限定されない。
S1で、CPU12によりROM13に格納されている所定のプログラムが実行されることに応じて、アプリケーション21は、ソケットAPI send()を呼び出す

0031

ソケットAPI send()が呼び出されると、S2で、データ転送部17は、バッファ管理部16を介して、送信データを格納するペイロード用バッファをRAM11内に取得する。S2では、データ転送部17は、ペイロード用バッファを、通常メモリ11aのペイロード用バッファ31、または高速メモリ11bのペイロード用バッファ32のいずれかから取得する。
S3で、データ転送部17は、S2で取得されたペイロード用バッファへ、S1で受け渡された送信データを転送する。ユーザデータの転送先は、RAM11内の通常メモリ11aのペイロード用バッファ31、または高速メモリ11bのペイロード用バッファ32のいずれかである。
ユーザデータをペイロード用バッファ31、32へ転送する際、データ転送部17は、送信データをMSS単位にチャンク化し、チャンク化された送信データに対して、チェックサムを事前に計算する。

0032

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

0033

S5で、セグメント処理部225は、送信バッファに連結される送信データについて、送信データ管理部221により管理される送信データサイズが、ウインドウ制御部223により管理される送信ウインドウサイズを超えるか否かを判定する。
送信データ管理部221が管理する送信データサイズが、送信ウインドウサイズを超えない場合(S5:N)、S6に進み、セグメント処理部225は、送信バッファに格納されている送信データの送信データサイズをそのまま送信データサイズに決定する。一方、送信データサイズが、送信ウインドウサイズを超える場合(S5:Y)、S7に進み、セグメント処理部225は、送信バッファに格納されている送信データの送信データサイズを、送信ウインドウサイズに変更する。

0034

S8で、通信プロトコル処理部226は、S6またはS7で決定された送信データサイズが、コネクション管理部222により管理されるMSSを超えるか否かを判定する。決定された送信データサイズが、MSSを超えない場合(S8:N)、S9に進み、一方、決定された送信データサイズが、MSSを超える場合(S8:Y)、S11へ進む。
決定された送信データサイズがMSSを超えない場合、S9で、通信プロトコル処理部226は、バッファ管理部25を介して、RAM11内の通常メモリ11aのヘッダ用バッファ33から送信バッファを取得し、S10に進む。
S10で、通信プロトコル処理部226は、通常メモリ11aのヘッダ用バッファ33から取得された送信バッファに対して、CPU12によりROM13に格納されている所定のプログラムを実行する。具体的には、通信プロトコル処理部226は、送信バッファの送信データに対して、パケット生成部20を制御してチェックサムを計算し、TCP/IPヘッダを生成し、TCP/IPヘッダを用いて送信データをパケット化して、TCP/IPパケットを生成する。
通信プロトコル処理部226はさらに、TCP/IPパケットに対するイーサネットヘッダを生成し、生成したイーサネットヘッダを用いて、TCP/IPパケットをイーサネットフレーム化して、S17へ進む。

0035

S8に戻り、一方、決定された送信データサイズがMSSを超える場合、S11で、フレーム生成部19は、TCP/IPヘッダ、およびイーサネットヘッダを生成するための情報として、ヘッダ情報を生成する。
S12で、バッファ管理部25は、RAM11内の高速メモリ11bのヘッダ用バッファ35から、ヘッダ用のバッファを取得する。バッファ管理部25はまた、RAM11内の通常メモリ11aの領域に、管理情報34を格納する領域を取得する。この管理情報34は、通常メモリ11aまたは高速メモリ11bのペイロード用バッファに格納される送信データのセグメントに、高速メモリ11bのヘッダ用バッファ35に格納されるヘッダを関連付け連結するための情報(関連付け情報)である。

0036

S13で、データ転送部23は、チャンク化された各送信データと関連付けられているチェックサム値が使用可能か否かを判定する。
各送信データと関連付けられているチェックサム値が使用可能である場合(S13:Y)、S14に進み、一方、チェックサム値が使用可能でない場合(S13:N)、S15に進む。
チェックサム値が使用可能である場合、S14で、ヘッダ生成部242は、各送信データと関連付けられる、事前計算されたチェックサム値を利用し、データ転送部241は、チェックサム値の再計算や送信データの再チャンク化を行わない。
ヘッダ生成部242は、S11で生成されたヘッダ情報を使用し、TCP/IPヘッダとイーサネットヘッダとを、RAM11の高速メモリ18bのヘッダ用バッファ35に自動的に生成する。また、パケット生成部24は、管理情報34を生成して、S12で取得された通常メモリ18a内の管理情報34用の領域に格納する。

0037

一方、各送信データと関連付けられているチェックサム値が使用可能でない場合、S15で、パケット生成部24のデータ転送部241は、チャンク化された各送信データのチェックサム値を再計算する。また、ヘッダ生成部242は、S11で生成されたヘッダ情報を使用して、TCP/IPヘッダとイーサネットヘッダとを、RAM11の高速メモリ18bのヘッダ用バッファ35に自動的に生成する。また、パケット生成部24は、管理情報34を生成して、S12で取得された通常メモリa内の管理情報34用の領域に格納する。
上記S13〜S15の処理は、図1のパケット生成部20に対応する図2のパケット生成部24により実行される処理である。

0038

S16で、パケット化部243は、S14またはS15で生成されたイーサネットヘッダと、TCP/IPヘッダと、送信データのセグメントとを、管理情報34により連結し、TCP/IPパケットを生成して、イーサネットフレーム化する。なお、一度に連結できるセグメントの数は、輻輳制御部224により管理される輻輳ウインドウサイズに基づいて決定されてよい。
S17で、通信プロトコル処理部226は、生成されたイーサネットフレームを、通信I/F制御部26に送信して、処理を終了する。通信I/F制御部26は、通信I/F27を介して、イーサネットフレームをネットワークへ送信する。

0039

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

0040

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

0041

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

0042

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

0043

S8で送信データサイズがMSSを超えると判定され(S8:Y)、S11で複数ヘッダを一括生成するためのヘッダ情報が生成されると、S18で、管理情報34と、高速メモリ18b上にヘッダ用バッファ35が取得できるか否かが判定される。
管理情報34と、高速メモリ18b上にヘッダ用バッファ35が取得できないと判定された場合(S18:N)、S19に進む。
S19で、バッファ管理部25は、RAM11内の通常メモリ18aのヘッダ用バッファ33からバッファを取得し、S13に進む。
S13〜S17の処理は、図4に示される実施形態1のS13〜S17と同様である。ただし、本実施形態では、CPU12により所定のプログラムを実行するソフトウエア処理により、S13〜S15で、各セグメントに対するTCP/IPヘッダおよびイーサネットヘッダを通常メモリ18a内のヘッダ用バッファ33に生成する。また、S16で、パケット化部243は、ヘッダ用バッファ33内のヘッダに対応して生成された管理情報に基づいて、通常メモリ18a内のヘッダ用バッファ33に生成されたヘッダを送信データのセグメントに連結してイーサネットフレーム化する。

0044

一方、S18で、管理情報34と、高速メモリ18a上にヘッダ用バッファ35が取得できると判定された場合(S18:Y)、S12に進む。
S12〜S17の処理は、図4に示される実施形態1のS12〜S17と同様である。すなわち、S12で、バッファ管理部25は、RAM11内の高速メモリ11bのヘッダ用バッファ35から、ヘッダ用のバッファを取得する。バッファ管理部25はまた、RAM11内の通常メモリ11aの領域に、管理情報34を格納する領域を取得する。
また、S13〜S15で、ハードウエアオフロードにより、各セグメントに対するTCP/IPヘッダおよびイーサネットヘッダを高速メモリ18b内のヘッダ用バッファ35に生成する。また、S16で、パケット化部243は、通常メモリ18a内の領域に格納された管理情報に基づいて、高速メモリ18b内のヘッダ用バッファ35に生成されたヘッダを送信データのセグメントに連結してイーサネットフレーム化する。
なお、一度に連結できるセグメントの数は、輻輳ウインドウサイズに基づいて決定されてよい。

0045

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

0046

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

0047

1…通信装置、10…システムバス、11…RAM、11a…通常メモリ、11b…高速メモリ、12…CPU、13…ROM、14…タイマ管理部、15…通信部、15a…MAC、15b…PHY、16…バッファ管理部、17…データ転送部、18…チェックサム計算部、19…フレーム生成部、20…パケット生成部

ページトップへ

この技術を出願した法人

この技術を発明した人物

ページトップへ

関連する挑戦したい社会課題

関連する公募課題

ページトップへ

おススメ サービス

おススメ astavisionコンテンツ

新着 最近 公開された関連が強い技術

  • 三菱電機株式会社の「 通信装置、通信システム、及びプログラム」が 公開されました。( 2020/12/17)

    【課題・解決手段】第1PHY部(121)は、物理層における信号の送受信を担い、通信ケーブル(601)を介して通信装置(101)の第2PHY部(142)と信号の送受信を行い、第2PHY部(142)に対し... 詳細

  • 日本電信電話株式会社の「 識別装置、識別方法及び識別プログラム」が 公開されました。( 2020/12/17)

    【課題・解決手段】識別装置(10)は、IPアドレスブロックに含まれるIPアドレスであって、所定の順序でソートされたIPアドレスの列を複数の部分に分割する境界を、各IPアドレスのAS番号、e2LD、PT... 詳細

  • 三菱電機株式会社の「 通信装置、通信方法及び通信プログラム」が 公開されました。( 2020/12/17)

    【課題・解決手段】通信装置(10)は、TSN(Time−Sensitive Networking)技術が用いられたネットワークで通信する。タイムスロット管理部(21)は、TSN技術におけるタイムスロ... 詳細

この 技術と関連性が強い技術

関連性が強い 技術一覧

この 技術と関連性が強い人物

関連性が強い人物一覧

この 技術と関連する社会課題

関連する挑戦したい社会課題一覧

この 技術と関連する公募課題

関連する公募課題一覧

astavision 新着記事

サイト情報について

本サービスは、国が公開している情報(公開特許公報、特許整理標準化データ等)を元に構成されています。出典元のデータには一部間違いやノイズがあり、情報の正確さについては保証致しかねます。また一時的に、各データの収録範囲や更新周期によって、一部の情報が正しく表示されないことがございます。当サイトの情報を元にした諸問題、不利益等について当方は何ら責任を負いかねることを予めご承知おきのほど宜しくお願い申し上げます。

主たる情報の出典

特許情報…特許整理標準化データ(XML編)、公開特許公報、特許公報、審決公報、Patent Map Guidance System データ