JP2013538389A - Ｘｆｒ＿ｒｄｙの動的なイネーブリングおよびディセーブリングのための方法、コンピュータ・プログラム、およびシステム（ｘｆｒ＿ｒｄｙの動的なイネーブリングおよびディセーブリング） - Google Patents

Abstract

【課題】 ＸＦＲ＿ＲＤＹの使用を動的にイネーブリングおよびディセーブリングするための方法を提供する。
【解決手段】 本発明の一実施形態では、こうした方法は、ターゲットで書き込みコマンドを受信すること、および書き込みコマンドに対してＸＦＲ＿ＲＤＹがイネーブルまたはディセーブルであるかどうかを決定することを含む。ＸＦＲ＿ＲＤＹがディセーブルである場合、この方法は、ターゲットで１つまたは複数のバッファが使用可能であるかどうかを決定する。少なくとも１つのバッファが使用可能である場合、この方法は、書き込みコマンドに関連付けられたデータを１つまたは複数のバッファに書き込むことによって、書き込みコマンドを処理する。次にこの方法は、書き込みコマンドが完了した後に、ターゲットで依然として使用可能なバッファの数を示す情報を戻す。本明細書では、対応する装置およびコンピュータ・プログラム製品も開示および請求される。
【選択図】 図５

Description

本発明は、転送準備済み（ＸＦＲ＿ＲＤＹ）（transfer-ready）イネーブル・モード（enabled mode）と転送準備済み（ＸＦＲ＿ＲＤＹ）ディセーブル・モード（disabled mode）とを動的に切り替えるための装置および方法に関する。

ファイバ・チャネル・プロトコル（ＦＣＰ）書き込み動作中、ＸＦＲ＿ＲＤＹは、ターゲット・デバイスが、ＦＣＰデータのバーストの受信準備ができた旨をＦＣＰイニシエータに通知するために、ＦＣＰターゲット・デバイスによって使用可能である。データの第１のバーストに対するＸＦＲ＿ＲＤＹの使用は、プロセス・ログイン（ＰＲＬＩ）時に２つのＦＣＰポート間で取り決め（negotiate）られる。ＦＣＰポートは、書き込み動作中、ＦＣＰデータの第１のバースト時にＸＦＲ＿ＲＤＹを使用するように、あるいは、第１のバースト時にＸＦＲ＿ＲＤＹをディセーブルするように取り決める。ＸＦＲ＿ＲＤＹがイネーブルとされた場合、ターゲット・デバイスは、ＦＣＰ書き込みコマンドを受信した後、イニシエータにＸＦＲ＿ＲＤＹメッセージを送信する前にＦＣＰデータの第１のバースト用にスペースを割り振ることになる。同様に、イニシエータは、ＸＦＲ＿ＲＤＹメッセージを受信した後に、ＦＣＰ書き込みデータのバーストを送信するのみとすることができる。ＸＦＲ＿ＲＤＹがディセーブルとされた場合、イニシエータは、ターゲット・デバイスがデータの第１のバーストを受信するために常にｘバイトのデータを使用できるものと想定し、イニシエータは、ＸＦＲ＿ＲＤＹメッセージを待つことなく、ＦＣＰデータの直後に書き込みコマンドを送信することになる。ＸＦＲ＿ＲＤＹがイネーブルされずに動作することは、長距離を介したデータ複製などの待ち時間に縛られた応用例にとって、特に有益である。

現在のファイバ・チャネル・ポートは、通常、少なくとも４Ｋ、およびデータの各バーストに対して６４Ｋの、同時ファイバ・チャネル交換をサポートする。これらの値を想定すると、ＸＦＲ＿ＲＤＹのディセーブルをサポートするＦＣＰデバイスは、データの第１のバーストを受信するために１ポートあたり少なくとも６４Ｋ×４Ｋ＝２５６ＭＢの使用可能なメモリを有していなければならない。これは、特に、現在のストレージ・コントローラが１２８ポート以上をサポートしている可能性があり、これがデータの第１のバースト向けに予約される３２ＧＢ（２５６ＭＢ×１２８ポート）のメモリに変換されることを考えると、大量のメモリである。すべてのストレージ・コントローラが、ＸＦＲ＿ＲＤＹがディセーブルなデータの第１のバーストを受信するために、この大量のメモリの予約に使用可能なリソースを有するわけではない。データの第１のバーストを受信するために使用可能な十分なバッファ・スペースを保証することなく、ＸＦＲ＿ＲＤＹがディセーブルな状態で動作可能な必要のあるストレージ・コントローラは、以下のオプションを有する。

第１のオプションは、ＸＦＲ＿ＲＤＹディセーブル・モードでの動作をサポートしないことである。これは、ほとんどのファイバ・チャネル・デバイスによって実装されるオプションである。しかしながらこのオプションは、書き込み性能に容認できないほどの影響を与えるため、長距離を介してデータを複製する構成などの多くの構成で実行不可能である。これは、ＸＦＲ＿ＲＤＹをディセーブルにするためには、イニシエータがデータ転送を実行する前にターゲットからのＸＦＲ＿ＲＤＹメッセージを待機する必要があるという事実によるものである。こうした遅延は、多くの構成において容認することができない。

第２のオプションは、イニシエータとターゲットとの間で限定数の交換をサポートすることである。このオプションは、加入超過（oversubscription）が一般的な競合環境では実行不可能である。ほとんどのコントローラは、各イニシエータが多数の交換を同時に送信する場合、１ポートあたり多数のイニシエータのログインをサポートする必要がある。

第３のオプションは、ＸＦＲ＿ＲＤＹディセーブル・モードでの動作をサポートすることであるが、データの第１のバーストのサイズを制限する。このオプションは、６４ＫトラックごとにＸＦＲ＿ＲＤＹメッセージを送信するように構成可能な、キャッシュ・トラック・ベース・アーキテクチャを備えたストレージ・コントローラには実行不可能である。したがって、最低６４Ｋをサポートすることが可能なバースト・サイズを有する必要がある。

第４のオプションは、ＸＦＲ＿ＲＤＹディセーブル・モードでの動作をサポートすることであるが、ＸＦＲ＿ＲＤＹがディセーブルな状態で実行可能な最大数の同時書き込み転送に対処するのに十分なバッファが存在することは保証しない。言い換えれば、ターゲット・デバイスは、使用可能なバッファ・スペースの加入超過を可能にするように構成される。このオプションは、作業負荷がすべてのリソースを必要としないという事実に依拠している。しかしながら、作業負荷が充分に大きく、物理的に使用可能であるよりも多くのバッファ・スペースが必要である場合、ターゲット・コントローラは交換を破棄するかまたは打ち切らなければならない。これはＩ／Ｏエラーにつながり、結果として性能の低下、および、ＳＡＮ内の他のデバイスへの影響を含む、そのさまざまな結果を伴う起こり得るＳＡＮ輻輳を生じさせる。

