JP4755390B2 - メモリを介してデータ処理システムの間でデータのフローを制御する方法および装置 - Google Patents

Description

本発明は、ホスト・コンピュータ・システムとデータ通信ネットワークの間でデータを通信するホスト・コンピュータ・システムおよびデータ通信インターフェースなどの第１および第２のデータ処理システムの間でメモリを介してデータのフローを制御する方法および装置に関する。

従来のデータ処理ネットワークには、イーサネット（Ｒ）・アーキテクチャなどの中間のネットワーク・アーキテクチャによってすべてが相互接続される複数のホスト・コンピュータ・システムおよび複数の付加デバイスが含まれる。ネットワーク・アーキテクチャには、通常は、１つまたは複数のデータ通信交換機が含まれる。ホスト・コンピュータ・システムおよび付加デバイスのそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システムには、通常は、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャによって相互接続される、複数の中央処理装置およびデータ・ストレージ・メモリ・デバイスが含まれる。ネットワーク・アダプタも、ホスト・コンピュータ・システムとデータ処理ネットワーク内の他のノードの間でネットワーク・アーキテクチャを介してデータを通信するためにバス・アーキテクチャに接続される。

ホスト・コンピュータ・システムとネットワーク・アーキテクチャの間のデータおよび制御情報の転送をできる限り効率的に促進することが望ましい。

本発明によれば、メモリを介して第１および第２のデータ処理システムの間でデータのフローを制御する装置であって、メモリ内の位置と第２データ処理システムの間で通信されるデータ・パケットを定義するフレーム記述子およびメモリ内の位置を識別するポインタ記述子を含む複数の記述子を生成する記述子ロジックと、第１および第２のデータ処理システムによるアクセスのために記述子ロジックによって生成された記述子を保管する記述子テーブルとを含む装置が提供される。

記述子ロジックおよび記述子テーブルによって、ホスト・コンピュータ・システムとデータ通信ネットワークの間でデータを通信するホスト・コンピュータ・システムとデータ通信インターフェースなどの第１および第２のデータ処理システムの間のデータ・フロー制御の効率が改善される。

記述子テーブルは、ホスト・コンピュータ・システムのメモリに保管することができる。代替案では、記述子テーブルが、データ通信インターフェースのメモリに保管される。記述子ロジックは、記述子テーブル内の別の記述子へのリンクを含む分岐記述子も生成することができる。記述子テーブルに、その中の分岐記述子を介して一緒に順次リンクされた複数の記述子リストを含めることができる。代替案では、記述子テーブルに、循環記述子リストが含まれる。

本発明は、メモリを有するホスト処理システムと、ホスト・コンピュータ・システムとデータ通信ネットワークの間でデータを通信するデータ通信インターフェースと、ホスト・コンピュータ・システムのメモリとデータ通信インターフェースの間でのデータのフローを制御する、上に記載の装置とを含むデータ処理システムに拡張される。

もう１つの態様から本発明を見ると、メモリを介して第１および第２のデータ処理システムの間でデータのフローを制御する方法であって、記述子ロジックによって、メモリ内の位置と第２データ処理システムの間で通信されるデータ・パケットを定義するフレーム記述子およびメモリ内の位置を識別するポインタ記述子を含む複数の記述子を生成することと、第１および第２のデータ処理システムによるアクセスのために、記述子ロジックによって生成された記述子を記述子テーブルに保管することとを含む方法が提供される。

本発明の好ましい実施形態を、例のみとして、添付図面に関してこれから説明する。

まず図１を参照すると、本発明を実施するデータ処理ネットワークの例に、InfiniBandネットワーク・アーキテクチャ（InfiniBandはInfiniBandTrade Association社の商標である）などの中間ネットワーク・アーキテクチャ３０によって相互接続された、複数のホスト・コンピュータ・システム１０および複数の付加デバイス２０が含まれる。ネットワーク・アーキテクチャ３０には、通常は、複数のデータ通信交換機４０が含まれる。ホスト・コンピュータ・システム１０および付加デバイス２０のそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システム１０に、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャ７０によって相互接続される、複数の中央処理装置（ＣＰＵ）５０およびメモリ６０が含まれる。ネットワーク・アダプタ８０も、ホスト・コンピュータ・システム１０と、データ処理ネットワーク内の他のノードとの間で、ネットワーク・アーキテクチャ３０を介してデータを通信するために、バス・アーキテクチャに接続される。

図２を参照すると、本発明の特に好ましい実施形態では、ネットワーク・アダプタ８０に、ホスト・コンピュータ・システム１０のバス・アーキテクチャ７０への取外し可能な挿入のためのエッジ・コネクタなどのコネクタを有するプラグ可能オプション・カードが含まれる。オプション・カードは、コネクタ２７０を介してバス・アーキテクチャ７０に接続可能な特定用途向け集積回路（ＡＳＩＣ）またはインテグレーテッド・システム・オン・ア・チップ（Integrated System on a Chip、ＩＳＯＣ）１２０、ＩＳＯＣ１２０に接続される１つまたは複数の第３レベル・メモリ・モジュール２５０、および、ネットワーク・アーキテクチャ３０の媒体とＩＳＯＣ１２０の間でデータを通信するためにＩＳＯＣ１２０に接続されたインターポーザ２６０を担持する。インターポーザ２６０は、ネットワーク３０への物理的接続を提供する。本発明のいくつかの実施形態では、インターポーザ２６０を、単一のＡＳＩＣ内で実施することができる。しかし、本発明の他の実施形態では、インターポーザ２６０を、複数の構成要素によって実施することができる。たとえば、ネットワーク３０に光ネットワークが含まれる場合に、インターポーザ２６０に、別の光トランシーバを駆動するリタイマ（retimer）を含めることができる。メモリ２５０は、ＳＲＡＭ、ＳＤＲＡＭ、またはその組合せによって実施することができる。他の形態のメモリも、メモリ２５０の実施に使用することができる。ＩＳＯＣ１２０には、第１および第２のメモリが含まれる。アダプタ８０のメモリ・サブシステムを、すぐに説明する。以下の説明から明らかになるように、この配置は、データ処理ネットワークで動作する分散アプリケーションの改良された性能、改良されたシステム・スケーラビリティ、ある範囲の通信プロトコルとの互換性、およびホスト・コンピュータ・システムでの減らされた処理要件を提供する。具体的に言うと、この配置では、アダプタ８０とホスト・システム１０の間の異種通信プロトコルの共存が可能になる。そのようなプロトコルは、さまざまなアプリケーションをサービスし、同一のアダプタ８０を使用し、データ構造の事前定義の組を使用することができ、これによって、ホストとアダプタ８０の間のデータ転送が機能強化される。並列にオープンすることができるアプリケーション・チャネルの数は、アダプタ８０に割り振られるメモリ・リソースの量によって決定され、アダプタに組み込まれる処理能力に依存しない。下記から、複数の構成要素を単一の集積回路チップに統合するというＩＳＯＣ１２０の概念によって、有利なことに、製造コストが最小になり、再利用可能なシステム基本構成要素が提供される。しかし、本発明の他の実施形態で、ＩＳＯＣ１２０の要素を、別個の構成要素によって実施できることも諒解されたい。

以下の説明では、用語「フレーム」が、ホスト・コンピュータ・システム１０で稼動するソフトウェアとアダプタ８０の間で転送されるデータ単位またはメッセージを指す。各フレームに、フレーム・ヘッダおよびデータ・ペイロードが含まれる。データ・ペイロードに、ユーザ・データ、高水準プロトコル・ヘッダ・データ、肯定応答、フロー制御、またはこれらの任意の組合せを含めることができる。フレーム・ヘッダの内容を、詳細にすぐに説明する。アダプタ８０は、フレーム・ヘッダだけを処理する。アダプタ８０は、フレームを、ネットワーク・アーキテクチャ３０でより効率的に移送される、より小さいパケットに断片化することができる。しかし、そのような断片化では、一般に、データ・ペイロードは変換されない。

本発明の特に好ましい実施形態では、データが、ネットワーク・アーキテクチャ３０上で、以下でパケットと称するアトミックな単位で移送される。各パケットには、経路情報と、その後のハードウェア・ヘッダ・データおよびペイロード・データが含まれる。本発明の通常の例では、１０２４バイトまでのパケット・サイズが使用される。より大きいサイズのフレームは、１０２４バイト・パケットに断片化される。本発明の他の実施形態で、異なるパケット・サイズを使用できることを諒解されたい。

本発明の好ましい実施形態では、アダプタ８０と、ホスト・コンピュータ・システム１０で稼動する複数のアプリケーションとの間の通信が、論理通信ポート（Logical Communication Port）アーキテクチャ（ＬＣＰ）を介してもたらされる。アダプタ８０には、異なる内部データ構造へのアクセス待ち時間の最適化を可能にするメモリ階層が含まれる。このメモリ階層を、すぐに説明する。本発明の好ましい実施形態では、アダプタ８０が、ネットワーク・アーキテクチャ３０に宛てられたアウトバウンド（ＴＸ）データとホスト・コンピュータ・システム１０に宛てられたインバウンド（ＲＸ）データに別々のパスを提供する。各パスには、それ自体のデータ転送エンジン、ヘッダ処理ロジック、およびネットワーク・アーキテクチャ・インターフェースが含まれる。これらのパスも、詳細にすぐに説明する。

