JP2001517888A - バッファリスト変更子制御ビットを備えた通信プロセッサ - Google Patents

バッファリスト変更子制御ビットを備えた通信プロセッサ

Info

Publication number
JP2001517888A
JP2001517888A JP2000513358A JP2000513358A JP2001517888A JP 2001517888 A JP2001517888 A JP 2001517888A JP 2000513358 A JP2000513358 A JP 2000513358A JP 2000513358 A JP2000513358 A JP 2000513358A JP 2001517888 A JP2001517888 A JP 2001517888A
Authority
JP
Japan
Prior art keywords
frame
transmission
processor
host
buffer
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
Application number
JP2000513358A
Other languages
English (en)
Other versions
JP3457947B2 (ja
Inventor
ローチ，ブラッドリー
フィアッコ，ピーター
シェレル，グレッグ
バーマン，ステュアート
ダックマン，デイヴィッド
Original Assignee
エミュレックス コーポレーション
Priority date (The priority date 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 date listed.)
Filing date
Publication date
Application filed by エミュレックス コーポレーション filed Critical エミュレックス コーポレーション
Publication of JP2001517888A publication Critical patent/JP2001517888A/ja
Application granted granted Critical
Publication of JP3457947B2 publication Critical patent/JP3457947B2/ja
Anticipated expiration legal-status Critical
Expired - Fee Related legal-status Critical Current

Links

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L12/00—Data switching networks
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9084—Reactions to storage capacity overflow
    • H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L47/00—Traffic control in data switching networks
    • H04L47/10—Flow control; Congestion control
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/901—Buffering arrangements using storage descriptor, e.g. read or write pointers
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9047—Buffering arrangements including multiple buffers, e.g. buffer pools
    • H04L49/9052—Buffering arrangements including multiple buffers, e.g. buffer pools with buffers of different sizes
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L49/00—Packet switching elements
    • H04L49/90—Buffering arrangements
    • H04L49/9084—Reactions to storage capacity overflow
    • H04L49/9089—Reactions to storage capacity overflow replacing packets in a storage arrangement, e.g. pushout
    • H04L49/9094—Arrangements for simultaneous transmit and receive, e.g. simultaneous reading/writing from/to the storage element
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L9/00—Cryptographic mechanisms or cryptographic arrangements for secret or secure communications; Network security protocols
    • H04L9/40—Network security protocols
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L69/00—Network arrangements, protocols or services independent of the application payload and not provided for in the other groups of this subclass
    • H04L69/12—Protocol engines

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Computer Security & Cryptography (AREA)
  • Computer And Data Communications (AREA)
  • Communication Control (AREA)
  • Information Transfer Systems (AREA)
  • Multi Processors (AREA)

Abstract

(57)【要約】 通信プロセッサがフレームデータとコマンドを送受信する。送受信プロトコルエンジンが、1連のフレームの中でどのフレームが最後であるかを表示するために所定のビットを使用するホストドライバ・ソフトウェアによって制御される。次に、この情報が送信前の送信フレーム内に配置される。

Description

【発明の詳細な説明】 【発明の属する技術分野】
【０００１】 本発明は、コンピュータネットワーク内でデータを送信するための装置に関する
ものであり、特に、コンピュータネットワーク・バウンダリにかけてフレームデ
ータを生成、送信を容易にするための、制御ビットを利用した装置に関するもの
である。
【従来の技術】
【０００２】 近年、多数のコンピュータおよび周辺機器が次々と開発されている。これによ
り、これらの装置第1を相互接続するための向上した方法の必要が生じた。これ までに、別種のコンピュータおよび周辺コンポーネントを相互に通信させるため
の様々なネットワーキングパラダイムが開発されてきた。 しかし、このようなネットワークを介してデータを交換することができる速度
には欠点がある。ネットワークアーキテクチャ速度の高速化は、より増速するコ
ンピュータ処理速度と同じ速度を保つことができなかったので、これは驚くこと
ではない。コンピュータチップの処理能力はこれまでに18ヶ月ごとに2倍に増え 続けており、どんどんパワフルになるマシンと、大きな回線容量を必要とするア
プリケーションを生み出している。一般に、処理能力"MIPS"（１秒間に命令実行
を何回行なえるかを表わす）について1メガバイト/秒の入力/出力が必要である ことが予想されてきた。現在では楽に200 MIPを越えるCPUがあり、ネットワーク
アーキテクチャがこれらの増速する速度について行くことは困難になっている。
【０００３】 エリアワイド・ネットワーク（例えばLAN、WAN）とチャネルは、コンピュータ
ネットワーク・アーキテクチャのためにこれまでに開発された2つのアプローチ である。従来のネットワークは多大な柔軟性と、比較的長距離網羅する能力を提
供する。エンタープライズ・システム・コネクション（ESCON）やスモール・コ ンピュータ・システム・インタフェース（SCSI）といった、高いパフォーマンス
と信頼性を備えたチャネルが開発されてきた。一般に、チャネルは、コンピュー
タ間、またはコンピュータと周辺機器間を接続する専用の短距離コネクションを
使用する。 「ファイバチャネル」として知られる新しいネットワーク・スタンダードには、 チャネルとネットワーク両方の特徴が採用されている。ファイバチャネルシス
テムは、チャネルの速度と信頼性、ネットワークの柔軟性と接続性を兼ね備えて
いる。ファイバチャネルプロダクトは、現在、266 Mbpsまたは1062 Mbpsといっ た非常に高いデータ値で実行されている。これらの速度は、圧縮していないフル
・モーションの高品質ビデオのような、大容量のアプリケーションを十分に扱え
るものである。 ファイバチャネルの配備には、単純なポイント・ツー・ポイント接続、任意ル
ープ、交換ファブリックの3つの方法が採用されている。最も簡単な技術は、あ らゆる2つのファイバチャネルシステムを直接接続するだけのポイント・ツー・ ポイントコンフィギュレーションである。任意ループは、アービトレーションを
介した帯域へのシェアドアクセスを提供するファイバチャネルリング接続である
。交換ファイバチャネルネットワークは「ファブリック」と呼ばれ、クロス・ポ
イント・スイッチングの利点にてこ入れすることで最も高いパフォーマンスを生
じる。
【０００４】 ファイバチャネルファブリックは、従来の電話システムのように働く。ファブ
リックは、ファイバチャネル・インタフェース・ポートを備えたワークステーシ
ョン、PC、サーバ、ルータ、メインフレーム、記憶装置といった様々な装置に接
続することができる。このような装置の各々は、目的ポートのアドレスをフレー
ムヘッダに入力することでファブリックを「呼出す」発信ポートを備えることが
できる。ファイバチャネル・スペシフィケーションはこのフレームの構造を定義
する。（このフレーム構造は、以下に述べる、本発明が検討するデータ転送問題
を生じる）ファイバチャネルファブリックは、所望の接続の設定作業を全て行う
ため、フレームオリジネータを複雑なルーティングアルゴリズムと接続する必要
がない。複雑な固定接続型仮想チャンネル（PVC）を設定する必要もない。ファ イバチャネルファブリックは、160,000,000を超えるアドレス扱うことが可能で あり、そのため、非常に大型のネットワークを収容することができる。このファ
ブリックは、単純にポートを追加することで拡張することができる。完全にコン
フィギュレートされたファイバチャネルネットワークの合計データ値は、テラビ
ット/秒の粋に達する。
【０００５】 ファイバチャネル技術を用いた多数の方法を表している図1に、ファイバチャネ ル接続の3つの基本タイプを示す。特に、メインフレームどうしを接続するポイ ント・ツー・ポイント接続10が示されている。また、ディスク記憶ユニットを接
続するファイバチャネル任意ループ11が示されている。ファイバチャネル交換フ
ァブリック12は、ワークステーション13、メインフレーム14、サーバ15、ディス
クドライブ16、ローカル・エリア・ネットワーク（LAN）17を接続する。LANは、
例えばイーサネット、トークンリング、FDDIネットワークを含む。 ANSI明細書（X3.230-1994）は、ファイバチャネルネットワークを定義してい る。この明細書は、5つの層の間のファイバチャネル機能について説明している 。図2に示すように、ファイバチャネルの5つの機能層は、FC-0‐物理メディア層
、FC-1‐コーディングおよびデコーディング層、FC-2‐フレーミング・プロトコ
ルとノード間のフロー制御を含む実送信機構、FC-3‐共用サービス層、FC-4‐上
層プロトコル、である。 ファイバチャネルが比較的高速で動作する一方で、より高速なプロセッサの要
求を満たすために速度をさらに増速することが望ましい。その方法の1つとして 、インタフェースポイントで発生するディレイを除去または短縮するものである
。このようなディレイの1つは、FC-1層からFC-2層にフレームを転送する間に生 じる。このインタフェースでは、ファイバチャネルデータリンクによってリンク
された装置が、ファイバチャネルフレームを連続して受信する。プロトコルエン
ジンがこれらのフレームを受信し、次の層、すなわち図2に示すFC-2においてこ れを処理する。プロトコルエンジンの機能には、各フレームの確認、飼うフレー
ムをホストへ転送するためのDMAオペレーションのキューアップ、送信フレーム の作成が含まれる。
【０００６】 ファイバチャネルデータリンクの高速なビット速度は、プロトコルエンジンに
並外れた要求を行う。プロトコルエンジンによってはハーフデュプレックスモー
ドでしか動作できないものもある。つまり、プロトコルエンジンが、1度に1方向
においてしかデータを処理できないということである。これによってデータ転送
の速度が著しく減衰してしまう。その理由は、送信または受信タスクのどちらか
片方が実行されている間、もう片方は待機していなければならないためである。 全2重プロトコルエンジンは、受信フレームと送信フレームの両方を同時に処 理することができる。そのため、全2重プロトコルエンジンは、データスループ ットを著しく向上させる。しかしながら、通常は各々がローカルRAMを備えた2つ
のマイクロプロセッサである全2重プロトコルエンジンが、送信オペレーション と受信オペレーションを扱う。これらの機能に対してデュアル・マイクロプロセ
ッサを使用すれば、プロトコルエンジンのコストが非常に高額になってしまう。 さらに従来のプロトコルエンジンは、時に、フレーム・バイ・フレームでのホ
ストCPUの装備に依存する。例えば、受信したフレームの確認、受信したフレー ムへの確認の生成には、一般にホストCPUが必要である。ホストCPUの使用によっ
てフレームの送・受信の値が限定され、ホストCPUの他のタスクの実行を妨害し てしまう。 さらに、送信プロトコルエンジンは、送信フレーム「ヘッダ」を作成するため
に、フレームペイロード・データサイズの事前の通知が必要である。これを達成
するための1つの方法として、送信プロトコルエンジンに、1連のフレームが記憶
されているコンピュータメモリへアクセスさせ、最終フレーム内のヘッダフィー
ルドを変更するものがある。しかし、送信プロトコルエンジンが、ペイロードデ
ータを転送する前に、カレントフレームが最終フレームであるかどうかを決定で
きない場合には、この余分な段階によってフレームヘッダの作成および送信処理
を遅くしてしまい、これにより全体の通信データ値をも遅くしてしまうことにな
る。 前述の説明を考慮すると、本発明の目的は、ファイバチャネルネットワークの
ような高速ネットワークにおけるデータ転送処理速度を増速し、プロトコルエン
ジンのデータフレーム処理をスピードアップできる技術を提供し、フレーム・バ
イ・フレームでのホストCPUを用いる必要なく、データの高速全2重処理を実行で
きるプロトコルエンジンを提供し、送信プロトコルエンジンが、フレームペイロ
ードデータサイズの事前の通知を行うと同様に、カレントフレームが最終フレー
ムであるかどうかを予め決定するための方法を提供することである。
【課題を解決するための手段】
【０００７】 本発明は、コンピュータデータリンク内でのフレームデータの処理および転送
に向けられている。本発明は、送信フレームの作成、受信フレームの確認、ホス
トDMAオペレーションの設定を行うために、フレーム・バイ・フレームでのホス トCPUと、常駐マイクロプロセッサとを用いることなく、2重マイクロコード・エ
ンジン、専用のハードウェアを使用する全2重通信プロセッサである。本発明の 好ましい実施例は、独立した専用の送信プロトコルプロセッサと受信プロトコル
プロセッサを使用している。これらの独立したプロセッサは、転送キューを用い
て互いに通信する。コンテキストマネージャは、受信したフレームを確認するた
めに受信プロセッサによって、また、送信フレームを作成するために送信プロセ
ッサによって使用されるコンテキスト情報を提供する。 コンテキスト情報は、バッファセグメントのアドレスとサイズを提供し、各セ
グメントについて制御ビット（バッファ・リスト・変更子ビット）を提供するバ
ッファビットをポイントする。送信プロトコルプロセッサは、バッファセグメン
ト内のデータをフレームのシーケンス内でどのように送信するかを決定するため
に、これらの制御ビットを使用する。この情報は、送信プロトコルプロセッサが
送信フレームヘッダを作成および送信する速度を増促する。好ましい実施例にお
いて、データチャネルはファイバチャネルデータリンクであり、全2重通信プロ セッサはFC-2プロトコル・ファイバチャネル・フレームを処理するように構成さ
れている。 本発明の好ましい実施例の詳細を、添付の図面と以下の記述によって説明する
。本発明の詳細がわかれば、当業者には、様々な追加の改変および変更が明らか
になるであろう。
【発明の実施の形態】
【０００８】 本発明は、フレーム送信とフレーム受信レートを、ファイバチャネルのような
高速データリンクに改善する全2重通信プロセッサを含む。ホストドライバ・ソ フトウェアと直接通信する独立した送・受信マイクロコード・エンジンを使用す
ることで、ホストCPUなしで全2重ネットワーク通信を達成することができる。ど
のフレームバッファが最終フレームを含んでいるかについての事前通知を送信プ
ロセッサに供給することで、バッファリスト変更子制御ビットの使用により、送
信フレームの作成と送信の速度がアップする。 図3は、本発明の好ましい実施例による全2重通信プロセッサ22を利用したファ
イバチャネル通信システム20を示している。ファイバチャネルデータリンク24を
に沿って、連続するデータが受信される。一般に、フレームは3つの部分、すな わちプリアンブル、データまたは「ペイロード」部分、そしてトレイラ部分を備
える。ファイバチャネルデータリンクでは、例えば、ファイバチャネルフレーム
はスタート・オブ・フレーム（SOF）ワード（4バイト）、フレームヘッダを備え
たデータ部分（6バイト）、0〜2112ペイロードバイト、巡回符号検査（CRC）ワ ード（4バイト）、最終フレーム（EOF）ワード（4バイト）から成る。フレーム ヘッダは、リンクアプリケーションの制御、デバイスプロトコル送信の制御、欠
損した、または使用不可能なフレームの検出のために使用される。CRCワードは 、送信に、データ破壊といった問題があるかどうか、または、フレームのアル部
分が送信中に落ちてしまっていないかどうかを示す。 ファイバチャネルデータリンク24から受信したフレームは、入ってくる連続デ
ータをワードにデコードおよび並列化するNLポート36によって処理される。NLポ
ート36はワードをフレームにアセンブルする。NLポート36はさらに、受信した各
フレームについてCRCワードをチェックし、その結果の「可・不可」CRC状態の識
別子を、EOFワードから生成されたEOFステータスワード内の他のステータス情報
ビットに追加する。次に、NLポート36は、フレームを受信フレームFIFOバッファ
28に書き込む。好ましいFIFOバッファ・モジュール2については、同時継続の特 許明細書である、同じ被譲渡人に譲渡された、1997年9月23日出願の出願番号第0
8/935,898号"RECEIVE FRAME FIFO WITH END OF FRAME BYPASS"に詳細に説明して
おり、また、本明細書中でもこの開示を参照している。
【０００９】 次に、プロトコルエンジンとも呼ばれる全2重通信プロセッサ22によって、フ ァイバチャネルフレームが受信される。全2重通信プロセッサ22によって、以下 を含むいくつかの機能が実行される。1）受信したフレームのデータを、直接メ モリアクセス（DMA）を介してホストメモリ内に書込むためにホストコマンドを キューアップする、2）そのフレームが、次に受信する倫理フレームであること を確実にするためにフレームヘッダを検査する、3）そのフレームに欠陥がない かどうかを調べる、4）受信したフレーム、またはホストで生成された送信コマ ンドに応答して送信フレームを生成する。 従来のプロトコルエンジンと異なり、全2重通信プロセッサ22はマイクロプロ セッサを採用していない。そのかわり、プロトコルエンジン受信タスクをプロト
コルエンジン送信タスクから分離するために、マイクロコードを2個使用したエ ンジンを採用している。特に、全2重通信プロセッサ22は、受信プロトコルエン ジン30と、送信プロトコルエンジン32を備えている。これらのプロトコルエンジ
ンは、転送レディ・キュー60を介して相互に通信する。受信プロトコルエンジン
30は、受信フレームバッファ28より受信した受信フレームヘッダを検査する。送
信プロトコルエンジン32は、送信フレームを作成し、これらを、送信FIFO66とNL
ポート36を介してファイバチャネルデータリンク24へ送信する。
【００１０】 全2重通信プロセッサ22は、ホストドライバソフトウェア38、ホストメモリ42 を備えたホストコンピュータ40と協働する。特に、送・受信プロトコルエンジン
30、32は、ホストドライバソフトウェア38と直接通信する。全2重通信は、送信 プロトコルエンジンと受信プロトコルエンジンが独立して、相互に作用して動作
するために達成される。送・受信プロトコルエンジンが同じI/Oコマンドで動作 できるようにするために、インタロックされたコンテキスト情報テーブルを使用
している。これについては、以下に詳細に説明する。 全2重通信プロセッサ22は、ホストCPUを使用せずに、フレーム・バイ・フレー
ムでフレームを処理することができる。例えば、全2重通信プロセッサ22の1つの
機能として、遠隔装置に、ファイバチャネルリンク24を介してフレームを受信プ
ロトコルエンジン30に送信させ、これによって送信プロトコルエンジン32を「起
こし」、NLポート36を介してデータをファイバチャネルリンク24に送信させるも
のがある。このようなデータは、例えばホストメモリ42内に常駐していてもよい
。
【００１１】 図5は、本発明の好ましい実施例による全2重通信プロセッサのさらなる詳細で
ある。全2重通信プロセッサ22は、連続的、または非連続的な物理メモリを含む 、ホストメモリ42内に常駐するデータ構造を備えている。 NLポート36を介して、受信プロトコルエンジン30によってファイバチャネルフ
レームが受信される。NLポート・ステータスユニット44は、受信フレームシーケ
ンスのタイミングをとり、NLポート妨害を監視する機能を実行する。受信したフ
レームは、受信したフレームを受信バッファ50内に配置する受信バッファ制御ユ
ニット48へ、シーケンサ46を介して送信される。次に、受信バッファ50内のフレ
ームヘッダが受信プロトコルエンジン30内に自動的に配置される。 各フレームヘッダ内のルックアップフィールドは、関連するコンテキストへの
ポインタを備えている。一般に、関連するコンテキストは、ホストメモリ42内の
ホストドライバ38によって初期化され、また、特定のフレームデータをホストメ
モリ42のどこに配置するかを示す情報を含有している。さらに詳細には、このコ
ンテキストは、最大フレームサイズ、カレントバッファポインタとその長さ、ス
モール・コンピュータ・システム・インタフェース（SCSI）ステート情報といっ
た、バッファのリストに定義されたフィールドを含んでいる。
【００１２】 一般に、ホストメモリユニット42は、メガバイト数の大きなメモリを備えてお
り、各特定のフレームがそのメモリのスロットの1つにはめられる。各フレーム ヘッダは、受信プロトコルエンジンがそのフレームを確認することができるよう
にその特定のフレームにアクセスまたは「プルダウン」する旨のコンテキストを
受信プロトコルエンジン30に伝える。コンテキスト・マネージャエンジンの制御
下で、ホストメモリインタフェース54を介して、コンテキストがホストメモリ42
からプルダウンされる。次に、受信プロトコル・エンジンシー・ケンサ46がその
フレームを確認する。 フレームの確認が終了すると、フレームヘッダによってポイントされたコンテ
キストが、そのフレームをどう処理するかを受信プロトコルエンジン30に伝える
。このフレームの処理方法は、以下に示すようにいくつかある。1）フレームを ルーティング制御/タイプ（R-CTL/TYPE）リング制御ユニット56の外に送信し、 そこからさらに、ホストメモリインタフェース54を介してホストメモリ42する、
。2）フレームを、バッファリストリング制御ユニット58を介して、内部ホスト メモリに存在するにバッファポインタリスト内の、あるセグメントに送信する。
3）非データ受信フレームと関連するペイロードを処理する。（例えば、フレー ムは、ターゲットがデータ受信する状態にある旨を送信装置に伝える「トランス
ファ レディ」のような通信フレームであってよい。これにより、受信フレーム が転送レディキュー60を送信する。次に、送信プロトコルエンジン32に送信コマ
ンドが送信される。
【００１３】 第2のケースは、バッファ記述子のシーケンシャルリストであるバッファポイ ンタリストへのフレームの送信を含む。このリストの第1エントリには、バイト で表す合計送信サイズが含まれる。例示した実施例では、全2重通信プロセッサ2
2によってワード転送のみが実行される。従って、合計転送サイズが4バイトワー
ドの整数でない場合には、次のバウンダリに追加のバイトが転送される。バッフ
ァリストへの次のエントリは、2つの部分から成る。この内の1つは、バッファの
最初をポイントするマルチバイトアドレスであり、もう1つは、そのバッファの サイズと使用量である。
【００１４】 本発明によれば、各バッファポインタリストはバッファリスト変更子（ＢＬＭ
）ビットを備えている。このバッファリスト変更子は、バッファの使用量を表し
、各送信フレームについて、出て行くファイバチャネルフレームヘッダ（FC-2ヘ
ッダ）を作成する。全2重通信プロセッサ22は、フレームヘッダと、関連するフ レーム制御（F-CTL）ビットを作成し、DMAオペレーションを介してペイロードを
転送する前にそのフレームヘッダを送信FIFO 66に送信しなければならない。バ ッファリスト内のBLMビットとバッファの長さは、あるフレームが一連のフレー ムの中の最後のものであるかどうかを決定する上で、全2重通信プロセッサ22を 援助する。受信プロトコルエンジンについては、BLMビットが、受信したデータ とステータス情報のバッファセグメント内への適切な配置を制御する。BLTビッ トについて以下により詳細に説明する。 全2重通信プロセッサ22が実行するタスクの1例は、遠隔装置からファイバチャ
ネルリンク24上のディスクドライブへデータを書込むためのコマンドの処理であ
る。書込みコマンドが送信され、全2重通信プロセッサがコマンドをディスクド ライブへ転送し、続いて、ディスクドライブが、ディスクドライブがデータを受
信する状態にある旨を示す転送レディメッセージを受信プロトコルエンジン30に
送る。このメッセージが転送レディキュー60へ送られ、続いて、転送レディキュ
ー60が、ホストメモリ42からのデータを検索し、フレームを生成し、データをデ
ィスクドライブに送信するように送信プロトコルエンジン32に指示する。
【００１５】 2つのイベントのいずれかによって送信プロトコルエンジン32がトリガされる 。この2つのイベントの1つは転送レディキュー60内のエントリの存在であり、も
う1つはコマンドリングコントローラ62の動作である。各コマンドを処理するた めに、後に説明する交換コンテキスト・リソース・インデックス（XRI）が使用 されている。コマンドリングは、コマンドエントリの環状キューであり、一般に
コマンドの読出し、書込みを行う。これらの読出し・書込みコマンドは、例えば
、ディスクドライブのような遠隔装置への通信コマンドに使用できる。コマンド
リングのサイズとベースメモリアドレスは、コマンドリングベース・レジスタ内
に指定されている。コマンドリングレジスタは、コマンドリングを次に示す方法
で管理するために使用される「プット」と「ゲット」ポインタを含む。この方法
とは、コマンドがコマンドリング62に照会されるたびに、ホストドライバ38がポ
インタを増加させながらプットポインタを管理するものである。また、コマンド
がリングから読み出されるたびに、全2重通信プロセッサ22がポインタを増加さ せながらゲットポインタを管理するものである。
【００１６】 フルフレーム送信以外のコマンドは、バッファポインタリストにポインタを提
供する。バッファポインタリストは、第1バッファリスト・エントリ内の合計転 送サイズと、後続するバッファリストエントリにおけるバッファポインタサイズ
の対とを含んでいる。次いで、適切なコンテキストを送信プロトコルエンジン32
にプルダウン旨をコンテキストマネージャ52に指示するために、コマンド内のXR
Iフィールドが使用される。交換と呼ばれるこの転送は、送信プロトコルエンジ ン32に、その特定のバッファリングリスト内におけるエンジンの場所、フレーム
が保有するデータの量、それがどの段階にあるか等について伝える。コンテキス
トはさらに、次のフレームヘッダを含んでいる。次のフレームヘッダは、ホスト
ドライバ38によって最初に作成されるが、その後、送信プロトコルエンジン32が
これに続くフレームヘッダを作成する。コンテキストマネージャ52は、ホストメ
モリ42から各フレームヘッダを検索し、このヘッダをヘッダコントローラ68へ送
信し、次いで、ヘッダコントローラが、送信FIFO66を介して、フレームヘッダを
NLポート36へ送信する。 フレームヘッダが作成されると、ホストメモリからのデータ収集処理において
バッファリストに従ってシステムはが開始する。コマンド用のコンテキストはバ
ッファリストへのポインタを含んでいる。バッファリストリングコントローラ70
によって、バッファリストからエントリが1度に1つずつプルダウンされる。フレ
ームヘッダが、送信ヘッダ制御68を介して送信FIFO66に送信される。ペイロード
セグメント72が ペイロード（フレームデータ）のプルインを開始し、ペイロ
ードデータを送信FIFO 66に配置する。フレームヘッダとペイロードデータが送 信FIFO 66に入ったら、最後のタスク、すなわち最終フレーム（EOF）ワードの送
信FIFO 66への書込みを行う。EOFワードは、アセンブルド・フレームのファイバ
チャネルリンク24への送信開始を示す、NLポート36に対する指示である。全ての
フレームの送信が成功すると、ペンディング中のコマンドに関連するフレームの
送信が実際に成功した旨の応答が生成され、ホストドライバ38へ送信される。 同様に、受信プロトコルエンジン30は、確認フレーム（基本的に、受信フレー
ムヘッダの変更形である）を生成する確認FIFO 74を含んでいる。確認フレーム は、受信確認のために、ファイバチャネルリンク24を介してセンダーへ戻される
。
【００１７】 全2重通信プロセッサ22はさらに、送信プロトコル・エンジン・レジスタ76、 受信プロトコル・エンジン・レジスタ78を備えている。これらのレジスタは、コ
ンテキストマネージャ52内のコンテキストレジスタを介してリンクおよび同期し
た自立プロトコル管理機能を備えている。コンテキストマネージャ52は、ホスト
メモリ42からの交換コンテキストの統一性とキャッシングを管理し、さらに、送
・受信プロトコルエンジン30、32による、コンテキストレジスタ80内に含まれる
キャッシュド・交換コンテキストへのアクセスと同期する。 好ましい実施例では、コンテキストマネージャ52と送・受信プロトコルエンジ
ン30、32とが、ホストメモリインタフェース54を介してホスト40と通信する。こ
のホストメモリインタフェース54には、周辺コンポーネントインタフェース（PC
I）、直接メモリアクセス（DMA）コントローラ（図示せず）、PCIスレーブイン タフェース（図示せず）が含まれる。プロトコルエンジンレジスタ76、78は、プ
ロトコルエンジン30、32用のPCIスレーブインタフェース・インタラプトコント ローラを備えている。コンテキストマネージャ52、送・受信プロトコルエンジン
30、32は、プロトコルエンジンレジスタ76、78へ/から、PCIスレーブインタフェ
ース・インタラプトコントローラ用のステータスを提供する。
【００１８】 送・受信プロトコルエンジン30、32は、2つの独立したプログラム可能シーケ ンサ46、63を使用することによってファイバチャネルプロトコルを実現する。シ
ーケンサ46，63を使用することで、初期化中に送・受信プロトコルエンジンレジ
スタ76、78内にダウンロードされたバリアブル書込可能制御記憶RAM内での、プ ロトコルエンジン・ステート・マシンの実現が可能になる。ホスト40は、この書
込可能制御記憶RAMにアクセすることができ、また、プロトコルレジスタマップ を介して書込可能制御記憶RAMからの読出し、これへの書込みが可能である。書 込可能制御記憶RAM内のコードを変更することで、全2重通信プロセッサ22に新規
または異なる機能をダウンロードすることができるため、シーケンサを使用する
ことによってプロトコルエンジン・ステート・マシンの実現に優れた柔軟性が加
わる。 全2重通信プロセッサ22は、シングルチップ（例えば、特定用途向けIC（ASIC ））上で、単独または他の機能と共に実現することができる。例えば、図示した
実施例では、全2重通信プロセッサ22は、最新の送・受信コンテキストの1つのイ
ンスタンスをキャッシュすることができる。しかし、オンチップ・メモリを追加
すれば、キャッシュできるコンテキストのインスタンスが増える。
【００１９】 Buffer Pointer List 図6は、全2重通信プロセッサ22の例証的な実施例における大型のデータ構造を
示す。図6に示すバッファポインタリストは、バッファ記述子のシーケンシャル リストである。このリストの第1エントリは、バイトで示す合計転送サイズが含 まれているが、全2重通信プロセッサ22がワード転送しか実行しないため、合計 転送サイズが4バイトワードの整数でない場合には、追加のバイトが次のワード バウンダリに転送される。バッファリスト内の次のエントリは、各々2つの部分 から成っている。1つはバッファの開始を示すアドレスであり、もう1つはバッフ
ァと制御ビットのワード内のサイズである。しかし、開始ワードアドレスとバッ
ファワード・カウントパラメータが使用されているため、ホストがバッファ開始
アドレスを32ビットワードアドレスと整列させなければならない。 例証的な実施例において、バッファポインタリストは、常にクワド・ワード（
16バイト）・バウンダリで始まる。最終エントリは常にNULL記述子である。バッ
ファポインタリストは、連続的な物理メモリ内に存在していなければならない。
バッファ記述子のフォーマットと、リストのレイアウトは図8のバッファポイン トリスト・エントリ・フォーマットと、図9のバッファポインタリスト・フォー マットに示している。
【００２０】 以下に示す可能な1実施例のために、図示した実施例のビット・バッファポイ ントリスト・エントリ・フォーマットと、バッファポインタリスト・フォーマッ
トについて詳細に説明する。 ビット[31:0] 合計転送サイズ（TTSZ） 合計転送サイズは、送信または受信されるバイトの合計数である。FCP I/Oの 場合には、合計送信サイズはFCP-CMD、FCP-XFR-RDYまたはFCP-RSPフレームを含 まない。 ビット[31:2] バッファ開始ワードアドレス（BSWA） このフィールドは、バッラリスト内に配置されたバッファリストエントリ（BL
E）によって、以下の情報を含有している。最初のBLEについてはBSWAフィールド
は使用されない。その後の、最後を除く全てのBLEについては、BSWAフィールド はバッファの開始ワードアドレスを含んでいる。最終BLEについては、BSWAフィ ールドはIOTAGを含んでいる。最終BLEは、BWC（長）フィールド内に0を設定する
ことによって表示される。0000,0000hからFFFF,FFFChまでの全てのBSWA値が有効
である。 ビット[31:24] バッファリスト識別子（BLM） BLMビットは、送信プロトコルエンジン32に、特定のビットをFC2ヘッダ内に設
定またはこれをクリアさせる。これらのビットは、第1 BLEを除く全てのBLEの各
々について有効であり、ここで、これらのビットは、上部合計転送サイズビット
31‐24として再定義される。BLMビットは以下に示すように使用される。 ビット[31] 受信バッファ これは受信バッファであり、送信はされない。 ビット[30] 第1フレーム表示 設定されると、送信プロトコルエンジン32が、1つのフレームについてSOFデリ
ミタをSOF13に設定する。 ビット[29] F-CTL.fs bit 設定されると、送信プロトコルエンジン32が、交換の第1フレームF-CTLビット
を設定する。 ビット[28] F-CTL.si bit 設定されると、送信プロトコルエンジン32が、このシーケンスに送信された最
終フレームについて、F-CTLフィールド内にシーケンス開始ビットを設定する。 ビット[27] F-CTL.es bit 設定されると、送信プロトコルエンジン32が、このシーケンスに送信された最
終フレームについて、F-CTLフィールド内に最終シーケンスビットを設定する。 ビット[26] F-CTL.ls bit 設定されると、交換を終了するために、送信プロトコルエンジン32が、このシ
ーケンスに送信された最終フレームについて、F-CTLフィールド内に最終シーケ ンスビットを設定する。 ビット[25] SEQ-COMPLETE 設定されると、送信プロトコルエンジン32が、このBLEによってポイントされ た全てのデータが送信された時にシーケンスを完了する。 ビット[24] FCP-DATA 設定されると、送信プロトコルエンジン32がヘッダTYPEフィールドをFCP-DATA
と交換する。 ビット[23:18] 予約BLM 予約BLMビットは、将来使用する時のために、第1BLEの除くシーケンサにマッ ピングされ、こｋで、これらのビットは合計送信サイズのビット23‐18として定
義される。 ビット[17:2] バッファワードカウント（BWC） これらのビットは、バッファリスト内のBLE位置に依存して、バッファの30ビ ットワードの長さ、または合計送信サイズを定義する。第1BLEについて、これら
のビットは、合計転送サイズの17−2の大きさのビットを提供する。このフィー ルドは、これに続く、最終BLEを除く全てのBLEについて、フィールドはバッファ
ワードカウントを定義する。最終BLEについては、BWCフィールドが受信され、ゼ
ロ値を有していなければならない。 ビット[1:0] 予約ビット 第1BLEについてはゼロと書かなければならず、ここで、ビット1-0は、合計転 送の残存バイト長を定義する。 ビット[31:0] I/O Tag(IOTAG) BSWAの代わりに、最終BLEは、完了したオペレーションを識別するために、ホ ストドライバに使用される値を含むことができる。このフィールドは、通信プロ
セッサ22によって処理されるものではない。送信シーケンスコマンドの通常の完
了について、応答のワード1がこのワードをポイントする。
【００２１】 XR1コンテキスト 好ましい実施例では、各コンテキストは2つのホストメモリ構造、すなわち、 遠隔ポートコンテキストと交換コンテキストに分割されている。交換コンテキス
トは、コマンドの処理に使用する交換コンテキスト・リソース・インデックス（
XRI）に内臓されている。特に、交換コンテキストは、完全交換を記述する、ま たは1つまたはそれ以上のシーケンスの送信を制御する構造である。この構造は 、交換ポインタ・テーブル内のエントリによってポインティングされている。XR
Iコンテキストは、迅速な、または個別のシーケンスを介したオペレーションの 実行のために必要な支持コンテキストを含んでいる。送信するデータ、または受
信を行うバッファは、実バッファにポインティングする1組のバッファリスト・ エントリで構成されたバッファポインタ・リストによって記述される。上述した
ように、バッファリスト・エントリは、開始シーケンス、最終交換、最終シーケ
ンス等を示すための、バッファと制御ビットのアドレスと長さを含んでいる。マ
ルチプル・シーケンス・オペレーションのためには、XRIコンテキストが作業レ ジスタコンテンツ用の記憶領域を提供する。
【００２２】 好ましい実施例では、XRIコンテキストは、その開始場所であるファイバチャ ネルプロトコル（FCP）交換、送信交換、そしてシングルフレームまたは多重フ レームシーケンスの送信を制御するための一時的な目的のために、全2重通信プ ロセッサ22によって使用される。また、データがバッファリング・バッファに受
信された交換を記録するために、XRIコンテキストによってホストドライバ38を 使用することも可能である。 XRIコンテキストの1例を図6に示す。第1ワードはXIR制御ステータスワードで ある。XRI制御ステータスワードは、ホストドライバによって設定されたコンフ ィギュレーション・フィールドを含んでいる。合計送信サイズワード・サイズは
シーケンサアクティビティを反映する。ファイバチャネルプロトコル（FCP）か ら始まった交換について、XRI制御ステータスワードは、書込みオペレーション 用の残りのバイトカウントと、読出しオペレーション用の累積受信バイトカウン
トを表示する。また、シーケンスが全て送信される以前にオペレーションが停止
した場合、XRI制御ステータスワードは、送信シーケンスコマンドについて残り のバイトカウントを表示する。また、フレームを確認するために、Rxeng制御ス テータスワードが受信プロトコルエンジン30によって使用される。カレントバッ
ファリストアドレスワードは、カレントバッファオフセットアドレスワード同様
にシーケンサアクティビティを反映する。
【００２３】 バッファリスト変更子（BLM）ビットが、シーケンサ制御下で読み出される関 連するバッファリストエントリ（BLE）のビットから設定される。ワード5内の残
存バッファ長がシーケンサアクティビティを反映する。シーケンサがBLEを読み 出すたびに、このフィールドがバッファワードカウントを受信する。また、バッ
ファへ、またはバッファからデータを送信するためにシーケンサがDMAオペレー ションを発行するたびに、ワードカウントが送信データの長さだけ減じられる。
カレントバッファバースト長ワードもまた、送信シーケンサアクティビティを反
映する。 ワード7〜12において、送信プロトコルエンジン22によって送信された各フレ ームについてヘッダ情報を生成するために、ファイバチャネルFC-2ヘッダが使用
される。
【００２４】 R-CTL/TYPEバッファリング 再び図5を参照すると、R-CTL/TYPEリング制御56が、FCPレスポンダフレームを
除く全てのフレーム最新バッファリストを受信するために使用されるバッファリ
ングを（すなわち、局所的に開始したFCP交換について）制御する。入ってくる フレームを適切なドライバエントリポイントにデマルチプレクスする上で、3つ のR-CTL/TYPEバッファリングがホストを援助する。R-CTL/TYPEバッファリングは
、バッファ記述子の固定サイズのシーケンシャルリストである。このリストは、
ハードウェアによって論理リングとして管理される。バッファ記述子は、バッフ
ァポインタリスト内のバッファリストエントリと似ているが、BLMビットを含ん でいない。 ホストドライバ42は、関連するベースレジスタ内の各バッファリングの場所と
サイズを特定する。特定レジスタは、R-CTL/TYPEバッファリング内のどのエント
リが有効であるかを特定する。各レジスタはプットポインタとゲットポインタを
含んでいる。各リング用の受信バッファが、ホストドライバが関連するバッファ
記述子をリングに入れる正確な順番で使用される。 ホスト制御下で、または他のポートによって遠隔的に、ループの局所的な初期
化が開始される。ホストドライバ38、送・受信シーケンサ46、63、NLポート36論
理が協働して、ループの初期化手順を完了する。この手順の実行中に、ホストド
ライバが、ループ上のポートのアドレスと機能を決定するファイバチャネル拡張
リンクサービス（ELS）フレームを開始するか、またはこれを無視する。ホスト ドライバ38は、ループの初期化手順を容易にするためのループ初期化選択マスタ
ー（LISM）ELSフレームを発行する役割を果たす。 初期化が必要な理由は、受信プロトコルエンジン30と送信プロトコルエンジン
32の両方が基本的に全2重で実行される2つの自律エンジンであり、また、両エン
ジン間の通信が最低限であるためである。初期化の実行中に、送信プロトコルエ
ンジン32はオフにされ、一方で、受信プロトコルエンジン30は、フレームを受信
し、これを送信プロトコルエンジン32を介して送信することできるようにされる
。そのため、受信プロトコルエンジンは 送信プロトコルエンジン・ハードウェ
アの「所有権」を取り、フレーム、特に、送信LISM制御モジュール82を利用して
送信されたLISMフレームを進めるために、そのハードウェアを使用する。
【００２５】 バッファリスト変更子ビットインタープリタ 全2重通信プロセッサ22は、出て行くファイバチャネルFC2ヘッダを作成するた
めに、バッファリスト変更子（BLM）ビットを使用する。ヘッダと、関連するF-C
TLビットを作成し、ペイロードをDMAする前に、これを送信FIFO内に転送しなけ ればならない。そのフレームが最終フレームであるかどうかを決定する上で、BL
Mビットとバッファリスト内のバッファ長がプロセッサ22を援助する。以下の擬 似コードで示すように、全2重通信プロセッサ22によってパラメータが解釈され る。 If(first frame of command or xfr-rdy) If(BLM.first-frame) SOF = SOFi3 else SOF = SOFn3// Set SOFi3/n3 delimiter else SOF = SOFn3 if(BLM.first-sequence)F-CTL.fs =1 else F-CTL.fs =0//Set F-CTL first frame bit if(BLM.FCO-DATA)R-CTL = FCP-DATA,F-CTL.rop = 1 // Set up FCP-DATA frame if(sequence-complete) if(BLM.si)F-CTL.si = 1 if(BLM.si)F-CTL.es = 1 if(BLM.si)F-CTL.ls = 1 F-CTL.fill-bytes = fill bytes from burst length running count SOF.Last-Frame = 1 ここで、 sequence-complete = (total transfer size <=max frame size)|| (Burst size <=max frame size)|| (BLM.SEQ COMP && (remaining buffer size <=max frame si
ze)) max frame size = min(N-Port max frame size, 1k) ifFCP burst size = FCP-XFR-RDY burst length field else burst size = total transfer size
【００２６】 各BLEが全2重通信プロセッサ22によって処理されると、XRIコンテキスト内でB
LMビットが更新される。ある例外の状態において、ドライバは、シーケンス送信
を再開するための再開コマンドを発行する前に、XRIコンテキスト内でBLMビット
を更新しなければならない。1例として、第1フレームが既に送信された後でシー
ケンスの送信を再開するために、BLM first-frameビットはクリアでなければな らない。 フレームが最終のものであるかどうかを決定する上でプロセッサ22をサポート
することで、BLMビットが送信プロトコルエンジン32に、フレームペイロードデ ータサイズについての事前の通知なしで、1つのパス内に送信フレームヘッダを 形成させる。さらに、BLMビットは送信プロトコルエンジン32に、送信ペイロー ドサイズについて知る以前に、送信ヘッダワードを送信バッファ内にロードする
ことを許容する。これによって、アドレス論理をアドレスポインタ上に再配置す
る必要なく、送信バッファFIFO 66アーキテクチャを簡素化することができる。
【００２７】 本発明の全2重通信プロセッサ22の好ましい実施例のさらなる詳細は、本発明 と同じ被譲渡人に譲渡された、 出願の、明細書番号 、同
時継続中の特許明細書"Full Duplex Communication Processor"で説明している 。この開示については本発明でも参照している。当業者には、BLMビットを、例 えば受信および送信プロセッサにシングルプロトコルエンジンを利用している他
の通信プロセッサの同じような利点と共に使用できることがわかるであろう。 本発明の多くの実施例について説明してきた。しかし、本発明の精神と範囲を
逸脱しない限りでの様々な変更が可能なことが理解されるであろう。従って、本
発明は特定の例証的な実施例によってではなく、請求項の範囲によってのみ限定
されることを理解すべきである。
【００２８】
【図面の簡単な説明】
【図1】 ファイバチャネル技術を利用した、従来技術の複雑なコンピュー タネットワークを示すブロック線図である。
【図2】 従来技術のファイバチャネルスタンダードの5つの機能層を示す線
図である。
【図3】 本発明の好ましい実施例による通信処理システムの簡素化したブ ロック線図である。
【図4】 典型的な従来技術のファイバチャネル・フレームデータを示す線 図である。
【図5】 本発明の好ましい実施例による全2重通信プロセッサを示す簡素化
したブロック線図である。
【図6】 本発明の好ましい実施例におけるホストデータ構造をを示す線図 である。
【図7】 本発明の好ましい実施例による交換コンテキスト・リソース・イ ンデックス（XRI）を示す線図である。
【図8】 本発明の好ましい実施例によるバッファポインタリスト・エント リフォーマットの線図である。
【図9】 本発明の好ましい実施例によるバッファポインタリスト・フォー マットの線図である。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 シェレル，グレッグ アメリカ合衆国 92886 カリフォルニア 州，ヨーバ リンダ，クレストクノール ドライブ 19621 (72)発明者 バーマン，ステュアート アメリカ合衆国 92660 カリフォルニア 州，ニューポート ビーチ，ヴィスタ コ ウダル 2010 (72)発明者 ダックマン，デイヴィッド アメリカ合衆国 90803 カリフォルニア 州，ロング ビーチ，アルゴン アベニュ ー 76

