JP2019164713A - ストレージシステム及びデータ転送方法 - Google Patents
ストレージシステム及びデータ転送方法 Download PDFInfo
- Publication number
- JP2019164713A JP2019164713A JP2018053280A JP2018053280A JP2019164713A JP 2019164713 A JP2019164713 A JP 2019164713A JP 2018053280 A JP2018053280 A JP 2018053280A JP 2018053280 A JP2018053280 A JP 2018053280A JP 2019164713 A JP2019164713 A JP 2019164713A
- Authority
- JP
- Japan
- Prior art keywords
- packet
- command
- data
- controller
- storages
- 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.)
- Pending
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0659—Command handling arrangements, e.g. command buffers, queues, command scheduling
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0602—Interfaces specially adapted for storage systems specifically adapted to achieve a particular effect
- G06F3/061—Improving I/O performance
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0628—Interfaces specially adapted for storage systems making use of a particular technique
- G06F3/0655—Vertical data movement, i.e. input-output transfer; data movement between one or more hosts and one or more storage devices
- G06F3/0656—Data buffering arrangements
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/067—Distributed or networked storage systems, e.g. storage area networks [SAN], network attached storage [NAS]
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F3/00—Input arrangements for transferring data to be processed into a form capable of being handled by the computer; Output arrangements for transferring data from processing unit to output unit, e.g. interface arrangements
- G06F3/06—Digital input from, or digital output to, record carriers, e.g. RAID, emulated record carriers or networked record carriers
- G06F3/0601—Interfaces specially adapted for storage systems
- G06F3/0668—Interfaces specially adapted for storage systems adopting a particular infrastructure
- G06F3/0671—In-line storage system
- G06F3/0683—Plurality of storage devices
- G06F3/0688—Non-volatile semiconductor memory arrays
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F12/00—Accessing, addressing or allocating within memory systems or architectures
- G06F12/02—Addressing or allocation; Relocation
- G06F12/0223—User address space allocation, e.g. contiguous or non contiguous base addressing
- G06F12/023—Free address space management
- G06F12/0238—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory
- G06F12/0246—Memory management in non-volatile memory, e.g. resistive RAM or ferroelectric memory in block erasable memory, e.g. flash memory
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F9/00—Arrangements for program control, e.g. control units
- G06F9/06—Arrangements for program control, e.g. control units using stored programs, i.e. using an internal store of processing equipment to receive or retain programs
- G06F9/46—Multiprogramming arrangements
- G06F9/48—Program initiating; Program switching, e.g. by interrupt
- G06F9/4806—Task transfer initiation or dispatching
- G06F9/4843—Task transfer initiation or dispatching by program, e.g. task dispatcher, supervisor, operating system
- G06F9/4881—Scheduling strategies for dispatcher, e.g. round robin, multi-level priority queues
Landscapes
- Engineering & Computer Science (AREA)
- Theoretical Computer Science (AREA)
- Human Computer Interaction (AREA)
- Physics & Mathematics (AREA)
- General Engineering & Computer Science (AREA)
- General Physics & Mathematics (AREA)
- Data Exchanges In Wide-Area Networks (AREA)
- Communication Control (AREA)
Abstract
【課題】 効率よく他のストレージにアクセスすることができるストレージシステム及びデータ転送方法を提供すること。【解決手段】 実施形態によれば、ストレージシステムは、複数のストレージと、複数のコントローラと、複数のパケット転送部と、を具備する。コントローラは、第2ストレージからデータをリードする場合、リードデータを含む第1パケットを受信するための領域をメモリに確保し、第1パケットを受信するための第1コマンドをパケット転送部の第1キューに登録し、リードデータの送信を要求するための第2パケットをメモリに格納し、第2パケットを送信するための第2コマンドを第1キューに登録する。パケット転送部は、第1コマンドを受信した場合、受信予定の第1パケットを全て受信すると、完了通知を第2キューに登録し、第2コマンドを受信した場合、前記第2パケットの送信が完了すると、完了通知を第2キューに登録する。【選択図】図13
Description
本発明の実施形態は概してストレージシステム及びデータ転送方法に関する。
フラッシュメモリ等の不揮発性半導体メモリを含む複数のストレージを含むストレージシステムが開発されている。
従来のストレージシステムでは、複数のストレージがネットワークを構成している。第1のストレージが第2のストレージにデータをライトする際及び/又は第1のストレージが第2のストレージからデータをリードする際の効率には改善の余地があった。
本発明の目的は効率よく他のストレージにアクセスすることができるストレージシステム及びデータ転送方法を提供することである。
実施形態によれば、ストレージシステムは、複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備する。
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージへ第1データをライトする場合、ライト完了通知を含む第1パケットを受信するための領域をメモリに確保し、前記第1パケットを受信するための第1コマンドを前記第1コントローラに接続される第1パケット転送部の第1キューに登録し、前記第1データを含む第2パケットを前記メモリに格納し、前記第2パケットを送信するための第2コマンドを前記第1パケット転送部の前記第1キューに登録する。
前記第1コントローラは、前記第2ストレージから第2データをリードする場合、前記第2データを含む第3パケットを受信するための領域を前記メモリに確保し、前記第3パケットを受信するための第1コマンドを前記第1パケット転送部の前記第1キューに登録し、前記第2データの送信を要求するための第4パケットを前記メモリに格納し、前記第4パケットを送信するための第2コマンドを前記第1パケット転送部の前記第1キューに登録する。
前記第1パケット転送部は、前記第1パケット又は前記第3パケットを受信するための第1コマンドを受信した場合、受信予定の前記第1パケット又は前記第3パケットを全て受信すると、前記第1コマンドの完了通知を第2キューに登録し、前記第2パケット又は前記第4パケットを送信するための前記第2コマンドを受信した場合、前記第2パケット又は前記第4パケットの送信が完了すると、前記第2コマンドの完了通知を前記第2キューに登録する。
以下、実施の形態について図面を参照して説明する。なお、開示はあくまで一例にすぎず、以下の実施形態に記載した内容により発明が限定されるものではない。当業者が容易に想到し得る変形は、当然に開示の範囲に含まれる。説明をより明確にするため、図面において、各部分のサイズ、形状等を実際の実施態様に対して変更して模式的に表す場合もある。複数の図面において、対応する要素には同じ参照数字を付して、詳細な説明を省略する場合もある。
[ストレージシステムの全体構成]
図1は実施形態に係るストレージシステム全体の構成の一例を示すブロック図である。多数のストレージ10−1、10−2、…(ストレージ10と総称することもある)が複数のノード12−1、12−2、…(ノード12と総称することもある)にそれぞれ接続される。ストレージ10はフラッシュメモリ等の不揮発性半導体メモリを含むものであり、例えばSSD(Solid State Drive)である。ノード12は、プログラムを格納するROM4、プログラムを実行するCPU2、プログラム実行中のデータを一時的に保持するDRAM等のメインメモリ6を備え、ストレージ10に対するリード/ライト処理を実行する。
図1は実施形態に係るストレージシステム全体の構成の一例を示すブロック図である。多数のストレージ10−1、10−2、…(ストレージ10と総称することもある)が複数のノード12−1、12−2、…(ノード12と総称することもある)にそれぞれ接続される。ストレージ10はフラッシュメモリ等の不揮発性半導体メモリを含むものであり、例えばSSD(Solid State Drive)である。ノード12は、プログラムを格納するROM4、プログラムを実行するCPU2、プログラム実行中のデータを一時的に保持するDRAM等のメインメモリ6を備え、ストレージ10に対するリード/ライト処理を実行する。
複数のマトリクスコントローラ(以下、MCと称する)14−1、14−2、14−3、…(MC14と総称することもある)がネットワークを構成する。ネットワークの一例は、1つのMC14が複数のMC14に接続されるメッシュネットワークがある。各MC14は、例えばLVDS(Low Voltage Differential Signaling)規格の信号線を介して複数のMCに接続される。各ノード12はいずれかのMC14に接続される。MC14はノード12からのパケットを、接続されている複数のMC14の中のいずれかのMC14に転送するルーティング機能を有する。すなわち、ノード12−1から送信されたパケットが複数のMC14を介してノード12−2に転送される。これにより、各ノード12は複数のストレージ10を共有することができる。
ノード12とストレージ10とを相互接続するためのインタフェースとしては、SCSI(Small Computer System Interface)、SAS(Serial Attached SCSI)、ATA(Advanced Technology Attachment)、SATA(Serial ATA)、PCI Express(PCIeとも称する)(登録商標)、NVM Express(NVMeとも称する)(登録商標)、Ethernet(登録商標)、Fibre channel等を使用し得る。実施形態では、ノード12とストレージ10の間、ノード12とMC14の間、隣接するMC14の間でNVMeインタフェースに従ってパケットが通信される。
図2はノード12とMC14の機能ブロックの一例を示す図である。ノード12は、図2(a)に示すように、ストレージI/F32、ストレージ(自ノード)アクセスモジュール34、アクセス要求パケット管理モジュール26、送受信コマンド発行管理モジュール28を備えるドライバ24からなる。アクセス要求パケット管理モジュール26は、パケット分割モジュール42、パケット統合モジュール44、パケットID付与モジュール46、パケットID照合モジュール48、SGL(Scatter Gather List)分割モジュール50、SGL統合モジュール52からなる。ノード12のドライバ24が備える各モジュールはCPU2が実行するソフトウェアで実現される。
ストレージI/F32は、ファイルシステム等の上位レイヤがストレージ10にアクセスするために必要なインタフェース(例えば、OS上のデバイスファイル)を提供する。ストレージI/F32は、自ノードのストレージ10及び他ノードのストレージ10を同一アドレス空間又はそれぞれ独立したアドレス空間で提供することができる。ストレージI/F32は、必要な場合、提供しているアドレス空間から自ノードのストレージ10や他ノードのストレージ10上のアドレス空間へのアドレス変換を行うことができる。
ストレージ(自ノード)アクセスモジュール34は、ストレージI/F32により自ノードのストレージ10にマッピングされているアドレス空間内の領域に対するアクセス要求を受信した場合、自ノードのストレージ10に対してアクセスする。
アクセス要求パケット管理モジュール26は、ストレージI/F32により他ノードのストレージ10にマッピングされているアドレス空間内の領域に対するアクセス要求を受信した場合、そのアクセス要求をパケットに変換し、他ノードにそのパケットを転送し、他ノードからの応答パケットをアクセス要求の応答に変換する。さらに、アクセス要求パケット管理モジュール26は、他ノードから転送された要求パケットを自ノードのストレージアクセス要求に変換して、ストレージ(自ノード)アクセスモジュール34を使用して当該ストレージアクセス要求を実行し、その応答パケットを他ノードに返送する。
パケット分割モジュール42は、他ノードのストレージ10に対するアクセス要求に関するデータ転送量が単一のパケットに収まらない場合、当該アクセス要求を複数のパケットに分割して転送する。パケット統合モジュール44は、複数のパケットに分割されて転送されたアクセス要求を転送先で元の1つのアクセス要求に復元する。
パケット分割、パケット統合のために、パケットID付与モジュール46とパケットID照合モジュール48が設けられる。パケットIDは、要求とパケットを対応付けし、パケットが不正なパケットではないことを識別するためのものであり、パケットにユニークな番号である。
パケットID付与モジュール46は、受信用パケットを用意する際に、各パケットにパケットIDを割り当てる。パケットID照合モジュール48は、パケットを受信すると、受信したパケットが正しい受信用パケットであるか否かをパケットIDに基づいて判断する。
図3はパケットID(PktIDとも称する)の一例を示す。パケットIDは、例えば64ビットからなり、上位56ビットがTAGであり、下位8ビットがパケット番号である。TAGはパケットIDのセットを示す。パケット番号はTAGで識別される1セットのパケットID(TAG)の中の何番目のパケットIDであるかを示す。
SGL分割モジュール50は、1つのパケットを複数のパケットに分割する際に、SGLをパケット毎の複数のSGLに分割する。SGLとは、メインメモリ(物理アドレス領域)内に不連続に配置されたデータ(パケットヘッダを含む)領域のポインタ及びサイズを送受信する順番に並べたリストである。SGL統合モジュール52は、複数のパケットを統合して1つのアクセス要求に復元する際に、複数のSGLを1つのSGLに統合する。
送受信コマンド発行管理モジュール28は、パケットIDがワイルドカードに設定された受信用パケットを受信するコマンドをサブミッションキュー(submission Queue:SQ)に登録したり、送信コマンドが完了したことをコンプリーションキュー(completion Queue:CQ)をポーリングして確認したり、割り込みを受信して受信完了したコマンドを処理する。NVMe規格では、メッセージ(コマンドとコマンド完了通知)を通知するために、固定のエントリサイズを有するサーキュラーキューが使用される。キューは、SQとCQを含む。キューは何処にあっても良いが、ここでは、MC14内にノード間のパケット転送のために使われるSQとCQが設けられているとする。SQはノード12からMC14に対するコマンドを発行するために使われる。CQはそのコマンドが完了したことをMC14からノード12に通知するために使われる。コマンドの例として、パケットを送信するもの(後述するSMコマンド)や、パケットを受信するもの(RMコマンド)がある。
MC14は、図2(b)に示すように、コマンドキューイングモジュール62、パケット送受信モジュール64、パケット管理モジュール66、受信コマンド待機モジュール68を備え、パケット管理データ70を格納する。MC14の各モジュールはハードウェアで実現される。
コマンドキューイングモジュール62は、ノード12から発行された送受信コマンドのためのジョブをSQに登録し、完了した送受信コマンドのためのジョブをCQに登録する。
パケット送受信モジュール64は、送信コマンドにより発行されたパケットを隣接するMC14に転送し、隣接したMC14から転送されたパケットが自MC宛のパケットか他MC宛のパケットかを判別し、他MC宛のパケットを他MC14へ転送し、パケット管理モジュール66を用いて自MC宛のパケットを判別し、ノード12上のメモリ空間内の受信コマンドに定義されている領域に自MC宛のパケットを受信する。
受信コマンド待機モジュール68は、ノード12がセットした受信コマンドを適切なパケットが到着するまで保持する。保持したコマンドはノード12のCPU2が実行するアプリケーションプログラム等の指示によりキャンセルされ得る。
パケット管理モジュール66は、図4に示すパケット管理データ70を利用して、受信パケットの状況を管理する。受信パケットの状況の管理は、パケット管理データ70のパケット番号ビットマップへのパケット番号の登録、パケット番号ビットマップからのパケット番号の削除等を含む。パケット管理モジュール66は、他のモジュールと連携して適切なタイミングでノード12へ割り込みを発行する。
パケット管理データ70は、パケット管理構造で保持される受信パケットの状況を示す管理用データである。図4はパケット管理データ70の一例を示す。パケット管理データ70は登録されているTAG毎のパケット番号のビットマップ(256ビット)を示す。パケット管理モジュール66は、自ノードからRMコマンド(後述)を受信すると、コマンドに含まれるパケットIDに含まれるTAGがパケット管理データ70に登録済みであるか否かをチェックする。未登録であれば、パケット管理モジュール66は、パケット管理データ70にTAGを登録し、パケット番号ビットマップのパケット番号に対応するビットを“1”とする。ただし、パケットIDがワイルドカードの場合、パケット管理モジュール66は、TAGを登録しない。
パケット管理モジュール66は、他ノードからRMコマンドを示すパケットを受信すると、対応するRMコマンドで指定されたメモリ領域にデータを転送する。転送が終わると、パケット管理モジュール66は、CQに完了通知を入れるとともに、パケット管理データ70のパケット番号ビットマップのパケット番号に対応するビットを“0”とする。パケット管理モジュール66は、パケット番号ビットマップの全ビットが“0”になったら、TAGをリストから削除し、割り込みを発生させる。パケット管理モジュール66は、登録されているTAGが無ければ、即時割り込みを発生させる。これにより、コマンドキューイングモジュール62は、1つの受信コマンドが完了しても割り込みを生じさせずに、1つの送信コマンドに関係する全ての受信コマンドが完了した時に割り込みを生じさせ、ノード12のCPU2が実行するアプリケーションプログラムに送受信コマンドの完了を通知する。このため、パケットの受信毎に割り込みが発生せず、RMコマンドに関する全パケットが受信したら割り込みが発生する。これにより、割り込みの発生頻度が低下し、転送効率が改善する。
[第1のリード/ライト処理]
実施形態のストレージデバイスは、第1のノードが第2のノードに接続されているストレージに対してデータをリード/ライトする効率を向上できる。このリード/ライト効率は、ノード12のCPU2によるデータのコピー回数と、MC14からノード12のCPU2に対する割り込みの回数に応じている。
実施形態のストレージデバイスは、第1のノードが第2のノードに接続されているストレージに対してデータをリード/ライトする効率を向上できる。このリード/ライト効率は、ノード12のCPU2によるデータのコピー回数と、MC14からノード12のCPU2に対する割り込みの回数に応じている。
ノード12のCPU2はパケットの作成に際して、データを所定の位置に配置し、所定の順番に並べたり、パケットに転送先のノードのアドレス等のルーティングアドレスや誤り訂正のためのCRC(Cyclic Redundancy Code)を付けたりするが、この際、データをメインメモリ6(物理アドレス領域)内で一旦他の場所にコピーする必要がある。このコピー処理の負荷がデータのリード/ライト効率を低下させる。
しかし、実施形態のノード12はパケットを作成する際、SGLを利用してメインメモリ6(物理アドレス領域)内のヘッダ、データを関連づけてパケットを作成している。そのため、メインメモリ6(物理アドレス領域)内でデータのコピーが不要であり、リード/ライト効率が改善する。
また、MC14は他のMCへ送信したコマンドにおいて要求したデータを含むパケットを受信する。データのサイズが大きいと、1つのコマンドに対して複数のパケットを受信する。MC14はパケットの受信を完了すると、その都度ノード12に完了通知を送信することがある。ノード12が完了通知を受信すると、CPU2は割り込み処理を開始するので、リード/ライト効率が低下する。しかし、実施形態では、1つのコマンドに関する全てのデータを受信するまでは、パケットを受信してもMC14はノード12に完了通知を送信しない。MC14は1つのコマンドに関する全てのデータを受信すると、ノード12に完了通知を送信する。
これを実現するために、実施形態では、各ノードは予めパケット受信用パケットを準備しておく。パケット受信用パケットとはパケットを受信するためのメインメモリ6(物理アドレス領域)の一部の領域に相当する。予め準備しておくパケット受信用パケットのパケットIDはワイルドカードとされる。パケットがノードに転送されると、ノードは、転送されたパケットのパケットIDを確認して、そのパケットIDと一致する受信用パケットにてパケットを受信し、データをパケット受信用パケットに対応するメインメモリ6(物理アドレス領域)内の領域に格納する。もし、受信したパケットのパケットIDと一致する受信用パケットがなくても、ワイルドカードであるパケットIDのパケット受信用パケットがあれば、そのパケットにてパケットが受信される。そのため、パケット受信用パケットはどのようなパケットでも受信可能である。準備しておくパケット受信用パケットの数は、メインメモリ6(物理アドレス領域)に余裕がある限りできるだけ多数でよい。
そして、第1のノードは第2のノードへデータを要求する際、そのデータを受信する複数のパケット受信用パケットのパケットIDと、そのパケットが受信するデータ長のリストを転送する。リストの転送時に、第1のノードに接続されるMC14は、図4に示すパケット管理データ70に受信用パケットのパケットIDを登録する(TAG毎のパケット番号ビットマップのパケット番号に対応するビットを“1”とする)。第2のノードはこのリストに従いデータを複数のパケットとして第1のノードへ転送する。第1のノードに接続されるMC14は、パケットを受信すると、TAG毎のパケット番号ビットマップにおける受信したパケット番号に対応するビットを“0”とする。TAG毎のパケット番号ビットマップが全て“0”になると、MC14はパケット管理データ70からTAGを削除し、ノード12に完了通知を送信する。これにより、ノード12のCPU2が割り込み処理を開始する頻度が低下し、リード/ライト効率の低下が防止される。
[第1のライト処理]
第1のノード12−1が第2のノード(ここでは、ノード12−2)のストレージ10−2へデータをライトする第1のライト処理の一例を説明する。図5は第1のライト処理におけるパケットの転送の一例を示し、図6、図7はライト処理の一例を示すフローチャートである。図6(a)、図7(a)は第1のノード12−1側の処理、図6(b)、図7(b)は第2のノード12−2側の処理を示す。
第1のノード12−1が第2のノード(ここでは、ノード12−2)のストレージ10−2へデータをライトする第1のライト処理の一例を説明する。図5は第1のライト処理におけるパケットの転送の一例を示し、図6、図7はライト処理の一例を示すフローチャートである。図6(a)、図7(a)は第1のノード12−1側の処理、図6(b)、図7(b)は第2のノード12−2側の処理を示す。
先ず、図6(a)を参照して第1のノード12−1側の処理を説明する。
ステップS112において、ドライバ24−1は、CPU2が実行するアプリケーションプログラムからライト要求を受信する。ライト要求は、仮想アドレス領域のメインメモリ6(以下、仮想メモリと称する)M11内のデータを第2のノード12−2のストレージ10−2へライトする要求である。
ステップS114において、ドライバ24−1は、仮想メモリM11内のライトデータを物理アドレス領域のメインメモリ6(以下、物理メモリと称する)内のデータ領域に変換(アドレス変換)し、パケットのヘッダ(PktIDはワイルドカードである)を作成し、パケットヘッダを物理メモリM21内に格納する。PktIDがワイルドカードであるパケットは、パケット受信用パケットで受信可能である。図5では、物理メモリM21が断片化されている場合を想定したので、ライトデータを物理メモリM21内の複数のデータ領域に変換したが、断片化されていない場合は、1つのデータ領域に変換される。
ドライバ24−1は、SGLを利用して、物理メモリM21内のヘッダとデータを統合してライトコマンドを送信するためのパケットを作成する。ライトされるデータのサイズに応じて、1つのライト要求に対して複数のパケットが作成されることがある。ここでは、2つのパケットP11、P12が作成される例を示す。
ステップS116において、ドライバ24−1は、ノード12−2からのライト要求に対する完了通知パケット(PktID=特定のID)を受信するためのNVMeコマンド、ここではReceive Message(RM)コマンド(RMCmd)R10をMC14−11のSQに登録する。
図8は、完了通知受信用パケットP10と完了通知受信用パケットを受信するためのRMコマンドR10の一例を示す。図8(a)に示すように、完了通知受信用パケットP10は空のヘッダ領域のみからなり、ペイロードは含まない。図8(b)に示すように、完了通知受信用パケットRMコマンドR10は、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はReceive Messageであり、40−47バイトのCommand Dword 10 (CDW10)、Command Dword 11 (CDW11)には完了通知パケットのパケットIDがセットされる。完了通知受信用RMコマンドR10の16−31バイトのMTPRとDPTRはパケットのSGLポインタであり、実際のSGLは別領域である。完了通知パケットはヘッダ領域のみの1エントリなので、SGLポインタはSGL Descriptor0となる。これにより、物理メモリM21内で完了通知パケットP10を受信するための領域が確保される。
ステップS117において、MC14−11はSQに登録されたRMコマンドR10に含まれる完了通知パケットIDに含まれるTAGがパケット管理データ70に登録済みであるか否かをチェックする。未登録であれば、MC14−11はパケット管理モジュール66を用いてパケット管理データ70にTAGを登録し、パケット番号ビットマップのパケット番号に対応するビットを“1”とする。
ステップS118において、ドライバ24−1は、ライトコマンド送信パケットP11、P12を送信するためのNVMeコマンド、ここではSend Message(SM)コマンド(SMCmd)S11、S12をMC14−11のSQに登録する。
図9は、ライトコマンド送信パケットP11、P12とライトコマンド送信パケットを送信するSMコマンドS11、S12の一例を示す。図9(a)に示すように、ライトコマンド送信パケットP11、P12はヘッダ領域とペイロードからなる。ヘッダ領域は、コマンドがライトコマンドであることを示すライトコマンド情報、パケット識別情報、パケットID(=ワイルドカード)、完了通知パケットのパケットIDからなり、ペイロードはライトデータからなる。ライトコマンド情報はデータがライトされるストレージ10−2の領域の論理アドレス及びデータを書き込む領域のサイズ(例えば、セクタ数)を含む。パケット識別情報はコマンドを識別する情報とそのコマンドに関する何番目のパケットであるかを示す情報を含む。コマンドを識別する情報は、あるコマンドが複数のパケットに分割された場合、そのコマンドに属するパケットであることを示す情報(前述したTAGはこの情報の例である)である。例えば、ライトコマンドAが複数のパケットに分割された場合、各パケットのパケットIDはワイルドカードであるが、パケット識別情報は、ライトコマンドAであることを示す識別子と、ライトコマンドAについての何番目のパケットであるかを示す番号情報を含む。なお、図示しないが、全てのパケットのヘッダ領域はルーティングアドレスも含む。ルーティングアドレスは第2のノードのアドレス等を含み、MC14が受信したパケットをネットワーク内のどのMC14に転送するかを決める際に使用される。ペイロードは、例えば4KiBである。ワイルドカードパケットIDは、例えば0xFFFF FFFF FFFF FFFFである。
図9(b)に示すように、ライトコマンド送信パケットP11、P12を送信するSMコマンドS11、S12は64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はSend Messageである。ライトコマンド送信パケットP11、P12はヘッダ領域とペイロードからなり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptorとなる。
ステップS120において、MC14−11はSQ内のコマンドを実行し、コマンドで規定されるパケットをLVDS線を介して隣接するMC14へ転送する。ここでは、図9(a)に示すライトコマンド送信パケットP11、P12が第2のノード12−2へ転送されたとする。MC14−11はLVDS線へのパケットP11、P12の送信が完了したタイミングで割り込みを発生させ、ノード12−1にそれを通知する。
ここで、第2のノード12−2の動作を説明する。上述したように、全ノード12は、システムがオンすると、パケット受信用パケットを準備し、パケット受信用のNVMeコマンドを作成し、SQに登録しておく。そのため、第2のノード12−2も、システムがオンすると、図6(b)のステップS212に示すように、物理メモリM22内にデータとヘッダからなり、パケットIDがワイルドカードからなる多数のパケット受信用パケット(ここでは2つのみ示す)P21、P22を作成し、受信用パケットP21、P22を受信するためのNVMeコマンド、ここではRMコマンド(RMCmd)R21、R22をMC14−13のSQに登録する。なお、第1のノード12−1もパケット受信用パケットのRMコマンドをMC14−11のSQに登録するが、ライト処理では使用されないので、図6(a)、図7(a)では説明を省略する。
図10は、パケット受信用パケットP21、P22とパケット受信用パケットを受信するためのRMコマンドR21、R22の一例を示す。図10(a)に示すように、パケット受信用パケットP21、P22はヘッダ領域とペイロードからなる。ヘッダ領域は空である。ペイロードはペイロードヘッダとペイロードデータからなるが、両方とも空である。ペイロードは、例えば4KiBである。
図10(b)に示すように、パケット受信用パケットRMコマンドR21、R22は64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はReceive Messageであり、40−47バイトのCommand Dword 10 (CDW10)、Command Dword 11 (CDW11)のパケットIDにはワイルドカードパケットID(0xFFFF FFFF FFFF FFFF)がセットされる。受信用パケットはヘッダ領域とペイロードがあり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptor となる。ただし、受信用パケットのヘッダ領域とペイロード領域は空領域であるので、1エントリとして、SGLポインタをSGL Descriptor0としてもよい。
第1のノード12−1からステップS120において送信されたライトコマンド送信パケットP11、P12を第2のノード12−2のドライバ24−1が図7(b)のステップS214で受信する。
ドライバ24−1はパケットを受信すると、SQ内のRMコマンドをスキャンし、パケットIDが一致するRMコマンドがあるか否かをチェックする。ライトコマンド送信パケットP11、P12のパケットIDはワイルドカードであるので、ドライバ24−1は、図10(b)に示すパケット受信用パケットRMコマンドR21、R22を見つける。ドライバ24−1は受信したパケットP11、P12のヘッダとデータをパケット受信用パケットP21、P22に対応する物理メモリM22内の領域に格納する。
また、パケットを受信した際、パケットで指定されたパケットIDのRMコマンドがSQに存在しない場合、パケットIDがワイルドカードであるRMコマンドでパケットを受信することができる。
MC14−13は、パケットIDがワイルドカードであるRMコマンドでパケットを受信すると、ステップS215で、即時、ノード12−2に受信完了を通知する。
ステップS216において、ドライバ24−2はパケット受信用パケットP21、P22に対応する物理メモリM22内の領域に格納されたデータを統合して、その統合したデータをストレージ10−2にライトするためのライトコマンド(Write Cmd)Wr20を発行し、ストレージ10−2内のSQに登録する。ストレージ10−2でライトコマンドが実行され、データがストレージ10−2内にライトされる。
ステップS217において、ストレージ10−2がデータをライト完了すると、ストレージ10−2内のCQはノード12−2にライト完了を通知する。
ステップS218において、ドライバ24−2は、ステップS214で受信したライトコマンド送信パケットP11、P12で指定された完了通知パケットIDを使用して完了通知送信パケットP20を作成し、完了通知送信パケットP20を物理メモリM22内に格納し、完了通知送信パケットP20を送信するためのNVMeコマンド、ここではSMコマンドS20をMC14−13内のSQに登録する。
図11は、完了通知送信パケットP20と完了通知送信パケットSMコマンドS20の一例を示す。図11(a)に示すように、完了通知送信パケットP20はヘッダ領域のみからなる。ヘッダ領域はライトコマンドが成功か否かを示すライトコマンド結果と、完了通知送信パケットのパケットIDからなる。図11(b)に示すように、完了通知送信パケットSMコマンドS20は、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はSend Messageであり、16−31バイトのMTPRとDPTRはパケットのSGLポインタであり、完了通知送信パケットはヘッダ領域のみの1エントリなので、SGLポインタはSGL Descriptor0となる。
ステップS220において、MC14−13はSQ内のコマンドを実行し、コマンドで規定されるパケットをLVDS線を介して隣接するMC14へ転送する。ここでは、図11(a)に示す完了通知送信パケットP20が第1のノード12−1へ転送されたとする。MC14−13はLVDS線へのパケットP20の送信が完了したタイミングで割り込みを発生させ、ノード12−2にそれを通知する。
図7(a)のステップS122に示すように、第1のノード12−1のドライバ24−1は、完了通知送信パケットP20を受信すると、SQ内のRMコマンドをスキャンし、パケットIDが一致するRMコマンドがあるか否かをチェックする。ドライバ24−1は、図8(b)に示す完了通知受信用RMコマンドR10を見つける。ドライバ24−1は受信した完了通知送信パケットP20のヘッダを完了通知受信用パケットP10に対応する物理メモリM22内の領域に格納する。
MC14−11はパケットを物理メモリM22に格納すると、ステップS123でパケット管理データ70のTAG毎のパケット番号ビットマップにおける受信したパケット番号に対応するビットを“0”とする。TAG毎のパケット番号ビットマップが全て“0”になると、MC14−13はパケット管理データ70からTAGを削除し、アプリケーションプログラムにライト要求の完了を通知する。パケット管理データ70にTAGが登録されていなければ、パケットを受信すると、即時受信完了が通知される。
なお、ドライバ24−1が定期的にCQをチェックして、CQ内に完了通知があれば、CPU2に割り込みを発生させてもよい。あるいは、ドライバ24−1は、別要因の割り込み発生時にCQをチェックして、CQ内に完了通知があれば、割り込みを発生させてもよい。このように、1パケットの送信毎に割り込みが発生しないので、ノード12のCPU2のリード/ライト処理が中断されることがなく、処理効率が低下することがない。
図12はNVMeコマンドのオペコードの一例を示す。オペコードはコマンドの00−03バイトのCommand Dword 0 (CDW0)の00−07ビットに定義される。Data transferはデータ転送方向を示し、“00b”はデータ転送無、“01b”はノード12からストレージ10へのデータ転送、“10b”はストレージ10からノード12へのデータ転送、“11b”は双方向のデータ転送を示す。O/Mの“O”は任意、“M”は必須を示す。
Send Messageは07ビットが1b、06−02ビットが000 00b、01−00ビットが01b、Combined Opcodeが81hである。なお、SMコマンドのCommand Dword 10-15 (CDW10-CDW15)は図9、図11に示すように、Reservedである。
Receive Messageは07ビットが1b、06−02ビットが000 00b、01−00ビットが10b、Combined Opcodeが82hである。なお、RMコマンドのCommand Dword 10, 11 (CDW11-CDW12)は図8、図10に示すように、通常のパケットIDかワイルドカードである。
[第1のリード処理]
次に、第1のノード12−1が第2のノード(例えば、12−2、ただし、複数の第2のノードでもよい)のストレージ10−2からデータをリードする第1のリード処理の一例を説明する。図13は第1のリード処理におけるパケットの転送の一例を示し、図14、図15はリード処理の一例を示すフローチャートである。図14(a)、図15(a)は第1のノード12−1側の処理、図14(b)、図15(b)は第2のノード12−2側の処理を示す。
次に、第1のノード12−1が第2のノード(例えば、12−2、ただし、複数の第2のノードでもよい)のストレージ10−2からデータをリードする第1のリード処理の一例を説明する。図13は第1のリード処理におけるパケットの転送の一例を示し、図14、図15はリード処理の一例を示すフローチャートである。図14(a)、図15(a)は第1のノード12−1側の処理、図14(b)、図15(b)は第2のノード12−2側の処理を示す。
先ず、図14(a)を参照して第1のノード12−1側の処理を説明する。
ステップS152において、ドライバ24−1は、CPU2が実行するアプリケーションプログラムからリード要求を受信する。リード要求は、第2のノード12−2のストレージ10−2内のデータをリードする要求である。
ステップS154において、ドライバ24−1は、リードデータを格納するための領域を物理メモリM21に確保するために、仮想メモリM11内のリードデータを物理メモリM21の複数のデータに変換(アドレス変換)し、パケットのヘッダのための領域も物理メモリM21内に確保し、SGLを利用して、ヘッダとデータを統合してリードデータを受信するためのパケットP31、P32を作成する。リードデータのサイズに応じて、1つのリード要求に対して複数のパケットが作成されることがある。ここでは、2つのパケットP31、P32が作成される例を示す。図13では、物理メモリM21が断片化されている場合を想定したので、リードデータが物理メモリM21内の複数のデータ領域で受信される例を説明したが、断片化されていない場合は、1つのデータ領域で受信される。
ステップS156において、ドライバ24−1は、リードデータ受信用パケットP31、P32を受信するためのNVMeコマンド、ここではRMコマンド(RMCmd)R31、R32をMC14−11のSQに登録する。
図16は、リード受信用パケットP31、P32とリードデータ受信用パケットを受信するためのRMコマンドR31、R312の一例を示す。図16(a)に示すように、リードデータ受信用パケットP31、P32はヘッダ領域とペイロードからなる。ヘッダ領域は空であり、ペイロードは空のリードデータからなる。ペイロードは、例えば4KiBである。
図16(b)に示すように、リードデータ受信用パケットP31、P32を受信するRMコマンドR31、R32は64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はReceive Messageである。受信用パケットP31、P32はヘッダ領域とペイロードからなり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptorとなる。40−44バイトのパケットIDにはリードデータ送信パケットのパケットIDxxがセットされる。
ステップS157において、MC14−11はSQに登録されたRMコマンドR31、R32に含まれるパケットIDに含まれるTAGがパケット管理データ70に登録済みであるか否かをチェックする。未登録であれば、MC14−11はパケット管理モジュール66を用いてパケット管理データ70にTAGを登録し、パケット番号ビットマップのパケット番号に対応するビットを“1”とする。
ステップS158において、ドライバ24−1は、リードコマンド送信パケットP30を送信するためのNVMeコマンド、ここではSend Message(SM)コマンド(SMCmd)S30をMC14−11のSQに登録する。
図17は、リードコマンド送信パケットP30とリードコマンド送信パケットを送信するSMコマンドS30の一例を示す。図17(a)に示すように、リードコマンド送信パケットP30はヘッダ領域とペイロードからなる。ヘッダ領域は、コマンドがリードコマンドであることを示すリードコマンド情報、パケット識別情報、パケットID(=ワイルドカード)からなり、ペイロードは受信用パケットIDの数(受信用パケットの数)、各受信用パケット毎のパケットIDとデータ長からなる。リードコマンド情報はリードされるデータが格納されているストレージ10−2の領域の論理アドレス及びリードするデータのサイズ(例えば、セクタ数)を含む。パケット識別情報はリードコマンドが複数のパケットからなる場合、リードコマンドであることを示す識別子と、当該パケットが何番目のパケットであるかを示す番号情報を含む。ペイロードは、例えば最長4KiBである。ワイルドカードパケットIDは、例えば0xFFFF FFFF FFFF FFFFである。
図17(b)に示すように、リードコマンド送信パケットP30を送信するSMコマンドS30は64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はSend Messageである。リードコマンド送信パケットはヘッダ領域とペイロードからなり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptorとなる。
ステップS160において、MC14−11はSQ内のコマンドを実行し、コマンドで規定されるパケットをLVDS線を介して隣接するMC14へ転送する。ここでは、図17(a)に示すリードコマンド送信パケットP30が第2のノード12−2へ転送されたとする。MC14−11はLVDS線へのパケットP30の送信が完了したタイミングで割り込みを発生させ、ノード12−1にそれを通知する。
ここで、第2のノード12−2の動作を説明する。ライト処理の場合と同様に、全ノード12は、システムがオンすると、パケット受信用パケットを準備し、パケット受信用のNVMeコマンドを作成し、SQに登録しておく。そのため、第2のノード12−2も、システムがオンすると、図14(b)のステップS252に示すように、物理メモリM22内に、データとヘッダからなり、パケットIDがワイルドカードからなるパケット受信用パケットP40を受信するためのNVMeコマンド、ここではRMコマンド(RMCmd)R40をMC14−13のSQに登録する。なお、第1のノード12−1も受信用パケットのRMコマンドをMC14−11のSQに登録するが、リード処理では使用されないので、図14(a)、図15(a)では説明を省略する。
図18は、パケット受信用パケットP40とパケット受信用パケットを受信するためのNVMeコマンド、ここではRMコマンド(RMCmd)R40の一例を示す。図18(a)に示すように、パケット受信用パケットはヘッダ領域とペイロードからなる。ヘッダ領域は空である。ペイロードはペイロードヘッダとペイロードデータからなり、両方とも空である。ペイロードは、例えば4KiBである。図18(b)に示すように、パケット受信用パケットRMコマンドR40は、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はReceive Messageであり、40−47バイトのCommand Dword 10 (CDW10)、Command Dword 11 (CDW11)にはワイルドカードパケットID(0xFFFF FFFF FFFF FFFF)がセットされる。受信用パケットはヘッダ領域とペイロードがあり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptorとなる。ただし、受信用パケットのヘッダ領域とペイロード領域は空領域であるので、1エントリとして、SGLポインタをSGL Descriptor0としてもよい。
第1のノード12−1からステップS160において送信されたリードコマンド送信パケットP30を第2のノード12−2のドライバ24−2が図15(b)のステップS254で受信する。
ドライバ24−2はパケットを受信すると、SQ内のRMコマンドをスキャンし、パケットIDが一致するRMコマンドがあるか否かをチェックする。リードコマンド送信パケットP30のパケットIDはワイルドカードであるので、ドライバ24−2は、図18(b)に示すパケット受信用パケットRMコマンドR40を見つける。ドライバ24−2は受信したリードコマンド送信パケットP30をパケット受信用パケットRMコマンドR40に対応する物理メモリM22内の領域に格納する。
MC14−13は、パケットIDがワイルドカードであるRMコマンドでパケットを受信すると、ステップS255で、即時、ノード12−2に受信完了を通知する。
ステップS256において、ドライバ24−2は物理メモリM22内にデータをリードするデータ領域を確保し、データをストレージ10−2からリードするためのリードコマンド(Read Cmd)Re40を発行し、ストレージ10−2内のSQに登録する。ストレージ10−2でリードコマンドが実行され、リードデータが物理メモリM22内に書き込まれる。リードコマンドRe40の完了すると、CQで通知される。
ステップS258において、ドライバ24−2は、ステップS254で受信したリードコマンド送信パケットP30で指定された受信用パケットIDを使用してリードデータ送信パケットP41、P42を作成し、リードデータ送信パケットP41、P42を送信するためのNVMeコマンド、ここではSMコマンドS41、S42をMC14−13のSQに登録する。
図19は、リードデータ送信パケットP41、P42とリードデータ送信パケットSMコマンドS41、S42の一例を示す。図19(a)に示すように、リードデータ送信パケットP41、P42はヘッダ領域とペイロードからなる。ヘッダ領域は、リードコマンド情報、パケット識別情報、パケットID(=PktIDxx)からなる。なお、パケットIDが指定されているので、パケット識別情報は必須ではなく、省略可能である。ペイロードはリードデータからなり、最長サイズは、例えば4KiBである。図19(b)に示すように、リードデータ送信パケットSMコマンドS41、S42は、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はSend Messageである。リードデータ送信パケットはヘッダ領域とペイロードからなり、少なくとも2エントリになるため、16−31バイトのSGLポインタはSGL Segment Descriptorとなる。
ステップS260において、MC14−13はSQ内のコマンドを実行し、コマンドで規定されるパケットをLVDS線を介して隣接するMC14へ転送する。ここでは、図19(a)に示すリードデータ送信パケットP41、P42が第1のノード12−1へ転送されたとする。
図15(a)のステップS162に示すように、第1のノード12−1のドライバ24−1は、リードデータ送信パケットP41、P42を受信すると、SQ内のRMコマンドをスキャンし、パケットIDが一致するRMコマンドがあるかをチェックする。ドライバ24−1は、図16(b)に示すリードデータ受信用パケットRMコマンドR31、R32を見つける。ドライバ24−1は受信したリードデータ送信パケットP41、P42のヘッダとデータをリードデータ受信用パケットRMコマンドR31、R32のリードデータ受信用パケットP31、P32に対応する物理メモリM21内の領域に格納する。
MC14−11はパケットを物理メモリM21に格納すると、ステップS163でパケット管理データ70のTAG毎のパケット番号ビットマップにおける受信したパケット番号に対応するビットを“0”とする。TAG毎のパケット番号ビットマップが全て“0”になると、MC14−11はパケット管理データ70からTAGを削除し、アプリケーションプログラムにリード要求の完了を通知する。パケット管理データ70にTAGが登録されていなければ、パケットを受信すると、即時受信完了が通知される。
なお、ドライバ24−1が定期的にCQをチェックして、CQ内に完了通知があれば、割り込みを発生してもよい。あるいは、ドライバ24−1は、別要因の割り込み発生時にCQをチェックして、CQ内に完了通知があれば、割り込みを発生してもよい。このように、1パケットの送信毎に割り込みが発生しないので、ノード12のCPU2のリード、ライト処理が中断され、処理効率が低下することがない。
[第2のリード/ライト処理]
第1のリード/ライト処理では、パケットの送信についてSend MessageとReceive Messageの2種類のNVMeコマンドが用いられた。次に、3種類のNVMeコマンドを用いる第2のリード/ライト処理の例を説明する。第1の処理では、ノード12の物理メモリM21、M22内にパケット受信用パケットのデータを格納する領域を確保している。第2の処理では、MC14内の物理メモリ内に受信パケットに関する管理データを格納するスロットを設ける。受信パケットに関する管理データは、スロットが受信できるパケットのパケットIDと、受信したパケットを格納するノード12内の物理メモリM21、M22へのポインタ等を含む。
第1のリード/ライト処理では、パケットの送信についてSend MessageとReceive Messageの2種類のNVMeコマンドが用いられた。次に、3種類のNVMeコマンドを用いる第2のリード/ライト処理の例を説明する。第1の処理では、ノード12の物理メモリM21、M22内にパケット受信用パケットのデータを格納する領域を確保している。第2の処理では、MC14内の物理メモリ内に受信パケットに関する管理データを格納するスロットを設ける。受信パケットに関する管理データは、スロットが受信できるパケットのパケットIDと、受信したパケットを格納するノード12内の物理メモリM21、M22へのポインタ等を含む。
第2の処理で使われるパケットの送信に関するコマンドは、スロットを確保してからパケットを送信する送信コマンドRSend(Reserve Send)と、スロットを確保しないでパケットを送信する送信コマンドSendがある。
第2の処理では、パケットの送信に関係せず、パケットを受信するためのスロットを確保するだけのスロット確保コマンド(Wildcard)もある。パケットを受信するためには、スロットが必要であり、パケットIDがワイルドカードIDに設定されたパケットを受信できるスロットを確保するためのコマンドがスロット確保コマンドである。スロット確保コマンドは、第1のリード/ライト処理で説明したパケットIDがワイルドカードIDに設定されたパケットを受信するためのRMコマンドに相当する。スロット確保コマンド(Wildcard)の一例を図20に示す。スロット確保コマンド(Wildcard)は、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はWildcardであり、16−23バイトのMetadata Pointer (MPTR)は受信したパケットのヘッダを格納する物理メモリの領域を示すSGLポインタであり、24−31バイトのData Pointer (DPTR)は受信したパケットのデータを格納する物理メモリの領域を示すSGLポインタである。スロット確保コマンド(Wildcard)が実行されると、パケットの受信待ちとなり、1コマンドで1パケットの受信を担う。
スロット確保コマンド(Wildcard)の実行により、確保されたスロットをワイルドカードスロットと称する。一方、送信コマンドRSend(Reserve Send)の実行により確保されたスロットをリザーブドスロットと称する。リザーブドスロットはパケットの送信に用いられるとともに、送信したパケットに対する応答のパケットの受信にも用いられる。一方、ワイルドカードスロットはパケットの受信専用のスロットである。
図21はキューSQ、CQの概念を示す。3種類のコマンドそれぞれ毎にキューが設けられる。RSendコマンドは専用のキューSQaに登録され、Sendコマンドも専用のキューSQbに登録され、Wildcardコマンドも専用のキューSQcに登録される。CQもSQに対応して3種類のコマンドそれぞれ毎に設けられる。
コマンド登録のためのSQが1つであると、スロットを確保するために多数のRSendコマンドがSQに登録されると、Sendコマンドが登録できない場合がある。Sendコマンドが実行できないと、他ノードとデッドロック状態になる可能性がある。1つのSQに後から登録されたSendコマンドを実行するジョブが先から登録されたRSendコマンドを実行するジョブを追い越す制御は困難であるが、コマンド毎にキューを設け、コマンド毎のキューSQa、SQb、SQcの優先度を適宜異ならせると、デッドロック状態を回避できる。あるいは、キューSQa、SQb、SQcの優先度が同じでも、ラウンドロビン方式で3つのキューのジョブを順番に実行させれば、デッドロック状態を回避できる。なお、第1のリード/ライト処理でも図5、図13に示すSQ、CQをSend MessageコマンドとReceive Messageコマンド毎に設けてもよい。
[第2のリード処理]
図22を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2のノードでもよい)のストレージ10−2からデータをリードする第2のリード処理の一例を説明する。
図22を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2のノードでもよい)のストレージ10−2からデータをリードする第2のリード処理の一例を説明する。
先ず、各ノードはシステムオンすると適宜な数のWildcardコマンドをキューSQcに登録し、このコマンドを実行することにより、Wildcardスロットを作成しているとする。
第1のノード12−1のドライバ24−1は、CPU2が実行するアプリケーションプログラムからリード要求を受信する。リード要求は、第2のノード12−2のストレージ10−2内のデータをリードする要求である。
ドライバ24−1は、ノード12−2のドライバ24−2に接続されているMC14−13のワイルドカードスロットに対して送信されるリードコマンド送信パケット302を作成し、パケット302を物理メモリ内に格納する。
図23はリードコマンド送信パケット302の一例を示し、図24はそれを送信するためのスロット確保送信コマンドRSendの一例を示す。図23に示すリードコマンド送信パケット302はヘッダ領域とペイロードからなる。ヘッダ領域は送信先(ここでは、ノード12−1)ノードアドレス、送信元が確保したスロットID(ここでは、MC14―11によりSL1が登録される)、送信先スロットID(ここでは、ワイルドカードスロット)、パケット番号情報、パケットID(ここでは、ワイルドカード)、送信先で何をさせるかを示すコマンド情報(ここでは、リード)等を含む。ワイルドカードスロットとは、相手側の送信先スロットのIDが分からないので、任意のワイルドカードスロット宛とするものである。相手側のノード12−2でスロットSL2が空いており、パケットがスロットSL2で受信されるとする。ワイルドカードパケットIDは任意のIDである。ノード12−2が応答を返す際に同じIDを指定し、ノード12−1で応答を受信する際、スロットDL1に登録されたパケットIDと一致しているパケットIDを有する応答のみ受信するためにワイルドカードパケットIDは利用される。ワイルドカードパケットIDは、他のノードが誤ってノード12−1のスロットSL1に対してパケットを送っても、スロットSL1が間違って受信しないようにするためのシグネチャーである。パケット番号情報はコマンドを送信するパケットが複数ある場合、当該パケットが何番目のパケットであるかを示す。コマンド情報はリードされるデータが格納されているストレージ10の領域の論理アドレス及びリードするデータのサイズ(例えば、セクタ数)を含む。リード処理では、送信するデータは無いので、ペイロードは空である。
図24に示すスロット確保送信コマンドRSendのパケットを送信するとともに、受信するためのコマンドである。スロット確保送信コマンドRSendは、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はReserve Sendであり、16−23バイトのMetadata Pointer (MPTR)はパケットのヘッダ領域が格納されている物理メモリの領域を示すSGLポインタであり、24−31バイトのDate Pointer (DPTR)は送信データが格納されている物理メモリの領域を示すSGLポインタであり、32−39バイトのDate Pointer (DPTR)は受信データが格納されている物理メモリの領域を示すSGLポインタであり、40−43バイトのCommand Dword 10 (CDW10)は送信パケット数であり、44−47バイトのCommand Dword 11 (CDW11)は受信パケット数である。リードコマンド送信パケットは1つであるが、RSendコマンドは複数のパケットを送信することも受信することもできるので、送信パケット数、受信パケット数を含む。なお、ヘッダ領域のSGLもデータと同様に送信パケット用と受信パケット用に分かれていてもよい。
ドライバ24−1は、図23に示すリードコマンド送信パケット302が格納されている物理メモリの領域を示すSGLポインタを図24に示すRSendコマンドの16−23バイトのMPTRにセットし、リードデータ受信用の領域を指すSGLを32−39バイトのDPTRにセットし、リードコマンド送信パケット数(=1)を40−43バイトのCDW10にセットし、リードデータのサイズに応じた受信パケット数を44−47バイトのCDW11にセットし、RSendコマンド304をSQaに登録する。
MC14−11は、スロット確保送信コマンドRSendを実行し、スロットSL1を確保して、確保したスロットのIDであるSL1をパケットヘッダの送信元スロットに格納してからリードコマンド送信パケットをLVDS線を介して送信させる。
ノード12−2に接続されるMC14−13にリードコマンド送信パケットが到達すると、MC14−13はパケットのヘッダ領域の送信先スロットIDで指定されたワイルドカードスロットの中で空いているスロット、ここではSL2でリードコマンド送信パケットを受信する。ノード12−2のドライバ24−2はパケットのヘッダ領域のリードコマンド情報に基づいて、ストレージ10−2の指定された論理アドレスの領域からデータをリードするためのリードコマンドを図示しないストレージ10−2のSQに登録する。ドライバ24−2はSQを使わずに、ストレージ10−2からデータをリードしてもよい。ストレージ10−2がリードコマンドを実行して、リードデータが得られ、リードデータは物理メモリ内に格納される。
ドライバ24−2は、ヘッダを作成し、ヘッダを物理メモリに格納する。ドライバ24−2はヘッダ領域とリードデータからなるリードデータ送信パケット306を作成する。リードデータのサイズに応じて複数のリードデータ送信パケット306が作成される。
図25はリードデータ送信パケット306の一例を示し、図26はそれを送信するためのスロット確保無し送信コマンドSendの一例を示す。図25に示すリードデータ送信パケット306はヘッダ領域とペイロードからなる。ヘッダ領域は送信先(ここでは、ノード12−2)ノードアドレス、送信元スロットID(Sendコマンドはスロットを確保しないので、未定義)、送信先スロットID(ここでは、リザーブドスロットSL1)、パケット番号情報、パケットID、コマンド情報(ここでは、リード要求のリプライ)等を含む。パケットIDはスロット確保の際にスロットと紐づけられて登録されるパケット固有のIDであり、リード要求パケットに格納されていたパケットIDが登録される。ペイロードにはリードデータが含まれる。
図26に示すスロット確保無し送信コマンドSendは、パケットを送信するだけのコマンドである。スロット確保無し送信コマンドSendは、例えば64バイトからなり、00−03バイトのCommand Dword 0 (CDW0)はSendであり、16−23バイトのMetadata Pointer (MPTR)はパケットのヘッダ領域のためのSGLポインタであり、24−31バイトのDate Pointer (DPTR)はリードデータのためのSGLポインタであり、40−43バイトのCommand Dword 10 (CDW10)は送信パケット数である。Sendコマンドは複数のパケットを送信することができるので、送信パケット数を含む。
ドライバ24−2は、図25に示すリードデータ送信パケット306のヘッダ領域が格納されている物理メモリの領域を示すSGLポインタを図26に示すSendコマンドの16−23バイトのMPTRにセットし、ペイロード305が格納されている物理メモリの領域を示すSGLポインタを24−31バイトのDPTRにセットし、リードデータ送信パケット306の数をSendコマンドの40−43バイトのCDW10にセットし、Sendコマンド308をSQbに登録する。
MC14−13は、スロット確保無し送信コマンドSendを実行し、リードデータ送信パケット306(複数の場合もある)をLVDS線を介して送信させる。
ノード12−1に接続されるMC14−11にリードデータ送信パケットが到達すると、MC14−11はパケットのヘッダ領域の送信先スロットIDで指定されたリザーブドスロットSL1でリードデータ送信パケットを受信する。MC14−11はパケットのヘッダ領域のパケット番号情報に基づいて全てのリードデータ送信パケットを受信したことを検出すると、全パケットのペイロード310を物理メモリに転送し書き込み、リード要求の完了をアプリケーションに送る。MC14−11は複数のパケットそれぞれを受信する度にパケットのペイロード310を物理メモリに転送してもよい。その場合でも、リード要求の完了をアプリケーションに送るのは、全てのリードデータ送信パケットを受信した時のみである。
[第2のライト処理]
図27を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2ノードでもよい)のストレージ10−2へデータをライトする第2のライト処理の一例を説明する。
図27を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2ノードでもよい)のストレージ10−2へデータをライトする第2のライト処理の一例を説明する。
ここでも、各ノードはシステムオンすると適宜な数のWildcardコマンドをキューSQcに登録し、このコマンドを実行することにより、Wildcardスロットを作成しているとする。
ノード12−1のドライバ24−1は、CPU2が実行するアプリケーションプログラムからライト要求を受信する。ライト要求は、第2のノード12−2のストレージ10−2へデータをライトする要求である。
ドライバ24−1は、ノード12−2に接続されているMC14−13のワイルドカードスロットに対して送信されるライト予約コマンド送信パケット402を作成し、パケット402を物理メモリ内に格納する。ライト予約コマンド送信パケット402はヘッダ領域のみからなる。ヘッダ領域は送信先(ここでは、ノード12−2)ノードアドレス、送信元が確保したスロットID(ここでは、リザーブドスロットSL1)、送信先スロットID(ここでは、ワイルドカードスロット)、パケット番号情報、パケットID(ここでは、今回のライト要求に割り振られた固有のパケットID)、コマンド情報(ここでは、ライト予約)等を含む。ライト予約処理では、送信するデータは無いので、ペイロードは空である。
ドライバ24−1は、ライト予約コマンド送信パケット402のヘッダが格納されている物理メモリの領域を示すSGLポインタを図24に示すRSendコマンドの16−23バイトのMPTRにセットし、受信パケットのデータを格納する物理メモリの領域を示すSGLポインタを32−39バイトのDPTRにセットし、送信パケット数(=1)を40−43バイトのCDW10にセットし、受信パケット数(=1)を44−47バイトのCDW11にセットし、RSendコマンド404をSQaに登録する。
MC14−11は、スロット確保送信コマンドRSendを実行し、スロットSL1を確保して、確保したスロットのIDであるSL1をパケットヘッダの送信元スロットに格納してからライト予約コマンド送信パケットをLVDS線を介して送信させる。
ノード12−2に接続されるMC14−13にライト予約コマンド送信パケットが到達すると、MC14−13はパケットのヘッダ領域の送信先スロットIDで指定されたワイルドカードスロットの中で空いているスロット、ここではSL2でライト予約コマンド送信パケットを受信する。ノード12−2のドライバ24−2はパケットのヘッダ領域のライト予約コマンド情報に基づいて、ライト予約を行う。ライト予約はライトデータを格納する領域を物理メモリ内に確保し、及びライトデータ受信用のスロットを確保することである。
ドライバ24−2は、MC14−11のリザーブドスロットSL1に対して送信されるライト予約完了通知送信パケット406を作成し、パケット406を物理メモリ内に格納する。ライト予約完了通知送信パケット406はヘッダ領域のみからなる。ヘッダ領域は送信先(ここでは、ノード12−1)ノードアドレス、送信元が確保したスロットID(ここでは、MC14−13によりSL3が登録される)、送信先スロットID(ここでは、リザーブドスロットSL1)、パケット番号情報、パケットID、コマンド情報(ここでは、ライトデータ送信)等を含む。ライト予約完了通知処理では、送信するデータは無いので、ペイロードは空である。
ドライバ24−2は、ライト予約完了通知送信パケット406が格納されている物理メモリの領域を示すSGLポインタを図24に示すRSendコマンドの16−23バイトのMetadata Pointer (MPTR)にセットし、受信パケットのデータを格納する物理メモリの領域を示すSGLポインタを32−39バイトのDPTRにセットし、送信パケット数(=1)を40−43バイトのCDW10にセットし、ライトデータのサイズに応じた受信パケット数を44−47バイトのCDW11にセットし、RSendコマンド408をSQaに登録する。
MC14−13は、スロット確保送信コマンドRSendを実行し、スロットSL3を確保して、確保したスロットのIDであるSL3をパケットヘッダの送信元スロットに登録してからライト予約完了通知送信パケットをLVDS線を介して送信させる。
ノード12−1に接続されるMC14−11にライト予約完了通知送信パケットが到達すると、MC14−11はパケットのヘッダ領域の送信先スロットIDで指定されたリザーブドスロットSL1でライト予約完了通知送信パケットを受信する。ノード12−1のドライバ24−1はパケットのヘッダ領域のライトデータ送信コマンド情報に基づいて、ライトデータ送信を行う。
ライトデータ送信のために、ドライバ24−1は、MC14−13のリザーブドスロットSL3に対して送信されるライトデータ送信パケット412を作成し、パケット412を物理メモリ内に格納する。ライトデータ送信パケット412はヘッダ領域とペイロードからなる。ヘッダ領域は送信先(ここでは、ノード12−2)ノードアドレス、送信元が確保したスロットID(ここでは、MC14−11によりSL4が登録される)、送信先スロットID(ここでは、リザーブドスロットSL3)、パケット番号情報、パケットID、コマンド情報(ここでは、ライト)等を含む。コマンド情報はデータがライトされるストレージ10の領域の論理アドレスも含む。ペイロードはライトデータである。ライトデータのサイズが1パケットのペイロードに収まらない場合は、複数のライトデータ送信パケットが作成される。
ドライバ24−1は、ライトデータ送信パケット412のヘッダが格納されている物理メモリの領域を示すSGLポインタを図24に示すRSendコマンドの16−23バイトのMPTRにセットし、ライトデータを格納する物理メモリの領域を示すSGLポインタを24−31バイトのDPTRにセットし、ライトデータ送信パケットの数を40−43バイトのCDW10にセットし、受信パケット数(=1)を44−47バイトのCDW11にセットし、RSendコマンド414をSQaに登録する。
MC14−11は、スロット確保送信コマンドRSendを実行し、スロットSL4を確保して、確保したスロットのIDであるSL4をパケットヘッダの送信元スロットに格納してからライトデータ送信パケットをLVDS線を介して送信させる。
ノード12−2に接続されるMC14−13にライトデータ送信パケットが到達すると、MC14−13はパケットのヘッダ領域の送信先スロットIDで指定されたリザーブドスロットSL3でライトデータ送信パケットを受信する。ノード12−2のドライバ24−2はパケットのヘッダ領域のライトコマンド情報に基づいて、ライトデータをストレージ10−2の指定された論理アドレスの領域へライトするためのライトコマンドを図示しないストレージ10−2のSQに登録する。ドライバ24−2はSQを使わずに、ストレージ10−2にデータをライトしてもよい。ストレージ10−2がライトコマンドを実行する。
ストレージ10−2のライト処理が完了すると、ドライバ24−2は、MC14−11のリザーブドスロットSL4に対して送信されるライト完了通知送信パケット418を作成し、パケット418を物理メモリ内に格納する。ライト完了通知送信パケット416はヘッダ領域のみからなる。ヘッダ領域は送信先(ここでは、ノード12−1)ノードアドレス、送信先スロットID(ここでは、リザーブドスロットSL4)、パケット番号情報、パケットID、コマンド情報(ここでは、ライト完了)等を含む。
ドライバ24−2は、ライト完了通知送信パケット418のヘッダが格納されている物理メモリの領域を示すSGLポインタを図26に示すSendコマンドの16−23バイトのMPTRにセットし、送信パケット数(=1)を40−43バイトのCDW10にセットし、Sendコマンド420をSQbに登録する。
MC14−13は、Sendコマンドを実行し、ライト完了通知送信パケットをLVDS線を介して送信させる。
ノード12−1に接続されるMC14−11にライト完了通知送信パケットが到達すると、MC14−11はパケットのヘッダ領域の送信先スロットIDで指定されたリザーブドスロットSL4でライト完了通知送信パケットを受信し、ドライバ24−1はアプリケーションプログラムへライト要求の完了を通知する。
[第3のライト処理]
図28を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2ノードでもよい)のストレージ10−2へデータをライトする第3のライト処理の一例を説明する。第3のライト処理は第2のライト処理の変形に関するものであり、第2のライト処理では第1のノード12−1は2つのスロットをリザーブする必要があったが、第3のライト処理では第1のノード12−1は1つのスロットをリザーブするだけでよい。
図28を参照して、第1のノード12−1が第2のノード(例えば、ノード12−2、ただし複数の第2ノードでもよい)のストレージ10−2へデータをライトする第3のライト処理の一例を説明する。第3のライト処理は第2のライト処理の変形に関するものであり、第2のライト処理では第1のノード12−1は2つのスロットをリザーブする必要があったが、第3のライト処理では第1のノード12−1は1つのスロットをリザーブするだけでよい。
第1のノード12−1からRSendコマンド404によりライト予約コマンド送信パケット402がRSendコマンド404により送信されるまでは、第2のライト処理と同じである。
ドライバ24−2はライト予約を完了すると、MC14−11のワイルドカードスロットに対して送信されるライトデータ要求送信パケット432を作成し、パケット432を物理メモリ内に格納する。ライトデータ要求送信パケット432はヘッダ領域のみからなる。ヘッダ領域は送信先(ここでは、ノード12−1)ノードアドレス、送信元が確保したスロットID(ここでは、MC14−13によりSL3が登録される)、送信先スロットID(ここでは、ワイルドカードスロット)、パケット番号情報、パケットID、コマンド情報(ここでは、ライトデータ送信)等を含む。ライトデータ要求処理では、送信するデータは無いので、ペイロードは空である。
ドライバ24−2は、ライトデータ要求送信パケット432が格納されている物理メモリの領域を示すSGLポインタを図24に示すRSendコマンドの16−23バイトのMPTRにセットし、ライトデータを受信するための物理メモリを指すSGLを32−39バイトのDPTRにセットし、送信パケット数(=1)を40−43バイトのCDW10にセットし、ライトデータのサイズに応じた受信パケット数を44−47バイトのCDW11にセットし、RSendコマンド434をSQaに登録する。
MC14−13は、スロット確保送信コマンドRSendを実行し、スロットSL3を確保して、確保したスロットのIDであるSL3をパケットヘッダの送信元スロットに格納してからライトデータ要求送信パケットをLVDS線を介して送信させる。
ノード12−1に接続されるMC14−11にライトデータ要求送信パケットが到達すると、MC14−11はパケットのヘッダ領域の送信先スロットIDで指定されたワイルドカードスロットの中で空いているスロット、ここではSL4でライトデータ要求送信パケットを受信する。ノード12−1のドライバ24−1はパケットのヘッダ領域のライトデータ送信コマンド情報に基づいて、ライトデータ送信を行う。
ライトデータ送信のために、ドライバ24−1は、MC14−13のリザーブドスロットSL3に対して送信されるライトデータ送信パケット412を作成し、パケット412を物理メモリ内に格納する。ライトデータ送信パケット412はヘッダ領域とペイロードからなる。ヘッダ領域は送信先(ここでは、ノード12−2)ノードアドレス、送信先スロットID(ここでは、リザーブドスロットSL3)、パケット番号情報、パケットID、コマンド情報(ここでは、ライト)等を含む。コマンド情報はデータがライトされるストレージ10の領域の論理アドレスも含む。ペイロードはライトデータである。ライトデータのサイズが1パケットのペイロードに収まらない場合は、複数のライトデータ送信パケットが作成される。
ドライバ24−1は、ライトデータ送信パケット412のヘッダが格納されている物理メモリの領域を示すSGLポインタを図26に示すSendコマンドの16−23バイトのMPTRにセットし、ライトデータを格納する物理メモリの領域を示すSGLポインタを24−31バイトのDPTRにセットし、ライトデータ送信パケットの数を40−43バイトのCDW10にセットし、Sendコマンド436をSQbに登録する。
MC14−11は、Sendコマンドを実行し、ライトデータ送信パケットをLVDS線を介して送信させる。
ノード12−2に接続されるMC14−13にライトデータ送信パケットが到達すると、MC14−13はパケットのヘッダ領域の送信先スロットIDで指定されたリザーブドスロットSL3でライトデータ送信パケットを受信する。この後、第2のライト処理と同様に、ライト処理、Sendコマンドによるライト完了通知送信パケットの送信が行われる。ただし、ライト完了通知送信パケットの送信は第2のリザーブドスロットSL4ではなく、ライト予約コマンド送信パケットを送信した第1のリザーブドスロットSL1である点が異なる。
なお、本発明は上記実施形態そのままに限定されるものではなく、実施段階ではその要旨を逸脱しない範囲で構成要素を変形して具体化できる。また、上記実施形態に開示されている複数の構成要素の適宜な組み合せにより種々の発明を形成できる。例えば、実施形態に示される全構成要素から幾つかの構成要素を削除してもよい。更に、異なる実施形態に亘る構成要素を適宜組み合せてもよい。
10…ストレージ、12…ノード、14…MC、24…ドライバ、26…アクセス要求パケット管理モジュール、28…送受信コマンド発行管理モジュール、70…パケット管理データ。
Claims (17)
- 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムであって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージから第1データをリードする場合、前記第1データを含む複数の第1パケットを受信するための領域をメモリに確保し、前記複数の第1パケットを受信するための第1コマンドを前記第1コントローラに接続される第1パケット転送部の第1キューに登録し、前記第1データの送信を要求するための第2パケットを前記メモリに格納し、前記第2パケットを送信するための第2コマンドを前記第1パケット転送部の前記第1キューに登録し、
前記第1パケット転送部は、第1コマンドを受信した場合、前記複数の第1パケットを全て受信すると、前記第1コマンドの完了通知を第2キューに登録し、前記第2コマンドを受信した場合、前記第2パケットの送信が完了すると、前記第2コマンドの完了通知を前記第2キューに登録するストレージシステム。 - 前記メモリは前記第1コントローラのメインメモリの物理アドレス領域である請求項1記載のストレージシステム。
- 前記第1コントローラは、前記複数のストレージの中の第2ストレージへ第2データをライトする場合、ライト完了通知を含む第3パケットを受信するための領域を前記メモリに確保し、前記第3パケットを受信するための第1コマンドを前記第1キューに登録し、前記第2データを含む複数の第4パケットを前記メモリに格納し、前記複数の第4パケットを送信するための第2コマンドを前記第1キューに登録し、
前記第1パケット転送部は、前記複数の第1パケット又は前記第3パケットを受信するための第1コマンドを受信した場合、前記複数の第1パケットを全て受信する、又は前記第3パケットを受信すると、前記第1コマンドの前記完了通知を前記第2キューに登録し、前記第2パケット又は前記第4パケットを送信するための前記第2コマンドを受信した場合、前記第2パケット又は前記第4パケットの送信が完了すると、前記第2コマンドの完了通知を前記第2キューに登録する請求項1記載のストレージシステム。 - 前記第1パケットは空領域のヘッダと、空領域のペイロードからなり、
前記第2パケットはリードコマンド情報、パケット識別情報、ワイルドカードがセットされたパケットIDを含むヘッダ領域と、複数の前記第1パケットの総数、各第1パケットのパケットIDとデータ長を含むペイロードならなる請求項1記載のストレージシステム。 - 前記第3パケットは空領域のヘッダと、空領域のペイロードからなり、
前記第4パケットはライトコマンド情報、パケット識別情報、ワイルドカードがセットされたパケットIDを含むヘッダ領域と、前記第2データを含むペイロードならなる請求項3記載のストレージシステム。 - 前記第1パケット転送部は、前記第1コマンドを受信した場合、前記複数の第1パケットのパケット番号がセットされるビットマップデータを具備し、前記ビットマップデータは前記複数の第1パケットを受信する毎に対応するパケット番号がクリアされ、前記ビットマップデータが全てクリアされると、前記第1コマンドの完了通知を前記第1コントローラへ送信する請求項1記載のストレージシステム。
- 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムであって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージから第1データをリードする場合、前記第1データのリードを要求するための第1パケットをメモリに格納し、前記第1パケットを、前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1パケット転送部は、前記第1データを含む第2パケットを前記第1スロットを介して受信し、リード完了を前記第1コントローラへ送信するストレージシステム。 - 前記メモリは前記第1コントローラのメインメモリの物理アドレス領域である請求項7記載のストレージシステム。
- 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムであって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージへ第1データをライトする場合、前記第1データのライトを予約するための第1パケットをメモリに格納し、前記第1パケットを前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1コントローラは、前記第1パケット転送部がライト予約完了を通知するための第2パケットを前記第1スロットを介して受信すると、前記第1データを含む第3パケットを前記メモリに格納し、前記第3パケットを前記第1コントローラに接続される第1パケット転送部の第2スロットを介して送信するための第3コマンドを前記第1パケット転送部のキューに登録し、
前記第1パケット転送部はライト完了を通知するための第4パケットを前記第2スロットを介して受信すると、前記ライト完了を前記第1コントローラへ送信するストレージシステム。 - 前記メモリは前記第1コントローラのメインメモリの物理アドレス領域である請求項9記載のストレージシステム。
- 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムであって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージへ第1データをライトする場合、前記第1データのライトを予約するための第1パケットをメモリに格納し、前記第1パケットを前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1コントローラは、前記第1パケット転送部がライトデータ要求を含む第2パケットを第2スロットを介して受信すると、前記第1データを含む第3パケットを前記メモリに格納し、前記第3パケットを送信するための第3コマンドを前記キューに登録し、
前記第1パケット転送部はライト完了を通知するための第4パケットを前記第1スロットを介して受信すると、前記ライト完了を前記第1コントローラへ送信するストレージシステム。 - 前記メモリは前記第1コントローラのメインメモリの物理アドレス領域である請求項11記載のストレージシステム。
- 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムにおけるデータ転送方法であって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージから第1データをリードする場合、前記第1データを含む複数の第1パケットを受信するための領域をメモリに確保し、前記複数の第1パケットを受信するための第1コマンドを前記第1コントローラに接続される第1パケット転送部の第1キューに登録し、前記第1データの送信を要求するための第2パケットを前記メモリに格納し、前記第2パケットを送信するための第2コマンドを前記第1パケット転送部の前記第1キューに登録し、
前記第1パケット転送部は、第1コマンドを受信した場合、前記複数の第1パケットを全て受信すると、前記第1コマンドの完了通知を第2キューに登録し、前記第2コマンドを受信した場合、前記第2パケットの送信が完了すると、前記第2コマンドの完了通知を前記第2キューに登録するデータ転送方法。 - 前記第1コントローラは、前記複数のストレージの中の第2ストレージへ第2データをライトする場合、ライト完了通知を含む第3パケットを受信するための領域を前記メモリに確保し、前記第3パケットを受信するための第1コマンドを前記第1キューに登録し、前記第2データを含む複数の第4パケットを前記メモリに格納し、前記複数の第4パケットを送信するための第2コマンドを前記第1キューに登録し、
前記第1パケット転送部は、前記複数の第1パケット又は前記第3パケットを受信するための第1コマンドを受信した場合、前記複数の第1パケットを全て受信する、又は前記第3パケットを受信すると、前記第1コマンドの前記完了通知を前記第2キューに登録し、前記第2パケット又は前記第4パケットを送信するための前記第2コマンドを受信した場合、前記第2パケット又は前記第4パケットの送信が完了すると、前記第2コマンドの完了通知を前記第2キューに登録する請求項13記載のデータ転送方法。 - 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムにおけるデータ転送方法であって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージから第1データをリードする場合、前記第1データのリードを要求するための第1パケットをメモリに格納し、前記第1パケットを、前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1パケット転送部は、前記第1データを含む第2パケットを前記第1スロットを介して受信し、リード完了を前記第1コントローラへ送信するデータ転送方法。 - 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムにおけるデータ転送方法であって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージへ第1データをライトする場合、前記第1データのライトを予約するための第1パケットをメモリに格納し、前記第1パケットを前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1コントローラは、前記第1パケット転送部がライト予約完了を通知するための第2パケットを前記第1スロットを介して受信すると、前記第1データを含む第3パケットを前記メモリに格納し、前記第3パケットを前記第1コントローラに接続される第1パケット転送部の第2スロットを介して送信するための第3コマンドを前記第1パケット転送部のキューに登録し、
前記第1パケット転送部はライト完了を通知するための第4パケットを前記第2スロットを介して受信すると、前記ライト完了を前記第1コントローラへ送信するデータ転送方法。 - 複数のストレージと、前記複数のストレージに接続される複数のコントローラと、前記複数のコントローラに接続される複数のパケット転送部と、を具備するストレージシステムにおけるデータ転送方法であって、
前記複数のストレージの中の第1ストレージに接続される第1コントローラは、前記複数のストレージの中の第2ストレージへ第1データをライトする場合、前記第1データのライトを予約するための第1パケットをメモリに格納し、前記第1パケットを前記第1コントローラに接続される第1パケット転送部の第1スロットを介して送信するための第1コマンドを前記第1パケット転送部のキューに登録し、
前記第1コントローラは、前記第1パケット転送部がライトデータ要求を含む第2パケットを第2スロットを介して受信すると、前記第1データを含む第3パケットを前記メモリに格納し、前記第3パケットを送信するための第3コマンドを前記キューに登録し、
前記第1パケット転送部はライト完了を通知するための第4パケットを前記第1スロットを介して受信すると、前記ライト完了を前記第1コントローラへ送信するデータ転送方法。
Priority Applications (2)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018053280A JP2019164713A (ja) | 2018-03-20 | 2018-03-20 | ストレージシステム及びデータ転送方法 |
US16/114,746 US10599365B2 (en) | 2018-03-20 | 2018-08-28 | Storage system |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
JP2018053280A JP2019164713A (ja) | 2018-03-20 | 2018-03-20 | ストレージシステム及びデータ転送方法 |
Publications (1)
Publication Number | Publication Date |
---|---|
JP2019164713A true JP2019164713A (ja) | 2019-09-26 |
Family
ID=67985192
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
JP2018053280A Pending JP2019164713A (ja) | 2018-03-20 | 2018-03-20 | ストレージシステム及びデータ転送方法 |
Country Status (2)
Country | Link |
---|---|
US (1) | US10599365B2 (ja) |
JP (1) | JP2019164713A (ja) |
Cited By (1)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US12014173B2 (en) | 2020-06-09 | 2024-06-18 | Huawei Technologies Co., Ltd. | Data processing method for network adapter and network adapter |
Families Citing this family (3)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
CN112988623B (zh) * | 2019-12-17 | 2021-12-21 | 北京忆芯科技有限公司 | 加速sgl处理的方法与存储设备 |
CN113010111A (zh) * | 2021-03-05 | 2021-06-22 | 深圳忆联信息系统有限公司 | Ssd访问加速方法、装置、计算机设备及存储介质 |
US20240168876A1 (en) * | 2022-11-22 | 2024-05-23 | Samsung Electronics Co., Ltd. | Solving submission queue entry overflow using metadata or data pointers |
Family Cites Families (20)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US6317804B1 (en) | 1998-11-30 | 2001-11-13 | Philips Semiconductors Inc. | Concurrent serial interconnect for integrating functional blocks in an integrated circuit device |
US7236490B2 (en) | 2000-11-17 | 2007-06-26 | Foundry Networks, Inc. | Backplane interface adapter |
US20030054774A1 (en) | 2001-03-22 | 2003-03-20 | Quicksilver Technology, Inc. | Method and system for managing hardware resources to implement system acquisition using an adaptive computing architecture |
US7249242B2 (en) | 2002-10-28 | 2007-07-24 | Nvidia Corporation | Input pipeline registers for a node in an adaptive computing engine |
US7433909B2 (en) | 2002-06-25 | 2008-10-07 | Nvidia Corporation | Processing architecture for a reconfigurable arithmetic node |
US7752419B1 (en) | 2001-03-22 | 2010-07-06 | Qst Holdings, Llc | Method and system for managing hardware resources to implement system functions using an adaptive computing architecture |
US7489779B2 (en) | 2001-03-22 | 2009-02-10 | Qstholdings, Llc | Hardware implementation of the secure hash standard |
US7325123B2 (en) | 2001-03-22 | 2008-01-29 | Qst Holdings, Llc | Hierarchical interconnect for configuring separate interconnects for each group of fixed and diverse computational elements |
US6836839B2 (en) | 2001-03-22 | 2004-12-28 | Quicksilver Technology, Inc. | Adaptive integrated circuitry with heterogeneous and reconfigurable matrices of diverse and adaptive computational units having fixed, application specific computational elements |
US8843928B2 (en) | 2010-01-21 | 2014-09-23 | Qst Holdings, Llc | Method and apparatus for a general-purpose, multiple-core system for implementing stream-based computations |
US7624204B2 (en) | 2001-03-22 | 2009-11-24 | Nvidia Corporation | Input/output controller node in an adaptable computing environment |
US7400668B2 (en) | 2001-03-22 | 2008-07-15 | Qst Holdings, Llc | Method and system for implementing a system acquisition function for use with a communication device |
US7225279B2 (en) | 2002-06-25 | 2007-05-29 | Nvidia Corporation | Data distributor in a computation unit forwarding network data to select components in respective communication method type |
US7653710B2 (en) | 2002-06-25 | 2010-01-26 | Qst Holdings, Llc. | Hardware task manager |
US8407429B2 (en) | 2006-06-21 | 2013-03-26 | Element Cxi, Llc | Multi-context configurable memory controller |
WO2010045732A1 (en) | 2008-10-20 | 2010-04-29 | Tadeusz Szymanski | Crossbar switch and recursive scheduling |
JP5353278B2 (ja) * | 2009-02-06 | 2013-11-27 | 富士通株式会社 | 通信装置 |
EP3525087A1 (en) | 2010-08-06 | 2019-08-14 | Frederick Furtek | A method and apparatus for a compiler and related components for stream-based computations for a general-purpose, multiple-core system |
US9559990B2 (en) | 2013-08-27 | 2017-01-31 | Oracle International Corporation | System and method for supporting host channel adapter (HCA) filtering in an engineered system for middleware and application execution |
US9577928B2 (en) | 2013-08-27 | 2017-02-21 | Oracle International Corporation | System and method for supporting data service addressing in an engineered system for middleware and application execution |
-
2018
- 2018-03-20 JP JP2018053280A patent/JP2019164713A/ja active Pending
- 2018-08-28 US US16/114,746 patent/US10599365B2/en active Active
Cited By (2)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US12014173B2 (en) | 2020-06-09 | 2024-06-18 | Huawei Technologies Co., Ltd. | Data processing method for network adapter and network adapter |
JP7501957B2 (ja) | 2020-06-09 | 2024-06-18 | ホアウェイ・テクノロジーズ・カンパニー・リミテッド | ネットワークアダプタのデータ処理方法およびネットワークアダプタ |
Also Published As
Publication number | Publication date |
---|---|
US20190294366A1 (en) | 2019-09-26 |
US10599365B2 (en) | 2020-03-24 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
CN114780458B (zh) | 数据处理的方法和存储系统 | |
US7822908B2 (en) | Discovery of a bridge device in a SAS communication system | |
US8843696B2 (en) | Memory device and method of controlling the same | |
JP2019164713A (ja) | ストレージシステム及びデータ転送方法 | |
US7496691B2 (en) | Standard ATA queuing automation in serial ATA interface for creating a frame information structure (FIS) corresponding to command from transport layer | |
US10747663B2 (en) | Storage device, computer system, and operation method of storage device configured to arbitrarily stop garbage collection | |
US10146475B2 (en) | Memory device performing control of discarding packet | |
US8417853B2 (en) | Universal serial bus host control methods and universal serial bus host controllers | |
CN111290983B (zh) | Usb传输设备及传输方法 | |
EP3945406A1 (en) | Storage device and method for processing commands | |
WO2017072868A1 (ja) | ストレージ装置 | |
US9146693B2 (en) | Storage control device, storage system, and storage control method | |
CN116107697B (zh) | 一种不同操作系统之间互相通信的方法及系统 | |
JP4936088B2 (ja) | ディスクアレイ装置、ディスクアレイシステム、及びキャッシュ制御方法 | |
US8234651B2 (en) | Information processing method and apparatus using the same | |
CN116486868A (zh) | 计算高速链路(CXL)上的高速非易失性存储器(NVMe) | |
US7769911B2 (en) | Data reading method and data reading apparatus | |
JP2023027970A (ja) | メモリシステム | |
US20240168876A1 (en) | Solving submission queue entry overflow using metadata or data pointers | |
US20240168877A1 (en) | Solving submission queue entry overflow with an additional out-of-order submission queue entry | |
EP3945407A1 (en) | Systems and methods for processing copy commands | |
JP2017162399A (ja) | 記憶装置 | |
CN112286657A (zh) | 电子设备和中断处理方法 | |
US7028131B1 (en) | Reverse message writes and reads | |
CN115396250A (zh) | 具有一致事务排序的多插槽网络接口控制器 |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
A711 | Notification of change in applicant |
Free format text: JAPANESE INTERMEDIATE CODE: A712 Effective date: 20180830 |