(57)【特許請求の範囲】
【請求項１】
入出力（ＩＯ）リソースを提供する複数のリモートラインカード（ＬＣ）に物理リンクを介して相互接続により連結する複数の物理ＩＯポートと、
前記複数の物理ＩＯポートに連結され、アプリケーションに前記ＩＯリソースへのアクセスを提供するオペレーティングシステム（ＯＳ）を実装するプロセッサと
を備え、
前記プロセッサは、
前記複数のリモートＬＣを複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）に、前記ＩＯリソースの少なくともいくつかを前記複数のｖＮＩＣに割り振ることによってマッピングし、
前記複数のｖＮＩＣのうちの第１のｖＮＩＣへのアクセスの前記ＯＳに対するリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを前記アプリケーションから受信し、
前記複数のリモートＬＣのうちの、前記第１のｖＮＩＣに対応する第１のリモートＬＣを決定し、
前記ＯＳカーネルＩＯコールを前記第１のリモートＬＣおよび前記相互接続と関連付けられたデバイスドライバコールに変換するように構成されている装置。
【請求項２】
前記プロセッサはさらに、
前記複数のリモートＬＣのうちの１つのリモートＬＣのＩＯリソースを少なくとも第１の部分および第２の部分へと論理的に分割すること、
前記第１の部分を１つのｖＮＩＣに割り当てること、および
前記第２の部分を別のｖＮＩＣに割り当てること
によって前記ＩＯリソースを前記複数のｖＮＩＣに割り振る、請求項１に記載の装置。
【請求項３】
前記プロセッサはさらに、
１つのリモートＬＣと関連付けられた前記ＩＯリソースの少なくとも第１の部分を前記第１のｖＮＩＣに割り当てること、および
別のリモートＬＣと関連付けられた前記ＩＯリソースの少なくとも第２の部分を前記第１のｖＮＩＣに割り当てること
によって前記ＩＯリソースを前記複数のｖＮＩＣに割り振る、請求項１または２に記載の装置。
【請求項４】
前記第１のｖＮＩＣは、第１の量の前記ＩＯリソースが割り振られ、前記プロセッサはさらに、
前記第１の量の前記ＩＯリソースを変更するリクエストを受信し、
前記リクエストにしたがって、第２の量の前記ＩＯリソースを前記第１のｖＮＩＣに再割り振りする、請求項１から３のいずれか一項に記載の装置。
【請求項５】
前記ＩＯリソースは、メモリ、帯域幅、ネットワークポート、コンピューティングリソース、またはそれらの組み合わせを含み、前記第１の量の前記ＩＯリソースは、前記メモリのサイズ、前記帯域幅の量、前記ネットワークポートの数、前記コンピューティングリソースの一部、またはそれらの組み合わせを含む、請求項４に記載の装置。
【請求項６】
前記相互接続は、オープンシステム相互接続（ＯＳＩ）第２層（Ｌ２）ネットワーク接続、ＯＳＩ第３層（Ｌ３）ネットワーク接続、スイッチングファブリック、またはそれらの組み合わせを含む、請求項１から５の何れか１つに記載の装置。
【請求項７】
前記プロセッサはさらに、
仮想マシン（ＶＭ）をプロビジョニングし、
前記第１のｖＮＩＣを前記ＶＭに割り当て、
前記ＯＳカーネルＩＯコールは前記ＶＭから受信される、
請求項１から６のいずれか一項に記載の装置。
【請求項８】
前記複数の物理ＩＯポートはさらに、リモートホストに連結し、前記複数のｖＮＩＣの少なくとも１つは前記リモートホストと関連付けられる、請求項１から７のいずれか一項に記載の装置。
【請求項９】
アプリケーションにＩＯリソースへのアクセスを提供するオペレーティングシステム（ＯＳ）の下で動作するローカルサーバホストによって実装される方法であって、
前記ローカルサーバホストに物理リンクを介して相互接続により連結された複数のリモートラインカード（ＬＣ）の入出力（ＩＯ）リソース情報を取得する段階と、
前記複数のリモートＬＣの前記ＩＯリソース情報にしたがって、ＩＯリソースプールを定義する段階と、
前記複数のリモートＬＣの前記ＩＯリソース情報にしたがって、前記ＩＯリソースプールからＩＯリソースを割り振ることによって、前記複数のリモートＬＣと複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）との間のマッピングを決定する段階と、
前記複数のｖＮＩＣのうちの第１のｖＮＩＣへのアクセスの前記ＯＳに対するリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを前記アプリケーションから受信する段階と、
前記複数のリモートＬＣのうちの、前記第１のｖＮＩＣに対応する第１のリモートＬＣを決定する段階と、
前記ＯＳカーネルＩＯコールを前記第１のリモートＬＣおよび前記相互接続と関連付けられたデバイスドライバコールに変換する段階と
を備える方法。
【請求項１０】
前記複数のリモートＬＣは、オープンシステム相互接続（ＯＳＩ）第２層（Ｌ２）プロトコル、ＯＳＩ第３層（Ｌ３）プロトコル、またはそれらの組み合わせを含むネットワークプロトコルと関連付けられた相互接続を介して前記ローカルサーバホストに接続される、請求項９に記載の方法。
【請求項１１】
前記ＯＳカーネルＩＯコールは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）デバイス、またはＰＣＩ−エクスプレス（ＰＣＩｅ）デバイスと関連付けられる、請求項１０に記載の方法。
【請求項１２】
ＩＯリソース要件の変更を受信する段階と、
前記ＩＯリソース要件の変更に応答して、前記ＩＯリソースプールの前記ＩＯリソースを動的に再割り振りする段階とをさらに備え、
前記ＩＯリソース要件の変更は、前記複数のｖＮＩＣのうちの一ｖＮＩＣの増加されたＩＯリソースの量、前記複数のｖＮＩＣのうちの別のｖＮＩＣの低減されたＩＯリソースの量、更なるｖＮＩＣの追加、既存のｖＮＩＣの削除、またはそれらの組み合わせを含む、
請求項９から１１のいずれか一項に記載の方法。
【請求項１３】
前記ＩＯリソースプールは、メモリ、帯域幅、ネットワークポート、コンピューティングリソース、またはそれらの組み合わせを含み、前記ＩＯリソースの量は、前記メモリのサイズ、前記帯域幅の量、前記ネットワークポートの数、前記コンピューティングリソースの一部、もしくはそれらの組み合わせを含む、請求項１２に記載の方法。
【請求項１４】
前記ローカルサーバホストに物理リンクを介して連結され、他のアプリケーションにＩＯリソースへのアクセスを提供する他のＯＳの下で動作するリモートサーバホストにＩＯ設定を送信する段階であって、前記ＩＯ設定は、前記複数のｖＮＩＣのうちの少なくとも前記他のＯＳに提供される第２のｖＮＩＣと関連付けられた設定情報を含む、段階と、
前記第２のｖＮＩＣへのアクセスの前記他のＯＳに対するリクエストを含む他のＯＳカーネルＩＯコールを前記他のアプリケーションから受信する段階と、
前記複数のリモートＬＣのうちの、前記第２のｖＮＩＣに対応する第２のリモートＬＣを決定する段階と、
前記他のＯＳカーネルＩＯコールを前記第２のリモートＬＣおよび前記相互接続と関連付けられたデバイスドライバコールに変換する段階と
をさらに備える、請求項１０から１３のいずれか一項に記載の方法。
【発明の詳細な説明】
【背景技術】
【０００１】
ペリフェラルコンポーネントインターコネクト（ＰＣＩ）バスは、パーソナルコンピュータ（ＰＣ）、サーバ、およびマルチシャーシシステムなどの多種多様なコンピュータシステムの中に存在している。ＰＣＩバスは、コンピュータコンポーネントおよび／または周辺機器が中央演算処理装置（ＣＰＵ）と通信するためのチャネルを提供する。種々のバスアーキテクチャおよび追加機能によって性能を向上させるべく、様々なバージョンのＰＣＩが開発されてきた。例えば、原型のＰＣＩは、共有パラレルバスアーキテクチャを使用し、共有パラレルバスアーキテクチャでは、ＰＣＩホストとその全てのデバイスとがアドレス、データ、および制御線の共通のセットを共有する。一方で、その後継のＰＣＩ−エクスプレス（ＰＣＩｅ）は、ポイントツーポイントトポロジに基づいており、ポイントツーポイントトポロジは、別個のシリアルリンクを使用して、あらゆるデバイスをＰＣＩｅホストに接続する。各ＰＣＩｅデバイスはそれ自身の専用のＰＣＩｅホストへの直列接続を有しているので、ＰＣＩｅは、原型のＰＣＩより高いスループットとより低いレイテンシとを提供する。 
【発明の概要】
【０００２】
一実施形態において、本開示は、入出力（ＩＯ）リソースを提供する複数のリモートラインカード（ＬＣ）に連結するよう構成される複数の物理ＩＯポートと、複数の物理ＩＯポートに連結され、リモートＬＣを複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）に、ＩＯリソースのうちの少なくともいくつかをローカルｖＮＩＣに割り振ることによってマッピングし、ｖＮＩＣのうちの第１のｖＮＩＣにアクセスするリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを受信し、リモートＬＣのうちの、第１のｖＮＩＣに対応する第１のリモートＬＣを決定し、第１のリモートＬＣにアクセスするようにリクエストを向けるよう構成されるプロセッサとを備える装置を含む。
【０００３】
別の実施形態において、本開示は、ＯＳの下で動作するローカルサーバホストによって実装される方法を含む。当該方法は、ローカルサーバホストに連結された複数のリモートＬＣのＩＯリソース情報を取得する段階と、リモートＬＣのＩＯリソース情報にしたがってＩＯリソースプールを定義する段階と、リモートＬＣのＩＯリソース情報にしたがってＩＯリソースプールからＩＯリソースを割り振ることによって、リモートＬＣと複数のｖＮＩＣとの間のマッピングを決定する段階と、ｖＮＩＣのうちの第１のｖＮＩＣにアクセスするリクエストを含むＯＳカーネルＩＯコールを受信する段階と、リモートＬＣのうちの、第１のｖＮＩＣに対応する第１のリモートＬＣを決定する段階と、第１のリモートＬＣにアクセスするようにリクエストを向ける段階とを備える。
【０００４】
さらに別の実施形態において、本開示は、ＩＯリソースを提供する複数のリモートＬＣに連結するよう構成される複数の物理ＩＯポートと、リモートホストと、複数の物理ＩＯポートに連結され、複数のリモートＬＣのリソース情報を取得し、リモートＬＣのリソース情報にしたがってＩＯリソースプールを定義し、リモートＬＣと、複数のｖＮＩＣであって、そのうちの少なくとも第１のｖＮＩＣがリモートホストと関連付けられた複数のｖＮＩＣとの間のマッピングを、ＩＯリソースプールからＩＯリソースをｖＮＩＣに割り振ることによって決定し、第１のｖＮＩＣと関連付けられた設定情報を含む設定メッセージを、ＩＯポートを介してリモートホストに送信するよう構成されるプロセッサとを備える装置を含む。
【０００５】
以下の詳細な説明を添付の図面および特許請求の範囲と併せ読むことによって、これらの、および他の特徴がより明確に理解される。
【図面の簡単な説明】
【０００６】
本開示をより完全に理解するために、ここで、添付の図面および詳細な説明に関連して、以下の簡潔な説明を参照する。同様の参照番号は同様の部分を表す。 
【０００７】
【図１】単一ホスト環境において動作するコンピュータシステムの実施形態の概略図である。
【０００８】
【図２】マルチホスト環境において動作するコンピュータシステムの実施形態の概略図である。
【０００９】
【図３】コンピュータシステムにおいてホストとしての機能を果たし得るネットワーク要素（ＮＥ）の実施形態の概略図である。
【００１０】
【図４】ネットワークＬＣを検出および初期化するための方法の実施形態のプロトコル図である。
【００１１】
【図５】ネットワークＬＣをローカルｖＮＩＣにマッピングするための方法の実施形態のプロトコル図である。
【００１２】
【図６】ローカルＩＯサービスをアプリケーションに提供するための方法の実施形態のプロトコル図である。
【００１３】
【図７】ローカルＩＯリソースプールを定義するための方法の実施形態のフローチャートである。
【００１４】
【図８】ローカルＩＯサービスをアプリケーションに提供するための方法の実施形態のフローチャートである。
【００１５】
【図９】エラスティックなローカルＩＯリソースプールを提供するための方法の実施形態のフローチャートである。
【発明を実施するための形態】
【００１６】
１または複数の実施形態のうちの例示的な実装が以下で提供されるが、開示されたシステムおよび／または方法は、現在知られているものか、存在しているものかを問わない任意の数の技術を用いて実装され得ることが最初に理解されるべきである。本開示は、本明細書において示され説明される例示的な設計および実装を含む、以下で示される例示的な実装、図面、および技術に決して限定されるべきではないが、添付の特許請求の範囲に加え、それらの均等物の全範囲内において変更され得る。
【００１７】
ＯＳとは、コンピュータのハードウェアおよびソフトウェアのリソースを管理し、コンピュータプログラムおよびアプリケーションに一般的なサービスを提供するソフトウェアである。例えば、一般的なサービスにアクセスするためにコンピュータプログラムおよびアプリケーションによって用いられてよいカーネルコールまたはシステムコールのセットをＯＳが提供し得る。ＯＳによって実行される基本的なタスクは、メモリの割り振り、システムリクエストの優先順位付け、ＩＯデバイスの制御、ネットワーキングの促進化、および／またはファイルシステム管理を含んでよい。最新のコンピュータシステムによって使用される一般的な、またはよく見られるＯＳのいくつかの例としては、Ｗｉｎｄｏｗｓ（登録商標）、Ｕｎｉｘ（登録商標）、およびＬｉｎｕｘ（登録商標）が挙げられ得る。 
【００１８】
ＰＣＩおよび／またはＰＣＩｅは、多くのコンピュータシステムのバスシステムの一部として使用され、ＰＣＩおよび／またはＰＣＩｅデバイスは、ローカルＩＯデバイスとして、ほとんどの一般的なＯＳと統合される。ネットワーク接続を介してリモートでコンピュータシステムに接続されるネットワーク機器とは対照的に、ローカルＩＯデバイスは、ローカルバスシステムを介して直接コンピュータシステムに接続されるデバイスである。例えば、ＰＣＩおよび／またはＰＣＩｅデバイスは、デバイス設定メモリ空間を介してコンピュータシステムにおいてアクセスされ、制御され得る。システムの起動（例えば、電源投入）時、コンピュータシステムの基本入出力システム（ＢＩＯＳ）は、デバイス設定メモリ空間を通じて、取り付けられたＰＣＩおよび／またはＰＣＩｅデバイスを検出し、設定し得る。例えば、ＢＩＯＳは、取り付けられたＰＣＩおよび／またはＰＣＩｅデバイスの各々のためのメモリもしくはＩＯのベースアドレス、および／または、割り込みリクエスト（ＩＲＱ）線を決定し得る。加えて、各ＰＣＩデバイスに対応するデバイスドライバがロードされ得、デバイスドライバによってデバイス特有の設定が扱われてよい。その後、ＢＩＯＳに加えて実行する一般的なＯＳが、取り付けられたＰＣＩデバイスへのＩＯアクセスをアプリケーションに提供し得る。例えば、一般的なＯＳの各々は、取り付けられたＰＣＩデバイスに対するデータの読み出しおよび／または書き込みのためのカーネルコールまたはシステムコールのセットを提供し得る。
【００１９】
デジタルアセットが増え、より多くのアプリケーションが展開されるにつれ、データセンタ（ＤＣ）は大きくなり続ける。増大する要求を満たすべく、サーバおよび／またはストレージ仮想化がＤＣによって一般に使用される。サーバおよび／またはストレージ仮想化は、物理リソースとその使用とを根本的な物理マシンから切り離すソフトウェア抽象化技術を指す。ほとんどの物理リソースは、仮想化されたエンティティとして抽象化され、プロビジョニングされ得る。仮想化されたエンティティのいくつかの例として、ＣＰＵ、ネットワークＩＯ、およびストレージＩＯが挙げられ得る。例えば、ＤＣは、複数のサーバラックまたはシャーシベースシステムを収納し得る。各サーバラックは、ＬＣ（例えば、コンピューティングおよび／またはストレージハードウェアユニット）を保持するよう設計された複数の取り付け用スロットまたはベイと、ＬＣへの接続を提供するバックプレーンとを備える。管理および制御機能をＬＣに提供するよう、１または複数のホストマシンまたはサーバホストがサーバラックのいたる所に分散され得る。高い帯域幅および／またはスループットの要件があるために、サーバラックに設置されたＬＣは通常、ＰＣＩおよび／またはＰＣＩｅとは異なる相互接続技術によって相互接続される。ゆえに、ホストマシンが一般的なＯＳを使用するとき、ＬＣは、ローカルＩＯまたはローカルＮＩＣとして、一般的なＯＳと直接統合され得ない。例えば、ＤＣには、スイッチングファブリック技術（例えば、クロスバースイッチ）を使用して、サーバラックおよび／またはＬＣを相互接続するものもあれば、オープンシステム相互接続（ＯＳＩ）第２層（Ｌ２）および／または第３層（Ｌ３）ネットワーク技術（例えば、イーサネット（登録商標）スイッチおよび／またはＩＰスイッチ）を使用してサーバラックおよび／またはＬＣを相互接続するものもある。したがって、一般的なＯＳを使用するサーバホストはＰＣＩデバイスの統合と同一のメカニズムを使用して、ローカルＩＯデバイスおよび／またはリソースとしてＬＣを統合し得ない。 
【００２０】
業界ではいくつかの手法を開発して、ＰＣＩおよび／またはＰＣＩｅに基づかないＬＣおよび／またはＩＯデバイスをＯＳと統合してきた。一手法において、スイッチングファブリックに特有のプロプライエタリプロトコルを実装することによってプロプライエタリＯＳが開発されている。しかしながら、プロプライエタリＯＳの使用は柔軟性に欠ける場合があり、一般的なサードパーティ解決手段での使用または統合を制限する場合がある。第２の手法では、ＬＣは、ＯＳカーネルネットワークコール（例えば、ソケット）を使用することによって、リモートネットワークデバイスとして一般的なＯＳと統合される。例えば、ファーウェイ（登録商標）多目的ルーティングプラットフォーム（ＶＲＰ）および他のいくつかの組み込みＯＳは、米国電気電子学会（ＩＥＥＥ）によって開発され、文献８０２．１ｂｒにおいて説明されるブリッジポート拡張プロトコルなどの既存のネットワークプロトコルを使用することによってＬＣを統合し得る。しかしながら、ＬＣがリモートネットワークデバイスとして統合されるとき、一般的なＯＳは、ＬＣをアプリケーションに対してローカルＩＯデバイスとしては提示し得ず、その代わりにネットワーク接続として提示し得る。第３の手法において、オンボードの特定用途向け集積回路（ＡＳＩＣ）チップが、ローカルネットワークインタフェースカード（ＮＩＣ）として一般的なＯＳと統合される。例えば、Ｃｕｍｕｌｕｓは、ローカルＮＩＣ（例えば、ＰＣＩまたはＰＣＩｅデバイス）としてＴｒｉｄｅｎｔ  ＡＳＩＣをＬｉｎｕｘ（登録商標）に統合した。しかしながら、そのようなアプローチはローカルのオンボードコンポーネントに限定され、リモートネットワークデバイスには適用され得ない。第４の手法において、仮想機能（ＶＦ）をサポートするよう、ＰＣＩ機能が拡張される。例えば、シングルルート−ＩＯ仮想化（ＳＲ−ＩＯＶ）が、ハードウェアの中にＳＲ−ＩＯＶ仕様を設計することによってＰＣＩ機能を拡張する。したがって、そのようなアプローチは、ＳＲ−ＩＯＶをサポートするよう設計されていない他のハードウェアとは互換性がない。Ｊｕｎｉｐｅｒ  ｎｏｄｅ  ｕｎｉｆｉｅｒ（ＪＮＵ）などの他のいくつかの業界の解決手段が、アプリケーション層においてリモートデバイスの中央管理を提供する。しかしながら、そのような解決手段は管理には重点を置くが、アプリケーションに対してリモートデバイスをＩＯリソースとして提示することには重点を置き得ない。加えて、上述された全ての手法が備えられず、エラスティックなＩＯ再割り振りがサポートされない場合がある。
【００２１】
本明細書では、ネットワークＬＣをローカルｖＮＩＣにマッピングすることによって、ネットワークＬＣを一般的なＩＯデバイスとしてホストＯＳに統合するための様々な実施形態が開示される。ここで、一般的なＩＯデバイスとは、ＰＣＩおよび／またはＰＣＩｅデバイスを指す。例えば、ホストＯＳが、一般的なＩＯデバイスにアクセスするためのＯＳカーネルＩＯコールまたはインタフェースのセットで構築され得る。例えば、Ｌｉｎｕｘ（登録商標）ＯＳは、ＰＣＩおよび／またはＰＣＩｅデバイスとインタフェースで接続するための組み込まれたカーネルコール（例えば、ｉｏｃｔｌ）を備える。ｖＮＩＣとは、ＬＣの物理ハードウェアに論理的に接続される仮想ネットワークデバイスまたは仮想ＩＯデバイスを指す。開示された実施形態において、ホストＯＳが、ネットワークＬＣを一般的なＩＯデバイスとして使用し、ＯＳカーネルＩＯコールを通じてＩＯサービスをアプリケーションに提供し得る。例えば、ネットワークＬＣは、いくつかのネットワーク接続を介してホストシステムまたはホストマシンに接続されるリモートＬＣであり、ネットワークおよび／またはＩＯリソース（例えば、メモリおよびネットワーク帯域幅）をホストシステムに提供する。開示された実施形態は、ＬＣマネージャ（ＬＣＭ）を使用してリモートＬＣの使用を管理および制御する。ＬＣＭは、リモートＬＣをローカルｖＮＩＣにマッピングする。例えば、ＬＣＭは、単一のネットワークＬＣからのＩＯリソースを複数の部分へと論理的に分割し得、異なる部分を異なるローカルｖＮＩＣにマッピングし得る。あるいは、ＬＣＭは、種々のリモートＬＣからのＩＯリソースを論理的に組み合わせ得、組み合わされたＩＯリソースを単一のローカルｖＮＩＣにマッピングし得る。ホストＯＳは、ローカルｖＮＩＣをローカルＩＯデバイスとして用い得、アプリケーションは、ＯＳカーネルＩＯインタフェースを介してローカルｖＮＩＣにアクセスし得る。一実施形態において、ホストは、ＩＯインタフェース変換（ＩＯＩＣ）コンポーネントを使用して、ＯＳカーネルＩＯインタフェースと、リモートＬＣのハードウェアに特有のデバイスドライバインタフェースとの間の変換を実行し得る。開示された実施形態は、ローカルｖＮＩＣを通じて、リモートＬＣの物理リソースと物理リソースの使用量とをリモートＬＣの物理ハードウェアから抽象化するので、開示された実施形態は、リモートＬＣの物理リソースを、ＩＯ要求に動的に適応し得るエラスティックなローカルＩＯリソースプールとして提示し得る。加えて、開示された実施形態はマルチホストシステムに適していると考えられる。マルチホストシステムでは、単一のＬＣＭが、リモートＬＣを管理し、複数のホストのローカルｖＮＩＣとリモートＬＣとの間のマッピングを提供するよう構成され得る。
【００２２】
図１は、単一ホスト環境において動作するコンピュータシステム１００の実施形態の概略図である。システム１００は、ホストハードウェア１１０と、複数のＬＣ１２０（例えば、ＬＣ１、ＬＣ２、ＬＣ３、およびＬＣ４）と、スイッチ１３０とを備える。スイッチ１３０は、リンク１３１を介してＬＣ１２０をホスト１１０に接続するよう構成される物理デバイスである。リンク１３１は、物理リンクであり、それは、光リンク、電気リンク、またはそれらの組み合わせであり得る。スイッチ１３０は、様々なスイッチングメカニズムを使用して、ＬＣ１２０とホストハードウェア１１０との間でデータを受信、処理、および／または転送し得る。スイッチ１３０は、フロー制御を実行して、ＬＣ１２０とホストハードウェア１１０との間のデータの伝送を管理し得る。例えば、スイッチ１３０はイーサネット（登録商標）スイッチであり得、リンク１３１はイーサネット（登録商標）ケーブルであり得る。ＬＣ１２０は、コンピューティングデバイスおよび／またはストレージデバイスを備える任意のハードウェアユニットである。例えば、ＬＣ１２０はネットワークデバイスとして動作し得、さらに、他のネットワークデバイスに通信可能に連結されたＩＯポートを備えてよい。一実施形態において、システム１００は、ＤＣのシャーシシステムまたはサーバラックに対応し得る。例えば、ホストハードウェア１１０は、サーバラック上に位置するサーバエンジンまたはサーバホストマシンに対応し得、ＬＣ１２０は、サーバラック上に設置されたＬＣに対応し得、スイッチ１３０およびリンク１３１は、サーバラックのバックプレーンを形成し得る。ＬＣ１２０は、ＩＯリソース１６１をシステム１００に提供し得る。ＩＯリソース１６１は、メモリ、ネットワーク帯域幅、ネットワーク接続ポート、および／または他のコンピューティングリソースを含んでよい。 
【００２３】
ホストハードウェア１１０は、データの処理に適した任意のコンピューティングデバイスであり得る。例えば、ホストハードウェア１１０は、１または複数のＣＰＵ、１または複数のメモリデバイス、バスシステム、および／または他のインタフェースポートを備えてよい。ホストハードウェア１１０によって、様々なソフトウェアプログラムおよび／またはコンポーネントが実行され得る。例えば、ホストハードウェア１１０は、複数のＬＣデバイスドライバ１５２（例えば、ＬＣＤ１およびＬＣＤ２）と、１または複数のアプリケーション１５３と、ＬＣＭ１５４と、複数のｖＮＩＣ１６０と、ホストＯＳ１４０とを実行するよう構成され得る。 
【００２４】
ＬＣデバイスドライバ１５２は、ソフトウェアインタフェースをＬＣ１２０の物理ハードウェアに提供するよう構成されるソフトウェアプログラムである。したがって、ＬＣデバイスドライバ１５２はハードウェア特有のものである。例えば、ＬＣデバイスドライバ１５２の実装は、ＬＣ１２０の物理ハードウェアと、ＬＣ１２０をホストハードウェア１１０に接続する相互接続とに依存している。いくつかの一般的なデバイスドライバ動作は、デバイス初期化、デバイス設定、デバイス読み出し、および／またはデバイス書き込みを含んでよい。デバイス初期化とはＬＣ１２０の初期設定を指し、これにより、他のソフトウェアコンポーネントがＬＣ１２０と通信し得る。デバイス設定とは、後のデバイス特有パラメータ（例えば、帯域幅、速度、および動作モード）の設定を指す。デバイス読み出しとは、ＬＣ１２０からのデータの受信または読み出しを指す。デバイス書き込みとは、ＬＣ１２０へのデータの送信を指す。ＬＣデバイスドライバ１５２は、ＬＣ１２０を動作させるために他のソフトウェアコンポーネントによって呼び出され得る、デバイスドライバインタフェースと称され得るソフトウェアインタフェースの中に、ハードウェアに特有の動作を抽象化する。例えば、データ書き込みインタフェースのためのソフトウェアインタフェースが、ＬＣ１２０に送信されるべきデータのブロックおよびデータの長さを含んでよい。しかしながら、データ書き込みを完了すべく、ＬＣデバイスドライバ１５２は、複数のハードウェア読み出しおよび／もしくは書き込みトランザクション、ならびに／または他のタイミングおよびフロー制御を実行し得る。一実施形態において、ＬＣ１２０が、イーサネット（登録商標）ファブリックでスイッチ１３０を介してホストハードウェア１１０に接続されたリモートネットワークデバイスであるとき、対応するＬＣデバイスドライバ１５２は、イーサネット（登録商標）プロトコルにしたがって、データの送信および／または受信に加えて、イーサネット（登録商標）パケットカプセル化および／またはデカプセル化を実行し得る。いくつかの実施形態において、各ＬＣデバイスドライバ１５２は、特定のＬＣ１２０（例えば、ＬＣ１）とインタフェースで接続するよう構成される。他のいくつかの実施形態において、ＬＣデバイスドライバ１５２は、複数のＬＣ１２０（例えば、ＬＣ２、ＬＣ３、およびＬＣ４）とインタフェースで接続するよう構成される。 
【００２５】
ホストＯＳ１４０は、ハードウェアリソース（例えば、ホストハードウェア１１０）を管理および制御し、アプリケーション１５３にサービスを提供するよう構成される任意の一般的な、またはよく見られるＯＳ（例えば、Ｗｉｎｄｏｗｓ（登録商標）、Ｌｉｎｕｘ（登録商標）、またはＵｎｉｘ（登録商標））であり得る。例えば、アプリケーション１５３などのソフトウェアプログラムまたはプロセスが、特定のタスクを実行するために、ＣＰＵ処理時間、メモリ、ファイル、および／またはＩＯデバイスなどのある特定のリソースを必要とし得る。ホストＯＳ１４０は、プロセス管理コンポーネント、メモリ管理コンポーネント、ファイル管理コンポーネント、ＩＯシステム管理コンポーネント、および／または保護システムコンポーネントなどの様々なコンポーネントを含むことによって、リソースを管理し、サービスを提供し得る。プロセス管理コンポーネントは、プロセス（例えば、スレッドまたはタスク）の生成、削除、一時停止、および／または再開を実行し得る。プロセス管理コンポーネントはまた、プロセスの同期および／または通信のためのメカニズムをプロビジョニングし得る。メモリ管理コンポーネントは、メモリの割り振りおよび割り振り解除を実行し、ならびに／または、メモリの状態および／またはステータスをトラッキングおよび維持し得る。例えば、メモリ管理コンポーネントは、メモリ空間をアプリケーション１５３に割り当て、アプリケーション１５３をロードし、アプリケーション１５３によって必要とされるときにメモリの割り振りおよび割り振り解除を実行し得る。ファイル管理コンポーネントは、ファイルおよび／もしくはディレクトリの生成、ならびに／または削除を実行し得る。ファイル管理コンポーネントは、ファイルおよび／またはディレクトリの操作のための追加のプリミティブを提供し得る。ＩＯシステム管理コンポーネントは、ＬＣデバイスドライバ１５２などのデバイスドライバとインタフェースで接続して、ＬＣ１２０などのＩＯデバイスとの間でＩＯデータを伝送し得る。保護システムコンポーネントは、ソフトウェアプログラムおよび／またはプロセスによってアクセスを制御し得る。例えば、ソフトウェアプログラムは、メモリまたはハードウェアのある特定の部分にアクセスすることは許容され得るが、メモリまたはハードウェアの別の部分にアクセスすることは許容され得ない。 
【００２６】
ホストＯＳ１４０はさらに、ＩＯＩＣコンポーネント１４８を備える。ＩＯＩＣコンポーネント１４８は、ＬＣデバイスドライバ１５２およびＩＯシステム管理コンポーネントとインタフェースで接続するよう構成されるソフトウェアコンポーネントである。例えば、ＬＣデバイスドライバ１５２は、特定のＬＣ１２０を動作させるためのデバイスドライバまたはインタフェースデバイスドライバコールのセットを提供し得る。ＬＣ１２０がネットワーク機器であるとき、対応するＬＣデバイスドライバ１５２は、デバイスドライバコールのセットをネットワークデバイスドライバコールとして提供し得る。しかしながら、ホストＯＳ１４０は、ネットワーク機器とインターネットで接続するためではなく、一般的なＩＯデバイス（例えば、ＰＣＩおよび／またはＰＣＩｅデバイス）とインタフェースで接続するためのＯＳカーネルＩＯコール（例えば、Ｌｉｎｕｘ（登録商標）ｉｏｃｔｌコール）のセットを提供し得る。したがって、ＯＳカーネルＩＯコールは、ネットワークデバイスドライバコールと互換性のあるものではあり得ない。ＩＯＩＣコンポーネント１４８は、ＩＯシステム管理コンポーネントへのシム層（ｓｈｉｍ  ｌａｙｅｒ）として機能して、ネットワークデバイスドライバコールとＯＳカーネルＩＯコールとの間で変換を行う。したがって、ＩＯＩＣコンポーネント１４８は、ホストＯＳ１４０がアプリケーション１５３に対してＬＣ１２０を一般的なＩＯデバイスとして提示し、ＯＳカーネルＩＯコールのセットを通じてＩＯサービスをアプリケーション１５３に提供することを可能にする。ＩＯＩＣコンポーネント１４８がホストＯＳ１４０内のコンポーネントとして示されているが、ＩＯＩＣコンポーネント１４８は、ホストＯＳ１４０の外部のコンポーネントとして構成され得ることが留意されるべきである。
【００２７】
アプリケーション１５３は、特定のアプリケーション、アクティビティ、および／またはタスクを実行するよう構成されるソフトウェアプログラムである。ＤＣの一実施形態において、アプリケーション１５３は、コアビジネスの業務および組織の運用データを扱う情報技術（ＩＴ）のシステムアプリケーションを含んでよい。いくつかの実施形態において、アプリケーション１５３は、特定のコンピュータシステムのエミュレーションまたはソフトウェア実装である仮想マシン（ＶＭ）であり得る。そのような実施形態において、ホストＯＳ１４０は、ホストハードウェア１１０および／またはＬＣ１２０からのハードウェアリソースをＶＭに割り振り、根本的なホストハードウェア１１０がＶＭに対して透過的であるよう、ＬＣデバイスドライバ１５２と併せて全てのハードウェアインタフェースを扱う。
【００２８】
ｖＮＩＣ１６０は、仮想ＩＯデバイスとして動作するよう構成されるソフトウェアコンポーネントである。ｖＮＩＣ１６０は、ＬＣ１２０に論理的に接続される。ｖＮＩＣ１６０は、ＬＣ１２０とホストＯＳ１４０との間で抽象化層を形成する。例えば、各ｖＮＩＣ１６０は別個のＩＯデバイスとして動作し、ホストＯＳ１４０は、アプリケーション１５３に対してｖＮＩＣ１６０をローカルＩＯデバイスとして提示する。ゆえに、アプリケーション１５３は、ｖＮＩＣ１６０がホストハードウェア１１０にローカルに接続された物理ＩＯデバイスであるかのように、ｖＮＩＣ１６０へパケットを送信および／またはｖＮＩＣ１６０からパケットを受信し得る。したがって、システム１００に示されるように、ホストハードウェア１１０が４つのＬＣ１２０（例えば、ＬＣ１、ＬＣ２、ＬＣ３、およびＬＣ４）に動作上接続される一方、アプリケーション１５３は、ホストハードウェア１１０がＮ個の物理ＩＯデバイス（例えば、ｖＮＩＣ１からｖＮＩＣ  Ｎ）に結び付けられているかのように動作する。一実施形態において、ホストＯＳ１４０は、メモリデバイスからのメモリをｖＮＩＣ１６０に割り振る。例えば、各ｖＮＩＣ１６０は、送信（Ｔｘ）キューおよび受信（Ｒｘ）キューと関連付けられ得る。ここで、ＴｘキューはｖＮＩＣ１６０を介した送信の準備が整った発信パケットをキューに登録し得、Ｒｘキューは、ｖＮＩＣ１６０を介して受信される着信パケットをキューに登録し得る。 
【００２９】
ＬＣＭ１５４は、ＬＣ１２０とｖＮＩＣ１６０とを管理するよう構成されるソフトウェアプログラムである。ＬＣＭ１５４は、ＩＯリソース１６１をｖＮＩＣ１６０にマッピングおよび／または割り当てることによって、ＬＣ１２０によって提供されたＩＯリソース１６１をＬＣ１２０の物理ハードウェアから切り離す。一実施形態において、ＬＣＭ１５４は、単一のＬＣ１２０（例えば、ＬＣ１）のリソースを複数の部分へと論理的に分割し、異なる部分を異なるローカルｖＮＩＣ１６０（例えば、ｖＮＩＣ１およびｖＮＩＣ２）にマッピングする。別の実施形態において、ＬＣＭ１５４は、複数のＬＣ１２０からのＩＯリソースを論理的に組み合わせ、組み合わされたリソースを単一のローカルｖＮＩＣ１６０にマッピングする。ゆえに、ＬＣＭ１５４は、ＬＣ１２０、および／またはＬＣ１２０によって提供されるＩＯリソース１６１をエラスティックなＩＯリソースプールとして利用し得る。したがって、ＬＣＭ１５４は、更なるｖＮＩＣ１６０を追加すること、未使用のｖＮＩＣ１６０を削除すること、およびランタイムにおいて特定のｖＮＩＣ１６０に割り当てられるＩＯリソースの量を変更することによって、ＩＯ要求の変更に動的に適応し得る。ＩＯ要求は、様々な要因により、ランタイム中に変化し得る。例えば、システム１００は、ランタイムにおいて追加のＶＭ（例えば、追加のアプリケーション１５３）のためのプロビジョニングを行い得る。ここで、当該ＶＭは、ある特定の量のＩＯリソースを必要とし得る。一実施形態において、ＬＣＭ１５４は、（例えば、アプリケーション１５３として）ユーザ空間において実行される。そのような実施形態では、ＬＣＭ１５４は、ホストＯＳ１４０と連携して、ｖＮＩＣ１６０を生成し、ｖＮＩＣ１６０をＬＣ１２０にマッピングし得る。システム１００は、示されるとおりに構成され得、または代替的に、同一の機能を達成するよう当業者によって決定されるとおりに構成され得ることが留意されるべきである。
【００３０】
一実施形態において、システム１００が電源投入されたとき、ＬＣＭ１５４は、取り付けられたＬＣ１２０の情報を検索し、対応するＬＣデバイスドライバ１５２をロードし得る。ＬＣデバイスドライバ１５２は、デバイス初期化を実行してＬＣ１２０を初期化し得る。ロードおよびデバイス初期化を問題なく行い次第、ＬＣＭ１５４は、ＬＣ１２０から取り出された情報にしたがって、ローカルｖＮＩＣ１６０を生成および／または初期化するようホストＯＳ１４０に命令し得る。例えば、ホストＯＳ１４０がＬｉｎｕｘ（登録商標）カーネルであるとき、ローカルｖＮＩＣ１６０は、Ｌｉｎｕｘ（登録商標）タップメカニズムを使用することによって生成され得る。Ｌｉｎｕｘ（登録商標）タップメカニズムは、物理媒体の代わりにプログラム空間（例えば、仮想カーネルネットワークデバイス）でのパケットの受信および送信を可能にする。ローカルｖＮＩＣ１６０が生成および初期化された後、ＬＣＭ１５４は、ＬＣ１２０をローカルｖＮＩＣ１６０にマッピングする。その後、アプリケーション１５３は、ＯＳカーネルＩＯコールを使用することによって、ｖＮＩＣへデータを送信および／またはｖＮＩＣからデータを受信し始め得る。システム１００が電源投入されている間に追加のＬＣ１２０が設置されたとき、ＬＣＭ１５４およびホストＯＳ１４０は、同様のメカニズムを使用して、追加のＬＣ１２０のためのローカルｖＮＩＣ１６０を初期化および生成し得ることが留意されるべきである。
【００３１】
アプリケーション１５３が、例えば、ＯＳカーネルＩＯ書き込みコール（例えば、バイト書き込み）を介して、ローカルｖＮＩＣ１６０に対してＩＯ書き込み動作を実行するようホストＯＳ１４０にリクエストするとき、ホストＯＳ１４０は、ＬＣＭ１５４にリクエストを向け直す。リクエストを受信し次第、ＬＣＭ１５４は、マッピング解除を実行して、アプリケーション１５３によってリクエストされたローカルｖＮＩＣ１６０に対応するＬＣ１２０を決定する。ホストＯＳ１４０は、ＩＯＩＣコンポーネント１４８と、ＬＣ１２０に対応するＬＣデバイスドライバ１５２とを介してＩＯ書き込み動作を実行する。例えば、ＩＯＩＣコンポーネント１４８は、ＯＳカーネルＩＯ書き込みコールを、対応するＬＣデバイスドライバ１５２によって提供されるデバイスドライバ書き込みコールに変換する。その後、ＬＣデバイスドライバ１５２は、ＬＣ１２０によって使用されるプロトコルおよび／またはフォーマットにしたがって、対応するＬＣ１２０にデータを書き込む。アプリケーション１５３は、ローカルｖＮＩＣ１６０において、送信のためにデータをキューに登録し得ることが留意されるべきである。
【００３２】
ＩＯ読み出し動作は、ＩＯ書き込み動作について説明されたものと同様のメカニズムを使用することによって実行され得る。例えば、アプリケーション１５３は、ＯＳカーネルＩＯ読み出しコール（例えば、バイト読み出し）を介して、ローカルｖＮＩＣ１６０からデータを読み出すようホストＯＳ１４０にリクエストし得る。ホストＯＳ１４０は、リクエストをＬＣＭ１５４に向け直す。ＬＣＭ１５４は、マッピング解除を実行して、アプリケーション１５３によってリクエストされたローカルｖＮＩＣ１６０に対応するＬＣ１２０を決定する。ホストＯＳ１４０は、ＩＯＩＣコンポーネント１４８と、ＬＣ１２０に対応するＬＣデバイスドライバ１５２とを介してＩＯ読み出し動作を実行する。ＩＯＩＣコンポーネント１６０は、ＯＳカーネルＩＯ読み出しコールを、ＬＣデバイスドライバ１５２によって提供されるデバイスドライバ読み出しコールに変換する。ＬＣデバイスドライバ１５２は、ＬＣ１２０によって使用されるプロトコルおよび／またはフォーマットにしたがって、ＬＣ１２０からリクエストされたデータを読み出す。ＩＯＩＣコンポーネント１６０は、ＬＣデバイスドライバ１５２によって提供されるデバイスドライバコールバックまたはリターンコールを介して、ＬＣ１２０から読み出されたデータを受信する。ＩＯＩＣコンポーネント１６０は、ＯＳカーネルＩＯリターンコールを介してデータをアプリケーション１５３に提供し得る。ＬＣデバイスドライバ１５２は、ローカルｖＮＩＣ１６０において、ＬＣ１２０から受信されたデータをキューに登録し得ることが留意されるべきである。 
【００３３】
図２は、マルチホスト環境において動作するコンピュータシステム２００の実施形態の概略図である。システム２００は、システム１００と同様であるが、複数のホストを備え得る。例えば、システム２００は、ホスト１１０と同様の第１のホストハードウェア２１１および第２のホストハードウェア２１２を備える。第１のホストハードウェア２１１は、第１のホストＯＳ２４１によって制御および管理される。第２のホストハードウェア２１２は、第２のホストＯＳ２４２によって制御および管理される。第１のホストＯＳ２４１および第２のホストＯＳ２４２は、ホストＯＳ１４０と同様である。第１のホストＯＳ２４１および第２のホストＯＳ２４２は各々、ＩＯＩＣコンポーネント１４８と同様のＩＯＩＣコンポーネント２４８を有する。システム２００はさらに、スイッチ１３０と同様の複数のスイッチ２３０と、リンク１３１と同様の複数のリンク２３１と、ＬＣ１２０と同様の複数のＬＣ２２０とを備える。ＬＣ２２０は、ＩＯリソース２６３をシステム２００に提供する。第１のホストハードウェア２１１、第２のホストハードウェア２１２、およびＬＣ２２０は、スイッチ２３０およびリンク２３１を介して相互接続される。システム１００と同様に、様々なソフトウェアプログラムおよび／またはコンポーネントが、第１のホストハードウェア２１１および第２のホストハードウェア２１２において実行され得る。例えば、ＬＣデバイスドライバ１５２と同様の複数のＬＣデバイスドライバ２５２と、アプリケーション１５２と同様の複数のアプリケーション２５３とが、第１のホストハードウェア２１１および／または第２のホストハードウェア２１２において実行され得る。いくつかのアプリケーション２５３が、第１のホストハードウェア２１１および第２のホストハードウェア２１２の両方において実行され得る。しかしながら、ＬＣデバイスドライバ２５２は特定のハードウェアに専用のものである。例えば、あるＬＣデバイスドライバのセット２５２が第１のホストハードウェア２１１において実行され得、第１のホストＯＳ２４１とＬＣ２２０との間でインタフェースで接続し、別のＬＣデバイスドライバのセット２５２が、第２のホストハードウェア２１２において実行され得、第２のホストＯＳ２４２とＬＣ１２０との間でインタフェースで接続する。 
【００３４】
システム１００と同様に、ＬＣ２２０は、ＬＣＭ１５４と同様のＬＣＭ２５４によって管理および制御される。しかしながら、ＬＣＭ２５４は、ＬＣ２２０によって提供されたＩＯリソース２６３を第１のホストＯＳ２４１および第２のホストＯＳ２４２の中で分配し得る。例えば、ＬＣＭは、ＩＯリソース２６３の第１の部分を第１の複数のローカルｖＮＩＣ２６１（例えば、ｖＮＩＣ１からＮＩＣ  Ｍ）にマッピングし、第１の複数のローカルｖＮＩＣ２６１を第１のホストＯＳ２４１に提供する。同様に、ＬＣＭ２５４は、ＩＯリソース２６３の第２の部分を第２の複数のローカルｖＮＩＣ２６２（例えば、ｖＮＩＣ  Ｍ＋１からｖＮＩＣ  Ｎ）にマッピングし、第２の複数のローカルｖＮＩＣ２６２を第２のホストＯＳ２４２に提供する。ＬＣＭ２５４は、システム１００で上述されたものと実質的に同様のメカニズムを使用することによって、第１のホストＯＳ２４１および／または第２のホストＯＳと対話し得る。しかしながら、示されるように、ＬＣＭ２５４は第２のホストハードウェア２１２において実行される。したがって、ＬＣＭ２５４は、リンク２３１とスイッチ２３０とを介して第１のホストＯＳ２４１と通信し得る。例えば、ＬＣＭ２５４は、ＩＯ設定メッセージを第１のホストＯＳ２４１に送信して、ローカルｖＮＩＣ２６１を生成するよう第１のホストＯＳ２４１にリクエストし得、第１のホストＯＳ２４１は、ＩＯアクセスリクエストをＬＣＭ２５４に送信し得、ＬＣＭ２５４は、ＩＯアクセスリクエストに対する、ローカルｖＮＩＣのリモートＬＣへのマッピングを決定し得、マッピングを第１のホストＯＳ２４１に送信し得る。ＬＣＭ２５４は、任意の適切な数のホストを管理するよう構成され得ることが留意されるべきである。加えて、システム２００は、示されるとおりに構成され得、または代替的に、同一の機能を達成するよう当業者によって決定されるとおりに構成され得る。
【００３５】
図３は、ＮＥ３００の例示的実施形態の概略図である、ＮＥ３００は、システム１００および２００などのコンピュータシステムにおいてホストの機能を果たし得る。例えば、ＮＥ３００は、ＤＣにおけるサーバホスト、または、コンピュータネットワークにおけるネットワークノードであり得る。ＮＥ３００は、本明細書において説明されたＬＣ管理、マッピング、およびＩＯリソース割り振りメカニズムを実装および／またはサポートするよう構成され得る。ＮＥ３００は単一のノードにおいて実装され得、または、ＮＥ３００の機能は複数のノードにおいて実装され得る。当業者ならば認識しているように、ＮＥという用語は様々なデバイスを包含し、ＮＥ３００はその例に過ぎない。ＮＥ３００は、説明を明確にする目的で含まれるが、決して本開示のアプリケーションを特定のＮＥの実施形態、またはＮＥの実施形態のクラスに限定するようには意図されていない。本開示において説明された特徴および／または方法のうちの少なくともいくつかが、ＮＥ３００などのネットワーク装置またはモジュールにおいて実装され得る。例えば、本開示の特徴および／または方法は、ハードウェア、ファームウェア、および／またはハードウェア上で動作するようインストールされたソフトウェアを用いて実装され得る。図３に示されるように、ＮＥ３００は、送受信機（Ｔｘ／Ｒｘ）３１０を備えてよい。Ｔｘ／Ｒｘ３１０は、送信機、受信機、またはそれらの組み合わせであり得る。それぞれ、Ｔｘ／Ｒｘ３１０が、ＬＣ１２０などの他のノードへフレームを送信および／または当該他のノードからフレームを受信するための複数のダウンストリームポート３２０（例えば、ＩＯポート）に連結され得、Ｔｘ／Ｒｘ３１０が、他のノードへフレームを送信および／または他のノードからフレームを受信するための複数のアップストリームポート３５０（例えば、ＩＯポート）に連結され得る。フレームを処理し、および／または、どのノードにフレームを送信するかを決定すべく、プロセッサ３３０がＴｘ／Ｒｘ３１０に連結され得る。プロセッサ３３０は、１または複数のマルチコアプロセッサ、および／または、データストア、バッファなどとして機能し得るメモリデバイス３３２を備えてよい。プロセッサ３３０は、一般的なプロセッサとして実装され得、または、１または複数のＡＳＩＣおよび／またはデジタル信号プロセッサ（ＤＳＰ）の一部であり得る。プロセッサ３３０は、それぞれＯＳ動作およびＬＣ管理動作を実行し得るホストＯＳモジュール３３３およびＬＣＭモジュール３３４を有し得、以下でより詳細に説明される方法４００、５００、６００、７００、および８００を実装し得る。ゆえに、ホストＯＳモジュール３３３、ＬＣＭモジュール３３４、および関連する方法およびシステムを包含することで、ＮＥ３００の機能に対する改善がもたらされる。代替的な実施形態において、ホストＯＳモジュール３３３およびＬＣＭモジュール３３４は、プロセッサ３３０によって実行され得る、メモリデバイス３３２に格納された命令として実装され得る。メモリデバイス３３２は、例えば、ランダムアクセスメモリ（ＲＡＭ）といった、一時的にコンテンツを格納するためのキャッシュを有し得る。例えば、メモリデバイス３３２は、１または複数のパケットキュー３３５を格納するよう構成され得る。加えて、メモリデバイス３３２は、例えば、リードオンリメモリ（ＲＯＭ）といった、比較的より長くコンテンツを格納するための長期ストレージを含み得る。例えば、キャッシュおよび長期ストレージは、ダイナミックＲＡＭ（ＤＲＡＭ）、ソリッドステートドライブ（ＳＳＤ）、ハードディスク、またはそれらの組み合わせを含み得る。
【００３６】
実行可能命令をＮＥ３００上にプログラムおよび／またはロードすることによって、プロセッサ３３０および／またはメモリデバイス３３２のうちの少なくとも１つが変更され、本開示によって教示される新規の機能を有する、例えば、マルチコア転送アーキテクチャといった特定のマシンまたは装置へとＮＥ３００を部分的に転換することが理解される。電気工学およびソフトウェア工学の技術では基本的なことであるが、実行可能なソフトウェアをコンピュータにロードすることによって実装され得る機能は、周知の設計ルールによってハードウェア実装に変換され得る。概念をソフトウェアで実装するか、ハードウェアで実装するかの決定は、通常、ソフトウェアドメインからハードウェアドメインへの変換に伴うあらゆる問題ではなく、設計の安定性と生成されるユニット数との考察で決まる。概して、さらに頻繁に変更される可能性のある設計はソフトウェアで実装されるのが好ましいと考えられる。なぜなら、ハードウェア実装のやり直しは、ソフトウェア設計のやり直しより費用がかかるからである。概して、安定的であり、大量生産される設計は、ハードウェアで、例えば、ＡＳＩＣで、実装されるのが好ましいと考えられる。なぜなら、大量生産工程では、ハードウェア実装はソフトウェア実装より費用がかからないと考えられるからである。しばしば、設計はソフトウェア形態で開発および試験され得、後に、ソフトウェアの命令をハードウェアに組み込むＡＳＩＣにおいて、周知の設計ルールによって均等なハードウェア実装に転換され得る。新しいＡＳＩＣによって制御されるマシンが特定のマシンまたは装置であるのと同じように、実行可能命令がプログラムおよび／またはロードされたコンピュータは同様に、特定のマシンまたは装置であるとみなされ得る。
【００３７】
図４は、ＬＣ１２０および２２０などのネットワークＬＣを検出および初期化するための方法４００の実施形態のプロトコル図である。方法４００は、システム１００および２００、ならびにＮＥ３００などのホストによって実装される。方法４００は、ＬＣＭ１５４および２５４などのＬＣＭと、ホストＯＳ１４０、２４１、および２４２などのホストＯＳと、ＬＣデバイスドライバ１５２および２５２などのＬＣデバイスドライバと、ネットワークＬＣとの間で実装される。方法４００は、ホストに電源が入れられたときに始まる。段階４１０において、ＬＣＭはホストＯＳに登録して、システムにおける全てのネットワークＬＣの物理イベントをリッスンする。段階４２０において、ネットワークＬＣは、例えば、ユーザによってホストのスロットへと挿入される。段階４３１において、ネットワークＬＣの挿入が、物理イベント（例えば、インジケーション信号または割り込み信号）を引き起こす。当該物理イベントはまずホストＯＳによって受信される。段階４３２において、ホストＯＳは物理イベントをＬＣＭにディスパッチする。なぜなら、ＬＣＭは、段階４１０においてＬＣの物理イベントをリッスンするよう、ホストＯＳに登録したからである。段階４４０において、物理イベントを受信し次第、ＬＣＭは、ネットワークＬＣの情報を取り出し、対応するＬＣデバイスドライバを選択する。いくつかのネットワークＬＣ情報は、ネットワークＬＣによってサポートされるＩＯのタイプ、帯域幅、および／またはスループットを含み得る。段階４５０において、ＬＣＭは、対応するＬＣデバイスドライバをロードする。段階４６０において、ＬＣデバイスドライバがロードされたとき、ＬＣデバイスドライバは、例えば、１または複数の書き込みコマンドをＬＣに送信することによって、ネットワークＬＣを設定および／または初期化する。 
【００３８】
図５は、ネットワークＬＣをローカルｖＮＩＣにマッピングするための方法５００の実施形態のプロトコル図である。方法５００は、システム１００および２００、ならびにＮＥ３００などのホストによって実装される。方法５００は、ＬＣＭ１５４および２５４などのＬＣＭと、ホストＯＳ１４０、２４１、および２４２などのホストＯＳとの間で実装される。方法５００は、ホストが、例えば、方法４００を使用することによって、接続されたネットワークＬＣを首尾よく検出および初期化した後に始まる。段階５１０において、ＬＣＭは、ローカルｖＮＩＣ１６０、２６１、および２６２などのローカルｖＮＩＣを決定し、（例えば、方法４００の段階４４０において）ＬＣの検出および初期化中に先に取り出されたＬＣ情報にしたがって、ローカルｖＮＩＣとネットワークＬＣとの間のマッピングを実行する。例えば、ＬＣＭは、ネットワークＬＣをローカルｖＮＩＣにマッピングするマップを格納し得る。一実施形態において、ＬＣＭは、単一のネットワークＬＣのＩＯリソースを複数の部分へと論理的に分割し、異なる部分を異なるローカルｖＮＩＣにマッピングし得る。別の実施形態において、ＬＣＭは、複数のネットワークＬＣからのＩＯリソースを論理的に組み合わせ、組み合わされたＩＯリソースを単一のローカルｖＮＩＣにマッピングし得る。さらに別の実施形態において、ＬＣＭは、単一のネットワークＬＣの全てのＩＯリソースを単一のローカルｖＮＩＣにマッピングし得る。段階５２０において、ＬＣＭは、ネットワークＬＣおよび割り振られたリソースの情報を提供することによって、ローカルｖＮＩＣを生成および／または初期化するようホストＯＳに命令する。段階５３０において、ホストＯＳは、ＬＣＭから受信された命令にしたがって、ローカルｖＮＩＣを生成および初期化する。例えば、ホストＯＳがＬｉｎｕｘ（登録商標）カーネルであるとき、ホストＯＳは、Ｌｉｎｕｘ（登録商標）タップメカニズムを使用することによって、ローカルｖＮＩＣを生成し得る。
【００３９】
図６は、ローカルＩＯサービスをアプリケーションに提供するための方法６００の実施形態のプロトコル図である。方法６００は、システム１００および２００、ならびにＮＥ３００などのホストによって実装される。方法６００は、アプリケーション１５３および２５３などのアプリケーションと、ＬＣＭ１５４および２５４などのＬＣＭと、ホストＯＳ１４０、２４１、および２４２などのホストＯＳと、ＬＣデバイスドライバ１５２および２５２などのＬＣデバイスドライバと、ＬＣ１２０および２２０などのネットワークＬＣとの間で実装される。方法６００は、ホストが、例えば、方法５００を使用することによって、ホストに接続されたネットワークＬＣに基づいてローカルｖＮＩＣを生成および初期化した後に始まる。例えば、ホストＯＳはローカルｖＮＩＣをアプリケーションに割り当てた。段階６１０において、アプリケーションは、リクエストをホストＯＳに送信して、例えば、ＯＳカーネルＩＯコールを介してローカルｖＮＩＣにアクセスする。段階６２０において、リクエストを受信し次第、ホストＯＳは、当該リクエスト、または少なくとも、リクエストされたローカルｖＮＩＣと関連付けられた情報をＬＣＭに転送する。段階６３０において、当該情報を受信し次第、ＬＣＭはマッピング解除機能を実行して、リクエストされたローカルｖＮＩＣに対応するＬＣデバイスドライバを決定する。例えば、ＬＣＭは、ネットワークＬＣをローカルｖＮＩＣにマッピングするマップを先に格納し得る。段階６４０において、対応するＬＣデバイスドライバを決定した後、ＬＣＭは、対応するＬＣデバイスドライバを使用してＩＯアクセスを完了するようホストＯＳに命令する。段階６５０において、ホストＯＳは、ＬＣＭによって提供されたＬＣデバイスドライバにリクエストを送信することによって、ＩＯアクセスの処理を続ける。上述されたように、ホストＯＳは、ＩＯＩＣコンポーネント１４８および２４８などのＩＯＩＣコンポーネントを使用して、ＯＳカーネルＩＯコールをデバイスドライバコールに変換し得る。段階６６０において、リクエストを受信し次第、ＬＣデバイスドライバは対応するＬＣとインタフェースで接続して、リクエストにしたがってＩＯ動作を実行する。ＬＣとＬＣデバイスドライバとの間には複数のＩＯトランザクションが存在し得ることが留意されるべきである。加えて、ＩＯリクエストが完了し次第、ＬＣデバイスドライバは、完了を示すべくホストＯＳに信号を送り返し得、ホストＯＳはさらにアプリケーションを通知し得る。 
【００４０】
ＤＣの一実施形態において、ＩＯリクエストがＩＯ読み出しリクエストであるとき、物理ＬＣから読み出されたデータは、スイッチ１３０および２３０などのバックプレーンスイッチからルーティングされ得る。当該スイッチは、カプセル化および／または逆多重化を実行することによってデータを処理し得る。ＬＣデバイスドライバがデータを受信したとき、ＬＣデバイスドライバは、対応するローカルｖＮＩＣの、パケットキュー３３５などのパケットキューまたはＲｘキューにデータを登録し得る。同様の動作がＩＯ書き込みについてデータに対して実行され得るが、当該動作は逆の順序である場合がある。例えば、データは、ローカルｖＮＩＣのパケットキューまたはＴｘキューにおいて登録され得、スイッチは、対応するネットワークＬＣにデータを送信する前にデータに対してカプセル化および逆多重化を実行し得る。 
【００４１】
図７は、ローカルＩＯリソースプールを定義するための方法７００の実施形態のフローチャートである。方法７００は、ＬＣＭ１５４および２５４などのＬＣＭによって実装される。方法７００は、ホストシステム１００および２００などのホストシステムに電源が入れられたときに実装される。方法７００は方法４００および５００と同様である。例えば、ホストシステムは、ホストＯＳ１４０、２４１、および２４２などのＯＳの制御下にある。段階７１０において、リモートＬＣ物理イベントをリッスンすることへの関心がＯＳに登録される。例えば、リモートＬＣ物理イベントは、ＬＣ１２０および２２０などのリモートＬＣの挿入を含み得る。段階７２０において、リモートＬＣの挿入を示す物理イベントが受信される。例えば、リモートＬＣが挿入または設置されたとき、割り込み信号がＯＳに送信され得る。ＯＳは、割り込み信号を物理イベントにマッピングし、物理イベントをリッスンするよう登録されたソフトウェアコンポーネントに物理イベントを送信し得る。段階７３０において、物理イベントを受信し次第、リモートＬＣのＩＯリソース情報（例えば、ＩＯタイプおよびリソース容量）が取得される。加えて、ＬＣボードプロパティと関連付けられた他の情報が取得され得る。段階７４０において、リモートＬＣに対応するデバイスドライバがロードされる。例えば、デバイスドライバがロードされたとき、デバイスドライバは、対応するリモートＬＣを初期化および／または設定し得、これにより、リモートＬＣは動作の準備が整い得る。段階７５０において、ＩＯリソース情報にしたがってＩＯリソースプールが定義される。段階７６０において、ＩＯリソースをＩＯリソースプールからローカルｖＮＩＣに割り振ることによって、リモートＬＣと、ローカルｖＮＩＣ１６０、２６１、および２６２などの複数のローカルｖＮＩＣとの間のマッピングが決定される。例えば、ＬＣは、メモリデバイス３３２などのメモリデバイスにマッピングを格納し得る。一実施形態において、ＬＣＭは、単一リモートＬＣからの全てのＩＯリソースを単一のローカルｖＮＩＣに割り振り得る。別の実施形態において、ＬＣＭは、単一リモートＬＣのＩＯリソースを複数のローカルｖＮＩＣの間で論理的に分割し得る。さらに別の実施形態において、ＬＣＭは、種々のリモートＬＣからのＩＯリソースを単一のローカルｖＮＩＣに割り振り得る。段階７７０において、ローカルｖＮＩＣを生成および初期化するための命令がＯＳに送信される。例えば、ＯＳは、ローカルｖＮＩＣをローカルＩＯデバイスとして提示することによって、ＩＯサービスをアプリケーションに提供し得、ＯＳカーネルＩＯコールおよび／またはインタフェースを介してアプリケーションがローカルｖＮＩＣにアクセスすることを可能にし得る。 
【００４２】
図８は、ローカルＩＯサービスをアプリケーションに提供するための方法８００の実施形態のフローチャートである。方法８００は、ＬＣＭ１５４および２５４などのＬＣＭによって実装される。方法８００は、システム１００および２００などのホストシステムが、例えば、方法７００を使用することによって、ＬＣ１２０および２２０などのリモートＬＣをローカルｖＮＩＣ１６０、２６１、および２６２などのローカルｖＮＩＣにマッピングした後に実装される。例えば、ホストシステムは、ホストＯＳ１４０、２４１、および２４２などのホストＯＳの下で動作させられ得、ホストＯＳは、ローカルｖＮＩＣをアプリケーションに割り当て得る。段階８１０において、アプリケーションが、ローカルｖＮＩＣに対してＩＯ動作を実行するようリクエストするというインジケーションが、例えば、ＯＳから受信される。段階８２０において、インジケーションを受信し次第、例えば、（例えば、段階７６０において）先に格納された、リモートＬＣとローカルｖＮＩＣとの間のマッピングにしたがって、ローカルｖＮＩＣに対応するリモートＬＣが決定される。段階８３０において、ＩＯ動作は当該リモートＬＣに向けられる。例えば、ＬＣＭは、リモートＬＣに対応する、ＬＣデバイスドライバ１５２および２５２などのＬＣデバイスドライバを介して、リモートＬＣへと向けられたＩＯ動作を進めるようＯＳに命令し得る。あるいは、ＬＣＭは、直接ＩＯ動作を実行するよう、リモートＬＣに対応するＬＣデバイスドライバにリクエストし得る。
【００４３】
図９は、エラスティックなローカルＩＯリソースプールを提供するための方法９００の実施形態のフローチャートである。方法９００は、ＬＣＭ１５４および２５４などのＬＣＭによって実装される。方法９００は、ホストシステム１００および２００などのホストシステムが動作中であるとき（例えば、方法４００、５００、６００、７００、および／または８００を適用した後）に実装される。例えば、ホストシステムに接続された、リモートＬＣ１２０および２２０などのリモートＬＣからＩＯリソースプールが生成され、リモートＬＣによって提供されたＩＯリソースは、ローカルｖＮＩＣ１６０、２６１、および２６２などのローカルｖＮＩＣに割り振られる。段階９１０において、例えば、ホストＯＳ１４０、２４１、および２４２などのＯＳから、ＩＯリソース要件の変更が受信される。例えば、ローカルｖＮＩＣを使用するアプリケーションが、ＩＯリソースの量を増加または低減することを必要とし得、ＩＯリソースの量を増加または低減するようＯＳにリクエストし得る。あるいは、アプリケーションがローカルｖＮＩＣにおいてＩＯ動作を終了し得、したがって、ホストＯＳはローカルｖＮＩＣを除去するようリクエストし得る。段階９２０において、ＩＯリソース要件の変更を受信し次第、ＩＯリソース要件の変更にしたがってＩＯリソースが再割り振りされる。例えば、当該変更が特定のローカルｖＮＩＣについてより大量のＩＯリソースを必要とするとき、ＬＣＭは、より大量のＩＯリソースをＩＯリソースプールからローカルｖＮＩＣに割り振り得る。あるいは、当該変更が特定のローカルｖＮＩＣについてより少ないＩＯリソースを必要とするとき、または特定のローカルｖＮＩＣを終了すべく、ＬＣＭは、特定のローカルｖＮＩＣに割り振られたＩＯリソースをＩＯリソースプールに戻し得る。ゆえに、ＩＯリソースはＩＯ要求にしたがって、動的に再割り振りされ得る。 
【００４４】
本開示においていくつかの実施形態が提供されてきたが、開示されたシステムおよび方法は、本開示の主旨または範囲から逸脱することなく、他の多くの特定の形態で具現化され得ることが理解されるべきである。本例は例示的なものであって限定的なものではないとみなされるべきであり、その意図は、本明細書において与えられた詳細に限定されるべきではない。例えば、様々な要素またはコンポーネントは、別のシステムに組み合わされ、もしくは統合される場合があり、または、ある特定の特徴が省略され、もしくは実装されない場合がある。 
【００４５】
加えて、様々な実施形態において個別のまたは別個のものとして説明および示された技術、システム、サブシステム、および方法が、本開示の範囲から逸脱することなく、他のシステム、モジュール、技術、または方法と組み合わされ、または統合され得る。連結される、または直接連結される、または互いに通信し合うとして示されまたは説明された他のアイテムは、電気的にか、機械的にか、またはその他の方式によってかは問わず、いくつかのインタフェース、デバイス、または中間コンポーネントを介して間接的に連結され得、または通信し得る。変更、置き換え、および修正の他の例が当業者によって確かめられ、本明細書において開示された主旨および範囲から逸脱することなく成され得る。
［項目１］
入出力（ＩＯ）リソースを提供する複数のリモートラインカード（ＬＣ）に連結するよう構成される複数の物理ＩＯポートと、
上記複数の物理ＩＯポートに連結され、
上記リモートＬＣを複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）に、上記ＩＯリソースの少なくともいくつかをローカルの上記複数のｖＮＩＣに割り振ることによってマッピングし、
上記ｖＮＩＣのうちの第１のｖＮＩＣにアクセスするリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを受信し、
上記リモートＬＣのうちの、上記第１のｖＮＩＣに対応する第１のリモートＬＣを決定し、
上記第１のリモートＬＣにアクセスするように上記リクエストを向けるよう構成されるプロセッサと
を備える装置。
［項目２］
上記プロセッサはさらに、
上記ＬＣのうちの１つのリモートＬＣのＩＯリソースを少なくとも第１の部分および第２の部分へと論理的に分割すること、
上記第１の部分を１つのｖＮＩＣに割り当てること、および
上記第２の部分を別のｖＮＩＣに割り当てること
によって上記ＩＯリソースを上記ｖＮＩＣに割り振るよう構成される、項目１に記載の装置。
［項目３］
上記プロセッサはさらに、
１つのリモートＬＣと関連付けられた上記ＩＯリソースの少なくとも第１の部分を上記第１のｖＮＩＣに割り当てること、および
別のリモートＬＣと関連付けられた上記ＩＯリソースの少なくとも第２の部分を上記第１のｖＮＩＣに割り当てること
によって上記ＩＯリソースを上記ｖＮＩＣに割り振るよう構成される、項目１に記載の装置。
［項目４］
上記第１のｖＮＩＣは、第１の量の上記ＩＯリソースが割り振られ、上記プロセッサはさらに、
上記第１の量の上記ＩＯリソースを変更するリクエストを受信し、
上記リクエストにしたがって、第２の量の上記ＩＯリソースをローカルの上記第１のｖＮＩＣに再割り振りするよう構成される、項目１に記載の装置。
［項目５］
上記ＩＯリソースは、メモリ、帯域幅、ネットワークポート、コンピューティングリソース、またはそれらの組み合わせを含み、上記第１の量の上記ＩＯリソースは、上記メモリのサイズ、上記帯域幅の量、上記ネットワークポートの数、上記コンピューティングリソースの一部、またはそれらの組み合わせを含む、項目４に記載の装置。
［項目６］
上記物理ＩＯポートは相互接続を介して上記リモートＬＣに連結され、上記プロセッサはさらに、上記ＯＳカーネルＩＯコールを、上記第１のリモートＬＣおよび上記相互接続と関連付けられたデバイスドライバコールに変換するよう構成される、項目１に記載の装置。
［項目７］
上記相互接続は、オープンシステム相互接続（ＯＳＩ）第２層（Ｌ２）ネットワーク接続、ＯＳＩ第３層（Ｌ３）ネットワーク接続、スイッチングファブリック、またはそれらの組み合わせを含む、項目６に記載の装置。
［項目８］
上記プロセッサはさらに、
仮想マシン（ＶＭ）をプロビジョニングし、
上記第１のｖＮＩＣを上記ＶＭに割り当てるよう構成され、
上記ＯＳカーネルＩＯコールは上記ＶＭから受信される、
項目１に記載の装置。
［項目９］
上記物理ＩＯポートはさらに、リモートホストに連結するよう構成され、上記ｖＮＩＣの少なくとも１つは上記リモートホストと関連付けられる、項目１に記載の装置。
［項目１０］
オペレーティングシステム（ＯＳ）の下で動作するローカルサーバホストによって実装される方法であって、
上記ローカルサーバホストに連結された複数のリモートラインカード（ＬＣ）の入出力（ＩＯ）リソース情報を取得する段階と、
上記リモートＬＣの上記ＩＯリソース情報にしたがって、ＩＯリソースプールを定義する段階と、
上記リモートＬＣの上記ＩＯリソース情報にしたがって、上記ＩＯリソースプールからＩＯリソースを割り振ることによって、上記リモートＬＣと複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）との間のマッピングを決定する段階と、
上記ｖＮＩＣのうちの第１のｖＮＩＣにアクセスするリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを受信する段階と、
上記リモートＬＣのうちの、上記第１のｖＮＩＣに対応する第１のリモートＬＣを決定する段階と、
上記第１のリモートＬＣにアクセスするように上記リクエストを向ける段階と
を備える方法。
［項目１１］
上記リモートＬＣは、オープンシステム相互接続（ＯＳＩ）第２層（Ｌ２）プロトコル、ＯＳＩ第３層（Ｌ３）プロトコル、またはそれらの組み合わせを含むネットワークプロトコルと関連付けられた相互接続を介して上記ローカルサーバホストに接続され、上記方法はさらに、上記ＯＳカーネルＩＯコールと、上記第１のリモートＬＣおよび上記相互接続と関連付けられたデバイスドライバコールとの間のＩＯインタフェース変換を実行する段階を備える、項目１０に記載の方法。
［項目１２］
上記ＯＳカーネルＩＯコールは、ペリフェラルコンポーネントインターコネクト（ＰＣＩ）デバイス、またはＰＣＩ−エクスプレス（ＰＣＩｅ）デバイスと関連付けられる、項目１１に記載の方法。
［項目１３］
ＩＯリソース要件の変更を受信する段階と、
上記ＩＯリソース要件の変更に応答して、上記ＩＯリソースプールの上記ＩＯリソースを動的に再割り振りする段階とをさらに備え、
上記ＩＯリソース要件の変更は、上記ｖＮＩＣのうちの第１のｖＮＩＣの増加されたＩＯリソースの量、上記ｖＮＩＣのうちの第２のｖＮＩＣの低減されたＩＯリソースの量、更なるｖＮＩＣの追加、既存のｖＮＩＣの削除、またはそれらの組み合わせを含む、
項目１０に記載の方法。
［項目１４］
上記ＩＯリソースプールは、メモリ、帯域幅、ネットワークポート、コンピューティングリソース、またはそれらの組み合わせを含み、上記ＩＯリソースの量は、上記メモリのサイズ、上記帯域幅の量、上記ネットワークポートの数、上記コンピューティングリソースの一部、もしくはそれらの組み合わせを含む、項目１３に記載の方法。
［項目１５］
上記ローカルサーバホストに連結されたリモートサーバホストにＩＯ設定を送信する段階であって、上記ＩＯ設定は、上記ｖＮＩＣのうちの少なくとも第２のｖＮＩＣと関連付けられた設定情報を含む、段階と、
上記第２のｖＮＩＣにアクセスする、上記リモートサーバホストからのＩＯリクエストを受信する段階と、
上記リモートＬＣのうちの、上記第２のｖＮＩＣに対応する第２のリモートＬＣを決定する段階と、
上記リモートサーバホストにＩＯマップを送信して、上記第２のリモートＬＣにアクセスするよう上記リモートサーバホストに命令する段階と
をさらに備える、項目１１に記載の方法。
［項目１６］
入出力（ＩＯ）リソースを提供する複数のリモートラインカード（ＬＣ）、および
リモートホスト
に連結するよう構成された複数の物理ＩＯポートと、
上記複数の物理ＩＯポートに連結され、
上記複数のリモートＬＣのリソース情報を取得し、
上記リモートＬＣの上記リソース情報にしたがってＩＯリソースプールを定義し、
上記リモートＬＣと、複数の仮想ネットワークインタフェースカード（ｖＮＩＣ）であって、そのうちの少なくとも第１のｖＮＩＣが上記リモートホストと関連付けられた複数のｖＮＩＣとの間のマッピングを、ＩＯリソースを上記ＩＯリソースプールから上記ｖＮＩＣに割り振ることによって決定し、
上記第１のｖＮＩＣと関連付けられた設定情報を含む設定メッセージを、上記ＩＯポートを介して上記リモートホストに送信するよう構成されるプロセッサと
を備える装置。
［項目１７］
上記プロセッサはさらに、
上記第１のｖＮＩＣと関連付けられたＩＯアクセスを示す上記リモートホストからのＩＯアクセスメッセージを、上記ＩＯポートを介して受信し、
上記マッピングにしたがって、上記第１のｖＮＩＣに対応するリモートＬＣを決定し、
上記ＩＯポートを介してマッピングメッセージを上記リモートホストに送信して、上記ＩＯアクセスを上記第１のｖＮＩＣに対応する上記リモートＬＣに向けるよう上記リモートホストに命令する
よう構成される、項目１６に記載の装置。
［項目１８］
上記プロセッサはさらに、
更なるｖＮＩＣを追加するリクエストを受信し、
上記更なるｖＮＩＣを生成し、
上記ＩＯリソースのうちの少なくともいくつかを上記更なるｖＮＩＣに割り振る
よう構成される、項目１７に記載の装置。
［項目１９］
上記プロセッサはさらに、
上記第１のｖＮＩＣのＩＯ動作を終了するリクエストを受信し、
上記第１のｖＮＩＣに対応するリモートＬＣと、上記第１のｖＮＩＣに割り振られた上記リモートＬＣのＩＯリソースの一部を、上記リモートＬＣと上記ｖＮＩＣとの間の上記マッピングにしたがって決定し、
上記第１のｖＮＩＣによって使用される上記リモートＬＣの上記ＩＯリソースの上記一部を上記ＩＯリソースプールに返す
よう構成される、項目１７に記載の装置。
［項目２０］
上記物理ＩＯポートは、相互接続を介して上記リモートＬＣに連結し、上記プロセッサはさらに、
上記装置と関連付けられた上記ｖＮＩＣのうちの第２のｖＮＩＣにアクセスするリクエストを含むオペレーティングシステム（ＯＳ）カーネルＩＯコールを受信し、
上記リモートＬＣのうちの、上記第２のｖＮＩＣに対応する第２のリモートＬＣを決定し、
上記第２のリモートＬＣにアクセスするように上記リクエストを向ける
よう構成される、項目１６に記載の装置。
【図１】
0006760579.tif 000002
【図２】
0006760579.tif 000003
【図３】
0006760579.tif 000004
【図４】
0006760579.tif 000005
【図５】
0006760579.tif 000006
【図６】
0006760579.tif 000007
【図７】
0006760579.tif 000008
【図８】
0006760579.tif 000009
【図９】
0006760579.tif 000010