Claims (15)

    【特許請求の範囲】
  1. 【請求項1】 通信プロセッサであって、 (a)ホストメモリ、CPU、ペイロード、ホストドライバソフトウェアを備えたホス
    トコンピュータを有し、 (b)フレームデータを受信し、これを確認するための、及び、フレームデータを 構成および送信するためにコンピュータネットワークと接続した 受、送信プロ
    セッサをさらに有し、前記フレームデータがヘッダを有し、 (c)前記受送信プロセッサを前記ホストコンピュータと接続するためのインタフ ェースをさらに有し、 (d)前記ホストドライバソフトウェアが、フレーム内に、1連のフレーム内におい
    てどれが最終フレームであるかを示す所定のビットを設定するための手段を有し
    、 (e)前記受送信プロセッサが、1連のフレーム内においてどのフレームが最終フレ
    ームであるかに関連する情報を含む送信フレームヘッダを作成するために前記所
    定のビットを使用するための手段を有する、 ことを特徴とする通信プロセッサ。
  2. 【請求項2】 コンテキスト情報を含んだインターロックされた情報テーブ ルをさらに有し、前記受信プロセッサが、前記CPUを用いることなく、前記受信 フレームを処理するために前記コンテキスト情報を使用し、また、前記コンテキ
    スト情報を処理するためのコンテキストマネージャをさらに有し、前記コンテキ
    ストマネジャが前記ホストドライブソフトウェアの制御下にあることを特徴とす
    る請求項1に記載の通信プロセッサ。
  3. 【請求項3】 前記送受信プロセッサが、独立した送信マイクロコードエン ジンと受信マイクロコードエンジンを有することを特徴とする請求項1に記載の 通信プロセッサ。
  4. 【請求項4】 前記マイクロコードエンジンがシーケンサであり、前記通信 プロセッサがマイクロプロセッサを有さないことを特徴とする請求項4に記載の 通信プロセッサ。
  5. 【請求項5】前記フレームデータがファイバチャネルフレームであることを 特徴とする請求項1に記載の通信プロセッサ。
  6. 【請求項6】 前記受・送信プロセッサの各々が、FC-2ファイバチャンネル 通信プロトコルを実現することを特徴とする請求項5に記載の通信プロセッサ。
  7. 【請求項7】 前記受・送信プロセッサを備えたシングル集積回路を有する ことを特徴とする請求項1に記載の通信プロセッサ。
  8. 【請求項8】 前記インタフェース手段が、直接メモリアクセス（DMA）イン
    タフェースを有することを特徴とする請求項1に記載の通信プロセッサ。
  9. 【請求項9】 コンピュータネットワークにおける1連のフレームデータの処
    理方法であって、 前記コンピュータネットワークと接続した受送信プロセッサに第1フレームデ ータを受信し、 前記受信プロセッサから通信モジュールへ、前記第1フレームを転送し、 前記フレームデータに関連する文脈上の情報を情報テーブル内に記憶し、 前記第1フレームデータを確認するために前記文脈上の情報を使用し、 前記1連のフレームにおいてどのフレームが最終であるかを示すフレーム内の 所定のビットを設定するために、ホストコンピュータ内のホストドライバソフト
    ウェアを使用し、 1連のフレーム内においてどのフレームが最終であるかを示す情報を含む送信 フレームを構成するために、前記受送信プロセッサを使用し、 前記送信フレームを前記コンピュータネットワークへ転送する、 ことを特徴とする方法。
  10. 【請求項10】 前記第1、第2フレームデータがファイバチャネルフレームで
    あり、送信フレームを構成する前記段階が、ファイバチャネル送信フレームを構
    成する段階を有することを特徴とする請求項9に記載の方法。
  11. 【請求項11】 直接メモリアクセス（DMA）インタフェースを介して、前記 受信・送信プロセッサを前記ホストコンピュータと接続するための段階をさらに
    有することを特徴とする請求項10に記載の方法。
  12. 【請求項12】 コンピュータネットワークであって、 (a)ソースおよびデスティネーションコンピュータ装置を有し、 (b)前記ソースおよびデスティネーションコンピュータ装置と接続した通信チャ ネルをさらに有し、 (c)前記ソースコンピュータ装置からの一連のフレームデータを受信および確認 するための、前記通信チャネルと接続した受送信プロセッサをさらに有し、前記
    フレームデータがコマンドを有し、前記受送信プロセッサがさらに送信フレーム
    を構成し、 (d)CPU、メモリ、ドライバソフトウェアを含むホストコンピュータをさらに有し
    、 (e)前記受送信プロセッサを前記ホストコンピュータと接続するためのインタフ ェース手段をさらに有し、 (f)前記ホストコンピュータ内の前記ドライバソフトウェアが、前記一連のフレ ームにおいてどれが最終フレームであるかを示す所定のビットをフレーム内に設
    定するための手段をさらに有し、 (g)前記受送信プロセッサが、1連のフレームにおいてどれが最終.フレームであ るかについての情報を含んだ送信フレームヘッダを作成するために、前記所定の
    ビットを使用するための手段を有する、 ことを特徴とするコンピュータネットワーク。
  13. 【請求項13】 前記フレームデータがファイバチャネルフレームであること
    を特徴とする請求項12に記載のコンピュータネットワーク。
  14. 【請求項14】 前記受信および送信プロセッサの各々が、FC-2ファイバチャ
    ネル通信プロトコルを実現することを特徴とする請求項12に記載のコンピュータ
    ネットワーク。
  15. 【請求項15】 前記インタフェース手段が、直接メモリアクセス（DMA）イ ンタフェースを有することを特徴とする請求項12に記載のコンピュータネットワ
    ーク。