第５のオプションは、ＦＣＰポートについて、プロセス・ログイン中にＸＦＲ＿ＲＤＹのディセーブリングを取り決めることである。バッファ・スペースがあるしきい値を下回った場合、ターゲットは新規の着信する交換をドロップすること、またはホストをログアウトすること、あるいはその両方を実行するように構成される。これにより、ホストを再度ログインさせることが可能であり、その時点でＦＣＰポートはＸＦＲ＿ＲＤＹをイネーブルするように再度取り決めることができる。このオプションは、ＸＦＲ＿ＲＤＹの使用をイネーブルまたはディセーブルする前にすべてのＩ／Ｏを終結する必要があり、これによって望ましくない性能の低下を生じさせる。

上記に鑑みて、従来技術の前述の欠点を軽減する手段が求められている。

したがって本発明は、第１の態様において、ＸＦＲ＿ＲＤＹを動的にイネーブリングおよびディセーブリングするための方法を提供し、この方法は、ターゲットで書き込みコマンドを受信すること、書き込みコマンドに対してＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定すること、ＸＦＲ＿ＲＤＹがディセーブルである場合、ターゲット上で少なくとも１つのバッファが使用可能であるかどうかを決定すること、少なくとも１つのバッファが使用可能である場合、書き込みコマンドに関連付けられたデータを少なくとも１つのバッファに書き込むことによって、書き込みコマンドを処理すること、および、書き込みコマンドが完了した後に、ターゲット上で依然として使用可能なバッファの数を示す情報を戻すことを含む。

この方法は、少なくとも１つのバッファが使用可能でない場合、ターゲットで書き込みコマンドに関連付けられたデータを破棄することを、さらに含むことができる。好ましくは、データを破棄することは、書き込みコマンドが失敗し、ＸＦＲ＿ＲＤＹがイネーブルな状態で再駆動されるべきであることを示す状況を戻すことを、さらに含む。好ましくは、情報を戻すことは、この情報を書き込みコマンドのイニシエータに送信することをさらに含む。好ましくは、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドをターゲットに送信する以前に、イニシエータは、ターゲット上で依然として使用可能なバッファの数が、イニシエータが有するターゲットとの未処理の書き込みコマンドの数よりも多いかどうかを決定する。好ましくは、イニシエータが、ターゲット上で依然として使用可能なバッファの数が、イニシエータが有するターゲットとの未処理の書き込みコマンドの数よりも多いものと決定した場合、イニシエータは、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドを送信するように構成される。好ましくは、イニシエータが、ターゲット上で依然として使用可能なバッファの数が、イニシエータが有するターゲットとの未処理の書き込みコマンドの数よりも多くないものと決定した場合、イニシエータは、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを送信するように構成される。

第２の態様では、コンピュータ・システム内にロードされ、その上で実行された場合、当該コンピュータ・システムに、第１の態様に従った方法のすべてのステップを実行させるための、コンピュータ読み取り可能媒体上に格納されたコンピュータ・プログラム・コードを含む、コンピュータ・プログラムが提供される。

この第２の態様で見られる本発明は、ＸＦＲ＿ＲＤＹを動的にイネーブルおよびディセーブルするためのコンピュータ・プログラム製品の形で提供可能であり、このコンピュータ・プログラム製品は、内部にコンピュータ使用可能プログラム・コードを具体化したコンピュータ使用可能記憶媒体を含み、このコンピュータ使用可能プログラム・コードは、ターゲットで書き込みコマンドを受信するためのコンピュータ使用可能プログラム・コードと、書き込みコマンドに対してＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定するためのコンピュータ使用可能プログラム・コードと、ＸＦＲ＿ＲＤＹがディセーブルである場合、ターゲット上で少なくとも１つのバッファが使用可能であるかどうかを決定するためのコンピュータ使用可能プログラム・コードと、少なくとも１つのバッファが使用可能である場合、書き込みコマンドに関連付けられたデータを少なくとも１つのバッファに書き込むことによって書き込みコマンドを処理するためのコンピュータ使用可能プログラム・コードと、書き込みコマンドが完了した後に、ターゲット上で依然として使用可能なバッファの数を示す情報を戻すためのコンピュータ使用可能プログラム・コードとを含む。

第３の態様では、ＸＦＲ＿ＲＤＹを動的にイネーブルおよびディセーブルするためのシステムが提供され、このシステムは、書き込みコマンドを送信するためのイニシエータと、書き込みコマンドを受信し、書き込みコマンドに対してＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定するためのターゲットを備え、さらにこのターゲットは、ＸＦＲ＿ＲＤＹがディセーブルである場合、ターゲット上で少なくとも１つのバッファが使用可能であるかどうかを決定するように構成され、さらにこのターゲットは、ターゲット上で少なくとも１つのバッファが使用可能である場合、書き込みコマンドに関連付けられたデータを少なくとも１つのバッファに書き込むことによって書き込みコマンドを処理するように構成され、さらにこのターゲットは、書き込みコマンドが完了した後に、ターゲット上で依然として使用可能なバッファの数を示す情報をイニシエータに戻すようにさらに構成される。

好ましくは、さらにこのターゲットは、少なくとも１つのバッファが使用可能でない場合、書き込みコマンドに関連付けられたデータを破棄するように構成される。好ましくは、さらにこのターゲットは、データが破棄された場合、書き込みコマンドが失敗し、ＸＦＲ＿ＲＤＹがイネーブルな状態で再駆動されるべきであることを示す状況を戻すように構成される。好ましくは、さらにこのイニシエータは、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドをターゲットに送信する以前に、ターゲット上で依然として使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも多いかどうかを決定するように構成される。好ましくは、さらにこのイニシエータは、ターゲット上で依然として使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも多い場合、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドをターゲットに送信するように構成される。好ましくは、さらにこのイニシエータは、ターゲット上で依然として使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも多くない場合、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを送信するように構成される。

ある実施形態では、ＸＦＲ＿ＲＤＹを動的にイネーブリングおよびディセーブリングするための方法は、ターゲット上で使用可能なバッファの数を示す情報をターゲットから受信すること、ターゲット上で依然として使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも大きいかどうかを決定すること、ターゲット上で使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも大きい場合、ＸＦＲ＿ＲＤＹがディセーブルな状態で書き込みコマンドを送信すること、および、ターゲット上で使用可能なバッファの数が、ターゲットとの未処理の書き込みコマンドの数よりも大きくない場合、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを送信することを、含むことができる。具体化される方法は、ＸＦＲ＿ＲＤＹがディセーブルな状態で書き込みコマンドが失敗した場合、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを再駆動することを、さらに含むことができる。

