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

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

Info

Publication number
JP3457947B2
JP3457947B2 JP2000513358A JP2000513358A JP3457947B2 JP 3457947 B2 JP3457947 B2 JP 3457947B2 JP 2000513358 A JP2000513358 A JP 2000513358A JP 2000513358 A JP2000513358 A JP 2000513358A JP 3457947 B2 JP3457947 B2 JP 3457947B2
Authority
JP
Japan
Prior art keywords
frame
processor
data
frames
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.)
Expired - Fee Related
Application number
JP2000513358A
Other languages
English (en)
Other versions
JP2001517888A (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)

Description

【発明の詳細な説明】 【発明の属する技術分野】
【０００１】本発明は、コンピュータネットワーク内で
データを送信するための装置に関するものであり、特
に、コンピュータネットワーク・バウンダリにかけてフ
レームデータを生成、送信を容易にするための、制御ビ
ットを利用した装置に関するものである。
【従来の技術】
【０００２】近年、多数のコンピュータおよび周辺機器
が次々と開発されている。これにより、これらの装置第
1を相互接続するための向上した方法の必要が生じた。
これまでに、別種のコンピュータおよび周辺コンポーネ
ントを相互に通信させるための様々なネットワーキング
パラダイムが開発されてきた。しかし、このようなネッ
トワークを介してデータを交換することができる速度に
は欠点がある。ネットワークアーキテクチャ速度の高速
化は、より増速するコンピュータ処理速度と同じ速度を
保つことができなかったので、これは驚くことではな
い。コンピュータチップの処理能力はこれまでに18ヶ月
ごとに2倍に増え続けており、どんどんパワフルになる
マシンと、大きな回線容量を必要とするアプリケーショ
ンを生み出している。一般に、処理能力"MIPS"（１秒間
に命令実行を何回行なえるかを表わす）について1メガ
バイト/秒の入力/出力が必要であることが予想されてき
た。現在では楽に200 MIPを越えるCPUがあり、ネットワ
ークアーキテクチャがこれらの増速する速度について行
くことは困難になっている。
【０００３】エリアワイド・ネットワーク（例えばLA
N、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重プロトコル
エンジンが、送信オペレーションと受信オペレーション
を扱う。これらの機能に対してデュアル・マイクロプロ
セッサを使用すれば、プロトコルエンジンのコストが非
常に高額になってしまう。さらに従来のプロトコルエン
ジンは、時に、フレーム・バイ・フレームでのホストCP
Uの装備に依存する。例えば、受信したフレームの確
認、受信したフレームへの確認の生成には、一般にホス
ト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〜21
12ペイロードバイト、巡回符号検査（CRC）ワード（4バ
イト）、最終フレーム（EOF）ワード（4バイト）から成
る。フレームヘッダは、リンクアプリケーションの制
御、デバイスプロトコル送信の制御、欠損した、または
使用不可能なフレームの検出のために使用される。CRC
ワードは、送信に、データ破壊といった問題があるかど
うか、または、フレームのアル部分が送信中に落ちてし
まっていないかどうかを示す。ファイバチャネルデータ
リンク24から受信したフレームは、入ってくる連続デー
タをワードにデコードおよび並列化するNLポート36によ
って処理される。NLポート36はワードをフレームにアセ
ンブルする。NLポート36はさらに、受信した各フレーム
についてCRCワードをチェックし、その結果の「可・不
可」CRC状態の識別子を、EOFワードから生成されたEOF
ステータスワード内の他のステータス情報ビットに追加
する。次に、NLポート36は、フレームを受信フレームFI
FOバッファ28に書き込む。好ましいFIFOバッファ・モジ
ュール2については、同時継続の特許明細書である、同
じ被譲渡人に譲渡された、1997年9月23日出願の出願番
号第08/935,898号"RECEIVE FRAME FIFO WITH END OF FR
AME 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重通信プロセッサ22によってワード転送のみ
が実行される。従って、合計転送サイズが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に指示するた
めに、コマンド内のXRIフィールドが使用される。交換
と呼ばれるこの転送は、送信プロトコルエンジン32に、
その特定のバッファリングリスト内におけるエンジンの
場所、フレームが保有するデータの量、それがどの段階
にあるか等について伝える。コンテキストはさらに、次
のフレームヘッダを含んでいる。次のフレームヘッダ
は、ホストドライバ38によって最初に作成されるが、そ
の後、送信プロトコルエンジン32がこれに続くフレーム
ヘッダを作成する。コンテキストマネージャ52は、ホス
トメモリ42から各フレームヘッダを検索し、このヘッダ
をヘッダコントローラ68へ送信し、次いで、ヘッダコン
トローラが、送信FIFO66を介して、フレームヘッダをNL
ポート36へ送信する。フレームヘッダが作成されると、
ホストメモリからのデータ収集処理においてバッファリ
ストに従ってシステムはが開始する。コマンド用のコン
テキストはバッファリストへのポインタを含んでいる。
バッファリストリングコントローラ70によって、バッフ
ァリストからエントリが1度に1つずつプルダウンされ
る。フレームヘッダが、送信ヘッダ制御68を介して送信
FIFO66に送信される。ペイロードセグメント72が ペ
イロード（フレームデータ）のプルインを開始し、ペイ
ロードデータを送信FIFO 66に配置する。フレームヘッ
ダとペイロードデータが送信FIFO 66に入ったら、最後
のタスク、すなわち最終フレーム（EOF）ワードの送信F
IFO 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には、周辺コンポーネントインタ
フェース（PCI）、直接メモリアクセス（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-C
MD、FCP-XFR-RDYまたはFCP-RSPフレームを含まない。 ビット[31:2] バッファ開始ワードアドレス（BSWA） このフィールドは、バッラリスト内に配置されたバッフ
ァリストエントリ（BLE）によって、以下の情報を含有
している。最初のBLEについてはBSWAフィールドは使用
されない。その後の、最後を除く全てのBLEについて
は、BSWAフィールドはバッファの開始ワードアドレスを
含んでいる。最終BLEについては、BSWAフィールドはIOT
AGを含んでいる。最終BLEは、BWC（長）フィールド内に
0を設定することによって表示される。0000,0000hからF
FFF,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つまたは
それ以上のシーケンスの送信を制御する構造である。こ
の構造は、交換ポインタ・テーブル内のエントリによっ
てポインティングされている。XRIコンテキストは、迅
速な、または個別のシーケンスを介したオペレーション
の実行のために必要な支持コンテキストを含んでいる。
送信するデータ、または受信を行うバッファは、実バッ
ファにポインティングする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ビットを含んでいない。ホストドライバ4
2は、関連するベースレジスタ内の各バッファリングの
場所とサイズを特定する。特定レジスタは、R-CTL/TYPE
バッファリング内のどのエントリが有効であるかを特定
する。各レジスタはプットポインタとゲットポインタを
含んでいる。各リング用の受信バッファが、ホストドラ
イバが関連するバッファ記述子をリングに入れる正確な
順番で使用される。ホスト制御下で、または他のポート
によって遠隔的に、ループの局所的な初期化が開始され
る。ホストドライバ38、送・受信シーケンサ46、63、NL
ポート36論理が協働して、ループの初期化手順を完了す
る。この手順の実行中に、ホストドライバが、ループ上
のポートのアドレスと機能を決定するファイバチャネル
拡張リンクサービス（ELS）フレームを開始するか、ま
たはこれを無視する。ホストドライバ38は、ループの初
期化手順を容易にするためのループ初期化選択マスター
（LISM）ELSフレームを発行する役割を果たす。初期化
が必要な理由は、受信プロトコルエンジン30と送信プロ
トコルエンジン32の両方が基本的に全2重で実行される2
つの自律エンジンであり、また、両エンジン間の通信が
最低限であるためである。初期化の実行中に、送信プロ
トコルエンジン32はオフにされ、一方で、受信プロトコ
ルエンジン30は、フレームを受信し、これを送信プロト
コルエンジン32を介して送信することできるようにされ
る。そのため、受信プロトコルエンジンは 送信プロト
コルエンジン・ハードウェアの「所有権」を取り、フレ
ーム、特に、送信LISM制御モジュール82を利用して送信
されたLISMフレームを進めるために、そのハードウェア
を使用する。
【００２５】バッファリスト変更子ビットインタープリ
タ 全2重通信プロセッサ22は、出て行くファイバチャネルF
C2ヘッダを作成するために、バッファリスト変更子（BL
M）ビットを使用する。ヘッダと、関連するF-CTLビット
を作成し、ペイロードをDMAする前に、これを送信FIFO
内に転送しなければならない。そのフレームが最終フレ
ームであるかどうかを決定する上で、BLMビットとバッ
ファリスト内のバッファ長がプロセッサ22を援助する。
以下の擬似コードで示すように、全2重通信プロセッサ2
2によってパラメータが解釈される。 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コンテキスト内でBLMビットが更新され
る。ある例外の状態において、ドライバは、シーケンス
送信を再開するための再開コマンドを発行する前に、XR
Iコンテキスト内でBLMビットを更新しなければならな
い。1例として、第1フレームが既に送信された後でシー
ケンスの送信を再開するために、BLM first-frameビッ
トはクリアでなければならない。フレームが最終のもの
であるかどうかを決定する上でプロセッサ22をサポート
することで、BLMビットが送信プロトコルエンジン32
に、フレームペイロードデータサイズについての事前の
通知なしで、1つのパス内に送信フレームヘッダを形成
させる。さらに、BLMビットは送信プロトコルエンジン3
2に、送信ペイロードサイズについて知る以前に、送信
ヘッダワードを送信バッファ内にロードすることを許容
する。これによって、アドレス論理をアドレスポインタ
上に再配置する必要なく、送信バッファFIFO 66アーキ
テクチャを簡素化することができる。
【００２７】本発明の全2重通信プロセッサ22の好まし
い実施例のさらなる詳細は、本発明と同じ被譲渡人に譲
渡された、 出願の、明細書番号
、同時継続中の特許明細書"Full Duplex Communicatio
n Processor"で説明している。この開示については本発
明でも参照している。当業者には、BLMビットを、例え
ば受信および送信プロセッサにシングルプロトコルエン
ジンを利用している他の通信プロセッサの同じような利
点と共に使用できることがわかるであろう。本発明の多
くの実施例について説明してきた。しかし、本発明の精
神と範囲を逸脱しない限りでの様々な変更が可能なこと
が理解されるであろう。従って、本発明は特定の例証的
な実施例によってではなく、請求項の範囲によってのみ
限定されることを理解すべきである。
【００２８】 ［図面の簡単な説明］
【図１】 ファイバチャネル技術を利用した、従来技術
の複雑なコンピュータネットワークを示すブロック線図
である。
【図２】 従来技術のファイバチャネルスタンダードの
5つの機能層を示す線図である。
【図３】 本発明の好ましい実施例による通信処理シス
テムの簡素化したブロック線図である。
【図４】 典型的な従来技術のファイバチャネル・フレ
ームデータを示す線図である。
【図５】 本発明の好ましい実施例による全2重通信プ
ロセッサを示す簡素化したブロック線図である。
【図６】 本発明の好ましい実施例におけるホストデー
タ構造をを示す線図である。
【図７】 本発明の好ましい実施例による交換コンテキ
スト・リソース・インデックス（XRI）を示す線図であ
る。
【図８】 本発明の好ましい実施例によるバッファポイ
ンタリスト・エントリフォーマットの線図である。
【図９】 本発明の好ましい実施例によるバッファポイ
ンタリスト・フォーマットの線図である。
───────────────────────────────────────────────────── フロントページの続き (72)発明者 シェレル，グレッグ アメリカ合衆国 92886 カリフォルニ ア州，ヨーバ リンダ，クレストクノー ル ドライブ 19621 (72)発明者 バーマン，ステュアート アメリカ合衆国 92660 カリフォルニ ア州，ニューポート ビーチ，ヴィスタ コウダル 2010 (72)発明者 ダックマン，デイヴィッド アメリカ合衆国 90803 カリフォルニ ア州，ロング ビーチ，アルゴン アベ ニュー 76 (58)調査した分野(Int.Cl.7，ＤＢ名) H04L 29/10 G06F 15/17 H04L 12/56 H04L 13/08 H04L 29/06