JP2000513358A 1997-09-24 1998-09-24 バッファリスト変更子制御ビットを備えた通信プロセッサ Expired - Fee Related JP3457947B2 (ja)

Applications Claiming Priority (3)

Application Number Priority Date Filing Date Title
US08/937,065 US6304910B1 (en) 1997-09-24 1997-09-24 Communication processor having buffer list modifier control bits
US08/937,065 1997-09-24
PCT/US1998/020011 WO1999016177A2 (en) 1997-09-24 1998-09-24 Communication processor having buffer list modifier control bits

Publications (2)

Publication Number Publication Date
JP2001517888A true JP2001517888A (ja) 2001-10-09
JP3457947B2 JP3457947B2 (ja) 2003-10-20

Family

ID=25469442

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2000513358A Expired - Fee Related JP3457947B2 (ja) 1997-09-24 1998-09-24 バッファリスト変更子制御ビットを備えた通信プロセッサ

Country Status (6)

Country Link
US (1) US6304910B1 (ja)
EP (1) EP1023668A4 (ja)
JP (1) JP3457947B2 (ja)
KR (1) KR100367949B1 (ja)
CA (1) CA2304620C (ja)
WO (1) WO1999016177A2 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8327043B2 (en) 2010-07-29 2012-12-04 Kabushiki Kaisha Toshiba Buffer management device which manages buffer transfer, storage apparatus comprising the same device, and buffer management method