したがって本発明の実施形態は、ＦＣＰ書き込み動作の最大サポート数が同時に実行できるようにする必要なしに、ＸＦＲ＿ＲＤＹがディセーブルな状態で可能な性能利得をデバイスが利用できるようにするソリューションを提供する。さらに、最小限の書き込み性能の低下でＸＦＲ＿ＲＤＹを効率的にイネーブルおよびディセーブルすることが可能なソリューションも求められている。理想的には、こうしたソリューションは、作業負荷の変化に応じて、および交換ごとに、デバイスがＸＦＲ＿ＲＤＹをイネーブルおよびディセーブルできるようにするものである。したがって本発明は、ＸＦＲ＿ＲＤＹの使用を動的にイネーブルおよびディセーブルするための装置および方法を提供するために開発されてきた。本発明の特徴および利点は、以下の説明および添付の特許請求の範囲からさらに詳細に明らかとなるか、または、以下で説明するような本発明の実践によって習得することができる。

前述の内容に一致して、本明細書では、ＸＦＲ＿ＲＤＹの使用を動的にイネーブリングおよびディセーブリングするための方法が開示される。本発明の一実施形態では、こうした方法は、ターゲットで書き込みコマンドを受信すること、および、書き込みコマンドに対してＸＦＲ＿ＲＤＹがイネーブルまたはディセーブルされるかどうかを決定することを含む。ＸＦＲ＿ＲＤＹがディセーブルである場合、この方法は、ターゲットで１つまたは複数のバッファが使用可能であるかどうかを決定する。少なくとも１つのバッファが使用可能である場合、この方法は、書き込みコマンドに関連付けられたデータを１つまたは複数のバッファに書き込むことによって書き込みコマンドを処理する。次にこの方法は、書き込みコマンドが完了した後に、ターゲットで依然として使用可能なバッファの数を示す情報を戻す。

対応する装置およびコンピュータ・プログラム製品も、本明細書で開示および請求されている。

次に、本発明の好ましい実施形態について、添付の図面を参照しながら単なる例として説明する。

本発明の実施形態に従った装置および方法が実装可能なネットワーク環境の一例を示す、高水準ブロック図である。 ネットワーク・デバイス間での通信をイネーブリングするための構成要素を示す、高水準ブロック図である。 イニシエータとターゲットとの間の通信を示す、高水準ブロック図である。 ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするイニシエータによって実装される方法の、一実施形態を示す流れ図である。 ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするターゲットによって実装される方法の、一実施形態を示す流れ図である。 ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするイニシエータ内で実装可能な様々なモジュールを示す、高水準ブロック図である。 ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするターゲット内で実装可能な様々なモジュールを示す、高水準ブロック図である。

本明細書の図面内に全体として説明および例示されているように、本発明の実施形態の構成要素が多種多様な異なる構成で配置および設計可能であることが容易に理解されよう。したがって、図面内に表されたような以下の本発明の実施形態のより詳細な説明は、本発明の範囲を請求された通りに限定することを意図するものではなく、本発明に従って現在企図されている実施形態のある例を単に代表するものである。ここで説明される実施形態は、同じ部分が全般にわたって同じ番号で指定される図面を参照することにより、最も良く理解されるであろう。

当業者であれば理解されるように、本発明は、装置、システム、方法、またはコンピュータ・プログラム製品として具体化可能である。さらに本発明は、ハードウェア実施形態、ハードウェアを動作するように構成されたソフトウェア実施形態（ファームウェア、常駐ソフトウェア、マイクロコードなどを含む）、または、本明細書ではすべてを全体として「モジュール」または「システム」として呼ぶことが可能なソフトウェアおよびハードウェアの態様を組み合わせた実施形態の、形を取ることが可能である。さらに、本発明は、コンピュータ使用可能プログラム・コードが内部に格納された任意の有形な表現媒体内に具体化された、コンピュータ使用可能記憶媒体の形を取ることが可能である。

コンピュータ・プログラム製品を格納するために、１つまたは複数のコンピュータ使用可能またはコンピュータ読み取り可能記憶媒体の任意の組み合わせを使用することが可能である。コンピュータ使用可能またはコンピュータ読み取り可能記憶媒体は、たとえば、電子、磁気、光、電磁、赤外線、または半導体のシステム、装置、またはデバイスとすることが可能であるが、これらに限定されるものではない。コンピュータ読み取り可能記憶媒体のより特定な例（非網羅的リスト）は、１本または複数本のワイヤを有する電気接続、ポータブル・コンピュータ・ディスケット、ハード・ディスク、ランダム・アクセス・メモリ（ＲＡＭ）、読み取り専用メモリ（ＲＯＭ）、消去可能プログラマブル読み取り専用メモリ（ＥＰＲＯＭまたはフラッシュ・メモリ）、光ファイバ、ポータブル・コンパクト・ディスク読み取り専用メモリ（ＣＤ−ＲＯＭ）、光記憶デバイス、または磁気記憶デバイスを含むことができる。本明細書との関連において、コンピュータ使用可能またはコンピュータ読み取り可能記憶媒体は、命令実行のシステム、装置、またはデバイスによって、あるいはこれらと共に使用するためのプログラムを包含、格納、または移送することが可能な、任意の媒体とすることができる。

本発明の動作を実行するためのコンピュータ・プログラム・コードは、Ｊａｖａ、Ｓｍａｌｌｔａｌｋ、Ｃ＋＋などの、オブジェクト指向プログラミング言語、および、「Ｃ」プログラミング言語または同様のプログラミング言語などの、従来の手続き型プログラミング言語を含む、１つまたは複数のプログラミング言語の任意の組み合わせで作成可能である。本発明を実施するためのコンピュータ・プログラム・コードは、アセンブリ言語などの低水準プログラミング言語でも作成可能である。

本発明について、本発明の実施形態に従った方法、装置、システム、およびコンピュータ・プログラム製品の、流れ図またはブロック図あるいはその両方を参照しながら、以下で説明することができる。流れ図またはブロック図あるいはその両方の各ブロック、および、流れ図またはブロック図あるいはその両方のブロックの組み合わせが、コンピュータ・プログラム命令またはコードによって実装可能であることを理解されよう。これらのコンピュータ・プログラム命令は、機械を製造するために、汎用コンピュータ、特定用途向けコンピュータ、または他のプログラム可能データ処理装置のプロセッサに提供することが可能であり、結果として、コンピュータまたは他のプログラム可能データ処理装置のプロセッサを介して実行する命令が、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するための手段を作成する。

これらのコンピュータ・プログラム命令は、特定の様式で機能するようにコンピュータまたは他のプログラム可能データ処理装置に指示することが可能なコンピュータ読み取り可能記憶媒体内に格納することも可能であり、結果として、コンピュータ読み取り可能記憶媒体内に格納された命令が、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装する命令手段を含む製品を製造する。

コンピュータ・プログラム命令は、一連の動作ステップをコンピュータまたは他のプログラム可能装置上で実行させ、コンピュータ実装プロセスを生成するために、コンピュータまたは他のプログラム可能データ処理装置上にロードすることも可能であり、結果として、コンピュータまたは他のプログラム可能装置上で実行する命令が、流れ図またはブロック図あるいはその両方のブロック内に指定された機能／動作を実装するためのプロセスを提供する。

