JP2008020977A - ネットワークプロセッサシステムおよびネットワークプロトコル処理方法 - Google Patents

Abstract

【課題】リモートダイレクトメモリアクセス（ＲＤＭＡ）を利用するためには、ＲＤＭＡ対応のＮＩＣが必要であり、コストがかかる。
【解決手段】ＲＤＭＡ機能をエミュレートするマルチプロセッサシステムを提供する。第１のサブプロセッシングユニット（ＳＰＵ）２２は、送信すべきメッセージを生成する。第２のＳＰＵ２１は、リモートダイレクトメモリアクセス機能をエミュレートするプロセッサであり、第１のＳＰＵ２２からの通知を受けて、メッセージをＲＤＭＡプロトコルにしたがったパケットに組み立てる。第３のＳＰＵ２０は、ＴＣＰ／ＩＰプロトコル処理を実行するプロセッサであり、第２のＳＰＵ２１からの通知を受けて、ＲＤＭＡプロトコルにしたがって生成されたパケットをＴＣＰ／ＩＰパケットに組み立て、ネットワークインターフェースカード（ＮＩＣ）３０から送出する。
【選択図】図３

Description

この発明は、ネットワークプロセッサシステムおよびネットワークプロトコル処理方法に関する。

近年のネットワーク技術の進歩により、ギガビットネットワークの利用が広がるなど、ネットワークの帯域が著しく伸びている。その一方で、ネットワークを流れるパケットを処理するマイクロプロセッサの処理性能はネットワーク性能に比べてそれほど向上していないのが現状である。そのため、高速なネットワークを流れるパケットをマイクロプロセッサが十分な速度で処理することは難しい。特に、ネットワークの帯域幅が１Ｇｂｐｓ（giga bit per second）を越えるあたりからマイクロプロセッサの処理性能がネットワークの帯域幅に対してボトルネックとなる。

プロセッサの処理性能がボトルネックになる原因は、大きく分けて次の３つである。
（１）ＴＣＰ（Transmission Control Protocol）処理
（２）コンテキストスイッチ
（３）メモリ間コピー

（１）のＴＣＰ処理とは、ＴＣＰにおけるチェックサムや再送制御など、計算量の多い処理であり、プロセッサへの負荷が大きくなる。この問題を解決するために、ＴＣＰオフロードエンジン（TCP Offload Engine; TOE)と呼ばれる技術があり、ＴＣＰにおける各処理を実行する専用のハードウェアがネットワークインタフェースカード（ＮＩＣ）に実装される。このようなＴＣＰオフロードエンジンが搭載されたネットワークインタフェースカードはＴＯＥ−ＮＩＣと呼ばれる。この場合、送受信バッファはＴＯＥ−ＮＩＣ内に設けられる。

（２）のコンテキストスイッチとは、パケット処理をするためにユーザモードとカーネルモードの間でコンテキストスイッチが行われることであり、このコンテキストスイッチがオーバーヘッドとなり、全体の処理性能のボトルネックとなる。この問題を解決するために、カーネルによるプロトコル処理をスキップするカーネルバイパスなどの実装技術が検討されている。

（３）のメモリ間コピーとは、パケットを処理する過程でパケットのデータが複数のメモリ間でコピーされることである。まず、ネットワークインタフェースカードがカーネルのバッファに受信パケットを書き込む。ＣＰＵはカーネルのバッファ内のパケットを解析した後、アプリケーションのバッファにパケットを書き込む。この処理過程でカーネルバッファからアプリケーションバッファへパケットのデータがコピーされており、このメモリ間コピーがオーバーヘッドとなる。

メモリ間コピーの問題を解決するために、リモートダイレクトメモリアクセス（ＲＤＭＡ）と呼ばれる技術の実装が行われている。ＣＰＵを介さずに各種デバイスとＲＡＭの間で直接データ転送する方式がダイレクトメモリアクセス（ＤＭＡ）であるが、ＲＤＭＡは、このＤＭＡ機能をネットワークに拡張したものである。ＲＤＭＡは、あるコンピュータのメモリから別のコンピュータのメモリに直接データを移動させることで、ＣＰＵ処理のオーバーヘッドをなくす。ＲＤＭＡを利用するためには、ＴＣＰ／ＩＰネットワークの場合、ＲＤＭＡ対応のネットワークインタフェースカード（ＲＮＩＣ；RDMA-enabled NIC）を用いる必要がある。一般に、ＲＮＩＣはＴＯＥ機能とＲＤＭＡ機能を合わせもつネットワークインタフェースカードである。

今後ますます高速化するネットワークに対応するために、マイクロプロセッサへの処理負荷を減らすことが通信の効率化のために重要な課題となっている。そのためのひとつの解決策が前述のＲＤＭＡである。しかしながら、ＲＤＭＡを利用するためには、ＲＮＩＣと呼ばれる、ＲＤＭＡ対応の特別なネットワークインタフェースカードが必要であり、これまで使用されていた通常のネットワークインタフェースカードでは、ＲＤＭＡを利用することができない。現在使用中のＮＩＣをすべてＲＤＭＡ対応のＲＮＩＣに入れ換えることは、たいへんなコストがかかる。これはＲＤＭＡの普及を遅らせている一因である。

また、一部のネットワークインタフェースカードだけをＲＤＭＡ対応にすることで従来のＮＩＣとＲＮＩＣとが混在するネットワークを構成した場合、従来のＮＩＣとＲＮＩＣの間で通信ができないという問題が生じる。

本発明はこうした課題に鑑みてなされたものであり、その目的は、ＲＤＭＡ機能を前提とした通信を効率良く行うことのできる通信技術を提供することにある。

上記課題を解決するために、本発明のある態様のネットワークプロセッサシステムは、リモートダイレクトメモリアクセス機能をエミュレートする第１プロセッサと、前記第１プロセッサによりリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、前記バッファからパケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施す第２プロセッサと、前記第２プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信するネットワークインターフェースカードとを含む。

本発明の別の態様もまた、ネットワークプロセッサシステムである。このネットワークプロセッサシステムは、ユーザレベルで処理を実行するプロセッサであって、送信すべきメッセージをユーザ空間に生成する第１プロセッサと、カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートするプロセッサであって、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てる第２プロセッサと、前記第２プロセッサから出力される前記リモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、カーネルレベルでＴＣＰ／ＩＰプロトコル処理を実行するプロセッサであって、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコルにしたがったパケットに組み立てる第３プロセッサと、前記第３プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信するネットワークインターフェースカードとを含む。

本発明のさらに別の態様もまた、ネットワークプロセッサシステムである。このネットワークプロセッサシステムは、リモートダイレクトメモリアクセス機能をエミュレートするプロセッサと、前記プロセッサから出力されるリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すためのＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードとを含む。

本発明のさらに別の態様もまた、ネットワークプロセッサシステムである。このネットワークプロセッサシステムは、ユーザレベルで処理を実行するプロセッサであって、送信すべきメッセージをユーザ空間に生成する第１プロセッサと、カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートするプロセッサであって、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てる第２プロセッサと、前記第２プロセッサから出力される前記リモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードとを含む。

本発明のさらに別の態様もまた、ネットワークプロセッサシステムである。このネットワークプロセッサシステムは、リモートダイレクトメモリアクセス機能をエミュレートする第１プロセッサと、前記第１プロセッサによりリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施す第２プロセッサと、前記第２プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信する第１ネットワークインタフェースカードと、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すためのＴＣＰ／ＩＰオフロード機能をもつ第２ネットワークインタフェースカードとを含む。前記第１プロセッサは、前記パケットの送信元ＩＰアドレスを前記第１ネットワークインタフェースカードのＭＡＣアドレスまたは前記第２ネットワークインタフェースカードのＭＡＣアドレスに対応づけたテーブルを参照して、前記パケットの送信元ＩＰアドレスに応じて、前記パケットを送出するためのネットワークインタフェースを前記第１ネットワークインタフェースカードまたは前記第２ネットワークインタフェースカードのいずれかに振り分ける機能を有する。前記パケットが前記第１ネットワークインタフェースカードに振り分けられる場合は、前記パケットは、前記第２プロセッサによりＴＣＰ／ＩＰプロトコル処理がなされて、前記第１ネットワークインタフェースカードから送出され、前記パケットが前記第２ネットワークインタフェースカードに振り分けられる場合は、前記パケットは、前記第２ネットワークインタフェースカードのＴＣＰ／ＩＰオフロード機能によりＴＣＰ／ＩＰプロトコル処理がなされて、前記第２ネットワークインタフェースカードから送出される。