Claims (15)

    (57)【特許請求の範囲】
  1. 【請求項１】 コンピュータネットワークとホストコン
    ピュータとに適用される通信プロセッサであって、 前記ホストコンピュータは、ホストメモリ、CPU、ペイ
    ロード、ホストドライバソフトウェアを有し、 前記通信プロセッサは、フレームデータを受信し、これ
    を確認するための、また、フレームデータを構成および
    送信するために前記コンピュータネットワークと接続し
    た受信プロセッサ及び送信プロセッサをさらに有し、前
    記フレームデータがヘッダを有し、 前記受信プロセッサと前記送信プロセッサとは、フレー
    ム毎の前記ＣＰＵの関与及び常駐マイクロプロセッサ無
    しに、前記フレームデータを受け取り検証するために協
    働して動作し、 前記ホストコンピュータを前記送信プロセッサと前記受
    信プロセッサと関連付けするためのインターフェースを
    さらに有し、 前記ホストドライバソフトウェアが、一連のフレーム内
    において最終フレームを示す１つのフレーム内における
    所定のビットを処理し、 前記送信プロセッサと前記受信プロセッサが、1連のフ
    レーム内における最終フレームに関連する情報を含む送
    信フレームヘッダを作成するために前記所定のビットを
    使用するための手段を有することを特徴とする通信プロ
    セッサ。
  2. 【請求項２】 コンテキスト情報を含んだ情報テーブル
    をさらに有し、前記受信プロセッサが、前記CPUを用い
    ることなくデータの前記受信フレームのデータを受け取
    り、前記送信プロセッサが送信フレームを生成するため
    に前記コンテキスト情報を使用し、また、前記コンテキ
    スト情報を処理するためのコンテキストマネージャをさ
    らに有することを特徴とする請求項1に記載の通信プロ
    セッサ。
  3. 【請求項３】 前記送信プロセッサ及び前記受信プロセ
    ッサが、独立した送信マイクロコードエンジンと受信マ
    イクロコードエンジンとを有することを特徴とする請求
    項1に記載の通信プロセッサ。
  4. 【請求項４】 前記マイクロコードエンジンがシーケン
    サであることを特徴とする請求項３に記載の通信プロセ
    ッサ。
  5. 【請求項５】前記受信フレームデータがファイバチャネ
    ルフレームであることを特徴とする請求項1に記載の通
    信プロセッサ。
  6. 【請求項６】 前記受信プロセッサと前記送信プロセッ
    サとの各々が、FC-2ファイバチャンネル通信プロトコル
    を実現することを特徴とする請求項5に記載の通信プロ
    セッサ。
  7. 【請求項７】 前記受信プロセッサと前記送信プロセッ
    サを備えたシングル集積回路を有することを特徴とする
    請求項1に記載の通信プロセッサ。
  8. 【請求項８】 前記インターフェース手段が、直接メモ
    リアクセス（DMA）インターフェースを有することを特
    徴とする請求項1に記載の通信プロセッサ。
  9. 【請求項９】 受信プロセッサと送信プロセッサとを含
    み、外部ＣＰＵのフレーム毎の参加無しに、かつ、常駐
    のマイクロプロセッサの参加無しに、フレームデータの
    受信及び検証フレームと協働する通信プロセッサにおい
    て、一連のフレームを処理する方法であって、 前記コンピュータネットワークから受信プロセッサに第
    １フレームデータを受信し、 前記受信プロセッサから通信モジュールへ、前記第1フ
    レームデータを転送し、 前記第１フレームデータに関連する文脈上の情報を情報
    テーブル内に記憶し、 前記第1フレームを確認するために前記文脈上の情報を
    使用し、 前記1連のフレームにおいて最終フレームを示す情報を
    含む１つのフレーム中の所定のビットを設定し、 前記送信プロセッサによって、前記1連のフレーム内に
    おける最終フレームを示す情報を含む送信フレームを構
    成し、 前記送信フレームを前記コンピュータネットワークへ転
    送する、 ことを特徴とする方法。
  10. 【請求項１０】 前記第1フレームデータがファイバチ
    ャネルフレームであり、送信フレームを構成する前記段
    階が、ファイバチャネル送信フレームを構成する段階を
    有することを特徴とする請求項9に記載の方法。
  11. 【請求項１１】 直接メモリアクセス（DMA）インター
    フェースを介して、前記受信プロセッサ及び前記送信プ
    ロセッサを前記ホストコンピュータと接続するための段
    階をさらに有することを特徴とする請求項10に記載の方
    法。
  12. 【請求項１２】 コンピュータネットワークであって、 （a） ソースおよびデスティネーションコンピュータ装
    置を有し、 （b） 前記ソースおよびデスティネーションコンピュー
    タ装置と接続した１つの通信チャネルをさらに有し、 （c） 前記通信チャネルと組み合わされる１つの受信プ
    ロセッサ及び送信プロセッサであって、前記受信プロセ
    ッサは、前記ソースコンピュータ装置からの一連のデー
    タフレームを受け取り確認し、一連のデータはコマンド
    を有し、前記送信プロセッサも送信フレームを構成し、 （d） １つのCPU、メモリ、ホストドライバソフトウェ
    アを含む１つのホストコンピュータと、 （e） 前記送信プロセッサ及び受信プロセッサを前記ホ
    ストコンピュータと接続するための１つのインターフェ
    ース手段と、 （f） 前記ホストコンピュータ内の前記ドライバソフト
    ウェアは、前記一連のフレームにおける最終フレームで
    あるかを示す所定のビットをフレーム内に設定するよう
    に構成され、 （g） 前記送信プロセッサと受信プロセッサが、1連の
    フレームにおいてどれが最終のフレームであるかを特定
    するための情報を含んだ送信フレームヘッダを作成する
    ために、前記所定のビットを使用するための手段を有
    し、 （h） 前記受信プロセッサ及び送信プロセッサが、外部
    ＣＰＵのフレーム毎の関連及び常駐マイクロプロセッサ
    無しにデータフレームを受け取り、かつ確認するために
    協働して動作することを特徴とするコンピュータネット
    ワーク。
  13. 【請求項１３】 前記フレームデータがファイバチャネ
    ルフレームであることを特徴とする請求項12に記載のコ
    ンピュータネットワーク。
  14. 【請求項１４】 前記受信および送信プロセッサの各々
    が、FC-2ファイバチャネル通信プロトコルを実現するこ
    とを特徴とする請求項12に記載のコンピュータネットワ
    ーク。
  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 JP2001517888A (ja) 2001-10-09
