JP2006260543A - データをネットワークに送信する方法及び装置並びにデータをネットワークから受信する方法及び装置 - Google Patents

Abstract

【課題】複数のプロセッサが搭載されたコンピュータ等において、複数の上位プロセスが、相互に影響し合うことなく、データの送受信をすることを可能とするＴＯＥ(TCP/IP Offload Engine)を提供する。
【解決手段】ＴＯＥ１０１では各上位プロセス毎に通知用待ち行列を生成する。ＴＯＥドライバ１０２では、各上位プロセスがどのソケットとどの通知用待ち行列とに対応するかの情報を保持する。データ送信時には、送信バッファ待ち行列１０２−４に送信データが一時保存され、送信後に送信バッファは、上位プロセスに対応する通知用待ち行列に追加される。データ受信時には、受信バッファ待ち行列１０２−３にあった受信バッファに受信データが格納され、その受信バッファが上位プロセスに対応する通知用待ち行列に追加される。
【選択図】図８

Description

本発明は、データをネットワークに送信する方法及び装置並びにデータをネットワークから受信する方法及び装置に関し、特に、同時に稼働する複数プロセッサでそれぞれ実行される複数の上位プロセス又は１つのプロセッサで同時に稼働する複数コアでそれぞれ実行される複数の上位プロセスが、相互に影響を及ぼすことなく、データをネットワークに送信する方法及び装置並びにデータをネットワークから受信する方法及び装置に関する。

従来のコンピュータでは、１つのプロセッサを利用して、タイム・シェアリングにより、複数のプロセスが見かけ上、同時に実行されている。同時に稼働するプロセスがそれぞれＩＰ(Internet Protocol)パケットの送受信を行なう場合、複数のプロセスから送信するＩＰパケットは、コンピュータ内の１つの待ち行列を通り送信され、複数のプロセスが受信するＩＰパケットは、コンピュータ内の１つの待ち行列を通り受信される。
特開２００３−３３３０７６号公報 特開平０６−２５０９８３号公報 特開平１１−３４６２４６号公報

ところが、近年、１つのコンピュータに複数のプロセッサが搭載されるようになってきている。また、１つのプロセッサに複数のコアが搭載されるようになってきている。

しかし、このようなコンピュータを利用した場合であっても、従来通り、同時に稼働するプロセスがそれぞれＩＰパケットの送受信を行なう場合、複数のプロセスから送信するＩＰパケットは、コンピュータ内の１つの待ち行列を通り送信され、複数のプロセスが受信するＩＰパケットは、コンピュータ内の１つの待ち行列を通り受信される。

特に、受信したＩＰパケットはプロセス間の区別無く、同一の待ち行列に追加される。従って、処理量の多いプロセスにより待ち行列からのデータの取出しが遅れた場合には、他のプロセスの処理の進行が遅れることとなる。例えば、ファイルサーバにおいて、ＮＦＳ(network file system)とＣＩＦＳ(common internet file system)が混在し、且つ、通信量が一方に集中した場合に、このような事態が顕在化する。また、ＮＦＳの複数の上位プロセスがあり、通信量が或る上位プロセスに集中した場合にも、このような事態が顕在化する。同様に、ＣＩＦＳの複数の上位プロセスがあり、通信量が或る上位プロセスに集中した場合に、このような事態が顕在化する。

ＴＣＰ／ＩＰプロトコル処理をホスト上のＣＰＵに代わって行うＴＯＥ（ＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）機能を持つハードウェアでは従来、送信完了通知・受信データ一時保持用に利用される待ち行列を１つ用意し、ＴＯＥドライバとＴＯＥ上のファームウェアでその待ち行列を使い、通信を行っている。このため１枚のＴＯＥカード上において、扱うことができる送受信データの量が少なくなってしまう。また、送受信データの量が多い上位プロセスと、送受信データの量が少ない上位プロセスが同時に動作していた場合、送受信データの量が少ない上位プロセスの応答時間が、遅延してしまう。これは、送受信データの量が多いプロセスの処理に時間がかかり、この処理の所定の区切りが終了するまで、送受信データの量が少ない上位プロセスの処理が待たされるからである。

そこで、本発明は、複数のプロセッサが搭載されたコンピュータや、複数のコアが搭載されたプロセッサが搭載されたコンピュータにおいて、複数の上位プロセスが、相互に影響し合うことなく、データの送受信をすることを可能とするデータをネットワークに送信する方法及びその装置並びにデータをネットワークから受信する方法及び装置を提供することを目的とする。