本発明のさらに別の態様は、ネットワークプロトコル処理方法である。この方法は、ユーザレベルで処理を実行する第１プロセッサが、送信すべきメッセージをユーザ空間に生成するステップと、カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサが、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップと、カーネルレベルでＴＣＰ／ＩＰプロトコル処理を実行する第３プロセッサが、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコルにしたがったパケットに組み立てるステップとを含む。

本発明のさらに別の態様もまた、ネットワークプロトコル処理方法である。この方法は、ユーザレベルで処理を実行する第１プロセッサが、送信すべきメッセージをユーザ空間に生成するステップと、カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサが、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップと、ネットワークインタフェースカード内でＴＣＰ／ＩＰオフロード機能を実行する第３プロセッサが、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すステップを実行する。

なお、以上の構成要素の任意の組合せ、本発明の表現を方法、装置、システム、コンピュータプログラム、プログラム製品、データ構造、記録媒体などの間で変換したものもまた、本発明の態様として有効である。

本発明によれば、ＲＭＤＡ機能を利用した効率の良い通信を行うことができる。

以下、図面を参照し、本発明の実施の形態を説明する。なお、以下に述べる実施の形態は、本発明の好適な具体例であるから、技術的に好ましい種々の限定が付されているが、本発明の範囲は以下の説明において、特に本発明を限定する旨の記載がない限り、これらの形態に限定されるものではない。

また、実施の形態では、カーネルモードおよびユーザモードに分けてプロトコル処理を説明するが、これは一例に過ぎず、各プロトコルスタックが実装されるべきモードを限定する趣旨ではない。なお、カーネルモード、ユーザモードは、それぞれカーネルレベル、ユーザレベルとも呼ばれる。

さらに、ＲＤＭＡ機能を実行するプロセッシングエレメントとして、マルチプロセッサのひとつを用いたが、ＲＤＭＡ機能だけを実行するために、別チップのＣＰＵを用いることも可能である。

実施の形態１
図１は、本発明の実施の形態に係るネットワークシステムを示す図である。ネットワーク１００には、複数のノード２００ａ、２００ｂ、２００ｃ、…、２００ｎが接続されている。以下、ネットワーク１００に接続されたノードを総称するときは、単にノード２００という。ネットワーク１００はルータを含み、ＩＰ（Internet Protocol）にしたがってパケットを転送する。

図２は、図１のノード２００の構成図である。各ノード２００は、マイクロプロセッシングユニット（ＭＰＵ）２１０、メインメモリ２２０、Ｉ／Ｏブリッジ２４０、およびネットワークインタフェースカード（ＮＩＣ）２３０を含む。

ＭＰＵ２１０は、メインメモリ２２０に保持された送信すべきデータに宛先アドレスなどのヘッダ情報を付加したパケットを生成し、Ｉ／Ｏブリッジ２４０を介してＮＩＣ２３０のバッファにパケットを渡す。ＮＩＣ２３０は、バッファ内に蓄積されたパケットをネットワーク１００に送出する。

ＮＩＣ２３０はネットワーク１００から受信されたパケットをバッファに蓄積し、Ｉ／Ｏブリッジ２４０を介してＭＰＵ２１０にパケットを渡す。ＭＰＵ２１０はパケットのヘッダを解析し、パケット内のデータをメインメモリ２２０に格納する。

図３は、図２のノード２００のＭＰＵ２１０に実装されたＴＣＰ／ＩＰプロトコルスタックおよびＲＤＭＡ機能を説明する図である。これらの機能は、ハードウェアとソフトウェアの組み合わせにより構成され、ソフトウェアはユーザモードおよびカーネルモードで動作する。

ハードウェアの構成として各ノード２００にはＮＩＣ２３０とＭＰＵ２１０がある。ＮＩＣ２３０として、同図に示したように、ＴＯＥ機能のないＮＩＣ３０またはＴＯＥ機能が搭載されたＴＯＥ−ＮＩＣ３１のいずれか、あるいは両方が用いられる。ＭＰＵ２１０は、ここでは、プロセッシングユニット（ＰＵ）とサブプロセッシングユニット（ＳＰＵ）を含むマルチプロセッサで構成される。ここで、ＰＵとＳＰＵは処理性能や構成が異なるプロセッシングエレメントである。一例としてＰＵは、メインメモリ２２０のデータをキャッシュするためのハードウェアキャッシュ機構を有するが、ＳＰＵは、ハードウェアキャッシュ機構がなく、ローカルメモリをもつ。

ユーザモードで動作するソフトウェアとして、アプリケーションプログラム１１ｕ−１、２２ｕ−１、ソケットＡＰＩ１１ｕ−２、２２ｕ−２およびソケットスイッチ５０がある。ソケットスイッチ５０は、パケットのプロトコルがＴＣＰあるいはＳＤＰ（ソケットダイレクトプロトコル）のどちらであるかを判別して、パケットの供給先を切り替える。ここで、ＳＤＰとは、既存のソケットプログラムへ変更を加えることなくＲＤＭＡ機能を実現するためのプロトコルである。ソケットスイッチ５０の働きにより、ＲＤＭＡ機能を前提とするパケットはＲＤＭＡ機能を実装したカーネルレベルのプロトコルスタック２１ｒに渡され、ＲＤＭＡ機能を必要としない通常のＴＣＰのパケットはＲＤＭＡ機能が実装されていないカーネルレベルのプロトコルスタック１０ｓ、２０ｓに渡される。

カーネルモードで動作するソフトウェアとして、次の３つがある。
（１）ＰＵ１０上で動作するＴＣＰ／ＩＰプロトコルスタック１０ｓ、
（２）ＳＰＵ２０上で動作するＴＣＰ／ＩＰプロトコルスタック２０ｓ、および
（３）ＳＰＵ２１上で動作するＲＤＭＡプロトコルスタック２１ｒ。

ＲＤＭＡプロトコルスタック２１ｒは、既存のソケットプログラムを変更することなしにＲＤＭＡ動作を可能とするために、ソケット層２１ｒ−１とＳＤＰ層２１ｒ−２を含む。これらのレイヤの下にＲＤＭＡ層２１ｒ−３があり、ＲＤＭＡリード（read）、ＲＤＭＡライト（write）などのＲＤＭＡコマンドがＤＤＰ（Direct Data Placement）メッセージに変換される。ＲＤＭＡ層２１ｒ−３の下には、ＤＤＰ層２１ｒ−４がある。ＤＤＰ層２１ｒ−４は、送信の際、ＤＤＰメッセージを１つまたは複数のＤＤＰセグメントに分割し、受信の際、１つまたは複数のＤＤＰセグメントをＤＤＰメッセージにリアセンブルする。

ＤＤＰ層２１ｒ−４の下には、ＭＰＡ（Marker Protocol-data-unit Aligned）層２１ｒ−５がある。ＭＰＡ層２１ｒ−５は、ＤＤＰセグメントに一定間隔で逆変換マーカーを付加し、各ＭＰＡセグメントにＤＤＰセグメントのデータ長と誤り検出のためのＣＲＣ（Cyclic Redundancy Check）を付加する。ＭＰＡ層２１ｒ−５の下には、ＴＣＰ／ＩＰプロトコルスタックが実装される。

ＴＣＰ／ＩＰプロトコルスタックの実装方法として、（ａ）ＰＵ１０またはＳＰＵ２０にカーネルモードで動作するソフトウェアとして実装する方法と、（ｂ）ＴＯＥ−ＮＩＣ３１内のＴＣＰオフロードエンジン（ＴＯＥ）機能としてハードウェアで実装する方法とがある。後者の場合、ＲＤＭＡプロトコルスタック２１ｒにより処理されたパケットは、デバイスドライバ２１ｒ−６、ＳＰＵ２１、Ｉ／Ｏブリッジ２４０を経由して、ＴＯＥ−ＮＩＣ３１に渡され、ＴＯＥ機能によりＴＣＰ／ＩＰプロトコル処理がなされ、ネットワークに送出される。