図１を参照すると、ネットワーク・アーキテクチャ１００の一例が示されている。ネットワーク・アーキテクチャ１００は、本発明に従った装置および方法が実装可能な環境の一例を示すために提示されている。ネットワーク・アーキテクチャ１００は単なる例として提示されており、限定的であることは意図されていない。実際に、本明細書で開示された装置および方法は、図示されたネットワーク・アーキテクチャ１００に加え、多種多様な異なるネットワーク・アーキテクチャにも適用可能である。

図に示されるように、ネットワーク・アーキテクチャ１００は、ネットワーク１０４によって相互接続された１つまたは複数のコンピュータ１０２、１０６を含む。ネットワーク１０４は、たとえばローカル・エリア・ネットワーク（ＬＡＮ）１０４、ワイド・エリア・ネットワーク（ＷＡＮ）１０４、インターネット１０４、イントラネット１０４などを含むことができる。ある実施形態では、コンピュータ１０２、１０６は、クライアント・コンピュータ１０２およびサーバ・コンピュータ１０６（本明細書では「ホスト・システム」１０６とも呼ばれる）の両方を含むことができる。一般に、クライアント・コンピュータ１０２は通信セッションを開始し、サーバ・コンピュータ１０６はクライアント・コンピュータ１０２からの要求を待機する。ある実施形態では、コンピュータ１０２またはサーバ１０６あるいはその両方は、１つまたは複数の内部または外部の直接接続記憶システム（たとえば、ハードディスク・ドライブ、ソリッドステート・ドライブ、テープ・ドライブなど）に接続可能である。これらのコンピュータ１０２、１０６および直接接続記憶システム１１２は、ＡＴＡ、ＳＡＴＡ、ＳＣＳＩ、ＳＡＳ、ファイバ・チャネルなどのプロトコルを使用して通信可能である。

ネットワーク・アーキテクチャ１００は、ある実施形態において、サーバ１０６の背後に、ストレージ・エリア・ネットワーク（ＳＡＮ）１０８またはＬＡＮ１０８（たとえば、ネットワーク接続ストレージを使用する場合）などの、記憶ネットワーク１０８を含むことができる。このネットワーク１０８は、サーバ１０６を、ハードディスク・ドライブまたはソリッドステート・ドライブのアレイ１１０ａ、テープ・ライブラリ１１０ｂ、個々のハードディスク・ドライブ１１０ｃまたはソリッドステート・ドライブ１１０ｃ、テープ・ドライブ１１０ｄ、ＣＤ−ＲＯＭライブラリなどの、１つまたは複数の記憶システム１１０に接続することができる。記憶システム１１０にアクセスするために、ホスト・システム１０６は、ホスト１０６上の１つまたは複数のポートから記憶システム１１０上の１つまたは複数のポートへ、物理接続を介して通信することができる。接続は、スイッチ、構造（fabric）、直接接続などを介することができる。ある実施形態では、サーバ１０６および記憶システム１１０は、ファイバ・チャネル（ＦＣ）などのネットワーク標準を使用して通信することができる。

図２を参照すると、各ホスト・システム１０６および記憶システム１１０は、記憶ネットワーク１０８を介して他のホスト・システム１０６および記憶システム１１０と通信するために、１つまたは複数のホスト・アダプタ２００を含むことができる。ある実施形態では、ホスト・アダプタ２００は、それぞれホスト・システム１０６および記憶システム１１０の拡張スロットにプラグインされるアダプタ・カードとして具体化されるが、これはすべての実施形態において必須ではない。ホスト・システム１０６および記憶システム１１０上のホスト・アダプタ２００は、通信を容易にするために１つまたは複数のポート２０２を含むことができる。これを説明するために、通信を（たとえばコマンドの送信によって）開始するポート２０２を「イニシエータ」と呼ぶことが可能であり、通信を受信してこれに応答するポート２０２を「ターゲット」と呼ぶことが可能である。イニシエータ３００およびターゲット３０２の一例を示す高水準ブロック図が、図３に示されている。

図３を参照すると、上記の背景セクションで論じられたように、ファイバ・チャネル・プロトコル（ＦＣＰ）書き込み動作中、ＦＣＰターゲット３０２はＸＦＲ＿ＲＤＹを使用して、ターゲット３０２がＦＣＰデータのバーストを受信するための準備済みである旨をＦＣＰイニシエータ３００に通知することができる。データの第１のバーストに対するＸＦＲ＿ＲＤＹの使用を、プロセス・ログイン（ＰＲＬＩ）時に２つのＦＣＰポート２０２間で取り決めることができる。ＦＣＰポート２０２は、書き込み動作中のＦＣＰデータの第１のバースト時にＸＦＲ＿ＲＤＹを使用するか、または、第１のバースト時にＸＦＲ＿ＲＤＹをディセーブルとするかを、取り決めることができる。ＸＦＲ＿ＲＤＹがイネーブルである場合、ＦＣＰ書き込みコマンドを受信した後、ターゲット３０２は、ＸＦＲ＿ＲＤＹメッセージをイニシエータ３００に送信する前に、ＦＣＰデータの第１のバーストに対してスペースを割り振ることになる。同様に、イニシエータ３００は、ＸＦＲ＿ＲＤＹメッセージを受信した後、ＦＣＰ書き込みデータのバーストのみを送信することができる。ＸＦＲ＿ＲＤＹがディセーブルである場合、イニシエータ３００は、ターゲット・デバイス３０２がデータの第１のバーストを受信するために使用可能なｘバイトのデータを常に有するものと想定し、イニシエータ３００は、ＸＦＲ＿ＲＤＹメッセージを待機することなく、書き込みコマンドとその直後に続く最高ｘバイトまでのＦＣＰデータとを送信することになる。

背景セクションで説明したように、ＸＦＲ＿ＲＤＹをイネーブルとしない動作は、長距離を介したデータ複製など（たとえば、ピアツーピア遠隔コピー・アプリケーション、すなわちＰＰＲＣなど）の待ち時間に縛られた構成にとって有益である。それにもかかわらず、さらに上記で論じられたように、すべての記憶コントローラが、ＸＦＲ＿ＲＤＹがディセーブルな状態でデータの第１のバーストを受信するために必要な大量のメモリを予約するために使用可能なリソースを有する訳ではない。したがって、限られた数の書き込み動作に対してディセーブルなＸＦＲ＿ＲＤＹを有することの性能利点を、デバイスが利用できるようにするソリューションが求められている。最小限の書き込み性能の低下でのＸＦＲ＿ＲＤＹの使用を動的にイネーブルおよびディセーブルためのソリューションがさらに求められている。理想的には、こうした装置および方法は、作業負荷の変化に応じて、および交換ごとに、デバイスがＸＦＲ＿ＲＤＹをイネーブルおよびディセーブルできるようにするものである。