本発明の第１の観点によれば、データをネットワークに送信する方法であって、ドライバが、送信データのための送信バッファを記憶装置から確保するステップと、ドライバが、上位プロセスから受けた送信データを前記送信バッファに格納するステップと、前記ドライバが、前記送信データが格納された送信バッファを送信バッファ待ち行列に追加するステップと、オフロード・エンジンが、前記送信バッファ待ち行列に１以上の送信バッファが在ることを検出すると、前記送信バッファ待ち行列に在る各送信バッファに格納された送信データを、送信バッファ待ち行列に在る送信バッファの順に、前記ネットワーク上に送信するステップと、前記オフロード・エンジンが、送信済みの前記送信データが格納されていた各送信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するステップと、前記ドライバが、前記通知用待ち行列に在る送信バッファを前記記憶装置に開放するステップと、を備えることを特徴とする方法が提供される。

上記の方法において、前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設けるステップと、前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設けるステップと、を更に備えるようにしてもよい。

上記の方法において、前記ドライバが、前記送信バッファへの前記送信データの格納に成功した場合に、その成功の旨を前記上位プロセスに通知するステップを更に備えるようにしてもよい。

上記の方法において、前記ドライバが、前記送信バッファ待ち行列に追加した前記送信バッファに対応したエントリが前記通知用待ち行列にない場合に、その旨をドライバの外部に通知するステップを更に備えるようにしてもよい。

本発明の第２の観点によれば、データをネットワークから受信する方法であって、ドライバが、受信データのための受信バッファを記憶装置から確保するステップと、前記ドライバが、前記受信バッファを受信バッファ待ち行列に追加するステップと、オフロード・エンジンが、前記ネットワークから受けた受信データを、前記受信バッファ待ち行列に在る前記受信バッファに、受信バッファ待ち行列に在る受信バッファの順に、格納するステップと、前記オフロード・エンジンが、受信済みの前記受信データが格納されていた各受信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するステップと、前記ドライバが、前記通知用待ち行列に在る受信バッファに在る受信データを、受信通知用待ち行列に在る受信バッファの順に、前記上位プロセスに渡すステップと、を備えることを特徴とする方法が提供される。

また、上記の方法において、前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設けるステップと、前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設けるステップと、を更に備えるようにしてもよい。

本発明によれば、前記オフロード・エンジンが、送信済みの前記送信データが格納されていた各送信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するので、複数の上位プロセスの間で影響を及ぼし合うことを防止できる。

また、本発明によれば、 前記オフロード・エンジンが、受信済みの前記受信データが格納されていた各受信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するので、複数の上位プロセスの間で影響を及ぼし合うことを防止できる。

以下、図面を参照して本発明を実施するための最良の形態について詳細に説明する。

近年、複数のＣＰＵが搭載されたホストマシンがある。また、複数のコアが搭載されたＣＰＵがある。このような複数ＣＰＵのホストマシンや、このような複数コアのＣＰＵ上では、複数のプロセスを同時に実行することができる。ＴＯＥ上でデータ送信が完了したことを知らせたり、受信データを一時保持するための待ち行列（以下、「通知用待ち行列」という。）を最大で上位プロセスの数だけ搭載し、上位プロセスを複数のＣＰＵ又は複数コアＣＰＵで同時に動作できるようにすることで、送受信の多重度を上げ性能を向上させる。また、上述したような、上位プロセス間の通信量の違いにより、一方の上位プロセスが他方の上位プロセスの通信を阻害するという問題は、各上位プロセス毎に別々の通知用待ち行列を利用することで解消できる。

次に、本発明の実施形態の構成について図面を参照して詳細に説明する。

［実施形態１］
図１を参照すると、本発明の第１の実施形態では、プログラム制御により動作するコンピュータ１００は、ＴＯＥ１０１と、ＴＯＥ１０１をドライブするＴＯＥドライバ（ソフトウェア）１０２と、ＴＯＥドライバを利用する上位プロセス（ソフトウェア）１０３及び記憶装置１０４を備える。

図２を参照すると、ＴＯＥ１０１は、ハードウェア（以降、「ＴＯＥハードウェア」という。）１０１−１とファームウェア（以降、「ＴＯＥファームウェア」という。）１０１−２を備える。ＴＯＥファームウェア１０１−２は、ＴＯＥハードウェア１０１−１の制御を行う。特に、ＴＯＥファームウェア１０１−１とＴＯＥハードウェア１０１−２は、送受信データ記憶部１０４−３（図３参照）にある送信データをネットワーク上に送信し、ネットワークからの受信データを送受信データ記憶部１０４−３に格納する。また、これらは、ＩＰに関連した処理を行なう。

また、ＴＯＥ１０１は、通知用待ち行列１０１−３を複数備える。各通知用待ち行列１０１−３は、各上位プロセス１０３に対応する。但し、各通知用待ち行列１０１−３に複数の上位待ち行列を対応させることを絶対的に排除する必要はない。この対応関係は、ＴＯＥドライバ１０２により生成され、オフロード通信制御記憶部１０４−１（図１参照）に格納される。

