JP4317348B2 - 情報処理装置及び入出力方法並びにプログラム - Google Patents
情報処理装置及び入出力方法並びにプログラム Download PDFInfo
- Publication number
- JP4317348B2 JP4317348B2 JP2002139572A JP2002139572A JP4317348B2 JP 4317348 B2 JP4317348 B2 JP 4317348B2 JP 2002139572 A JP2002139572 A JP 2002139572A JP 2002139572 A JP2002139572 A JP 2002139572A JP 4317348 B2 JP4317348 B2 JP 4317348B2
- Authority
- JP
- Japan
- Prior art keywords
- adapter
- state
- processes
- scheduler
- interrupt
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Expired - Fee Related
Links
Images
Classifications
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L47/00—Traffic control in data switching networks
- H04L47/50—Queue scheduling
- H04L47/62—Queue scheduling characterised by scheduling criteria
- H04L47/625—Queue scheduling characterised by scheduling criteria for service slots or service orders
-
- H—ELECTRICITY
- H04—ELECTRIC COMMUNICATION TECHNIQUE
- H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
- H04L49/00—Packet switching elements
- H04L49/90—Buffering arrangements
Landscapes
- Engineering & Computer Science (AREA)
- Computer Networks & Wireless Communication (AREA)
- Signal Processing (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Description
【０００１】
【発明の属する技術分野】
本発明は入出力アダプタ、特にディスク装置、ネットワーク等を、コンピュータ等に接続し、そのディスク装置やネットワークに使用するプロトコルを処理するアダプタに関する。
【０００２】
【従来の技術】
ディスク接続方法やネットワークは、複数の種類が存在し、イーサネット（登録商標）、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ、ＡＴＭ、パラレルＳＣＳＩがその例である。
【０００３】
これらのディスク接続方法やネットワークをホスト（コンピュータ）等の情報処理装置に接続するとき、ホストの内部Ｉ／Ｏバスと、ディスク接続方法やネットワークを結ぶアダプタを使用する。
【０００４】
パーソナルコンピュータにおいては、ＰＣＩバスとイーサネットを結ぶネットワークアダプタがそのアダプタの一例である（ＰＣＩバスのコネクタに接続するカードという形式のアダプタが良くあるが、マザーボードにこれらのコンポーネントを直接組み付ける例もあり、この場合にもアダプタと呼ぶ）。
【０００５】
図６を使用してコンピュータシステムのアダプタ、そしてオペレーティングシステム（以下、ＯＳ）のカーネルとプロセスの動作を説明する。
【０００６】
本願明細書では、説明を分かりやすくするためにネットワークアダプタ、そしてネットワークでの通信に極めて一般的に使用されているＴＣＰ／ＩＰプロトコル（W. Richard Stevens, “UNIX Network Programming,” Prentice Hall, U.S.A., 1990, ISBN 0-13-949876-1参照、以下参考文献１と呼ぶ）の通信の場合を中心に説明する。そして、ＴＣＰ／ＩＰで通信するためのソケットＡＰＩ（Application Programming Interface、プロセスがコンピュータやオペレーティングシステムのある機能を用いるために呼び出す関数の集合）を例に使用する（参考文献１参照）。また、ＯＳとしてはＬｉｎｕｘカーネル（D. P. Bovet, M. Cesati, “Understanding the Linux Kernel,” O’Reilly & Associates, 2001, ISBN 0-596-00002-2参照、以下参考文献２と呼ぶ）を例にすることがある。なお、本発明においてはネットワークアダプタ、ＴＣＰ／ＩＰプロトコル、ソケットＡＰＩやＬｉｎｕｘカーネルに制限されるものではない。
【０００７】
まず、図６の場合、ホスト１の複数のプロセス（プログラム）３１、３２がアダプタ２を使用して通信する（図６と今後の図にネットワーク上の通信相手を図示しない）。カーネル４は、アダプタ２を制御し、プロセス３１、３２のデータと制御の多重化（マルチプレクシング、デマルチプレクシング）をする。次にこの多重化を説明する。
【０００８】
まず、データの多重化について説明する。アダプタ２は複数のプロセス３１、３２のデータをまとめて送受信するため、カーネル４はバッファ４５を介して複数プロセス３１、３２とアダプタ２の間でデータの多重化を行う。まず、受信処理について説明する。アダプタ２はネットワークからパケットを受信したとき、そのパケットをカーネル４のバッファ４５に書き込む（アダプタは、ＤＭＡで主記憶の書き込み／読み出しができる）。
【０００９】
そして、アダプタ２が受信完了のときに割り込みを起こし、その割り込みを、このアダプタ２の割り込み処理４７のコードが処理し、デバイスドライバ４６を呼び出す。デバイスドライバ４６がバッファ４５を読み出し、パケットの通信プロトコルを調べ、このプロトコル（この例ではＴＣＰ／ＩＰ）のプロトコル処理４３を呼び出す。
【００１０】
ＴＣＰ／ＩＰでは、予め確立された論理接続の上でデータを通信する。プロトコル処理４３はＴＣＰ／ＩＰ処理を行うために、通信の状態の管理と、論理接続とプロセスとの連携などを記録するプロトコル処理表４４を持つ。プロトコル処理４３は、受信したデータの宛先となるプロセス３１、３２を調べ、このデータをこのプロセス３１、３２のバッファ３３、３４にそれぞれコピーし、受信したデータのバッファ４５の領域を開放し、受信処理を完了する。
【００１１】
送信処理はほぼ逆方向の処理を行う。まず、プロセス３１、３２が送信データ３３、３４を指定してプロトコル処理４３を呼び出す。プロトコル処理４３がそのデータ３３、３４をバッファ４５にコピーし、このバッファ４５上でパケットを組み立て、デバイスドライバ４６を呼び出す。デバイスドライバ４６がアダプタ２を制御し、パケットを送信させる。送信が完了したとき、アダプタ２が割り込みを起こし、この割り込みを割り込み処理４７と、デバイスドライバ４６が処理し、デバイスドライバ４６が送信されたパケットのバッファ４５の領域を開放する。
【００１２】
次にプロセス制御の多重化を説明する。図６において、アダプタ２は複数のプロセス３１、３２に関する割り込みをまとめて起こすため、カーネル４が各プロセス３１、３２のプロセス制御のために割り込みの多重化も行う（この処理は普段「多重化」と呼ばれないが、データの多重化との類似を指摘するためにこの明細書はこの用語を使用する）。
【００１３】
プロセス制御は主に、次に説明するプロセス状態の変更を行う。各プロセスは複数の状態があり、「実行中」（どれかのＣＰＵがこのプロセスを実行しているという状態）、「実行可能」（プロセスが実行できるが、ＣＰＵが実行していない状態）、「Ｉ／Ｏ待ち」（プロセスが送受信などの完了を待っている状態）がその例である（参考文献２参考。Ｌｉｎｕｘのプロセスはこれらの状態があるが、Ｌｉｎｕｘのtask#structの状態は上記の３つの状態に一対一対応しない）。
【００１４】
カーネル４が送受信時に各プロセス３１、３２の状態を管理し、プロセステーブル４２に状態を記録する。
【００１５】
図８に受信処理のタイムチャートを例にする。プロセス３１、３２がソケットＡＰＩのブロッキング呼び出し（データ受信完了まで待つ）を使用したとき、カーネル４のプロトコル処理４３が呼ばれる（８００）。プロトコル処理４３ではデータが受信されていない場合、カーネル４のスケジューラ４１を呼び出し（８０１）プロセス３１、３２を実行中状態からＩ／Ｏ待ち状態に変更する。
【００１６】
アダプタ２はデータ受信完了のときに割り込みを起こす（８０２）。割り込み処理４７、デバイスドライバ４６とプロトコル処理４３が呼び出され（８０３、８０４）、プロトコル処理４３は上記受信処理の中でどのプロセス３１、３２がこの受信に対応するかを調べ、状態変更が必要である場合にスケジューラ４１を呼び出す（８０５）。スケジューラ４１がデータを送受信したプロセス３１、３２を実行可能状態にする。
【００１７】
その後（実行可能状態になった直後か、一つあるいは複数のタイマー５割込み（後述）の後）、このプロセス３１、３２が実行中状態となり（８０６）、受信処理を完了する（８０７）。
【００１８】
なお、送受信に関わらず、タイマー５が定期的に割り込みを起こし（Ｌｉｎｕｘでは１００Ｈｚ、参考文献１の１４０ページ参照）、タイマー処理４８の後にスケジューラが呼ばれ（参考文献１の１３３及び１４２ページ参照）、必要があればスケジューラ４１が実行可能と実行中プロセス３１、３２の中のどれを実行中、実行可能にするかを選択する。この処理でカーネルがタイムシェアリングを実現する。
【００１９】
近年、ネットワーク性能がサーバ処理能力を大きく上回って向上してきた結果、ＴＣＰ／ＩＰプロトコルの処理がボトルネックとして顕在化してきた。
【００２０】
その対策として、アダプタでのプロトコル処理の２つの方式、すなわちＴＣＰ／ＩＰのハードウェア化（J. Hufferd, “The Outboarding of TCP/IP," e-Commerce Infrastructure Technology Conference and Tradeshow, February 2001, Monterey, U.S.A.参照）と、論理接続などのＴＣＰ／ＩＰ相当の機能を独自プロトコルで実現するＩｎｆｉｎｉＢａｎｄネットワーク（InfiniBand Architecture Specification Volume 1 Release 1.0.a参照）が開発されてきた。
【００２１】
図７にＩｎｆｉｎｉＢａｎｄアダプタを例にしてプロトコルを処理するアダプタ６００を説明する。
【００２２】
このアダプタ６００は、論理接続の通信エンドポイント６１０〜６３０で、各論理接続の処理と通信状態の管理をする（ＩｎｆｉｎｉＢａｎｄでは、この通信エンドポイントをＱｕｅｕｅ Ｐａｉｒと呼び、以下ＱＰと略す）。
【００２３】
プロセス３１、３２がプロトコル処理４９とデバイスドライバ５０を介して論理接続を確立するが、確立後にカーネル４を介さないでエンドポイント６１０〜６３０を直接アクセスする（プロトコル処理４９、プロトコル処理表４０、デバイスドライバ５０はプロトコル処理４３、プロトコル処理表４４、デバイスドライバ４６と同等であるが、前者のプロトコル処理は後者のプロトコル処理を含めず、接続管理の機能のみを含む）。
【００２４】
そして、アダプタ６００はプロセス３１、３２のデータ３３、３４を直接送受信するために複数の通信エンドポイント６１０〜６３０の多重処理６４を行う。このため、アダプタ６００の場合、カーネル４でなく、アダプタ６００がデータの多重化を行う。
【００２５】
ＩｎｆｉｎｉＢａｎｄアダプタ６００を直接駆動するにはソケットと異なったＡＰＩを使用するが、ＩｎｆｉｎｉＢａｎｄ向けＡＰＩにもブロッキング呼び出しが存在すると考えられる（これらのＡＰＩは現在規格化中である）。
【００２６】
上記図７のＩｎｆｉｎｉＢａｎｄアダプタ６００における処理を、上記図８のタイムチャートを用いて説明すると、アダプタ６００がデータ送受信のプロトコル処理をするため、ブロッキング呼び出し（８００）のときにプロトコル処理４９がスケジューラ４１の呼び出しをする（変形例としてここでは、特別なシステムコールを設ければ、プロセス３１、３２が直接スケジューラを呼べる）。送受信完了のときにアダプタ６００が割込みを起こす（８０２）。
【００２７】
【発明が解決しようとする課題】
上記図７の従来例においては、プロトコルを処理するアダプタ６００は、データ送受信時にカーネル４をバイパスして、プロトコル処理４３のバイパス、そしてプロセス３１、３２のバッファ３３、３４とバッファ４５とのデータコピーをなくすことなどにより、ＣＰＵ負荷を削減し、通常のアダプタ２（図６）のボトルネックの一部を解決する。
【００２８】
しかしながら、プロトコルを処理するアダプタ６００がデータの多重化を処理する一方、制御の多重化を行っていない。例えば、プロセス３１、３２がソケットＡＰＩのブロッキング受信呼び出しを使用したとき、割り込みに関する処理、すなわち割り込み処理４７、デバイスドライバ５０、プロトコル処理４９、スケジューラ４１の処理（８０２〜８０５）が必要である。その結果、データ通信がカーネル４をバイパスする一方、制御はカーネル４をバイパスしないため、ボトルネックの一部が残ってしまう。
【００２９】
つまり、アダプタ６００は送受信が完了すると、割り込み処理４７を行って、プロトコル処理４９、スケジューラ４１を呼び出し、データ送受信待ち（Ｉ／Ｏ待ち）となっていたプロセス３１、３２を実行可能にする訳であるが、図７で示したように、複数のエンドポイント６１０〜６３０で送受信が完了する度に割り込み処理を行う必要があるため、各プロセスが「Ｉ／Ｏ待ち」から「実行可能」となるまでに処理時間を要し、このためデータの多重化のみでは、アダプタ６００における通信処理のオーバーヘッドを解消できない、という問題があった。
【００３０】
そこで本発明は、上記問題点に鑑みてなされたもので、データの多重化を行うとともに割り込み処理にかかる時間を低減して、入出力の高速化を図ることを目的とする。
【００３１】
【課題を解決するための手段】
本発明は、１つ以上のＣＰＵと、主記憶手段と、外部装置または外部ネットワークとのデータ入出力を行うためのInfiniBandアダプタとを備えた情報処理装置が、オペレーティングシステム上で複数のアプリケーションを実行し、当該アプリケーションと前記InfiniBandアダプタとの間で通信を行う入出力方法において、前記アプリケーションの各々に、前記InfiniBandアダプタ上の通信エンドポイントを割り当て、各アプリケーションと前記InfiniBandアダプタに割り当てた通信エンドポイントとの間の論理接続をそれぞれ確立するステップと、前記論理接続のそれぞれが確立したときに、前記エンドポイントのそれぞれに対応して設けられた状態変更機構に対し、前記オペレーティングシステム内のスケジューラが管理するプロセステーブル内の、当該通信エンドポイントの接続相手である前記アプリケーションの状態を示す主記憶アドレスを記録するステップと、前記論理接続のひとつのデータの送受信時に、前記論理接続に対応するアプリケーションがブロッキング呼び出しを使用した場合に、前記オペレーティングシステムに含まれるプロトコル処理により、前記プロセステーブルに記録した前記アプリケーションの状態をＩＯ待ち状態に変更するステップと、前記InfiniBandアダプタが、前記論理接続のデータ送受信を完了したときに、当該論理接続に対応する前記状態変更機構内に記録した主記憶アドレスにより前記接続相手であるアプリケーションの状態を示すエントリを特定して、当該エントリの値を「実行可能」を示す値に変更するステップと、前記InfiniBandアダプタが起動する割り込み、もしくはタイマ割り込みにより、前記スケジューラを呼び出し、前記通信相手であるアプリケーションを実行させるステップと、を含む。
【００３２】
すなわち、プロセス３１、３２がブロッキング呼び出しをし、この呼び出しに関する送受信が完了したとき、アダプタ６がこのプロセス３１、３２のプロセステーブル４２の状態を実行可能にする。このため、割り込みとカーネル４の処理なしでプロセス３１、３２の状態を変更できる。このプロセス３１、３２はその後のタイマー処理４８によるスケジューラ４１の実行時に実行中になる。
【００３３】
一方、ホスト１にアイドル状態のＣＰＵがあれば、性能を向上するために送受信完了時に実行可能になったプロセス３１、３２をすぐに実行中にする必要がある。このため、アイドル状態のＣＰＵがあれば割り込みを起こす。割り込み処理の後にスケジューラ４１が呼ばれ、このプロセス３１、３２が実行中になる。
【００３４】
【発明の効果】
したがって本発明は、入出力動作が要求されると、InfiniBandアダプタによる入出力動作を実行するとともに、要求した処理を実行待ち（Ｉ／Ｏ待ち）状態にする。そして、InfiniBandアダプタは入出力動作が完了すると、処理の状態を直接的に実行待ち状態から実行可能状態へ変更するため、入出力動作が完了した時点から処理が再び実行されるまでの処理時間を短縮でき、入出力処理の高効率化による高速化を図ることが可能となるのである。
【００３５】
【発明の実施の形態】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００３６】
図１は、前記従来例の図７に示したＩｎｆｉｎｉＢａｎｄアダプタに、本発明を適用した一例を示す。
【００３７】
ホスト（コンピュータ）１のオペレーティングシステム上で稼働する複数のプロセス３１、３２（アプリケーション）が、ＩｎｆｉｎｉＢａｎｄアダプタ６を使用して、ホスト１の外部とネットワーク７を介して通信するもので、オペレーティングシステム（以下、ＯＳ）のカーネル４は、ＩｎｆｉｎｉＢａｎｄアダプタ６を制御して、プロセス３１、３２のデータ３３、３４と制御の多重化（マルチプレクシング、デマルチプレクシング）を行う。
【００３８】
ここで、ホスト１のハードウェア構成の概略を図２に示す。
【００３９】
ホスト１には、複数のＣＰＵ（プロセッサ）１０１、１０２がＣＰＵバス１０３を介してメモリーコントローラ１０４に接続され、また、メモリーバス１０５を介してメモリーコントローラ１０４はメモリー１０６に接続されており、ＣＰＵ１０１、１０２または他のデバイスからメモリー１０６のアクセスを行う。
【００４０】
さらに、メモリーコントローラ１０４は、内部Ｉ／Ｏバス１０７を介してＩｎｆｉｎｉＢａｎｄアダプタ６に接続され、ＣＰＵ１０１、１０２は外部のネットワーク７と通信可能となる。
【００４１】
なお、メモリーコントローラ１０４には、割り込みコントローラなどが含まれ、メモリー１０６が主記憶となる。また、ＣＰＵ１０１、１０２は論理的に独立している仮想プロセッサで構成してもよい。
【００４２】
図１において、アダプタ６は、論理接続の通信エンドポイント（Ｑｕｅｕｅ Ｐａｉｒで、以下ＱＰ）６１〜６３で、各論理接続の処理と通信状態の管理をする。
【００４３】
プロセス３１、３２がプロトコル処理４９とデバイスドライバ５０を介して論理接続を確立するが、論理接続の確立後にはカーネル４を介さないでエンドポイント６１〜６３を直接アクセスする。
【００４４】
そして、アダプタ６はプロセス３１、３２のデータ３３、３４を直接送受信するために複数の通信エンドポイント６１〜６３の多重処理６４を行う。このため、ＩｎｆｉｎｉＢａｎｄアダプタ６の場合、カーネル４でなく、ＩｎｆｉｎｉＢａｎｄアダプタ６がデータの多重化を行う。
【００４５】
オペレーティングシステムのプロセス制御は主に、次に説明するプロセス状態の変更を行う。各プロセスは複数の状態があり、「実行中」（どれかのＣＰＵがこのプロセスを実行しているという状態）、「実行可能」（プロセスが実行できるが、ＣＰＵが実行していない状態）、「Ｉ／Ｏ待ち」（プロセスが送受信などの完了を待っている状態）がその例である（参考文献２参考。Ｌｉｎｕｘのプロセスはこれらの状態があるが、Ｌｉｎｕｘのtask#structの状態は上記の３つの状態に一対一対応しない）。
【００４６】
ここで、ＯＳ（ここではＬｉｎｕｘ）のカーネル４には、プロセス３１、３２とアダプタ６の論理接続を確立するプロトコル処理４９、デバイスドライバ５０を備え、また、タイマー５によるタイマー処理４８または割り込み処理４７によってプロセス３１、３２を制御するスケジューラ４１を備えている。
【００４７】
さらに、スケジューラ４１のテーブル４２は、アダプタ６のエンドポイント６１〜６３にそれぞれ設けた状態変更機構６５〜６７により、直接書き込み可能に構成される。
【００４８】
また、アイドル状態のＣＰＵがあるか否かを示す稼働中フラグ６８が設けられ、この稼働中フラグ６８は、スケジューラ４１によって設定され、アダプタ６からの割り込み要求をＣＰＵの稼働状態に応じて制御可能とする。
【００４９】
次に、各エンドポイント６１〜６３に設けた、状態変更機構６５〜６７について説明する。
【００５０】
プロトコル処理４９が、あるエンドポイント６１〜６３をあるプロセス３１、３２にアロケートし、このエンドポイント６１〜６３の論理接続を確立したとき、これらエンドポイント６１〜６３の状態変更機構６５〜６７に、プロセステーブル４２上でこれらプロセス３１、３２の状態を示すエントリのアドレスを登録する。これにより、各エンドポイントの状態変更機構６５〜６７は、エンドポイント毎の論理接続に対応するプロセステーブル４２上のエントリへ書き込み可能となる。
【００５１】
そして、この状態変更機構６５〜６７へのエントリ登録時に、プロセステーブル４２の各エントリのフィールド上で「実行可能」を示す値とバイト幅を状態変更機構６５〜６７に登録する。なお、スケジューラ４１のプロセステーブル４２は、主記憶上の所定の領域に予め設定された記憶領域である。
【００５２】
また、論理接続上のデータ送受信時に、プロセス３１、３２がブロッキング呼び出しを使用した場合に、エンドポイント６１〜６３を起動して送受信を開始する際に、送受信完了時に状態を変更することを要求する（前記従来例と同じく、起動の処理を、標準ＡＰＩの下にあるアダプタ６関連の通信ライブラリが実現する）。
【００５３】
この状態変更機構６５〜６７の動作について、図３のタイムチャートを参照しながら説明する。
【００５４】
そして、プロセス３１、３２がプロトコル処理４９を呼び出し（図３の８００）、プロトコル処理４９がこのプロセスの状態をＩ／Ｏ待ちにし、スケジューラ４１を呼び出す（８０１）（これで、実行可能のプロセス３１、３２があれば、これらのどれかが実行中になる）。
【００５５】
送受信が完了したときに、エンドポイント６１〜６３が状態変更機構６５〜６７に登録されたエントリに基づいて、実行可能を示す値をＤＭＡにより主記憶のプロセステーブル４２に書き込み、プロセス３１、３２の状態をＩ／Ｏ待ちから実行可能に変更する（図１では例として、エンドポイント６２の状態変更機構６６からのプロセステーブル４２への書き込みを矢印で示す）。一つあるいは複数のタイマー５割込みの後、このプロセス３１、３２が実行中になり（８０６）、ブロッキング呼び出しの処理を完了する（８０７）。
【００５６】
エンドポイントの送受信完了時に、全てのＣＰＵがビジーであれば、スケジューラを呼び出してもホスト１の性能が向上しない（実行中のプロセスのタイムカンタムが終わっておらず、プロセス３１、３２の状態が変更されないからである）。このため、状態変更機構６５〜６７からプロセステーブル４２への書き込みで実行可能となったプロセスはその後のタイマー処理４８のときに実行中になる。
【００５７】
一方、アイドル状態のＣＰＵがあれば、ホスト１の性能を向上するためにすぐにスケジューラを呼び出し、実行可能となったプロセスを実行中にする必要がある。
【００５８】
その結果、ＣＰＵのビジー状態により割り込み制御（起こすか否か）が必要である。この割り込みの制御を行うために、アイドル状態のＣＰＵがあるか否かを示すフラグとして上記稼動中フラグ６８が設けられ、スケジューラ４１が稼動中フラグ６８を設定する。
【００５９】
アイドル状態のＣＰＵがある場合、稼動中フラグ６８はアダプタ６からの割り込みを許可し、ない場合に割り込みをディスエーブル（禁止）する（但し、エラーなどの例外処理に関連する割り込みを抑止しない。これら例外処理については稼動中フラグ６８で監視せずに、別の割り込みライン（図示せず）を使用することが望ましい）。
【００６０】
次に、図４には上記割り込み処理の処理フローを示す。
【００６１】
アダプタ６は、状態変更機構６５〜６７によりプロセステーブル４２を変更した後に割り込みを起こし、割り込み処理４７を起動する（８０２）。
【００６２】
割り込み処理４７がアダプタ６の状態を調べ、この割り込みがプロセス３１〜３２の状態の変更を目的とする情報を取得したら、デバイスドライバ５０を呼ぶ必要がないことを判明する。これで、スケジューラ４１が呼ばれ（８０８）、対象となるプロセス３１〜３２が実行可能になり（８０６）、ブロッキング呼び出しの処理を完了する（８０７）。
【００６３】
なお、この図４では、一般的な処理の流れとして割込み処理４７から直接スケジューラ４１を呼ぶことを示している。但し、Ｌｉｎｕｘでは割込み処理４７から直接スケジューラ４１を呼べないため、ボトムハーフ等の処理を延期する方法を使用して間接的にスケジューラ４１を呼ぶ。
【００６４】
こうして、アダプタ６がエンドポイント６１〜６３の論理接続を確立したとき、プロセステーブル４２上で論理接続を確立したプロセスに対応するエントリのアドレスを状態変更機構６５〜６７へ登録し、その後、送受信を行う。そして、送受信完了時には、アダプタ６の状態変更機構６５〜６７は、送受信に対応したプロセステーブル４２上のエントリを、「Ｉ／Ｏ待ち」から「実行可能」に更新し、その後、アダプタ６が割り込みをかけることで、直接スケジューラ４１を呼ぶことが可能となる。
【００６５】
これにより、前記従来例では、図８で示したように、割り込み処理４７は、デバイスドライバ５０、プロトコル処理４９、スケジューラ４１の順で、順次処理を行っていたのに比して、本願発明によれば、割り込み処理４７から直接スケジューラ４１を呼ぶようにしたため、前記従来例の図８におけるステップ８０３、８０４、８０５が不要になって、これらの処理に要するオーバーヘッドを低減でき、送受信完了からプロセスの実行までの時間を短縮することが可能となり、この結果、プロセス３１、３２とアダプタ６間の通信（または入出力）処理の高速化を図ることが可能となるのである。
【００６６】
本発明は、上記実施形態あるいはその変形例に限定されるものではなく、以下に例示する変形例あるいは他の変形例によっても実現可能であることは言うまでもない。また、上記複数の実施の形態あるいはその変形例として記載の技術あるいは以下の変形例の組み合わせによっても実現できる。
（変形例１）
上記図１では、プロトコル処理表４０がプロトコル処理の情報を持つ。しかし、実際のカーネル４ではこの情報が複数の表として実現されることもあるが、本発明はこの場合にでも実現できる。
（変形例２）
本発明はＩｎｆｉｎｉＢａｎｄアダプタ６に制限されておらず、他のプロトコル（ＴＣＰ／ＩＰ等）を処理するアダプタにも使用できる。
【００６７】
ＴＣＰ／ＩＰを処理するアダプタの場合には、個別にインプリメントされたエンドポイント６１〜６３がない場合が考えられる。しかし、このアダプタが各ＴＣＰ／ＩＰ論理接続の状態を管理するため、この管理の中に状態変更機構６５〜６７相当の機能を追加することで本発明をインプリメントできる。
【００６８】
そして、ＩｎｆｉｎｉＢａｎｄでは各送受信操作の完了が明確である一方、ＴＣＰ／ＩＰはストリーミングプロトコルであるため、データが連続に流れ、プロセス３１、３２の送受信の完了はプロトコルレベルから見えない。このため、一つのパケットの送受信、またはプロセス３１、３２が設定した最低限のデータ量などを送受信の完了の基準とする。
（変形例３）
本発明は、上記ＩｎｆｉｎｉＢａｎｄやＴＣＰ／ＩＰのようなネットワークアダプタだけでなく、ディスクや他のアダプタにも使用できる。例えば、ディスクアダプタは従来、データを入出力（書き込み／読み出し）動作を起動するときに、書き込み／読み出しを対象とする主記憶アドレスとディスクブロックを指定し、これらの間で入出力が行われる。
【００６９】
この従来のディスクアダプタに本発明を適用するために、上記の入出力動作を起動するための情報に状態変更機構６５〜６７相当の情報（書き込みアドレスと値とバイト幅）を追加し、そしてアダプタにこの状態変更機構６５〜６７相当の情報を送受信完了時にカーネル４側のプロセステーブル４２へ書き込むための機能を追加すればよい。
（変形例４）
以上の説明では、論理接続確立のときに「実行可能」を示す値とそのバイト幅をアダプタ６に登録する例を示した。しかし、アダプタ６に「実行可能」を示す情報を登録するタイミングは上記に限定されるものではなく、例えば、アダプタ６の初期化のときに登録してもよい。そして、その値を各状態変更機構６５〜６７に登録することでなく、アダプタ全体にその値を登録する一つの機構を追加することも考えられる。
（変形例５）
上記図１において、アダプタ６の状態変更機構６５〜６７が書き込み先を、プロセステーブル４２でなく、図５に示す別の表（表５２）にすることが考えられる。
【００７０】
この形態は、カーネル４の変更を削減し、ハードウェアにプロセステーブル４２を直接アクセスさせないため、カーネル４に関する開発工数と信頼性の面では望ましい。この場合、カーネル４の状態変更タスク５１がその表の値を定期的に調べ、アダプタ６からの書き込みが行なわれた場合に、対象とするプロセスのプロセステーブル４２の状態を変更する。
【００７１】
そして、アイドルＣＰＵがあり、割り込みを起こした場合に、割り込み処理４７からスケジューラ４１を直接呼ばない。代わりに、状態変更タスク５１を呼び、状態変更タスク５１がプロセステーブル４２を変更し、スケジューラ４１を呼ぶ手順になる。
【００７２】
状態変更タスク５１が表５２を定期的に調べる方法として、例えばＬｉｎｕｘではＴａｓｋ Ｑｕｅｕｅを使用することが考えられる（A. Rubini, “Linux Device Drivers," O'Reilly & Associates, ISBN 1-56592-292-1参照）。アダプタ６を初期化したときにtq#timerタスクキューに書き込みを調べるタスクを入れ、そしてこの状態変更タスク５１が、実行時に自分をこのタスクキューに再び追加することで、書き込みを調べるタスクがタイマー５割り込み毎に実行される。
【００７３】
本変形例の場合、プロセステーブル４２には、書き込むアドレスと値とバイト幅ではなく、プロセス識別子（プロセス番号など）を使用することが考えられる。なお、表５２のデータ構造として、循環キューが考えられる。循環キューの場合、アダプタ６が循環キューに、状態変更するプロセス３１、３２の情報（識別子等）を書き込み、定期的にその情報を調べる状態変更タスク５１がその情報を消費する。状態変更タスク５１が消費した分をアダプタ６か状態変更機構６６に知らせる（アダプタ６全体に一つの表５２のみを設けた場合はアダプタ６に、状態変更機構６６毎に表５２を設けた場合に状態変更機構６６に知らせる）。
【００７４】
（変形例６）
以上の実施形態と変形例に、アダプタ６が主記憶にプロセス３１、３２に関する情報を書き込むことで、直接的か間接的に対象となるプロセスの状態を変更する。代わりに、図５に示すとおり、主記憶にないキュー５３を設け、アダプタ６が状態変更するプロセス３１、３２の情報（識別子など）をこのキュー５３に追加し、定期的にこのキュー５３の情報を調べる状態変更タスク５１（上記変形例５参照）がこの情報を読み出す方法が考えられる。
【００７５】
このキュー５３は、アダプタの内部の記憶手段（または記憶域）、または割り込みコントローラの内部の記憶手段（記憶域）などが考えられる。
【００７６】
（変形例７）
上記実施形態に示した稼動中フラグ６８は、ハードウェアまたはソフトウェアの何れかで実現できる。まず、ハードウェアによる実現方法としては、アダプタ６の一部、そしてホスト１の回路（割り込みコントローラ回路の内部など）が考えられる。
【００７７】
次に、ソフトウェアによる実現方法としては、ホスト１の割り込みコントローラを設定して、アダプタ６からの割り込みをイネーブル／抑止することが考えられる。
【００７８】
（変形例８）
以上の説明では説明や図を分かりやすくするために、アダプタ６は、上記図２で示したように、ホスト１の内部Ｉ／Ｏバス１０７とネットワーク７との間のアダプタにしたが、本発明はこの形態に制限されていない。他の形態の具体例として、ＩｎｆｉｎｉＢａｎｄと他ネットワークのアダプタが考えられる（この場合、ＩｎｆｉｎｉＢａｎｄが内部バスの位置付けを持つ）。そして、アダプタが一つまたは複数の接続でＩｎｆｉｎｉＢａｎｄのみに接続され、ＩｎｆｉｎｉＢａｎｄ上のＴＣＰ／ＩＰを処理する形態も考えられる（この場合、内部バスと外部ネットワークがＩｎｆｉｎｉＢａｎｄとなる）。
【００７９】
（変形例９）
以上の説明では説明や図を分かりやすくするために、ホスト１がコンピュータのような情報処理装置を前提にした。しかし、本発明はこれらの情報処理装置に制限されておらず、例えばストレージ装置や、スイッチやルータのようなネットワーク装置、またはそれらのアダプタにも適用できる。この場合、装置は組み込み型装置向けオペレーティングシステムを使用し、このオペレーティングシステムにプロセス３１、３２という概念がないことがあるが、本発明は各Ｉ／Ｏ処理の制御に使用できる。
【００８０】
（変形例１０）
以上の説明では本発明はプロセス３１、３２の状態を制御しているが、本発明はプロセス３１、３２に制限されておらず、各プロセス３１、３２の中の処理スレッドの制御にも使用できる。
【００８１】
なお、本発明を実施するためのプログラムは、それ単独であるいは他のプログラムと組み合わせて、ディスク記憶装置等のプログラム記憶媒体に記憶された販売することができる。また、本発明を実施するためのプログラムは、すでに使用されている通信を行うプログラムに追加される形式のプログラムでもよく、あるいはその通信用のプログラムの一部を置換する形式のプログラムでも良い。
【００８２】
今回開示した実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び内容の範囲での全ての変更が含まれることが意図される。
【図面の簡単な説明】
【図１】本発明の一実施形態を示し、ホストの機能概略を示すブロック図である。
【図２】同じく、ハードウェアの概略図である。
【図３】アダプタの状態変更機構の動作を示すタイムチャートである。
【図４】アダプタからの割り込み処理を示すタイムチャートである。
【図５】他の実施形態を示し、ホストの機能概略を示すブロック図である。
【図６】従来例を示し、ネットワークアダプタを用いたホストの機能概略を示すブロック図。
【図７】他の従来例を示し、ＩｎｆｉｎｉＢａｎｄのアダプタを用いたホストの機能概略を示すブロック図。
【図８】同じく、従来例を示し、アダプタからの割り込み処理を示すタイムチャートである。
【符号の説明】
１ ホスト
４ カーネル
６ アダプタ
４１ スケジューラ
４２ プロセステーブル
６１〜６３ エンドポイント
６５〜６７ 状態変更機構
【発明の属する技術分野】
本発明は入出力アダプタ、特にディスク装置、ネットワーク等を、コンピュータ等に接続し、そのディスク装置やネットワークに使用するプロトコルを処理するアダプタに関する。
【０００２】
【従来の技術】
ディスク接続方法やネットワークは、複数の種類が存在し、イーサネット（登録商標）、Ｆｉｂｒｅ Ｃｈａｎｎｅｌ、ＡＴＭ、パラレルＳＣＳＩがその例である。
【０００３】
これらのディスク接続方法やネットワークをホスト（コンピュータ）等の情報処理装置に接続するとき、ホストの内部Ｉ／Ｏバスと、ディスク接続方法やネットワークを結ぶアダプタを使用する。
【０００４】
パーソナルコンピュータにおいては、ＰＣＩバスとイーサネットを結ぶネットワークアダプタがそのアダプタの一例である（ＰＣＩバスのコネクタに接続するカードという形式のアダプタが良くあるが、マザーボードにこれらのコンポーネントを直接組み付ける例もあり、この場合にもアダプタと呼ぶ）。
【０００５】
図６を使用してコンピュータシステムのアダプタ、そしてオペレーティングシステム（以下、ＯＳ）のカーネルとプロセスの動作を説明する。
【０００６】
本願明細書では、説明を分かりやすくするためにネットワークアダプタ、そしてネットワークでの通信に極めて一般的に使用されているＴＣＰ／ＩＰプロトコル（W. Richard Stevens, “UNIX Network Programming,” Prentice Hall, U.S.A., 1990, ISBN 0-13-949876-1参照、以下参考文献１と呼ぶ）の通信の場合を中心に説明する。そして、ＴＣＰ／ＩＰで通信するためのソケットＡＰＩ（Application Programming Interface、プロセスがコンピュータやオペレーティングシステムのある機能を用いるために呼び出す関数の集合）を例に使用する（参考文献１参照）。また、ＯＳとしてはＬｉｎｕｘカーネル（D. P. Bovet, M. Cesati, “Understanding the Linux Kernel,” O’Reilly & Associates, 2001, ISBN 0-596-00002-2参照、以下参考文献２と呼ぶ）を例にすることがある。なお、本発明においてはネットワークアダプタ、ＴＣＰ／ＩＰプロトコル、ソケットＡＰＩやＬｉｎｕｘカーネルに制限されるものではない。
【０００７】
まず、図６の場合、ホスト１の複数のプロセス（プログラム）３１、３２がアダプタ２を使用して通信する（図６と今後の図にネットワーク上の通信相手を図示しない）。カーネル４は、アダプタ２を制御し、プロセス３１、３２のデータと制御の多重化（マルチプレクシング、デマルチプレクシング）をする。次にこの多重化を説明する。
【０００８】
まず、データの多重化について説明する。アダプタ２は複数のプロセス３１、３２のデータをまとめて送受信するため、カーネル４はバッファ４５を介して複数プロセス３１、３２とアダプタ２の間でデータの多重化を行う。まず、受信処理について説明する。アダプタ２はネットワークからパケットを受信したとき、そのパケットをカーネル４のバッファ４５に書き込む（アダプタは、ＤＭＡで主記憶の書き込み／読み出しができる）。
【０００９】
そして、アダプタ２が受信完了のときに割り込みを起こし、その割り込みを、このアダプタ２の割り込み処理４７のコードが処理し、デバイスドライバ４６を呼び出す。デバイスドライバ４６がバッファ４５を読み出し、パケットの通信プロトコルを調べ、このプロトコル（この例ではＴＣＰ／ＩＰ）のプロトコル処理４３を呼び出す。
【００１０】
ＴＣＰ／ＩＰでは、予め確立された論理接続の上でデータを通信する。プロトコル処理４３はＴＣＰ／ＩＰ処理を行うために、通信の状態の管理と、論理接続とプロセスとの連携などを記録するプロトコル処理表４４を持つ。プロトコル処理４３は、受信したデータの宛先となるプロセス３１、３２を調べ、このデータをこのプロセス３１、３２のバッファ３３、３４にそれぞれコピーし、受信したデータのバッファ４５の領域を開放し、受信処理を完了する。
【００１１】
送信処理はほぼ逆方向の処理を行う。まず、プロセス３１、３２が送信データ３３、３４を指定してプロトコル処理４３を呼び出す。プロトコル処理４３がそのデータ３３、３４をバッファ４５にコピーし、このバッファ４５上でパケットを組み立て、デバイスドライバ４６を呼び出す。デバイスドライバ４６がアダプタ２を制御し、パケットを送信させる。送信が完了したとき、アダプタ２が割り込みを起こし、この割り込みを割り込み処理４７と、デバイスドライバ４６が処理し、デバイスドライバ４６が送信されたパケットのバッファ４５の領域を開放する。
【００１２】
次にプロセス制御の多重化を説明する。図６において、アダプタ２は複数のプロセス３１、３２に関する割り込みをまとめて起こすため、カーネル４が各プロセス３１、３２のプロセス制御のために割り込みの多重化も行う（この処理は普段「多重化」と呼ばれないが、データの多重化との類似を指摘するためにこの明細書はこの用語を使用する）。
【００１３】
プロセス制御は主に、次に説明するプロセス状態の変更を行う。各プロセスは複数の状態があり、「実行中」（どれかのＣＰＵがこのプロセスを実行しているという状態）、「実行可能」（プロセスが実行できるが、ＣＰＵが実行していない状態）、「Ｉ／Ｏ待ち」（プロセスが送受信などの完了を待っている状態）がその例である（参考文献２参考。Ｌｉｎｕｘのプロセスはこれらの状態があるが、Ｌｉｎｕｘのtask#structの状態は上記の３つの状態に一対一対応しない）。
【００１４】
カーネル４が送受信時に各プロセス３１、３２の状態を管理し、プロセステーブル４２に状態を記録する。
【００１５】
図８に受信処理のタイムチャートを例にする。プロセス３１、３２がソケットＡＰＩのブロッキング呼び出し（データ受信完了まで待つ）を使用したとき、カーネル４のプロトコル処理４３が呼ばれる（８００）。プロトコル処理４３ではデータが受信されていない場合、カーネル４のスケジューラ４１を呼び出し（８０１）プロセス３１、３２を実行中状態からＩ／Ｏ待ち状態に変更する。
【００１６】
アダプタ２はデータ受信完了のときに割り込みを起こす（８０２）。割り込み処理４７、デバイスドライバ４６とプロトコル処理４３が呼び出され（８０３、８０４）、プロトコル処理４３は上記受信処理の中でどのプロセス３１、３２がこの受信に対応するかを調べ、状態変更が必要である場合にスケジューラ４１を呼び出す（８０５）。スケジューラ４１がデータを送受信したプロセス３１、３２を実行可能状態にする。
【００１７】
その後（実行可能状態になった直後か、一つあるいは複数のタイマー５割込み（後述）の後）、このプロセス３１、３２が実行中状態となり（８０６）、受信処理を完了する（８０７）。
【００１８】
なお、送受信に関わらず、タイマー５が定期的に割り込みを起こし（Ｌｉｎｕｘでは１００Ｈｚ、参考文献１の１４０ページ参照）、タイマー処理４８の後にスケジューラが呼ばれ（参考文献１の１３３及び１４２ページ参照）、必要があればスケジューラ４１が実行可能と実行中プロセス３１、３２の中のどれを実行中、実行可能にするかを選択する。この処理でカーネルがタイムシェアリングを実現する。
【００１９】
近年、ネットワーク性能がサーバ処理能力を大きく上回って向上してきた結果、ＴＣＰ／ＩＰプロトコルの処理がボトルネックとして顕在化してきた。
【００２０】
その対策として、アダプタでのプロトコル処理の２つの方式、すなわちＴＣＰ／ＩＰのハードウェア化（J. Hufferd, “The Outboarding of TCP/IP," e-Commerce Infrastructure Technology Conference and Tradeshow, February 2001, Monterey, U.S.A.参照）と、論理接続などのＴＣＰ／ＩＰ相当の機能を独自プロトコルで実現するＩｎｆｉｎｉＢａｎｄネットワーク（InfiniBand Architecture Specification Volume 1 Release 1.0.a参照）が開発されてきた。
【００２１】
図７にＩｎｆｉｎｉＢａｎｄアダプタを例にしてプロトコルを処理するアダプタ６００を説明する。
【００２２】
このアダプタ６００は、論理接続の通信エンドポイント６１０〜６３０で、各論理接続の処理と通信状態の管理をする（ＩｎｆｉｎｉＢａｎｄでは、この通信エンドポイントをＱｕｅｕｅ Ｐａｉｒと呼び、以下ＱＰと略す）。
【００２３】
プロセス３１、３２がプロトコル処理４９とデバイスドライバ５０を介して論理接続を確立するが、確立後にカーネル４を介さないでエンドポイント６１０〜６３０を直接アクセスする（プロトコル処理４９、プロトコル処理表４０、デバイスドライバ５０はプロトコル処理４３、プロトコル処理表４４、デバイスドライバ４６と同等であるが、前者のプロトコル処理は後者のプロトコル処理を含めず、接続管理の機能のみを含む）。
【００２４】
そして、アダプタ６００はプロセス３１、３２のデータ３３、３４を直接送受信するために複数の通信エンドポイント６１０〜６３０の多重処理６４を行う。このため、アダプタ６００の場合、カーネル４でなく、アダプタ６００がデータの多重化を行う。
【００２５】
ＩｎｆｉｎｉＢａｎｄアダプタ６００を直接駆動するにはソケットと異なったＡＰＩを使用するが、ＩｎｆｉｎｉＢａｎｄ向けＡＰＩにもブロッキング呼び出しが存在すると考えられる（これらのＡＰＩは現在規格化中である）。
【００２６】
上記図７のＩｎｆｉｎｉＢａｎｄアダプタ６００における処理を、上記図８のタイムチャートを用いて説明すると、アダプタ６００がデータ送受信のプロトコル処理をするため、ブロッキング呼び出し（８００）のときにプロトコル処理４９がスケジューラ４１の呼び出しをする（変形例としてここでは、特別なシステムコールを設ければ、プロセス３１、３２が直接スケジューラを呼べる）。送受信完了のときにアダプタ６００が割込みを起こす（８０２）。
【００２７】
【発明が解決しようとする課題】
上記図７の従来例においては、プロトコルを処理するアダプタ６００は、データ送受信時にカーネル４をバイパスして、プロトコル処理４３のバイパス、そしてプロセス３１、３２のバッファ３３、３４とバッファ４５とのデータコピーをなくすことなどにより、ＣＰＵ負荷を削減し、通常のアダプタ２（図６）のボトルネックの一部を解決する。
【００２８】
しかしながら、プロトコルを処理するアダプタ６００がデータの多重化を処理する一方、制御の多重化を行っていない。例えば、プロセス３１、３２がソケットＡＰＩのブロッキング受信呼び出しを使用したとき、割り込みに関する処理、すなわち割り込み処理４７、デバイスドライバ５０、プロトコル処理４９、スケジューラ４１の処理（８０２〜８０５）が必要である。その結果、データ通信がカーネル４をバイパスする一方、制御はカーネル４をバイパスしないため、ボトルネックの一部が残ってしまう。
【００２９】
つまり、アダプタ６００は送受信が完了すると、割り込み処理４７を行って、プロトコル処理４９、スケジューラ４１を呼び出し、データ送受信待ち（Ｉ／Ｏ待ち）となっていたプロセス３１、３２を実行可能にする訳であるが、図７で示したように、複数のエンドポイント６１０〜６３０で送受信が完了する度に割り込み処理を行う必要があるため、各プロセスが「Ｉ／Ｏ待ち」から「実行可能」となるまでに処理時間を要し、このためデータの多重化のみでは、アダプタ６００における通信処理のオーバーヘッドを解消できない、という問題があった。
【００３０】
そこで本発明は、上記問題点に鑑みてなされたもので、データの多重化を行うとともに割り込み処理にかかる時間を低減して、入出力の高速化を図ることを目的とする。
【００３１】
【課題を解決するための手段】
本発明は、１つ以上のＣＰＵと、主記憶手段と、外部装置または外部ネットワークとのデータ入出力を行うためのInfiniBandアダプタとを備えた情報処理装置が、オペレーティングシステム上で複数のアプリケーションを実行し、当該アプリケーションと前記InfiniBandアダプタとの間で通信を行う入出力方法において、前記アプリケーションの各々に、前記InfiniBandアダプタ上の通信エンドポイントを割り当て、各アプリケーションと前記InfiniBandアダプタに割り当てた通信エンドポイントとの間の論理接続をそれぞれ確立するステップと、前記論理接続のそれぞれが確立したときに、前記エンドポイントのそれぞれに対応して設けられた状態変更機構に対し、前記オペレーティングシステム内のスケジューラが管理するプロセステーブル内の、当該通信エンドポイントの接続相手である前記アプリケーションの状態を示す主記憶アドレスを記録するステップと、前記論理接続のひとつのデータの送受信時に、前記論理接続に対応するアプリケーションがブロッキング呼び出しを使用した場合に、前記オペレーティングシステムに含まれるプロトコル処理により、前記プロセステーブルに記録した前記アプリケーションの状態をＩＯ待ち状態に変更するステップと、前記InfiniBandアダプタが、前記論理接続のデータ送受信を完了したときに、当該論理接続に対応する前記状態変更機構内に記録した主記憶アドレスにより前記接続相手であるアプリケーションの状態を示すエントリを特定して、当該エントリの値を「実行可能」を示す値に変更するステップと、前記InfiniBandアダプタが起動する割り込み、もしくはタイマ割り込みにより、前記スケジューラを呼び出し、前記通信相手であるアプリケーションを実行させるステップと、を含む。
【００３２】
すなわち、プロセス３１、３２がブロッキング呼び出しをし、この呼び出しに関する送受信が完了したとき、アダプタ６がこのプロセス３１、３２のプロセステーブル４２の状態を実行可能にする。このため、割り込みとカーネル４の処理なしでプロセス３１、３２の状態を変更できる。このプロセス３１、３２はその後のタイマー処理４８によるスケジューラ４１の実行時に実行中になる。
【００３３】
一方、ホスト１にアイドル状態のＣＰＵがあれば、性能を向上するために送受信完了時に実行可能になったプロセス３１、３２をすぐに実行中にする必要がある。このため、アイドル状態のＣＰＵがあれば割り込みを起こす。割り込み処理の後にスケジューラ４１が呼ばれ、このプロセス３１、３２が実行中になる。
【００３４】
【発明の効果】
したがって本発明は、入出力動作が要求されると、InfiniBandアダプタによる入出力動作を実行するとともに、要求した処理を実行待ち（Ｉ／Ｏ待ち）状態にする。そして、InfiniBandアダプタは入出力動作が完了すると、処理の状態を直接的に実行待ち状態から実行可能状態へ変更するため、入出力動作が完了した時点から処理が再び実行されるまでの処理時間を短縮でき、入出力処理の高効率化による高速化を図ることが可能となるのである。
【００３５】
【発明の実施の形態】
以下、本発明の一実施形態を添付図面に基づいて説明する。
【００３６】
図１は、前記従来例の図７に示したＩｎｆｉｎｉＢａｎｄアダプタに、本発明を適用した一例を示す。
【００３７】
ホスト（コンピュータ）１のオペレーティングシステム上で稼働する複数のプロセス３１、３２（アプリケーション）が、ＩｎｆｉｎｉＢａｎｄアダプタ６を使用して、ホスト１の外部とネットワーク７を介して通信するもので、オペレーティングシステム（以下、ＯＳ）のカーネル４は、ＩｎｆｉｎｉＢａｎｄアダプタ６を制御して、プロセス３１、３２のデータ３３、３４と制御の多重化（マルチプレクシング、デマルチプレクシング）を行う。
【００３８】
ここで、ホスト１のハードウェア構成の概略を図２に示す。
【００３９】
ホスト１には、複数のＣＰＵ（プロセッサ）１０１、１０２がＣＰＵバス１０３を介してメモリーコントローラ１０４に接続され、また、メモリーバス１０５を介してメモリーコントローラ１０４はメモリー１０６に接続されており、ＣＰＵ１０１、１０２または他のデバイスからメモリー１０６のアクセスを行う。
【００４０】
さらに、メモリーコントローラ１０４は、内部Ｉ／Ｏバス１０７を介してＩｎｆｉｎｉＢａｎｄアダプタ６に接続され、ＣＰＵ１０１、１０２は外部のネットワーク７と通信可能となる。
【００４１】
なお、メモリーコントローラ１０４には、割り込みコントローラなどが含まれ、メモリー１０６が主記憶となる。また、ＣＰＵ１０１、１０２は論理的に独立している仮想プロセッサで構成してもよい。
【００４２】
図１において、アダプタ６は、論理接続の通信エンドポイント（Ｑｕｅｕｅ Ｐａｉｒで、以下ＱＰ）６１〜６３で、各論理接続の処理と通信状態の管理をする。
【００４３】
プロセス３１、３２がプロトコル処理４９とデバイスドライバ５０を介して論理接続を確立するが、論理接続の確立後にはカーネル４を介さないでエンドポイント６１〜６３を直接アクセスする。
【００４４】
そして、アダプタ６はプロセス３１、３２のデータ３３、３４を直接送受信するために複数の通信エンドポイント６１〜６３の多重処理６４を行う。このため、ＩｎｆｉｎｉＢａｎｄアダプタ６の場合、カーネル４でなく、ＩｎｆｉｎｉＢａｎｄアダプタ６がデータの多重化を行う。
【００４５】
オペレーティングシステムのプロセス制御は主に、次に説明するプロセス状態の変更を行う。各プロセスは複数の状態があり、「実行中」（どれかのＣＰＵがこのプロセスを実行しているという状態）、「実行可能」（プロセスが実行できるが、ＣＰＵが実行していない状態）、「Ｉ／Ｏ待ち」（プロセスが送受信などの完了を待っている状態）がその例である（参考文献２参考。Ｌｉｎｕｘのプロセスはこれらの状態があるが、Ｌｉｎｕｘのtask#structの状態は上記の３つの状態に一対一対応しない）。
【００４６】
ここで、ＯＳ（ここではＬｉｎｕｘ）のカーネル４には、プロセス３１、３２とアダプタ６の論理接続を確立するプロトコル処理４９、デバイスドライバ５０を備え、また、タイマー５によるタイマー処理４８または割り込み処理４７によってプロセス３１、３２を制御するスケジューラ４１を備えている。
【００４７】
さらに、スケジューラ４１のテーブル４２は、アダプタ６のエンドポイント６１〜６３にそれぞれ設けた状態変更機構６５〜６７により、直接書き込み可能に構成される。
【００４８】
また、アイドル状態のＣＰＵがあるか否かを示す稼働中フラグ６８が設けられ、この稼働中フラグ６８は、スケジューラ４１によって設定され、アダプタ６からの割り込み要求をＣＰＵの稼働状態に応じて制御可能とする。
【００４９】
次に、各エンドポイント６１〜６３に設けた、状態変更機構６５〜６７について説明する。
【００５０】
プロトコル処理４９が、あるエンドポイント６１〜６３をあるプロセス３１、３２にアロケートし、このエンドポイント６１〜６３の論理接続を確立したとき、これらエンドポイント６１〜６３の状態変更機構６５〜６７に、プロセステーブル４２上でこれらプロセス３１、３２の状態を示すエントリのアドレスを登録する。これにより、各エンドポイントの状態変更機構６５〜６７は、エンドポイント毎の論理接続に対応するプロセステーブル４２上のエントリへ書き込み可能となる。
【００５１】
そして、この状態変更機構６５〜６７へのエントリ登録時に、プロセステーブル４２の各エントリのフィールド上で「実行可能」を示す値とバイト幅を状態変更機構６５〜６７に登録する。なお、スケジューラ４１のプロセステーブル４２は、主記憶上の所定の領域に予め設定された記憶領域である。
【００５２】
また、論理接続上のデータ送受信時に、プロセス３１、３２がブロッキング呼び出しを使用した場合に、エンドポイント６１〜６３を起動して送受信を開始する際に、送受信完了時に状態を変更することを要求する（前記従来例と同じく、起動の処理を、標準ＡＰＩの下にあるアダプタ６関連の通信ライブラリが実現する）。
【００５３】
この状態変更機構６５〜６７の動作について、図３のタイムチャートを参照しながら説明する。
【００５４】
そして、プロセス３１、３２がプロトコル処理４９を呼び出し（図３の８００）、プロトコル処理４９がこのプロセスの状態をＩ／Ｏ待ちにし、スケジューラ４１を呼び出す（８０１）（これで、実行可能のプロセス３１、３２があれば、これらのどれかが実行中になる）。
【００５５】
送受信が完了したときに、エンドポイント６１〜６３が状態変更機構６５〜６７に登録されたエントリに基づいて、実行可能を示す値をＤＭＡにより主記憶のプロセステーブル４２に書き込み、プロセス３１、３２の状態をＩ／Ｏ待ちから実行可能に変更する（図１では例として、エンドポイント６２の状態変更機構６６からのプロセステーブル４２への書き込みを矢印で示す）。一つあるいは複数のタイマー５割込みの後、このプロセス３１、３２が実行中になり（８０６）、ブロッキング呼び出しの処理を完了する（８０７）。
【００５６】
エンドポイントの送受信完了時に、全てのＣＰＵがビジーであれば、スケジューラを呼び出してもホスト１の性能が向上しない（実行中のプロセスのタイムカンタムが終わっておらず、プロセス３１、３２の状態が変更されないからである）。このため、状態変更機構６５〜６７からプロセステーブル４２への書き込みで実行可能となったプロセスはその後のタイマー処理４８のときに実行中になる。
【００５７】
一方、アイドル状態のＣＰＵがあれば、ホスト１の性能を向上するためにすぐにスケジューラを呼び出し、実行可能となったプロセスを実行中にする必要がある。
【００５８】
その結果、ＣＰＵのビジー状態により割り込み制御（起こすか否か）が必要である。この割り込みの制御を行うために、アイドル状態のＣＰＵがあるか否かを示すフラグとして上記稼動中フラグ６８が設けられ、スケジューラ４１が稼動中フラグ６８を設定する。
【００５９】
アイドル状態のＣＰＵがある場合、稼動中フラグ６８はアダプタ６からの割り込みを許可し、ない場合に割り込みをディスエーブル（禁止）する（但し、エラーなどの例外処理に関連する割り込みを抑止しない。これら例外処理については稼動中フラグ６８で監視せずに、別の割り込みライン（図示せず）を使用することが望ましい）。
【００６０】
次に、図４には上記割り込み処理の処理フローを示す。
【００６１】
アダプタ６は、状態変更機構６５〜６７によりプロセステーブル４２を変更した後に割り込みを起こし、割り込み処理４７を起動する（８０２）。
【００６２】
割り込み処理４７がアダプタ６の状態を調べ、この割り込みがプロセス３１〜３２の状態の変更を目的とする情報を取得したら、デバイスドライバ５０を呼ぶ必要がないことを判明する。これで、スケジューラ４１が呼ばれ（８０８）、対象となるプロセス３１〜３２が実行可能になり（８０６）、ブロッキング呼び出しの処理を完了する（８０７）。
【００６３】
なお、この図４では、一般的な処理の流れとして割込み処理４７から直接スケジューラ４１を呼ぶことを示している。但し、Ｌｉｎｕｘでは割込み処理４７から直接スケジューラ４１を呼べないため、ボトムハーフ等の処理を延期する方法を使用して間接的にスケジューラ４１を呼ぶ。
【００６４】
こうして、アダプタ６がエンドポイント６１〜６３の論理接続を確立したとき、プロセステーブル４２上で論理接続を確立したプロセスに対応するエントリのアドレスを状態変更機構６５〜６７へ登録し、その後、送受信を行う。そして、送受信完了時には、アダプタ６の状態変更機構６５〜６７は、送受信に対応したプロセステーブル４２上のエントリを、「Ｉ／Ｏ待ち」から「実行可能」に更新し、その後、アダプタ６が割り込みをかけることで、直接スケジューラ４１を呼ぶことが可能となる。
【００６５】
これにより、前記従来例では、図８で示したように、割り込み処理４７は、デバイスドライバ５０、プロトコル処理４９、スケジューラ４１の順で、順次処理を行っていたのに比して、本願発明によれば、割り込み処理４７から直接スケジューラ４１を呼ぶようにしたため、前記従来例の図８におけるステップ８０３、８０４、８０５が不要になって、これらの処理に要するオーバーヘッドを低減でき、送受信完了からプロセスの実行までの時間を短縮することが可能となり、この結果、プロセス３１、３２とアダプタ６間の通信（または入出力）処理の高速化を図ることが可能となるのである。
【００６６】
本発明は、上記実施形態あるいはその変形例に限定されるものではなく、以下に例示する変形例あるいは他の変形例によっても実現可能であることは言うまでもない。また、上記複数の実施の形態あるいはその変形例として記載の技術あるいは以下の変形例の組み合わせによっても実現できる。
（変形例１）
上記図１では、プロトコル処理表４０がプロトコル処理の情報を持つ。しかし、実際のカーネル４ではこの情報が複数の表として実現されることもあるが、本発明はこの場合にでも実現できる。
（変形例２）
本発明はＩｎｆｉｎｉＢａｎｄアダプタ６に制限されておらず、他のプロトコル（ＴＣＰ／ＩＰ等）を処理するアダプタにも使用できる。
【００６７】
ＴＣＰ／ＩＰを処理するアダプタの場合には、個別にインプリメントされたエンドポイント６１〜６３がない場合が考えられる。しかし、このアダプタが各ＴＣＰ／ＩＰ論理接続の状態を管理するため、この管理の中に状態変更機構６５〜６７相当の機能を追加することで本発明をインプリメントできる。
【００６８】
そして、ＩｎｆｉｎｉＢａｎｄでは各送受信操作の完了が明確である一方、ＴＣＰ／ＩＰはストリーミングプロトコルであるため、データが連続に流れ、プロセス３１、３２の送受信の完了はプロトコルレベルから見えない。このため、一つのパケットの送受信、またはプロセス３１、３２が設定した最低限のデータ量などを送受信の完了の基準とする。
（変形例３）
本発明は、上記ＩｎｆｉｎｉＢａｎｄやＴＣＰ／ＩＰのようなネットワークアダプタだけでなく、ディスクや他のアダプタにも使用できる。例えば、ディスクアダプタは従来、データを入出力（書き込み／読み出し）動作を起動するときに、書き込み／読み出しを対象とする主記憶アドレスとディスクブロックを指定し、これらの間で入出力が行われる。
【００６９】
この従来のディスクアダプタに本発明を適用するために、上記の入出力動作を起動するための情報に状態変更機構６５〜６７相当の情報（書き込みアドレスと値とバイト幅）を追加し、そしてアダプタにこの状態変更機構６５〜６７相当の情報を送受信完了時にカーネル４側のプロセステーブル４２へ書き込むための機能を追加すればよい。
（変形例４）
以上の説明では、論理接続確立のときに「実行可能」を示す値とそのバイト幅をアダプタ６に登録する例を示した。しかし、アダプタ６に「実行可能」を示す情報を登録するタイミングは上記に限定されるものではなく、例えば、アダプタ６の初期化のときに登録してもよい。そして、その値を各状態変更機構６５〜６７に登録することでなく、アダプタ全体にその値を登録する一つの機構を追加することも考えられる。
（変形例５）
上記図１において、アダプタ６の状態変更機構６５〜６７が書き込み先を、プロセステーブル４２でなく、図５に示す別の表（表５２）にすることが考えられる。
【００７０】
この形態は、カーネル４の変更を削減し、ハードウェアにプロセステーブル４２を直接アクセスさせないため、カーネル４に関する開発工数と信頼性の面では望ましい。この場合、カーネル４の状態変更タスク５１がその表の値を定期的に調べ、アダプタ６からの書き込みが行なわれた場合に、対象とするプロセスのプロセステーブル４２の状態を変更する。
【００７１】
そして、アイドルＣＰＵがあり、割り込みを起こした場合に、割り込み処理４７からスケジューラ４１を直接呼ばない。代わりに、状態変更タスク５１を呼び、状態変更タスク５１がプロセステーブル４２を変更し、スケジューラ４１を呼ぶ手順になる。
【００７２】
状態変更タスク５１が表５２を定期的に調べる方法として、例えばＬｉｎｕｘではＴａｓｋ Ｑｕｅｕｅを使用することが考えられる（A. Rubini, “Linux Device Drivers," O'Reilly & Associates, ISBN 1-56592-292-1参照）。アダプタ６を初期化したときにtq#timerタスクキューに書き込みを調べるタスクを入れ、そしてこの状態変更タスク５１が、実行時に自分をこのタスクキューに再び追加することで、書き込みを調べるタスクがタイマー５割り込み毎に実行される。
【００７３】
本変形例の場合、プロセステーブル４２には、書き込むアドレスと値とバイト幅ではなく、プロセス識別子（プロセス番号など）を使用することが考えられる。なお、表５２のデータ構造として、循環キューが考えられる。循環キューの場合、アダプタ６が循環キューに、状態変更するプロセス３１、３２の情報（識別子等）を書き込み、定期的にその情報を調べる状態変更タスク５１がその情報を消費する。状態変更タスク５１が消費した分をアダプタ６か状態変更機構６６に知らせる（アダプタ６全体に一つの表５２のみを設けた場合はアダプタ６に、状態変更機構６６毎に表５２を設けた場合に状態変更機構６６に知らせる）。
【００７４】
（変形例６）
以上の実施形態と変形例に、アダプタ６が主記憶にプロセス３１、３２に関する情報を書き込むことで、直接的か間接的に対象となるプロセスの状態を変更する。代わりに、図５に示すとおり、主記憶にないキュー５３を設け、アダプタ６が状態変更するプロセス３１、３２の情報（識別子など）をこのキュー５３に追加し、定期的にこのキュー５３の情報を調べる状態変更タスク５１（上記変形例５参照）がこの情報を読み出す方法が考えられる。
【００７５】
このキュー５３は、アダプタの内部の記憶手段（または記憶域）、または割り込みコントローラの内部の記憶手段（記憶域）などが考えられる。
【００７６】
（変形例７）
上記実施形態に示した稼動中フラグ６８は、ハードウェアまたはソフトウェアの何れかで実現できる。まず、ハードウェアによる実現方法としては、アダプタ６の一部、そしてホスト１の回路（割り込みコントローラ回路の内部など）が考えられる。
【００７７】
次に、ソフトウェアによる実現方法としては、ホスト１の割り込みコントローラを設定して、アダプタ６からの割り込みをイネーブル／抑止することが考えられる。
【００７８】
（変形例８）
以上の説明では説明や図を分かりやすくするために、アダプタ６は、上記図２で示したように、ホスト１の内部Ｉ／Ｏバス１０７とネットワーク７との間のアダプタにしたが、本発明はこの形態に制限されていない。他の形態の具体例として、ＩｎｆｉｎｉＢａｎｄと他ネットワークのアダプタが考えられる（この場合、ＩｎｆｉｎｉＢａｎｄが内部バスの位置付けを持つ）。そして、アダプタが一つまたは複数の接続でＩｎｆｉｎｉＢａｎｄのみに接続され、ＩｎｆｉｎｉＢａｎｄ上のＴＣＰ／ＩＰを処理する形態も考えられる（この場合、内部バスと外部ネットワークがＩｎｆｉｎｉＢａｎｄとなる）。
【００７９】
（変形例９）
以上の説明では説明や図を分かりやすくするために、ホスト１がコンピュータのような情報処理装置を前提にした。しかし、本発明はこれらの情報処理装置に制限されておらず、例えばストレージ装置や、スイッチやルータのようなネットワーク装置、またはそれらのアダプタにも適用できる。この場合、装置は組み込み型装置向けオペレーティングシステムを使用し、このオペレーティングシステムにプロセス３１、３２という概念がないことがあるが、本発明は各Ｉ／Ｏ処理の制御に使用できる。
【００８０】
（変形例１０）
以上の説明では本発明はプロセス３１、３２の状態を制御しているが、本発明はプロセス３１、３２に制限されておらず、各プロセス３１、３２の中の処理スレッドの制御にも使用できる。
【００８１】
なお、本発明を実施するためのプログラムは、それ単独であるいは他のプログラムと組み合わせて、ディスク記憶装置等のプログラム記憶媒体に記憶された販売することができる。また、本発明を実施するためのプログラムは、すでに使用されている通信を行うプログラムに追加される形式のプログラムでもよく、あるいはその通信用のプログラムの一部を置換する形式のプログラムでも良い。
【００８２】
今回開示した実施の形態は、全ての点で例示であって制限的なものではないと考えられるべきである。本発明の範囲は上記した説明ではなくて特許請求の範囲によって示され、特許請求の範囲と均等の意味及び内容の範囲での全ての変更が含まれることが意図される。
【図面の簡単な説明】
【図１】本発明の一実施形態を示し、ホストの機能概略を示すブロック図である。
【図２】同じく、ハードウェアの概略図である。
【図３】アダプタの状態変更機構の動作を示すタイムチャートである。
【図４】アダプタからの割り込み処理を示すタイムチャートである。
【図５】他の実施形態を示し、ホストの機能概略を示すブロック図である。
【図６】従来例を示し、ネットワークアダプタを用いたホストの機能概略を示すブロック図。
【図７】他の従来例を示し、ＩｎｆｉｎｉＢａｎｄのアダプタを用いたホストの機能概略を示すブロック図。
【図８】同じく、従来例を示し、アダプタからの割り込み処理を示すタイムチャートである。
【符号の説明】
１ ホスト
４ カーネル
６ アダプタ
４１ スケジューラ
４２ プロセステーブル
６１〜６３ エンドポイント
６５〜６７ 状態変更機構
Claims (2)
- １つ以上のＣＰＵと、主記憶手段と、外部装置または外部ネットワークとのデータ入出力を行うためのInfiniBandアダプタとを備えた情報処理装置が、オペレーティングシステム上で複数のアプリケーションを実行し、当該アプリケーションと前記InfiniBandアダプタとの間で通信を行う入出力方法において、
前記アプリケーションの各々に、前記InfiniBandアダプタ上の通信エンドポイントを割り当て、各アプリケーションと前記InfiniBandアダプタに割り当てた通信エンドポイントとの間の論理接続をそれぞれ確立するステップと、
前記論理接続のそれぞれが確立したときに、前記エンドポイントのそれぞれに対応して設けられた状態変更機構に対し、前記オペレーティングシステム内のスケジューラが管理するプロセステーブル内の、当該通信エンドポイントの接続相手である前記アプリケーションの状態を示す主記憶アドレスを記録するステップと、
前記論理接続のひとつのデータの送受信時に、前記論理接続に対応するアプリケーションがブロッキング呼び出しを使用した場合に、前記オペレーティングシステムに含まれるプロトコル処理により、前記プロセステーブルに記録した前記アプリケーションの状態をＩＯ待ち状態に変更するステップと、
前記InfiniBandアダプタが、前記論理接続のデータ送受信を完了したときに、当該論理接続に対応する前記状態変更機構内に記録した主記憶アドレスにより前記接続相手であるアプリケーションの状態を示すエントリを特定して、当該エントリの値を「実行可能」を示す値に変更するステップと、
前記InfiniBandアダプタが起動する割り込み、もしくはタイマ割り込みにより、前記スケジューラを呼び出し、前記通信相手であるアプリケーションを実行させるステップと、
を含むことを特徴とする入出力方法。 - 前記エントリの値を「実行可能」を示す値に変更するステップの後に、アイドル状態のＣＰＵが現に存在することを示すフラグをチェックするステップを有し、該フラグが真であると確認されたら前記InfiniBandアダプタから前記スケジューラへの割り込みを実行することを特徴とする請求項１の入出力方法。
Priority Applications (2)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002139572A JP4317348B2 (ja) | 2002-05-15 | 2002-05-15 | 情報処理装置及び入出力方法並びにプログラム |
| US10/320,607 US7336664B2 (en) | 2002-05-15 | 2002-12-17 | Data processing device and its input/output method and program |
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| JP2002139572A JP4317348B2 (ja) | 2002-05-15 | 2002-05-15 | 情報処理装置及び入出力方法並びにプログラム |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2003330873A JP2003330873A (ja) | 2003-11-21 |
| JP4317348B2 true JP4317348B2 (ja) | 2009-08-19 |
Family
ID=29416910
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002139572A Expired - Fee Related JP4317348B2 (ja) | 2002-05-15 | 2002-05-15 | 情報処理装置及び入出力方法並びにプログラム |
Country Status (2)
| Country | Link |
|---|---|
| US (1) | US7336664B2 (ja) |
| JP (1) | JP4317348B2 (ja) |
Families Citing this family (6)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US20050050187A1 (en) * | 2003-09-03 | 2005-03-03 | International Business Machines Corporation | Method and apparatus for support of bottleneck avoidance in an intelligent adapter |
| US7484016B2 (en) * | 2004-06-30 | 2009-01-27 | Intel Corporation | Apparatus and method for high performance volatile disk drive memory access using an integrated DMA engine |
| US20060031837A1 (en) * | 2004-08-05 | 2006-02-09 | International Business Machines Corporation | Thread starvation profiler |
| US7639715B1 (en) * | 2005-09-09 | 2009-12-29 | Qlogic, Corporation | Dedicated application interface for network systems |
| US7735099B1 (en) | 2005-12-23 | 2010-06-08 | Qlogic, Corporation | Method and system for processing network data |
| KR101409040B1 (ko) * | 2012-11-22 | 2014-06-18 | 엘에스산전 주식회사 | 피엘씨 시스템의 데이터 처리 장치 및 방법 |
Family Cites Families (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US6370592B1 (en) * | 1997-11-04 | 2002-04-09 | Hewlett-Packard Company | Network interface device which allows peripherals to utilize network transport services |
| US6687905B1 (en) * | 2000-08-11 | 2004-02-03 | International Business Machines Corporation | Multiple port input/output job scheduling |
| US6938111B2 (en) * | 2002-04-19 | 2005-08-30 | Siemens Aktiengesellschaft | Method for operating automation control equipment applications |
-
2002
- 2002-05-15 JP JP2002139572A patent/JP4317348B2/ja not_active Expired - Fee Related
- 2002-12-17 US US10/320,607 patent/US7336664B2/en not_active Expired - Fee Related
Also Published As
| Publication number | Publication date |
|---|---|
| JP2003330873A (ja) | 2003-11-21 |
| US20030214909A1 (en) | 2003-11-20 |
| US7336664B2 (en) | 2008-02-26 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| US10365830B2 (en) | Method, device, and system for implementing hardware acceleration processing | |
| US7496699B2 (en) | DMA descriptor queue read and cache write pointer arrangement | |
| US20180375782A1 (en) | Data buffering | |
| JP5364773B2 (ja) | クライアントとサーバ間の接続を管理するためのシステムおよび方法 | |
| EP2240852B1 (en) | Scalable sockets | |
| US7200695B2 (en) | Method, system, and program for processing packets utilizing descriptors | |
| US20020091826A1 (en) | Method and apparatus for interprocessor communication and peripheral sharing | |
| US7937499B1 (en) | Methods and apparatus for dynamically switching between polling and interrupt mode for a ring buffer of a network interface card | |
| JPH09231157A (ja) | コンピュータに接続されている入力／出力（ｉ／ｏ）デバイスを制御する方法 | |
| JP4788124B2 (ja) | データ処理システム | |
| WO2010043619A1 (en) | Data communications through a host fibre channel adapter | |
| US20050097226A1 (en) | Methods and apparatus for dynamically switching between polling and interrupt to handle network traffic | |
| US7552232B2 (en) | Speculative method and system for rapid data communications | |
| CN115298656A (zh) | 用于调度可共享pcie端点设备的系统和方法 | |
| US7209971B1 (en) | Architecture and run-time environment for network filter drivers | |
| US20040223504A1 (en) | Apparatus and method for workflow-based routing in a distributed architecture router | |
| JPH065524B2 (ja) | 記憶装置管理方法 | |
| JP4317348B2 (ja) | 情報処理装置及び入出力方法並びにプログラム | |
| JP2002208981A (ja) | 通信方法 | |
| WO2007074343A2 (en) | Processing received data | |
| US20020194332A1 (en) | Method and apparatus to manage resources for a multi-threaded device driver | |
| CN113162932B (zh) | 一种基于套接字的异步i/o操作的方法和装置 | |
| KR960006472B1 (ko) | TICOM IOP 환경에서 FDDI펌웨어(firmware) 구동방법 | |
| CN117743252A (zh) | 基于Mailbox的异构Soc子系统间通信的方法 | |
| Kcholi | Network Driver Interface Specification and Network Device Drivers |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A621 | Written request for application examination |
Free format text: JAPANESE INTERMEDIATE CODE: A621 Effective date: 20050406 |
|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20070823 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070911 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20071112 |
|
| A02 | Decision of refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A02 Effective date: 20080805 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20081006 |
|
| A911 | Transfer to examiner for re-examination before appeal (zenchi) |
Free format text: JAPANESE INTERMEDIATE CODE: A911 Effective date: 20081010 |
|
| TRDD | Decision of grant or rejection written | ||
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090519 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090522 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120529 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120529 Year of fee payment: 3 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130529 Year of fee payment: 4 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20130529 Year of fee payment: 4 |
|
| LAPS | Cancellation because of no payment of annual fees |