図３を参照すると、ＬＣＰアーキテクチャによって、ホスト・コンピュータ・システム１０で稼動するローカル・コンシューマとアダプタ８０の間のインターフェースのフレームワークが定義される。そのようなコンシューマの例に、アプリケーションとスレッドの両方が含まれる。コンピュータ・システム１０を、ユーザ・アプリケーション空間９０とカーネル空間１１０に副分割することができる。ＬＣＰアーキテクチャは、各コンシューマにネットワーク・アーキテクチャ３０への論理ポートを与える。このポートには、ユーザ空間９０から直接にアクセスすることができる。本発明の特に好ましい実施形態では、ハードウェア保護機構が、アクセス許可を解決する。ＬＣＰ登録が、データ・フレームの転送の前に、カーネル空間１１０によって実行される。ＬＣＰアーキテクチャでは、通信プロトコルを定義する必要がない。そうではなく、ＬＣＰアーキテクチャでは、データおよび制御情報を転送するための、アプリケーションとアダプタ８０の間のインターフェースが定義される。その代わりに、通信プロトコルの詳細を、アプリケーションおよびアダプタ８０で実行されるプログラム・コードによってセットすることができる。アダプタ８０で使用できるチャネルの数は、ＬＣＰ関連情報に使用可能なアダプタ・カード８０上のメモリの量だけによって制限される。各ＬＣＰポートを、特定の特徴の組を有するようにプログラムすることができる。特徴の組は、特定のプロトコルに従って、ホスト・コンピュータ・システム内のメモリ６０とアダプタ８０の間でのデータ転送を最もよくサポートするように選択される。さまざまな通信プロトコルを、各プロトコルで異なるＬＣＰポートを使用して、同時にサポートすることができる。

ＬＣＰアーキテクチャには、ＬＣＰクライアント１００、カーネル空間１１０に常駐するＬＣＰマネージャ１３０、および、アダプタ８０に常駐する１つまたは複数のＬＣＰコンテキスト１４０が含まれる。

各ＬＣＰクライアント１００は、ＬＣＰポートに接続された、単一方向アプリケーション・エンド・ポイントである。ＬＣＰクライアント１００を、ユーザ・アプリケーション空間９０またはカーネル１１０内に配置することができる。動作中に、各ＬＣＰクライアント１００は、メモリ６０から読み取られ、アダプタ８０によってＴＸ ＬＣＰチャネルを介して転送されるコマンドおよびデータを作るか、アダプタ８０によってメモリ６０へＲＸ ＬＣＰチャネルを介して転送されるデータを消費する。

ＬＣＰマネージャ１３０は、ＬＣＰチャネルの割振りおよび割振り解除と、チャネルごとのメモリ６０内の読取／書込区域の登録の要求をサービスする、信頼される構成要素である。ＬＣＰマネージャ１３０は、他の通信動作、アプリケーション、またはホスト・コンピュータ・システム１０のオペレーティング・システムを危険にさらさずに、ユーザ空間アプリケーションが、アダプタ８０のリソースを使用できるようにする。

各ＬＣＰコンテキスト１４０は、特定のＬＣＰクライアント１００をサービスするのにアダプタ８０が必要とする制御情報の組である。ＬＣＰコンテキスト１４０には、可能なコマンド、ポインタ構造、およびバッファ記述子定義など、チャネルの存在全体を通じて一定のＬＣＰチャネル属性を含めることができる。ＬＣＰコンテキスト１４０には、サービスを待っているデータの量、関連するＬＣＰチャネルにアクセスするための次のアドレスなど、ＬＣＰチャネルに関する特定のＬＣＰサービス情報も含めることができる。ＬＣＰコンテキスト１４０は、アダプタ８０に常駐するメモリに保管されて、アダプタ８０があるチャネルのサービスを停止し、別のチャネルのサービスを開始する時の高速ＬＣＰコンテキスト切替が可能になっている。

ＬＣＰポートの開始を要求するＬＣＰクライアント１００は、ＬＣＰマネージャ１３０に頼り、ＬＣＰチャネルの割振りを要求する。ＬＣＰチャネル属性は、この時に決定され、これによって、ＬＣＰポートの挙動およびＬＣＰクライアント１００がＬＣＰポートに関連して実行を許可される動作が規定される。ＬＣＰクライアント１００は、一意の保護された形でアダプタ８０にアクセスするのに使用されるアドレスを許可される。このアドレスを、ドアベル（Doorbell）アドレスと称する。

ＬＣＰマネージャ１３０は、アダプタによる仮想アドレスから物理アドレスへの変換を可能にし、ユーザ空間クライアントが他のプログラムを改竄せずにこれらのホスト・メモリ区域にアクセスできるようにするために、ホスト・メモリ６０の区域を登録する責任も負う。

新しいバッファの登録および前のバッファの登録解除は、実行時中に各ＬＣＰクライアント１００が要求することができる。そのような変更は、ＬＣＰクライアント１００、ＬＣＰマネージャ１３０、およびアダプタ８０の間の情報交換のシーケンスを必要とする。

各ＬＣＰクライアント１００およびポートは、ＬＣＰポートによってコマンド実行のために送られる保留中の要求をサービスするためにアダプタ８０が必要とするすべての情報を提供するＬＣＰコンテキスト１４０に関連する。

ＬＣＰクライアント１００とアダプタ８０の間のメモリ転送を開始し、フレームの送信を開始するために、ＬＣＰクライアント１００は、特定の動作に関する情報を保持する記述子を用意する。ＬＣＰクライアント１００は、アダプタ８０にマッピングされたドアベル・アドレスへの入出力書込を実行する。ドアベル・アドレスに書き込むことによって、アダプタ８０のＬＣＰコンテキスト１４０が更新され、新しい要求が実行のために追加される。

アダプタ８０は、保留中の要求を有するさまざまな送信ＬＣＰポートの間で調停し、次にサービスされる送信ＬＣＰポートを選択する。

データの受信時に、受信されたパケットのフレームおよびＬＣＰが、識別される。記述子を生成して、受信されたＬＣＰに必要な動作を定義する。アダプタ８０のＬＣＰエンジンによるこれらの記述子の実行によって、着信データが、ホスト・コンピュータ・システム１０のメモリ６０内でＬＣＰチャネルに割り振られた適当なデータ・バッファに保管される。

サービスされるＬＣＰチャネルごとに、アダプタ８０は、関連するＬＣＰコンテキスト情報をロードし、この情報を使用して、データ転送の所望の組を実行する。その後、アダプタ８０は、次に選択されるＬＣＰコンテキスト１４０の処理に継続する。

図４を参照すると、前に述べたように、ＩＳＯＣ１２０に、第１メモリ空間２２０および２３０と第２メモリ空間２４０が含まれ、アダプタ８０に、さらに、第３レベル・メモリ２５０が含まれる。第１、第２、および第３のメモリは、アダプタ８０のメモリ・サブシステム２１０のために間隔を空ける。本発明の好ましい実施形態では、ＩＳＯＣ１２０に、データ送信動作専用のＴＸプロセッサ（ＴＸ ＭＰＣ）１５０と、データ受信動作専用のＲＸプロセッサ（ＲＸ ＭＰＣ）１６０が含まれる。本発明の特に好ましい実施形態では、プロセッサ１５０および１６０が、ＩＢＭ ＰｏｗｅｒＰＣ ４０５ ＲＩＳＣマイクロプロセッサなどの縮小命令セット・コンピューティング（ＲＩＳＣ）マイクロプロセッサによって実施される。メモリ・サブシステム２１０内で、ＩＳＯＣ１２０に、第１および第２のメモリ空間の他に、ＴＸプロセッサ１５０に関連するデータ・キャッシュ１８０および命令キャッシュ１７０が、ＲＸプロセッサ１６０に関連する第２データ・キャッシュ１９０および第２命令キャッシュ２００と共に含まれる。３つのレベルの間の相違は、メモリのサイズおよび関連するアクセス時間である。すぐに明らかになるように、メモリ・サブシステム２１０は、ＴＸプロセッサ１５０およびＲＸプロセッサ１６０の両方による命令およびデータへの便利なアクセスと、スケーラビリティと、削減された製造コストのためのＴＸプロセッサ１５０およびＲＸプロセッサ１６０の間のリソースの共用とを容易にする。

第１レベル・メモリ空間（Ｍ１）２２０および２３０に、ＴＸ−Ｍ１メモリ空間２２０およびＲＸ−Ｍ１メモリ空間２３０が含まれる。ＴＸ−Ｍ１メモリ２２０は、ＴＸプロセッサ１５０によってのみアクセスでき、ＲＸ−Ｍ１メモリ２３０は、ＲＸプロセッサ１６０によってのみアクセスできる。動作中に、第１レベル・メモリ空間２２０および２３０は、一時データ構造、ヘッダ・テンプレート、スタックなどを保持するのに使用される。第１レベル・メモリ空間２２０および２３０の両方が、０待ち状態に反応する。第１レベル・メモリ空間２２０および２３０のそれぞれは、プロセッサ１５０および１６０の対応する１つのデータ・インターフェースだけに接続され、命令インターフェースには接続されない。この配置によって、キャッシュ可能およびキャッシュ不能の両方の第１レベル・メモリ区域を使用可能にすることができるのと同時に、第１レベル・メモリ空間２２０および２３０内のデータへの効率的なアクセスを維持できるようになる。