図３を参照すると、通知用待ち行列１０１−３の各エントリは、記憶装置１０４から確保した送受信制御記憶部１０４−２と、記憶装置１０４から確保した送受信データ記憶部１０４−３を備える。送受信制御記憶部１０４−２は、次のエントリへのポインタ（＊ｎｅｘｔ）と、送受信データ記憶部１０４−３へのポインタ（＊ｂｕｆ）を備える。但し、待ち行列を形成するためのリストの生成方法は、これに限られるわけではない。

ＴＯＥドライバ１０２には、送信バッファ待ち行列１０２−４（図４参照）と受信バッファ待ち行列１０２−３（図４参照）が備わる。なお、これらのバッファは、物理的には、記憶装置１０４に設けられる。送信バッファ待ち行列１０２−４と受信バッファ待ち行列１０２−３も、図３に示すような構造を有する。

送信バッファ待ち行列１０２−４の各エントリである送信バッファは、上位プロセスから受けた送信データを、ＴＯＥ１０１が送信するまで、一時的に保持するものである。また、データ送信が完了した後には、送信バッファは、送信バッファ待ち行列１０２−４から削除され、上位プロセスに対応する通知用待ち行列１０１−３に追加される。つまり、送信バッファは、送信バッファ待ち行列１０２−４から通知用待ち行列１０１−３に移動する。通知用待ち行列１０１−３に追加されたエントリは、先頭から順々に廃棄され、それが占有していた領域は、記憶装置１０４に戻される。ＴＯＥドライバ１０２は、通知用待ち行列１０１−３のエントリを先頭から調べることにより、上位プロセスから要求されたとおりに、データを送信できたか否かを知ることができる。できていない場合には、例えば、該当する上位プロセスやオペレーティングシステムに送信失敗の旨を通知するようにしてもよい。

また、ＴＯＥドライバ１０２は、上位プロセスから受けた送信データを格納した送信バッファが送信バッファ待ち行列１０２−４にあるか否かを、送信レジスタ１０１−４（図４参照）を介して、ＴＯＥ１０１に伝える。ＴＯＥ１０１は、送信レジスタ１０１−４を調べて、送信データがあることを認識したならば、データ送信をして、送信バッファを送信バッファ行列１０２−４から通知用待ち行列１０２−３に移す。移動先の通知用待ち行列１０１−３は、該当する上位プロセスに対応したものである。この対応関係は、オフロード通信制御記憶部１０４−１に格納されているので、ＴＯＥファームウェア１０１−１は、これを参照して、移動先の通知用待ち行列１０１−３を知る。

受信バッファ待ち行列１０２−３の各エントリである受信バッファは、受信したデータを格納する。受信バッファは、データ受信をする前に予め作成されて、受信バッファ待ち行列１０２−３に追加されている。そして、実際に、ＴＯＥ１０１がデータを受信すると、受信バッファ待ち行列１０２−３の先頭にある１以上の受信バッファに受信データが格納される。その後、ＴＯＥファームウェア１０１−１は、受信データが格納された受信バッファを、受信バッファ待ち行列１０２−３から通知用待ち行列１０１−３に移す。移動先の通知用待ち行列１０１−３は、該当する上位プロセスに対応したものである。この対応関係は、オフロード通信制御記憶部１０４−１に格納されているので、ＴＯＥファームウェア１０１−１は、これを参照して、移動先の通知用待ち行列１０１−３を知る。

図１に戻ると、ＴＯＥドライバ１０２は、ＴＯＥ１０１と上位プロセス１０３との間のデータの橋渡しをする。ＴＯＥドライバ１０２は通信制御部１０２−１と、送受信制御部１０２−２を備える。通信制御部１０２−１は、ＴＯＥ１０１でのオフロード通信に必要な情報を制御する。送受信制御部１０２−２は、上位プロセス１０３からの送信要求をＴＯＥファームウェア１０１−１へ伝えるオフロード送信機能と、ネットワーク１１１から受け取りＴＯＥファームウェア１０１−１によりオフロード処理されたデータを受け取るオフロード受信機能とを備える。

送受信制御部１０２−２は、通知用待ち行列監視プロセスを行なう。この通知用待ち行列監視プロセスは、ＴＯＥファームウェア１０１−１から通知用待ち行列１０１−３経由で受けた送信バッファ又は受信バッファを処理する。

通信制御部１０２−１は、実際のオフロード通信を制御する情報を収めたオフロード通信制御記憶部１０４−１を利用する。オフロード通信制御記憶部１０４−１には、上位プロセスの識別情報と通知用待ち行列の識別情報との対応関係が格納されている。

上位プロセス１０３はオフロード通信を利用するプログラムであり、ＴＯＥドライバ１０２との間で送信要求と受信通知をやりとりする。