Families Citing this family (16)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6118776A (en) 1997-02-18 2000-09-12 Vixel Corporation Methods and apparatus for fiber channel interconnection of private loop devices
US6185203B1 (en) 1997-02-18 2001-02-06 Vixel Corporation Fibre channel switching fabric
US6279057B1 (en) * 1997-11-17 2001-08-21 Seagate Technology, Inc. Communications system having dedicated frame buffers located in a channel node connected to two ports of the channel node for receiving frames
US6470026B1 (en) * 1998-10-30 2002-10-22 Agilent Technologies, Inc. Fibre channel loop map initialization protocol implemented in hardware
US6985431B1 (en) 1999-08-27 2006-01-10 International Business Machines Corporation Network switch and components and method of operation
US6769033B1 (en) 1999-08-27 2004-07-27 International Business Machines Corporation Network processor processing complex and methods
US6643710B1 (en) * 1999-09-17 2003-11-04 3Com Corporation Architecture to fragment transmitted TCP packets to a requested window size
US6856619B1 (en) * 2000-03-07 2005-02-15 Sun Microsystems, Inc. Computer network controller
US6775693B1 (en) * 2000-03-30 2004-08-10 Baydel Limited Network DMA method
US6757730B1 (en) 2000-05-31 2004-06-29 Datasynapse, Inc. Method, apparatus and articles-of-manufacture for network-based distributed computing
WO2002063479A1 (en) * 2001-02-02 2002-08-15 Datasynapse, Inc. Distributed computing system
US7359397B2 (en) * 2002-04-19 2008-04-15 Seagate Technology Llc Prioritizing transfers across an interface
JP2004080226A (ja) * 2002-08-14 2004-03-11 Nec Corp 代理ｆｃポート、ｆｃネットワーク及びそれらに用いるｆｃ透過転送方法
WO2004017220A1 (en) * 2002-08-19 2004-02-26 Broadcom Corporation One-shot rdma
US8185602B2 (en) 2002-11-05 2012-05-22 Newisys, Inc. Transaction processing using multiple protocol engines in systems having multiple multi-processor clusters
US8111696B2 (en) * 2008-10-14 2012-02-07 Emulex Design & Manufacturing Corporation Method to improve the performance of a computer network