一方、ＴＯＥ機能が実装されていないＮＩＣ３０の場合には、ＰＵ１０またはＳＰＵ２０にカーネルモードで動作するソフトウェアとして実装された、ＴＣＰ／ＩＰプロトコルスタック１０ｓ、２０ｓを用いてＴＣＰ／ＩＰプロトコル処理を行う必要がある。

上記の（ａ）ＴＯＥ機能なしの実装と（ｂ）ＴＯＥ機能ありの実装の切り換えは、システム起動時に設定ファイルの情報を用いて行う。以下、（ａ）ＴＯＥ機能なしの実装の構成と動作を実施例１として説明し、（ｂ）ＴＯＥ機能ありの実装の構成と動作を実施例２として説明する。また、ノード２００内にＴＯＥ機能のない通常のＮＩＣ３０とＴＯＥ機能付きのＴＯＥ−ＮＩＣ３１がともに実装されている場合の構成と動作を実施例３として説明する。

ＲＤＭＡプロトコルスタック２１ｒとＴＣＰ／ＩＰプロトコルスタック１０ｓ、２０ｓはＭＰＵ２１０の各プロセッサ上に常駐することを基本とするが、ＲＤＭＡ機能を用いない場合には、ＲＤＭＡプロトコルスタック２１ｒはサスペンドされ、他のプロセスが動作してもよい。これは、ＴＣＰ／ＩＰプロトコルスタック１０ｓ、２０ｓについても同様である。

実施例１
図４は、実施例１のノード２００の構成図である。実施例１では、ノード２００にはＴＯＥ機能のない通常のＮＩＣ３０が搭載されており、システム起動時の設定により、ＮＩＣ３０が動作可能になるため、動作しないＴＯＥ−ＮＩＣ３１に関わる構成については図示していない。実施例１では、ＴＣＰ／ＩＰプロトコルスタックはＰＵ１０またはＳＰＵ２０上に実装される。ＰＵ１０およびＳＰＵ２０上のＴＣＰ／ＩＰプロトコルスタック１０ｓおよび２０ｓは同時に動作することも可能であるし、どちらかが休止していてもかまわない。

ＲＤＭＡ動作の一例として、ＲＤＭＡライトについて説明する。図１の２つのノード２００ａと２００ｂ間でＲＤＭＡライトが実行されるとする。発行元ノード２００ａが発行先ノード２００ｂに対してＲＤＭＡライト命令を発行し、ＲＤＭＡライトされるべきデータを発行先ノード２００ｂに送信する。

図５は、発行元ノード２００ａと発行先ノード２００ｂの間で行われるＲＤＭＡライト処理のシーケンス図である。はじめに、発行元ノード２００ａから発行先ノード２００ｂへＲＤＭＡライトのリクエストが発行される（Ｓ１０）。このリクエスト時にＲＤＭＡライトされるデータのサイズ等の情報が送信される。その後、発行元ノード２００ａは、自ノード内のメインメモリ２２０ａにＲＤＭＡライトすべきデータを準備する（Ｓ１２）。

一方、発行先ノード２００ｂは、発行元ノード２００ａから発行されたＲＤＭＡライトのリクエストに対して、自ノード内のメインメモリ２２０ｂにＲＤＭＡライト用のメモリ領域を確保する（Ｓ１４）。発行先ノード２００ｂにデータが受信されると、自ノードのＮＩＣ３０ｂがカーネルモードのソフトウェアに割り込み信号を送ることで、受信データの存在をカーネルに知らせる。

発行先ノード２００ｂは、ＲＤＭＡライト用メモリ領域を確保した後、発行元ノード２００ａに向けて、レディ（Ready）メッセージを送信する（Ｓ１６）。

発行元ノード２００ａは、発行先ノード２００ｂからレディメッセージを受信した後、ＲＤＭＡライトを実行する（Ｓ１８）。なお、発行元のノード２００ａは、メッセージの受信を自ノードのＮＩＣ３０から割り込みが入ることで検出することができる。

発行元のノード２００ａは、ＲＤＭＡライトが完了した後に、完了メッセージを発行先ノード２００ｂに送信する（Ｓ２０）。以上で、ＲＤＭＡライトの処理が完了する。

図６および図７Ａを参照し、図５のＲＤＭＡライト処理シーケンスの各ステップが図４の構成によって実行される様子を詳しく説明する。図６は、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用しないＴＣＰによる送受信動作を示す図である。一方、図７Ａは、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用するＳＤＰによる送受信動作を示す図である。

以下では、ＴＣＰ／ＩＰプロトコルスタックがＳＰＵ２０に実装されている場合について動作を説明するが、ＴＣＰ／ＩＰプロトコルスタックがＰＵ１０に実装されている場合の動作も基本的には同様である。

（１）ステップＳ１０の動作
図４において、発行元ノード２００ａのユーザ空間にあるアプリケーションプログラム１１ｕ−１または２２ｕ−１により、ＲＤＭＡライトのリクエストが発行される。ここで、アプリケーションプログラム１１ｕ−１、２２ｕ−１はそれぞれ発行元ノード２００ａのＰＵ１１、ＳＰＵ２２で実行される。ここでは、アプリケーションプログラム１１ｕ−１、２２ｕ−１を実行するＰＵ１１、ＳＰＵ２２と、プロトコルスタックを実行するＰＵ１０ａ、ＳＰＵ２０、２１は異なるものとして説明するが、アプリケーションプログラムとプロトコルスタックを実行するＰＵあるいはＳＰＵは同一であってもかまわない。

発行元ノード２００ａのソケットスイッチ５０は、ＲＤＭＡライトのリクエストが通常のＴＣＰ／ＩＰにより送信されるべきであることを識別する。この識別は、発行元ノード２００ａのソケットＡＰＩ１１ｕ−２あるいは２２ｕ−２において、以下のコマンドを実行することで実現される。
socket(AF_INET, SOCK_STREAM, 0);
ここで、socketコマンドの第１引数AF_INETは、ＩＰｖ４のインターネットプロトコルであることを示す。第２引数SOCK_STREAMは通信がコネクション型であることを示す。第３引数の０は通常のＴＣＰ／ＩＰプロトコルを用いることを示す。

ＲＤＭＡライトのリクエストメッセージは、発行元ノード２００ａのＳＰＵ２０上に実装されたＴＣＰ／ＩＰプロトコルスタック２０ｓを経由することで、ＲＤＭＡライトのリクエストパケットへと組み立てられる。

図６を参照して、ＲＤＭＡライトのリクエストパケットの生成過程を説明する。発行元ノード２００ａにおいて、ユーザレベルで動作中のＳＰＵ２２ａは、ユーザ空間にあるアプリケーション用バッファ２２２ａにＲＤＭＡライトのリクエストメッセージ２２３ａを生成する。その後、ユーザレベルで動作中のＳＰＵ２２ａは、カーネルレベルで動作中のＳＰＵ２０ａに対してイベント通知することにより、パケットの組み立ての開始を通知する。このイベント通知には、アトミック命令のような同期機能を用いてもよく、ＳＰＵにイベント通知用のレジスタやメールボックスなどを設けることにより実現してもよい。

カーネルレベルのＳＰＵ２０ａは、アプリケーション用バッファ２２２ａからＲＤＭＡライトのリクエストメッセージ２２３ａを読み出し、そのリクエストメッセージ２２３ａにヘッダを付加し、カーネル空間にあるＴＣＰ／ＩＰ送受信バッファ２２４ａにＲＤＭＡライトのリクエストパケット２２５ａを生成する。生成されたリクエストパケット２２５ａは発行元ノード２００ａのＮＩＣ３０ａから送出される。