記憶装置１０４は、送受信に必要な記憶領域を備える。記憶装置１０４が、ＴＯＥドライバ１０２又は上位プロセス１０３からメモリ領域の確保の要求を受けた時に、記憶装置１０４に記憶領域が確保され、その記憶領域へのポインタがＴＯＥドライバ１０２、ＴＯＥ１０１又は上位プロセス１０３に渡される。記憶装置１０４が、ＴＯＥドライバ１０２又は上位プロセス１０３からメモリ領域の開放の要求を受けた時に、実在する記憶領域が開放される。

次に、図１、図５、図６及び図７等を参照して本発明の第１の実施形態の動作について詳細に説明する。

まず、図１及び図５等を参照して、オフロード機能を利用するソケットの作成について説明する。

まず、上位プロセス１０３は、ＴＯＥドライバ１０２に対して、ソケット作成を要求する（ステップＳ００１）。

次に、ＴＯＥドライバ１０２は、ＴＯＥ１０１でのオフロード通信のために必要な情報（ＩＰアドレス、ポート番号など）を、上位プロセス１０３から受けたパケットやソケットから収集する。この時、更に、送信完了時と受信通知時にＴＯＥファームウェア１０１−１から通知してもらいたい通知用待ち行列１０１−３の番号＃ｎを決定する（ステップＳ００２）。一例として、上位プロセスから受けたソースポート番号に応じて通知用待ち行列１０１−３の番号＃ｎを決定する。ＴＣＰ／ＩＰでのサーバ型プロセスは、それが持つポート番号が定まっているため、このように通知用待ち行列１０１−３の番号＃ｎを決定すれば、個々の上位プロセス１０３で使用する通知用待ち行列の番号＃ｎが一意に決定される。なお、ポート番号を表すために用いられている全てのビットのうちの一部のビットのみを抜き出して、これを通知用待ち行列１０１−３の番号＃ｎとしてもよい。もしも、上位プロセスの数が通知用待ち行列の数と等しいのであれば、異なった上位プロセスが、異なった番号の通知用待ち行列を利用することが理想的である。しかし、上位プロセスの数が通知用待ち行列の数を超えるのであれば、一部の複数の上位プロセスが共通の通知用待ち行列を利用することを避けることができない。しかし、このような場合であっても、従来技術の問題点はかなり解消される。ポイントは、従来技術では、Ｎ個の上位プロセスが１つの通知用待ち行列を共用していたのに対し、本発明では、理想的には、Ｎ個の上位プロセスがＮ個の通知用待ち行列を利用し、そうでなくても、Ｎ個の上位プロセスがＭ（Ｍは２以上且つＮ未満）個の通知用待ち行列を利用することである。

新たな通信制御記憶部１０４−１が生成される。そして、これらの情報（ＴＯＥ１０１でのオフロード通信のために必要な情報（ＩＰアドレス、ポート番号など）、通知用待ち行列１０１−３の番号＃ｎ、上位プロセスの識別情報等）は、生成されたオフロード通信制御記憶部１０４−１へ格納される（ステップＳ００３）。

最後に、ＴＯＥファームウェア１０１−１へ、オフロード通信制御記憶部１０４−１へのポインタが通知される（ステップＳ００４）。これにより、ＴＯＥファームウェア１０１−１は、上位プロセスと通知用待ち行列１０１−３と送受信するＩＰパケットのソケット情報との対応関係を知ることが可能となる。

次に、図１及び図６等を参照して、オフロード送信と送信完了処理について説明する。

上位プロセス１０３が、ＴＯＥドライバ１０２に対して、送信要求を出すことにより送信処理が開始される。

ＴＯＥドライバ１０２は、送信データをＴＯＥファームウェア１０１−１が解釈できる形式にするために、送信制御記憶部１０４−２を記憶装置１０４に確保する（ステップＳ２０１）。これは、送信バッファの一部を構成する。なお、送受信制御記憶部１０４−２は、送信時には、送信制御記憶部と呼ばれ、受信時には、受信制御記憶部と呼ばれる。同様に、送受信データ記憶部１０４−３は、送信時には、送信データ記憶部と呼ばれ、受信時には、受信データ記憶部と呼ばれる。

次に、送受信制御記憶部１０４−２に、実際に送信するデータを格納する送受信データ記憶部１０４−３へのポインタなどの、送信に必要な情報を格納する（ステップＳ２０２）。なお、送受信データ記憶部１０４−３は既に生成されており、ステップＳ２０１の段階で、既に送信データが格納されている。

