JP2004520646A - 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法および装置 - Google Patents
周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法および装置 Download PDFInfo
- Publication number
- JP2004520646A JP2004520646A JP2002561693A JP2002561693A JP2004520646A JP 2004520646 A JP2004520646 A JP 2004520646A JP 2002561693 A JP2002561693 A JP 2002561693A JP 2002561693 A JP2002561693 A JP 2002561693A JP 2004520646 A JP2004520646 A JP 2004520646A
- Authority
- JP
- Japan
- Prior art keywords
- lcp
- buffer
- data
- memory
- adapter
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
- 230000002093 peripheral effect Effects 0.000 title claims abstract description 17
- 238000000034 method Methods 0.000 title claims description 30
- 239000000872 buffer Substances 0.000 claims abstract description 127
- 230000004044 response Effects 0.000 claims abstract description 3
- 230000015654 memory Effects 0.000 claims description 183
- 238000012545 processing Methods 0.000 claims description 52
- 238000004891 communication Methods 0.000 claims description 22
- 238000012546 transfer Methods 0.000 abstract description 27
- 230000005540 biological transmission Effects 0.000 description 32
- 238000010586 diagram Methods 0.000 description 19
- 230000008569 process Effects 0.000 description 18
- 238000013519 translation Methods 0.000 description 18
- 238000013507 mapping Methods 0.000 description 14
- 230000009471 action Effects 0.000 description 5
- 238000006243 chemical reaction Methods 0.000 description 4
- 238000013467 fragmentation Methods 0.000 description 3
- 238000006062 fragmentation reaction Methods 0.000 description 3
- 238000013459 approach Methods 0.000 description 2
- 230000000694 effects Effects 0.000 description 2
- 238000003780 insertion Methods 0.000 description 2
- 230000037431 insertion Effects 0.000 description 2
- 238000004519 manufacturing process Methods 0.000 description 2
- 238000012986 modification Methods 0.000 description 2
- 230000004048 modification Effects 0.000 description 2
- 230000003287 optical effect Effects 0.000 description 2
- 238000005457 optimization Methods 0.000 description 2
- 238000003860 storage Methods 0.000 description 2
- 230000001960 triggered effect Effects 0.000 description 2
- 230000006399 behavior Effects 0.000 description 1
- 238000004364 calculation method Methods 0.000 description 1
- 230000008859 change Effects 0.000 description 1
- 239000003795 chemical substances by application Substances 0.000 description 1
- 125000004122 cyclic group Chemical group 0.000 description 1
- 238000013500 data storage Methods 0.000 description 1
- 230000001419 dependent effect Effects 0.000 description 1
- 230000002708 enhancing effect Effects 0.000 description 1
- 238000005111 flow chemistry technique Methods 0.000 description 1
- 239000012634 fragment Substances 0.000 description 1
- 230000006870 function Effects 0.000 description 1
- 230000000977 initiatory effect Effects 0.000 description 1
- 238000007726 management method Methods 0.000 description 1
- 230000007246 mechanism Effects 0.000 description 1
- 238000012544 monitoring process Methods 0.000 description 1
- 238000002360 preparation method Methods 0.000 description 1
- 230000009467 reduction Effects 0.000 description 1
- 238000000926 separation method Methods 0.000 description 1
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
- G06F13/14—Handling requests for interconnection or transfer
- G06F13/20—Handling requests for interconnection or transfer for access to input/output bus
- G06F13/24—Handling requests for interconnection or transfer for access to input/output bus using interrupt
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Computer And Data Communications (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
Abstract
【課題】周辺デバイスからホスト・コンピュータ・システムに割込みを転送する装置を提供すること。
【解決手段】アダプタに、周辺デバイスによって生成される割込みの指示を保管するバッファが含まれる。事前設定条件が満たされることに応答して、コントローラが、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送る。
【解決手段】アダプタに、周辺デバイスによって生成される割込みの指示を保管するバッファが含まれる。事前設定条件が満たされることに応答して、コントローラが、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送る。
Description
【技術分野】
【０００１】
本発明は、周辺デバイスからホスト・コンピュータ・システムへ割込みを転送する方法および装置に関する。
【背景技術】
【０００２】
従来のデータ処理ネットワークには、イーサネット（Ｒ）・アーキテクチャなどの中間のネットワーク・アーキテクチャによってすべてが相互接続される複数のホスト・コンピュータ・システムおよび複数の付加デバイスが含まれる。ネットワーク・アーキテクチャには、通常は、１つまたは複数のデータ通信交換機が含まれる。ホスト・コンピュータ・システムおよび付加デバイスのそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システムには、通常は、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャによって相互接続される、複数の中央処理装置およびデータ・ストレージ・メモリ・デバイスが含まれる。ネットワーク・アダプタも、ホスト・コンピュータ・システムとデータ処理ネットワーク内の他のノードの間でネットワーク・アーキテクチャを介してデータを通信するためにバス・アーキテクチャに接続される。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ホスト・コンピュータ・システムとネットワークの間の迅速なデータ通信のために、ネットワーク・アダプタとホスト・コンピュータ・システムの間の割込みの転送をできる限り効率的に促進することが望ましい。
【課題を解決するための手段】
【０００４】
本発明によれば、周辺デバイスからホスト・コンピュータ・システムに割込みを転送する装置が提供され、この装置には、周辺デバイスによって生成された割込みの指示を保管するバッファと、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送るコントローラが含まれる。バッファは、先入れ先出しメモリ・バッファを含むことが好ましい。
【０００５】
事前設定条件に、バッファが満杯であるかどうかの判定が含まれることが好ましい。事前設定条件に、少なくとも所定の複数の指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含めることができる。同様に、事前設定条件に、少なくとも１つの指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含めることができる。
【０００６】
本発明の好ましい実施形態では、制御データ・ブロックに、ＩＣＢを識別する識別子を有するヘッダ部分と、ペイロード部分に含まれる指示の数を表すカウントが含まれる。ヘッダ部分に、時刻スタンプも含めることができる。
【０００７】
本発明は、上に記載の装置を含む周辺デバイス、およびそのような周辺デバイスを含むデータ通信ネットワーク・インターフェースにも拡張される。本発明は、メモリを有するホスト処理システムと、ホスト・コンピュータ・システムとデータ通信ネットワークの間でデータを通信するデータ通信インターフェースと、データ通信インターフェースからホスト・コンピュータ・システムのメモリへの割込みのフローを制御する、上に記載された装置とを含むデータ処理システムにも拡張される。
【０００８】
もう１つの態様から本発明を見ると、周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法であって、周辺デバイスによって生成される割込みをバッファに保管することと、事前設定条件が満たされるかどうかを判定し、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送ることとを含む方法が提供される。
【０００９】
本発明の好ましい実施形態を、例のみとして、添付図面に関してこれから説明する。
【発明を実施するための最良の形態】
【００１０】
まず図１を参照すると、本発明を実施するデータ処理ネットワークの例に、InfiniBandネットワーク・アーキテクチャ（InfiniBandはInfiniBandTrade Association社の商標である）などの中間ネットワーク・アーキテクチャ３０によって相互接続された、複数のホスト・コンピュータ・システム１０および複数の付加デバイス２０が含まれる。ネットワーク・アーキテクチャ３０には、通常は、複数のデータ通信交換機４０が含まれる。ホスト・コンピュータ・システム１０および付加デバイス２０のそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システム１０に、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャ７０によって相互接続される、複数の中央処理装置（ＣＰＵ）５０およびメモリ６０が含まれる。ネットワーク・アダプタ８０も、ホスト・コンピュータ・システム１０と、データ処理ネットワーク内の他のノードとの間で、ネットワーク・アーキテクチャ３０を介してデータを通信するために、バス・アーキテクチャに接続される。
【００１１】
図２を参照すると、本発明の特に好ましい実施形態では、ネットワーク・アダプタ８０に、ホスト・コンピュータ・システム１０のバス・アーキテクチャ７０への取外し可能な挿入のためのエッジ・コネクタなどのコネクタを有するプラグ可能オプション・カードが含まれる。オプション・カードは、コネクタ２７０を介してバス・アーキテクチャ７０に接続可能な特定用途向け集積回路（ＡＳＩＣ）またはインテグレーテッド・システム・オン・ア・チップ（Integrated System on a Chip、ＩＳＯＣ）１２０、ＩＳＯＣ１２０に接続される１つまたは複数の第３レベル・メモリ・モジュール２５０、および、ネットワーク・アーキテクチャ３０の媒体とＩＳＯＣ１２０の間でデータを通信するためにＩＳＯＣ１２０に接続されたインターポーザ２６０を担持する。インターポーザ２６０は、ネットワーク３０への物理的接続を提供する。本発明のいくつかの実施形態では、インターポーザ２６０を、単一のＡＳＩＣ内で実施することができる。しかし、本発明の他の実施形態では、インターポーザ２６０を、複数の構成要素によって実施することができる。たとえば、ネットワーク３０に光ネットワークが含まれる場合に、インターポーザ２６０に、別の光トランシーバを駆動するリタイマ（retimer）を含めることができる。メモリ２５０は、ＳＲＡＭ、ＳＤＲＡＭ、またはその組合せによって実施することができる。他の形態のメモリも、メモリ２５０の実施に使用することができる。ＩＳＯＣ１２０には、第１および第２のメモリが含まれる。アダプタ８０のメモリ・サブシステムを、すぐに説明する。以下の説明から明らかになるように、この配置は、データ処理ネットワークで動作する分散アプリケーションの改良された性能、改良されたシステム・スケーラビリティ、ある範囲の通信プロトコルとの互換性、およびホスト・コンピュータ・システムでの減らされた処理要件を提供する。具体的に言うと、この配置では、アダプタ８０とホスト・システム１０の間の異種通信プロトコルの共存が可能になる。そのようなプロトコルは、さまざまなアプリケーションをサービスし、同一のアダプタ８０を使用し、データ構造の事前定義の組を使用することができ、これによって、ホストとアダプタ８０の間のデータ転送が機能強化される。並列にオープンすることができるアプリケーション・チャネルの数は、アダプタ８０に割り振られるメモリ・リソースの量によって決定され、アダプタに組み込まれる処理能力に依存しない。下記から、複数の構成要素を単一の集積回路チップに統合するというＩＳＯＣ１２０の概念によって、有利なことに、製造コストが最小になり、再利用可能なシステム基本構成要素が提供される。しかし、本発明の他の実施形態で、ＩＳＯＣ１２０の要素を、別個の構成要素によって実施できることも諒解されたい。
【００１２】
以下の説明では、用語「フレーム」が、ホスト・コンピュータ・システム１０で稼動するソフトウェアとアダプタ８０の間で転送されるデータ単位またはメッセージを指す。各フレームに、フレーム・ヘッダおよびデータ・ペイロードが含まれる。データ・ペイロードに、ユーザ・データ、高水準プロトコル・ヘッダ・データ、肯定応答、フロー制御、またはこれらの任意の組合せを含めることができる。フレーム・ヘッダの内容を、詳細にすぐに説明する。アダプタ８０は、フレーム・ヘッダだけを処理する。アダプタ８０は、フレームを、ネットワーク・アーキテクチャ３０でより効率的に移送される、より小さいパケットに断片化することができる。しかし、そのような断片化では、一般に、データ・ペイロードは変換されない。
【００１３】
本発明の特に好ましい実施形態では、データが、ネットワーク・アーキテクチャ３０上で、以下でパケットと称するアトミックな単位で移送される。各パケットには、経路情報と、その後のハードウェア・ヘッダ・データおよびペイロード・データが含まれる。本発明の通常の例では、１０２４バイトまでのパケット・サイズが使用される。より大きいサイズのフレームは、１０２４バイト・パケットに断片化される。本発明の他の実施形態で、異なるパケット・サイズを使用できることを諒解されたい。
【００１４】
本発明の好ましい実施形態では、アダプタ８０と、ホスト・コンピュータ・システム１０で稼動する複数のアプリケーションとの間の通信が、論理通信ポート（Logical Communication Port）アーキテクチャ（ＬＣＰ）を介してもたらされる。アダプタ８０には、異なる内部データ構造へのアクセス待ち時間の最適化を可能にするメモリ階層が含まれる。このメモリ階層を、すぐに説明する。本発明の好ましい実施形態では、アダプタ８０が、ネットワーク・アーキテクチャ３０に宛てられたアウトバウンド（ＴＸ）データとホスト・コンピュータ・システム１０に宛てられたインバウンド（ＲＸ）データに別々のパスを提供する。各パスには、それ自体のデータ転送エンジン、ヘッダ処理ロジック、およびネットワーク・アーキテクチャ・インターフェースが含まれる。これらのパスも、詳細にすぐに説明する。
【００１５】
図３を参照すると、ＬＣＰアーキテクチャによって、ホスト・コンピュータ・システム１０で稼動するローカル・コンシューマとアダプタ８０の間のインターフェースのフレームワークが定義される。そのようなコンシューマの例に、アプリケーションとスレッドの両方が含まれる。コンピュータ・システム１０を、ユーザ・アプリケーション空間９０とカーネル空間１１０に副分割することができる。ＬＣＰアーキテクチャは、各コンシューマにネットワーク・アーキテクチャ３０への論理ポートを与える。このポートには、ユーザ空間９０から直接にアクセスすることができる。本発明の特に好ましい実施形態では、ハードウェア保護機構が、アクセス許可を解決する。ＬＣＰ登録が、データ・フレームの転送の前に、カーネル空間１１０によって実行される。ＬＣＰアーキテクチャでは、通信プロトコルを定義する必要がない。そうではなく、ＬＣＰアーキテクチャでは、データおよび制御情報を転送するための、アプリケーションとアダプタ８０の間のインターフェースが定義される。その代わりに、通信プロトコルの詳細を、アプリケーションおよびアダプタ８０で実行されるプログラム・コードによってセットすることができる。アダプタ８０で使用できるチャネルの数は、ＬＣＰ関連情報に使用可能なアダプタ・カード８０上のメモリの量だけによって制限される。各ＬＣＰポートを、特定の特徴の組を有するようにプログラムすることができる。特徴の組は、特定のプロトコルに従って、ホスト・コンピュータ・システム内のメモリ６０とアダプタ８０の間でのデータ転送を最もよくサポートするように選択される。さまざまな通信プロトコルを、各プロトコルで異なるＬＣＰポートを使用して、同時にサポートすることができる。
【００１６】
ＬＣＰアーキテクチャには、ＬＣＰクライアント１００、カーネル空間１１０に常駐するＬＣＰマネージャ１３０、および、アダプタ８０に常駐する１つまたは複数のＬＣＰコンテキスト１４０が含まれる。
【００１７】
各ＬＣＰクライアント１００は、ＬＣＰポートに接続された、単一方向アプリケーション・エンド・ポイントである。ＬＣＰクライアント１００を、ユーザ・アプリケーション空間９０またはカーネル１１０内に配置することができる。動作中に、各ＬＣＰクライアント１００は、メモリ６０から読み取られ、アダプタ８０によってＴＸ ＬＣＰチャネルを介して転送されるコマンドおよびデータを作るか、アダプタ８０によってメモリ６０へＲＸ ＬＣＰチャネルを介して転送されるデータを消費する。
【００１８】
ＬＣＰマネージャ１３０は、ＬＣＰチャネルの割振りおよび割振り解除と、チャネルごとのメモリ６０内の読取／書込区域の登録の要求をサービスする、信頼される構成要素である。ＬＣＰマネージャ１３０は、他の通信動作、アプリケーション、またはホスト・コンピュータ・システム１０のオペレーティング・システムを危険にさらさずに、ユーザ空間アプリケーションが、アダプタ８０のリソースを使用できるようにする。
【００１９】
各ＬＣＰコンテキスト１４０は、特定のＬＣＰクライアント１００をサービスするのにアダプタ８０が必要とする制御情報の組である。ＬＣＰコンテキスト１４０には、可能なコマンド、ポインタ構造、およびバッファ記述子定義など、チャネルの存在全体を通じて一定のＬＣＰチャネル属性を含めることができる。ＬＣＰコンテキスト１４０には、サービスを待っているデータの量、関連するＬＣＰチャネルにアクセスするための次のアドレスなど、ＬＣＰチャネルに関する特定のＬＣＰサービス情報も含めることができる。ＬＣＰコンテキスト１４０は、アダプタ８０に常駐するメモリに保管されて、アダプタ８０があるチャネルのサービスを停止し、別のチャネルのサービスを開始する時の高速ＬＣＰコンテキスト切替が可能になっている。
【００２０】
ＬＣＰポートの開始を要求するＬＣＰクライアント１００は、ＬＣＰマネージャ１３０に頼り、ＬＣＰチャネルの割振りを要求する。ＬＣＰチャネル属性は、この時に決定され、これによって、ＬＣＰポートの挙動およびＬＣＰクライアント１００がＬＣＰポートに関連して実行を許可される動作が規定される。ＬＣＰクライアント１００は、一意の保護された形でアダプタ８０にアクセスするのに使用されるアドレスを許可される。このアドレスを、ドアベル（Doorbell）アドレスと称する。
【００２１】
ＬＣＰマネージャ１３０は、アダプタによる仮想アドレスから物理アドレスへの変換を可能にし、ユーザ空間クライアントが他のプログラムを改竄せずにこれらのホスト・メモリ区域にアクセスできるようにするために、ホスト・メモリ６０の区域を登録する責任も負う。
【００２２】
新しいバッファの登録および前のバッファの登録解除は、実行時中に各ＬＣＰクライアント１００が要求することができる。そのような変更は、ＬＣＰクライアント１００、ＬＣＰマネージャ１３０、およびアダプタ８０の間の情報交換のシーケンスを必要とする。
【００２３】
各ＬＣＰクライアント１００およびポートは、ＬＣＰポートによってコマンド実行のために送られる保留中の要求をサービスするためにアダプタ８０が必要とするすべての情報を提供するＬＣＰコンテキスト１４０に関連する。
【００２４】
ＬＣＰクライアント１００とアダプタ８０の間のメモリ転送を開始し、フレームの送信を開始するために、ＬＣＰクライアント１００は、特定の動作に関する情報を保持する記述子を用意する。ＬＣＰクライアント１００は、アダプタ８０にマッピングされたドアベル・アドレスへの入出力書込を実行する。ドアベル・アドレスに書き込むことによって、アダプタ８０のＬＣＰコンテキスト１４０が更新され、新しい要求が実行のために追加される。
【００２５】
アダプタ８０は、保留中の要求を有するさまざまな送信ＬＣＰポートの間で調停し、次にサービスされる送信ＬＣＰポートを選択する。
【００２６】
データの受信時に、受信されたパケットのフレームおよびＬＣＰが、識別される。記述子を生成して、受信されたＬＣＰに必要な動作を定義する。アダプタ８０のＬＣＰエンジンによるこれらの記述子の実行によって、着信データが、ホスト・コンピュータ・システム１０のメモリ６０内でＬＣＰチャネルに割り振られた適当なデータ・バッファに保管される。
【００２７】
サービスされるＬＣＰチャネルごとに、アダプタ８０は、関連するＬＣＰコンテキスト情報をロードし、この情報を使用して、データ転送の所望の組を実行する。その後、アダプタ８０は、次に選択されるＬＣＰコンテキスト１４０の処理に継続する。
【００２８】
図４を参照すると、前に述べたように、ＩＳＯＣ１２０に、第１メモリ空間２２０および２３０と第２メモリ空間２４０が含まれ、アダプタ８０に、さらに、第３レベル・メモリ２５０が含まれる。第１、第２、および第３のメモリは、アダプタ８０のメモリ・サブシステム２１０のために間隔を空ける。本発明の好ましい実施形態では、ＩＳＯＣ１２０に、データ送信動作専用のＴＸプロセッサ（ＴＸ ＭＰＣ）１５０と、データ受信動作専用のＲＸプロセッサ（ＲＸ ＭＰＣ）１６０が含まれる。本発明の特に好ましい実施形態では、プロセッサ１５０および１６０が、ＩＢＭ ＰｏｗｅｒＰＣ ４０５ ＲＩＳＣマイクロプロセッサなどの縮小命令セット・コンピューティング（ＲＩＳＣ）マイクロプロセッサによって実施される。メモリ・サブシステム２１０内で、ＩＳＯＣ１２０に、第１および第２のメモリ空間の他に、ＴＸプロセッサ１５０に関連するデータ・キャッシュ１８０および命令キャッシュ１７０が、ＲＸプロセッサ１６０に関連する第２データ・キャッシュ１９０および第２命令キャッシュ２００と共に含まれる。３つのレベルの間の相違は、メモリのサイズおよび関連するアクセス時間である。すぐに明らかになるように、メモリ・サブシステム２１０は、ＴＸプロセッサ１５０およびＲＸプロセッサ１６０の両方による命令およびデータへの便利なアクセスと、スケーラビリティと、削減された製造コストのためのＴＸプロセッサ１５０およびＲＸプロセッサ１６０の間のリソースの共用とを容易にする。
【００２９】
第１レベル・メモリ空間（Ｍ１）２２０および２３０に、ＴＸ−Ｍ１メモリ空間２２０およびＲＸ−Ｍ１メモリ空間２３０が含まれる。ＴＸ−Ｍ１メモリ２２０は、ＴＸプロセッサ１５０によってのみアクセスでき、ＲＸ−Ｍ１メモリ２３０は、ＲＸプロセッサ１６０によってのみアクセスできる。動作中に、第１レベル・メモリ空間２２０および２３０は、一時データ構造、ヘッダ・テンプレート、スタックなどを保持するのに使用される。第１レベル・メモリ空間２２０および２３０の両方が、０待ち状態に反応する。第１レベル・メモリ空間２２０および２３０のそれぞれは、プロセッサ１５０および１６０の対応する１つのデータ・インターフェースだけに接続され、命令インターフェースには接続されない。この配置によって、キャッシュ可能およびキャッシュ不能の両方の第１レベル・メモリ区域を使用可能にすることができるのと同時に、第１レベル・メモリ空間２２０および２３０内のデータへの効率的なアクセスを維持できるようになる。
【００３０】
第２レベル・メモリ空間（Ｍ２）２４０は、プロセッサ１５０および１６０の両方、アダプタ８０の他の構成要素、およびホスト・コンピュータ・システム１０から使用可能な共用メモリである。第２レベル・メモリ空間２４０へのアクセスは、第１レベル・メモリ区域２２０および２３０へのアクセスより低速である。というのは、第２レベル・メモリ空間２４０が、共用される内部バスを介してより多くのエージェントによって使用されるからである。第３レベル・メモリ空間２５０も、共用リソースである。本発明の特に好ましい実施形態では、アダプタ８０に、その上で第１レベル・メモリ空間２２０および２３０と第２レベル・メモリ空間２４０の両方がプロセッサ１５０および１６０と同一のＡＳＩＣに集積される、コンピュータ周辺回路カードが含まれる。共用メモリ空間２４０および２５０は、一般に、高速で頻繁なアクセス・サイクルを必要としないデータ・タイプに使用される。そのようなデータ・タイプには、ＬＣＰコンテキスト１４０および仮想アドレス変換テーブルが含まれる。この共用メモリ空間２４０および２５０は、プロセッサ１５０および１６０の命令インターフェースおよびデータ・インターフェースの両方からアクセス可能である。
【００３１】
アダプタ８０は、送信データ・フローと受信データ・フローを別々に処理する。送信パスおよび受信パスのプロセッサ１５０および１６０は、タスク間の切替のオーバーヘッドを防止し、あるパス内の一時的な処理負荷を他のパスから分離し、着信データ・ストリームおよび発信データ・ストリームの処理に２つの組込みプロセッサを使用することを促進する。図５を参照すると、ＩＳＯＣ１２０に、送信パス・ロジック２８０および受信パス・ロジック２９０と、共用ロジック３００が含まれる。送信パス・ロジック２８０には、各ＬＣＰチャネルの詳細をデコードし、ＬＣＰ関連コマンドを実行のために取り出すＬＣＰ ＴＸエンジン３１０と、アダプタ８０へのフレームの転送を制御するＴＸロジック３２０と、ＴＸフレームおよびパケット処理の管理用の前述のＴＸプロセッサ１５０と、命令および一時データ構造を保持する前述の第１レベルＴＸメモリ２２０と、リンク・ロジック３３０と、フレームのデータ・パケットへの断片化の経路指定処理などのデータ・フロー処理およびパケット処理を管理する際にＴＸプロセッサ１５０を支援するロジックとが含まれる。ＴＸプロセッサ１５０は、プロセッサが例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式に基づいてタスクを直列に処理する。第１レベルＴＸメモリ２２０は、プロセッサ１５０によって、ＴＸロジック３２０との通信に使用される。受信パス・ロジック２９０には、リンク・ロジック３４０と、着信パケットのヘッダ処理およびそのようなパケットのフレームへの変換または組立の際に前述のＲＸプロセッサ１６０を支援するハードウェアと、ＲＸフレームおよびパケット処理用の前述のＲＸプロセッサ１６０と、命令を保持する前述の第１レベルＲＸメモリ２３０と、ネットワーク・アーキテクチャ３０からのフレームの転送を制御するＲＸロジック３５０と、各ＬＣＰチャネルの詳細をデコードし、関連するＬＣＰデータ構造内の着信データをホスト・コンピュータ・システムのメモリ６０に保管し、ＬＣＰクライアント１００によってアダプタ８０による使用のために供給される時に、空フレーム・バッファへのポインタを受け入れ、登録する、ＬＣＰ ＲＸエンジン３６０とが含まれる。ＲＸプロセッサ１６０は、ＲＸプロセッサ１６０が例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式を使用してタスクを直列に処理する。第１レベルＲＸメモリ２３０は、ＲＸプロセッサ１６０によって、ＲＸロジック３５０との通信に使用される。
【００３２】
前に述べたように、ＩＳＯＣ手法では、アダプタ８０および、回路ボードおよび他のサポート・モジュールなどのアダプタの他の構成要素に関連する製造コストの削減が可能になる。ＩＳＯＣ手法では、アダプタ８０の単純さも高まり、これによって信頼性が高まる。ＩＳＯＣ１２０の要素の間の接続の数は、効果的に無制限である。したがって、複数の幅広い相互接続パスを実施することができる。ホスト・コンピュータ・システム１０でのデータ処理オーバーヘッドを減らすために、ホスト・メモリ６０との間のデータ転送動作は、大部分がＩＳＯＣ１２０によって実行される。ＩＳＯＣ１２０は、着信パケットおよび発信パケットのヘッダの処理も実行する。送信中に、ＩＳＯＣ１２０は、ヘッダを作り、ネットワーク・アーキテクチャ３０に経路指定する。受信中に、アダプタ８０は、システムのメモリ内でのヘッダの位置を判定するためにヘッダを処理する。レベル１メモリ２２０および２３０は、０待ち状態メモリであり、スタック、テンプレート、テーブル、および一時保管場所などのプロセッサ・データ空間を提供する。本発明の特に好ましい実施形態では、送信パス・ロジック２８０、受信パス・ロジック２９０、および共用ロジック３００が、コアと称する、より小さい論理要素から作られる。用語コアが使用されるのは、これらの要素が、それらを異なる応用例に使用できるようにする独立型の特性を有する個々のロジックとして設計されるからである。
【００３３】
前に示したように、送信パス・ロジック２８０は、送信フレームまたは発信フレームを処理する責任を負う。フレーム送信は、バス・アーキテクチャ７０を介して、ホスト・コンピュータ・システム１０のＣＰＵ５０などのＣＰＵによって開始される。ＩＳＯＣ１２０には、バス・アーキテクチャ７０と通信するバス・インターフェース・ロジック３７０が含まれる。ＩＳＯＣ１２０には、バス・インターフェース・ロジック３７０をＩＳＯＣ１２０のプロセッサ・ローカル・バス（ＰＬＢ）３９０に接続するバス・ブリッジング・ロジック３８０も含まれる。ＬＣＰ ＴＸエンジン３１０は、コマンドおよびフレームをホスト・メモリ６０から取り出す。ＴＸプロセッサ１５０は、各フレームのヘッダを処理して、ネットワーク・アーキテクチャ３０上でパケットとして送信するのに適するフォーマットにする。ＴＸロジック３２０は、フレーム・データを修正なしで転送する。リンク・ロジック３３０は、送信される各パケットを処理して、ネットワーク・アーキテクチャ３０での送信用の最終的な形にする。リンク・ロジック３３０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。
【００３４】
前に示したように、受信パス・ロジック２９０は、着信パケットを処理する責任を負う。まず、ネットワーク・アーキテクチャ３０から受信されたパケットが、リンク・ロジック３４０によって処理される。リンク・ロジック３４０は、ヘッダおよびペイロードのフォーマットのパケットを再作成する。パケット・フォーマットおよびホスト・メモリ６０内での宛先を判定するために、ヘッダが、ＲＸプロセッサ１６０によって処理される。リンク・ロジック３４０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。ＲＸ ＬＣＰエンジンは、バス・アーキテクチャ３７０を介してデータをホスト・メモリ６０に転送する責任を負う。
【００３５】
送信パス・ロジック２８０には、ＴＸ ＬＣＰエンジン３１０とＴＸプロセッサ１５０の間のＨｅａｄｅｒＩｎ先入れ先出しメモリ（ＦＩＦＯ）４００が含まれる。受信パス・ロジックには、ＲＸプロセッサ１６０とＲＸ ＬＣＰエンジン３６０の間のＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が含まれる。追加のＦＩＦＯおよびキューを、ＴＸロジック３２０内およびＲＸロジック３５０内に設けることができる。これらのＦＩＦＯおよびキューを、すぐに説明する。
【００３６】
共用ロジック３００には、送信パス・ロジック２８０および受信パス・ロジック２９０によって共用されるすべての要素が含まれる。この要素には、前述のバス・インターフェース・ロジック３７０、バス・ブリッジング・ロジック３８０、ＰＬＢ３９０、第２レベル・メモリ２４０、およびリモート第３レベル・メモリ２５０へのアクセスを提供するコントローラ４２０が含まれる。バス・インターフェース・ロジック３７０は、バス・アーキテクチャ７０上でマスタおよびスレーブの両方として動作する。スレーブとして、バス・インターフェース・ロジックは、ＣＰＵ５０が、第２レベル・メモリ２４０に、コントローラ４２０を介して第３レベル・メモリ２５０に、および、ＩＳＯＣ１２０の構成レジスタおよび状況レジスタにもアクセスできるようにする。そのようなレジスタは、一般に、ＣＰＵ５０、ＴＸプロセッサ１５０、およびＲＸプロセッサ１６０によってアクセスすることができる。マスタとして、バス・インターフェース・ロジックは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０が、ホスト・コンピュータ・システム１０のメモリ６０にアクセスできるようにする。図５では、「Ｍ」がマスタ接続、「Ｓ」がスレーブ接続を示す。
【００３７】
図６を参照すると、ＩＳＯＣ１２０を通るパケットフローは、一般に対称である。言い換えると、フローの全般的な構造は、送信方向と受信方向の両方で類似する。ＩＳＯＣ１２０は、第１インターフェース・ロジック４４０と、第１制御ロジック４６０と、プロセッサ・ロジック４８０と、第２制御ロジック４７０と、第２インターフェース・ロジック４５０とを含むとみなすことができる。パケットは、下記の形で処理される。
【００３８】
Ａ．送信方向では、情報が、バス・アーキテクチャ７０から第１インターフェース・ロジックを介してＩＳＯＣ１２０に持ってこられる。受信方向では、情報が、ネットワーク・アーキテクチャ３０から第２インターフェース・ロジック４５０を介してＩＳＯＣ１２０に持ってこられる。
【００３９】
Ｂ．送信方向では、第１インターフェース・ロジック４４０を介してＩＳＯＣ１２０に持ってこられた情報が、第１制御ロジック４６０によって処理される。受信方向では、第２インターフェース・ロジック４５０を介してＩＳＯＣに持ってこられた情報が、第２制御ロジック４７０によって処理される。
【００４０】
Ｃ．送信方向では、フレーム・ヘッダが、第１制御ロジック４６０で発信フレームについて抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第２制御ロジック４７０用の命令を生成する。発信フレームのペイロードは、第２制御ロジック４７０に渡される。受信方向では、フレーム・ヘッダが、第２制御ロジック４７０で着信フレームから抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第１制御ロジック４６０用の命令を生成する。着信フレームのペイロードは、第１制御ロジック４６０に渡される。両方の方向で、プロセッサ４８０は、ペイロード・データを直接には処理しない。
【００４１】
Ｄ．送信方向では、第２制御ロジック４７０が、プロセッサ・ロジック４８０から受け取った命令に従って発信ペイロード・データをパッケージする。受信方向では、第１制御ロジック４６０が、プロセッサ・ロジック４８０から受け取った命令に従って着信ペイロード・データをパッケージする。
【００４２】
Ｅ．送信方向では、情報が、第２インターフェース・ロジック４５０からその宛先へネットワーク・アーキテクチャ３０を介して移動される。受信方向では、情報が、第１インターフェース・ロジックからその宛先へバス・アーキテクチャ７０を介して移動される。
【００４３】
ホスト・コンピュータ・システム１０で動作するソフトウェアへのインターフェースを、４３０に示す。同様に、プロセッサの入力および出力で動作するマイクロコードへのインターフェースを、４９０および５００に示す。
【００４４】
図７を参照して、以下は、ＩＳＯＣ１２０を通る送信データ・フレームのフローの１例のより詳細な説明である。ＩＳＯＣ１２０は、ＩＳＯＣ１２０内の情報のさまざまなフォーマットに基づいて、ＬＣＰコンテキスト・ドメイン５１０、フレーム・ドメイン５２０、およびネットワーク・ドメイン５３０に分割することができる。ＴＸ ＬＣＰエンジン３１０には、ＬＣＰ要求ＦＩＦＯ５５０、直接メモリ・アクセス（ＤＭＡ）ロジック５６０、フレーム・ロジック５８０、および前述のＬＣＰコンテキスト・ロジック１４０が含まれる。ＬＣＰ要求ＦＩＦＯ５５０、ＤＭＡロジック５６０、およびＬＣＰ ＴＸコンテキスト・ロジック５９０は、ＬＣＰコンテキスト・ドメイン５１０に常駐する。フレーム・ロジック５８０は、フレーム・ドメイン５２０に常駐する。ＴＸロジック３２０、第１レベルＴＸメモリ空間２２０、およびＴＸプロセッサ１５０は、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の境界にまたがる。ＴＸリンク・ロジック３３０は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＩｎ ＦＩＦＯ４００が、第１レベルＴＸメモリ空間２２０に一体化される。一般に、ホスト・コンピュータ・システム１０で実行されるアプリケーションが、フレームを作成する。フレームは、その後、アダプタ８０のＴＸ ＬＣＰチャネルを使用して送信される。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＬＣＰサービス要求を追加するために、ＬＣＰクライアント１００が、アダプタ８０に、１つまたは複数の追加の送信フレームが実行の準備ができていることを知らせる。これは、ドアベルに制御ワードを書き込むことによって実行される。ドアベルのアドレスは、ＬＣＰポートに一意に関連し、他のプロセスによるアクセスから保護されるアドレスを使用して、書込動作が、バス・アーキテクチャ７０上での物理書込サイクルに変換される形で割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰクライアント１００の前の要求の項目を増分することによって、新しい要求をログに記録する。これは、関係するＬＣＰコンテキスト１４０の一部である。アダプタ８０のメモリ・サブシステム２１０内に保持される調停リストも、更新される。単純な例では、調停で、保留中の要求を有するすべての送信ＬＣＰチャネルの間で前述のＦＩＦＯ方式５５０が使用される。あるＬＣＰチャネルがサービスされている間に、次のＬＣＰチャネルが選択される。サービス・サイクルは、対応するＬＣＰコンテキストがＴＸ ＬＣＰエンジン３１０にロードされる時に開始される。その後、ＬＣＰコンテキスト１４０にアクセスして、ＬＣＰチャネルをサービスするアトミック・オペレーションを導出し、そのような動作のパラメータを判定する。たとえば、そのようなアトミック・オペレーションは、ＬＣＰコンテキスト１４０に記録されたＬＣＰチャネル属性に基づくものとすることができる。完全なサービス・サイクルに、通常は、ＬＣＰクライアント１００によって作成される複数のアトミックな記述子をフェッチし、実行するためにアダプタ８０によって実行されるアクティビティの組が含まれる。ＴＸ ＬＣＰチャネルの場合に、サービス・サイクルに、一般に、ホスト・メモリ６０からアダプタ８０のメモリ・サブシステム２１０に複数のフレームを読み取ることが含まれる。最後に、修正を必要とするすべてのＬＣＰコンテキスト情報（言い換えると、ＬＣＰサービス情報）が、アダプタ８０のメモリ・サブシステム２１０内で更新される。一般に、アダプタ８０によってＬＣＰサービス・サイクル内で最初に実行される動作は、次に処理される記述子を取り出すことである。
【００４５】
ＩＳＯＣ１２０による送信フレームの処理には、通常は下記のステップが含まれる。
【００４６】
Ａ．後続ＬＣＰポート・フレーム記述子の取出
次に取り出される記述子のアドレスは、ＬＣＰチャネルのコンテキスト１４０の一部として保管される。アダプタ８０は、ホスト・メモリ６０から記述子を読み取り、ＬＣＰチャネル属性に基づいてその記述子をデコードする。記述子によって、新しいフレーム・ヘッダのサイズ、データ・ペイロードのサイズ、およびこれらの項目の位置が定義される。
【００４７】
Ｂ．仮想アドレスの物理アドレスへの変換
データ・バッファが、アプリケーション内で仮想メモリ・アドレスによって参照される場合に、そのアドレスは、アドレス変換という追加処理を受けなければならない。この場合に、アプリケーションによって使用される仮想アドレスが、アダプタ８０がホスト・メモリ６０にアクセスする間にアダプタ８０によって使用可能な物理アドレスに変換される。これは、ページ境界を超えることを監視し、ＬＣＰマネージャ１３０によってアダプタ８０のメモリ・サブシステム２１０に書き込まれる物理ページ位置情報を使用することによって行われる。仮想アドレスから物理アドレスへの変換処理は、記述子テーブルが、信頼されないＬＣＰクライアント１００によって作成される場合のセキュリティ手段としても働く。これによって、ホスト・メモリ６０の無関係な区域への許可されないアクセスが防止される。
【００４８】
Ｃ．フレーム・ヘッダの読取
物理アドレッシングを使用して、ＴＸフレームのヘッダおよびペイロード・データが、ホスト・メモリ６０内のバッファから読み取られる。その後、ヘッダが、ＴＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ４００に保管される。ヘッダ取出が完了した時に、アダプタ８０は、ヘッダの処理をＴＸプロセッサ１５０によって開始できることを示す内部フラグをセットする。
【００４９】
Ｄ．フレーム・データの読取
ペイロード・データが、ホスト・メモリ６０から読み取られ、アダプタ８０によってデータＦＩＦＯ５７０に保管される。データＦＩＦＯ５７０は、図７では、ＴＸロジック３２０に常駐するものとして図示されている。しかし、データＦＩＦＯ５７０を、第１レベルＴＸメモリ空間２２０に一体化することもできる。データ読取トランザクションは、送信されるデータのすべてがアダプタ８０のメモリ・サブシステム２１０に保管されるまで継続する。読取動作の完了に続いて、状況指示が、ＬＣＰクライアント１００に返される。ヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００に読み取られてすぐに、ヘッダの処理を開始できることに留意されたい。データ全体が読み取られるのを待つ必要はない。
【００５０】
Ｅ．フレーム・ヘッダの処理
ヘッダ処理は、ＴＸプロセッサ１５０によって実行される。ヘッダ処理は、プロトコル依存であり、ＬＣＰアーキテクチャの外部のプロトコル情報が用いられる。ＴＸプロセッサ１５０は、ＴＸプロトコル・ヘッダ・マイクロコードを実行し、プロトコルおよび経路指定初期化シーケンス中にアダプタ８０のメモリ・サブシステム２１０に既に保管された経路指定テーブルおよび他の関連情報にアクセスする。ＴＸプロセッサ１５０は、新しいヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００内で待っていることの指示を受け取る時に、ヘッダ処理を開始する。ヘッダ処理では、ネットワーク・アーキテクチャ３０を介してパケットを送信するのに使用されるフォーマットであり、経路指定情報を含む、１つまたは複数のパケット・ヘッダが作られる。ペイロード・サイズが、ネットワーク・アーキテクチャ３０によって許容される最大パケット・サイズより大きい場合には、元のペイロード・データの連続するデータ・セグメントに関してそれぞれが使用される複数のパケット・ヘッダを生成して、ネットワーク・アーキテクチャ３０を介する通信用のパケットを形成することによって、ペイロードを断片化する。
【００５１】
Ｆ．送信用のパケット・ヘッダのキューイング
パケットのヘッダ・ワード数およびデータ・ワード数を定義するコマンドおよびパケット・ヘッダ自体が、ＴＸプロセッサ１５０によって、第１レベル・メモリ空間２２０内のＴＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０に書き込まれる。
【００５２】
Ｇ．送信用のパケット・ヘッダおよびパケット・データのマージ
ネットワーク・アーキテクチャ３０でのパケットの送信は、コマンドがＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０内で準備ができており、データＦＩＦＯ５７０に、関連するパケットの送信を完了するのに十分なデータが含まれる時に、必ずトリガされる。巡回冗長検査（ＣＲＣ）を、各パケットのヘッダおよびデータに追加することができる。各完全なパケットが、ＴＸリンク・ロジック３３０を介してネットワーク・アーキテクチャ３０に転送される。
【００５３】
各フレームの送信処理は、すべてのフレーム・データが、１つまたは複数のパケットによってネットワーク・アーキテクチャ３０で送信された時に完了する。アダプタ８０によって処理されるフレームごとに、第２のＬＣＰクライアント１００を介してアプリケーションに状況を返すことができる。この状況は、ホスト・メモリ６０からアダプタ８０へのフレーム・データ転送の完了、フレーム送信自体の完了、または他のレベルの送信状況とすることができる。
【００５４】
どの瞬間でも、アダプタ８０は、次にサービスされるＬＣＰの選択、ＬＣＰチャネルＡのサービスの開始、ＬＣＰチャネルＢの最後のフレームのデータのＤＭＡ取出の実行、ＬＣＰチャネルＣのフレーム・ヘッダの処理および断片化、ＬＣＰチャネルＤから発するパケットの送信のうちの一部またはすべてを平行に実行することができる。
【００５５】
図８を参照して、以下は、例のみとして、ＲＸ ＬＣＰポートを使用するアプリケーションによるデータ・フレーム受信の説明である。ＩＳＯＣ１２０の動作は、ＬＣＰによってサポートされるプロトコルのタイプに応じて変更することができる。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＲＸ ＬＣＰエンジン３６０には、ＬＣＰ割振りロジック６２０、ＬＣＰコンテキスト・ロジック６１０、およびＤＭＡロジック６３０が含まれ、これらのすべてが、ＬＣＰコンテキスト・ドメイン５１０に常駐する。ＲＸプロセッサ１６０、第１レベルＲＸメモリ空間２３０、およびＲＸロジック３５０のすべてが、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の間の境界にまたがる。ＲＸリンク・ロジック３４０およびパケット援助ロジック６００は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が、第１レベルＲＸメモリ空間２３０内に配置される。ＩＳＯＣ１２０によってネットワーク・アーキテクチャ３０から受信されたフレームは、ホスト・メモリ６０内のＬＣＰクライアント・バッファに書き込まれる。メモリ・バッファの可用性は、ＬＣＰ ＲＸクライアント１００によって判定され、着信データ・フレームの挿入のためにアダプタ８０に示される。ＬＣＰクライアント１００は、送信される準備ができた新しいフレームについて送信パス・ロジック２８０が知らされる前に述べた形に似て、ＩＳＯＣ１２０の受信ドアベルに書き込むことによってバッファを提供する。ドアベル・レジスタ・アドレスは、書込動作がバス・アーキテクチャ７０への物理書込サイクルに変換されるように割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰ ＲＸクライアント１００の使用可能なワード項目の数を増分することによって、空のメモリ区域の新たな提供をログに記録する。使用可能なワード・カウントは、関係するＬＣＰコンテキスト１４０の一部である。アプリケーションは、バッファ内の受信したフレームの処理を完了する時に、必ずドアベルに書き込む。この書込サイクルによって、新たに使用可能なメモリ空間のワード数が示される。ＬＣＰコンテキスト内のカウントが、その量だけ増分される。ネットワーク・アーキテクチャ３０から受信されたパケットは、アダプタ８０によってホスト・メモリ６０内の連続する空間に組み立てられる、より大きいフレームの一部である場合がある。ＩＳＯＣ１２０による受信されたフレームの処理には、一般に、下記のステップが含まれる。
【００５６】
Ａ．パケット・ヘッダとデータの分離
ＲＸリンク・ロジック３４０は、ネットワーク・アーキテクチャ３０からの情報をパケットのストリームに変換する。受信されたパケットのそれぞれが、ＲＸリンク・ロジック３４０によって処理されて、パケット・ヘッダがペイロード・データから分離される。ヘッダは、第１レベルＲＸメモリ空間２３０内のＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０にプッシュされる。ペイロードは、ＲＸロジック３５０内のＲＸデータＦＩＦＯ６５０にプッシュされる。ＲＸデータＦＩＦＯ６５０は、第１レベルＲＸメモリ空間２３０内で実施することもできる。
【００５７】
Ｂ．パケット・ヘッダのデコードおよびＬＣＰフレーム・ヘッダの生成。
パケット・ヘッダをデコードして、パケットが属するフレームのＩＤ、ペイロードのサイズ、およびフレーム・データのサイズを示すフィールドを提供する。パケット・ヘッダが、ＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０に関するリーダーになるならば、指示が、ＲＸプロセッサ１６０に送られる。ＲＸプロセッサは、パケット・ヘッダ情報を処理し、パケット・データの転送に必要な情報を含むＬＣＰ関連コマンドを生成する。そのような情報には、パケットのアドレスおよび長さが含まれる。ヘッダ処理の終りに、記述子または記述子の組が、ＬＣＰ ＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０に書き込まれ、指示がトリガされる。
【００５８】
Ｃ．ＲＸ ＬＣＰコンテキスト内のデータの転送
記述子が、ＲＸ ＬＣＰエンジン３６０によってＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０から取り出され、デコードされる。記述子には、ＬＣＰ番号、パケット・アドレス、パケット・データ長、および、アダプタ８０のメモリ・サブシステム２１０に転送されるデータのソース・アドレスが含まれる。ＲＸ ＬＣＰエンジン３４０は、ＬＣＰコンテキスト情報を使用して、ホスト・メモリ６０内の書き込まれるターゲット物理アドレス（または、ページにまたがる場合には複数のアドレス）を作成し、ＤＭＡ転送を開始して、データを書き込む。
【００５９】
Ｄ．ＩＳＯＣ ＤＭＡトランザクション
ＩＳＯＣ１２０は、適当なバス・コマンドを選択し、可能な最長のバーストを実行することによって、バス・アーキテクチャ７０でのトランザクションの最適化を目指す。
【００６０】
どの瞬間でも、アダプタ８０は、ＬＣＰチャネルＸのバッファ割振りの処理、ＬＣＰチャネルＡのインバウンド・データ書込サービスの開始、ＬＣＰチャネルＢのデータのＤＭＡストアの実行、ＬＣＰチャネルＣ宛のパケットのフレーム組立の処理、およびＬＣＰチャネルＤのパケットの受信の一部またはすべてを並列に実行することができる。
【００６１】
ＲＸプロセッサ１６０およびＴＸプロセッサ１５０でのフレーム処理オーバーヘッドを最小にするために、パケット援助ロジック６００に、フレーム断片化ロジック、ＣＲＣおよびチェックサム計算ロジック、およびマルチキャスト処理ロジックが含まれる。
【００６２】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０の両方とホスト１０の間のデータ・フローを、これから詳細に説明する。ＴＸ ＬＣＰポートおよびＲＸ ＬＣＰポートの両方で、データ転送用のメモリ・バッファと、そのようなメモリ・バッファをポイントする記述子構造が使用される。記述子構造は、データ・プロバイダとデータ・コンシューマの間でデータ・バッファを管理し、データ・プロバイダによって使用される空のメモリ・バッファを返すのに使用される。記述子は、物理アドレスまたは仮想アドレスのいずれかに基づいてメモリ・バッファをポイントする。
【００６３】
ＴＸ ＬＣＰチャネルは、ホスト・メモリ６０からＩＳＯＣ１２０のバッファへのデータ転送の責任を負う。ロジックの他の層は、ＩＳＯＣ１２０のバッファからネットワーク３０にデータを転送する責任を負う。ＲＸ ＬＣＰチャネルは、ネットワーク３０から受信されたデータのホスト・メモリ６０への転送の責任を負う。
【００６４】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、比較的多数のＬＣＰチャネルを扱うことができる。各ＬＣＰチャネルは、それに固有のすべての情報を含むパラメータの組を有する。この情報には、チャネルの構成、現在の状態、および状況が含まれる。あるチャネルに関連するＬＣＰコンテキスト１４０が、チャネルの初期化中にＬＣＰマネージャ１３０によってセットされる。チャネル動作中に、ＬＣＰコンテキスト１４０の内容が、ＩＳＯＣ１２０のみによって更新される。ＬＣＰコンテキスト１４０は、アダプタ８０のメモリ・サブシステム２１０内のコンテキスト・テーブルに保管される。ＬＣＰチャネルのＬＣＰコンテキスト１４０へのアクセスは、ＬＣＰ番号に従って実行される。ＬＣＰのＲＸチャネルおよびＴＸチャネルでは、異なるＬＣＰコンテキスト構造が使用される。
【００６５】
データ・バッファは、ホスト１０のメモリ６０内のピン止めされた区域である。送信バッファには、送信用のデータが保持される。ＴＸ ＬＣＰエンジン３１０は、これらのバッファに置かれたデータをＩＳＯＣ１２０の内部バッファに移動する。ネットワーク・アーキテクチャ３０から受信される着信データは、ＲＸ ＬＣＰエンジン３６０によって、ホスト１０のメモリ６０内のバッファに移動される。バッファの所有権は、ホスト１０内のソフトウェアとＩＳＯＣ１２０の間で交番する。ＬＣＰ ＴＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ホスト１０のメモリ６０内で、送信されるデータと共にバッファを準備する。
Ｂ．ソフトウェアが、バッファ内のデータが送信の準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、バッファからデータを読み取る。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、読み取られ、新しいデータを転送するためにホスト１０のソフトウェアによって再利用することができるバッファを識別する。
【００６６】
ＬＣＰ ＲＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ＩＳＯＣ１２０が受信されたデータを書き込むことができるバッファを準備する。
Ｂ．ソフトウェアが、空きバッファがホストのメモリ６０内で準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、データをバッファに書き込む。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、受信されたデータが書き込まれ、ソフトウェアによって処理されることができるバッファを識別する。
【００６７】
ソフトウェアが、ＩＳＯＣ１２０によって使用されるバッファを準備する時に、バッファ情報が、ドアベル・レジスタを介して追跡される。ＩＳＯＣ１２０によって使用されるバッファに関する情報は、状況更新を使用してまたは完了キューを介して、ソフトウェアに返される。ＴＸ ＬＣＰチャネルについて、バッファに、ＴＸ ＬＣＰエンジン３１０によってＩＳＯＣ１２０に転送され、処理されて、ネットワーク３０での送信用の１つまたは複数のパケットになるデータおよびヘッダの情報が含まれる。ヘッダは、ＩＳＯＣ１２０のＴＸプロセッサ１５０によって、ネットワーク３０で送信されるパケットのヘッダを生成するのに使用される。ＲＸ ＬＣＰチャネルについて、空きバッファが、ホスト１０のソフトウェアによってアダプタ８０に割り当てられる。アダプタ８０は、受信されたパケットをバッファに書き込む。
【００６８】
記述子によって、ＩＳＯＣ１２０およびホスト１０のソフトウェアの両方に既知のデータ構造が定義されている。ソフトウェアは、記述子を使用して、ＩＳＯＣ１２０に制御情報を転送する。制御情報は、所望の機能に応じて、フレーム記述子、ポインタ記述子、または分岐記述子の形とすることができる。ソフトウェア内およびＩＳＯＣ１２０内の記述子ロジックは、行われる制御手段に従って記述子を生成し、修正する。そのような手段を、すぐに説明する。フレーム記述子には、パケットの記述子（たとえば、データ長、ヘッダ長など）が含まれる。ポインタ記述子には、データ位置の記述子が含まれる。分岐記述子には、記述子位置の記述（たとえば、記述子のリンク・リスト）が含まれる。記述子内の情報は、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって実行されるデータ移動動作の、ホスト１０内のソフトウェアによる制御に使用される。ＴＸパケット・ヘッダを生成するためにフレームを処理するのに使用される情報は、フレームのヘッダに配置される。図９を参照すると、記述子を、単一のテーブル７００内に設けることができ、ＬＣＰコンテキスト１４０が、テーブル７００の先頭をポイントする。図１０を参照すると、記述子を、リンクされた記述子テーブル７２０から７４０の構造で配置することもできる。ＬＣＰチャネル初期化の後に、ＬＣＰコンテキスト１４０は、構造内の最初の記述子テーブル７２０の先頭をポイントする。分岐記述子７５０から７７０は、テーブル７２０から７４０のリンク・リストを生成するのに使用され、ここで、記述子テーブル７２０から７４０の終りの分岐記述子７５０から７７０は、別のテーブル７２０から７４０の始めをポイントする。図９に戻ると、分岐記述子は、循環バッファを生成するのにも使用することができ、ここで、テーブル７００の終りの分岐記述子７１０は、同一のテーブル７００の始めをポイントする。循環バッファは、受信パスで使用することもできる。この場合に、ＬＣＰコンテキスト１４０が、バッファの先頭をポイントするように開始される。バッファは、ＩＳＯＣ１２０がその終りに達した時に、ラップ・アラウンドされる。ホスト１０のソフトウェアは、ホスト１０のメモリ６０に（受信パスと送信パスの両方について）、またはアダプタ８０のメモリ２５０に（送信パスのみについて）記述子を書き込むことができる。アダプタ８０のメモリ・サブシステム２１０への記述子の書込には、ホスト１０のソフトウェアによる入出力動作が含まれ、アダプタ８０のメモリ・サブシステム２１０が占有される。ホスト１０のメモリ６０での記述子の書込は、アダプタ８０が、新しい記述子を読み取らなければならない時に、必ずホスト１０のメモリ６０にアクセスすることを必要とする。ソフトウェア記述子の位置は、ＬＣＰチャネルごとに独立に、ＬＣＰマネージャ１３０によって定義される。記述子の位置は、システム性能最適化に従って定義される。記述子は、キューの構成での柔軟性を提供する。
【００６９】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、記述子テーブル内の記述子にアクセスし、データ・バッファにアクセスするのに、アドレスを使用する。アドレスは、物理アドレスまたは仮想アドレスのいずれかとすることができる。用語物理アドレスは、ＩＳＯＣ１２０が、そのままでバス７０に駆動できるアドレスを指す。用語仮想アドレスは、物理アドレスではなく、ソフトウェアまたはマイクロコードによって使用されるアドレスを指す。仮想アドレスは、物理アドレスを生成するために、マッピングを受けなければならない。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるアドレスは、ＬＣＰチャネル・コンテキスト１４０内のポインタ、ホスト１０で稼動するソフトウェアによって準備される記述子内のポインタ、ＲＸプロセッサ１６０によって準備される記述子内のポインタ、およびＴＸプロセッサ１５０によって準備される記述子内のポインタ（完了メッセージを返すのに使用される）という異なるソースを有することができる。ポインタは、記述子またはデータ・バッファをポイントすることができる。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるすべてのアドレスを、任意選択として、バス７０上の物理アドレスとして使用される新しいアドレスにマッピングすることができる。アドレス・マッピングは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって行われる。ＩＳＯＣ１２０は、ローカル・メモリ２１０を使用して、変換テーブルを保持する。ＬＣＰマネージャ１３０は、メモリ登録中にアダプタ８０に変換テーブルを書き込む。アドレス・マッピングによって、バッファまたは記述子テーブルに仮想アドレスを使用できるようになる。仮想アドレッシングによって、物理的に複数の物理ページに配置される仮想バッファの管理が可能になる。アドレス・マッピングによって、ホスト１０が、ソフトウェアのための変換プロセッサを必要とせずに、仮想アドレスを使用するアプリケーションを直接に扱えるようになる。
【００７０】
図１１を参照すると、この図には、ホスト１０のソフトウェアから見えるバッファ８８０のイメージ８００が示されている。ホスト１０内のメモリ６０にアクセスするのに使用される、アドレスの物理マッピング８１０も示されている。仮想ポインタが、バッファ内の位置を８２０ポイントする。この例のバッファは、ホスト１０のメモリ６０内の少数の連続しないページ８４０から８７０を占める仮想バッファである。ＬＣＰエンジン３１０および３６０は、変換テーブル８３０を介してアドレスを変換することによってマッピングを実行する。変換テーブルは、仮想バッファ８８０からマッピングされる各物理バッファ８４０から８７０の先頭への物理アドレス・ポインタを保持する。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のメモリ６０内で記述子およびデータ・バッファをマッピングする時の柔軟性が可能になる。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のソフトウェアが物理アドレスへのアドレス変換を実行することを必要とせずに、仮想アドレスを使用するソフトウェア・バッファへの直接接続も可能になる。
【００７１】
アダプタ８０がホストのメモリ６０に書き込む各パケットは、それに関連する状況を有する。状況を用いると、アダプタ８０とホスト１０のソフトウェアの間の同期化が可能になる。状況は、パケットの異なる信頼性レベルを示すのに使用することができる。ＩＳＯＣ１２０は、下記の状況ライト・バックを提供する：送信ＤＭＡ完了は、ＴＸパケット内のデータがアダプタ８０に読み込まれたことを示し；信頼される送信は、ネットワーク３０でのデータ送信の完了を示すために返され；受信ＤＭＡ完了は、メモリ６０への受信データ転送の完了を示し；信頼される受信は、ネットワーク３０内の宛先ノードによる送信パケットの受信を示す。
【００７２】
ＴＸフレーム記述子には、２バイトの状況フィールドが含まれる。状況ライト・バックは、トランザクション状態が記述子にライト・バックされることを意味する。状況には、ホスト１０のソフトウェアがポーリングできる完了ビットが含まれる。ホスト１０のソフトウェアは、セットされた完了ビットを見つけた時に、そのフレーム記述子によって定義されるフレームに関連するバッファを再利用することができる。
【００７３】
完了キューは、ＲＸ ＬＣＰチャネルによって実施される。完了キューによって使用されるＬＣＰチャネルは、どのＲＸ ＬＣＰチャネルによっても実施することができる柔軟性および特性のすべてを有する。ＴＸプロセッサ１５０およびＲＸプロセッサ１６０は、状況ライト・バックを生成して、信頼される送信、信頼される受信、受信ＤＭＡ完了、または送信ＤＭＡ完了を示す。フレームに関連する異なる指示を、異なる場合に使用することができる。たとえば、信頼される送信の場合に、ＴＸプロセッサ１５０は、パケット送信の状況を示す内部レジスタを読み取る。信頼される受信の場合に、ＲＸプロセッサ１６０が、肯定応答を含む受信されたパケットとして完了指示を得る。受信ＤＭＡ完了の場合に、ＲＸプロセッサ１６０が、フレーム完了情報を使用する。送信ＤＭＡ完了の場合に、ＴＸプロセッサ１５０が、アダプタ８０での送信用フレームの受信を示す。完了キューは、単一のＴＸ ＬＣＰチャネルまたは単一のＲＸ ＬＣＰチャネルによって使用することができ、あるいは、複数のチャネルによって共用することができる。アダプタ８０のマイクロ・コードが、ＲＸ ＬＣＰエンジン３６０のコマンド・キューへのフレーム記述子を開始することによって、状況キューを更新する。図１２を参照すると、状況は、完了キュー９２０を含む完了状況ＬＣＰ９００を介してホスト１０のメモリ６０に転送される。完了キュー９２０は、連続し（物理的にまたは仮想的にのいずれか）、ホスト１０のメモリ６０内に配置される。たとえば、完了キューを、連続するバッファ内に保持することができる。完了キューの項目９３０は、固定されたサイズを有することが好ましい。各項目が、受信ＬＣＰ９１０に関連するバッファ９５０の先頭へのポインタ９４０を保持する。バッファ９５０には、完了状況に関連するパケット９６０が書き込まれる。
【００７４】
ＴＸソフトウェア／アダプタ・ハンドシェークに、ＴＸ ＬＣＰポートよび完了ＲＸ ＬＣＰポートが含まれる。各ＬＣＰ送信チャネルでは、下記のデータ構造が使用される。
メモリ・マップされたアドレスとして実施され、記述子およびデータを処理する増分要求についてアダプタ８０に知らせる、ドアベル項目。各プロセスは、ドアベル・アクセスに使用されるメモリ・マッピングされたアドレスの単一のページへの一意のアクセスを有する。
ＬＣＰ属性フィールドおよび状況フィールドを含む、アダプタ・メモリ空間２１０内のＬＣＰコンテキスト項目。
送信記述子の構造。この構造は、ホスト１０のメモリ６０内の複数の物理ページにまたがることができる。仮想アドレッシングが、記述子について使用される場合に、変換テーブルを使用して、あるページから次のページに移動する。物理アドレッシングが、記述子について使用される場合に、分岐記述子が、あるページから次のページへの移動に使用される。送信記述子には、アダプタ８０への記述子関連データのすべての転送の後に更新することができる状況フィールドが含まれる。
ポインタ記述子によってポイントされる、ホスト１０のメモリ６０内でピン止めされた送信データ・バッファ。仮想アドレッシングが、データ・バッファについて使用される場合に、変換テーブルによって、ポインタが、アダプタ８０によってホスト１０のメモリ６０にアクセスするのに使用される物理アドレスに変換される。
アダプタ・メモリ空間２１０内の変換テーブルおよび保護ブロックが、アドレス・マッピングに使用される。
【００７５】
図１３を参照すると、送信パケットのフローに、ステップ１０００で、ホスト１０のソフトウェア１０２０が、送信されるデータをバッファ１０３０に書き込むことが含まれる。ステップ１０１０で、ソフトウェア１０２０が、記述子１０４０を更新する。記述子１０４０は、ホスト１０のメモリ６０内またはアダプタ８０のメモリ・サブシステム２１０内のいずれかとすることができる。ステップ１０５０で、ソフトウェア１０２０が、ドアベルを鳴らして、新しいデータの送信の準備ができていることをアダプタ８０に通知する。ステップ１０６０で、アダプタ８０が、異なるＬＣＰチャネルからの要求の間の調停を管理する。あるチャネルが調停に勝った時に、アダプタ８０が、新しい記述子１０４０を読み取る。ステップ１０７０で、アダプタ８０が、データを読み取る。ステップ１０８０で、データが、ネットワーク３０に送信される。ステップ１０９０で、状況が、記述子１０４０内または完了キュー内で更新される。
【００７６】
ＴＸ ＬＣＰチャネルでは、データ・バッファにアクセスする時にアドレス変換を使用することができる。この場合に、データ・バッファは、複数のメモリ・ページからなる。この処理に関する限り、これらのメモリ・ページは、連続する仮想メモリ空間内にある。しかし、アダプタ８０に関する限り、これらのメモリ・ページは、連続しない物理メモリ空間内にある場合がある。完了状況構造に、送信されたフレームの状況を示す情報が含まれる。これは、別々のＬＣＰチャネルとして実施される。すべてのフレームの最初の記述子であるフレーム記述子は、フレームがアダプタ８０に転送された後に更新することができる任意選択の状況フィールドを有する。
【００７７】
図１４を参照すると、送信ＬＣＰチャネル・フローの例で、記述子１１００が、ホスト１０のメモリ６０に配置される。記述子１１００およびパケット１１２０を保管するバッファ１１１０へのアクセスは、アダプタ８０に配置される変換テーブル１１３０を介するアドレス変換を必要とする。バッファ１１１０によって、ホスト１０のソフトウェアの仮想アドレス空間内の連続するスペースが使用される。各フレーム１１２０は、２タイプの記述子すなわち、パケットに関係する情報を与えるフレーム記述子１１４０と、データ１１２０を保持するバッファ１１１０をポイントするポインタ記述子１１５０とによって記述される。各パケットに、データ・ペイロード１１７０と、同一のバッファ１１８０でそれに先行するヘッダ１１６０が含まれる。
【００７８】
ドアベルへの書込トランザクション１１９０によって、アダプタ８０による使用に使用可能なワード数１２００が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。送信ＬＣＰコンテキスト１４０には、送信されるデータを保持するバッファ１１１０の先頭へのポインタ１２１０が含まれる。ＬＣＰチャネルが、ＩＳＯＣ１２０の内部調停に勝つ時に、ＩＳＯＣ１２０は、ＬＣＰコンテキスト１４０内のポインタ１２１０に従ってＬＣＰチャネルの記述子を読み取る。ＬＣＰチャネルの記述子１１００およびバッファ１１１０の両方に関する仮想アドレスは、アダプタ８０のメモリ・サブシステム２１０内に配置される変換テーブル１１３０を使用して物理アドレスに変換される。変換テーブル１１３０は、メモリ・バッファの登録中にＬＣＰマネージャ１３０によって更新される。ＩＳＯＣ１２０は、データおよびフレーム・ヘッダをバッファ１１１０からアダプタ８０へ読み取る。フレーム・ヘッダ１１６０が、ＩＳＯＣ上でネットワーク３０のヘッダに置換される１３２０。パケット・ヘッダおよび対応するデータが、ネットワーク３０に送信される。
【００７９】
ＲＸ ＬＣＰポートは、着信データをＩＳＯＣ１２０からホスト１０で稼動するソフトウェア・アプリケーションによって使用されるメモリ６０に転送するのに使用される。ＴＸ ＬＣＰチャネルは、完全に、ホスト１０のソフトウェアによって開始される記述子を介して制御される。ＲＸ ＬＣＰチャネルでは、ホスト１０のソフトウェアおよびＩＳＯＣ１２０の両方からの記述子が使用される。ＩＳＯＣ１２０によって開始される記述子は、ＬＣＰチャネル動作を制御して、ホスト１０のメモリ６０内の受信されたフレームの宛先を定義するのに使用される。ホスト１０のソフトウェアによって開始される記述子は、バッファが変換テーブル内のマッピングを介して定義されない場合に、バッファの位置を定義するのに使用することができる。ホスト１０のソフトウェアとアダプタ８０の間のハンドシェークを実施するために、２つのＬＣＰチャネルすなわち、受信された着信データ構造を扱うＲＸ ＬＣＰチャネルと、完了状況キューを扱うＲＸ ＬＣＰチャネルが使用されることが好ましい。この完了状況は、アダプタ８０が、ホスト１０のソフトウェアに、ホスト１０のメモリ６０へのフレーム転送が完了したことをシグナリングするのに使用される。項目が、完了キュー構造の順次アドレスに挿入される。完了状況項目のそれぞれに、アダプタ８０によってマークされ、項目所有権がアダプタ８０からホスト１０のソフトウェアに転送されたことを検査するためにホスト１０のソフトウェアによってポーリングされるフィールドが含まれる。１つまたは複数のＲＸ ＬＣＰチャネルが、同一の完了状況キューを使用することができる。複数のＲＸ ＬＣＰチャネルによる完了状況キューの共用は、ＩＳＯＣ１２０によって実行される。
【００８０】
ＲＸ ＬＣＰチャネルは、着信パケットの宛先アドレスを示す情報を必要とする。ＩＳＯＣ１２０は、空きバッファの位置を見つけるための下記の２つのアドレッシングを有する。
直接アドレッシング・モードは、バッファをポイントするのにポインタ記述子を使用しないＬＣＰチャネルを指す。宛先アドレスは、ＩＳＯＣ１２０のマイクロコードによって定義されるか、コンテキスト１４０から読み取られる。
間接アドレッシング・モードは、記述子構造内でデータ・バッファへのポインタを維持するＬＣＰチャネルを指す。記述子は、ホスト１０のメモリ６０内に配置されることが好ましい。
【００８１】
直接アドレッシングでは、アダプタ８０を介する着信パケットの処理の待ち時間が、実質的に短縮される。しかし、直接アドレッシングでは、アダプタ８０での仮想アドレスから物理アドレスへの変換情報の保管を含めて、ＬＣＰマネージャ１３０によるメモリ・バッファの登録が必要である。ホスト１０のソフトウェアは、チャネル・ドアベルに書き込んで、チャネルによって使用可能な空きバッファに追加されるワード数を示す。直接モードでは、下記のステップを使用して、宛先バッファのアドレスを判定する。
Ａ．アドレスＡが、ＬＣＰエンジンへのコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、宛先バッファの基底アドレスになる。
【００８２】
間接モードでは、アダプタ８０が、記述子を使用して、データ・バッファのアドレスを見つける。記述子は、ホスト１０のソフトウェアによって管理される。記述子は、ホスト１０のメモリ６０に配置されることが好ましい。用語「間接」は、アダプタ８０が、宛先アドレスを定義するために追加情報を読み取ることを強調するのに使用される。アダプタ８０は、実行時中にこの情報にアクセスする。間接アドレッシングでは、変換テーブルを保管するのに必要なアダプタ８０のメモリの量が削減される。記述子は、通常は、ホスト１０のメモリ６０に配置される。間接モードでは、宛先バッファのアドレスを判定するのに、下記のステップが使用される。
Ａ．アドレスＡが、ＬＣＰエンジンに対するコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、ポインタ記述子のアドレスになる。
Ｄ．バッファへのポインタすなわちアドレスＢを、記述子から読み取る。
Ｅ．（任意選択）アドレスＢをアドレスＢ’にマッピングする。
Ｆ．アドレスＢ’（ステップＥが実行される場合）またはＢ（ステップＥが実行されない場合）が、宛先バッファの基底アドレスになる。
【００８３】
各ＲＸ ＬＣＰチャネルでは、下記のデータ構造が使用される。
メモリ・マッピングされたアドレスとして実施される、ドアベルへのアクセスによって、追加データについてまたはアダプタ８０がパケット・データを書き込むのに使用可能な記述子について、アダプタ８０が知らされる。
アダプタ８０のメモリ・サブシステム２１０内のＬＣＰコンテキスト項目に、ＬＣＰ属性、状況、構成、および状況フィールドが含まれる。
間接モードで使用されるメモリ・バッファをポイントする記述子。
ホスト１０のメモリ６０内の連続する仮想アドレス空間内のバッファ。
アドレス・マッピング用の、アダプタ８０のメモリ空間２１０内の変換テーブルおよび保護ブロック。
【００８４】
パケットの受信のフローは、下記の特性に依存する。
直接または間接の、アドレッシング・モード。
間接モードについて、記述子がホスト１０のメモリ６０内に配置される。
直接モードについて、アドレス・マッピングを、記述子へのアクセス中に使用してもしなくてもよい。
アドレス・マッピングを、バッファへのアクセス中に使用してもしなくてもよい。
間接モードについて、アドレス保護を、記述子へのアクセス中に使用してもしなくてもよい。
アドレス保護を、バッファへのアクセス中に使用してもしなくてもよい。
【００８５】
これらの特性は、ＬＣＰチャネルごとに、ＬＣＰチャネル初期化中にチャネルのコンテキスト１４０の一部としてセットされる。
【００８６】
図１５を参照すると、パケット受信のフローに、ステップ１３００での、受信されたデータ用の空きバッファ１３２０の、ホスト１０内のソフトウェア１３１０による準備が含まれる。ステップ１３３０で、間接モードで、ホスト１０のソフトウェア１３１０が、記述子１３４０を更新する。記述子１３４０は、ホスト１０のメモリ６０に配置される。ステップ１３５０で、ホスト１０のソフトウェアが、ドアベルを鳴らして、空きバッファ空間についてアダプタ８０に通知する。間接モードでは、ドアベルが、新しい記述子１３４０を示す情報を提供する。直接モードでは、ドアベルが、追加された空きバッファ空間を示す情報を提供する。この段階で、アダプタ８０は、ネットワーク３０からホスト１０のメモリ６０に受信データを転送する準備ができている。ステップ１３００、１３３０、および１３５０は、ホスト１０のソフトウェア１３１０が、ＲＸ ＬＣＰチャネルに空きバッファ１３２０を追加する時に、必ず繰り返される。ＩＳＯＣ１２０は、受信されたパケットごとに下記のステップを繰り返す。ステップ１３６０で、アダプタ８０が、データを受信する。ステップ１３７０で、間接モードで、アダプタ８０が、空きデータ・バッファ１３２０の位置をポイントする記述子１３４０を読み取る。ステップ１３８０で、データおよびヘッダが、データ・バッファ１３２０に書き込まれる。ステップ１３９０で、状況が、完了キュー内で更新される。
【００８７】
図１６を参照すると、受信ＬＣＰチャネル・フローの例で、ポインタ記述子が使用されない。さらに、変換テーブルが使用されない。データ・バッファ１４００で、バッファ１４００を使用するホスト１０内のソフトウェアの物理アドレス空間の連続する空間が使用される。ヘッダおよびデータ・ペイロードの両方が、バッファ１４００に書き込まれる。ドアベルへの書込トランザクション１４１０によって、アダプタ８０による使用のために使用可能なデータ空間が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。受信／完了ＬＣＰコンテキスト１４０に、新しいデータ／完了項目の書込に使用される次／現在のアドレスへの、バッファ１４００の先頭へのポインタ１４２０とオフセット１４３０が含まれる。アダプタ８０は、パケットを受信する時に、次のパケット位置へのオフセット１４３０を増分し、使用可能なデータ空間を更新する。完了項目１４４０が、フレーム受信の完了時、フレーム・タイムアウト時、またはＬＣＰクライアント１００が知ることを必要とする他のフレーム・イベントについて、完了ＬＣＰ１４５０に追加される。完了項目１４４０には、ＬＣＰデータ・バッファ１４００内でフレームを突き止めるためにＬＣＰクライアント１００が必要とするすべての情報が含まれる。ホスト１０のソフトウェアは、完了項目１４４０内のフィールドを使用して、完了項目１４４０の所有権を与えられていることを認識する。
【００８８】
ＩＳＯＣ１２０は、アダプタ８０のメモリ・サブシステム２１０とホスト１０のメモリ６０の間でデータを移動するのにＬＣＰチャネルを使用できるようにする。ホスト１０のメモリ６０からアダプタ８０にデータを転送するために、送信チャネルが使用される。アダプタ８０からホスト１０のメモリ６０にデータを転送するために、受信チャネルが使用される。データが、ホスト１０のメモリ６０からアダプタ８０に転送される時に、フレーム記述子に、ＩＳＯＣ１２０のバス３９０での宛先アドレスが含まれる。このアドレスによって、フレーム・データ・ペイロードの宛先が定義される。パケット・ヘッダは、通常の形で転送される。これによって、ＩＳＯＣ１２０のメモリ空間へのテーブルおよびコードのロードが可能になる。ＩＳＯＣ１２０のメモリ空間からホスト１０のメモリ６０に受信チャネルを介してデータを転送するために、記述子が、ＲＸプロセッサ１６０によって開始される。この記述子には、ホスト１０のメモリ６０での宛先アドレスとソース・アドレスの両方を示す情報が含まれる。
【００８９】
図１７を参照すると、前に示したように、ＩＳＯＣ１２０に、ＲＸロジック１５００およびＴＸロジック１５１０が含まれる。ＲＸロジック１５００には、割込みを扱う複数のレジスタ１５２０から１５４０が含まれる。同様に、ＴＸロジック１５１０に、割込みを扱う複数のレジスタ１５５０から１５７０が含まれる。ＴＸロジック１５１０のレジスタ１５５０から１５７０には、状況レジスタ１５７０、プロセッサ割込みマスク・レジスタ１５６０、およびホスト割込みレジスタ１５５０が含まれる。ＲＸロジック１５００のレジスタ１５２０から１５４０にも、状況レジスタ１５４０、プロセッサ割込みマスク・レジスタ１５３０、およびホスト割込みレジスタ１５２０が含まれる。ＴＸロジック１５１０およびＲＸロジック１５００のレジスタは、類似する構成で接続される。ＩＳＯＣレベル割込み１５８０は、ホスト・コンピュータ・システム１０に向けられる割込みである。割込み信号線１５８０には、対応するマスク・レジスタ１５６０および１５３０によってマスクされない、状況レジスタ１５７０および１５４０のビットの論理ＯＲが含まれる。これらの割込みは、ＬＣＰ動作完了１５９０、ＴＸプロセッサ１５０からの呼出し、ＲＸプロセッサ１６０からの呼出し、ＴＸロジック１５１０によって検出されたイベント、およびＲＸロジックによって検出されたイベントというソースで発する。ＴＸプロセッサ１５０およびＲＸプロセッサ１６０からの呼出しは、それぞれ、ＴＸ呼出しレジスタおよびＲＸ呼出しレジスタへの書込によって生成される。ＴＸロジック１５１０内で、マスク・レジスタ１５６０は、対応する状況レジスタ１５４０からＴＸプロセッサ１５０への割込みの通過を制御し、マスク・レジスタ１５５０は、ホスト１０への割込みの通過を制御する。同様に、ＲＸロジック１５００内で、マスク・レジスタ１５３０は、対応する状況レジスタ１５４０からＲＸプロセッサ１６０への割込みの通過を制御し、マスク・レジスタ１５２０は、ホスト１０への割込みの通過を制御する。この配置によって、ホスト１０が、ＩＳＯＣ１２０でのイベントによって生成されるすべての可能な割込みに肯定応答できるようになる。この配置を使用して、ＩＳＯＣ１２０のマイクロコードが、たとえばタスクがマイクロコードによって扱われるのに複雑すぎるので、またはマイクロコードがエラー発生の時にクラッシュしていたので、イベントを扱うことができると期待されない場合に、エラーについてホスト１０に割り込むことができる。この配置は、マイクロコードのガードとしてホスト１０を呼び出すのにも使用することができる。この場合に、マイクロコードは、報告されるエラーまたはイベントの後に処置を講ずる責任を負う。マイクロコードは、例外の処理に続いて、ホスト１０に完了指示を返す。ＴＸプロセッサ１５０への割込みは、状況レジスタ１５７０のマスクされないビットの論理ＯＲとして生成される。この状況レジスタは、割込みの原因の完全な詳細を定義するのではない、第１レベル割込みレジスタである。ＴＸプロセッサ１５０は、第２レベル割込みレジスタから割込みの原因を読み取る。割込みは、第２レベル割込みレジスタのクリア・アドレスに書き込むことによってクリアされる。ＴＸプロセッサ１５０への割込みは、ホスト１０のソフトウェアからの呼出し、ＲＸプロセッサ１６０からの呼出し、およびＴＸロジック１５１０によって検出されたイベントというソースから発する。同様に、ＲＸプロセッサ１６０への割込みは、状況レジスタ１５４０内のマスクされないビットの論理ＯＲとして生成される。この状況レジスタは、割込みの原因の完全な詳細を定義するのではない、第１レベル割込みレジスタである。ＲＸプロセッサ１６０は、第２レベル割込みレジスタから割込みの原因を読み取る。割込みは、第２レベル割込みレジスタのクリア・アドレスに書き込むことによってクリアされる。ＲＸプロセッサ１６０への割込みは、ホスト１０のソフトウェアからの呼出し、ＴＸプロセッサ１５０からの呼出し、およびＲＸロジック１５００によって検出されたイベントというソースから発する。
【００９０】
本発明のいくつかの実施形態では、ＴＸプロセッサ１５０が、さらに、送信パスと受信パスの間で共用されるロジックによって報告されるエラーを処理する責任を負うことができる。他の実施形態では、ＲＸプロセッサ１６０が、共用されるロジックからのそのようなエラーを処理する責任を負うことができる。
【００９１】
本発明の好ましい実施形態では、ＬＣＰ割込み１５９０が、ホスト１０のソフトウェアに対する処理負担を減らすために、前処理される。ＬＣＰ割込み情報を、ホスト１０のメモリ６０に書き込んで、ＩＳＯＣ１２０による繰り返されるアクセスからソフトウェア待ち時間を減らす。各ＬＣＰチャネルによる新しい割込み指示の生成は、前のチャネル割込みの処理が完了するまで延期される。ＬＣＰ割込みの処理を、これから、図１８に関して詳細に説明する。
【００９２】
図１８を参照すると、ＩＳＯＣ１２０とホスト１０の間の割込みフローに、ステップ１６００で、送信方向のソフトウェア・アプリケーション１６１０、または受信方向のＲＸプロセッサ１６０のいずれかが、割込みが要求される記述子１６２０のCompletionEventRequestビットをセットすることが含まれる。記述子１６２０は、記述子キュー１６３０に保管される。ステップ１６４０で、記述子の処理が完了したならば、完了イベント指示１６５０が、ＩＳＯＣ１２０の割込みコントローラによって、ＩＳＯＣ１２０内の割込みＦＩＦＯバッファ１６６０に送られる。EventMaskビットが、ＬＣＰコンテキスト１４０内でセットされる。完了イベント指示は、割込みＦＩＦＯ１６６０でキューに入れられる。ステップ１６７０で、事前設定条件が満たされる時に、割込み制御ブロック（ＩＣＢ）１６８０が、割込みＦＩＦＯ１６６０に保管された情報から、ＩＳＯＣ１２０によって生成される。事前設定条件は、すぐに説明する。ステップ１６９０で、ＩＣＢ１６８０が、ホスト１０のメモリ６０に転送される。ＩＳＯＣ１２０からのＩＣＢ１６８０は、ホスト１０のメモリ６０内のラップされるキュー１７００に保管される。ステップ１７１０で、ホスト１０のソフトウェア内の割込みハンドラ１７２０が、ＩＣＢ１６８０を読み取る。ステップ１７３０で、割込みハンドラ１７２０が、ＩＣＢ１６８０からの完了イベント１６５０をアプリケーション１６１０に送る。ステップ１７５０で、アプリケーション１６１０が、ＬＣＰチャネルのドアベル・レジスタにClearEventMaskビットを書き込んで、チャネルからの割込みをイネーブルする。
【００９３】
アクティブＬＣＰチャネルは、動作中に１つまたは複数の完了イベント１６５０を生成することができる。完了イベント１６５０は、CompletionEventRequestビットがセットされている記述子１６２０の処理が完了した時に生成される。完了イベントに続くＩＳＯＣ１２０の動作は、コンテキスト１４０内のEventMaskビットおよびCompletionEventビットの値に応じて変化する。EventMaskビットがクリアされている場合には、指示が、ＩＳＯＣ１２０の割込みコントローラに送られ、EventMaskビットが、ＩＳＯＣ１２０によってセットされる。EventMaskがセットされており、チャネルのコンテキスト１４０内のCompletionEventビットがクリアされている場合には、指示は割込みコントローラに転送されず、CompletionEventビットが、ＩＳＯＣ１２０によってセットされる。チャネルのコンテキスト１４０内のEventMaskビットおよびCompletionEventビットの両方がセットされている場合には、処置は講じられない。EventMaskビットは、チャネル初期化でクリアされる。このビットは、ClearEventMaskビットが、ドアベル・レジスタを介してチャネルのコンテキスト１４０に書き込まれた後にもクリアされる。チャネルのコンテキスト１４０のCompletionEventがセットされ、マスク・ビットが、ドアベル・レジスタのClearEventMaskビットによってクリアされている場合には、イベント完了の指示が、割込みコントローラに送られ、CompletionEventビットがクリアされる。完了イベントは、割込みコントローラによってＦＩＦＯ１６６０でログに記録される。ＦＩＦＯ１６６０内の各項目に、イベントを生成するＬＣＰチャネルの番号を記述するフィールドが含まれる。
【００９４】
ＩＣＢ１６８０は、ＩＳＯＣ１２０によって専用ＬＣＰチャネルを介してホスト１０のメモリ６０に転送されるデータ構造である。図１９を参照すると、ＩＣＢには、ヘッダ部分とペイロード部分が含まれる。ヘッダ部分には、ワード０に、ＩＣＢ１６８０を識別するＩＣＢインデックスを含む状況ワードと、ペイロード部分の番号割込みを示すＬＣＰ割込み有効カウントと、時刻（ＴＯＤ）スタンプが含まれる。ＩＣＢ１６８０の残りは、ペイロード部分に当てられる。ペイロード部分には、それぞれが完了イベントを示したＬＣＰチャネルの識別を含む複数のフィールドが含まれる。図１９に示された例では、各フィールドが２バイト長であり、ＩＣＢ１６８０内に２８個のフィールドがある。しかし、本発明の他の実施形態で、フィールド・サイズ、またはＩＣＢのサイズ、あるいはその両方を異なるものにすることができることを諒解されたい。
【００９５】
ＩＣＢ１６８０は、ＤＭＡ動作を介してホスト１０のメモリ６０に転送される。ＩＣＢ ＤＭＡは、下記のイベントのいずれかによって開始される。
ＦＩＦＯ１６６０に、少なくとも所定の最小数のイベント完了指示があり、所定の最小時間期間が経過した。
ＩＣＢ１６８０に少なくとも１つのイベントがあり、所定の最大時間期間が経過した。
割込みＦＩＦＯ１６６０バッファが満杯である。
【００９６】
ＩＣＢ１６８０は、割込みレシーバＬＣＰチャネルのコンテキスト１４０によって現在ポイントされている、ホストのメモリ６０内の位置にコピーされる。ＩＣＢ書込動作が完了する時に、ＩＳＯＣ１２０は、その割込みレジスタのＬＣＰ完了ビットをアサートする。ＬＣＰ完了ビットのアサートによって、マスク可能な割込みが生成される。ＬＣＰ完了ビットは、ＩＳＯＣ１２０の割込みレジスタからのホスト読取によってクリアされる。ＩＣＢ１６８０をＩＳＯＣ１２０からホスト１０のメモリ６０に移動するＩＣＢ ＬＣＰチャネルは、他のＬＣＰ受信チャネルと同様に振る舞う。具体的に言うと、ＩＣＢ ＬＣＰチャネルに関連するコンテキスト１４０およびバッファが、ＬＣＰマネージャ１３０によって開始され、ＩＣＢ ＬＣＰチャネルによって使用されるバッファを、他の受信ＬＣＰチャネルと同一のフォーマットにすることができ、ホスト１０のソフトウェアとＩＳＯＣの間の同期化が、チャネルに関連するドアベル・レジスタを介して新しい空き空間ワードまたはバッファ記述子をセットすることによって実行される。本発明のいくつかの実施形態では、ＩＣＢチャネルは、ＩＣＢチャネルがＩＣＢ割込み方式を使用しないこと、このチャネルに対する動作（記述子の処理または新しいＩＣＢ１６８０のホスト１０のメモリ６０への移動）の完了によって、割込みを生成できること、およびチャネルが、ＩＳＯＣ１２０内のプロセッサではなく、ＩＳＯＣ１２０内のロジックを介して管理されることにおいて、他のＬＣＰチャネルと異なる。
【００９７】
ホスト１０のＩＳＯＣ割込みハンドラ１７２０は、ＩＳＯＣ１２０の割込みレジスタを読み取る。割込みレジスタを読み取ることによって、ホスト１０のメモリ６０でのＩＣＢ書込動作の完了が引き起こされる。ＬＣＰ完了は、割込みチャネルの使用の代替としてＩＣＢ１６８０の次インデックスについてメモリ６０をポーリングすることによって監視することができる。これは、ＩＣＢが固定された位置を有し、したがって、次ＩＣＢの位置が既知になるからである。割込みハンドラ１７４０は、アプリケーション１６１０を呼び出し、このアプリケーション１６１０が、完了イベント１６５０を示したチャネルのそれぞれを処理する。ホスト１０でのＩＣＢ処理のオーバーヘッドを防ぐために、ＬＣＰチャネルは、チャネル・コンテキスト１４０のEventMaskビットがクリアされるまで、完了指示（ＩＣＢ１６８０を介する）を送る必要がない。EventMaskビットは、ドアベル書込でClearEventMaskビットをセットすることによってクリアされる。
【００９８】
上で説明した本発明の好ましい実施形態では、アダプタ８０が、バス・アーキテクチャ７０を介してホスト・コンピュータ・システム１０のＣＰＵ５０およびメモリ６０に接続される。しかし、本発明の他の実施形態では、アダプタ８０を、バス・アーキテクチャ７０とは独立にホスト・コンピュータ・システム１０に統合することができる。たとえば、本発明の他の実施形態で、アダプタ８０を、ホスト・メモリ６０に接続されたメモリ・コントローラを介してホスト・システムに統合することができる。
【００９９】
さらに、上で説明した本発明の好ましい実施形態では、アダプタ８０が、ホスト・コンピュータ・システム１０に挿入されるプラグ可能アダプタ・カードの形で実施された。しかし、本発明の他の実施形態で、アダプタ８０の異なる実施形態が可能であることを諒解されたい。たとえば、アダプタ８０を、ＣＰＵ５０およびメモリ６０と共に、ホスト・コンピュータ・システムのマザー・ボード上に配置することができる。
【図面の簡単な説明】
【０１００】
【図１】データ処理ネットワークの例のブロック図である。
【図２】データ処理ネットワークのネットワーク・インターフェース・アダプタ・カードのブロック図である。
【図３】データ・ネットワークのホスト・システムの例のブロック図である。
【図４】ネットワーク・アダプタ・カードのインテグレーテッド・システム・オン・ア・チップ（ＩＳＯＣ）の例のブロック図である。
【図５】ＩＳＯＣのもう１つのブロック図である。
【図６】ＩＳＯＣを通る情報のフローを示すＩＳＯＣのブロック図である。
【図７】ＩＳＯＣを通る論理送信パスのブロック図である。
【図８】ＩＳＯＣを通る論理受信パスのブロック図である。
【図９】循環記述子テーブルのブロック図である。
【図１０】記述子テーブルのリンクされた組のブロック図である。
【図１１】仮想バッファおよびその物理的に対応するバッファのブロック図である。
【図１２】完了キューのブロック図である。
【図１３】ホストからネットワークへのデータの送信フローのブロック図である。
【図１４】ホストからネットワークへのデータの送信フローのもう１つのブロック図である。
【図１５】ネットワークからホストへのデータの受信フローのブロック図である。
【図１６】ネットワークからホストへのデータの受信フローのもう１つのブロック図である。
【図１７】ＩＳＯＣのもう１つのブロック図である。
【図１８】ＩＳＯＣとホスト・コンピュータ・システムの間の割込みのフローを示す図である。
【図１９】割込み制御ブロックのブロック図である。
【０００１】
本発明は、周辺デバイスからホスト・コンピュータ・システムへ割込みを転送する方法および装置に関する。
【背景技術】
【０００２】
従来のデータ処理ネットワークには、イーサネット（Ｒ）・アーキテクチャなどの中間のネットワーク・アーキテクチャによってすべてが相互接続される複数のホスト・コンピュータ・システムおよび複数の付加デバイスが含まれる。ネットワーク・アーキテクチャには、通常は、１つまたは複数のデータ通信交換機が含まれる。ホスト・コンピュータ・システムおよび付加デバイスのそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システムには、通常は、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャによって相互接続される、複数の中央処理装置およびデータ・ストレージ・メモリ・デバイスが含まれる。ネットワーク・アダプタも、ホスト・コンピュータ・システムとデータ処理ネットワーク内の他のノードの間でネットワーク・アーキテクチャを介してデータを通信するためにバス・アーキテクチャに接続される。
【発明の開示】
【発明が解決しようとする課題】
【０００３】
ホスト・コンピュータ・システムとネットワークの間の迅速なデータ通信のために、ネットワーク・アダプタとホスト・コンピュータ・システムの間の割込みの転送をできる限り効率的に促進することが望ましい。
【課題を解決するための手段】
【０００４】
本発明によれば、周辺デバイスからホスト・コンピュータ・システムに割込みを転送する装置が提供され、この装置には、周辺デバイスによって生成された割込みの指示を保管するバッファと、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送るコントローラが含まれる。バッファは、先入れ先出しメモリ・バッファを含むことが好ましい。
【０００５】
事前設定条件に、バッファが満杯であるかどうかの判定が含まれることが好ましい。事前設定条件に、少なくとも所定の複数の指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含めることができる。同様に、事前設定条件に、少なくとも１つの指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含めることができる。
【０００６】
本発明の好ましい実施形態では、制御データ・ブロックに、ＩＣＢを識別する識別子を有するヘッダ部分と、ペイロード部分に含まれる指示の数を表すカウントが含まれる。ヘッダ部分に、時刻スタンプも含めることができる。
【０００７】
本発明は、上に記載の装置を含む周辺デバイス、およびそのような周辺デバイスを含むデータ通信ネットワーク・インターフェースにも拡張される。本発明は、メモリを有するホスト処理システムと、ホスト・コンピュータ・システムとデータ通信ネットワークの間でデータを通信するデータ通信インターフェースと、データ通信インターフェースからホスト・コンピュータ・システムのメモリへの割込みのフローを制御する、上に記載された装置とを含むデータ処理システムにも拡張される。
【０００８】
もう１つの態様から本発明を見ると、周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法であって、周辺デバイスによって生成される割込みをバッファに保管することと、事前設定条件が満たされるかどうかを判定し、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、制御データ・ブロックをホスト・コンピュータ・システムに送ることとを含む方法が提供される。
【０００９】
本発明の好ましい実施形態を、例のみとして、添付図面に関してこれから説明する。
【発明を実施するための最良の形態】
【００１０】
まず図１を参照すると、本発明を実施するデータ処理ネットワークの例に、InfiniBandネットワーク・アーキテクチャ（InfiniBandはInfiniBandTrade Association社の商標である）などの中間ネットワーク・アーキテクチャ３０によって相互接続された、複数のホスト・コンピュータ・システム１０および複数の付加デバイス２０が含まれる。ネットワーク・アーキテクチャ３０には、通常は、複数のデータ通信交換機４０が含まれる。ホスト・コンピュータ・システム１０および付加デバイス２０のそれぞれが、データ処理ネットワーク内のノードを形成する。各ホスト・コンピュータ・システム１０に、ＰＣＩバス・アーキテクチャなどのバス・アーキテクチャ７０によって相互接続される、複数の中央処理装置（ＣＰＵ）５０およびメモリ６０が含まれる。ネットワーク・アダプタ８０も、ホスト・コンピュータ・システム１０と、データ処理ネットワーク内の他のノードとの間で、ネットワーク・アーキテクチャ３０を介してデータを通信するために、バス・アーキテクチャに接続される。
【００１１】
図２を参照すると、本発明の特に好ましい実施形態では、ネットワーク・アダプタ８０に、ホスト・コンピュータ・システム１０のバス・アーキテクチャ７０への取外し可能な挿入のためのエッジ・コネクタなどのコネクタを有するプラグ可能オプション・カードが含まれる。オプション・カードは、コネクタ２７０を介してバス・アーキテクチャ７０に接続可能な特定用途向け集積回路（ＡＳＩＣ）またはインテグレーテッド・システム・オン・ア・チップ（Integrated System on a Chip、ＩＳＯＣ）１２０、ＩＳＯＣ１２０に接続される１つまたは複数の第３レベル・メモリ・モジュール２５０、および、ネットワーク・アーキテクチャ３０の媒体とＩＳＯＣ１２０の間でデータを通信するためにＩＳＯＣ１２０に接続されたインターポーザ２６０を担持する。インターポーザ２６０は、ネットワーク３０への物理的接続を提供する。本発明のいくつかの実施形態では、インターポーザ２６０を、単一のＡＳＩＣ内で実施することができる。しかし、本発明の他の実施形態では、インターポーザ２６０を、複数の構成要素によって実施することができる。たとえば、ネットワーク３０に光ネットワークが含まれる場合に、インターポーザ２６０に、別の光トランシーバを駆動するリタイマ（retimer）を含めることができる。メモリ２５０は、ＳＲＡＭ、ＳＤＲＡＭ、またはその組合せによって実施することができる。他の形態のメモリも、メモリ２５０の実施に使用することができる。ＩＳＯＣ１２０には、第１および第２のメモリが含まれる。アダプタ８０のメモリ・サブシステムを、すぐに説明する。以下の説明から明らかになるように、この配置は、データ処理ネットワークで動作する分散アプリケーションの改良された性能、改良されたシステム・スケーラビリティ、ある範囲の通信プロトコルとの互換性、およびホスト・コンピュータ・システムでの減らされた処理要件を提供する。具体的に言うと、この配置では、アダプタ８０とホスト・システム１０の間の異種通信プロトコルの共存が可能になる。そのようなプロトコルは、さまざまなアプリケーションをサービスし、同一のアダプタ８０を使用し、データ構造の事前定義の組を使用することができ、これによって、ホストとアダプタ８０の間のデータ転送が機能強化される。並列にオープンすることができるアプリケーション・チャネルの数は、アダプタ８０に割り振られるメモリ・リソースの量によって決定され、アダプタに組み込まれる処理能力に依存しない。下記から、複数の構成要素を単一の集積回路チップに統合するというＩＳＯＣ１２０の概念によって、有利なことに、製造コストが最小になり、再利用可能なシステム基本構成要素が提供される。しかし、本発明の他の実施形態で、ＩＳＯＣ１２０の要素を、別個の構成要素によって実施できることも諒解されたい。
【００１２】
以下の説明では、用語「フレーム」が、ホスト・コンピュータ・システム１０で稼動するソフトウェアとアダプタ８０の間で転送されるデータ単位またはメッセージを指す。各フレームに、フレーム・ヘッダおよびデータ・ペイロードが含まれる。データ・ペイロードに、ユーザ・データ、高水準プロトコル・ヘッダ・データ、肯定応答、フロー制御、またはこれらの任意の組合せを含めることができる。フレーム・ヘッダの内容を、詳細にすぐに説明する。アダプタ８０は、フレーム・ヘッダだけを処理する。アダプタ８０は、フレームを、ネットワーク・アーキテクチャ３０でより効率的に移送される、より小さいパケットに断片化することができる。しかし、そのような断片化では、一般に、データ・ペイロードは変換されない。
【００１３】
本発明の特に好ましい実施形態では、データが、ネットワーク・アーキテクチャ３０上で、以下でパケットと称するアトミックな単位で移送される。各パケットには、経路情報と、その後のハードウェア・ヘッダ・データおよびペイロード・データが含まれる。本発明の通常の例では、１０２４バイトまでのパケット・サイズが使用される。より大きいサイズのフレームは、１０２４バイト・パケットに断片化される。本発明の他の実施形態で、異なるパケット・サイズを使用できることを諒解されたい。
【００１４】
本発明の好ましい実施形態では、アダプタ８０と、ホスト・コンピュータ・システム１０で稼動する複数のアプリケーションとの間の通信が、論理通信ポート（Logical Communication Port）アーキテクチャ（ＬＣＰ）を介してもたらされる。アダプタ８０には、異なる内部データ構造へのアクセス待ち時間の最適化を可能にするメモリ階層が含まれる。このメモリ階層を、すぐに説明する。本発明の好ましい実施形態では、アダプタ８０が、ネットワーク・アーキテクチャ３０に宛てられたアウトバウンド（ＴＸ）データとホスト・コンピュータ・システム１０に宛てられたインバウンド（ＲＸ）データに別々のパスを提供する。各パスには、それ自体のデータ転送エンジン、ヘッダ処理ロジック、およびネットワーク・アーキテクチャ・インターフェースが含まれる。これらのパスも、詳細にすぐに説明する。
【００１５】
図３を参照すると、ＬＣＰアーキテクチャによって、ホスト・コンピュータ・システム１０で稼動するローカル・コンシューマとアダプタ８０の間のインターフェースのフレームワークが定義される。そのようなコンシューマの例に、アプリケーションとスレッドの両方が含まれる。コンピュータ・システム１０を、ユーザ・アプリケーション空間９０とカーネル空間１１０に副分割することができる。ＬＣＰアーキテクチャは、各コンシューマにネットワーク・アーキテクチャ３０への論理ポートを与える。このポートには、ユーザ空間９０から直接にアクセスすることができる。本発明の特に好ましい実施形態では、ハードウェア保護機構が、アクセス許可を解決する。ＬＣＰ登録が、データ・フレームの転送の前に、カーネル空間１１０によって実行される。ＬＣＰアーキテクチャでは、通信プロトコルを定義する必要がない。そうではなく、ＬＣＰアーキテクチャでは、データおよび制御情報を転送するための、アプリケーションとアダプタ８０の間のインターフェースが定義される。その代わりに、通信プロトコルの詳細を、アプリケーションおよびアダプタ８０で実行されるプログラム・コードによってセットすることができる。アダプタ８０で使用できるチャネルの数は、ＬＣＰ関連情報に使用可能なアダプタ・カード８０上のメモリの量だけによって制限される。各ＬＣＰポートを、特定の特徴の組を有するようにプログラムすることができる。特徴の組は、特定のプロトコルに従って、ホスト・コンピュータ・システム内のメモリ６０とアダプタ８０の間でのデータ転送を最もよくサポートするように選択される。さまざまな通信プロトコルを、各プロトコルで異なるＬＣＰポートを使用して、同時にサポートすることができる。
【００１６】
ＬＣＰアーキテクチャには、ＬＣＰクライアント１００、カーネル空間１１０に常駐するＬＣＰマネージャ１３０、および、アダプタ８０に常駐する１つまたは複数のＬＣＰコンテキスト１４０が含まれる。
【００１７】
各ＬＣＰクライアント１００は、ＬＣＰポートに接続された、単一方向アプリケーション・エンド・ポイントである。ＬＣＰクライアント１００を、ユーザ・アプリケーション空間９０またはカーネル１１０内に配置することができる。動作中に、各ＬＣＰクライアント１００は、メモリ６０から読み取られ、アダプタ８０によってＴＸ ＬＣＰチャネルを介して転送されるコマンドおよびデータを作るか、アダプタ８０によってメモリ６０へＲＸ ＬＣＰチャネルを介して転送されるデータを消費する。
【００１８】
ＬＣＰマネージャ１３０は、ＬＣＰチャネルの割振りおよび割振り解除と、チャネルごとのメモリ６０内の読取／書込区域の登録の要求をサービスする、信頼される構成要素である。ＬＣＰマネージャ１３０は、他の通信動作、アプリケーション、またはホスト・コンピュータ・システム１０のオペレーティング・システムを危険にさらさずに、ユーザ空間アプリケーションが、アダプタ８０のリソースを使用できるようにする。
【００１９】
各ＬＣＰコンテキスト１４０は、特定のＬＣＰクライアント１００をサービスするのにアダプタ８０が必要とする制御情報の組である。ＬＣＰコンテキスト１４０には、可能なコマンド、ポインタ構造、およびバッファ記述子定義など、チャネルの存在全体を通じて一定のＬＣＰチャネル属性を含めることができる。ＬＣＰコンテキスト１４０には、サービスを待っているデータの量、関連するＬＣＰチャネルにアクセスするための次のアドレスなど、ＬＣＰチャネルに関する特定のＬＣＰサービス情報も含めることができる。ＬＣＰコンテキスト１４０は、アダプタ８０に常駐するメモリに保管されて、アダプタ８０があるチャネルのサービスを停止し、別のチャネルのサービスを開始する時の高速ＬＣＰコンテキスト切替が可能になっている。
【００２０】
ＬＣＰポートの開始を要求するＬＣＰクライアント１００は、ＬＣＰマネージャ１３０に頼り、ＬＣＰチャネルの割振りを要求する。ＬＣＰチャネル属性は、この時に決定され、これによって、ＬＣＰポートの挙動およびＬＣＰクライアント１００がＬＣＰポートに関連して実行を許可される動作が規定される。ＬＣＰクライアント１００は、一意の保護された形でアダプタ８０にアクセスするのに使用されるアドレスを許可される。このアドレスを、ドアベル（Doorbell）アドレスと称する。
【００２１】
ＬＣＰマネージャ１３０は、アダプタによる仮想アドレスから物理アドレスへの変換を可能にし、ユーザ空間クライアントが他のプログラムを改竄せずにこれらのホスト・メモリ区域にアクセスできるようにするために、ホスト・メモリ６０の区域を登録する責任も負う。
【００２２】
新しいバッファの登録および前のバッファの登録解除は、実行時中に各ＬＣＰクライアント１００が要求することができる。そのような変更は、ＬＣＰクライアント１００、ＬＣＰマネージャ１３０、およびアダプタ８０の間の情報交換のシーケンスを必要とする。
【００２３】
各ＬＣＰクライアント１００およびポートは、ＬＣＰポートによってコマンド実行のために送られる保留中の要求をサービスするためにアダプタ８０が必要とするすべての情報を提供するＬＣＰコンテキスト１４０に関連する。
【００２４】
ＬＣＰクライアント１００とアダプタ８０の間のメモリ転送を開始し、フレームの送信を開始するために、ＬＣＰクライアント１００は、特定の動作に関する情報を保持する記述子を用意する。ＬＣＰクライアント１００は、アダプタ８０にマッピングされたドアベル・アドレスへの入出力書込を実行する。ドアベル・アドレスに書き込むことによって、アダプタ８０のＬＣＰコンテキスト１４０が更新され、新しい要求が実行のために追加される。
【００２５】
アダプタ８０は、保留中の要求を有するさまざまな送信ＬＣＰポートの間で調停し、次にサービスされる送信ＬＣＰポートを選択する。
【００２６】
データの受信時に、受信されたパケットのフレームおよびＬＣＰが、識別される。記述子を生成して、受信されたＬＣＰに必要な動作を定義する。アダプタ８０のＬＣＰエンジンによるこれらの記述子の実行によって、着信データが、ホスト・コンピュータ・システム１０のメモリ６０内でＬＣＰチャネルに割り振られた適当なデータ・バッファに保管される。
【００２７】
サービスされるＬＣＰチャネルごとに、アダプタ８０は、関連するＬＣＰコンテキスト情報をロードし、この情報を使用して、データ転送の所望の組を実行する。その後、アダプタ８０は、次に選択されるＬＣＰコンテキスト１４０の処理に継続する。
【００２８】
図４を参照すると、前に述べたように、ＩＳＯＣ１２０に、第１メモリ空間２２０および２３０と第２メモリ空間２４０が含まれ、アダプタ８０に、さらに、第３レベル・メモリ２５０が含まれる。第１、第２、および第３のメモリは、アダプタ８０のメモリ・サブシステム２１０のために間隔を空ける。本発明の好ましい実施形態では、ＩＳＯＣ１２０に、データ送信動作専用のＴＸプロセッサ（ＴＸ ＭＰＣ）１５０と、データ受信動作専用のＲＸプロセッサ（ＲＸ ＭＰＣ）１６０が含まれる。本発明の特に好ましい実施形態では、プロセッサ１５０および１６０が、ＩＢＭ ＰｏｗｅｒＰＣ ４０５ ＲＩＳＣマイクロプロセッサなどの縮小命令セット・コンピューティング（ＲＩＳＣ）マイクロプロセッサによって実施される。メモリ・サブシステム２１０内で、ＩＳＯＣ１２０に、第１および第２のメモリ空間の他に、ＴＸプロセッサ１５０に関連するデータ・キャッシュ１８０および命令キャッシュ１７０が、ＲＸプロセッサ１６０に関連する第２データ・キャッシュ１９０および第２命令キャッシュ２００と共に含まれる。３つのレベルの間の相違は、メモリのサイズおよび関連するアクセス時間である。すぐに明らかになるように、メモリ・サブシステム２１０は、ＴＸプロセッサ１５０およびＲＸプロセッサ１６０の両方による命令およびデータへの便利なアクセスと、スケーラビリティと、削減された製造コストのためのＴＸプロセッサ１５０およびＲＸプロセッサ１６０の間のリソースの共用とを容易にする。
【００２９】
第１レベル・メモリ空間（Ｍ１）２２０および２３０に、ＴＸ−Ｍ１メモリ空間２２０およびＲＸ−Ｍ１メモリ空間２３０が含まれる。ＴＸ−Ｍ１メモリ２２０は、ＴＸプロセッサ１５０によってのみアクセスでき、ＲＸ−Ｍ１メモリ２３０は、ＲＸプロセッサ１６０によってのみアクセスできる。動作中に、第１レベル・メモリ空間２２０および２３０は、一時データ構造、ヘッダ・テンプレート、スタックなどを保持するのに使用される。第１レベル・メモリ空間２２０および２３０の両方が、０待ち状態に反応する。第１レベル・メモリ空間２２０および２３０のそれぞれは、プロセッサ１５０および１６０の対応する１つのデータ・インターフェースだけに接続され、命令インターフェースには接続されない。この配置によって、キャッシュ可能およびキャッシュ不能の両方の第１レベル・メモリ区域を使用可能にすることができるのと同時に、第１レベル・メモリ空間２２０および２３０内のデータへの効率的なアクセスを維持できるようになる。
【００３０】
第２レベル・メモリ空間（Ｍ２）２４０は、プロセッサ１５０および１６０の両方、アダプタ８０の他の構成要素、およびホスト・コンピュータ・システム１０から使用可能な共用メモリである。第２レベル・メモリ空間２４０へのアクセスは、第１レベル・メモリ区域２２０および２３０へのアクセスより低速である。というのは、第２レベル・メモリ空間２４０が、共用される内部バスを介してより多くのエージェントによって使用されるからである。第３レベル・メモリ空間２５０も、共用リソースである。本発明の特に好ましい実施形態では、アダプタ８０に、その上で第１レベル・メモリ空間２２０および２３０と第２レベル・メモリ空間２４０の両方がプロセッサ１５０および１６０と同一のＡＳＩＣに集積される、コンピュータ周辺回路カードが含まれる。共用メモリ空間２４０および２５０は、一般に、高速で頻繁なアクセス・サイクルを必要としないデータ・タイプに使用される。そのようなデータ・タイプには、ＬＣＰコンテキスト１４０および仮想アドレス変換テーブルが含まれる。この共用メモリ空間２４０および２５０は、プロセッサ１５０および１６０の命令インターフェースおよびデータ・インターフェースの両方からアクセス可能である。
【００３１】
アダプタ８０は、送信データ・フローと受信データ・フローを別々に処理する。送信パスおよび受信パスのプロセッサ１５０および１６０は、タスク間の切替のオーバーヘッドを防止し、あるパス内の一時的な処理負荷を他のパスから分離し、着信データ・ストリームおよび発信データ・ストリームの処理に２つの組込みプロセッサを使用することを促進する。図５を参照すると、ＩＳＯＣ１２０に、送信パス・ロジック２８０および受信パス・ロジック２９０と、共用ロジック３００が含まれる。送信パス・ロジック２８０には、各ＬＣＰチャネルの詳細をデコードし、ＬＣＰ関連コマンドを実行のために取り出すＬＣＰ ＴＸエンジン３１０と、アダプタ８０へのフレームの転送を制御するＴＸロジック３２０と、ＴＸフレームおよびパケット処理の管理用の前述のＴＸプロセッサ１５０と、命令および一時データ構造を保持する前述の第１レベルＴＸメモリ２２０と、リンク・ロジック３３０と、フレームのデータ・パケットへの断片化の経路指定処理などのデータ・フロー処理およびパケット処理を管理する際にＴＸプロセッサ１５０を支援するロジックとが含まれる。ＴＸプロセッサ１５０は、プロセッサが例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式に基づいてタスクを直列に処理する。第１レベルＴＸメモリ２２０は、プロセッサ１５０によって、ＴＸロジック３２０との通信に使用される。受信パス・ロジック２９０には、リンク・ロジック３４０と、着信パケットのヘッダ処理およびそのようなパケットのフレームへの変換または組立の際に前述のＲＸプロセッサ１６０を支援するハードウェアと、ＲＸフレームおよびパケット処理用の前述のＲＸプロセッサ１６０と、命令を保持する前述の第１レベルＲＸメモリ２３０と、ネットワーク・アーキテクチャ３０からのフレームの転送を制御するＲＸロジック３５０と、各ＬＣＰチャネルの詳細をデコードし、関連するＬＣＰデータ構造内の着信データをホスト・コンピュータ・システムのメモリ６０に保管し、ＬＣＰクライアント１００によってアダプタ８０による使用のために供給される時に、空フレーム・バッファへのポインタを受け入れ、登録する、ＬＣＰ ＲＸエンジン３６０とが含まれる。ＲＸプロセッサ１６０は、ＲＸプロセッサ１６０が例外およびエラーの際にのみ割り込まれる、ポーリングのみ方式を使用してタスクを直列に処理する。第１レベルＲＸメモリ２３０は、ＲＸプロセッサ１６０によって、ＲＸロジック３５０との通信に使用される。
【００３２】
前に述べたように、ＩＳＯＣ手法では、アダプタ８０および、回路ボードおよび他のサポート・モジュールなどのアダプタの他の構成要素に関連する製造コストの削減が可能になる。ＩＳＯＣ手法では、アダプタ８０の単純さも高まり、これによって信頼性が高まる。ＩＳＯＣ１２０の要素の間の接続の数は、効果的に無制限である。したがって、複数の幅広い相互接続パスを実施することができる。ホスト・コンピュータ・システム１０でのデータ処理オーバーヘッドを減らすために、ホスト・メモリ６０との間のデータ転送動作は、大部分がＩＳＯＣ１２０によって実行される。ＩＳＯＣ１２０は、着信パケットおよび発信パケットのヘッダの処理も実行する。送信中に、ＩＳＯＣ１２０は、ヘッダを作り、ネットワーク・アーキテクチャ３０に経路指定する。受信中に、アダプタ８０は、システムのメモリ内でのヘッダの位置を判定するためにヘッダを処理する。レベル１メモリ２２０および２３０は、０待ち状態メモリであり、スタック、テンプレート、テーブル、および一時保管場所などのプロセッサ・データ空間を提供する。本発明の特に好ましい実施形態では、送信パス・ロジック２８０、受信パス・ロジック２９０、および共用ロジック３００が、コアと称する、より小さい論理要素から作られる。用語コアが使用されるのは、これらの要素が、それらを異なる応用例に使用できるようにする独立型の特性を有する個々のロジックとして設計されるからである。
【００３３】
前に示したように、送信パス・ロジック２８０は、送信フレームまたは発信フレームを処理する責任を負う。フレーム送信は、バス・アーキテクチャ７０を介して、ホスト・コンピュータ・システム１０のＣＰＵ５０などのＣＰＵによって開始される。ＩＳＯＣ１２０には、バス・アーキテクチャ７０と通信するバス・インターフェース・ロジック３７０が含まれる。ＩＳＯＣ１２０には、バス・インターフェース・ロジック３７０をＩＳＯＣ１２０のプロセッサ・ローカル・バス（ＰＬＢ）３９０に接続するバス・ブリッジング・ロジック３８０も含まれる。ＬＣＰ ＴＸエンジン３１０は、コマンドおよびフレームをホスト・メモリ６０から取り出す。ＴＸプロセッサ１５０は、各フレームのヘッダを処理して、ネットワーク・アーキテクチャ３０上でパケットとして送信するのに適するフォーマットにする。ＴＸロジック３２０は、フレーム・データを修正なしで転送する。リンク・ロジック３３０は、送信される各パケットを処理して、ネットワーク・アーキテクチャ３０での送信用の最終的な形にする。リンク・ロジック３３０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。
【００３４】
前に示したように、受信パス・ロジック２９０は、着信パケットを処理する責任を負う。まず、ネットワーク・アーキテクチャ３０から受信されたパケットが、リンク・ロジック３４０によって処理される。リンク・ロジック３４０は、ヘッダおよびペイロードのフォーマットのパケットを再作成する。パケット・フォーマットおよびホスト・メモリ６０内での宛先を判定するために、ヘッダが、ＲＸプロセッサ１６０によって処理される。リンク・ロジック３４０には、それぞれがネットワーク・アーキテクチャ３０に接続可能である１つまたは複数のポートを含めることができる。ＲＸ ＬＣＰエンジンは、バス・アーキテクチャ３７０を介してデータをホスト・メモリ６０に転送する責任を負う。
【００３５】
送信パス・ロジック２８０には、ＴＸ ＬＣＰエンジン３１０とＴＸプロセッサ１５０の間のＨｅａｄｅｒＩｎ先入れ先出しメモリ（ＦＩＦＯ）４００が含まれる。受信パス・ロジックには、ＲＸプロセッサ１６０とＲＸ ＬＣＰエンジン３６０の間のＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が含まれる。追加のＦＩＦＯおよびキューを、ＴＸロジック３２０内およびＲＸロジック３５０内に設けることができる。これらのＦＩＦＯおよびキューを、すぐに説明する。
【００３６】
共用ロジック３００には、送信パス・ロジック２８０および受信パス・ロジック２９０によって共用されるすべての要素が含まれる。この要素には、前述のバス・インターフェース・ロジック３７０、バス・ブリッジング・ロジック３８０、ＰＬＢ３９０、第２レベル・メモリ２４０、およびリモート第３レベル・メモリ２５０へのアクセスを提供するコントローラ４２０が含まれる。バス・インターフェース・ロジック３７０は、バス・アーキテクチャ７０上でマスタおよびスレーブの両方として動作する。スレーブとして、バス・インターフェース・ロジックは、ＣＰＵ５０が、第２レベル・メモリ２４０に、コントローラ４２０を介して第３レベル・メモリ２５０に、および、ＩＳＯＣ１２０の構成レジスタおよび状況レジスタにもアクセスできるようにする。そのようなレジスタは、一般に、ＣＰＵ５０、ＴＸプロセッサ１５０、およびＲＸプロセッサ１６０によってアクセスすることができる。マスタとして、バス・インターフェース・ロジックは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０が、ホスト・コンピュータ・システム１０のメモリ６０にアクセスできるようにする。図５では、「Ｍ」がマスタ接続、「Ｓ」がスレーブ接続を示す。
【００３７】
図６を参照すると、ＩＳＯＣ１２０を通るパケットフローは、一般に対称である。言い換えると、フローの全般的な構造は、送信方向と受信方向の両方で類似する。ＩＳＯＣ１２０は、第１インターフェース・ロジック４４０と、第１制御ロジック４６０と、プロセッサ・ロジック４８０と、第２制御ロジック４７０と、第２インターフェース・ロジック４５０とを含むとみなすことができる。パケットは、下記の形で処理される。
【００３８】
Ａ．送信方向では、情報が、バス・アーキテクチャ７０から第１インターフェース・ロジックを介してＩＳＯＣ１２０に持ってこられる。受信方向では、情報が、ネットワーク・アーキテクチャ３０から第２インターフェース・ロジック４５０を介してＩＳＯＣ１２０に持ってこられる。
【００３９】
Ｂ．送信方向では、第１インターフェース・ロジック４４０を介してＩＳＯＣ１２０に持ってこられた情報が、第１制御ロジック４６０によって処理される。受信方向では、第２インターフェース・ロジック４５０を介してＩＳＯＣに持ってこられた情報が、第２制御ロジック４７０によって処理される。
【００４０】
Ｃ．送信方向では、フレーム・ヘッダが、第１制御ロジック４６０で発信フレームについて抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第２制御ロジック４７０用の命令を生成する。発信フレームのペイロードは、第２制御ロジック４７０に渡される。受信方向では、フレーム・ヘッダが、第２制御ロジック４７０で着信フレームから抽出され、プロセッサ・ロジック４８０によって処理される。プロセッサ・ロジック４８０は、フレーム・ヘッダに基づいて、第１制御ロジック４６０用の命令を生成する。着信フレームのペイロードは、第１制御ロジック４６０に渡される。両方の方向で、プロセッサ４８０は、ペイロード・データを直接には処理しない。
【００４１】
Ｄ．送信方向では、第２制御ロジック４７０が、プロセッサ・ロジック４８０から受け取った命令に従って発信ペイロード・データをパッケージする。受信方向では、第１制御ロジック４６０が、プロセッサ・ロジック４８０から受け取った命令に従って着信ペイロード・データをパッケージする。
【００４２】
Ｅ．送信方向では、情報が、第２インターフェース・ロジック４５０からその宛先へネットワーク・アーキテクチャ３０を介して移動される。受信方向では、情報が、第１インターフェース・ロジックからその宛先へバス・アーキテクチャ７０を介して移動される。
【００４３】
ホスト・コンピュータ・システム１０で動作するソフトウェアへのインターフェースを、４３０に示す。同様に、プロセッサの入力および出力で動作するマイクロコードへのインターフェースを、４９０および５００に示す。
【００４４】
図７を参照して、以下は、ＩＳＯＣ１２０を通る送信データ・フレームのフローの１例のより詳細な説明である。ＩＳＯＣ１２０は、ＩＳＯＣ１２０内の情報のさまざまなフォーマットに基づいて、ＬＣＰコンテキスト・ドメイン５１０、フレーム・ドメイン５２０、およびネットワーク・ドメイン５３０に分割することができる。ＴＸ ＬＣＰエンジン３１０には、ＬＣＰ要求ＦＩＦＯ５５０、直接メモリ・アクセス（ＤＭＡ）ロジック５６０、フレーム・ロジック５８０、および前述のＬＣＰコンテキスト・ロジック１４０が含まれる。ＬＣＰ要求ＦＩＦＯ５５０、ＤＭＡロジック５６０、およびＬＣＰ ＴＸコンテキスト・ロジック５９０は、ＬＣＰコンテキスト・ドメイン５１０に常駐する。フレーム・ロジック５８０は、フレーム・ドメイン５２０に常駐する。ＴＸロジック３２０、第１レベルＴＸメモリ空間２２０、およびＴＸプロセッサ１５０は、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の境界にまたがる。ＴＸリンク・ロジック３３０は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＩｎ ＦＩＦＯ４００が、第１レベルＴＸメモリ空間２２０に一体化される。一般に、ホスト・コンピュータ・システム１０で実行されるアプリケーションが、フレームを作成する。フレームは、その後、アダプタ８０のＴＸ ＬＣＰチャネルを使用して送信される。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＬＣＰサービス要求を追加するために、ＬＣＰクライアント１００が、アダプタ８０に、１つまたは複数の追加の送信フレームが実行の準備ができていることを知らせる。これは、ドアベルに制御ワードを書き込むことによって実行される。ドアベルのアドレスは、ＬＣＰポートに一意に関連し、他のプロセスによるアクセスから保護されるアドレスを使用して、書込動作が、バス・アーキテクチャ７０上での物理書込サイクルに変換される形で割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰクライアント１００の前の要求の項目を増分することによって、新しい要求をログに記録する。これは、関係するＬＣＰコンテキスト１４０の一部である。アダプタ８０のメモリ・サブシステム２１０内に保持される調停リストも、更新される。単純な例では、調停で、保留中の要求を有するすべての送信ＬＣＰチャネルの間で前述のＦＩＦＯ方式５５０が使用される。あるＬＣＰチャネルがサービスされている間に、次のＬＣＰチャネルが選択される。サービス・サイクルは、対応するＬＣＰコンテキストがＴＸ ＬＣＰエンジン３１０にロードされる時に開始される。その後、ＬＣＰコンテキスト１４０にアクセスして、ＬＣＰチャネルをサービスするアトミック・オペレーションを導出し、そのような動作のパラメータを判定する。たとえば、そのようなアトミック・オペレーションは、ＬＣＰコンテキスト１４０に記録されたＬＣＰチャネル属性に基づくものとすることができる。完全なサービス・サイクルに、通常は、ＬＣＰクライアント１００によって作成される複数のアトミックな記述子をフェッチし、実行するためにアダプタ８０によって実行されるアクティビティの組が含まれる。ＴＸ ＬＣＰチャネルの場合に、サービス・サイクルに、一般に、ホスト・メモリ６０からアダプタ８０のメモリ・サブシステム２１０に複数のフレームを読み取ることが含まれる。最後に、修正を必要とするすべてのＬＣＰコンテキスト情報（言い換えると、ＬＣＰサービス情報）が、アダプタ８０のメモリ・サブシステム２１０内で更新される。一般に、アダプタ８０によってＬＣＰサービス・サイクル内で最初に実行される動作は、次に処理される記述子を取り出すことである。
【００４５】
ＩＳＯＣ１２０による送信フレームの処理には、通常は下記のステップが含まれる。
【００４６】
Ａ．後続ＬＣＰポート・フレーム記述子の取出
次に取り出される記述子のアドレスは、ＬＣＰチャネルのコンテキスト１４０の一部として保管される。アダプタ８０は、ホスト・メモリ６０から記述子を読み取り、ＬＣＰチャネル属性に基づいてその記述子をデコードする。記述子によって、新しいフレーム・ヘッダのサイズ、データ・ペイロードのサイズ、およびこれらの項目の位置が定義される。
【００４７】
Ｂ．仮想アドレスの物理アドレスへの変換
データ・バッファが、アプリケーション内で仮想メモリ・アドレスによって参照される場合に、そのアドレスは、アドレス変換という追加処理を受けなければならない。この場合に、アプリケーションによって使用される仮想アドレスが、アダプタ８０がホスト・メモリ６０にアクセスする間にアダプタ８０によって使用可能な物理アドレスに変換される。これは、ページ境界を超えることを監視し、ＬＣＰマネージャ１３０によってアダプタ８０のメモリ・サブシステム２１０に書き込まれる物理ページ位置情報を使用することによって行われる。仮想アドレスから物理アドレスへの変換処理は、記述子テーブルが、信頼されないＬＣＰクライアント１００によって作成される場合のセキュリティ手段としても働く。これによって、ホスト・メモリ６０の無関係な区域への許可されないアクセスが防止される。
【００４８】
Ｃ．フレーム・ヘッダの読取
物理アドレッシングを使用して、ＴＸフレームのヘッダおよびペイロード・データが、ホスト・メモリ６０内のバッファから読み取られる。その後、ヘッダが、ＴＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ４００に保管される。ヘッダ取出が完了した時に、アダプタ８０は、ヘッダの処理をＴＸプロセッサ１５０によって開始できることを示す内部フラグをセットする。
【００４９】
Ｄ．フレーム・データの読取
ペイロード・データが、ホスト・メモリ６０から読み取られ、アダプタ８０によってデータＦＩＦＯ５７０に保管される。データＦＩＦＯ５７０は、図７では、ＴＸロジック３２０に常駐するものとして図示されている。しかし、データＦＩＦＯ５７０を、第１レベルＴＸメモリ空間２２０に一体化することもできる。データ読取トランザクションは、送信されるデータのすべてがアダプタ８０のメモリ・サブシステム２１０に保管されるまで継続する。読取動作の完了に続いて、状況指示が、ＬＣＰクライアント１００に返される。ヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００に読み取られてすぐに、ヘッダの処理を開始できることに留意されたい。データ全体が読み取られるのを待つ必要はない。
【００５０】
Ｅ．フレーム・ヘッダの処理
ヘッダ処理は、ＴＸプロセッサ１５０によって実行される。ヘッダ処理は、プロトコル依存であり、ＬＣＰアーキテクチャの外部のプロトコル情報が用いられる。ＴＸプロセッサ１５０は、ＴＸプロトコル・ヘッダ・マイクロコードを実行し、プロトコルおよび経路指定初期化シーケンス中にアダプタ８０のメモリ・サブシステム２１０に既に保管された経路指定テーブルおよび他の関連情報にアクセスする。ＴＸプロセッサ１５０は、新しいヘッダがＨｅａｄｅｒＩｎ ＦＩＦＯ４００内で待っていることの指示を受け取る時に、ヘッダ処理を開始する。ヘッダ処理では、ネットワーク・アーキテクチャ３０を介してパケットを送信するのに使用されるフォーマットであり、経路指定情報を含む、１つまたは複数のパケット・ヘッダが作られる。ペイロード・サイズが、ネットワーク・アーキテクチャ３０によって許容される最大パケット・サイズより大きい場合には、元のペイロード・データの連続するデータ・セグメントに関してそれぞれが使用される複数のパケット・ヘッダを生成して、ネットワーク・アーキテクチャ３０を介する通信用のパケットを形成することによって、ペイロードを断片化する。
【００５１】
Ｆ．送信用のパケット・ヘッダのキューイング
パケットのヘッダ・ワード数およびデータ・ワード数を定義するコマンドおよびパケット・ヘッダ自体が、ＴＸプロセッサ１５０によって、第１レベル・メモリ空間２２０内のＴＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０に書き込まれる。
【００５２】
Ｇ．送信用のパケット・ヘッダおよびパケット・データのマージ
ネットワーク・アーキテクチャ３０でのパケットの送信は、コマンドがＨｅａｄｅｒＯｕｔ ＦＩＦＯ５４０内で準備ができており、データＦＩＦＯ５７０に、関連するパケットの送信を完了するのに十分なデータが含まれる時に、必ずトリガされる。巡回冗長検査（ＣＲＣ）を、各パケットのヘッダおよびデータに追加することができる。各完全なパケットが、ＴＸリンク・ロジック３３０を介してネットワーク・アーキテクチャ３０に転送される。
【００５３】
各フレームの送信処理は、すべてのフレーム・データが、１つまたは複数のパケットによってネットワーク・アーキテクチャ３０で送信された時に完了する。アダプタ８０によって処理されるフレームごとに、第２のＬＣＰクライアント１００を介してアプリケーションに状況を返すことができる。この状況は、ホスト・メモリ６０からアダプタ８０へのフレーム・データ転送の完了、フレーム送信自体の完了、または他のレベルの送信状況とすることができる。
【００５４】
どの瞬間でも、アダプタ８０は、次にサービスされるＬＣＰの選択、ＬＣＰチャネルＡのサービスの開始、ＬＣＰチャネルＢの最後のフレームのデータのＤＭＡ取出の実行、ＬＣＰチャネルＣのフレーム・ヘッダの処理および断片化、ＬＣＰチャネルＤから発するパケットの送信のうちの一部またはすべてを平行に実行することができる。
【００５５】
図８を参照して、以下は、例のみとして、ＲＸ ＬＣＰポートを使用するアプリケーションによるデータ・フレーム受信の説明である。ＩＳＯＣ１２０の動作は、ＬＣＰによってサポートされるプロトコルのタイプに応じて変更することができる。アプリケーションとアダプタ８０の間のハンドシェークは、ＬＣＰマネージャ１３０によって前に実行された初期化を前提とする。ＲＸ ＬＣＰエンジン３６０には、ＬＣＰ割振りロジック６２０、ＬＣＰコンテキスト・ロジック６１０、およびＤＭＡロジック６３０が含まれ、これらのすべてが、ＬＣＰコンテキスト・ドメイン５１０に常駐する。ＲＸプロセッサ１６０、第１レベルＲＸメモリ空間２３０、およびＲＸロジック３５０のすべてが、フレーム・ドメイン５２０とネットワーク・ドメイン５３０の間の境界にまたがる。ＲＸリンク・ロジック３４０およびパケット援助ロジック６００は、ネットワーク・ドメイン５３０に常駐する。本発明の特に好ましい実施形態では、ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０が、第１レベルＲＸメモリ空間２３０内に配置される。ＩＳＯＣ１２０によってネットワーク・アーキテクチャ３０から受信されたフレームは、ホスト・メモリ６０内のＬＣＰクライアント・バッファに書き込まれる。メモリ・バッファの可用性は、ＬＣＰ ＲＸクライアント１００によって判定され、着信データ・フレームの挿入のためにアダプタ８０に示される。ＬＣＰクライアント１００は、送信される準備ができた新しいフレームについて送信パス・ロジック２８０が知らされる前に述べた形に似て、ＩＳＯＣ１２０の受信ドアベルに書き込むことによってバッファを提供する。ドアベル・レジスタ・アドレスは、書込動作がバス・アーキテクチャ７０への物理書込サイクルに変換されるように割り振られる。アダプタ８０は、書込動作を検出し、特定のＬＣＰ ＲＸクライアント１００の使用可能なワード項目の数を増分することによって、空のメモリ区域の新たな提供をログに記録する。使用可能なワード・カウントは、関係するＬＣＰコンテキスト１４０の一部である。アプリケーションは、バッファ内の受信したフレームの処理を完了する時に、必ずドアベルに書き込む。この書込サイクルによって、新たに使用可能なメモリ空間のワード数が示される。ＬＣＰコンテキスト内のカウントが、その量だけ増分される。ネットワーク・アーキテクチャ３０から受信されたパケットは、アダプタ８０によってホスト・メモリ６０内の連続する空間に組み立てられる、より大きいフレームの一部である場合がある。ＩＳＯＣ１２０による受信されたフレームの処理には、一般に、下記のステップが含まれる。
【００５６】
Ａ．パケット・ヘッダとデータの分離
ＲＸリンク・ロジック３４０は、ネットワーク・アーキテクチャ３０からの情報をパケットのストリームに変換する。受信されたパケットのそれぞれが、ＲＸリンク・ロジック３４０によって処理されて、パケット・ヘッダがペイロード・データから分離される。ヘッダは、第１レベルＲＸメモリ空間２３０内のＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０にプッシュされる。ペイロードは、ＲＸロジック３５０内のＲＸデータＦＩＦＯ６５０にプッシュされる。ＲＸデータＦＩＦＯ６５０は、第１レベルＲＸメモリ空間２３０内で実施することもできる。
【００５７】
Ｂ．パケット・ヘッダのデコードおよびＬＣＰフレーム・ヘッダの生成。
パケット・ヘッダをデコードして、パケットが属するフレームのＩＤ、ペイロードのサイズ、およびフレーム・データのサイズを示すフィールドを提供する。パケット・ヘッダが、ＲＸ ＨｅａｄｅｒＩｎ ＦＩＦＯ６４０に関するリーダーになるならば、指示が、ＲＸプロセッサ１６０に送られる。ＲＸプロセッサは、パケット・ヘッダ情報を処理し、パケット・データの転送に必要な情報を含むＬＣＰ関連コマンドを生成する。そのような情報には、パケットのアドレスおよび長さが含まれる。ヘッダ処理の終りに、記述子または記述子の組が、ＬＣＰ ＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０に書き込まれ、指示がトリガされる。
【００５８】
Ｃ．ＲＸ ＬＣＰコンテキスト内のデータの転送
記述子が、ＲＸ ＬＣＰエンジン３６０によってＲＸ ＨｅａｄｅｒＯｕｔ ＦＩＦＯ４１０から取り出され、デコードされる。記述子には、ＬＣＰ番号、パケット・アドレス、パケット・データ長、および、アダプタ８０のメモリ・サブシステム２１０に転送されるデータのソース・アドレスが含まれる。ＲＸ ＬＣＰエンジン３４０は、ＬＣＰコンテキスト情報を使用して、ホスト・メモリ６０内の書き込まれるターゲット物理アドレス（または、ページにまたがる場合には複数のアドレス）を作成し、ＤＭＡ転送を開始して、データを書き込む。
【００５９】
Ｄ．ＩＳＯＣ ＤＭＡトランザクション
ＩＳＯＣ１２０は、適当なバス・コマンドを選択し、可能な最長のバーストを実行することによって、バス・アーキテクチャ７０でのトランザクションの最適化を目指す。
【００６０】
どの瞬間でも、アダプタ８０は、ＬＣＰチャネルＸのバッファ割振りの処理、ＬＣＰチャネルＡのインバウンド・データ書込サービスの開始、ＬＣＰチャネルＢのデータのＤＭＡストアの実行、ＬＣＰチャネルＣ宛のパケットのフレーム組立の処理、およびＬＣＰチャネルＤのパケットの受信の一部またはすべてを並列に実行することができる。
【００６１】
ＲＸプロセッサ１６０およびＴＸプロセッサ１５０でのフレーム処理オーバーヘッドを最小にするために、パケット援助ロジック６００に、フレーム断片化ロジック、ＣＲＣおよびチェックサム計算ロジック、およびマルチキャスト処理ロジックが含まれる。
【００６２】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０の両方とホスト１０の間のデータ・フローを、これから詳細に説明する。ＴＸ ＬＣＰポートおよびＲＸ ＬＣＰポートの両方で、データ転送用のメモリ・バッファと、そのようなメモリ・バッファをポイントする記述子構造が使用される。記述子構造は、データ・プロバイダとデータ・コンシューマの間でデータ・バッファを管理し、データ・プロバイダによって使用される空のメモリ・バッファを返すのに使用される。記述子は、物理アドレスまたは仮想アドレスのいずれかに基づいてメモリ・バッファをポイントする。
【００６３】
ＴＸ ＬＣＰチャネルは、ホスト・メモリ６０からＩＳＯＣ１２０のバッファへのデータ転送の責任を負う。ロジックの他の層は、ＩＳＯＣ１２０のバッファからネットワーク３０にデータを転送する責任を負う。ＲＸ ＬＣＰチャネルは、ネットワーク３０から受信されたデータのホスト・メモリ６０への転送の責任を負う。
【００６４】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、比較的多数のＬＣＰチャネルを扱うことができる。各ＬＣＰチャネルは、それに固有のすべての情報を含むパラメータの組を有する。この情報には、チャネルの構成、現在の状態、および状況が含まれる。あるチャネルに関連するＬＣＰコンテキスト１４０が、チャネルの初期化中にＬＣＰマネージャ１３０によってセットされる。チャネル動作中に、ＬＣＰコンテキスト１４０の内容が、ＩＳＯＣ１２０のみによって更新される。ＬＣＰコンテキスト１４０は、アダプタ８０のメモリ・サブシステム２１０内のコンテキスト・テーブルに保管される。ＬＣＰチャネルのＬＣＰコンテキスト１４０へのアクセスは、ＬＣＰ番号に従って実行される。ＬＣＰのＲＸチャネルおよびＴＸチャネルでは、異なるＬＣＰコンテキスト構造が使用される。
【００６５】
データ・バッファは、ホスト１０のメモリ６０内のピン止めされた区域である。送信バッファには、送信用のデータが保持される。ＴＸ ＬＣＰエンジン３１０は、これらのバッファに置かれたデータをＩＳＯＣ１２０の内部バッファに移動する。ネットワーク・アーキテクチャ３０から受信される着信データは、ＲＸ ＬＣＰエンジン３６０によって、ホスト１０のメモリ６０内のバッファに移動される。バッファの所有権は、ホスト１０内のソフトウェアとＩＳＯＣ１２０の間で交番する。ＬＣＰ ＴＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ホスト１０のメモリ６０内で、送信されるデータと共にバッファを準備する。
Ｂ．ソフトウェアが、バッファ内のデータが送信の準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、バッファからデータを読み取る。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、読み取られ、新しいデータを転送するためにホスト１０のソフトウェアによって再利用することができるバッファを識別する。
【００６６】
ＬＣＰ ＲＸチャネルでのイベントの順序は、次の通りである。
Ａ．ホスト１０のソフトウェアが、ＩＳＯＣ１２０が受信されたデータを書き込むことができるバッファを準備する。
Ｂ．ソフトウェアが、空きバッファがホストのメモリ６０内で準備ができていることをＩＳＯＣ１２０に通知する。
Ｃ．ＩＳＯＣ１２０が、データをバッファに書き込む。
Ｄ．ＩＳＯＣ１２０が、ホスト１０のソフトウェアに対して、受信されたデータが書き込まれ、ソフトウェアによって処理されることができるバッファを識別する。
【００６７】
ソフトウェアが、ＩＳＯＣ１２０によって使用されるバッファを準備する時に、バッファ情報が、ドアベル・レジスタを介して追跡される。ＩＳＯＣ１２０によって使用されるバッファに関する情報は、状況更新を使用してまたは完了キューを介して、ソフトウェアに返される。ＴＸ ＬＣＰチャネルについて、バッファに、ＴＸ ＬＣＰエンジン３１０によってＩＳＯＣ１２０に転送され、処理されて、ネットワーク３０での送信用の１つまたは複数のパケットになるデータおよびヘッダの情報が含まれる。ヘッダは、ＩＳＯＣ１２０のＴＸプロセッサ１５０によって、ネットワーク３０で送信されるパケットのヘッダを生成するのに使用される。ＲＸ ＬＣＰチャネルについて、空きバッファが、ホスト１０のソフトウェアによってアダプタ８０に割り当てられる。アダプタ８０は、受信されたパケットをバッファに書き込む。
【００６８】
記述子によって、ＩＳＯＣ１２０およびホスト１０のソフトウェアの両方に既知のデータ構造が定義されている。ソフトウェアは、記述子を使用して、ＩＳＯＣ１２０に制御情報を転送する。制御情報は、所望の機能に応じて、フレーム記述子、ポインタ記述子、または分岐記述子の形とすることができる。ソフトウェア内およびＩＳＯＣ１２０内の記述子ロジックは、行われる制御手段に従って記述子を生成し、修正する。そのような手段を、すぐに説明する。フレーム記述子には、パケットの記述子（たとえば、データ長、ヘッダ長など）が含まれる。ポインタ記述子には、データ位置の記述子が含まれる。分岐記述子には、記述子位置の記述（たとえば、記述子のリンク・リスト）が含まれる。記述子内の情報は、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって実行されるデータ移動動作の、ホスト１０内のソフトウェアによる制御に使用される。ＴＸパケット・ヘッダを生成するためにフレームを処理するのに使用される情報は、フレームのヘッダに配置される。図９を参照すると、記述子を、単一のテーブル７００内に設けることができ、ＬＣＰコンテキスト１４０が、テーブル７００の先頭をポイントする。図１０を参照すると、記述子を、リンクされた記述子テーブル７２０から７４０の構造で配置することもできる。ＬＣＰチャネル初期化の後に、ＬＣＰコンテキスト１４０は、構造内の最初の記述子テーブル７２０の先頭をポイントする。分岐記述子７５０から７７０は、テーブル７２０から７４０のリンク・リストを生成するのに使用され、ここで、記述子テーブル７２０から７４０の終りの分岐記述子７５０から７７０は、別のテーブル７２０から７４０の始めをポイントする。図９に戻ると、分岐記述子は、循環バッファを生成するのにも使用することができ、ここで、テーブル７００の終りの分岐記述子７１０は、同一のテーブル７００の始めをポイントする。循環バッファは、受信パスで使用することもできる。この場合に、ＬＣＰコンテキスト１４０が、バッファの先頭をポイントするように開始される。バッファは、ＩＳＯＣ１２０がその終りに達した時に、ラップ・アラウンドされる。ホスト１０のソフトウェアは、ホスト１０のメモリ６０に（受信パスと送信パスの両方について）、またはアダプタ８０のメモリ２５０に（送信パスのみについて）記述子を書き込むことができる。アダプタ８０のメモリ・サブシステム２１０への記述子の書込には、ホスト１０のソフトウェアによる入出力動作が含まれ、アダプタ８０のメモリ・サブシステム２１０が占有される。ホスト１０のメモリ６０での記述子の書込は、アダプタ８０が、新しい記述子を読み取らなければならない時に、必ずホスト１０のメモリ６０にアクセスすることを必要とする。ソフトウェア記述子の位置は、ＬＣＰチャネルごとに独立に、ＬＣＰマネージャ１３０によって定義される。記述子の位置は、システム性能最適化に従って定義される。記述子は、キューの構成での柔軟性を提供する。
【００６９】
ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０は、記述子テーブル内の記述子にアクセスし、データ・バッファにアクセスするのに、アドレスを使用する。アドレスは、物理アドレスまたは仮想アドレスのいずれかとすることができる。用語物理アドレスは、ＩＳＯＣ１２０が、そのままでバス７０に駆動できるアドレスを指す。用語仮想アドレスは、物理アドレスではなく、ソフトウェアまたはマイクロコードによって使用されるアドレスを指す。仮想アドレスは、物理アドレスを生成するために、マッピングを受けなければならない。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるアドレスは、ＬＣＰチャネル・コンテキスト１４０内のポインタ、ホスト１０で稼動するソフトウェアによって準備される記述子内のポインタ、ＲＸプロセッサ１６０によって準備される記述子内のポインタ、およびＴＸプロセッサ１５０によって準備される記述子内のポインタ（完了メッセージを返すのに使用される）という異なるソースを有することができる。ポインタは、記述子またはデータ・バッファをポイントすることができる。ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって使用されるすべてのアドレスを、任意選択として、バス７０上の物理アドレスとして使用される新しいアドレスにマッピングすることができる。アドレス・マッピングは、ＴＸ ＬＣＰエンジン３１０およびＲＸ ＬＣＰエンジン３６０によって行われる。ＩＳＯＣ１２０は、ローカル・メモリ２１０を使用して、変換テーブルを保持する。ＬＣＰマネージャ１３０は、メモリ登録中にアダプタ８０に変換テーブルを書き込む。アドレス・マッピングによって、バッファまたは記述子テーブルに仮想アドレスを使用できるようになる。仮想アドレッシングによって、物理的に複数の物理ページに配置される仮想バッファの管理が可能になる。アドレス・マッピングによって、ホスト１０が、ソフトウェアのための変換プロセッサを必要とせずに、仮想アドレスを使用するアプリケーションを直接に扱えるようになる。
【００７０】
図１１を参照すると、この図には、ホスト１０のソフトウェアから見えるバッファ８８０のイメージ８００が示されている。ホスト１０内のメモリ６０にアクセスするのに使用される、アドレスの物理マッピング８１０も示されている。仮想ポインタが、バッファ内の位置を８２０ポイントする。この例のバッファは、ホスト１０のメモリ６０内の少数の連続しないページ８４０から８７０を占める仮想バッファである。ＬＣＰエンジン３１０および３６０は、変換テーブル８３０を介してアドレスを変換することによってマッピングを実行する。変換テーブルは、仮想バッファ８８０からマッピングされる各物理バッファ８４０から８７０の先頭への物理アドレス・ポインタを保持する。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のメモリ６０内で記述子およびデータ・バッファをマッピングする時の柔軟性が可能になる。アダプタ８０内でのアドレス・マッピングによって、ホスト１０のソフトウェアが物理アドレスへのアドレス変換を実行することを必要とせずに、仮想アドレスを使用するソフトウェア・バッファへの直接接続も可能になる。
【００７１】
アダプタ８０がホストのメモリ６０に書き込む各パケットは、それに関連する状況を有する。状況を用いると、アダプタ８０とホスト１０のソフトウェアの間の同期化が可能になる。状況は、パケットの異なる信頼性レベルを示すのに使用することができる。ＩＳＯＣ１２０は、下記の状況ライト・バックを提供する：送信ＤＭＡ完了は、ＴＸパケット内のデータがアダプタ８０に読み込まれたことを示し；信頼される送信は、ネットワーク３０でのデータ送信の完了を示すために返され；受信ＤＭＡ完了は、メモリ６０への受信データ転送の完了を示し；信頼される受信は、ネットワーク３０内の宛先ノードによる送信パケットの受信を示す。
【００７２】
ＴＸフレーム記述子には、２バイトの状況フィールドが含まれる。状況ライト・バックは、トランザクション状態が記述子にライト・バックされることを意味する。状況には、ホスト１０のソフトウェアがポーリングできる完了ビットが含まれる。ホスト１０のソフトウェアは、セットされた完了ビットを見つけた時に、そのフレーム記述子によって定義されるフレームに関連するバッファを再利用することができる。
【００７３】
完了キューは、ＲＸ ＬＣＰチャネルによって実施される。完了キューによって使用されるＬＣＰチャネルは、どのＲＸ ＬＣＰチャネルによっても実施することができる柔軟性および特性のすべてを有する。ＴＸプロセッサ１５０およびＲＸプロセッサ１６０は、状況ライト・バックを生成して、信頼される送信、信頼される受信、受信ＤＭＡ完了、または送信ＤＭＡ完了を示す。フレームに関連する異なる指示を、異なる場合に使用することができる。たとえば、信頼される送信の場合に、ＴＸプロセッサ１５０は、パケット送信の状況を示す内部レジスタを読み取る。信頼される受信の場合に、ＲＸプロセッサ１６０が、肯定応答を含む受信されたパケットとして完了指示を得る。受信ＤＭＡ完了の場合に、ＲＸプロセッサ１６０が、フレーム完了情報を使用する。送信ＤＭＡ完了の場合に、ＴＸプロセッサ１５０が、アダプタ８０での送信用フレームの受信を示す。完了キューは、単一のＴＸ ＬＣＰチャネルまたは単一のＲＸ ＬＣＰチャネルによって使用することができ、あるいは、複数のチャネルによって共用することができる。アダプタ８０のマイクロ・コードが、ＲＸ ＬＣＰエンジン３６０のコマンド・キューへのフレーム記述子を開始することによって、状況キューを更新する。図１２を参照すると、状況は、完了キュー９２０を含む完了状況ＬＣＰ９００を介してホスト１０のメモリ６０に転送される。完了キュー９２０は、連続し（物理的にまたは仮想的にのいずれか）、ホスト１０のメモリ６０内に配置される。たとえば、完了キューを、連続するバッファ内に保持することができる。完了キューの項目９３０は、固定されたサイズを有することが好ましい。各項目が、受信ＬＣＰ９１０に関連するバッファ９５０の先頭へのポインタ９４０を保持する。バッファ９５０には、完了状況に関連するパケット９６０が書き込まれる。
【００７４】
ＴＸソフトウェア／アダプタ・ハンドシェークに、ＴＸ ＬＣＰポートよび完了ＲＸ ＬＣＰポートが含まれる。各ＬＣＰ送信チャネルでは、下記のデータ構造が使用される。
メモリ・マップされたアドレスとして実施され、記述子およびデータを処理する増分要求についてアダプタ８０に知らせる、ドアベル項目。各プロセスは、ドアベル・アクセスに使用されるメモリ・マッピングされたアドレスの単一のページへの一意のアクセスを有する。
ＬＣＰ属性フィールドおよび状況フィールドを含む、アダプタ・メモリ空間２１０内のＬＣＰコンテキスト項目。
送信記述子の構造。この構造は、ホスト１０のメモリ６０内の複数の物理ページにまたがることができる。仮想アドレッシングが、記述子について使用される場合に、変換テーブルを使用して、あるページから次のページに移動する。物理アドレッシングが、記述子について使用される場合に、分岐記述子が、あるページから次のページへの移動に使用される。送信記述子には、アダプタ８０への記述子関連データのすべての転送の後に更新することができる状況フィールドが含まれる。
ポインタ記述子によってポイントされる、ホスト１０のメモリ６０内でピン止めされた送信データ・バッファ。仮想アドレッシングが、データ・バッファについて使用される場合に、変換テーブルによって、ポインタが、アダプタ８０によってホスト１０のメモリ６０にアクセスするのに使用される物理アドレスに変換される。
アダプタ・メモリ空間２１０内の変換テーブルおよび保護ブロックが、アドレス・マッピングに使用される。
【００７５】
図１３を参照すると、送信パケットのフローに、ステップ１０００で、ホスト１０のソフトウェア１０２０が、送信されるデータをバッファ１０３０に書き込むことが含まれる。ステップ１０１０で、ソフトウェア１０２０が、記述子１０４０を更新する。記述子１０４０は、ホスト１０のメモリ６０内またはアダプタ８０のメモリ・サブシステム２１０内のいずれかとすることができる。ステップ１０５０で、ソフトウェア１０２０が、ドアベルを鳴らして、新しいデータの送信の準備ができていることをアダプタ８０に通知する。ステップ１０６０で、アダプタ８０が、異なるＬＣＰチャネルからの要求の間の調停を管理する。あるチャネルが調停に勝った時に、アダプタ８０が、新しい記述子１０４０を読み取る。ステップ１０７０で、アダプタ８０が、データを読み取る。ステップ１０８０で、データが、ネットワーク３０に送信される。ステップ１０９０で、状況が、記述子１０４０内または完了キュー内で更新される。
【００７６】
ＴＸ ＬＣＰチャネルでは、データ・バッファにアクセスする時にアドレス変換を使用することができる。この場合に、データ・バッファは、複数のメモリ・ページからなる。この処理に関する限り、これらのメモリ・ページは、連続する仮想メモリ空間内にある。しかし、アダプタ８０に関する限り、これらのメモリ・ページは、連続しない物理メモリ空間内にある場合がある。完了状況構造に、送信されたフレームの状況を示す情報が含まれる。これは、別々のＬＣＰチャネルとして実施される。すべてのフレームの最初の記述子であるフレーム記述子は、フレームがアダプタ８０に転送された後に更新することができる任意選択の状況フィールドを有する。
【００７７】
図１４を参照すると、送信ＬＣＰチャネル・フローの例で、記述子１１００が、ホスト１０のメモリ６０に配置される。記述子１１００およびパケット１１２０を保管するバッファ１１１０へのアクセスは、アダプタ８０に配置される変換テーブル１１３０を介するアドレス変換を必要とする。バッファ１１１０によって、ホスト１０のソフトウェアの仮想アドレス空間内の連続するスペースが使用される。各フレーム１１２０は、２タイプの記述子すなわち、パケットに関係する情報を与えるフレーム記述子１１４０と、データ１１２０を保持するバッファ１１１０をポイントするポインタ記述子１１５０とによって記述される。各パケットに、データ・ペイロード１１７０と、同一のバッファ１１８０でそれに先行するヘッダ１１６０が含まれる。
【００７８】
ドアベルへの書込トランザクション１１９０によって、アダプタ８０による使用に使用可能なワード数１２００が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。送信ＬＣＰコンテキスト１４０には、送信されるデータを保持するバッファ１１１０の先頭へのポインタ１２１０が含まれる。ＬＣＰチャネルが、ＩＳＯＣ１２０の内部調停に勝つ時に、ＩＳＯＣ１２０は、ＬＣＰコンテキスト１４０内のポインタ１２１０に従ってＬＣＰチャネルの記述子を読み取る。ＬＣＰチャネルの記述子１１００およびバッファ１１１０の両方に関する仮想アドレスは、アダプタ８０のメモリ・サブシステム２１０内に配置される変換テーブル１１３０を使用して物理アドレスに変換される。変換テーブル１１３０は、メモリ・バッファの登録中にＬＣＰマネージャ１３０によって更新される。ＩＳＯＣ１２０は、データおよびフレーム・ヘッダをバッファ１１１０からアダプタ８０へ読み取る。フレーム・ヘッダ１１６０が、ＩＳＯＣ上でネットワーク３０のヘッダに置換される１３２０。パケット・ヘッダおよび対応するデータが、ネットワーク３０に送信される。
【００７９】
ＲＸ ＬＣＰポートは、着信データをＩＳＯＣ１２０からホスト１０で稼動するソフトウェア・アプリケーションによって使用されるメモリ６０に転送するのに使用される。ＴＸ ＬＣＰチャネルは、完全に、ホスト１０のソフトウェアによって開始される記述子を介して制御される。ＲＸ ＬＣＰチャネルでは、ホスト１０のソフトウェアおよびＩＳＯＣ１２０の両方からの記述子が使用される。ＩＳＯＣ１２０によって開始される記述子は、ＬＣＰチャネル動作を制御して、ホスト１０のメモリ６０内の受信されたフレームの宛先を定義するのに使用される。ホスト１０のソフトウェアによって開始される記述子は、バッファが変換テーブル内のマッピングを介して定義されない場合に、バッファの位置を定義するのに使用することができる。ホスト１０のソフトウェアとアダプタ８０の間のハンドシェークを実施するために、２つのＬＣＰチャネルすなわち、受信された着信データ構造を扱うＲＸ ＬＣＰチャネルと、完了状況キューを扱うＲＸ ＬＣＰチャネルが使用されることが好ましい。この完了状況は、アダプタ８０が、ホスト１０のソフトウェアに、ホスト１０のメモリ６０へのフレーム転送が完了したことをシグナリングするのに使用される。項目が、完了キュー構造の順次アドレスに挿入される。完了状況項目のそれぞれに、アダプタ８０によってマークされ、項目所有権がアダプタ８０からホスト１０のソフトウェアに転送されたことを検査するためにホスト１０のソフトウェアによってポーリングされるフィールドが含まれる。１つまたは複数のＲＸ ＬＣＰチャネルが、同一の完了状況キューを使用することができる。複数のＲＸ ＬＣＰチャネルによる完了状況キューの共用は、ＩＳＯＣ１２０によって実行される。
【００８０】
ＲＸ ＬＣＰチャネルは、着信パケットの宛先アドレスを示す情報を必要とする。ＩＳＯＣ１２０は、空きバッファの位置を見つけるための下記の２つのアドレッシングを有する。
直接アドレッシング・モードは、バッファをポイントするのにポインタ記述子を使用しないＬＣＰチャネルを指す。宛先アドレスは、ＩＳＯＣ１２０のマイクロコードによって定義されるか、コンテキスト１４０から読み取られる。
間接アドレッシング・モードは、記述子構造内でデータ・バッファへのポインタを維持するＬＣＰチャネルを指す。記述子は、ホスト１０のメモリ６０内に配置されることが好ましい。
【００８１】
直接アドレッシングでは、アダプタ８０を介する着信パケットの処理の待ち時間が、実質的に短縮される。しかし、直接アドレッシングでは、アダプタ８０での仮想アドレスから物理アドレスへの変換情報の保管を含めて、ＬＣＰマネージャ１３０によるメモリ・バッファの登録が必要である。ホスト１０のソフトウェアは、チャネル・ドアベルに書き込んで、チャネルによって使用可能な空きバッファに追加されるワード数を示す。直接モードでは、下記のステップを使用して、宛先バッファのアドレスを判定する。
Ａ．アドレスＡが、ＬＣＰエンジンへのコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、宛先バッファの基底アドレスになる。
【００８２】
間接モードでは、アダプタ８０が、記述子を使用して、データ・バッファのアドレスを見つける。記述子は、ホスト１０のソフトウェアによって管理される。記述子は、ホスト１０のメモリ６０に配置されることが好ましい。用語「間接」は、アダプタ８０が、宛先アドレスを定義するために追加情報を読み取ることを強調するのに使用される。アダプタ８０は、実行時中にこの情報にアクセスする。間接アドレッシングでは、変換テーブルを保管するのに必要なアダプタ８０のメモリの量が削減される。記述子は、通常は、ホスト１０のメモリ６０に配置される。間接モードでは、宛先バッファのアドレスを判定するのに、下記のステップが使用される。
Ａ．アドレスＡが、ＬＣＰエンジンに対するコマンドとして駆動される。
Ｂ．（任意選択）アドレスＡをアドレスＡ’にマッピングする。
Ｃ．アドレスＡ’（ステップＢが実行される場合）またはＡ（ステップＢが実行されない場合）が、ポインタ記述子のアドレスになる。
Ｄ．バッファへのポインタすなわちアドレスＢを、記述子から読み取る。
Ｅ．（任意選択）アドレスＢをアドレスＢ’にマッピングする。
Ｆ．アドレスＢ’（ステップＥが実行される場合）またはＢ（ステップＥが実行されない場合）が、宛先バッファの基底アドレスになる。
【００８３】
各ＲＸ ＬＣＰチャネルでは、下記のデータ構造が使用される。
メモリ・マッピングされたアドレスとして実施される、ドアベルへのアクセスによって、追加データについてまたはアダプタ８０がパケット・データを書き込むのに使用可能な記述子について、アダプタ８０が知らされる。
アダプタ８０のメモリ・サブシステム２１０内のＬＣＰコンテキスト項目に、ＬＣＰ属性、状況、構成、および状況フィールドが含まれる。
間接モードで使用されるメモリ・バッファをポイントする記述子。
ホスト１０のメモリ６０内の連続する仮想アドレス空間内のバッファ。
アドレス・マッピング用の、アダプタ８０のメモリ空間２１０内の変換テーブルおよび保護ブロック。
【００８４】
パケットの受信のフローは、下記の特性に依存する。
直接または間接の、アドレッシング・モード。
間接モードについて、記述子がホスト１０のメモリ６０内に配置される。
直接モードについて、アドレス・マッピングを、記述子へのアクセス中に使用してもしなくてもよい。
アドレス・マッピングを、バッファへのアクセス中に使用してもしなくてもよい。
間接モードについて、アドレス保護を、記述子へのアクセス中に使用してもしなくてもよい。
アドレス保護を、バッファへのアクセス中に使用してもしなくてもよい。
【００８５】
これらの特性は、ＬＣＰチャネルごとに、ＬＣＰチャネル初期化中にチャネルのコンテキスト１４０の一部としてセットされる。
【００８６】
図１５を参照すると、パケット受信のフローに、ステップ１３００での、受信されたデータ用の空きバッファ１３２０の、ホスト１０内のソフトウェア１３１０による準備が含まれる。ステップ１３３０で、間接モードで、ホスト１０のソフトウェア１３１０が、記述子１３４０を更新する。記述子１３４０は、ホスト１０のメモリ６０に配置される。ステップ１３５０で、ホスト１０のソフトウェアが、ドアベルを鳴らして、空きバッファ空間についてアダプタ８０に通知する。間接モードでは、ドアベルが、新しい記述子１３４０を示す情報を提供する。直接モードでは、ドアベルが、追加された空きバッファ空間を示す情報を提供する。この段階で、アダプタ８０は、ネットワーク３０からホスト１０のメモリ６０に受信データを転送する準備ができている。ステップ１３００、１３３０、および１３５０は、ホスト１０のソフトウェア１３１０が、ＲＸ ＬＣＰチャネルに空きバッファ１３２０を追加する時に、必ず繰り返される。ＩＳＯＣ１２０は、受信されたパケットごとに下記のステップを繰り返す。ステップ１３６０で、アダプタ８０が、データを受信する。ステップ１３７０で、間接モードで、アダプタ８０が、空きデータ・バッファ１３２０の位置をポイントする記述子１３４０を読み取る。ステップ１３８０で、データおよびヘッダが、データ・バッファ１３２０に書き込まれる。ステップ１３９０で、状況が、完了キュー内で更新される。
【００８７】
図１６を参照すると、受信ＬＣＰチャネル・フローの例で、ポインタ記述子が使用されない。さらに、変換テーブルが使用されない。データ・バッファ１４００で、バッファ１４００を使用するホスト１０内のソフトウェアの物理アドレス空間の連続する空間が使用される。ヘッダおよびデータ・ペイロードの両方が、バッファ１４００に書き込まれる。ドアベルへの書込トランザクション１４１０によって、アダプタ８０による使用のために使用可能なデータ空間が更新される。この情報は、ＬＣＰコンテキスト１４０に保管される。受信／完了ＬＣＰコンテキスト１４０に、新しいデータ／完了項目の書込に使用される次／現在のアドレスへの、バッファ１４００の先頭へのポインタ１４２０とオフセット１４３０が含まれる。アダプタ８０は、パケットを受信する時に、次のパケット位置へのオフセット１４３０を増分し、使用可能なデータ空間を更新する。完了項目１４４０が、フレーム受信の完了時、フレーム・タイムアウト時、またはＬＣＰクライアント１００が知ることを必要とする他のフレーム・イベントについて、完了ＬＣＰ１４５０に追加される。完了項目１４４０には、ＬＣＰデータ・バッファ１４００内でフレームを突き止めるためにＬＣＰクライアント１００が必要とするすべての情報が含まれる。ホスト１０のソフトウェアは、完了項目１４４０内のフィールドを使用して、完了項目１４４０の所有権を与えられていることを認識する。
【００８８】
ＩＳＯＣ１２０は、アダプタ８０のメモリ・サブシステム２１０とホスト１０のメモリ６０の間でデータを移動するのにＬＣＰチャネルを使用できるようにする。ホスト１０のメモリ６０からアダプタ８０にデータを転送するために、送信チャネルが使用される。アダプタ８０からホスト１０のメモリ６０にデータを転送するために、受信チャネルが使用される。データが、ホスト１０のメモリ６０からアダプタ８０に転送される時に、フレーム記述子に、ＩＳＯＣ１２０のバス３９０での宛先アドレスが含まれる。このアドレスによって、フレーム・データ・ペイロードの宛先が定義される。パケット・ヘッダは、通常の形で転送される。これによって、ＩＳＯＣ１２０のメモリ空間へのテーブルおよびコードのロードが可能になる。ＩＳＯＣ１２０のメモリ空間からホスト１０のメモリ６０に受信チャネルを介してデータを転送するために、記述子が、ＲＸプロセッサ１６０によって開始される。この記述子には、ホスト１０のメモリ６０での宛先アドレスとソース・アドレスの両方を示す情報が含まれる。
【００８９】
図１７を参照すると、前に示したように、ＩＳＯＣ１２０に、ＲＸロジック１５００およびＴＸロジック１５１０が含まれる。ＲＸロジック１５００には、割込みを扱う複数のレジスタ１５２０から１５４０が含まれる。同様に、ＴＸロジック１５１０に、割込みを扱う複数のレジスタ１５５０から１５７０が含まれる。ＴＸロジック１５１０のレジスタ１５５０から１５７０には、状況レジスタ１５７０、プロセッサ割込みマスク・レジスタ１５６０、およびホスト割込みレジスタ１５５０が含まれる。ＲＸロジック１５００のレジスタ１５２０から１５４０にも、状況レジスタ１５４０、プロセッサ割込みマスク・レジスタ１５３０、およびホスト割込みレジスタ１５２０が含まれる。ＴＸロジック１５１０およびＲＸロジック１５００のレジスタは、類似する構成で接続される。ＩＳＯＣレベル割込み１５８０は、ホスト・コンピュータ・システム１０に向けられる割込みである。割込み信号線１５８０には、対応するマスク・レジスタ１５６０および１５３０によってマスクされない、状況レジスタ１５７０および１５４０のビットの論理ＯＲが含まれる。これらの割込みは、ＬＣＰ動作完了１５９０、ＴＸプロセッサ１５０からの呼出し、ＲＸプロセッサ１６０からの呼出し、ＴＸロジック１５１０によって検出されたイベント、およびＲＸロジックによって検出されたイベントというソースで発する。ＴＸプロセッサ１５０およびＲＸプロセッサ１６０からの呼出しは、それぞれ、ＴＸ呼出しレジスタおよびＲＸ呼出しレジスタへの書込によって生成される。ＴＸロジック１５１０内で、マスク・レジスタ１５６０は、対応する状況レジスタ１５４０からＴＸプロセッサ１５０への割込みの通過を制御し、マスク・レジスタ１５５０は、ホスト１０への割込みの通過を制御する。同様に、ＲＸロジック１５００内で、マスク・レジスタ１５３０は、対応する状況レジスタ１５４０からＲＸプロセッサ１６０への割込みの通過を制御し、マスク・レジスタ１５２０は、ホスト１０への割込みの通過を制御する。この配置によって、ホスト１０が、ＩＳＯＣ１２０でのイベントによって生成されるすべての可能な割込みに肯定応答できるようになる。この配置を使用して、ＩＳＯＣ１２０のマイクロコードが、たとえばタスクがマイクロコードによって扱われるのに複雑すぎるので、またはマイクロコードがエラー発生の時にクラッシュしていたので、イベントを扱うことができると期待されない場合に、エラーについてホスト１０に割り込むことができる。この配置は、マイクロコードのガードとしてホスト１０を呼び出すのにも使用することができる。この場合に、マイクロコードは、報告されるエラーまたはイベントの後に処置を講ずる責任を負う。マイクロコードは、例外の処理に続いて、ホスト１０に完了指示を返す。ＴＸプロセッサ１５０への割込みは、状況レジスタ１５７０のマスクされないビットの論理ＯＲとして生成される。この状況レジスタは、割込みの原因の完全な詳細を定義するのではない、第１レベル割込みレジスタである。ＴＸプロセッサ１５０は、第２レベル割込みレジスタから割込みの原因を読み取る。割込みは、第２レベル割込みレジスタのクリア・アドレスに書き込むことによってクリアされる。ＴＸプロセッサ１５０への割込みは、ホスト１０のソフトウェアからの呼出し、ＲＸプロセッサ１６０からの呼出し、およびＴＸロジック１５１０によって検出されたイベントというソースから発する。同様に、ＲＸプロセッサ１６０への割込みは、状況レジスタ１５４０内のマスクされないビットの論理ＯＲとして生成される。この状況レジスタは、割込みの原因の完全な詳細を定義するのではない、第１レベル割込みレジスタである。ＲＸプロセッサ１６０は、第２レベル割込みレジスタから割込みの原因を読み取る。割込みは、第２レベル割込みレジスタのクリア・アドレスに書き込むことによってクリアされる。ＲＸプロセッサ１６０への割込みは、ホスト１０のソフトウェアからの呼出し、ＴＸプロセッサ１５０からの呼出し、およびＲＸロジック１５００によって検出されたイベントというソースから発する。
【００９０】
本発明のいくつかの実施形態では、ＴＸプロセッサ１５０が、さらに、送信パスと受信パスの間で共用されるロジックによって報告されるエラーを処理する責任を負うことができる。他の実施形態では、ＲＸプロセッサ１６０が、共用されるロジックからのそのようなエラーを処理する責任を負うことができる。
【００９１】
本発明の好ましい実施形態では、ＬＣＰ割込み１５９０が、ホスト１０のソフトウェアに対する処理負担を減らすために、前処理される。ＬＣＰ割込み情報を、ホスト１０のメモリ６０に書き込んで、ＩＳＯＣ１２０による繰り返されるアクセスからソフトウェア待ち時間を減らす。各ＬＣＰチャネルによる新しい割込み指示の生成は、前のチャネル割込みの処理が完了するまで延期される。ＬＣＰ割込みの処理を、これから、図１８に関して詳細に説明する。
【００９２】
図１８を参照すると、ＩＳＯＣ１２０とホスト１０の間の割込みフローに、ステップ１６００で、送信方向のソフトウェア・アプリケーション１６１０、または受信方向のＲＸプロセッサ１６０のいずれかが、割込みが要求される記述子１６２０のCompletionEventRequestビットをセットすることが含まれる。記述子１６２０は、記述子キュー１６３０に保管される。ステップ１６４０で、記述子の処理が完了したならば、完了イベント指示１６５０が、ＩＳＯＣ１２０の割込みコントローラによって、ＩＳＯＣ１２０内の割込みＦＩＦＯバッファ１６６０に送られる。EventMaskビットが、ＬＣＰコンテキスト１４０内でセットされる。完了イベント指示は、割込みＦＩＦＯ１６６０でキューに入れられる。ステップ１６７０で、事前設定条件が満たされる時に、割込み制御ブロック（ＩＣＢ）１６８０が、割込みＦＩＦＯ１６６０に保管された情報から、ＩＳＯＣ１２０によって生成される。事前設定条件は、すぐに説明する。ステップ１６９０で、ＩＣＢ１６８０が、ホスト１０のメモリ６０に転送される。ＩＳＯＣ１２０からのＩＣＢ１６８０は、ホスト１０のメモリ６０内のラップされるキュー１７００に保管される。ステップ１７１０で、ホスト１０のソフトウェア内の割込みハンドラ１７２０が、ＩＣＢ１６８０を読み取る。ステップ１７３０で、割込みハンドラ１７２０が、ＩＣＢ１６８０からの完了イベント１６５０をアプリケーション１６１０に送る。ステップ１７５０で、アプリケーション１６１０が、ＬＣＰチャネルのドアベル・レジスタにClearEventMaskビットを書き込んで、チャネルからの割込みをイネーブルする。
【００９３】
アクティブＬＣＰチャネルは、動作中に１つまたは複数の完了イベント１６５０を生成することができる。完了イベント１６５０は、CompletionEventRequestビットがセットされている記述子１６２０の処理が完了した時に生成される。完了イベントに続くＩＳＯＣ１２０の動作は、コンテキスト１４０内のEventMaskビットおよびCompletionEventビットの値に応じて変化する。EventMaskビットがクリアされている場合には、指示が、ＩＳＯＣ１２０の割込みコントローラに送られ、EventMaskビットが、ＩＳＯＣ１２０によってセットされる。EventMaskがセットされており、チャネルのコンテキスト１４０内のCompletionEventビットがクリアされている場合には、指示は割込みコントローラに転送されず、CompletionEventビットが、ＩＳＯＣ１２０によってセットされる。チャネルのコンテキスト１４０内のEventMaskビットおよびCompletionEventビットの両方がセットされている場合には、処置は講じられない。EventMaskビットは、チャネル初期化でクリアされる。このビットは、ClearEventMaskビットが、ドアベル・レジスタを介してチャネルのコンテキスト１４０に書き込まれた後にもクリアされる。チャネルのコンテキスト１４０のCompletionEventがセットされ、マスク・ビットが、ドアベル・レジスタのClearEventMaskビットによってクリアされている場合には、イベント完了の指示が、割込みコントローラに送られ、CompletionEventビットがクリアされる。完了イベントは、割込みコントローラによってＦＩＦＯ１６６０でログに記録される。ＦＩＦＯ１６６０内の各項目に、イベントを生成するＬＣＰチャネルの番号を記述するフィールドが含まれる。
【００９４】
ＩＣＢ１６８０は、ＩＳＯＣ１２０によって専用ＬＣＰチャネルを介してホスト１０のメモリ６０に転送されるデータ構造である。図１９を参照すると、ＩＣＢには、ヘッダ部分とペイロード部分が含まれる。ヘッダ部分には、ワード０に、ＩＣＢ１６８０を識別するＩＣＢインデックスを含む状況ワードと、ペイロード部分の番号割込みを示すＬＣＰ割込み有効カウントと、時刻（ＴＯＤ）スタンプが含まれる。ＩＣＢ１６８０の残りは、ペイロード部分に当てられる。ペイロード部分には、それぞれが完了イベントを示したＬＣＰチャネルの識別を含む複数のフィールドが含まれる。図１９に示された例では、各フィールドが２バイト長であり、ＩＣＢ１６８０内に２８個のフィールドがある。しかし、本発明の他の実施形態で、フィールド・サイズ、またはＩＣＢのサイズ、あるいはその両方を異なるものにすることができることを諒解されたい。
【００９５】
ＩＣＢ１６８０は、ＤＭＡ動作を介してホスト１０のメモリ６０に転送される。ＩＣＢ ＤＭＡは、下記のイベントのいずれかによって開始される。
ＦＩＦＯ１６６０に、少なくとも所定の最小数のイベント完了指示があり、所定の最小時間期間が経過した。
ＩＣＢ１６８０に少なくとも１つのイベントがあり、所定の最大時間期間が経過した。
割込みＦＩＦＯ１６６０バッファが満杯である。
【００９６】
ＩＣＢ１６８０は、割込みレシーバＬＣＰチャネルのコンテキスト１４０によって現在ポイントされている、ホストのメモリ６０内の位置にコピーされる。ＩＣＢ書込動作が完了する時に、ＩＳＯＣ１２０は、その割込みレジスタのＬＣＰ完了ビットをアサートする。ＬＣＰ完了ビットのアサートによって、マスク可能な割込みが生成される。ＬＣＰ完了ビットは、ＩＳＯＣ１２０の割込みレジスタからのホスト読取によってクリアされる。ＩＣＢ１６８０をＩＳＯＣ１２０からホスト１０のメモリ６０に移動するＩＣＢ ＬＣＰチャネルは、他のＬＣＰ受信チャネルと同様に振る舞う。具体的に言うと、ＩＣＢ ＬＣＰチャネルに関連するコンテキスト１４０およびバッファが、ＬＣＰマネージャ１３０によって開始され、ＩＣＢ ＬＣＰチャネルによって使用されるバッファを、他の受信ＬＣＰチャネルと同一のフォーマットにすることができ、ホスト１０のソフトウェアとＩＳＯＣの間の同期化が、チャネルに関連するドアベル・レジスタを介して新しい空き空間ワードまたはバッファ記述子をセットすることによって実行される。本発明のいくつかの実施形態では、ＩＣＢチャネルは、ＩＣＢチャネルがＩＣＢ割込み方式を使用しないこと、このチャネルに対する動作（記述子の処理または新しいＩＣＢ１６８０のホスト１０のメモリ６０への移動）の完了によって、割込みを生成できること、およびチャネルが、ＩＳＯＣ１２０内のプロセッサではなく、ＩＳＯＣ１２０内のロジックを介して管理されることにおいて、他のＬＣＰチャネルと異なる。
【００９７】
ホスト１０のＩＳＯＣ割込みハンドラ１７２０は、ＩＳＯＣ１２０の割込みレジスタを読み取る。割込みレジスタを読み取ることによって、ホスト１０のメモリ６０でのＩＣＢ書込動作の完了が引き起こされる。ＬＣＰ完了は、割込みチャネルの使用の代替としてＩＣＢ１６８０の次インデックスについてメモリ６０をポーリングすることによって監視することができる。これは、ＩＣＢが固定された位置を有し、したがって、次ＩＣＢの位置が既知になるからである。割込みハンドラ１７４０は、アプリケーション１６１０を呼び出し、このアプリケーション１６１０が、完了イベント１６５０を示したチャネルのそれぞれを処理する。ホスト１０でのＩＣＢ処理のオーバーヘッドを防ぐために、ＬＣＰチャネルは、チャネル・コンテキスト１４０のEventMaskビットがクリアされるまで、完了指示（ＩＣＢ１６８０を介する）を送る必要がない。EventMaskビットは、ドアベル書込でClearEventMaskビットをセットすることによってクリアされる。
【００９８】
上で説明した本発明の好ましい実施形態では、アダプタ８０が、バス・アーキテクチャ７０を介してホスト・コンピュータ・システム１０のＣＰＵ５０およびメモリ６０に接続される。しかし、本発明の他の実施形態では、アダプタ８０を、バス・アーキテクチャ７０とは独立にホスト・コンピュータ・システム１０に統合することができる。たとえば、本発明の他の実施形態で、アダプタ８０を、ホスト・メモリ６０に接続されたメモリ・コントローラを介してホスト・システムに統合することができる。
【００９９】
さらに、上で説明した本発明の好ましい実施形態では、アダプタ８０が、ホスト・コンピュータ・システム１０に挿入されるプラグ可能アダプタ・カードの形で実施された。しかし、本発明の他の実施形態で、アダプタ８０の異なる実施形態が可能であることを諒解されたい。たとえば、アダプタ８０を、ＣＰＵ５０およびメモリ６０と共に、ホスト・コンピュータ・システムのマザー・ボード上に配置することができる。
【図面の簡単な説明】
【０１００】
【図１】データ処理ネットワークの例のブロック図である。
【図２】データ処理ネットワークのネットワーク・インターフェース・アダプタ・カードのブロック図である。
【図３】データ・ネットワークのホスト・システムの例のブロック図である。
【図４】ネットワーク・アダプタ・カードのインテグレーテッド・システム・オン・ア・チップ（ＩＳＯＣ）の例のブロック図である。
【図５】ＩＳＯＣのもう１つのブロック図である。
【図６】ＩＳＯＣを通る情報のフローを示すＩＳＯＣのブロック図である。
【図７】ＩＳＯＣを通る論理送信パスのブロック図である。
【図８】ＩＳＯＣを通る論理受信パスのブロック図である。
【図９】循環記述子テーブルのブロック図である。
【図１０】記述子テーブルのリンクされた組のブロック図である。
【図１１】仮想バッファおよびその物理的に対応するバッファのブロック図である。
【図１２】完了キューのブロック図である。
【図１３】ホストからネットワークへのデータの送信フローのブロック図である。
【図１４】ホストからネットワークへのデータの送信フローのもう１つのブロック図である。
【図１５】ネットワークからホストへのデータの受信フローのブロック図である。
【図１６】ネットワークからホストへのデータの受信フローのもう１つのブロック図である。
【図１７】ＩＳＯＣのもう１つのブロック図である。
【図１８】ＩＳＯＣとホスト・コンピュータ・システムの間の割込みのフローを示す図である。
【図１９】割込み制御ブロックのブロック図である。
Claims (16)
- 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する装置であって、装置が、周辺デバイスによって生成される割込みの指示を保管するバッファと、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、ホスト・コンピュータ・システムに制御データ・ブロックを送るコントローラとを有する、装置。
- 事前設定条件が、バッファが満杯であることの判定を含む、請求項１に記載の装置。
- 事前設定条件が、少なくとも所定の複数の指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含む、請求項１に記載の装置。
- 事前設定条件が、少なくとも１つの指示がバッファに保管されていることと、所定の期間が経過したこととの判定を含む、請求項１に記載の装置。
- 制御データ・ブロックが、ＩＣＢを識別する識別子を含むヘッダ部分と、ペイロード部分に含まれる指示の数を示すカウントとを含む、請求項１ないし４のいずれかに記載の装置。
- ヘッダ部分が、時刻スタンプを含む、請求項１ないし５のいずれかに記載の装置。
- バッファが、先入れ先出しメモリ・バッファを含む、請求項１ないし６のいずれかに記載の装置。
- 請求項１ないし７のいずれかに記載の装置を含む周辺デバイス。
- 請求項８に記載の周辺デバイスを含むデータ通信ネットワーク・インターフェース。
- データ処理システムであって、メモリを有するホスト処理システムと、ホスト・コンピュータ・システムとデータ通信ネットワークとの間でデータを通信するデータ通信インターフェースと、データ通信インターフェースからホスト・コンピュータ・システムのメモリへの割込みのフローを制御する、請求項１ないし６のいずれかに記載の装置とを含む、データ処理システム。
- 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法であって、周辺デバイスによって生成された割込みをバッファに保管することと、事前設定条件が満たされるかどうかを判定し、事前設定条件が満たされることに応答して、ペイロード部分を有する制御データ・ブロックを生成し、バッファの内容を制御データ・ブロックのペイロード部分に移動し、ホスト・コンピュータ・システムに制御データ・ブロックを送ることとを含む方法。
- 事前設定条件が満たされるかどうかを判定することが、バッファが満杯であるかどうかの判定を含む、請求項１１に記載の方法。
- 事前設定条件が満たされるかどうかを判定することが、少なくとも所定の複数の指示がバッファに保管されているかどうかと、所定の期間が経過したかどうかとの判定を含む、請求項１１に記載の方法。
- 事前設定条件が満たされるかどうかを判定することが、少なくとも１つの指示がバッファに保管されているかどうかと、所定の期間が経過したかどうかとの判定を含む、請求項１１に記載の方法。
- 制御データ・ブロックが、ＩＣＢを識別する識別子を含むヘッダ部分と、ペイロード部分に含まれる指示の数を示すカウントとを含む、請求項１１ないし１４のいずれかに記載の方法。
- バッファが、先入れ先出しメモリ・バッファを含む、請求項１１ないし１５のいずれかに記載の方法。
Applications Claiming Priority (1)
| Application Number | Priority Date | Filing Date | Title |
|---|---|---|---|
| PCT/IB2001/000121 WO2002061590A1 (en) | 2001-01-31 | 2001-01-31 | Method and apparatus for transferring interrupts from a peripheral device to a host computer system |
Publications (2)
| Publication Number | Publication Date |
|---|---|
| JP2004520646A true JP2004520646A (ja) | 2004-07-08 |
| JP4317365B2 JP4317365B2 (ja) | 2009-08-19 |
Family
ID=11004036
Family Applications (1)
| Application Number | Title | Priority Date | Filing Date |
|---|---|---|---|
| JP2002561693A Expired - Fee Related JP4317365B2 (ja) | 2001-01-31 | 2001-01-31 | 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法および装置 |
Country Status (10)
| Country | Link |
|---|---|
| US (1) | US20040054822A1 (ja) |
| EP (1) | EP1358561A1 (ja) |
| JP (1) | JP4317365B2 (ja) |
| KR (1) | KR100640515B1 (ja) |
| CN (1) | CN1256681C (ja) |
| CA (1) | CA2432386A1 (ja) |
| CZ (1) | CZ20032079A3 (ja) |
| HU (1) | HUP0302843A3 (ja) |
| PL (1) | PL363432A1 (ja) |
| WO (1) | WO2002061590A1 (ja) |
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009237987A (ja) * | 2008-03-27 | 2009-10-15 | Toshiba Corp | タイマ制御装置、タイマ制御システム、タイマ制御方法およびタイマ制御プログラム |
| JP2010072915A (ja) * | 2008-09-18 | 2010-04-02 | Hitachi Industrial Equipment Systems Co Ltd | 割込制御装置、割込制御システム、割込制御方法および割込制御プログラム |
| JP2011180653A (ja) * | 2010-02-26 | 2011-09-15 | Oki Joho Systems:Kk | データ転送装置およびデータ転送方法 |
Families Citing this family (21)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| CN1312600C (zh) * | 2003-07-09 | 2007-04-25 | 明基电通股份有限公司 | 用于减少对处理器的中断次数的控制装置及方法 |
| US7342934B1 (en) * | 2004-03-29 | 2008-03-11 | Sun Microsystems, Inc. | System and method for interleaving infiniband sends and RDMA read responses in a single receive queue |
| US7058738B2 (en) * | 2004-04-28 | 2006-06-06 | Microsoft Corporation | Configurable PCI express switch which allows multiple CPUs to be connected to multiple I/O devices |
| US7721033B2 (en) * | 2004-12-03 | 2010-05-18 | Emulex Design & Manufacturing Corporation | Interrupt notification block |
| CN100369021C (zh) * | 2004-12-31 | 2008-02-13 | 英业达股份有限公司 | 计算机外设操作事件响应处理方法及*** |
| CN100557586C (zh) * | 2005-06-01 | 2009-11-04 | 索尼株式会社 | 信息处理装置和信息处理方法 |
| US7675931B1 (en) * | 2005-11-08 | 2010-03-09 | Altera Corporation | Methods and apparatus for controlling multiple master/slave connections |
| US7676192B1 (en) * | 2005-12-21 | 2010-03-09 | Radio Shack, Corp. | Radio scanner programmed from frequency database and method |
| US7639561B2 (en) * | 2006-03-30 | 2009-12-29 | Silicon Image, Inc. | Multi-port memory device having variable port speeds |
| US9032100B2 (en) * | 2008-04-03 | 2015-05-12 | International Business Machines Corporation | I/O hub-supported atomic I/O operations |
| US8700819B2 (en) * | 2011-03-09 | 2014-04-15 | Apple Inc. | Host device suspending communication link to client device based on client device notification |
| CN102123158A (zh) * | 2011-04-11 | 2011-07-13 | 深圳市同洲软件有限公司 | 一种实现网络数据处理的方法和*** |
| US8364854B2 (en) * | 2011-06-01 | 2013-01-29 | International Business Machines Corporation | Fibre channel input/output data routing system and method |
| GB2497528B (en) * | 2011-12-12 | 2020-04-22 | Nordic Semiconductor Asa | Peripheral communication |
| US9542345B2 (en) * | 2012-09-28 | 2017-01-10 | Apple Inc. | Interrupt suppression strategy |
| US8880756B1 (en) * | 2013-07-01 | 2014-11-04 | Atmel Corporation | Direct memory access controller |
| US9246592B2 (en) * | 2013-08-19 | 2016-01-26 | International Business Machines Corporation | Structured substrate for optical fiber alignment |
| US10095891B2 (en) * | 2015-06-08 | 2018-10-09 | Nuvoton Technology Corporation | Secure access to peripheral devices over a bus |
| CN108197046A (zh) * | 2017-12-30 | 2018-06-22 | 盛科网络（苏州）有限公司 | 一种实现原子操作的***及方法 |
| US11269803B1 (en) * | 2020-12-01 | 2022-03-08 | Quanta Computer Inc. | Method and system for processor interposer to expansion devices |
| CN113342721B (zh) * | 2021-07-06 | 2022-09-23 | 无锡众星微***技术有限公司 | 存储控制器dma设计方法 |
Family Cites Families (26)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| US4493021A (en) * | 1981-04-03 | 1985-01-08 | The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration | Multicomputer communication system |
| US5185864A (en) * | 1989-06-16 | 1993-02-09 | International Business Machines Corporation | Interrupt handling for a computing system with logical devices and interrupt reset |
| EP0414651A1 (en) * | 1989-08-14 | 1991-02-27 | International Business Machines Corporation | Prolog interrupt processing |
| US5325536A (en) * | 1989-12-07 | 1994-06-28 | Motorola, Inc. | Linking microprocessor interrupts arranged by processing requirements into separate queues into one interrupt processing routine for execution as one routine |
| JP3078000B2 (ja) * | 1990-07-24 | 2000-08-21 | 三菱電機株式会社 | 情報処理装置 |
| US5265255A (en) * | 1990-09-24 | 1993-11-23 | International Business Machines Corp. | Personal computer system with interrupt controller |
| AU9043691A (en) * | 1990-11-09 | 1992-06-11 | Ast Research, Inc. | Protected hot key function for microprocessor-based computer system |
| US5319753A (en) * | 1992-09-29 | 1994-06-07 | Zilog, Inc. | Queued interrupt mechanism with supplementary command/status/message information |
| US5481724A (en) * | 1993-04-06 | 1996-01-02 | International Business Machines Corp. | Peer to peer computer-interrupt handling |
| JPH07191899A (ja) * | 1993-12-27 | 1995-07-28 | Hitachi Ltd | ファイル転送方法、データアクセス方法およびデータ書き込み方法 |
| US5553293A (en) * | 1994-12-09 | 1996-09-03 | International Business Machines Corporation | Interprocessor interrupt processing system |
| US5630059A (en) * | 1995-02-06 | 1997-05-13 | International Business Machines Corporation | Expedited message transfer in a multi-nodal data processing system |
| FR2737590B1 (fr) * | 1995-08-03 | 1997-10-17 | Sgs Thomson Microelectronics | Dispositif de gestion d'interruptions |
| US5708814A (en) * | 1995-11-21 | 1998-01-13 | Microsoft Corporation | Method and apparatus for reducing the rate of interrupts by generating a single interrupt for a group of events |
| US5606703A (en) * | 1995-12-06 | 1997-02-25 | International Business Machines Corporation | Interrupt protocol system and method using priority-arranged queues of interrupt status block control data structures |
| US5742791A (en) * | 1996-02-14 | 1998-04-21 | Advanced Micro Devices, Inc. | Apparatus for detecting updates to instructions which are within an instruction processing pipeline of a microprocessor |
| US6070219A (en) * | 1996-10-09 | 2000-05-30 | Intel Corporation | Hierarchical interrupt structure for event notification on multi-virtual circuit network interface controller |
| US6122700A (en) * | 1997-06-26 | 2000-09-19 | Ncr Corporation | Apparatus and method for reducing interrupt density in computer systems by storing one or more interrupt events received at a first device in a memory and issuing an interrupt upon occurrence of a first predefined event |
| US6430183B1 (en) * | 1997-09-18 | 2002-08-06 | International Business Machines Corporation | Data transmission system based upon orthogonal data stream mapping |
| US5968158A (en) * | 1997-10-06 | 1999-10-19 | International Business Machines Corporation | Apparatus including a host processor and communications adapters interconnected with a bus, with improved transfer of interrupts between the adapters and host processor |
| US6178180B1 (en) * | 1997-11-26 | 2001-01-23 | International Business Machines Corp. | Communications adapter for processing ATM and ISDN data |
| US6765685B1 (en) * | 1999-01-22 | 2004-07-20 | Ricoh Company, Ltd. | Printing electronic documents with automatically interleaved separation sheets |
| US6715099B1 (en) * | 1999-06-02 | 2004-03-30 | Nortel Networks Limited | High-availability architecture using high-speed pipes |
| US6493772B1 (en) * | 1999-08-23 | 2002-12-10 | International Business Machines Corporation | System and method with guaranteed maximum command response time |
| EP1221099A4 (en) * | 1999-09-08 | 2003-04-02 | Mellanox Technologies Ltd | REMOTE EVENT MANAGEMENT IN A PACKET SWITCHED NETWORK |
| US6618779B1 (en) * | 2000-05-30 | 2003-09-09 | Intel Corporation | Method and apparatus for chaining interrupt service routines |
-
2001
- 2001-01-31 CN CNB018224040A patent/CN1256681C/zh not_active Expired - Fee Related
- 2001-01-31 EP EP01273593A patent/EP1358561A1/en not_active Withdrawn
- 2001-01-31 HU HU0302843A patent/HUP0302843A3/hu unknown
- 2001-01-31 JP JP2002561693A patent/JP4317365B2/ja not_active Expired - Fee Related
- 2001-01-31 KR KR1020037009849A patent/KR100640515B1/ko not_active IP Right Cessation
- 2001-01-31 PL PL01363432A patent/PL363432A1/xx unknown
- 2001-01-31 CA CA002432386A patent/CA2432386A1/en not_active Abandoned
- 2001-01-31 WO PCT/IB2001/000121 patent/WO2002061590A1/en active Application Filing
- 2001-01-31 CZ CZ20032079A patent/CZ20032079A3/cs unknown
-
2003
- 2003-07-15 US US10/619,989 patent/US20040054822A1/en not_active Abandoned
Cited By (3)
| Publication number | Priority date | Publication date | Assignee | Title |
|---|---|---|---|---|
| JP2009237987A (ja) * | 2008-03-27 | 2009-10-15 | Toshiba Corp | タイマ制御装置、タイマ制御システム、タイマ制御方法およびタイマ制御プログラム |
| JP2010072915A (ja) * | 2008-09-18 | 2010-04-02 | Hitachi Industrial Equipment Systems Co Ltd | 割込制御装置、割込制御システム、割込制御方法および割込制御プログラム |
| JP2011180653A (ja) * | 2010-02-26 | 2011-09-15 | Oki Joho Systems:Kk | データ転送装置およびデータ転送方法 |
Also Published As
| Publication number | Publication date |
|---|---|
| JP4317365B2 (ja) | 2009-08-19 |
| PL363432A1 (en) | 2004-11-15 |
| WO2002061590A1 (en) | 2002-08-08 |
| KR20040012716A (ko) | 2004-02-11 |
| KR100640515B1 (ko) | 2006-10-30 |
| US20040054822A1 (en) | 2004-03-18 |
| HUP0302843A3 (en) | 2004-08-30 |
| CZ20032079A3 (cs) | 2003-12-17 |
| HUP0302843A2 (hu) | 2003-12-29 |
| EP1358561A1 (en) | 2003-11-05 |
| CA2432386A1 (en) | 2002-08-08 |
| CN1507591A (zh) | 2004-06-23 |
| CN1256681C (zh) | 2006-05-17 |
Similar Documents
| Publication | Publication Date | Title |
|---|---|---|
| JP4755390B2 (ja) | メモリを介してデータ処理システムの間でデータのフローを制御する方法および装置 | |
| JP4755391B2 (ja) | メモリを介してデータ処理システムの間でデータのフローを制御する方法および装置 | |
| JP4317365B2 (ja) | 周辺デバイスからホスト・コンピュータ・システムに割込みを転送する方法および装置 | |
| US6622193B1 (en) | Method and apparatus for synchronizing interrupts in a message passing queue oriented bus system | |
| US7076569B1 (en) | Embedded channel adapter having transport layer configured for prioritizing selection of work descriptors based on respective virtual lane priorities | |
| KR100555394B1 (ko) | Ｎｇｉｏ/ｉｎｆｉｎｉｂａｎｄ 어플리케이션용 리모트 키검증을 위한 방법 및 메커니즘 | |
| US7126952B2 (en) | Multiprotocol decapsulation/encapsulation control structure and packet protocol conversion method | |
| US6611883B1 (en) | Method and apparatus for implementing PCI DMA speculative prefetching in a message passing queue oriented bus system | |
| US8423675B2 (en) | Data transfer, synchronising applications, and low latency networks | |
| WO2004001615A1 (en) | A network device driver architecture | |
| GB2349717A (en) | Low latency network | |
| US6816889B1 (en) | Assignment of dual port memory banks for a CPU and a host channel adapter in an InfiniBand computing node | |
| US20020049875A1 (en) | Data communications interfaces | |
| US20020049878A1 (en) | Data communications interfaces | |
| Liaaen et al. | Dolphin SCI Adapter Cards. | |
| Lindenstruth et al. | 10. SCI Physical Layer API | |
| Lindenstruth et al. | SCI physical layer API | |
| Kaufmann et al. | Bachelor’s Thesis Nr. 36b |
Legal Events
| Date | Code | Title | Description |
|---|---|---|---|
| A977 | Report on retrieval |
Free format text: JAPANESE INTERMEDIATE CODE: A971007 Effective date: 20060427 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20060516 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20060814 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060814 |
|
| RD12 | Notification of acceptance of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7432 Effective date: 20060814 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20060815 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20070315 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20070613 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20070613 |
|
| A131 | Notification of reasons for refusal |
Free format text: JAPANESE INTERMEDIATE CODE: A131 Effective date: 20080407 |
|
| A521 | Request for written amendment filed |
Free format text: JAPANESE INTERMEDIATE CODE: A523 Effective date: 20080702 Free format text: JAPANESE INTERMEDIATE CODE: A821 Effective date: 20080702 |
|
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20081216 |
|
| TRDD | Decision of grant or rejection written | ||
| RD14 | Notification of resignation of power of sub attorney |
Free format text: JAPANESE INTERMEDIATE CODE: A7434 Effective date: 20090508 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 Effective date: 20090508 |
|
| A01 | Written decision to grant a patent or to grant a registration (utility model) |
Free format text: JAPANESE INTERMEDIATE CODE: A01 |
|
| A61 | First payment of annual fees (during grant procedure) |
Free format text: JAPANESE INTERMEDIATE CODE: A61 Effective date: 20090522 |
|
| R150 | Certificate of patent or registration of utility model |
Free format text: JAPANESE INTERMEDIATE CODE: R150 |
|
| FPAY | Renewal fee payment (event date is renewal date of database) |
Free format text: PAYMENT UNTIL: 20120529 Year of fee payment: 3 |
|
| LAPS | Cancellation because of no payment of annual fees |