JP3457947B2 true 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)

Families Citing this family (17)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US6185203B1 (en) * 1997-02-18 2001-02-06 Vixel Corporation Fibre channel switching fabric
US6118776A (en) 1997-02-18 2000-09-12 Vixel Corporation Methods and apparatus for fiber channel interconnection of private loop devices
US6317800B1 (en) * 1997-11-17 2001-11-13 Seagate Technology Llp System for reducing arbitrated-loop overhead by maintaining control of a communications channel as long as a predetermined amount of data is available within control of channel node
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 代理ｆｃポート、ｆｃネットワーク及びそれらに用いるｆｃ透過転送方法
EP1552409B1 (en) * 2002-08-19 2013-07-24 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
JP4922442B2 (ja) 2010-07-29 2012-04-25 株式会社東芝 バッファ管理装置、同装置を備えた記憶装置、及びバッファ管理方法

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
DE69031220T2 (de) 1990-12-20 1998-02-12 Ibm Hochgeschwindigkeitsmultiport-FIFO-Pufferschaltung
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
DE69330399T2 (de) * 1992-12-18 2002-05-02 Advanced Micro Devices Inc HDLC-Empfänger
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
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
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
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 三菱電機株式会社 リモートｐｌｃ装置を備えた数値制御装置
US6041058A (en) * 1997-09-11 2000-03-21 3Com Corporation Hardware filtering method and apparatus
US5978378A (en) * 1997-09-11 1999-11-02 3Com Corporation Method and apparatus for VLAN support
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

Also Published As

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

Similar Documents

Publication Publication Date Title
US6005849A (en) Full-duplex communication processor which can be used for fibre channel frames
JP3457947B2 (ja) バッファリスト変更子制御ビットを備えた通信プロセッサ
JP2699991B2 (ja) データ・フレームの伝送方法
US8923322B2 (en) Stateless fibre channel sequence acceleration for fibre channel traffic over Ethernet
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
US20030005039A1 (en) End node partitioning using local identifiers
US20020141424A1 (en) Host-fabric adapter having work queue entry (WQE) ring hardware assist (HWA) mechanism
US6064805A (en) Method, system, and computer program product for intraconnect data communication using buffer pools and buffer pool management
US6088729A (en) Method, system, and computer program product for establishing dialogs in an intraconnect data communication
CA2330014C (en) Method of mapping fibre channel frames based on control and type header fields
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
US6578096B1 (en) Method and system for efficient I/O operation completion in a fibre channel node
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
EP0958688B1 (en) Method and system for data communication using an intraconnect architecture
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