その後、新たな送受信制御記憶部１０４−２を既に在る送信制御記憶部１０４−２に接続する（ステップＳ２０３）。これが、送信バッファキューへの送信バッファの追加に該当する。そして、新たな送受信制御記憶部１０４−２を接続したことをＴＯＥ１０１へ通知するために、ＴＯＥ１０１に在る送信レジスタ１０１−４（図４参照）の記憶内容を変化させる。例えば、送信レジスタ１０１−４が送信バッファ待ち行列１０２−４にあるエントリ数を表すのであれば、その数を１だけ増加させる。送信レジスタ１０１−４が送信バッファ待ち行列１０２−４に１以上のエントリ数があるか否かを表すのであり、これまでにエントリが無いのであれば、あることを示す値に変化させる。すでにエントリがあるのであれば、あることを示す値を維持する。

ＴＯＥファームウェア１０１−１は、送信データが格納された送受信バッファがきたことを認識した後、送信処理をする。それにより、ネットワーク上へ送信データが流れる（ステップＳ２０４）。この時、オフロード通信制御記憶部１０４−１に格納されているソケット情報が利用される。

データの送信が終了したならば、ＴＯＥファームウェア１０１−１は、送信が完了したことをＴＯＥドライバ１０２へ通知するために、通知用待ち行列１０１−３へ、使用した送信バッファ１０４−２、１０４−３を、既に在るエントリに追加する。この時追加の対象となる通知用待ち行列１０１−３は、オフロード通信制御部１０４−１で指定された通知用待ち行列１０１−３である（ステップＳ２０５）。

通知用待ち行列１０１−３を監視しているＴＯＥドライバ１０２（通知用待ち行列監視プロセス）は、新たなエントリが通知用待ち行列１０１−３に接続されたことを認識すると、そのエントリを通知用待ち行列１０１−３から削除し、送信バッファを記憶領域へ開放する。

次に、図１及び図７等を参照して、オフロード受信処理について説明する。

ネットワーク上から受信データを受け取るとＴＯＥ１０１は、受信バッファ待ち行列１０２−３（図４参照）から、受信バッファを取り出す（ステップＳ１０１）。取り出した受信バッファへ受け取ったデータを格納する（ステップＳ１０２）。

受信データを受信バッファに格納し終えたＴＯＥファームウェア１０１−１は、ＴＯＥドライバ１０２に対してデータを受信したことを通知するため通知用待ち行列へ受信バッファ１０４−３を含むエントリを追加する。この時の接続先の通知用待ち行列１０１−３は、オフロード通信制御記憶部１０４−１で指定された通知用待ち行列である（ステップＳ１０３）。

通知用待ち行列１０１−３を監視していた通知用待ち行列監視プロセス（送受信制御部１０２−２により行なわれている。）は、送受信バッファ１０４−３を含む新しいエントリが新しく通知用待ち行列１０１−３に接続されたことを確認する。そして、通知用待ち行列監視プロセスは、その受信バッファ１０４−３内の受信データを上位プロセス１０３へ届ける（ステップＳ１０４）。

上位プロセス１０３へ受信バッファ内の受信データを届けることに成功すると、使用済みとなった送受信制御記憶部１０４−２は記憶装置へ開放される（ステップＳ１０５）。

また、ＴＯＥドライバ１０２は、新たな受信に備えるために、新しい受信バッファ（受信制御記憶部１０４−２と受信データ記憶部１０４−３）を記憶領域から確保し、これらにより構成される新しい受信バッファを受信バッファ待ち行列１１０２−３へ接続する。そして、ＴＯＥドライバ１０２は、新しい受信バッファを受信バッファ待ち行列１０２−３に追加したことを、受信レジスタ１０１−５を通して、ＴＯＥ１０２へ通知する（ステップＳ１０６）。

ここで、サーバ型の上位プロセスを考慮した一連の動作例を図４、図８及び図９を参照して説明する。つまり、このコンピュータは、ＮＦＳ又はＣＩＦＳを利用したファイルサーバであるとして説明をする。ファイルサーバは、図４では、ファイルのダウンロード又はアップロードの要求を受け（ＩＰパケットを受信し）、図８では、その要求に応じて、所定の処理をはさんだ後に、ファイルをダウンロードし（ＩＰパケットを送信し）、図９では、その要求に応じて、所定の処理をはさんだ後に、ファイルをアップロードする（ＩＰパケットを受信する）。

なお、図４、図８及び図９では、ＴＯＥドライバ１０２が、記憶装置１０４へ要求して、これにより確保した記憶部（受信バッファ、送信バッファ、通知用待ち行列等）をＴＯＥドライバ１０２の内部及びＴＯＥ１０１の内部に記述している。物理的には、これらの記憶部は、記憶装置１０４の内部にある。

図４を参照すると、ネットワーク上のクライアントから或る要求が来たとする（Ｒ１）。或る要求とは、ファイルのダウンロード又はアップロード等の要求である。この要求は、ＩＰパケットの形態で来る。