第２レベル・メモリ空間（Ｍ２）２４０は、プロセッサ１５０および１６０の両方、アダプタ８０の他の構成要素、およびホスト・コンピュータ・システム１０から使用可能な共用メモリである。第２レベル・メモリ空間２４０へのアクセスは、第１レベル・メモリ区域２２０および２３０へのアクセスより低速である。というのは、第２レベル・メモリ空間２４０が、共用される内部バスを介してより多くのエージェントによって使用されるからである。第３レベル・メモリ空間２５０も、共用リソースである。本発明の特に好ましい実施形態では、アダプタ８０に、その上で第１レベル・メモリ空間２２０および２３０と第２レベル・メモリ空間２４０の両方がプロセッサ１５０および１６０と同一のＡＳＩＣに集積される、コンピュータ周辺回路カードが含まれる。共用メモリ空間２４０および２５０は、一般に、高速で頻繁なアクセス・サイクルを必要としないデータ・タイプに使用される。そのようなデータ・タイプには、ＬＣＰコンテキスト１４０および仮想アドレス変換テーブルが含まれる。この共用メモリ空間２４０および２５０は、プロセッサ１５０および１６０の命令インターフェースおよびデータ・インターフェースの両方からアクセス可能である。

アダプタ８０は、送信データ・フローと受信データ・フローを別々に処理する。送信パスおよび受信パスのプロセッサ１５０および１６０は、タスク間の切替のオーバーヘッドを防止し、あるパス内の一時的な処理負荷を他のパスから分離し、着信データ・ストリームおよび発信データ・ストリームの処理に２つの組込みプロセッサを使用することを促進する。図５を参照すると、ＩＳＯＣ１２０に、送信パス・ロジック２８０および受信パス・ロジック２９０と、共用ロジック３００が含まれる。送信パス・ロジック２８０には、各ＬＣＰチャネルの詳細をデコードし、ＬＣＰ関連コマンドを実行のために取り出すＬＣＰ ＴＸエンジン３１０と、アダプタ８０へのフレームの転送を制御するＴＸロジック３２０と、ＴＸフレームおよびパケット処理の管理用の前述のＴＸプロセッサ１５０と、命令および一時データ構造を保持する前述の第１レベルＴＸメモリ２２０と、リンク・ロジック３３０と、フレームのデータ・パケットへの断片化の経路指定処理などのデータ・フロー処理およびパケット処理を管理する際にＴＸプロセッサ１５０を支援するロジックとが含まれる。ＴＸプロセッサ１５０は、プロセッサが例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式に基づいてタスクを直列に処理する。第１レベルＴＸメモリ２２０は、プロセッサ１５０によって、ＴＸロジック３２０との通信に使用される。受信パス・ロジック２９０には、リンク・ロジック３４０と、着信パケットのヘッダ処理およびそのようなパケットのフレームへの変換または組立の際に前述のＲＸプロセッサ１６０を支援するハードウェアと、ＲＸフレームおよびパケット処理用の前述のＲＸプロセッサ１６０と、命令を保持する前述の第１レベルＲＸメモリ２３０と、ネットワーク・アーキテクチャ３０からのフレームの転送を制御するＲＸロジック３５０と、各ＬＣＰチャネルの詳細をデコードし、関連するＬＣＰデータ構造内の着信データをホスト・コンピュータ・システムのメモリ６０に保管し、ＬＣＰクライアント１００によってアダプタ８０による使用のために供給される時に、空フレーム・バッファへのポインタを受け入れ、登録する、ＬＣＰ ＲＸエンジン３６０とが含まれる。ＲＸプロセッサ１６０は、ＲＸプロセッサ１６０が例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式を使用してタスクを直列に処理する。第１レベルＲＸメモリ２３０は、ＲＸプロセッサ１６０によって、ＲＸロジック３５０との通信に使用される。

前に述べたように、ＩＳＯＣ手法では、アダプタ８０および、回路ボードおよび他のサポート・モジュールなどのアダプタの他の構成要素に関連する製造コストの削減が可能になる。ＩＳＯＣ手法では、アダプタ８０の単純さも高まり、これによって信頼性が高まる。ＩＳＯＣ１２０の要素の間の接続の数は、効果的に無制限である。したがって、複数の幅広い相互接続パスを実施することができる。ホスト・コンピュータ・システム１０でのデータ処理オーバーヘッドを減らすために、ホスト・メモリ６０との間のデータ転送動作は、大部分がＩＳＯＣ１２０によって実行される。ＩＳＯＣ１２０は、着信パケットおよび発信パケットのヘッダの処理も実行する。送信中に、ＩＳＯＣ１２０は、ヘッダを作り、ネットワーク・アーキテクチャ３０に経路指定する。受信中に、アダプタ８０は、システムのメモリ内でのヘッダの位置を判定するためにヘッダを処理する。レベル１メモリ２２０および２３０は、０待ち状態メモリであり、スタック、テンプレート、テーブル、および一時保管場所などのプロセッサ・データ空間を提供する。本発明の特に好ましい実施形態では、送信パス・ロジック２８０、受信パス・ロジック２９０、および共用ロジック３００が、コアと称する、より小さい論理要素から作られる。用語コアが使用されるのは、これらの要素が、それらを異なる応用例に使用できるようにする独立型の特性を有する個々のロジックとして設計されるからである。

前に示したように、送信パス・ロジック２８０は、送信フレームまたは発信フレームを処理する責任を負う。フレーム送信は、バス・アーキテクチャ７０を介して、ホスト・コンピュータ・システム１０のＣＰＵ５０などのＣＰＵによって開始される。ＩＳＯＣ１２０には、バス・アーキテクチャ７０と通信するバス・インターフェース・ロジック３７０が含まれる。ＩＳＯＣ１２０には、バス・インターフェース・ロジック３７０をＩＳＯＣ１２０のプロセッサ・ローカル・バス（ＰＬＢ）３９０に接続するバス・ブリッジング・ロジック３８０も含まれる。ＬＣＰ ＴＸエンジン３１０は、コマンドおよびフレームをホスト・メモリ６０から取り出す。ＴＸプロセッサ１５０は、各フレームのヘッダを処理して、ネットワーク・アーキテクチャ３０上でパケットとして送信するのに適するフォーマットにする。ＴＸロジック３２０は、フレーム・データを修正なしで転送する。リンク・ロジック３３０は、送信される各パケットを処理して、ネットワーク・アーキテクチャ３０での送信用の最終的な形にする。リンク・ロジック３３０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。

前に示したように、受信パス・ロジック２９０は、着信パケットを処理する責任を負う。まず、ネットワーク・アーキテクチャ３０から受信されたパケットが、リンク・ロジック３４０によって処理される。リンク・ロジック３４０は、ヘッダおよびペイロードのフォーマットのパケットを再作成する。パケット・フォーマットおよびホスト・メモリ６０内での宛先を判定するために、ヘッダが、ＲＸプロセッサ１６０によって処理される。リンク・ロジック３４０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。ＲＸ ＬＣＰエンジンは、バス・アーキテクチャ３７０を介してデータをホスト・メモリ６０に転送する責任を負う。

送信パス・ロジック２８０には、ＴＸ ＬＣＰエンジン３１０とＴＸプロセッサ１５０の間のＨｅａｄｅｒＩｎ先入れ先出しメモリ（ＦＩＦＯ）４００が含まれる。受信パス・ロジックには、ＲＸプロセッサ１６０とＲＸ ＬＣＰエンジン３６０の間のＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が含まれる。追加のＦＩＦＯおよびキューを、ＴＸロジック３２０内およびＲＸロジック３５０内に設けることができる。これらのＦＩＦＯおよびキューを、すぐに説明する。

共用ロジック３００には、送信パス・ロジック２８０および受信パス・ロジック２９０によって共用されるすべての要素が含まれる。この要素には、前述のバス・インターフェース・ロジック３７０、バス・ブリッジング・ロジック３８０、ＰＬＢ３９０、第２レベル・メモリ２４０、およびリモート第３レベル・メモリ２５０へのアクセスを提供するコントローラ４２０が含まれる。バス・インターフェース・ロジック３７０は、バス・アーキテクチャ７０上でマスタおよびスレーブの両方として動作する。スレーブとして、バス・インターフェース・ロジックは、ＣＰＵ５０が、第２レベル・メモリ２４０に、コントローラ４２０を介して第３レベル・メモリ２５０に、および、ＩＳＯＣ１２０の構成レジスタおよび状況レジスタにもアクセスできるようにする。そのようなレジスタは、一般に、ＣＰＵ５０、ＴＸプロセッサ１５０、およびＲＸプロセッサ１６０によってアクセスすることができる。マスタとして、バス・インターフェース・ロジックは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０が、ホスト・コンピュータ・システム１０のメモリ６０にアクセスできるようにする。図５では、「Ｍ」がマスタ接続、「Ｓ」がスレーブ接続を示す。

図６を参照すると、ＩＳＯＣ１２０を通るパケットフローは、一般に対称である。言い換えると、フローの全般的な構造は、送信方向と受信方向の両方で類似する。ＩＳＯＣ１２０は、第１インターフェース・ロジック４４０と、第１制御ロジック４６０と、プロセッサ・ロジック４８０と、第２制御ロジック４７０と、第２インターフェース・ロジック４５０とを含むとみなすことができる。パケットは、下記の形で処理される。

Ａ．送信方向では、情報が、バス・アーキテクチャ７０から第１インターフェース・ロジックを介してＩＳＯＣ１２０に持ってこられる。受信方向では、情報が、ネットワーク・アーキテクチャ３０から第２インターフェース・ロジック４５０を介してＩＳＯＣ１２０に持ってこられる。

Ｂ．送信方向では、第１インターフェース・ロジック４４０を介してＩＳＯＣ１２０に持ってこられた情報が、第１制御ロジック４６０によって処理される。受信方向では、第２インターフェース・ロジック４５０を介してＩＳＯＣに持ってこられた情報が、第２制御ロジック４７０によって処理される。