図３は、ＸＦＲ＿ＲＤＹの使用を動的にイネーブリングおよびディセーブリングするための技法の全体概要を示す。この技法は、図４および図５に関連してより詳細に説明される。この技法は、イニシエータ３００およびターゲット３０２が、限られた数の書き込み動作に対してＸＦＲ＿ＲＤＹをディセーブリングすることに関連付けられた性能利得を利用できるようにするものである。

図３に示されるように、選択された実施形態では、イニシエータ３００は、（ＸＦＲ＿ＲＤＹがディセーブルな状態で）イニシエータが有するターゲット３０２との未処理の書き込みコマンド３０８の数を追跡するように構成することができる。未処理の書き込みコマンド３０８は、イニシエータ３００がターゲット３０２に送信したが、書き込みコマンド３０８が成功したかまたは失敗したかを示す状況３１０を依然として受信していない、書き込みコマンドを含むことができる。ある実施形態では、イニシエータ３００がターゲット３０２に送信する各書き込みコマンド３０８は、サポート・フィールド３１２およびイネーブル／ディセーブル・フィールド３１４を含むことができる。

サポート・フィールド３１２は、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするかどうかを示す。ある実施形態では、サポート・フィールド３１２は単一ビットである。このビットは、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートしていないターゲット３０２がビットを見ないように、選択または構成することができる。ビットが設定された場合、イニシエータ３００は、（１）ＸＦＲ＿ＲＤＹがディセーブルな状態で書き込みコマンド３０８が失敗し、ＸＦＲ＿ＲＤＹがイネーブルな状態で再駆動されるべきである旨を示す、状況メッセージ３１０、および、（２）書き込み動作が首尾よく完了した旨を示す状況メッセージ３１０の、２つをサポートする旨を示すことが可能であり、ここで状況メッセージ３１０は、イニシエータ３００からＸＦＲ＿ＲＤＹがディセーブルな状態で書き込み動作を処理するために、ターゲット３０２上で使用可能なバッファの数３０６を示す情報を含む。

他の実施形態では、サポート・フィールド３１２の使用以外、または使用に加えた方法を使用して、イニシエータ３００およびターゲット３０２がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするかどうかを確立することができる。たとえば、イニシエータ３００およびターゲット３０２は、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングが、ログイン段階で、あるいは、機能交換プロトコルまたは他の好適なプロトコルの一部として、サポートされるかどうかを取り決めることができる。他の実施形態では、書き込みコマンド３０８の場合とは反対に、サポート・フィールド３１２をフレーム・ヘッダまたは他の好適な位置に含めることができる。

イニシエータ３００は、ＸＦＲ＿ＲＤＹがその内部に含まれる特定の書き込みコマンド３０８に対してイネーブルであるかまたはディセーブルであるかを示すように、イネーブル／ディセーブル・フィールド３１４を設定することができる。ＸＦＲ＿ＲＤＹがイネーブルである場合、イニシエータは書き込みコマンド３０８に関連付けられたデータを送信するまで、ターゲット３０２からのＸＦＲ＿ＲＤＹメッセージを待機することになる。他方で、ＸＦＲ＿ＲＤＹがディセーブルである場合、イニシエータ３００は、ターゲット３０２からのＸＦＲ＿ＲＤＹメッセージを待機することなく、書き込みコマンド３０８の後にデータを送信することになる。ある実施形態では、書き込みコマンド３０８内にイネーブル／ディセーブル・フィールド３１４を提供する代わりに、フレーム・ヘッダの制御フィールドまたは他の好適な位置内にイネーブル／ディセーブル・フィールド３１４が含められる。

ターゲット３０２は、イニシエータ３００からの書き込みコマンド３０８を処理するために使用可能な、ターゲット３０２が有するバッファの数（Ｙ）３０６を追跡するように構成することができる。ある実施形態では、ターゲット３０２は、ターゲット３０２と共にログインされる各イニシエータ３００に対して異なる値の「Ｙ」を維持する。ターゲット３０２は、進行中の書き込みコマンド３０８の数およびターゲット３０２と共にログインされたイニシエータ３００の数に基づいて、「Ｙ」の値を動的に変更することができる。ターゲット３０２は、ターゲット・デバイス３０２上での他の動作に対してバッファを使用する必要性などの他の理由のために、「Ｙ」の値を変更することも可能である。「Ｙ」の現行の値は、任意の特定時点でのイニシエータ３００に対してターゲット３０２上で使用可能なバッファの数のスナップショットである。

書き込みコマンド３０８がターゲット３０２によって処理される場合、ターゲット３０２は、書き込み動作３０８の成功または失敗を示す状況３１０に応答することができる。状況メッセージ３１０（または望ましい実装に応じて他のメッセージ）は、書き込みコマンド３０８の完了後にターゲット３０２上で依然として使用可能なバッファの数３０６を示すことができる。この情報３０６を使用して、イニシエータ３００は、ターゲット３０２上で使用可能なバッファの数３０６と、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数３０４とを比較することができる。この比較を実行して、イニシエータ３００がターゲット３０２に送信する次の書き込みコマンド３０８に関する動作モード（すなわち、ＸＦＲ＿ＲＤＹがイネーブルであるかディセーブルであるか）を決定することができる。

たとえば、ターゲット３０２上で使用可能なバッファの数３０６が、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数３０４よりも大きい場合、イニシエータ３００はＸＦＲ＿ＲＤＹがディセーブルな状態で次の書き込みコマンド３０８を送信することができる。他方で、ターゲット３０２上で使用可能なバッファの数３０６が、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数３０４よりも小さいかまたは等しい場合、イニシエータ３００は、ＸＦＲ＿ＲＤＹがイネーブルな状態で次の書き込みコマンド３０８を送信することができる。ＸＦＲ＿ＲＤＹをイネーブルにすることで、書き込みコマンド３０８に関連付けられたデータを受信する前に、ターゲット３０２がバッファを割り振ることが可能となる。

図４を参照すると、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートする、イニシエータ３００によって実装される方法４００の一実施形態が示されている。図に示されるように、初めにイニシエータ３００は、書き込みコマンドを送信する準備が済んでいるかどうかを決定する（４０２）。これは、イニシエータ３００がターゲット・デバイス３０２に書き込む必要のあるデータを受信した場合に発生する可能性がある。次にイニシエータ３００は、書き込みコマンド３０８の制御フィールド３１２内でＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートする旨を示す（４０４）。前述のように、この制御フィールド３１２は、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートしていないターゲット３０２が制御フィールド３１２を見ないかまたはこれを無視するように選択することができる。

次にイニシエータ３００は、ターゲット３０２上で使用可能なバッファの数３０６を決定する（４０６）。これは、イニシエータ３００によって維持されるＹの値を読み取ることによって実施可能である。ある実施形態では、イニシエータ３００は、その内部値Ｙを所望の値に初期設定した後、使用可能なバッファの数３０６が状況メッセージ３１０または他の好適なメッセージ内でターゲット３０２から受信された場合にＹを更新する。イニシエータ３００は、それが有するターゲット３０２との未処理の書き込みコマンドの数３０４も決定する（４０８）。イニシエータ３００は、ターゲット３０２に書き込みコマンド３０８を送信し、ターゲット３０２から状況メッセージ３１０を受信する間、この数３０４を追跡することができる。