受信データを受け取ったＴＯＥ１０１は、受信バッファ待ち行列１０２−３から先頭の受信バッファを取り出す（Ｒ１３）。なお、データ受信の準備のために、ドライバの初期化時に前もって受信バッファを記憶装置１０４から確保して受信バッファ待ち行列１０２−３を作成している（Ｒ１１、Ｒ１２）。

ＴＯＥファームウェア１０１−１は、受信データを受信バッファの受信データ記憶部１０４−３へ格納し、受信のための制御情報を受信制御記憶部１０４−２へ格納する（Ｒ１３−１）。次に、ＴＯＥファームウェア１０１−１は、上位プロセス１０３に対応したオフロード通信制御記憶部１０４−１を覗き、受信バッファの受信データ記憶部１０４−３に格納された受信データを、どの通知用待ち行列１０１−３に連結するべきか確認する。ここでは、該当する通知用待ち行列は、オフロード通信制御記憶部１０４−１（ＰＣＢ＃１）を覗くと通知用待ち行列 ＃０なので、通知用待ち行列＃０に対し、受信バッファの受信制御記憶部１０４−２を連結する（Ｒ１３−２）。

通知用待ち行列 ＃０を監視している送受信制御部１０２−２によるＣＱ監視プロセス＃１は、受信バッファが通知用待ち行列 ＃０に連結されたことを知ると、上位プロセス＃１へ、受信データを渡す（Ｒ１４）。受信に使用した受信バッファは用済みとなるので、記憶装置１０４へ開放される。

上位プロセス＃１は、受信したデータを分析し、通信を行わせる別プロセスである上位プロセス＃２を生成する（図８又は図９参照）。

上位プロセス＃１は、以後の通信は、この上位プロセス＃２に行わせ、自分は要求の受付に専念する。

図８の例では、上位プロセス＃２は、ＩＰパケットの送信を行なう。

図８を参照すると、上位プロセス＃２は、オフロード通信を行うためのソケットを作成する。この時、上位プロセス＃２は、通知用待ち行列＃１を利用したいので、オフロード通信制御記憶部１０４−１ ＰＣＢ＃２に通知用待ち行列＃１を割り当てる。通信に必要なソケットを作成した後、上位プロセス＃２から、送信要求がＴＯＥドライバ１０２になされる（図８のＴ１１）。

送信要求を受け付けたＴＯＥドライバ１０２は、記憶装置１０４から送信制御記憶部１０４−２を確保し（Ｔ１２）、ＴＯＥファームウェア１０１−１が理解できる制御データを作成し、それを送信制御記憶部１０４−２に格納する。その後、送信バッファ待ち行列１０２−４に送信制御記憶部１０４−２を接続する（Ｔ１３）。なお、ＴＯＥドライバ１０２は、送信データを上位プロセス＃２から受けており、これを送信制御記憶部１０４−２のポインタ（＊ｂｕｆ）で示される送信データ記憶部１０４−３に格納している。

送信バッファ待ち行列１０２−４へ送信制御記憶部１０４−２を追加した後、その追加の旨を、送信レジスタ１０１−４を通じてＴＯＥファームウェア１０１−１に知らせる。ＴＯＥファームウェア１０１−１は、送信バッファ待ち行列１０２−４から送信すべきデータを取り出して、ネットワーク上へパケットを送信する（Ｔ１４−１）。

その後、ＴＯＥファームウェア１０１−１は、送信バッファを通知用待ち行列１０１−３へ連結する。この時、オフロード通信制御記憶部１０４−１（ＰＣＢ＃２）の中身を見て、送信バッファをどの通知用待ち行列に接続するか確認する（Ｔ１４−２）。この例では、ＴＯＥファームウェア１０１−１は、送信バッファを通知用待ち行列 ＃２へ連結する。通知用待ち行列 ＃２を監視していた監視プロセス＃２は、送信バッファが通知用待ち行列 ＃２に連結されたことを知った後、記憶領域へ使用済みの領域を開放する。

図９の例では、上位プロセス＃２は、ＩＰパケットの受信を行なう。図９に示す例は、図４に示す例と同様である。図９に示す例の図４に示す例との相違点は下記の通りである。

図４に示す例では、上位プロセス＃１に対応するのは、オフロード通信制御記憶部１０４−１（ＰＣＢ＃１）、通知用待ち行列１０１−３ Ｑ＃０であるのに対し、図９に示す例では、上位プロセス＃２に対応するのは、オフロード通信制御記憶部１０４−１ ＰＣＢ＃２、通知用待ち行列１０１−３ Ｑ＃１である。
以上のように通知用待ち行列をプロセスに応じて使い分けることができる。

次に、本発明の第１の実施形態の効果について説明する。