Family Cites Families (22)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4346440A (en) * 1978-06-30 1982-08-24 Motorola, Inc. Advanced data link controller
EP0206743A3 (en) 1985-06-20 1990-04-25 Texas Instruments Incorporated Zero fall-through time asynchronous fifo buffer with nonambiguous empty/full resolution
US4975829A (en) * 1986-09-22 1990-12-04 At&T Bell Laboratories Communication interface protocol
US5070477A (en) * 1987-04-13 1991-12-03 Unisys Coporation Port adapter system including a controller for switching channels upon encountering a wait period of data transfer
GB2239724B (en) * 1990-01-05 1993-11-24 Sun Microsystems Inc Apparatus for maintaining consistency in a multi-processor computer system using virtual caching
EP0492025B1 (en) 1990-12-20 1997-08-06 International Business Machines Corporation High-speed multi-port FIFO buffer circuit
US5426639A (en) 1991-11-29 1995-06-20 At&T Corp. Multiple virtual FIFO arrangement
US5444853A (en) 1992-03-31 1995-08-22 Seiko Epson Corporation System and method for transferring data between a plurality of virtual FIFO's and a peripheral via a hardware FIFO and selectively updating control information associated with the virtual FIFO's
EP0602806B1 (en) * 1992-12-18 2001-07-04 Advanced Micro Devices, Inc. High-level data link controller (HDLC) receiver
US5546347A (en) 1994-07-22 1996-08-13 Integrated Device Technology, Inc. Interleaving architecture and method for a high density FIFO
US5638518A (en) * 1994-10-24 1997-06-10 Lsi Logic Corporation Node loop core for implementing transmission protocol in fibre channel
US5809328A (en) * 1995-12-21 1998-09-15 Unisys Corp. Apparatus for fibre channel transmission having interface logic, buffer memory, multiplexor/control device, fibre channel controller, gigabit link module, microprocessor, and bus control device
US5828901A (en) * 1995-12-21 1998-10-27 Cirrus Logic, Inc. Method and apparatus for placing multiple frames of data in a buffer in a direct memory access transfer
US5727218A (en) * 1996-03-05 1998-03-10 Unisys Corp. Controlling an apparatus disposed for adapting fiber channel transmissions to an industry standard data bus
US5742765A (en) * 1996-06-19 1998-04-21 Pmc-Sierra, Inc. Combination local ATM segmentation and reassembly and physical layer device
US5748905A (en) * 1996-08-30 1998-05-05 Fujitsu Network Communications, Inc. Frame classification using classification keys
US5922046A (en) * 1996-09-12 1999-07-13 Cabletron Systems, Inc. Method and apparatus for avoiding control reads in a network node
JP3317156B2 (ja) * 1996-09-18 2002-08-26 三菱電機株式会社 リモートｐｌｃ装置を備えた数値制御装置
US5978378A (en) * 1997-09-11 1999-11-02 3Com Corporation Method and apparatus for VLAN support
US6041058A (en) * 1997-09-11 2000-03-21 3Com Corporation Hardware filtering method and apparatus
US6005849A (en) * 1997-09-24 1999-12-21 Emulex Corporation Full-duplex communication processor which can be used for fibre channel frames
US6098125A (en) * 1998-05-01 2000-08-01 California Institute Of Technology Method of mapping fibre channel frames based on control and type header fields

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US8327043B2 (en) 2010-07-29 2012-12-04 Kabushiki Kaisha Toshiba Buffer management device which manages buffer transfer, storage apparatus comprising the same device, and buffer management method