ステップ４１０で、ターゲット３０２上で使用可能なバッファの数（Ｙ）３０６が、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数（Ｚ）３０４よりも大きい場合、イニシエータ３００はＸＦＲ＿ＲＤＹがディセーブルな状態で書き込みコマンド３０８を送信する（４１２）。次にイニシエータ３００は、ターゲット３０２からのＸＦＲ＿ＲＤＹメッセージを待機することなく、書き込みコマンド３０８に関連付けられたデータをターゲット３０２に送信する（４１２）。ステップ４１０で、ターゲット３０２上で使用可能なバッファの数３０６が、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数３０４よりも小さいかまたは等しい場合、イニシエータ３００は、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンド３０８を送信する（４１４）。次にイニシエータ３００は、ターゲット３０２からＸＦＲ＿ＲＤＹメッセージを受信するのを待機する（４１６）。イニシエータ３００がＸＦＲ＿ＲＤＹメッセージを受信すると、イニシエータ３００は書き込みコマンド３０８に関連付けられたデータをターゲット３０２に送信する。

イニシエータ３００がステップ４１２または４１８でデータを送信すると、イニシエータ３００はターゲット３０２から状況３１０を受信するのを待機する（４２０）。状況が良好である場合、すなわち書き込み動作が首尾よく完了した場合、イニシエータ３００はターゲット３０２で使用可能なバッファの数を状況メッセージ３１０から読み取る（４２２）。この情報によって、イニシエータ３００は、将来の書き込みコマンド３０８に対してＸＦＲ＿ＲＤＹを適宜イネーブルまたはディセーブルにすることができる。他方で、状況が良好でない場合、すなわち書き込みコマンド３０８が首尾よく完了しなかった場合、イニシエータ３００はエラー回復プロセスを実行することができる（４２４）。これは、たとえば短い待機期間後に、同じかまたは別の経路をたどる書き込みコマンド３０８の再駆動を含むことができる。別の方法として、またはこれに加えて、状況メッセージ３１０がイニシエータ３００にそのように実行するよう指示する場合、ＸＦＲ＿ＲＤＹがイネーブルな状態での書き込みコマンド３０８の再駆動を含むことができる。イニシエータ３００に、書き込みコマンド３０８が首尾よく完了しなかった旨が通知された場合、イニシエータ３００はその内部値Ｙをゼロに設定し、ターゲット３０２上で現在使用可能なバッファがないことを反映させることができる。別の方法として、ターゲット３０２は、使用可能なバッファがないことをイニシエータ３００に通知し、そのＹの値を更新させることができる。次にイニシエータ３００は、次の書き込みコマンド３０８に対して方法４００を反復することができる。

図５を参照すると、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするターゲット３０２によって実装される方法５００の一実施形態が示される。図に示されるように、初めにターゲット３０２は、書き込みコマンド３０８が受信されたかどうかを決定する（３０８）。書き込みコマンド３０８が受信された場合（５０２）、書き込みコマンド３０８を調べることによって、ターゲット３０２はＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定する（５０４）。ＸＦＲ＿ＲＤＹがディセーブルでない場合、ターゲット３０２はバッファを割り振り（５２６）、ＸＦＲ＿ＲＤＹをイニシエータ３００に送信する（５２６）。データがイニシエータ３００から着信した場合、ターゲット３０２はそのデータをバッファに書き込み、書き込み動作の成功または失敗、ならびに書き込み動作の完了後にターゲット上で依然として使用可能なバッファの数３０６を示す状況３１０を、イニシエータ３００に戻す（５２８）。

ステップ５０４で、ＸＦＲ＿ＲＤＹがディセーブルである場合、ターゲット３０２は、ＸＦＲ＿ＲＤＹを送信することなく、書き込みコマンド３０８に関連付けられたデータが着信するのを待機する（５０６）。データが着信した場合、ターゲット３０２は、ターゲット上で１つまたは複数のバッファが使用可能であるかどうかを決定する（５０８）。１つまたは複数のバッファが使用可能である場合、ターゲット３０２は、データをバッファに書き込むことによって書き込みコマンド３０８を処理する（５１０）。次にターゲット３０２は、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするかどうかを決定する（５１２）。これは、書き込みコマンド３０８内のサポート・フィールド３１２を読み取ることによって実施可能である。サポートしている場合、ターゲット３０２は、ターゲット３０２上で依然として使用可能なバッファの数３０６を示す良好な（書き込み動作が首尾よく完了したものと想定する）状況３１０で応答する（５１４）。他方で、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートしていない場合、ターゲット３０２は単に良好な（書き込み動作が首尾よく完了したものと想定する）状況で応答する（５１６）。

ステップ５０８で、ターゲット３０２が、書き込みコマンド３０８に関連付けられたデータを保持するために使用可能なバッファがない旨を決定した場合、ターゲット３０２はデータを格納するためのリソースを有していないため、ターゲット３０２は受信された書き込みコマンド３０８に関連付けられたデータを破棄する（５１８）。次にターゲット３０２は、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするかどうかを決定する（５２０）。サポートしていない場合、ターゲット３０２はエラー状況３１０で応答する。これによりイニシエータ３００は、エラー回復プロセスを呼び出してエラー状況３１０に応答することができる。ステップ５２０でターゲット３０２が、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートしているものと決定した場合、ターゲット３０２は、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンド３０８を再駆動するようイニシエータ３００に指示する（５２４）。ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンド３０８を再駆動することで、ターゲット３０２はデータを受信する前にバッファを割り振る時間が可能になる。

図４および図５に提示された方法４００、５００は単なる例として提示されたものであり、限定的であることは意図されていない。当業者であれば、本発明の本質または特徴から逸脱することなく、方法４００、５００への様々な変更が実行可能であることを理解されよう。方法４００、５００は、イニシエータ３００およびターゲット３０２のそれぞれによって実行可能な方法４００、５００の単なる例を示すために提示されている。

図６および図７を参照すると、図４および図５に示された方法４００、５００が１つまたは複数のモジュールの形で実装可能である。これらのモジュールは、ハードウェア、ハードウェア上で実行可能なソフトウェアまたはファームウェア、あるいはそれらの組み合わせで実装可能である。これらのモジュールは単なる例として提示されたものであり、限定的であることは意図されていない。実際に、代替実施形態は、例示されたモジュールよりも多いかまたは少ないモジュールを含むことが可能である。いくつかの実施形態では、いくつかのモジュールの機能を複数のモジュールに分配すること、あるいはその逆に、いくつかのモジュールの機能を単一のモジュールまたはより少ないモジュールに組み合わせることが可能であることも理解されたい。モジュールが必ずしも例示された場所に実装されるものでないことも理解されたい。たとえば、イニシエータ３００内に示されたいくつかの機能は実際にはターゲット３０２内に実装可能であり、その逆もまた可能である。したがってモジュールの場所は単なる例として提示されており、限定的であることは意図されていない。