（２）ステップＳ１２の動作
発行元ノード２００ａにおいてＲＤＭＡライトのリクエストの発行が終わると、図７Ａに示すように、発行元ノード２００ａのユーザモードにあるＳＰＵ２２ａがアプリケーションを実行し、ＲＤＭＡライトにより書き込むべきＲＤＭＡメッセージ２２７ａをアプリケーション用バッファ２２２ａに書き込み、ＲＤＭＡライト用のデータを準備する。

（３）ステップＳ１４の動作
一方、発行先ノード２００ｂは、ステップＳ１０において発行元ノード２００ａが発行したＲＤＭＡライトのリクエストを受け取り、ＲＤＭＡライト用のメモリ領域を準備する。図６に示すように、発行先ノード２００ｂのＮＩＣ３０ｂはネットワーク１００からＲＤＭＡライトのリクエストパケット２２５ｂを受信し、ＴＣＰ／ＩＰ送受信バッファ２２４ｂにコピーする。

発行先ノード２００ｂのカーネルモードにあるＳＰＵ２０ｂは、ＴＣＰ／ＩＰ送受信バッファ２２４ｂに受信されたＲＤＭＡライトのリクエストパケット２２５ｂを解析し、パケット内のリクエストメッセージ２２３ｂをリアセンブルしてユーザ空間のアプリケーション用バッファ２２２ｂにコピーする。その後、カーネルモードにあるＳＰＵ２０ｂは、ユーザモードにあるＳＰＵ２２ｂにイベント通知し、ＲＤＭＡライトのリクエストメッセージが受信されたことを通知する。

カーネルモードにあるＳＰＵ２０ｂからイベント通知を受けた、ユーザモードにあるＳＰＵ２２ｂはアプリケーション２２ｕ−１を実行し、ＲＤＭＡライトのリクエストメッセージ２２３ｂを読み、アプリケーション用バッファ２２２ｂ内にＲＤＭＡライトに必要なメモリ領域（「ＲＤＭＡライト用領域」という）２２６ｂを確保する。

（４）ステップＳ１６の動作
その後、発行先ノード２００ｂのユーザ空間にあるアプリケーション２２ｕ−１は、レディメッセージを発行元ノード２００ａに返信する。ＲＤＭＡライトのリクエストメッセージの場合と同様、レディメッセージは、発行先ノード２００ｂのソケットスイッチ５０がＴＣＰ／ＩＰプロトコルを指定したコマンドを実行することにより、通常のＴＣＰ／ＩＰプロトコルにしたがって、ＴＣＰ／ＩＰプロトコルスタック２０ｓにより処理され、ＮＩＣ３０ｂから送信される。

（５）ステップＳ１８の動作
図４および図７Ａを参照して、ＲＤＭＡライトの動作を詳しく説明をする。発行元ノード２００ａにおいてアプリケーションプログラム１１ｕ−１あるいは２２ｕ−１がＲＤＭＡライトのコマンドを発行する。その際、ソケットＡＰＩ１１ｕ−２あるいは２２ｕ−２は、
socket(AF_INET_SDP, SOCK_STREAM, 0);
というコマンドを用いる。ここで、第１引数"AF_INET_SDP"は、通信プロトコルとしてＳＤＰを用いてＲＤＭＡ機能を実行することを意味する。それ以外のパラメータは前述の通りである。

ソケットスイッチ５０がsocketコマンドの第１引数によってＲＤＭＡ動作であることを認識し、ＲＤＭＡプロトコルスタックが実装されているＳＰＵ２１ａにイベント通知し、ＳＰＵ２１ａがＲＤＭＡパケットを生成する。

図７Ａを参照して、ＲＤＭＡパケットの生成過程を説明する。発行元ノード２００ａにおいて、ユーザモードのＳＰＵ２２ａからイベント通知を受け取ったカーネルモードのＳＰＵ２１ａは、ユーザ空間にあるアプリケーション用バッファ２２２ａ内のＲＤＭＡメッセージ２２７ａをセグメント化し、ＲＤＭＡパケットを組み立て、ＦＩＦＯバッファ２２１ａにＲＤＭＡパケットをキューイングする。

ＦＩＦＯバッファ２２１ａは、ＲＤＭＡプロトコルスタックが実装されたＳＰＵ２１ａと、ＴＣＰ／ＩＰプロトコルスタックが実装されたＳＰＵ２０ａとの間で共有されており、ＳＰＵ２１ａはＳＰＵ２０ａにイベント通知し、ＦＩＦＯバッファ２２１ａに送信すべきＲＤＭＡパケットがあることを知らせる。イベント通知されたＳＰＵ２０ａは、ＦＩＦＯバッファ２２１ａにあるＲＤＭＡパケットをＴＣＰ／ＩＰパケットに組み立て、ＴＣＰ／ＩＰ送受信バッファ２２４ａにコピーする。ＮＩＣ３０ａは、ＴＣＰ／ＩＰ送受信バッファ２２４ａ内のＲＤＭＡパケット２２９ａをネットワーク１００に送出する。

一方、発行先ノード２００ｂにおいても、ソケットＡＰＩ１１ｕ−１あるいは２２ｕ−２によってＲＤＭＡ機能を使用することがsocketコマンドにより宣言される。そして、ソケットスイッチ５０により、ユーザレベルのＳＰＵ２２ｂからカーネルレベルのＳＰＵ２１ｂおよびＳＰＵ２０ｂへＲＤＭＡイベントがあることが通知される。

発行先ノード２００ｂのＮＩＣ３０ｂは、ネットワーク１００からＲＤＭＡパケット２２９ｂを受信し、ＴＣＰ／ＩＰ送受信バッファ２２４ｂへコピーする。ＴＣＰ／ＩＰプロトコルスタック２０ｓが実装されたＳＰＵ２０ｂは、ＴＣＰ／ＩＰ送受信バッファ２２４ｂ内のＲＤＭＡパケット２２９ｂをＴＣＰ／ＩＰプロトコルにしたがって解析し、ＦＩＦＯバッファ２２１ｂにＴＣＰ／ＩＰパケットをキューイングする。ＦＩＦＯバッファ２２１ｂは、ＴＣＰ／ＩＰプロトコルスタック２０ｓが実装されたＳＰＵ２０ｂとＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１ｂの間で共有されている。ＴＣＰ／ＩＰプロトコル処理の後、ＳＰＵ２０ｂは、ＲＤＭＡプロトコル処理を行うＳＰＵ２１ｂにイベント通知し、ＲＤＭＡパケットが受信されたことを知らせる。

ＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１ｂは、ＲＤＭＡプロトコルにしたがってＦＩＦＯバッファ２２１ｂにあるＲＤＭＡパケットを解析し、ＲＤＭＡライトすべきメッセージをリアセンブルし、アプリケーション用バッファ２２２ｂのＲＤＭＡライト用領域２２６ｂに書き込む。

（６）ステップＳ２０の動作
ＲＤＭＡライトの発行が終わると、発行元ノード２００ａは「完了」メッセージを発行先ノード２００ｂに送信する。「完了メッセージ」は、図６で説明した、ＲＤＭＡ機能を用いない通常のＴＣＰ／ＩＰパケットで送信される。発行先ノード２００ｂは「完了」メッセージを受信し、ＲＤＭＡライト用領域２２６ｂを解放し、ＲＤＭＡライトの動作を終了する。

以上述べたように、実施例１によれば、ＲＤＭＡプロトコル処理をソフトウェアでエミュレートすることにより、ＲＤＭＡ対応のＮＩＣでなくてもＲＤＭＡ機能を用いた通信を行うことができる。また、実施例１では、ノード２００内の複数のプロセッサが、ＴＣＰ／ＩＰプロトコル処理やＲＤＭＡプロトコル処理など個別の特定処理を専門に行う。同一のプロセッサがＴＣＰ／ＩＰプロトコル処理とＲＤＭＡプロトコル処理を担当すると、異なるプロトコル処理を行う際、コンテキストスイッチが生じ、オーバーヘッドとなる。実施例１では、マルチプロセッサシステムであることを利用して、ＴＣＰ／ＩＰプロトコル処理を行うプロセッサと、ＲＤＭＡプロトコル処理を行うプロセッサを別々に分けたため、コンテキストスイッチによるオーバーヘッドを低減することができ、高速なネットワーク処理を実現することができる。また、ＲＤＭＡ機能を使わない通信の際は、ＴＣＰ／ＩＰプロトコルスタックが実装されたプロセッサだけを利用して通信を行うことができる。