Ｃ．送信方向では、フレーム・ヘッダが、第１制御ロジック４６０で発信フレームについて抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第２制御ロジック４７０用の命令を生成する。発信フレームのペイロードは、第２制御ロジック４７０に渡される。受信方向では、フレーム・ヘッダが、第２制御ロジック４７０で着信フレームから抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第１制御ロジック４６０用の命令を生成する。着信フレームのペイロードは、第１制御ロジック４６０に渡される。両方の方向で、プロセッサ４８０は、ペイロード・データを直接には処理しない。

Ｄ．送信方向では、第２制御ロジック４７０が、プロセッサ・ロジック４８０から受け取った命令に従って発信ペイロード・データをパッケージする。受信方向では、第１制御ロジック４６０が、プロセッサ・ロジック４８０から受け取った命令に従って着信ペイロード・データをパッケージする。

Ｅ．送信方向では、情報が、第２インターフェース・ロジック４５０からその宛先へネットワーク・アーキテクチャ３０を介して移動される。受信方向では、情報が、第１インターフェース・ロジックからその宛先へバス・アーキテクチャ７０を介して移動される。

ホスト・コンピュータ・システム１０で動作するソフトウェアへのインターフェースを、４３０に示す。同様に、プロセッサの入力および出力で動作するマイクロコードへのインターフェースを、４９０および５００に示す。

図７を参照して、以下は、ＩＳＯＣ１２０を通る送信データ・フレームのフローの１例のより詳細な説明である。ＩＳＯＣ１２０は、ＩＳＯＣ１２０内の情報のさまざまなフォーマットに基づいて、ＬＣＰコンテキスト・ドメイン５１０、フレーム・ドメイン５２０、およびネットワーク・ドメイン５３０に分割することができる。ＴＸ ＬＣＰエンジン３１０には、ＬＣＰ要求ＦＩＦＯ５５０、直接メモリ・アクセス（ＤＭＡ）ロジック５６０、フレーム・ロジック５８０、および前述のＬＣＰコンテキスト・ロジック１４０が含まれる。ＬＣＰ要求ＦＩＦＯ５５０、ＤＭＡロジック５６０、およびＬＣＰ ＴＸコンテキスト・ロジック５９０は、ＬＣＰコンテキスト・ドメイン５１０に常駐する。フレーム・ロジック５８０は、フレーム・ドメイン５２０に常駐する。ＴＸロジック３２０、第１レベルＴＸメモリ空間２２０、およびＴＸプロセッサ１５０は、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の境界にまたがる。ＴＸリンク・ロジック３３０は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＩｎ ＦＩＦＯ４００が、第１レベルＴＸメモリ空間２２０に一体化される。一般に、ホスト・コンピュータ・システム１０で実行されるアプリケーションが、フレームを作成する。フレームは、その後、アダプタ８０のＴＸ ＬＣＰチャネルを使用して送信される。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＬＣＰサービス要求を追加するために、ＬＣＰクライアント１００が、アダプタ８０に、１つまたは複数の追加の送信フレームが実行の準備ができていることを知らせる。これは、ドアベルに制御ワードを書き込むことによって実行される。ドアベルのアドレスは、ＬＣＰポートに一意に関連し、他のプロセスによるアクセスから保護されるアドレスを使用して、書込動作が、バス・アーキテクチャ７０上での物理書込サイクルに変換される形で割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰクライアント１００の前の要求の項目を増分することによって、新しい要求をログに記録する。これは、関係するＬＣＰコンテキスト１４０の一部である。アダプタ８０のメモリ・サブシステム２１０内に保持される調停リストも、更新される。単純な例では、調停で、保留中の要求を有するすべての送信ＬＣＰチャネルの間で前述のＦＩＦＯ方式５５０が使用される。あるＬＣＰチャネルがサービスされている間に、次のＬＣＰチャネルが選択される。サービス・サイクルは、対応するＬＣＰコンテキストがＴＸ ＬＣＰエンジン３１０にロードされる時に開始される。その後、ＬＣＰコンテキスト１４０にアクセスして、ＬＣＰチャネルをサービスするアトミック・オペレーションを導出し、そのような動作のパラメータを判定する。たとえば、そのようなアトミック・オペレーションは、ＬＣＰコンテキスト１４０に記録されたＬＣＰチャネル属性に基づくものとすることができる。完全なサービス・サイクルに、通常は、ＬＣＰクライアント１００によって作成される複数のアトミックな記述子をフェッチし、実行するためにアダプタ８０によって実行されるアクティビティの組が含まれる。ＴＸ ＬＣＰチャネルの場合に、サービス・サイクルに、一般に、ホスト・メモリ６０からアダプタ８０のメモリ・サブシステム２１０に複数のフレームを読み取ることが含まれる。最後に、修正を必要とするすべてのＬＣＰコンテキスト情報（言い換えると、ＬＣＰサービス情報）が、アダプタ８０のメモリ・サブシステム２１０内で更新される。一般に、アダプタ８０によってＬＣＰサービス・サイクル内で最初に実行される動作は、次に処理される記述子を取り出すことである。

ＩＳＯＣ１２０による送信フレームの処理には、通常は下記のステップが含まれる。

Ａ．後続ＬＣＰポート・フレーム記述子の取出
次に取り出される記述子のアドレスは、ＬＣＰチャネルのコンテキスト１４０の一部として保管される。アダプタ８０は、ホスト・メモリ６０から記述子を読み取り、ＬＣＰチャネル属性に基づいてその記述子をデコードする。記述子によって、新しいフレーム・ヘッダのサイズ、データ・ペイロードのサイズ、およびこれらの項目の位置が定義される。

Ｂ．仮想アドレスの物理アドレスへの変換
データ・バッファが、アプリケーション内で仮想メモリ・アドレスによって参照される場合に、そのアドレスは、アドレス変換という追加処理を受けなければならない。この場合に、アプリケーションによって使用される仮想アドレスが、アダプタ８０がホスト・メモリ６０にアクセスする間にアダプタ８０によって使用可能な物理アドレスに変換される。これは、ページ境界を超えることを監視し、ＬＣＰマネージャ１３０によってアダプタ８０のメモリ・サブシステム２１０に書き込まれる物理ページ位置情報を使用することによって行われる。仮想アドレスから物理アドレスへの変換処理は、記述子テーブルが、信頼されないＬＣＰクライアント１００によって作成される場合のセキュリティ手段としても働く。これによって、ホスト・メモリ６０の無関係な区域への許可されないアクセスが防止される。

Ｃ．フレーム・ヘッダの読取
物理アドレッシングを使用して、ＴＸフレームのヘッダおよびペイロード・データが、ホスト・メモリ６０内のバッファから読み取られる。その後、ヘッダが、ＴＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ４００に保管される。ヘッダ取出が完了した時に、アダプタ８０は、ヘッダの処理をＴＸプロセッサ１５０によって開始できることを示す内部フラグをセットする。

Ｄ．フレーム・データの読取
ペイロード・データが、ホスト・メモリ６０から読み取られ、アダプタ８０によってデータＦＩＦＯ５７０に保管される。データＦＩＦＯ５７０は、図７では、ＴＸロジック３２０に常駐するものとして図示されている。しかし、データＦＩＦＯ５７０を、第１レベルＴＸメモリ空間２２０に一体化することもできる。データ読取トランザクションは、送信されるデータのすべてがアダプタ８０のメモリ・サブシステム２１０に保管されるまで継続する。読取動作の完了に続いて、状況指示が、ＬＣＰクライアント１００に返される。ヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００に読み取られてすぐに、ヘッダの処理を開始できることに留意されたい。データ全体が読み取られるのを待つ必要はない。

Ｅ．フレーム・ヘッダの処理
ヘッダ処理は、ＴＸプロセッサ１５０によって実行される。ヘッダ処理は、プロトコル依存であり、ＬＣＰアーキテクチャの外部のプロトコル情報が用いられる。ＴＸプロセッサ１５０は、ＴＸプロトコル・ヘッダ・マイクロコードを実行し、プロトコルおよび経路指定初期化シーケンス中にアダプタ８０のメモリ・サブシステム２１０に既に保管された経路指定テーブルおよび他の関連情報にアクセスする。ＴＸプロセッサ１５０は、新しいヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００内で待っていることの指示を受け取る時に、ヘッダ処理を開始する。ヘッダ処理では、ネットワーク・アーキテクチャ３０を介してパケットを送信するのに使用されるフォーマットであり、経路指定情報を含む、１つまたは複数のパケット・ヘッダが作られる。ペイロード・サイズが、ネットワーク・アーキテクチャ３０によって許容される最大パケット・サイズより大きい場合には、元のペイロード・データの連続するデータ・セグメントに関してそれぞれが使用される複数のパケット・ヘッダを生成して、ネットワーク・アーキテクチャ３０を介する通信用のパケットを形成することによって、ペイロードを断片化する。

Ｆ．送信用のパケット・ヘッダのキューイング
パケットのヘッダ・ワード数およびデータ・ワード数を定義するコマンドおよびパケット・ヘッダ自体が、ＴＸプロセッサ１５０によって、第１レベル・メモリ空間２２０内のＴＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０に書き込まれる。

Ｇ．送信用のパケット・ヘッダおよびパケット・データのマージ
ネットワーク・アーキテクチャ３０でのパケットの送信は、コマンドがＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０内で準備ができており、データＦＩＦＯ５７０に、関連するパケットの送信を完了するのに十分なデータが含まれる時に、必ずトリガされる。巡回冗長検査（ＣＲＣ）を、各パケットのヘッダおよびデータに追加することができる。各完全なパケットが、ＴＸリンク・ロジック３３０を介してネットワーク・アーキテクチャ３０に転送される。