図６は、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするイニシエータ３００内に含めることが可能な様々なモジュールを示す高水準ブロック図である。図６に示されるように、選択された実施形態では、こうしたイニシエータ３００は、取り決めモジュール６００、値追跡モジュール６０２、コマンド生成モジュール６０４、コマンド送信モジュール６０６、待機モジュール６０８、データ送信モジュール６１０、および状況モジュール６１２のうちの、１つまたは複数の含むことができる。コマンド生成モジュール６０４は、設定モジュール６１４、決定モジュール６１６、イネーブル・モジュール６１８、およびディセーブル・モジュール６２０のうちの１つまたは複数を含むことができる。

イニシエータ３００の取り決めモジュール６００を使用して、ターゲット３０２の対応する取り決めモジュール７００（図７に示される）と取り決めることができる。ある実施形態では、取り決めモジュール６００、７００間での取り決めは、プロセス・ログイン時に実行される。取り決めモジュール６００、７００を使用して、イニシエータ３００およびターゲット３０２は、ＸＦＲ＿ＲＤＹのディセーブル・モードでの動作がサポートされるかどうかを取り決めることができる。イニシエータ３００およびターゲット３０２は、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングがサポートされるかどうかも取り決めることができる。

値追跡モジュール６０２を使用して、ターゲット３０２との未処理の書き込みコマンド３０８の数３０４を追跡することができる。ＸＦＲ＿ＲＤＹがディセーブルな状態で新しい書き込みコマンド３０８がターゲット３０２に送信された場合、値追跡モジュール６０２は数３０４を増分することができる。同様に、ＸＦＲ＿ＲＤＹがディセーブルな状態で未処理の書き込みコマンドに関する状況３１０が戻された場合、値追跡モジュール６０２は数３０４を減分することができる。値追跡モジュール６０２は、ターゲット３０２上で使用可能なバッファの数３０６を追跡することもできる。これはたとえば、状況メッセージ３１０がイニシエータ３００から受信された場合に使用可能なバッファの数３０６を読み取ることによって実施可能である。

コマンド生成モジュール６０４を使用して、ターゲット３０２に送信するための書き込みコマンド３０８を生成および読み込むことができる。このタスクを実施するために、設定モジュール３１４は、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートする旨を示す（４０４）ために、書き込みコマンド３０８内にサポート・フィールド３１２を設定することができる。次に決定モジュール６１６は、イネーブル／ディセーブル・フィールド３１４をどのように設定するかを決定することができる。より具体的に言えば、決定モジュール６１６は、ターゲット３０２上で使用可能なバッファの数３０６が、イニシエータ３００が有するターゲット３０２との未処理の書き込みコマンドの数３０４よりも大きいかどうかを決定することができる。大きい場合、ディセーブル・モジュール６２０が、書き込みコマンド３０８に対してＸＦＲ＿ＲＤＹをディセーブルにするようにイネーブル／ディセーブル・フィールド３１４を設定する。大きくない場合、イネーブル・モジュール６１８が、ＸＦＲ＿ＲＤＹをイネーブルにするようにイネーブル／ディセーブル・フィールド３１４を設定する。

コマンド生成モジュール６０４によって書き込みコマンド３０８が生成されると、コマンド送信モジュール６０６は書き込みコマンド３０８をターゲット３０２に送信する。書き込みコマンド３０８内でＸＦＲ＿ＲＤＹがイネーブルである場合、待機モジュール６０８はターゲット３０２からのＸＦＲ＿ＲＤＹメッセージを待機する。このメッセージが受信されると、データ送信モジュール６１０は１つまたは複数のフレーム内でデータを送信することなどによって、書き込みコマンド３０８に関連付けられたデータをターゲット３０２に送信する。他方で、ＸＦＲ＿ＲＤＹがディセーブルである場合、データ送信モジュール６１０はＸＦＲ＿ＲＤＹメッセージを待機することなくデータを送信することができる。データ送信モジュール６１０によってデータが送信されると、状況モジュール６１２はターゲット３０２からの状況情報３１０を待機し、これを読み取る。これは、書き込み動作の完了後に依然としてターゲット３０２上で使用可能なバッファの数３０６を状況情報３１０から読み取ることを含むことができる。

図７は、ＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするターゲット３０２内に含めることが可能な様々なモジュールを示す高水準ブロック図である。図７に示されるように、選択された実施形態では、こうしたターゲット３０２は、取り決めモジュール７００、値追跡モジュール７０２、検査モジュール７０４、決定モジュール７０６、割り振りモジュール７０８、送信モジュール７１０、可用性モジュール７１２、破棄モジュール７１４、処理モジュール７１６、および応答モジュール７１８のうちの１つまたは複数を含む。

前述のように、ターゲット３０２の取り決めモジュール７００は、ある機能がサポートされているかどうかを決定するために、プロセス・ログイン時にイニシエータ３００の取り決めモジュール６００と取り決めることができる。より具体的に言えば、取り決めモジュール７００は、ＸＦＲ＿ＲＤＹのディセーブル・モードでの動作がサポートされるかどうか、ならびにＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングがサポートされるかどうかを、取り決めることができる。値追跡モジュール７０２は、ターゲット３０２上で使用可能なバッファの数３０６を追跡することができる。バッファが使用可能な場合、値追跡モジュール７０２は数３０６を減分することができる。同様に、バッファがターゲット３０２上で使用可能になると、値追跡モジュール７０２は数３０６を増分することができる。

検査モジュール７０４を使用して、着信する書き込みコマンド３０８を検査することができる。特に検査モジュール７０４は、着信する書き込みコマンド３０８のサポート・フィールド３１２およびイネーブル／ディセーブル・フィールド３１４を検査するように構成することができる。これらのフィールド３１２、３１４内の情報を使用することで、決定モジュール７０６は、イニシエータ３００がＸＦＲ＿ＲＤＹの動的なイネーブリングおよびディセーブリングをサポートするかどうか、ならびに書き込みコマンド３０８に対してＸＦＲ＿ＲＤＹがイネーブルまたはディセーブルであるかどうかを、決定することができる。書き込みコマンド３０８に対してＸＦＲ＿ＲＤＹがイネーブルである場合、割り振りモジュール７０８は書き込みコマンド３０８に関連付けられたデータに対してバッファを割り振り、送信モジュール７１０は、バッファが割り振られたことおよびターゲット３０２がデータを受信する準備が済んでいることを示すＸＦＲ＿ＲＤＹメッセージを、インジケータ３００に送信する。