上記の実施の形態では、各ノード２００内にあるメインメモリ２２０にＴＣＰ／ＩＰ送受信バッファ２２４を設ける構成を説明したが、図７Ｂに示すように、各ノード２００に搭載されたＮＩＣ３０内にＴＣＰ／ＩＰ送受信バッファ２２４を設ける構成であってもよい。この場合、メインメモリ２２０とＮＩＣ３０内のバッファの間でＲＤＭＡパケット２２９をコピーする必要がなく、いわゆる「ゼロコピー」を実現することができ、メモリ間コピーによるオーバーヘッドをなくすことができる。

実施例２
図８は、実施例２のノード２００の構成図である。実施例１では、ＴＯＥ機能をもたない通常のＮＩＣ３０がノード２００に搭載されている場合を説明したが、実施例２では、ＴＯＥ機能をもつＴＯＥ−ＮＩＣ３１がノード２００に搭載されている場合を説明する。システム起動時の設定により、ＴＯＥ−ＮＩＣ３１が動作可能になるため、動作しないＮＩＣ３０に関わる構成については図示していない。ＴＯＥ−ＮＩＣ３１にはＴＣＰ／ＩＰプロトコルスタックが実装されており、ＴＯＥ−ＮＩＣ３１内部でＴＣＰ／ＩＰのプロトコル処理を行うことができる。

実施例２でも、実施例１と同様に、発行元ノード２００ａと発行先ノード２００ｂの間でＲＤＭＡライトが実行される場合の動作を説明する。発行元ノード２００ａと発行先ノード２００ｂの間で行われるＲＤＭＡライト処理のシーケンスは、実施例１の図５と同じである。図９および図１０を参照し、実施例２において、図５のＲＤＭＡライト処理シーケンスの各ステップが図８の構成によって実行される様子を詳しく説明する。図９は、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用しないＴＣＰによる送受信動作を示す図である。一方、図１０は、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用するＳＤＰによる送受信動作を示す図である。以下、実施例１と同様の動作については適宜説明を簡略にする。

（１）ステップＳ１０の動作
図８において、発行元ノード２００ａのユーザ空間にあるアプリケーションプログラム１１ｕ−１または２２ｕ−１により、ＲＤＭＡライトのリクエストが発行される。実施例１で説明したように、発行元ノード２００ａのソケットスイッチ５０は、ＲＤＭＡライトのリクエストが通常のＴＣＰ／ＩＰにより送信されるべきであることを識別する。実施例２では、ＲＤＭＡ動作をしない通常の通信もＲＤＭＡプロトコルスタックが実装されたＳＰＵ２１ａにおいて実行される。

発行元ノード２００ａのソケット層２１ｒ−１は、ソケットスイッチ５０のコマンドの引数により、ＲＤＭＡプロトコル処理を必要としない通常のＴＣＰ／ＩＰの通信であることを識別し、ＳＤＰ層２１ｒ−２、ＲＤＭＡ層２１ｒ−３、ＤＤＰ層２１ｒ−４、およびＭＰＡ層２１ｒ−５のＲＤＭＡプロトコルスタックをバイパスして、直接デバイスドライバ２１ｒ−６にＲＤＭＡライトのリクエストメッセージを渡す。

図９を参照する。発行元ノード２００ａにおいて、ユーザモードで動作しているＳＰＵ２２ａがＴＯＥ−ＮＩＣ３１ａ内のプロセッサ３２ａにイベント通知する。プロセッサ３２ａは、ユーザ空間のアプリケーション用バッファ２２２ａに書きこまれたＲＤＭＡライトのリクエストメッセージ２２３ａを読み出し、ＴＣＰ／ＩＰパケットとして組み立て、ＴＯＥ−ＮＩＣ３１ａ内に設けられたＴＣＰ／ＩＰ送受信バッファ２２４ａにＲＤＭＡライトのリクエストパケット２２５ａを書き込む。ＴＯＥ−ＮＩＣ３１ａは、ＴＣＰ／ＩＰ送受信バッファ２２４ａ内のリクエストパケット２２５ａをネットワーク１００に送信する。

（２）ステップＳ１２の動作
発行元ノード２００ａにおいてＲＤＭＡライトのリクエストの発行が終わると、図１０に示すように、発行元ノード２００ａのユーザモードにあるＳＰＵ２２ａがアプリケーションを実行し、ＲＤＭＡライトすべきＲＤＭＡメッセージ２２７ａをアプリケーション用バッファ２２２ａに書き込む。

（３）ステップＳ１４の動作
一方、発行先ノード２００ｂは、ステップＳ１０において発行元ノード２００ａが発行したＲＤＭＡライトのリクエストを受け取り、ＲＤＭＡライト用のメモリ領域を準備する。図９に示すように、発行先ノード２００ｂのＴＯＥ−ＮＩＣ３１ｂはネットワーク１００からＲＤＭＡライトのリクエストパケット２２５ｂを受信し、ＴＯＥ−ＮＩＣ３１ｂ内に設けられたＴＣＰ／ＩＰ送受信バッファ２２４ｂに格納する。

ＴＯＥ−ＮＩＣ３１ｂ内のプロセッサ３２ｂは、ＴＣＰ／ＩＰ送受信バッファ２２４ｂに受信されたＲＤＭＡライトのリクエストパケット２２５ｂを解析し、パケット内のリクエストメッセージ２２３ｂをリアセンブルしてユーザ空間のアプリケーション用バッファ２２２ｂにコピーする。その後、プロセッサ３２ｂは、ユーザモードにあるＳＰＵ２２ｂにイベント通知し、ＲＤＭＡライトのリクエストメッセージが受信されたことを通知する。

プロセッサ３２ｂからイベント通知を受けたＳＰＵ２２ｂはアプリケーション２２ｕ−１を実行し、ＲＤＭＡライトのリクエストメッセージ２２３ｂを読み、アプリケーション用バッファ２２２ｂ内にＲＤＭＡライトに必要なメモリ領域（「ＲＤＭＡライト用領域」）２２６ｂを確保する。

（４）ステップＳ１６の動作
その後、発行先ノード２００ｂのユーザ空間にあるアプリケーション２２ｕ−１は、レディメッセージを発行元ノード２００ａに返信する。ＲＤＭＡライトのリクエストメッセージの場合と同様、レディメッセージは、発行先ノード２００ｂのソケットスイッチ５０がＴＣＰ／ＩＰプロトコルを指定したコマンドを実行することにより、ＳＰＵ２１においてＲＤＭＡプロトコルスタックをスキップしてデバイスドライバ２１ｒ−６に渡され、ＴＯＥ−ＮＩＣ３１ｂのＴＯＥ機能によりＴＣＰ／ＩＰプロトコル処理がなされ、ネットワーク１００に送信される。

（５）ステップＳ１８の動作
図８および図１０を参照して、ＲＤＭＡライトの動作を詳しく説明をする。発行元ノード２００ａにおいてアプリケーションプログラム１１ｕ−１あるいは２２ｕ−１がＲＤＭＡライトのコマンドを発行する。

ソケットスイッチ５０がsocketコマンドの引数によってＲＤＭＡ動作であることを認識し、ＲＤＭＡプロトコルスタックが実装されているＳＰＵ２１ａにイベント通知し、ＳＰＵ２１ａがＲＤＭＡパケットを生成する。

図１０を参照して、ＲＤＭＡパケットの生成過程を説明する。発行元ノード２００ａにおいて、ユーザモードのＳＰＵ２２ａからイベント通知を受け取ったカーネルモードのＳＰＵ２１ａは、ユーザ空間にあるアプリケーション用バッファ２２２ａに書き込まれたＲＤＭＡメッセージ２２７ａをセグメント化し、ＲＤＭＡパケットを組み立て、ＦＩＦＯバッファ２２１ａにＲＤＭＡパケットをキューイングする。