各フレームの送信処理は、すべてのフレーム・データが、１つまたは複数のパケットによってネットワーク・アーキテクチャ３０で送信された時に完了する。アダプタ８０によって処理されるフレームごとに、第２のＬＣＰクライアント１００を介してアプリケーションに状況を返すことができる。この状況は、ホスト・メモリ６０からアダプタ８０へのフレーム・データ転送の完了、フレーム送信自体の完了、または他のレベルの送信状況とすることができる。

どの瞬間でも、アダプタ８０は、次にサービスされるＬＣＰの選択、ＬＣＰチャネルＡのサービスの開始、ＬＣＰチャネルＢの最後のフレームのデータのＤＭＡ取出の実行、ＬＣＰチャネルＣのフレーム・ヘッダの処理および断片化、ＬＣＰチャネルＤから発するパケットの送信のうちの一部またはすべてを平行に実行することができる。

図８を参照して、以下は、例のみとして、ＲＸ ＬＣＰポートを使用するアプリケーションによるデータ・フレーム受信の説明である。ＩＳＯＣ１２０の動作は、ＬＣＰによってサポートされるプロトコルのタイプに応じて変更することができる。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＲＸ ＬＣＰエンジン３６０には、ＬＣＰ割振りロジック６２０、ＬＣＰコンテキスト・ロジック６１０、およびＤＭＡロジック６３０が含まれ、これらのすべてが、ＬＣＰコンテキスト・ドメイン５１０に常駐する。ＲＸプロセッサ１６０、第１レベルＲＸメモリ空間２３０、およびＲＸロジック３５０のすべてが、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の間の境界にまたがる。ＲＸリンク・ロジック３４０およびパケット援助ロジック６００は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が、第１レベルＲＸメモリ空間２３０内に配置される。ＩＳＯＣ１２０によってネットワーク・アーキテクチャ３０から受信されたフレームは、ホスト・メモリ６０内のＬＣＰクライアント・バッファに書き込まれる。メモリ・バッファの可用性は、ＬＣＰ ＲＸクライアント１００によって判定され、着信データ・フレームの挿入のためにアダプタ８０に示される。ＬＣＰクライアント１００は、送信される準備ができた新しいフレームについて送信パス・ロジック２８０が知らされる前に述べた形に似て、ＩＳＯＣ１２０の受信ドアベルに書き込むことによってバッファを提供する。ドアベル・レジスタ・アドレスは、書込動作がバス・アーキテクチャ７０への物理書込サイクルに変換されるように割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰ ＲＸクライアント１００の使用可能なワード項目の数を増分することによって、空のメモリ区域の新たな提供をログに記録する。使用可能なワード・カウントは、関係するＬＣＰコンテキスト１４０の一部である。アプリケーションは、バッファ内の受信したフレームの処理を完了する時に、必ずドアベルに書き込む。この書込サイクルによって、新たに使用可能なメモリ空間のワード数が示される。ＬＣＰコンテキスト内のカウントが、その量だけ増分される。ネットワーク・アーキテクチャ３０から受信されたパケットは、アダプタ８０によってホスト・メモリ６０内の連続する空間に組み立てられる、より大きいフレームの一部である場合がある。ＩＳＯＣ１２０による受信されたフレームの処理には、一般に、下記のステップが含まれる。

Ａ．パケット・ヘッダとデータの分離
ＲＸリンク・ロジック３４０は、ネットワーク・アーキテクチャ３０からの情報をパケットのストリームに変換する。受信されたパケットのそれぞれが、ＲＸリンク・ロジック３４０によって処理されて、パケット・ヘッダがペイロード・データから分離される。ヘッダは、第１レベルＲＸメモリ空間２３０内のＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０にプッシュされる。ペイロードは、ＲＸロジック３５０内のＲＸデータＦＩＦＯ６５０にプッシュされる。ＲＸデータＦＩＦＯ６５０は、第１レベルＲＸメモリ空間２３０内で実施することもできる。

Ｂ．パケット・ヘッダのデコードおよびＬＣＰフレーム・ヘッダの生成。
パケット・ヘッダをデコードして、パケットが属するフレームのＩＤ、ペイロードのサイズ、およびフレーム・データのサイズを示すフィールドを提供する。パケット・ヘッダが、ＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０に関するリーダーになるならば、指示が、ＲＸプロセッサ１６０に送られる。ＲＸプロセッサは、パケット・ヘッダ情報を処理し、パケット・データの転送に必要な情報を含むＬＣＰ関連コマンドを生成する。そのような情報には、パケットのアドレスおよび長さが含まれる。ヘッダ処理の終りに、記述子または記述子の組が、ＬＣＰ ＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０に書き込まれ、指示がトリガされる。

Ｃ．ＲＸ ＬＣＰコンテキスト内のデータの転送
記述子が、ＲＸ ＬＣＰエンジン３６０によってＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０から取り出され、デコードされる。記述子には、ＬＣＰ番号、パケット・アドレス、パケット・データ長、および、アダプタ８０のメモリ・サブシステム２１０に転送されるデータのソース・アドレスが含まれる。ＲＸ ＬＣＰエンジン３４０は、ＬＣＰコンテキスト情報を使用して、ホスト・メモリ６０内の書き込まれるターゲット物理アドレス（または、ページにまたがる場合には複数のアドレス）を作成し、ＤＭＡ転送を開始して、データを書き込む。

Ｄ．ＩＳＯＣ ＤＭＡトランザクション
ＩＳＯＣ１２０は、適当なバス・コマンドを選択し、可能な最長のバーストを実行することによって、バス・アーキテクチャ７０でのトランザクションの最適化を目指す。

どの瞬間でも、アダプタ８０は、ＬＣＰチャネルＸのバッファ割振りの処理、ＬＣＰチャネルＡのインバウンド・データ書込サービスの開始、ＬＣＰチャネルＢのデータのＤＭＡストアの実行、ＬＣＰチャネルＣ宛のパケットのフレーム組立の処理、およびＬＣＰチャネルＤのパケットの受信の一部またはすべてを並列に実行することができる。

ＲＸプロセッサ１６０およびＴＸプロセッサ１５０でのフレーム処理オーバーヘッドを最小にするために、パケット援助ロジック６００に、フレーム断片化ロジック、ＣＲＣおよびチェックサム計算ロジック、およびマルチキャスト処理ロジックが含まれる。

ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０の両方とホスト１０の間のデータ・フローを、これから詳細に説明する。ＴＸ ＬＣＰポートおよびＲＸ ＬＣＰポートの両方で、データ転送用のメモリ・バッファと、そのようなメモリ・バッファをポイントする記述子構造が使用される。記述子構造は、データ・プロバイダとデータ・コンシューマの間でデータ・バッファを管理し、データ・プロバイダによって使用される空のメモリ・バッファを返すのに使用される。記述子は、物理アドレスまたは仮想アドレスのいずれかに基づいてメモリ・バッファをポイントする。

ＴＸ ＬＣＰチャネルは、ホスト・メモリ６０からＩＳＯＣ１２０のバッファへのデータ転送の責任を負う。ロジックの他の層は、ＩＳＯＣ１２０のバッファからネットワーク３０にデータを転送する責任を負う。ＲＸ ＬＣＰチャネルは、ネットワーク３０から受信されたデータのホスト・メモリ６０への転送の責任を負う。

ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、比較的多数のＬＣＰチャネルを扱うことができる。各ＬＣＰチャネルは、それに固有のすべての情報を含むパラメータの組を有する。この情報には、チャネルの構成、現在の状態、および状況が含まれる。あるチャネルに関連するＬＣＰコンテキスト１４０が、チャネルの初期化中にＬＣＰマネージャ１３０によってセットされる。チャネル動作中に、ＬＣＰコンテキスト１４０の内容が、ＩＳＯＣ１２０のみによって更新される。ＬＣＰコンテキスト１４０は、アダプタ８０のメモリ・サブシステム２１０内のコンテキスト・テーブルに保管される。ＬＣＰチャネルのＬＣＰコンテキスト１４０へのアクセスは、ＬＣＰ番号に従って実行される。ＬＣＰのＲＸチャネルおよびＴＸチャネルでは、異なるＬＣＰコンテキスト構造が使用される。

データ・バッファは、ホスト１０のメモリ６０内のピン止めされた区域である。送信バッファには、送信用のデータが保持される。ＴＸ ＬＣＰエンジン３１０は、これらのバッファに置かれたデータをＩＳＯＣ１２０の内部バッファに移動する。ネットワーク・アーキテクチャ３０から受信される着信データは、ＲＸ ＬＣＰエンジン３６０によって、ホスト１０のメモリ６０内のバッファに移動される。バッファの所有権は、ホスト１０内のソフトウェアとＩＳＯＣ１２０の間で交番する。ＬＣＰ ＴＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ホスト１０のメモリ６０内で、送信されるデータと共にバッファを準備する。
Ｂ．ソフトウェアが、バッファ内のデータが送信の準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、バッファからデータを読み取る。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、読み取られ、新しいデータを転送するためにホスト１０のソフトウェアによって再利用することができるバッファを識別する。

ＬＣＰ ＲＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ＩＳＯＣ１２０が受信されたデータを書き込むことができるバッファを準備する。
Ｂ．ソフトウェアが、空きバッファがホストのメモリ６０内で準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、データをバッファに書き込む。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、受信されたデータが書き込まれ、ソフトウェアによって処理されることができるバッファを識別する。