他方で、決定モジュール７０６が、書き込みコマンド３０８に対してＸＦＲ＿ＲＤＹがディセーブルであるものと決定した場合、ターゲット３０２は単に書き込みコマンド３０８に関連付けられたデータが着信するのを待機するだけでよい。データが着信した場合、可用性モジュール７１２は、データを受信するためにターゲット３０２上で少なくとも１つのバッファが使用可能であるかどうかを決定することができる。使用可能なバッファがない場合、破棄モジュール７１４は、データがイニシエータ３００から受信された場合にそのデータを破棄することができる。少なくとも１つのバッファが使用可能である場合、処理モジュール７１６は、コマンド３０８に関連付けられたデータを少なくとも１つのバッファに書き込むことによって、書き込みコマンド３０８を処理することができる。次に応答モジュール７１８は、書き込み動作の結果を示す状況３１０をイニシエータ３００に送信することができる。応答モジュール７１８は、書き込み動作の完了後、ターゲット３０２上で依然として使用可能なバッファの数を示す情報を状況３１０内に含めることができる。

図面内の流れ図およびブロック図は、本発明の様々な実施形態に従ったシステム、方法、およびコンピュータ使用可能媒体の可能な実装のアーキテクチャ、機能、および動作を示す。この点で、流れ図またはブロック図内の各ブロックは、指定された論理機能を実装するための１つまたは複数の実行可能命令を含む、コードのモジュール、セグメント、または部分を表すことができる。いくつかの代替実装では、ブロック内に示された機能が図面内に示された順序以外で実行可能であることにも留意されたい。たとえば連続して示された２つのブロックが実際にはほぼ同時に実行可能であるか、またはこのブロックが、関連する機能に応じて逆の順序で実行可能である。ブロック図または流れ図あるいはその両方の各ブロック、ならびに、ブロック図または流れ図あるいはその両方内のブロックの組み合わせが、特定用途向けハードウェアおよびコンピュータ命令の指定された機能または動作あるいはそれらの組み合わせを実行する、特定用途向けハードウェアベースのシステムによって実装可能であることにも留意されよう。

Claims (14)

1. ＸＦＲ＿ＲＤＹを動的にイネーブリングおよびディセーブリングするための方法であって、
   ターゲットで書き込みコマンドを受信すること、
   前記書き込みコマンドに対してＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定すること、
   ＸＦＲ＿ＲＤＹがディセーブルである場合、前記ターゲット上で少なくとも１つのバッファが使用可能であるかどうかを決定すること、
   少なくとも１つのバッファが使用可能である場合、前記書き込みコマンドに関連付けられたデータを前記少なくとも１つのバッファに書き込むことによって、前記書き込みコマンドを処理すること、および、
   前記書き込みコマンドが完了した後に、前記ターゲット上で依然として使用可能なバッファの数を示す情報を戻すこと、
   を含む、方法。
2. 少なくとも１つのバッファが使用可能でない場合、前記ターゲットで前記書き込みコマンドに関連付けられたデータを破棄することをさらに含む、請求項１に記載の方法。
3. データを破棄することは、前記書き込みコマンドが失敗し、ＸＦＲ＿ＲＤＹがイネーブルな状態で再駆動されるべきであることを示す状況を戻すことをさらに含む、請求項２に記載の方法。
4. 情報を戻すことは、前記情報を前記書き込みコマンドのイニシエータに送信することをさらに含む、前記請求項のいずれか一項に記載の方法。
5. ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドを前記ターゲットに送信する以前に、前記イニシエータは、前記ターゲット上で依然として使用可能な前記バッファの数が、前記イニシエータが有する前記ターゲットとの前記未処理の書き込みコマンドの数よりも多いかどうかを決定する、請求項４に記載の方法。
6. 前記イニシエータが、前記ターゲット上で依然として使用可能な前記バッファの数が、前記イニシエータが有する前記ターゲットとの前記未処理の書き込みコマンドの数よりも多いものと決定した場合、前記イニシエータは、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドを送信するように構成される、請求項５に記載の方法。
7. 前記イニシエータが、前記ターゲット上で依然として使用可能な前記バッファの数が、前記イニシエータが有する前記ターゲットとの前記未処理の書き込みコマンドの数よりも多くないものと決定した場合、前記イニシエータは、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを送信するように構成される、請求項５に記載の方法。
8. コンピュータ・システム内にロードされ、その上で実行された場合、前記コンピュータ・システムに請求項１から７のいずれか一項に従った方法のすべてのステップを実行させるための、コンピュータ読み取り可能媒体上に格納されたコンピュータ・プログラム・コードを含む、コンピュータ・プログラム。
9. ＸＦＲ＿ＲＤＹを動的にイネーブリングおよびディセーブリングするためのシステムであって、
   書き込みコマンドを送信するためのイニシエータと、
   前記書き込みコマンドを受信し、前記書き込みコマンドに対してＸＦＲ＿ＲＤＹがディセーブルであるかどうかを決定するためのターゲットを備え、
   さらに前記ターゲットは、ＸＦＲ＿ＲＤＹがディセーブルである場合、前記ターゲット上で少なくとも１つのバッファが使用可能であるかどうかを決定するように構成され、
   さらに前記ターゲットは、前記ターゲット上で少なくとも１つのバッファが使用可能である場合、前記書き込みコマンドに関連付けられたデータを前記少なくとも１つのバッファに書き込むことによって前記書き込みコマンドを処理するように構成され、
   さらに前記ターゲットは、前記書き込みコマンドが完了した後に、前記ターゲット上で依然として使用可能な前記バッファの数を示す情報を前記イニシエータに戻すようにさらに構成される、
   システム。
10. さらに前記ターゲットは、少なくとも１つのバッファが使用可能でない場合、前記書き込みコマンドに関連付けられたデータを破棄するように構成される、請求項９に記載のシステム。
11. さらに前記ターゲットは、前記データが破棄された場合、前記書き込みコマンドが失敗し、ＸＦＲ＿ＲＤＹがイネーブルな状態で再駆動されるべきであることを示す状況を戻すように構成される、請求項１０に記載のシステム。
12. さらに前記イニシエータは、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドを前記ターゲットに送信する以前に、前記ターゲット上で依然として使用可能な前記バッファの数が、前記ターゲットとの前記未処理の書き込みコマンドの数よりも多いかどうかを決定するように構成される、請求項９から１１のいずれか一項に記載のシステム。
13. さらに前記イニシエータは、前記ターゲット上で依然として使用可能な前記バッファの数が、前記ターゲットとの前記未処理の書き込みコマンドの数よりも多い場合、ＸＦＲ＿ＲＤＹがディセーブルな状態で別の書き込みコマンドを前記ターゲットに送信するように構成される、請求項１２に記載のシステム。
14. さらに前記イニシエータは、前記ターゲット上で依然として使用可能な前記バッファの数が、前記ターゲットとの前記未処理の書き込みコマンドの数よりも多くない場合、ＸＦＲ＿ＲＤＹがイネーブルな状態で書き込みコマンドを送信するように構成される、請求項１２に記載のシステム。

Images