本発明の第１の実施形態では、複数の通知用待ち行列を各上位プロセス毎に使用するように構成されているため、ＴＯＥファームウェア１０１−１から上位プロセスへの通知処理が並列に動作できる。

また、本発明の第１の実施形態では、さらに、ポート番号に応じて、使用する通知用待ち行列を決定しているため、次のようなケースでは通信性能の確保ができる。つまり、上位プロセスにＮＦＳ，ＣＩＦＳの２つを利用しており、通知用待ち行列 Ｑ＃１にＮＦＳを通知用待ち行列 Ｑ＃２にＣＩＦＳを使うようにする。ＮＦＳで使用する割合が非常に高いが、ＣＩＦＳの通信性能を確保しておきたい場合にこのような形態を利用できる。通知用待ち行列がＮＦＳとＣＩＦＳとの間で分離されており、従って、互いに相手の通信に影響を与えないため、両者の通信品質を確保することができる。

［実施形態２］
次に、本発明の第２の実施形態の構成について図面を参照して詳細に説明する。

実施形態２の構成は、実施形態１の構成と同一である。両実施形態は、ソケット作成時の動作が異なる。したがって、コンピュータ１００、ＴＯＥ１０１、ＴＯＥドライバ１０２、上位プロセス１０３及び記憶装置１０４は実施形態１と同じ動作を行う。

ソケット作成時の動作を図１０を用いて説明する。

通常のソケット作成時（ステップＳ３０１）において、ＴＯＥドライバ１０２は、ＴＯＥ１０１でのオフロード通信に必要な情報（ＩＰアドレス、ポート番号等）をパケットやソケットから収集する。この時、ＴＯＥドライバ１０２は、送信完了時と受信通知時にＴＯＥファームウェア１０１−１から通知されることを希望する通知用待ち行列の番号を決定する（ステップＳ３０２）。本実施形態では相手先ＩＰアドレスと相手先ポート番号を基にして、通知用待ち行列の番号の値がランダムになるような計算方法（例えば、ハッシュ関数を利用した計算方法）を用いて、通知用待ち行列の番号の値を算出し、その番号を決定された番号とする。これにより、使用する通知用待ち行列の番号をランダムに分布させ、これにより、通知用待ち行列処理を限りなく並列処理に近く動作させることが可能となる。

ちなみに、偶然に、別々の上位プロセスが同一の通知用待ち行列を利用するようになった場合には、上位プロセス間での相互影響が全くないという効果を得ることができなくなる。しかし、そのような場合であっても、ＴＯＥドライバは各上位プロセスをＩＰアドレスとポート番号により識別しているので、同一の通知用待ち行列からの各バッファ内のデータを適切な上位プロセスに渡すことができる。

図１０に示すステップＳ３０３、Ｓ３０４は、それぞれ、図５に示すステップＳ００３、Ｓ００４と同一であるので、これらの説明を省略する。

次に、本発明の第２の実施形態の効果について説明する。

本発明の第２の実施形態では、使用する通知用待ち行列の番号が限りなくランダムに近くなるようにできるので、送受信処理を並列して行なうことができる。従って、複数ＣＰＵのホストマシンや、複数コアのＣＰＵ上での、複数のプロセスの同時実行に効率的に対応することが可能となる。

本発明の実施形態によるコンピュータの構成を示すブロック図である。 図１に示すＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅの構成を示すブロック図である。 本発明の実施形態による通知用待ち行列、送信バッファ待ち行列及び受信バッファ待ち行列の構成を示す図である。 本発明の実施形態によるコンピュータの上位プロセス＃１がパケットを受信する場合の動作を示す図である。 本発明の実施形態によるコンピュータの実施形態１によるソケット作成時の動作を示すフローチャートである。 本発明の実施形態によるコンピュータのオフロード送信処理時の動作を示すフローチャートである。 本発明の実施形態によるコンピュータのオフロード受信処理時の動作を示すフローチャートである。 本発明の実施形態によるコンピュータの上位プロセス＃２がパケットを送信する場合の動作を示す図である。 本発明の実施形態によるコンピュータの上位プロセス＃２がパケットを受信する場合の動作を示す図である。 本発明の実施形態によるコンピュータの実施形態２によるソケット作成時の動作を示すフローチャートである。

符号の説明

１０１ ＴＯＥ（ＴＣＰ／ＩＰ Ｏｆｆｌｏａｄ Ｅｎｇｉｎｅ）
１０２ ＴＯＥドライバ
１０３ 上位プロセス
１０４ 記憶装置

Claims (12)