ソフトウェアが、ＩＳＯＣ１２０によって使用されるバッファを準備する時に、バッファ情報が、ドアベル・レジスタを介して追跡される。ＩＳＯＣ１２０によって使用されるバッファに関する情報は、状況更新を使用してまたは完了キューを介して、ソフトウェアに返される。ＴＸ ＬＣＰチャネルについて、バッファに、ＴＸ ＬＣＰエンジン３１０によってＩＳＯＣ１２０に転送され、処理されて、ネットワーク３０での送信用の１つまたは複数のパケットになるデータおよびヘッダの情報が含まれる。ヘッダは、ＩＳＯＣ１２０のＴＸプロセッサ１５０によって、ネットワーク３０で送信されるパケットのヘッダを生成するのに使用される。ＲＸ ＬＣＰチャネルについて、空きバッファが、ホスト１０のソフトウェアによってアダプタ８０に割り当てられる。アダプタ８０は、受信されたパケットをバッファに書き込む。

記述子によって、ＩＳＯＣ１２０およびホスト１０のソフトウェアの両方に既知のデータ構造が定義されている。ソフトウェアは、記述子を使用して、ＩＳＯＣ１２０に制御情報を転送する。制御情報は、所望の機能に応じて、フレーム記述子、ポインタ記述子、または分岐記述子の形とすることができる。ソフトウェア内およびＩＳＯＣ１２０内の記述子ロジックは、行われる制御手段に従って記述子を生成し、修正する。そのような手段を、すぐに説明する。フレーム記述子には、パケットの記述子（たとえば、データ長、ヘッダ長など）が含まれる。ポインタ記述子には、データ位置の記述子が含まれる。分岐記述子には、記述子位置の記述（たとえば、記述子のリンク・リスト）が含まれる。記述子内の情報は、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって実行されるデータ移動動作の、ホスト１０内のソフトウェアによる制御に使用される。ＴＸパケット・ヘッダを生成するためにフレームを処理するのに使用される情報は、フレームのヘッダに配置される。図９を参照すると、記述子を、単一のテーブル７００内に設けることができ、ＬＣＰコンテキスト１４０が、テーブル７００の先頭をポイントする。図１０を参照すると、記述子を、リンクされた記述子テーブル７２０から７４０の構造で配置することもできる。ＬＣＰチャネル初期化の後に、ＬＣＰコンテキスト１４０は、構造内の最初の記述子テーブル７２０の先頭をポイントする。分岐記述子７５０から７７０は、テーブル７２０から７４０のリンク・リストを生成するのに使用され、ここで、記述子テーブル７２０から７４０の終りの分岐記述子７５０から７７０は、別のテーブル７２０から７４０の始めをポイントする。図９に戻ると、分岐記述子は、循環バッファを生成するのにも使用することができ、ここで、テーブル７００の終りの分岐記述子７１０は、同一のテーブル７００の始めをポイントする。循環バッファは、受信パスで使用することもできる。この場合に、ＬＣＰコンテキスト１４０が、バッファの先頭をポイントするように開始される。バッファは、ＩＳＯＣ１２０がその終りに達した時に、ラップ・アラウンドされる。ホスト１０のソフトウェアは、ホスト１０のメモリ６０に（受信パスと送信パスの両方について）、またはアダプタ８０のメモリ２５０に（送信パスのみについて）記述子を書き込むことができる。アダプタ８０のメモリ・サブシステム２１０への記述子の書込には、ホスト１０のソフトウェアによる入出力動作が含まれ、アダプタ８０のメモリ・サブシステム２１０が占有される。ホスト１０のメモリ６０での記述子の書込は、アダプタ８０が、新しい記述子を読み取らなければならない時に、必ずホスト１０のメモリ６０にアクセスすることを必要とする。ソフトウェア記述子の位置は、ＬＣＰチャネルごとに独立に、ＬＣＰマネージャ１３０によって定義される。記述子の位置は、システム性能最適化に従って定義される。記述子は、キューの構成での柔軟性を提供する。

ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、記述子テーブル内の記述子にアクセスし、データ・バッファにアクセスするのに、アドレスを使用する。アドレスは、物理アドレスまたは仮想アドレスのいずれかとすることができる。用語物理アドレスは、ＩＳＯＣ１２０が、そのままでバス７０に駆動できるアドレスを指す。用語仮想アドレスは、物理アドレスではなく、ソフトウェアまたはマイクロコードによって使用されるアドレスを指す。仮想アドレスは、物理アドレスを生成するために、マッピングを受けなければならない。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるアドレスは、ＬＣＰチャネル・コンテキスト１４０内のポインタ、ホスト１０で稼動するソフトウェアによって準備される記述子内のポインタ、ＲＸプロセッサ１６０によって準備される記述子内のポインタ、およびＴＸプロセッサ１５０によって準備される記述子内のポインタ（完了メッセージを返すのに使用される）という異なるソースを有することができる。ポインタは、記述子またはデータ・バッファをポイントすることができる。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるすべてのアドレスを、任意選択として、バス７０上の物理アドレスとして使用される新しいアドレスにマッピングすることができる。アドレス・マッピングは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって行われる。ＩＳＯＣ１２０は、ローカル・メモリ２１０を使用して、変換テーブルを保持する。ＬＣＰマネージャ１３０は、メモリ登録中にアダプタ８０に変換テーブルを書き込む。アドレス・マッピングによって、バッファまたは記述子テーブルに仮想アドレスを使用できるようになる。仮想アドレッシングによって、物理的に複数の物理ページに配置される仮想バッファの管理が可能になる。アドレス・マッピングによって、ホスト１０が、ソフトウェアのための変換プロセッサを必要とせずに、仮想アドレスを使用するアプリケーションを直接に扱えるようになる。

図１１を参照すると、この図には、ホスト１０のソフトウェアから見えるバッファ８８０のイメージ８００が示されている。ホスト１０内のメモリ６０にアクセスするのに使用される、アドレスの物理マッピング８１０も示されている。仮想ポインタが、バッファ内の位置を８２０ポイントする。この例のバッファは、ホスト１０のメモリ６０内の少数の連続しないページ８４０から８７０を占める仮想バッファである。ＬＣＰエンジン３１０および３６０は、変換テーブル８３０を介してアドレスを変換することによってマッピングを実行する。変換テーブルは、仮想バッファ８８０からマッピングされる各物理バッファ８４０から８７０の先頭への物理アドレス・ポインタを保持する。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のメモリ６０内で記述子およびデータ・バッファをマッピングする時の柔軟性が可能になる。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のソフトウェアが物理アドレスへのアドレス変換を実行することを必要とせずに、仮想アドレスを使用するソフトウェア・バッファへの直接接続も可能になる。

アダプタ８０がホストのメモリ６０に書き込む各パケットは、それに関連する状況を有する。状況を用いると、アダプタ８０とホスト１０のソフトウェアの間の同期化が可能になる。状況は、パケットの異なる信頼性レベルを示すのに使用することができる。ＩＳＯＣ１２０は、下記の状況ライト・バックを提供する：送信ＤＭＡ完了は、ＴＸパケット内のデータがアダプタ８０に読み込まれたことを示し；信頼される送信は、ネットワーク３０でのデータ送信の完了を示すために返され；受信ＤＭＡ完了は、メモリ６０への受信データ転送の完了を示し；信頼される受信は、ネットワーク３０内の宛先ノードによる送信パケットの受信を示す。

ＴＸフレーム記述子には、２バイトの状況フィールドが含まれる。状況ライト・バックは、トランザクション状態が記述子にライト・バックされることを意味する。状況には、ホスト１０のソフトウェアがポーリングできる完了ビットが含まれる。ホスト１０のソフトウェアは、セットされた完了ビットを見つけた時に、そのフレーム記述子によって定義されるフレームに関連するバッファを再利用することができる。

完了キューは、ＲＸ ＬＣＰチャネルによって実施される。完了キューによって使用されるＬＣＰチャネルは、どのＲＸ ＬＣＰチャネルによっても実施することができる柔軟性および特性のすべてを有する。ＴＸプロセッサ１５０およびＲＸプロセッサ１６０は、状況ライト・バックを生成して、信頼される送信、信頼される受信、受信ＤＭＡ完了、または送信ＤＭＡ完了を示す。フレームに関連する異なる指示を、異なる場合に使用することができる。たとえば、信頼される送信の場合に、ＴＸプロセッサ１５０は、パケット送信の状況を示す内部レジスタを読み取る。信頼される受信の場合に、ＲＸプロセッサ１６０が、肯定応答を含む受信されたパケットとして完了指示を得る。受信ＤＭＡ完了の場合に、ＲＸプロセッサ１６０が、フレーム完了情報を使用する。送信ＤＭＡ完了の場合に、ＴＸプロセッサ１５０が、アダプタ８０での送信用フレームの受信を示す。完了キューは、単一のＴＸ ＬＣＰチャネルまたは単一のＲＸ ＬＣＰチャネルによって使用することができ、あるいは、複数のチャネルによって共用することができる。アダプタ８０のマイクロ・コードが、ＲＸ ＬＣＰエンジン３６０のコマンド・キューへのフレーム記述子を開始することによって、状況キューを更新する。図１２を参照すると、状況は、完了キュー９２０を含む完了状況ＬＣＰ９００を介してホスト１０のメモリ６０に転送される。完了キュー９２０は、連続し（物理的にまたは仮想的にのいずれか）、ホスト１０のメモリ６０内に配置される。たとえば、完了キューを、連続するバッファ内に保持することができる。完了キューの項目９３０は、固定されたサイズを有することが好ましい。各項目が、受信ＬＣＰ９１０に関連するバッファ９５０の先頭へのポインタ９４０を保持する。バッファ９５０には、完了状況に関連するパケット９６０が書き込まれる。