ＦＩＦＯバッファ２２１ａは、ＲＤＭＡプロトコルスタックが実装されたＳＰＵ２１と、ＴＣＰ／ＩＰプロトコルスタックが実装されたプロセッサ３２ａとの間で共有されており、ＳＰＵ２１は、ＴＯＥ−ＮＩＣ３１ａ内のプロセッサ３２ａにイベント通知し、ＦＩＦＯバッファ２２１ａに送信すべきＲＤＭＡパケットがあることを知らせる。イベント通知されたプロセッサ３２ａは、ＦＩＦＯバッファ２２１ａにあるＲＤＭＡパケットをＴＣＰ／ＩＰパケットに組み立て、ＴＯＥ−ＮＩＣ３１ａ内に設けられたＴＣＰ／ＩＰ送受信バッファ２２４ａにコピーする。ＴＯＥ−ＮＩＣ３１ａは、ＴＣＰ／ＩＰ送受信バッファ２２４ａ内のＲＤＭＡパケット２２９ａをネットワーク１００に送出する。

一方、発行先ノード２００ｂにおいても、ソケットＡＰＩ１１ｕ−１あるいは２２ｕ−２によってＲＤＭＡ機能を使用することが宣言される。ソケットスイッチ５０により、ユーザレベルのＳＰＵ２２ｂからカーネルレベルのＳＰＵ２１ｂおよびＴＯＥ−ＮＩＣ３１ｂ内のプロセッサ３２ｂへＲＤＭＡイベントがあることが通知される。

発行先ノード２００ｂのＴＯＥ−ＮＩＣ３１ｂは、ネットワーク１００からＲＤＭＡパケット２２９ｂを受信し、ＴＣＰ／ＩＰ送受信バッファ２２４ｂに格納する。ＴＯＥ−ＮＩＣ３１ｂ内のプロセッサ３２ｂは、ＴＣＰ／ＩＰ送受信バッファ２２４ｂ内のＲＤＭＡパケット２２９ｂをＴＣＰ／ＩＰプロトコルにしたがって解析し、ＦＩＦＯバッファ２２１ｂにＴＣＰ／ＩＰパケットをキューイングする。ＦＩＦＯバッファ２２１ｂは、ＴＯＥ−ＮＩＣ３１ｂ内のプロセッサ３２ｂとＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１ｂの間で共有されている。ＴＣＰ／ＩＰプロトコル処理の後、プロセッサ３２ｂは、ＲＤＭＡプロトコル処理を行うＳＰＵ２１ｂにイベント通知し、ＲＤＭＡパケットが受信されたことを知らせる。

ＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１ｂは、ＲＤＭＡプロトコルにしたがってＦＩＦＯバッファ２２１ｂにあるＲＤＭＡパケットを解析し、ＲＤＭＡライトすべきメッセージをリアセンブルし、アプリケーション用バッファ２２２ｂのＲＤＭＡライト用領域２２６ｂに書き込む。

なお、ここで述べたＦＩＦＯバッファ２２１ａ、２２１ｂは必ずしも、各ノード２００ａ、２００ｂ内のメインメモリにある必要はなく、ＴＯＥ−ＮＩＣ３１ａ、３１ｂ内に設けられてもよい。

（６）ステップＳ２０の動作
ＲＤＭＡライトの発行が終わると、発行元ノード２００ａは「完了」メッセージを発行先ノード２００ｂに送信する。「完了メッセージ」は、図９で説明した、ＲＤＭＡ機能を用いない通常のＴＣＰ／ＩＰパケットで送信される。発行先ノード２００ｂは「完了」メッセージを受信し、ＲＤＭＡライト用領域２２６ｂを解放し、ＲＤＭＡライトの動作を終了する。

以上述べたように、実施例２によれば、ＲＤＭＡプロトコル処理をソフトウェアでエミュレートすることにより、ＲＤＭＡ対応のＮＩＣでなくてもＲＤＭＡ機能を用いた通信を行うことができる。また、実施例２では、マルチプロセッサシステムにおいて、ＲＤＭＡプロトコル処理を行うプロセッサをユーザレベルでアプリケーションを実行するプロセッサとは別に設けたことで、ＲＤＭＡプロトコル処理を効率良く実行することができる。また、ＮＩＣ内のＴＯＥ機能を実行するプロセッサが、ＲＤＭＡプロトコル処理を担当するプロセッサに負荷をかけないで、ＲＤＭＡプロトコル処理されたパケットをＴＣＰ／ＩＰプロトコル処理することができる。

実施例３
実施例１ではＴＯＥ機能をもたない通常のＮＩＣ３０を用いたＲＤＭＡ動作を説明し、実施例２ではＴＯＥ機能をもつＴＯＥ−ＮＩＣ３１を用いたＲＤＭＡ動作を説明した。実際には、ＮＩＣが複数枚実装されており、ＴＯＥ機能のないＮＩＣとＴＯＥ機能のあるＮＩＣが共存するネットワークノードの存在する。そのようなネットワークノードの一例としてルータがある。ルータはポート毎に異なるＮＩＣを搭載するため、複数の異なる種類のＮＩＣが共存することがある。また、別の例として、マルチプロセッサシステムにおいて各プロセッサに異なるＩＰアドレスを割り当て、プロセッサ毎にＮＩＣを設ける構成もある。以下では、実施例３として、ＴＯＥ機能のないＮＩＣとＴＯＥ機能のあるＮＩＣが共存するネットワークノードの構成を取り上げ、ＴＯＥ機能のないＮＩＣとＴＯＥ機能のあるＮＩＣを動的に切り替えて、通信する仕組みを説明する。

図１１は、実施例３のノード２００の構成図である。ノード２００内には、ＴＯＥ機能のないＮＩＣ３０とＴＯＥ機能のあるＴＯＥ−ＮＩＣ３１とが搭載されており、Ｉ／Ｏブリッジ２４０を介してＭＰＵ２１０の各プロセッサと接続している。ＴＣＰ／ＩＰプロトコルスタック１０ｓ、２０ｓが実装されたＰＵ１０、ＳＰＵ２０は、ＴＯＥ機能のないＮＩＣ３０を利用して通信し、ＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１は、ＴＯＥ機能のあるＴＯＥ−ＮＩＣ３１を利用して通信する。

ＲＤＭＡプロトコルスタック２１ｒのＭＰＡ層２１ｒ−５の下に、パケットのＩＰアドレスを判別するためのＩＰＡ（Internet Protocol Address）判別層２１ｒ−７を新たに設ける。ＩＰＡ判別層２１ｒ−７には、送信元ＩＰアドレスをＮＩＣのＭＡＣアドレスに対応づけたアドレステーブルをあらかじめ用意しておく。ここで、ＭＡＣアドレスは、一つ一つのＮＩＣに割り当てられた固有のアドレスである。ＩＰＡ判別層２１ｒ−７は、メッセージを送信する際に、ＩＰパケットの送信元アドレスを取得し、このアドレステーブルを参照することにより、どのＮＩＣから送信すべきパケットであるかを判定する。

ＩＰＡ判別層２１ｒ−７において、パケットの送信元ＩＰアドレスがＴＯＥ機能のないＮＩＣ３０のＭＡＣアドレスに対応づけられていることが判明すると、ＲＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１は、ＴＣＰ／ＩＰプロトコルスタック２０ｓが実装されたＳＰＵ２０にイベント通知する。これにより、当該パケットはＳＰＵ２０のＴＣＰ／ＩＰプロトコルスタック２０ｓによりプロトコル処理され、ＮＩＣ３０から送信される。

ＩＰＡ判別層２１ｒ−７において、パケットの送信元ＩＰアドレスがＴＯＥ機能のあるＴＯＥ−ＮＩＣ３１のＭＡＣアドレスに対応づけられていることが判明すると、ＤＭＡプロトコルスタック２１ｒが実装されたＳＰＵ２１は、自分自身にイベント通知するか、あるいは、ドライバ２１ｒ−６へとパケットを渡す。これにより、当該パケットはＴＯＥ−ＮＩＣ３１に供給され、ＴＯＥ−ＮＩＣ３１のＴＯＥ機能を用いてＴＣＰ／ＩＰにしたがったプロトコル処理がなされ、ネットワークに送信される。