1. データをネットワークに送信する方法であって、
   ドライバが、送信データのための送信バッファを記憶装置から確保するステップと、
   ドライバが、上位プロセスから受けた送信データを前記送信バッファに格納するステップと、
   前記ドライバが、前記送信データが格納された送信バッファを送信バッファ待ち行列に追加するステップと、
   オフロード・エンジンが、前記送信バッファ待ち行列に１以上の送信バッファが在ることを検出すると、前記送信バッファ待ち行列に在る各送信バッファに格納された送信データを、送信バッファ待ち行列に在る送信バッファの順に、前記ネットワーク上に送信するステップと、
   前記オフロード・エンジンが、送信済みの前記送信データが格納されていた各送信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するステップと、
   前記ドライバが、前記通知用待ち行列に在る送信バッファを前記記憶装置に開放するステップと、
   を備えることを特徴とする方法。
2. 請求項１に記載の方法において、
   前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設けるステップと、
   前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設けるステップと、
   を更に備えることを特徴とする方法。
3. 請求項１に記載の方法において、
   前記ドライバが、前記送信バッファへの前記送信データの格納に成功した場合に、その成功の旨を前記上位プロセスに通知するステップを更に備えることを特徴とする方法。
4. 請求項１に記載の方法において、
   前記ドライバが、前記送信バッファ待ち行列に追加した前記送信バッファに対応したエントリが前記通知用待ち行列にない場合に、その旨をドライバの外部に通知するステップを更に備えることを特徴とする方法。
5. データをネットワークから受信する方法であって、
   ドライバが、受信データのための受信バッファを記憶装置から確保するステップと、
   前記ドライバが、前記受信バッファを受信バッファ待ち行列に追加するステップと、
   オフロード・エンジンが、前記ネットワークから受けた受信データを、前記受信バッファ待ち行列に在る前記受信バッファに、受信バッファ待ち行列に在る受信バッファの順に、格納するステップと、
   前記オフロード・エンジンが、受信済みの前記受信データが格納されていた各受信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加するステップと、
   前記ドライバが、前記通知用待ち行列に在る受信バッファに在る受信データを、受信通知用待ち行列に在る受信バッファの順に、前記上位プロセスに渡すステップと、
   を備えることを特徴とする方法。
6. 請求項５に記載の方法において、
   前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設けるステップと、
   前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設けるステップと、
   を更に備えることを特徴とする方法。
7. データをネットワークに送信する装置であって、
   ドライバが、送信データのための送信バッファを記憶装置から確保する手段と、
   ドライバが、上位プロセスから受けた送信データを前記送信バッファに格納する手段と、
   前記ドライバが、前記送信データが格納された送信バッファを送信バッファ待ち行列に追加する手段と、
   オフロード・エンジンが、前記送信バッファ待ち行列に１以上の送信バッファが在ることを検出すると、前記送信バッファ待ち行列に在る各送信バッファに格納された送信データを、送信バッファ待ち行列に在る送信バッファの順に、前記ネットワーク上に送信する手段と、
   前記オフロード・エンジンが、送信済みの前記送信データが格納されていた各送信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加する手段と、
   前記ドライバが、前記通知用待ち行列に在る送信バッファを前記記憶装置に開放する手段と、
   を備えることを特徴とする装置。
8. 請求項７に記載の装置において、
   前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設ける手段と、
   前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設ける手段と、
   を更に備えることを特徴とする装置。
9. 請求項７に記載の装置において、
   前記ドライバが、前記送信バッファへの前記送信データの格納に成功した場合に、その成功の旨を前記上位プロセスに通知する手段を更に備えることを特徴とする装置。
10. 請求項７に記載の装置において、
    前記ドライバが、前記送信バッファ待ち行列に追加した前記送信バッファに対応したエントリが前記通知用待ち行列にない場合に、その旨をドライバの外部に通知する手段を更に備えることを特徴とする装置。
11. データをネットワークから受信する装置であって、
    ドライバが、受信データのための受信バッファを記憶装置から確保する手段と、
    前記ドライバが、前記受信バッファを受信バッファ待ち行列に追加する手段と、
    オフロード・エンジンが、前記ネットワークから受けた受信データを、前記受信バッファ待ち行列に在る前記受信バッファに、受信バッファ待ち行列に在る受信バッファの順に、格納する手段と、
    前記オフロード・エンジンが、受信済みの前記受信データが格納されていた各受信バッファを、各上位プロセスと各通知用待ち行列の対応関係に関する情報を参照して、前記上位プロセスに対応する通知用待ち行列に追加する手段と、
    前記ドライバが、前記通知用待ち行列に在る受信バッファに在る受信データを、受信通知用待ち行列に在る受信バッファの順に、前記上位プロセスに渡す手段と、
    を備えることを特徴とする装置。
12. 請求項１１に記載の装置において、
    前記ドライバが、各上位プロセスに対応する各通知用待ち行列を設ける手段と、
    前記ドライバが、各上位プロセスと各通知用待ち行列の対応関係に関する情報を設ける手段と、
    を更に備えることを特徴とする装置。

Images