Also Published As

Publication number Publication date
KR100367949B1 (ko) 2003-01-14
US6304910B1 (en) 2001-10-16
EP1023668A2 (en) 2000-08-02
CA2304620C (en) 2004-08-10
WO1999016177A3 (en) 1999-08-12
CA2304620A1 (en) 1999-04-01
EP1023668A4 (en) 2005-02-09
KR20010078685A (ko) 2001-08-21
WO1999016177A2 (en) 1999-04-01
JP3457947B2 (ja) 2003-10-20
WO1999016177B1 (en) 1999-10-07

Similar Documents

Publication Publication Date Title
JP2001517895A (ja) ファイバチャネルフレームに用いられる全２重通信プロセッサ
JP2001517888A (ja) バッファリスト変更子制御ビットを備えた通信プロセッサ
CN1276372C (zh) 智能网络存储接口系统和装置
US6775719B1 (en) Host-fabric adapter and method of connecting a host system to a channel-based switched fabric in a data network
US20020071450A1 (en) Host-fabric adapter having bandwidth-optimizing, area-minimal, vertical sliced memory architecture and method of connecting a host system to a channel-based switched fabric in a data network
JP2002512766A (ja) 第１のプロトコルから第２のプロトコルへのデータ転送方法及び装置
US5748634A (en) Method and apparatus for implementing a two-port ethernet bridge using a semaphoring technique
US20040174867A1 (en) Interconnection architecture for managing multiple low bandwidth connections over a high bandwidth link
JPH02196541A (ja) ワークステーシヨンをローカル・エリヤ・ネツトワークに接続する方法および装置
JP2001273154A (ja) 有限状態のマシーン制御をハードウエア実行データ構造操作により置換するパーフォーマンス向上方法およびシステム
JP4173636B2 (ja) 制御とタイプヘッダのフィールドに基づいてファイバーチャネルフレームをマップする方法
JP3735647B2 (ja) マップされていないファイバーチャネルフレームの確認およびホストバッファの割当てを行う方法
US5983272A (en) Option request protocol
US6463498B1 (en) Transmission of FCP response in the same loop tenancy as the FCP data with minimization of inter-sequence gap
JP3628514B2 (ja) 計算機間データ送受信方法
EP1033658A2 (en) Communication apparatus with means for allocating alternate designation information to each function unit, and communication system with said two communication apparatus
US6526458B1 (en) Method and system for efficient i/o operation completion in a fibre channel node using an application specific integration circuit and determining i/o operation completion status within interface controller
US7225274B2 (en) Method and apparatus for transferring data across a protocol bridge
US6311226B1 (en) Method and apparatus for dynamic link name negotiation
JP2001034567A (ja) 外部記憶サブシステムおよび外部記憶サブシステムの制御方法
WO1999015973A1 (en) Receive frame fifo with end of frame bypass

Legal Events

Date Code Title Description
S111 Request for change of ownership or part of ownership

Free format text: JAPANESE INTERMEDIATE CODE: R313113

S531 Written request for registration of change of domicile

Free format text: JAPANESE INTERMEDIATE CODE: R313531

R350 Written notification of registration of transfer

Free format text: JAPANESE INTERMEDIATE CODE: R350

LAPS Cancellation because of no payment of annual fees