ＴＸソフトウェア／アダプタ・ハンドシェークに、ＴＸ ＬＣＰポートよび完了ＲＸ ＬＣＰポートが含まれる。各ＬＣＰ送信チャネルでは、下記のデータ構造が使用される。
メモリ・マップされたアドレスとして実施され、記述子およびデータを処理する増分要求についてアダプタ８０に知らせる、ドアベル項目。各プロセスは、ドアベル・アクセスに使用されるメモリ・マッピングされたアドレスの単一のページへの一意のアクセスを有する。
ＬＣＰ属性フィールドおよび状況フィールドを含む、アダプタ・メモリ空間２１０内のＬＣＰコンテキスト項目。
送信記述子の構造。この構造は、ホスト１０のメモリ６０内の複数の物理ページにまたがることができる。仮想アドレッシングが、記述子について使用される場合に、変換テーブルを使用して、あるページから次のページに移動する。物理アドレッシングが、記述子について使用される場合に、分岐記述子が、あるページから次のページへの移動に使用される。送信記述子には、アダプタ８０への記述子関連データのすべての転送の後に更新することができる状況フィールドが含まれる。
ポインタ記述子によってポイントされる、ホスト１０のメモリ６０内でピン止めされた送信データ・バッファ。仮想アドレッシングが、データ・バッファについて使用される場合に、変換テーブルによって、ポインタが、アダプタ８０によってホスト１０のメモリ６０にアクセスするのに使用される物理アドレスに変換される。
アダプタ・メモリ空間２１０内の変換テーブルおよび保護ブロックが、アドレス・マッピングに使用される。

図１３を参照すると、送信パケットのフローに、ステップ１０００で、ホスト１０のソフトウェア１０２０が、送信されるデータをバッファ１０３０に書き込むことが含まれる。ステップ１０１０で、ソフトウェア１０２０が、記述子１０４０を更新する。記述子１０４０は、ホスト１０のメモリ６０内またはアダプタ８０のメモリ・サブシステム２１０内のいずれかとすることができる。ステップ１０５０で、ソフトウェア１０２０が、ドアベルを鳴らして、新しいデータの送信の準備ができていることをアダプタ８０に通知する。ステップ１０６０で、アダプタ８０が、異なるＬＣＰチャネルからの要求の間の調停を管理する。あるチャネルが調停に勝った時に、アダプタ８０が、新しい記述子１０４０を読み取る。ステップ１０７０で、アダプタ８０が、データを読み取る。ステップ１０８０で、データが、ネットワーク３０に送信される。ステップ１０９０で、状況が、記述子１０４０内または完了キュー内で更新される。

ＴＸ ＬＣＰチャネルでは、データ・バッファにアクセスする時にアドレス変換を使用することができる。この場合に、データ・バッファは、複数のメモリ・ページからなる。この処理に関する限り、これらのメモリ・ページは、連続する仮想メモリ空間内にある。しかし、アダプタ８０に関する限り、これらのメモリ・ページは、連続しない物理メモリ空間内にある場合がある。完了状況構造に、送信されたフレームの状況を示す情報が含まれる。これは、別々のＬＣＰチャネルとして実施される。すべてのフレームの最初の記述子であるフレーム記述子は、フレームがアダプタ８０に転送された後に更新することができる任意選択の状況フィールドを有する。

図１４を参照すると、送信ＬＣＰチャネル・フローの例で、記述子１１００が、ホスト１０のメモリ６０に配置される。記述子１１００およびパケット１１２０を保管するバッファ１１１０へのアクセスは、アダプタ８０に配置される変換テーブル１１３０を介するアドレス変換を必要とする。バッファ１１１０によって、ホスト１０のソフトウェアの仮想アドレス空間内の連続するスペースが使用される。各フレーム１１２０は、２タイプの記述子すなわち、パケットに関係する情報を与えるフレーム記述子１１４０と、データ１１２０を保持するバッファ１１１０をポイントするポインタ記述子１１５０とによって記述される。各パケットに、データ・ペイロード１１７０と、同一のバッファ１１８０でそれに先行するヘッダ１１６０が含まれる。

ドアベルへの書込トランザクション１１９０によって、アダプタ８０による使用に使用可能なワード数１２００が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。送信ＬＣＰコンテキスト１４０には、送信されるデータを保持するバッファ１１１０の先頭へのポインタ１２１０が含まれる。ＬＣＰチャネルが、ＩＳＯＣ１２０の内部調停に勝つ時に、ＩＳＯＣ１２０は、ＬＣＰコンテキスト１４０内のポインタ１２１０に従ってＬＣＰチャネルの記述子を読み取る。ＬＣＰチャネルの記述子１１００およびバッファ１１１０の両方に関する仮想アドレスは、アダプタ８０のメモリ・サブシステム２１０内に配置される変換テーブル１１３０を使用して物理アドレスに変換される。変換テーブル１１３０は、メモリ・バッファの登録中にＬＣＰマネージャ１３０によって更新される。ＩＳＯＣ１２０は、データおよびフレーム・ヘッダをバッファ１１１０からアダプタ８０へ読み取る。フレーム・ヘッダ１１６０が、ＩＳＯＣ上でネットワーク３０のヘッダに置換される１３２０。パケット・ヘッダおよび対応するデータが、ネットワーク３０に送信される。

ＲＸ ＬＣＰポートは、着信データをＩＳＯＣ１２０からホスト１０で稼動するソフトウェア・アプリケーションによって使用されるメモリ６０に転送するのに使用される。ＴＸ ＬＣＰチャネルは、完全に、ホスト１０のソフトウェアによって開始される記述子を介して制御される。ＲＸ ＬＣＰチャネルでは、ホスト１０のソフトウェアおよびＩＳＯＣ１２０の両方からの記述子が使用される。ＩＳＯＣ１２０によって開始される記述子は、ＬＣＰチャネル動作を制御して、ホスト１０のメモリ６０内の受信されたフレームの宛先を定義するのに使用される。ホスト１０のソフトウェアによって開始される記述子は、バッファが変換テーブル内のマッピングを介して定義されない場合に、バッファの位置を定義するのに使用することができる。ホスト１０のソフトウェアとアダプタ８０の間のハンドシェークを実施するために、２つのＬＣＰチャネルすなわち、受信された着信データ構造を扱うＲＸ ＬＣＰチャネルと、完了状況キューを扱うＲＸ ＬＣＰチャネルが使用されることが好ましい。この完了状況は、アダプタ８０が、ホスト１０のソフトウェアに、ホスト１０のメモリ６０へのフレーム転送が完了したことをシグナリングするのに使用される。項目が、完了キュー構造の順次アドレスに挿入される。完了状況項目のそれぞれに、アダプタ８０によってマークされ、項目所有権がアダプタ８０からホスト１０のソフトウェアに転送されたことを検査するためにホスト１０のソフトウェアによってポーリングされるフィールドが含まれる。１つまたは複数のＲＸ ＬＣＰチャネルが、同一の完了状況キューを使用することができる。複数のＲＸ ＬＣＰチャネルによる完了状況キューの共用は、ＩＳＯＣ１２０によって実行される。

ＲＸ ＬＣＰチャネルは、着信パケットの宛先アドレスを示す情報を必要とする。ＩＳＯＣ１２０は、空きバッファの位置を見つけるための下記の２つのアドレッシングを有する。
直接アドレッシング・モードは、バッファをポイントするのにポインタ記述子を使用しないＬＣＰチャネルを指す。宛先アドレスは、ＩＳＯＣ１２０のマイクロコードによって定義されるか、コンテキスト１４０から読み取られる。
間接アドレッシング・モードは、記述子構造内でデータ・バッファへのポインタを維持するＬＣＰチャネルを指す。記述子は、ホスト１０のメモリ６０内に配置されることが好ましい。

直接アドレッシングでは、アダプタ８０を介する着信パケットの処理の待ち時間が、実質的に短縮される。しかし、直接アドレッシングでは、アダプタ８０での仮想アドレスから物理アドレスへの変換情報の保管を含めて、ＬＣＰマネージャ１３０によるメモリ・バッファの登録が必要である。ホスト１０のソフトウェアは、チャネル・ドアベルに書き込んで、チャネルによって使用可能な空きバッファに追加されるワード数を示す。直接モードでは、下記のステップを使用して、宛先バッファのアドレスを判定する。
Ａ．アドレスＡが、ＬＣＰエンジンへのコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、宛先バッファの基底アドレスになる。

間接モードでは、アダプタ８０が、記述子を使用して、データ・バッファのアドレスを見つける。記述子は、ホスト１０のソフトウェアによって管理される。記述子は、ホスト１０のメモリ６０に配置されることが好ましい。用語「間接」は、アダプタ８０が、宛先アドレスを定義するために追加情報を読み取ることを強調するのに使用される。アダプタ８０は、実行時中にこの情報にアクセスする。間接アドレッシングでは、変換テーブルを保管するのに必要なアダプタ８０のメモリの量が削減される。記述子は、通常は、ホスト１０のメモリ６０に配置される。間接モードでは、宛先バッファのアドレスを判定するのに、下記のステップが使用される。
Ａ．アドレスＡが、ＬＣＰエンジンに対するコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、ポインタ記述子のアドレスになる。
Ｄ．バッファへのポインタすなわちアドレスＢを、記述子から読み取る。
Ｅ．（任意選択）アドレスＢをアドレスＢ’にマッピングする。
Ｆ．アドレスＢ’（ステップＥが実行される場合）またはＢ（ステップＥが実行されない場合）が、宛先バッファの基底アドレスになる。