ネットワークからパケットを受信する際は、通常のＴＣＰ／ＩＰ通信であるか、あるいは、ＲＤＭＡ機能を用いた通信であるかは、通信を開始するときに指定されるため、ＴＣＰ／ＩＰプロトコルスタック１０ｓ、２０ｓに特別な機能を設ける必要はない。

実施例３によれば、ＴＯＥ機能のないＮＩＣとＴＯＥ機能のあるＮＩＣが混在するシステムにおいても、両者を動的に切り替えて通信を行うことができ、システムに柔軟性と拡張性をもたせることができる。

実施の形態２
実施の形態２では、実施の形態１で説明したノード２００の応用例として、ＲＤＭＡ機能を利用したサーバ−クライアントシステムを説明する。

図１２は、実施の形態２に係るネットワークシステムの構成図である。このネットワークシステムは、複数のサーバ３１０ａ、３１０ｂと複数のクライアント２０２ａ〜２０２ｎがネットワークで接続されて構成される。複数のサーバ３１０ａ、３１０ｂは、スイッチ３２０ａ、３２０ｂを介してネットワークに接続しており、これらはサーバクラスタ３００を構成し、クライアント２０２ａ〜２０２ｎから見た場合、ひとつのサーバとして機能する。以下、複数のサーバ３１０ａ、３１０ｂを総称してサーバ３１０と呼び、複数のクライアント２０２ａ〜２０２ｎを総称してクライアント２０２と呼ぶ。

サーバ３１０にはＲＤＭＡ対応のＮＩＣが搭載されており、サーバ３１０のＣＰＵの負荷を低減させることができる。一方、クライアント２０２には、ソフトウェアでＲＤＭＡをエミュレートするＲＤＭＡ機能が実装されており、いわゆるｉＷＡＲＰが実現して、サーバ３１０との間でＲＤＭＡによる通信が可能となり、サーバ３１０の負荷を低減させるのに貢献する。

図１３は、クライアント２０２とサーバ３１０の構成図である。クライアント２０２は、実施の形態１で説明したマルチプロセッサシステムのように、ＲＤＭＡプロトコルスタックが実装されるプロセッサとＴＣＰ／ＩＰプロトコルスタックが実装されるプロセッサが異なってもよいが、実施の形態２では、クライアント２０２はシングルプロセッサシステムであり、ＲＤＭＡプロトコルスタックとＴＣＰ／ＩＰプロトコルスタックが１つのプロセッサで実行される場合を説明する。

クライアント２０２のユーザレベルにはバッファ６０が設けられ、サーバ３１０に送信するデータとサーバ３１０から受信するデータが格納される。ＤＡＦＳ（Direct Access File System）ＡＰＩ６２は、ＲＤＭＡプロトコル上で動作するファイルシステムであるＤＡＦＳのアプリケーションプログラムインタフェース（ＡＰＩ）である。ｕＤＡＰＬ（user Direct Access Programming Library）６４は、ＲＤＭＡ機能を実現するための汎用ＡＰＩである。クライアント２０２は、これらのＡＰＩを使用して、ＲＤＭＡ機能を用いてサーバ３１０のデータにアクセスする。

カーネルレベルには、ソケット層７１、ＲＤＭＡ層７２、ＴＣＰ層７３、ＩＰ層７４、ＮＩＣドライバ７５が実装され、ＲＤＭＡリードあるいはＲＤＭＡライトのパケットがプロトコル処理され、ギガビットイーサネット（商標または登録商標）８０を介してネットワーク１００に送信される。

サーバ３１０のユーザレベルにはバッファ８０が設けられ、クライアント２０２に送信するデータとクライアント２０２から受信するデータが格納される。また、クライアント２０２と同様に、ＤＡＦＳＡＰＩ８２とｕＤＡＰＬ８４が実装される。また、カーネルレベルのＨＣＡドライバ８８にアクセスするための仮想的なＡＰＩであるＶＡＰＩ８６が実装される。

サーバ３１０にはＲＤＭＡ対応のＮＩＣ（以下、「ＲＮＩＣ」という）９０が搭載されており、カーネルレベルのＨＣＡドライバ８８により制御される。ＲＮＩＣ９０においてＲＤＭＡプロトコル処理がハードウェアで実行され、サーバ３１０のＣＰＵを用いることなく、バッファ８０に対してデータが直接読み書きされる。なお、ＲＮＩＣ９０にはＴＯＥ機能も搭載されており、ハードウェアでＴＣＰ／ＩＰプロトコル処理もなされる。

図１３において、クライアント２０２からサーバ３１０に対してＲＤＭＡリードあるいはＲＤＭＡライトが発行されると、クライアント２０２のＲＤＭＡ層７２においてソフトウェアでＲＤＭＡ機能が実行され、サーバ３１０のＲＮＩＣ９０においてハードウェアでＲＤＭＡ機能が実行される。これにより、クライアント２０２は、サーバ３１０のＣＰＵに負荷をかけないで、サーバ３１０のバッファ８０に直接アクセスすることができる。

実施の形態２によれば、サーバ−クライアントシステムにおいて、サーバ側にＲＤＭＡ機能が実装されており、クライアント側に必ずしもＲＮＩＣが実装されていない場合でも、クライアント側でＲＤＭＡ機能をエミュレートするため、サーバとクライアント間でＲＤＭＡ機能を前提とした通信を行うことができる。これにより、サーバに搭載されたＲＤＭＡ機能を有効活用して、高速な通信を行うことができる。特定のクライアントにおいてＲＮＩＣの搭載ができなかったり、ＲＮＩＣの搭載が遅れる事情があっても、サーバ側でＲＤＭＡ機能を停止させる必要がないため、ＲＮＩＣが搭載されているかどうかに関係なく、システムにクライアントを追加していくことができ、サーバ−クライアントシステムの拡張が容易である。

以上説明したように、いずれの実施の形態においてもマルチプロセッサシステム上に、ＲＤＭＡプロトコルおよびＴＣＰプロトコルを常駐させるので、新規にＲＤＭＡ対応のＮＩＣを購入することなく、低コストで、ＲＤＭＡ機能をエミュレートすることが可能となる。実施の形態ではＲＤＭＡプロトコルスタックをカーネルレベルに実装する例を説明したが、ＲＤＭＡプロトコルスタックをユーザレベルに実装してもよい。ＲＤＭＡ機能をＴＣＰ／ＩＰ上に実装する技術は、一般にｉＷＡＲＰと呼ばれ、ネットワーク上の通信先のノードのメモリに直接データを書き込むことで処理遅延を減らすことができる。実施の形態では、ｉＷＡＲＰをソフトウェアで実装することで、ＲＤＭＡのハードウェアをもたないシステムでもＲＤＭＡ機能を実現可能である。

以上、本発明を実施の形態をもとに説明した。実施の形態は例示であり、それらの各構成要素や各処理プロセスの組合せにいろいろな変形例が可能なこと、またそうした変形例も本発明の範囲にあることは当業者に理解されるところである。そのような変形例を説明する。

実施の形態では、プロセッサ間でイベント通知をすることにより、送受信データの存在を他のプロセッサに知らせたが、これ以外にも、たとえば、ＰＵあるいはＳＰＵが受信バッファをポーリングすることにより、イベントを検知してもよい。

また、各ノード２００内のメインメモリ２２０を用いて、パケット用のバッファを構築したが、たとえば、図２における、ＭＰＵ２１０内の各プロセッサが個別にローカルメモリをもっており、そのローカルメモリを用いてパケット用のバッファを構築してもよい。

なお、ソケットプログラムでは、送受信時にsendあるいはrecvコマンドを発行するが、実施の形態では説明の簡略化のため、ソケットの処理の詳細は省略した。

本発明の実施の形態に係るネットワークシステムを示す図である。 図１のノードの構成図である。 図２のノードのＭＰＵに実装されたＴＣＰ／ＩＰプロトコルスタックおよびＲＤＭＡ機能を説明する図である。 実施例１のノードの構成図である。 実施例１における発行元ノードと発行先ノードの間で行われるＲＤＭＡライト処理のシーケンス図である。 図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用しないＴＣＰによる送受信動作を示す図である。 図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用するＳＤＰによる送受信動作を示す図である。 各ノードに搭載されたＮＩＣ内にＴＣＰ／ＩＰ送受信バッファを設ける構成を説明する図である。 実施例２のノードの構成図である。 実施例２において、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用しないＴＣＰによる送受信動作を示す図である。 実施例２において、図５のＲＤＭＡライト処理シーケンスの内、ＲＤＭＡ機能を使用するＳＤＰによる送受信動作を示す図である。 実施例３のノードの構成図である。 実施の形態２に係るネットワークシステムの構成図である。 図１２のクライアントとサーバの構成図である。

符号の説明

１０ ＰＵ、 １１ ＰＵ、２０ ＳＰＵ、 ２１ ＳＰＵ、 ２２ ＳＰＵ、 ３０ ＮＩＣ、 ３１ ＴＯＥ−ＮＩＣ、 ５０ ソケットスイッチ、 １００ ネットワーク、 ２００ ノード、 ２１０ ＭＰＵ、 ２２０ メインメモリ、 ２２２ アプリケーション用バッファ、 ２２４ ＴＣＰ／ＩＰ送受信バッファ、 ２３０ ＮＩＣ、 ２４０ Ｉ／Ｏブリッジ。

Claims (13)

1. リモートダイレクトメモリアクセス機能をエミュレートする第１プロセッサと、
   前記第１プロセッサによりリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、
   前記バッファからパケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施す第２プロセッサと、
   前記第２プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信するネットワークインターフェースカードとを含むことを特徴とするネットワークプロセッサシステム。
2. ユーザレベルで処理を実行するプロセッサであって、送信すべきメッセージをユーザ空間に生成する第１プロセッサと、
   カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートするプロセッサであって、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てる第２プロセッサと、
   前記第２プロセッサから出力される前記リモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、
   カーネルレベルでＴＣＰ／ＩＰプロトコル処理を実行するプロセッサであって、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコルにしたがったパケットに組み立てる第３プロセッサと、
   前記第３プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信するネットワークインターフェースカードとを含むことを特徴とするネットワークプロセッサシステム。
3. 送信すべきメッセージをリモートダイレクトメモリアクセス機能を用いることなく送信する場合、前記第３プロセッサは、前記第１プロセッサからの通知を受けて、前記メッセージをＴＣＰ／ＩＰにしたがったパケットに組み立てることを特徴とする請求項２に記載のネットワークプロセッサシステム。
4. 前記第１プロセッサは、指定されたプロトコルの違いを判別してイベント通知先を変更するプロトコルスイッチの機能を有し、
   前記プロトコルスイッチは、
   リモートダイレクトメモリアクセスのプロトコルが指定された場合、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てるために前記第２プロセッサにイベント通知し、
   リモートダイレクトメモリアクセスのプロトコルが指定されない場合、前記メッセージをＴＣＰ／ＩＰにしたがったパケットに組み立てるために前記第３プロセッサにイベント通知することを特徴とする請求項３に記載のネットワークプロセッサシステム。
5. リモートダイレクトメモリアクセス機能をエミュレートするプロセッサと、
   前記プロセッサから出力されるリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、
   前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すためのＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードとを含むことを特徴とするネットワークプロセッサシステム。
6. ユーザレベルで処理を実行するプロセッサであって、送信すべきメッセージをユーザ空間に生成する第１プロセッサと、
   カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートするプロセッサであって、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てる第２プロセッサと、
   前記第２プロセッサから出力される前記リモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、
   前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードとを含むことを特徴とするネットワークプロセッサシステム。
7. 送信すべきメッセージをリモートダイレクトメモリアクセス機能を用いることなく送信する場合、前記ＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードは、前記第１プロセッサからの通知を受けて、前記メッセージをＴＣＰ／ＩＰにしたがったパケットに組み立てることを特徴とする請求項６に記載のネットワークプロセッサシステム。
8. 前記第１プロセッサは、指定されたプロトコルの違いを判別してイベント通知先を変更するプロトコルスイッチの機能を有し、
   前記プロトコルスイッチは、
   リモートダイレクトメモリアクセスのプロトコルが指定された場合、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立てるために前記第２プロセッサにイベント通知し、
   リモートダイレクトメモリアクセスのプロトコルが指定されない場合、前記メッセージをＴＣＰ／ＩＰにしたがったパケットに組み立てるために前記ＴＣＰ／ＩＰオフロード機能をもつネットワークインタフェースカードにイベント通知することを特徴とする請求項７に記載のネットワークプロセッサシステム。
9. リモートダイレクトメモリアクセス機能をエミュレートする第１プロセッサと、
   前記第１プロセッサによりリモートダイレクトメモリアクセスのプロトコルにしたがって生成されたパケットをキューイングするバッファと、
   前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施す第２プロセッサと、
   前記第２プロセッサにより生成されたＴＣＰ／ＩＰパケットをネットワークに送信する第１ネットワークインタフェースカードと、
   前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すためのＴＣＰ／ＩＰオフロード機能をもつ第２ネットワークインタフェースカードとを含み、
   前記第１プロセッサは、前記パケットの送信元ＩＰアドレスを前記第１ネットワークインタフェースカードのＭＡＣアドレスまたは前記第２ネットワークインタフェースカードのＭＡＣアドレスに対応づけたテーブルを参照して、前記パケットの送信元ＩＰアドレスに応じて、前記パケットを送出するためのネットワークインタフェースを前記第１ネットワークインタフェースカードまたは前記第２ネットワークインタフェースカードのいずれかに振り分ける機能を有し、
   前記パケットが前記第１ネットワークインタフェースカードに振り分けられる場合は、前記パケットは、前記第２プロセッサによりＴＣＰ／ＩＰプロトコル処理がなされて、前記第１ネットワークインタフェースカードから送出され、
   前記パケットが前記第２ネットワークインタフェースカードに振り分けられる場合は、前記パケットは、前記第２ネットワークインタフェースカードのＴＣＰ／ＩＰオフロード機能によりＴＣＰ／ＩＰプロトコル処理がなされて、前記第２ネットワークインタフェースカードから送出されることを特徴とするネットワークプロセッサシステム。
10. ユーザレベルで処理を実行する第１プロセッサに、送信すべきメッセージをユーザ空間に生成するステップを実行させ、
    カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサに、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップを実行させ、
    カーネルレベルでＴＣＰ／ＩＰプロトコル処理を実行する第３プロセッサに、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコルにしたがったパケットに組み立てるステップを実行させることを特徴とするプログラム。
11. ユーザレベルで処理を実行する第１プロセッサに、送信すべきメッセージをユーザ空間に生成するステップを実行させ、
    カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサに、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップを実行させ、
    ネットワークインタフェースカード内でＴＣＰ／ＩＰオフロード機能を実行する第３プロセッサに、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すステップを実行させることを特徴とするプログラム。
12. ユーザレベルで処理を実行する第１プロセッサが、送信すべきメッセージをユーザ空間に生成するステップと、
    カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサが、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップと、
    カーネルレベルでＴＣＰ／ＩＰプロトコル処理を実行する第３プロセッサが、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコルにしたがったパケットに組み立てるステップとを含むことを特徴とするネットワークプロトコル処理方法。
13. ユーザレベルで処理を実行する第１プロセッサが、送信すべきメッセージをユーザ空間に生成するステップと、
    カーネルレベルでリモートダイレクトメモリアクセス機能をエミュレートする第２プロセッサが、前記第１プロセッサからの通知を受けて、前記メッセージをリモートダイレクトメモリアクセスのプロトコルにしたがったパケットに組み立て、バッファにキューイングするステップと、
    ネットワークインタフェースカード内でＴＣＰ／ＩＰオフロード機能を実行する第３プロセッサが、前記第２プロセッサからの通知を受けて、前記バッファから前記パケットを読み込み、ＴＣＰ／ＩＰプロトコル処理を施すステップを実行することを特徴とするネットワークプロトコル処理方法。

Images