各ＲＸ ＬＣＰチャネルでは、下記のデータ構造が使用される。
メモリ・マッピングされたアドレスとして実施される、ドアベルへのアクセスによって、追加データについてまたはアダプタ８０がパケット・データを書き込むのに使用可能な記述子について、アダプタ８０が知らされる。
アダプタ８０のメモリ・サブシステム２１０内のＬＣＰコンテキスト項目に、ＬＣＰ属性、状況、構成、および状況フィールドが含まれる。
間接モードで使用されるメモリ・バッファをポイントする記述子。
ホスト１０のメモリ６０内の連続する仮想アドレス空間内のバッファ。
アドレス・マッピング用の、アダプタ８０のメモリ空間２１０内の変換テーブルおよび保護ブロック。

パケットの受信のフローは、下記の特性に依存する。
直接または間接の、アドレッシング・モード。
間接モードについて、記述子がホスト１０のメモリ６０内に配置される。
直接モードについて、アドレス・マッピングを、記述子へのアクセス中に使用してもしなくてもよい。
アドレス・マッピングを、バッファへのアクセス中に使用してもしなくてもよい。
間接モードについて、アドレス保護を、記述子へのアクセス中に使用してもしなくてもよい。
アドレス保護を、バッファへのアクセス中に使用してもしなくてもよい。

これらの特性は、ＬＣＰチャネルごとに、ＬＣＰチャネル初期化中にチャネルのコンテキスト１４０の一部としてセットされる。

図１５を参照すると、パケット受信のフローに、ステップ１３００での、受信されたデータ用の空きバッファ１３２０の、ホスト１０内のソフトウェア１３１０による準備が含まれる。ステップ１３３０で、間接モードで、ホスト１０のソフトウェア１３１０が、記述子１３４０を更新する。記述子１３４０は、ホスト１０のメモリ６０に配置される。ステップ１３５０で、ホスト１０のソフトウェアが、ドアベルを鳴らして、空きバッファ空間についてアダプタ８０に通知する。間接モードでは、ドアベルが、新しい記述子１３４０を示す情報を提供する。直接モードでは、ドアベルが、追加された空きバッファ空間を示す情報を提供する。この段階で、アダプタ８０は、ネットワーク３０からホスト１０のメモリ６０に受信データを転送する準備ができている。ステップ１３００、１３３０、および１３５０は、ホスト１０のソフトウェア１３１０が、ＲＸ ＬＣＰチャネルに空きバッファ１３２０を追加する時に、必ず繰り返される。ＩＳＯＣ１２０は、受信されたパケットごとに下記のステップを繰り返す。ステップ１３６０で、アダプタ８０が、データを受信する。ステップ１３７０で、間接モードで、アダプタ８０が、空きデータ・バッファ１３２０の位置をポイントする記述子１３４０を読み取る。ステップ１３８０で、データおよびヘッダが、データ・バッファ１３２０に書き込まれる。ステップ１３９０で、状況が、完了キュー内で更新される。

図１６を参照すると、受信ＬＣＰチャネル・フローの例で、ポインタ記述子が使用されない。さらに、変換テーブルが使用されない。データ・バッファ１４００で、バッファ１４００を使用するホスト１０内のソフトウェアの物理アドレス空間の連続する空間が使用される。ヘッダおよびデータ・ペイロードの両方が、バッファ１４００に書き込まれる。ドアベルへの書込トランザクション１４１０によって、アダプタ８０による使用のために使用可能なデータ空間が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。受信／完了ＬＣＰコンテキスト１４０に、新しいデータ／完了項目の書込に使用される次／現在のアドレスへの、バッファ１４００の先頭へのポインタ１４２０とオフセット１４３０が含まれる。アダプタ８０は、パケットを受信する時に、次のパケット位置へのオフセット１４３０を増分し、使用可能なデータ空間を更新する。完了項目１４４０が、フレーム受信の完了時、フレーム・タイムアウト時、またはＬＣＰクライアント１００が知ることを必要とする他のフレーム・イベントについて、完了ＬＣＰ１４５０に追加される。完了項目１４４０には、ＬＣＰデータ・バッファ１４００内でフレームを突き止めるためにＬＣＰクライアント１００が必要とするすべての情報が含まれる。ホスト１０のソフトウェアは、完了項目１４４０内のフィールドを使用して、完了項目１４４０の所有権を与えられていることを認識する。

ＩＳＯＣ１２０は、アダプタ８０のメモリ・サブシステム２１０とホスト１０のメモリ６０の間でデータを移動するのにＬＣＰチャネルを使用できるようにする。ホスト１０のメモリ６０からアダプタ８０にデータを転送するために、送信チャネルが使用される。アダプタ８０からホスト１０のメモリ６０にデータを転送するために、受信チャネルが使用される。データが、ホスト１０のメモリ６０からアダプタ８０に転送される時に、フレーム記述子に、ＩＳＯＣ１２０のバス３９０での宛先アドレスが含まれる。このアドレスによって、フレーム・データ・ペイロードの宛先が定義される。パケット・ヘッダは、通常の形で転送される。これによって、ＩＳＯＣ１２０のメモリ空間へのテーブルおよびコードのロードが可能になる。ＩＳＯＣ１２０のメモリ空間からホスト１０のメモリ６０に受信チャネルを介してデータを転送するために、記述子が、ＲＸプロセッサ１６０によって開始される。この記述子には、ホスト１０のメモリ６０での宛先アドレスとソース・アドレスの両方を示す情報が含まれる。

上で説明した本発明の好ましい実施形態では、アダプタ８０が、バス・アーキテクチャ７０を介してホスト・コンピュータ・システム１０のＣＰＵ５０およびメモリ６０に接続される。しかし、本発明の他の実施形態では、アダプタ８０を、バス・アーキテクチャ７０とは独立にホスト・コンピュータ・システム１０に統合することができる。たとえば、本発明の他の実施形態で、アダプタ８０を、ホスト・メモリ６０に接続されたメモリ・コントローラを介してホスト・システムに統合することができる。

さらに、上で説明した本発明の好ましい実施形態では、アダプタ８０が、ホスト・コンピュータ・システム１０に挿入されるプラグ可能アダプタ・カードの形で実施された。しかし、本発明の他の実施形態で、アダプタ８０の異なる実施形態が可能であることを諒解されたい。たとえば、アダプタ８０を、ＣＰＵ５０およびメモリ６０と共に、ホスト・コンピュータ・システムのマザー・ボード上に配置することができる。

データ処理ネットワークの例のブロック図である。 データ処理ネットワークのネットワーク・インターフェース・アダプタ・カードのブロック図である。 データ・ネットワークのホスト・システムの例のブロック図である。 ネットワーク・アダプタ・カードのインテグレーテッド・システム・オン・ア・チップ（ＩＳＯＣ）の例のブロック図である。 ＩＳＯＣのもう１つのブロック図である。 ＩＳＯＣを通る情報のフローを示すＩＳＯＣのブロック図である。 ＩＳＯＣを通る論理送信パスのブロック図である。 ＩＳＯＣを通る論理受信パスのブロック図である。 循環記述子テーブルのブロック図である。 記述子テーブルのリンクされた組のブロック図である。 仮想バッファおよびその物理的に対応するバッファのブロック図である。 完了キューのブロック図である。 ホストからネットワークへのデータの送信フローのブロック図である。 ホストからネットワークへのデータの送信フローのもう１つのブロック図である。 ネットワークからホストへのデータの受信フローのブロック図である。 ネットワークからホストへのデータの受信フローのもう１つのブロック図である。

Claims (4)

1. 記述子により、メモリを介してホスト・コンピュータ・システムである第１のデータ処理システムが、前記ホスト・コンピュータ・システムとデータ通信ネットワークとでデータを通信するデータ通信インターフェースを含む第２のデータ処理システムからデータのフローを送信する装置であって、第１のデータ処理システムと前記装置はバス・アーキテクチャで接続され、第２のデータ処理システムと前記装置はデータ通信ネットワークにより接続される前記装置であって、
   メモリ内と第２データ処理システムとの間で通信されるデータ・パケットを定義するフレーム記述子およびメモリ内の位置を識別するポインタ記述子を含む複数の記述子を生成する記述子ロジックと、
   前記第１および第２のデータ処理システムによるアクセスのために記述子ロジックによって生成された記述子を保管する記述子テーブルを前記メモリに含み、
   前記メモリから前記通信ネットワークへ転送するチャネルと、ネットワークから受信されたデータの前記メモリへ転送する受信チャネルと、
   前記記述子ロジックにより生成されるメモリ転送を開始し、、第１のデータ処理システムのメモリから前記装置へのメモリ転送を開始し、前記装置からのフレームの送信を前記データ通信ネットワークへ前記転送するチャネルで開始するための特定のコマンドとしての動作に関する情報と、受信チャネルに必要な動作の情報を保持する記述子と、１つまたは複数の送信フレームが実行の準備ができていることを前記通信ネットワークへ転送するチャネルに知らせるための制御ワードが書き込まれたドアベル・レジスタを含む装置。
2. 記述子ロジックが、記述子テーブル内の別の記述子へのリンクを含む分岐記述子を生成する、請求項１に記載の装置。
3. 記述子テーブルが、その中の分岐記述子を介して一緒に順次リンクされる複数の記述子リストを含む、請求項２に記載の装置。
4. 記述子テーブルが、循環記述子リストを含む、請求項２に記載の装置。

Images