JPH1074174A - ネットワーク・インタフェース - Google Patents

Abstract

(57)【要約】 【課題】 コネクションベースの通信ネットワーク用の
ネットワーク・インタフェースにおいて、短い待ち時間
でかつメッセージ処理のための支援機能の複雑さを減ら
したものを提供する。 【解決手段】 ネットワーク・インタフェース６６の受
信側８２が、データとメッセージデータに関して実施さ
れる動作を示す宛先制御情報とを含むメッセージを受信
し、この受信メッセージから宛先制御情報を抽出し、抽
出された宛先制御情報をネットワーク・インタフェース
に接続されたメッセージ・コプロセッサ６４に通信し、
これによりメッセージ・コプロセッサ６４によって発生
された命令と引数を受け取り、これらの受信した命令と
引数に応じて受信メッセージに関する小集合の動作の内
の少なくとも１つを実行する。

Description

【発明の詳細な説明】

【０００１】

【発明の属する技術分野】この発明は、ネットワーク・
インタフェースに関し、特に非同期伝送モードネットワ
ーク等のコネクションベースのネットワークに関する。
さらに具体的には、この発明は、短い待ち時間の通信、
メッセージ・フィルタリング、及びメッセージの多重化
を含む、ネットワーク・インタフェースにおけるメッセ
ージ処理用支援機能の提供に関する。

【０００２】

【従来の技術】ディジタル通信において、また、特に非
同期伝送モード(ＡＴＭ)ネットワーク等のコネクション
ベースの通信システムにおいて、多数のコンピュータ
が、ネットワークに接続されて、パケット又はフレーム
(ここでは、交換可能に使用される)と呼ばれる単位が数
連になった状態で、メッセージや情報の流れを、通信し
ている。非同期伝送モードネットワークにおいて、パケ
ットは、セルと呼ばれる小単位が連結したものである。
特定のコンピュータに送られるパケットは、そのコンピ
ュータをそのネットワークに接続しているネットワーク
・インタフェース経由で、コンピュータに受け取られ
る。同様に、コンピュータは、そのネットワーク・イン
タフェース経由で、そのネットワークにパケットを注入
する。ネットワーク・インタフェースの仕事は、送信と
受信の両方に対して、パケットを効率的に処理すること
である。

【０００３】この出願において、用語「メッセージ」
は、パケットの意味論上の内容、つまり、そのパケット
が表しているものを、意味している。

【０００４】多くの現在のコンピュータ・システムにお
いて、パケットは、ネットワーク・インタフェースのバ
ッファで、先ずそのパケットを捕らえることによって、
受信される。適当なときに、ホストコンピュータは、そ
のパケットの到着を知らされる。ネットワーク・インタ
フェースによって、ホストコンピュータは、そのホスト
メモリのフリーバッファに、そのパケットをコピーし
て、そのパケットによって要求されている処理を行う。
さらに最近のネットワーク・インタフェースは、直接記
憶アクセス(ＤＭＡ)機構を有しているので、そのネット
ワーク・インタフェースに、ホストメモリのフリーバッ
ファにデータを保存させることができる。同様に、メッ
セージが、ホストコンピュータによって送信されると、
そのメッセージは、ネットワーク・インタフェースに、
ホストメモリにおけるそのデータの位置と、所望の宛先
を通知する。ネットワーク・インタフェースは、適当な
長さに分割された、そのデータを、ホストメモリからネ
ットワーク・インタフェースのローカルメモリにコピー
し、その宛先への送信のために、そのデータでパケット
を形成する。さらに最近のネットワーク・インタフェー
スは、出力パケット用データを得るために、ホストメモ
リへの直接記憶アクセスを可能にしている。

【０００５】パケットから構成されているメッセージを
送受信するプロセスは、コンピュータ処理オーバーヘッ
ドを伴うが、そのオーバーヘッドは、主に、オペレーテ
ィングシステムの対話とメッセージのコピーに起因す
る。ホストコンピュータにおいて、アプリケーション・
プログラムが、ネットワーク・インタフェースと直接的
に対話せず、むしろホストオペレーティングシステム経
由で間接的に対話することによって、通常、オペレーテ
ィング・システムの対話が発生する。この対話には、４
つのタイプがある。第１は、処理の通知であり、パケッ
トの到着のとき、又は受信側待ち行列の中の未処理のパ
ケット数が、所与のしきい置を越えたとき、あるいはそ
の両方のときに、割込を通して通知される。第２は、パ
ケットを送るために、送信側待ち行列に、あるいは、ネ
ットワーク・インタフェースからの通知に応じた受信側
待ち行列からのどちらかのデータの、アプリケーション
が始動する伝送である。第３は、アプリケーション・プ
ログラムによって使用される仮想メモリアドレスを、ホ
ストメモリに直接的にアクセスするために、ネットワー
ク・インタフェースによって使用される物理的アドレス
に、読み替えることである。現在のシステムにおいて、
送信側では、オペレーティング・システムが、送られる
べきデータについて、ネットワーク・インタフェースに
通知したときに、この対話が発生する。受信側では、オ
ペレーティング・システムが、ネットワーク・インタフ
ェースに、受信メッセージが保存されるべき場所、又は
フリーバッファについて通知するときに、同じオーバヘ
ッドが発生する。第４は、最長経路(クリティカルパス)
にないフリーバッファ待ち行列を満たしておくような、
一般的な段取り機能である。オペレーティング・システ
ムの呼び出しや取り扱いの割込は、通常、高価である。
そのようなオペレーティング・システムの対話は、ホス
ト処理サイクルを浪費するので、アプリケーション・プ
ログラムに使用できるサイクル数を減少させて、メッセ
ージの送受信をさらに遅延させる。

【０００６】受信メッセージが保存され、オペレーティ
ング・システムに使用されるバッファが、オペレーティ
ング・システムの中の使用可能なフリーバッファのグロ
ーバルプールから選択されて、コネクションに対して、
フリーバッファの固定的な割当てが無くなるために、一
般に、メッセージのコピーによるオーバーヘッドが発生
する。結果として、フリーバッファの位置は、アプリケ
ーション・プログラムが、メッセージデータに期待して
いるホストメモリの最終位置であることを、保証されな
い。従って、オペレーティング・システムは、フリーバ
ッファから所望の最終位置にデータをコピーする。つま
り、メッセージのコピーも、ホストの処理サイクルを浪
費して、アプリケーション・プログラムに利用できるサ
イクル数を減少させて、メッセージの受信をさらに遅延
させる。

【０００７】アプリケーションに、ネットワーク・イン
タフェースと直接的に対話させるネットワーク・インタ
フェースを使用することによって、オペレーティング・
システムの対話が減少する。しかし、確実に防護するた
めに、アプリケーション・プログラムに使用される仮想
アドレスを、ネットワーク・インタフェースにより使用
される物理的アドレスに置き換える機構が、存在する。
そのようなネットワーク・インタフェースは、例えば、
１９９４年９月にProceedings of ACM SigComm'94に発
表されたPeter Drushel他著の"Experiences with a Hig
h-Speed Network Adapter: A Software Perspective"に
公表されている。この論文は、仮想アドレスが、その仮
想アドレスから物理的アドレスを生成するために、マッ
ピングエンジンを備えているネットワーク・インタフェ
ースに使用されている、システムの説明をしている。こ
の様なシステムにおいては、オペレーティング・システ
ムは、置き換えを実行する必要はないが、仮想アドレス
を有するネットワーク・インタフェースを提供する。

【０００８】ホストプロセッサを避けて、ネットワーク
・インタフェースからアプリケーション・プログラムの
アドレス空間に、直接的にデータを伝送する機構を備え
ることで、メッセージコピー・オーバーヘッドを削減で
きる。このようなシステムは、１９９４年４月１２日に
出願された、Randy B. Osborn発明の米国特許出願第08/
226,541号に公開されている。そのようなシステムで
は、ネットワークで通信されるメッセージは、宛先制御
情報の領域を有していて、その宛先制御情報は、ネット
ワーク・インタフェースによって行われるべき動作と、
場合によっては、その動作の達成に使用される数項のオ
ペランドを識別する。ネットワーク・インタフェースの
機構は、受信メッセージを検査して、ホストコンピュー
タと対話することなく、その宛先制御情報に示されてい
る動作を行う。例えば、メッセージ中のデータが、ホス
トコンピュータによるコピーを排除するために、ネット
ワーク・インタフェースによって決定されたホストメモ
リの場所に、直接的に保存されることが可能である。

【０００９】ホストメモリに、メッセージデータを直接
的に保存することは、一種のメッセージ処理であり、そ
のような制御情報を用いて、ネットワーク・インタフェ
ースによって実行され得る。他の数種類の動作があり、
それらは、ホストからメッセージを取り出し、ネットワ
ークにそれを注入し、ネットワークからメッセージを受
け取り、さらにそれをホストに保存する間に、メッセー
ジの低レベル処理を必要とする。

【００１０】ある種のメッセージ処理は、メッセージ・
フィルタリングである。適切なメッセージ形式で、受信
側は、そのようなメッセージがホストに到達して、ホス
トの資源、特にホストプロセッサ時間を消費する前に、
望まないメッセージを濾し取ること(フィルタリング)が
できる。このようなフィルタリングの用途は、ＡＴＭフ
ォーラムスタイルのＬＡＮエミュレーション(ＬＡＮＥ)
実施の効率を向上することである。そのような実施は、
不明な宛先を見つけるためにメッセージを放送し、ＬＡ
ＮＥサーバーに送ったメッセージを繰り返す。これらの
動作は、ホストが望まないメッセージを受け取ることに
なる。通常、ホストコンピュータは、それらをすぐに捨
ててしまうためにだけ、それらのメッセージを処理する
ための資源を消費する。本発明により、メッセージプロ
セッサは、受信メッセージの先頭にある制御情報を検査
でき、従って、ホストコンピュータを巻き込まずに、そ
のメッセージを、廃棄することができる。

【００１１】別の種類のメッセージ処理は、早くて安い
メッセージの多重分離である。メッセージの先頭は、メ
ッセージは、ホストのどこに送られるべきかを示すため
の、多重分離項目として、使用され得る。例えば、送信
制御プロトコル(ＴＣＰ)ポートアドレスは、ＴＣＰパケ
ットのヘッダから分離でき、そのポートに適した待ち行
列に、そのパケットを送るために使用できる。ネットワ
ーク・インタフェースとメッセージ・コプロセッサによ
る、この多重分離は、取り出されるメッセージを、ホス
トからの多重分離の支援をすることができる。

【００１２】メッセージ処理は、リモート動作も含み、
それらは、その宛先でメッセージ本体に取る行動を表し
ている情報を、メッセージが運ぶ部類のプロトコルに属
している。従来のプロトコルにおいて、宛先でのホスト
コンピュータは、必要なデータの全てを受け取るまで
は、メッセージの処理を行うことができなかった。上記
のように、この要件は、そのデータをコピーするという
余分なオーバーヘッド、及び、短いメッセージにとって
はさらに重大な、メッセージ処理のためのホスト・プロ
セッサの主要活動の通知オーバーヘッドと割込を、含ん
でいる。ある工業用制御システムは、反射メモリとして
知られている「巡回」メモリを実施するためのリモート
動作を、既に使用している。本発明によるネットワーク
・インタフェースにおけるメッセージ処理支援機能は、
巡回メモリの実装を、さらに容易に、さらに効率的にす
る。

【００１３】さらに別の種類のメッセージ処理動作は、
分散直接記憶アクセス(ＤＭＡ)である。２種類の分散Ｄ
ＭＡが、特に有用である：分散サイズは事前に定義され
る、暗示的分散と、メッセージが、メッセージデータと
共にまとめられた分散宛先アドレスを含んでいる、明示
的分散である。暗示的分散の例は、メッセージデータか
らプロトコルヘッダを分離し、そのヘッダをあるバッフ
ァに送り、データを別のバッファに送るが、どちらのバ
ッファも任意の場所に存在可能である。この技術は、Ｔ
ＣＰ／ＩＰ処理に使用され得る。明示的分散ＤＭＡにつ
いては、その宛先での低レベル処理は、データとアドレ
スをまとめて、そのデータを適切なアドレスに送ること
ができる。

【００１４】

【発明が解決しようとする課題】しかし、そのようなメ
ッセージ処理用のネットワーク・インタフェースにおけ
る支援機能の提供は、ネットワーク・インタフェースに
複雑さと、従って、コストを増加させる。ネットワーク
・インタフェースにおける低レベルメッセージ処理は、
現在、非標準通信プロトコルにおける研究を必要として
いるので、この追加コストは、一般に、商業用アプリケ
ーションにおける利点を、上回ってしまう。従って、殆
どの商業的に使用可能なネットワーク・インタフェース
は、そのような支援機能を提供していない。

【００１５】この発明は上記の課題を解決するためにな
されたもので、ネットワーク・インタフェースを任意の
メッセージ・コプロセッサと接続するための単純なイン
タフェースを備えることによって、コネクションベース
の通信ネットワーク用のネットワーク・インタフェース
におけるメッセージ処理のための支援機能の複雑さを減
らしたネットワーク・インタフェースを提供することを
目的とする。

【００１６】

【課題を解決するための手段】上記の目的に鑑み、この
発明の第１の発明は、プロセッサとメモリを有するホス
トコンピュータを、このホストコンピュータを複数のコ
ンピュータに接続するネットワークに接続するためのネ
ットワーク・インタフェースであって、上記ネットワー
ク・インタフェースの受信側が、上記ネットワーク・イ
ンタフェースにおいて、データとメッセージデータに関
して実施される動作を示す宛先制御情報とを含むメッセ
ージを受け取るための手段と、上記ネットワーク・イン
タフェースにおいて、上記受信メッセージから宛先制御
情報を抽出し、抽出された宛先制御情報を、上記ネット
ワーク・インタフェースに接続されたメッセージ・コプ
ロセッサに通信するための手段と、上記ネットワーク・
インタフェースにおいて上記メッセージ・コプロセッサ
への上記抽出された制御情報の通信後に動作可能な、上
記メッセージ・コプロセッサによって発生された命令と
引数を受け取るための手段と、上記受信した命令と引数
に応じて、上記受信メッセージに関する小集合の動作の
内の少なくとも１つを実行するための手段と、を備えた
ことを特徴とするネットワーク・インタフェースにあ
る。

【００１７】第２の発明は、上記メッセージ・コプロセ
ッサが、ネットワーク・インタフェースの外部にあり、
さらに、上記ネットワーク・インタフェースが、受信メ
ッセージから宛先制御情報を抽出し、上記メッセージ・
コプロセッサに上記抽出情報を通信し、上記メッセージ
・コプロセッサから上記命令と引数を受け取り、さらに
引数を有する命令を実行するための上記各手段を実装し
ているメッセージ・コントローラを含む集積回路からな
ることを特徴とする請求項１に記載のネットワーク・イ
ンタフェースにある。

【００１８】第３の発明は、上記ネットワーク・インタ
フェース内のインタフェースが、上記外部メッセージ・
コプロセッサに接続されたメモリマッピングされたロー
カルバスであることを特徴とする請求項２に記載のネッ
トワーク・インタフェースにある。

【００１９】第４の発明は、上記宛先制御情報が、上記
ネットワーク・インタフェースを上記メッセージ・コプ
ロセッサに接続しているメモリマッピングされたバス上
の指定メモリ位置に書き込まれることを特徴とする請求
項１に記載のネットワーク・インタフェースにある。

【００２０】第５の発明は、上記メッセージ・コプロセ
ッサから受け取った上記命令が、上記ネットワーク・イ
ンタフェースによって実行されるべき小集合の動作の中
の１つの動作を表す第１の項目と、１つ以上のオペラン
ドを表す第２の項目とを定義しているフォーマットを有
することを特徴とする請求項１に記載のネットワーク・
インタフェースにある。

【００２１】第６の発明は、上記命令が、上記ネットワ
ーク・インタフェースを上記メッセージ・コプロセッサ
に接続しているメモリマッピングされたバス上の指定さ
れたメモリ位置から読み込まれることを特徴とする請求
項５に記載のネットワーク・インタフェースにある。

【００２２】第７の発明は、上記命令が、上記ネットワ
ーク・インタフェースによって実行されるべき可能な動
作毎に独立した１ビットを含むフォーマットを有してい
ることを特徴とする請求項５に記載のネットワーク・イ
ンタフェースにある。

【００２３】第８の発明は、上記命令を受け取ってそれ
を実行する手段が、上記命令に応じて動作する、上記受
信メッセージからさらに多くのデータを読み取ってそれ
を上記メッセージ・コプロセッサに送るための手段と、
上記メッセージ・コプロセッサからさらに別の命令を繰
り返し受け取りさらに実行するための手段を備えている
ことを特徴とする請求項１に記載のネットワーク・イン
タフェースにある。

【００２４】第９の発明は、上記命令を受け取ってそれ
を実行する手段が、返信動作命令を作成して、上記ネッ
トワーク・インタフェースの送信側によってアクセス可
能な返信待ち行列に返信命令を保存する手段を備えてい
ることを特徴とする請求項１に記載のネットワーク・イ
ンタフェースにある。

【００２５】第１０の発明は、上記命令を受け取ってこ
れを実行する手段が、上記宛先制御情報を読み終える前
に、上記受信メッセージを最初の状態に復元するための
手段を備えていることを特徴とする請求項１に記載のネ
ットワーク・インタフェースにある。

【００２６】第１１の発明は、上記命令がネットワーク
・インタフェースによって書き込まれるべきメッセージ
からのデータの指定長を示し、上記命令を受け取ってそ
れを実行する手段が、上記指定長のデータが、上記メッ
セージ・コプロセッサによって指定されたアドレスに書
き込まれるべきであるか否かを判断する手段と、指定さ
れたアドレスから始まる指定量のデータを保存するため
の手段と、を備えていることを特徴とする請求項１に記
載のネットワーク・インタフェースにある。

【００２７】第１２の発明は、上記命令がネットワーク
・インタフェースによって書き込まれるべきメッセージ
からのデータの指定長を示し、上記命令を受け取ってそ
れを実行する手段が、フリーバッファを選択する手段
と、指定量のデータを上記選択されたフリーバッファに
保存する手段と、を備えていることを特徴とする請求項
１に記載のネットワーク・インタフェースにある。

【００２８】第１３の発明は、上記保存手段がさらに、
ホスト・プロセッサに対する割込み信号を生成する手段
をさらに備えたことを特徴とする請求項１１に記載のネ
ットワーク・インタフェースにある。

【００２９】第１４の発明は、上記受信メッセージが分
割メッセージであり、上記命令を受け取ってこれを実行
する手段が、任意の前の制御区分の処理後に、上記分割
メッセージにおける任意の次の制御区分を自動的に処理
する手段を備えていることを特徴とする請求項１に記載
のネットワーク・インタフェースにある。

【００３０】第１５の発明は、プロセッサとメモリを有
するホストコンピュータを、このホストコンピュータを
メッセージを通信するために複数のコンピュータに接続
するネットワークに接続するためのネットワーク・イン
タフェースであって、上記ネットワーク・インタフェー
スの送信側が、上記ネットワーク・インタフェースにお
いて、宛先制御情報を出力メッセージから獲得する方法
を示す送り元制御情報をホストコンピュータから受け取
り、上記ネットワーク・インタフェースに接続されたメ
ッセージ・コプロセッサに通信する手段と、上記ネット
ワーク・インタフェースにおいて、上記メッセージ・コ
プロセッサへの送り元制御情報の通信後に動作可能な、
上記送り元制御情報に応じて、上記メッセージ・コプロ
セッサによって作成された命令と引数を受け取る手段
と、上記出力メッセージの受信によって上記出力メッセ
ージに関して実施される動作を表す上記宛先制御情報を
得るために、上記受け取った命令と引数に応じて小集合
の命令の内の少なくとも１つの命令を実行する手段と、
上記ネットワーク・インタフェースにおいて、上記ネッ
トワーク経由で上記複数のコンピュータの内の少なくと
も１台に送信されるべき上記出力メッセージに上記宛先
制御情報を挿入する手段と、を備えたことを特徴とする
ネットワーク・インタフェースにある。

【００３１】第１６の発明は、上記メッセージ・コプロ
セッサが、上記ネットワーク・インタフェースに対して
外部にあり、上記ネットワーク・インタフェースが、上
記受け取りおよび通信のための上記各手段を実装し、さ
らに上記外部メッセージ・コプロセッサへのインタフェ
ースを有するメッセージ・コントローラから成る集積回
路であることを特徴とする請求項１５に記載のネットワ
ーク・インタフェースにある。

【００３２】第１７の発明は、上記ネットワーク・イン
タフェース内のインタフェースが、上記外部メッセージ
・コプロセッサに接続されたメモリマッピングされたロ
ーカルバスであることを特徴とする請求項１６に記載の
ネットワーク・インタフェースにある。

【００３３】第１８の発明は、上記送り元制御情報が、
上記ネットワーク・インタフェースを上記メッセージ・
コプロセッサに接続しているメモリマッピングされたバ
ス上の指定されたメモリ位置に書き込まれることを特徴
とする請求項１５に記載のネットワーク・インタフェー
スにある。

【００３４】第１９の発明は、上記メッセージ・コプロ
セッサから受け取った上記命令が、上記ネットワーク・
インタフェースによって実行されるべき小集合の動作の
内の１つの動作を表す第１の項目と、１つ以上のオペラ
ンドを表す第２の項目を含むフォーマットを有すること
を特徴とする請求項１５に記載のネットワーク・インタ
フェースにある。

【００３５】第２０の発明は、上記命令が、上記ネット
ワーク・インタフェースを上記メッセージ・コプロセッ
サに接続している、メモリマッピングされたバス上の指
定されたメモリ位置から読み込まれることを特徴とする
請求項１９に記載のネットワーク・インタフェースにあ
る。

【００３６】第２１の発明は、上記命令が、上記ネット
ワーク・インタフェースによって実行されるべき可能な
動作毎に独立した１ビットを含むフォーマットを有して
いることを特徴とする請求項１９に記載のネットワーク
・インタフェースにある。

【００３７】第２２の発明は、上記命令を受け取ってそ
れを実行する手段が、上記命令に応じて動作する、上記
ホストコンピュータからさらに多くのデータを読み取っ
てそれを上記メッセージ・コプロセッサに送るための手
段と、上記メッセージ・コプロセッサからさらに別の命
令を繰り返し受け取りさらに実行するための手段を備え
たことを特徴とする請求項１５に記載のネットワーク・
インタフェースにある。

【００３８】第２３の発明は、上記命令が上記ネットワ
ーク・インタフェースによって読み取られるべきデータ
の指定量を示し、上記命令を受け取ってこれを実行する
ための手段が、上記指定量のデータが上記受け取った命
令によって指定されるアドレスから読み取られるべきか
否かを判断する手段と、上記指定されたバッファにある
上記指定量のデータを上記出力メッセージに読み込む手
段と、を備えたことを特徴とする請求項１５に記載のネ
ットワーク・インタフェースにある。

【００３９】第２４の発明は、上記命令が上記ネットワ
ーク・インタフェースによって読み出されるべきデータ
の指定量を示し、上記命令を受け取ってこれを実行する
ための手段が、送信のために上記ホストによって上記ネ
ットワーク・インタフェースに提供された上記バッファ
からのデータを選択する手段と、上記指定量のデータを
上記選択されたバッファから読み取り、上記読み取った
データを出力メッセージに挿入する手段と、を備えたこ
とを特徴とする請求項１５に記載のネットワーク・イン
タフェースにある。

【００４０】第２５の発明は、上記出力メッセージが分
割メッセージであり、上記命令を受け取ってこれを実行
する手段が、任意の前の制御区分の処理後に、上記分割
メッセージにおける任意の次の制御区分を自動的に処理
する手段を備えていることを特徴とする請求項１５に記
載のネットワーク・インタフェースにある。

【００４１】第２６の発明は、ホストコンピュータを複
数のコンピュータに接続するネットワークとの間で、実
行されるべき動作を表す宛先制御情報と通信チャネルを
表すヘッダとを含むメッセージを送受するために、プロ
セッサとメモリを有する上記ホストコンピュータに接続
されたネットワーク・インタフェースであって、上記ネ
ットワーク・インタフェースが、コントローラと、上記
ネットワーク・インタフェースによって送受されるメッ
セージにおける宛先制御情報の位置に関する情報を含む
関連メモリと、制御情報を上記コントローラからメッセ
ージ・コプロセッサに送信するための手段、上記メッセ
ージ・コプロセッサから小集合の命令の中の１つの命令
を受け取るための手段を備えた上記メッセージ・コプロ
セッサに接続するためのインタフェースであって、上記
コントローラが、上記メッセージ・コプロセッサからの
命令に応じて、出力メッセージの宛先で実行されるべき
動作を表す宛先制御情報を得るための手段、上記宛先制
御情報を上記出力メッセージに挿入するための手段を有
しているものと、上記コントローラが、上記メッセージ
・コプロセッサから受け取った命令に応じて、受け取っ
たメッセージを取り扱うための手段を有している、こと
を特徴とするネットワーク・インタフェースにある。

【００４２】この発明は、ネットワーク・インタフェー
スを、任意のメッセージ・コプロセッサと接続するため
に、単純なインタフェースを提供することによって、コ
ネクションベースの通信ネットワーク用ネットワーク・
インタフェースにおける、メッセージ処理のための支援
機能の複雑さを減らしている。ある実施の形態におい
て、ネットワーク・インタフェースは、外部メッセージ
・コプロセッサに対する簡単なインタフェースと、メッ
セージから制御情報を抽出し、その制御情報をそのコプ
ロセッサに送り、さらに、そのコプロセッサが出した小
集合の命令に対応するための手段との両方を有する、簡
単な集積回路である。このようにして、ネットワーク・
インタフェースは、メッセージ処理のためのオーバーヘ
ッドを最小限度しか負担せず、一方、外部コプロセッサ
が提供できる普遍性は、全て残している。

【００４３】この発明によるネットワーク・インタフェ
ースにおいて、受信側では、メッセージ中の宛先制御情
報は、そのネットワーク・インタフェースによって抽出
され、メッセージ・コプロセッサに送られる。そのメッ
セージ・コプロセッサは、その宛先制御情報に応じて、
そのネットワーク・インタフェースによる、短い待ち時
間の通信、メッセージ・フィルタリング、又は他の形式
のメッセージ処理に対する動作を含む、種々のメッセー
ジ処理動作を実施するように、プログラムされている。
メッセージ・コプロセッサは、そのネットワーク・イン
タフェースが理解する簡単な一組の命令を返す。ネット
ワーク・インタフェースに送られる簡単な一組の命令だ
けを提供し、宛先制御情報が、種々のメッセージ処理動
作を定義することができるようにすることによって、非
常に柔軟性のあるシステムが得られる。

【００４４】送信側では、ネットワーク・インタフェー
スは、ホストコンピュータによって作成された送り元制
御情報を読み、それをメッセージ・コプロセッサに送
る。そのメッセージ・コプロセッサは、出力メッセージ
の宛先でネットワーク・インタフェースによって処理さ
れるはずの、出力メッセージ用の宛先制御情報を生成す
るために、送り元制御情報に応じて、動作を実施する。
メッセージ・コプロセッサは、小集合の命令の内の１命
令をネットワーク・インタフェースに返すので、ネット
ワーク・インタフェースは、その命令を処理して、宛先
制御情報を出力メッセージに挿入する。

【００４５】メッセージ処理用の、そのようなインタフ
ェースを支援するために、ネットワーク・インタフェー
スは、宛先制御情報を送信メッセージに挿入し、宛先制
御情報を受信メッセージから抽出するための機構を、備
えている。ネットワーク・インタフェースは、メッセー
ジ・コプロセッサへの簡単なコネクションも有してい
る。メッセージ・コプロセッサは、そのネットワーク・
インタフェースが使用するローカルバス上にあり、この
ローカルバスは、現在のコネクション又は仮想チャネル
に関する表形式の情報を保存するために、ネットワーク
・インタフェースが使用するメモリバスである。この場
合、そのコプロセッサは、ネットワーク・インタフェー
スのメモリ空間にマッピングされて、メモリのようにア
クセスされる。

【００４６】このシステムにおいて提供される機能の組
み合わせにより、短い待ち時間の通信(リモート読取り
及び書き込み)、効率的なメッセージのフィルタリン
グ、及び速くて高価ではない多重分離を含めた、多くの
リモート動作が実行可能である。任意のメッセージ・コ
プロセッサを使用することのより、その制御情報が、そ
のコプロセッサが実行できる命令を定義できるようにす
ることにより、受信及び送信メッセージを取り扱うため
の柔軟な方法が、提供される。

【００４７】返信付きで、短い待ち時間のリモート動作
を実行する能力は、特に重要である。

【００４８】返信付きのリモート動作の支援が、本質的
に難しいのは、受信メッセージが、リモート書き込みの
ように復号されなければならないだけでなく、送信動作
が、その返信を作成するために、開始されなければなら
ないためである。ネットワーク・インタフェースは、リ
モート書込みと同じようにリモート読取りを取り扱い、
受信側は、メッセージ・コプロセッサに、指定量のメッ
セージデータを書き込み、次に、命令を読む。通常、こ
の命令は、受信側で実施される。しかし、その命令が
「send-reply(返信を送れ)」である場合、ホストメモリ
位置から直接記憶アクセス(ＤＭＡ)経由で、直接的にア
クセスされたデータに、ある制御情報を付加する処理を
する送信側に使用される機構と同じものを、そのネット
ワーク・インタフェースは、呼び出す。短い通信経路、
又はメッセージ待ち行列は、そのようなリモート読取り
を支援するために、ネットワーク・インタフェースの送
信側と受信側の間に設けられる。そのようなシステムに
より、リモート読取りが、ホスト・プロセッサの介入無
しに実施できるようになる。

【００４９】従って、この発明の１つの形態は、ネット
ワークにホストコンピュータを接続するためのネットワ
ーク・インタフェースの受信側であり、そこでは、ネッ
トワークは、ホストコンピュータと、複数のコンピュー
タを接続している。そのネットワーク・インタフェース
の受信側は、コネクション経由で、複数のコンピュータ
から受け取ったメッセージから、制御情報を抽出するた
めの機構を備えている。この抽出された制御情報は、そ
のネットワーク・インタフェースに接続された、メッセ
ージ・コプロセッサに通信される。その抽出された情報
の、メッセージ・コプロセッサへの通信後、受信側は、
その受信メッセージに関する動作を実行するために、メ
ッセージ・コプロセッサから命令を受け取りそれを実行
する。

【００５０】この発明の別の形態は、ホストコンピュー
タと、ネットワークを接続するためのネットワーク・イ
ンタフェースの送信側であり、そこでは、ネットワーク
は、ホストコンピュータを、複数のコンピュータに接続
している。そのネットワーク・インタフェースの送信側
は、ホストコンピュータから送り元制御情報を受け取る
ための機構と、その送り元制御情報を、ネットワーク・
インタフェースに接続されたメッセージ・コプロセッサ
に通信するための機構とを、備えている。送信側は、メ
ッセージ・コプロセッサへの送り元制御情報の通信後に
動作可能で、宛先制御情報を得るために、メッセージ・
コプロセッサから命令を受け取って、それを実行するた
めの機構も備えている。その宛先制御情報は、次に、コ
ネクション経由で、複数のコンピュータの内の１台に送
信されるべきメッセージに、挿入される。

【００５１】この発明のさらに別の形態は、ホストコン
ピュータを、複数のコンピュータと接続しているネット
ワークとの間で、メッセージを送受するために、ホスト
コンピュータに接続されているネットワーク・インタフ
ェースであり、そこでは、メッセージは、制御情報と、
通信チャネルを示すヘッダとを有している。そのネット
ワーク・インタフェースは、送信側と受信側用のコント
ローラを備えている。送信側では、コントローラは、ホ
ストから送り元制御情報を受け取る。その送り元制御情
報を、メッセージ・コプロセッサに送るために、コント
ローラは、送信側メッセージ・コプロセッサとインタフ
ェースし、そのメッセージ・コプロセッサから、小集合
の命令の中から１つ以上の命令を受け取る。そのメッセ
ージ・コプロセッサからの命令に応じて、そのコントロ
ーラは、宛先制御情報を、出力メッセージに挿入する。
受信側では、コントローラは、受信メッセージから宛先
制御情報を抽出して、その宛先制御情報を、受信側メッ
セージ・コプロセッサに送る。そのメッセージ・コプロ
セッサは、小集合の命令から１つ以上の命令を返す。そ
のコントローラは、受信した命令に応じて、受信メッセ
ージを処理する。

【００５２】この発明の、これら種々の形態において、
ネットワーク・インタフェースとメッセージ・コプロセ
ッサとの間のインタフェースは、簡単なメモリマッピン
グされたインタフェースである。

【００５３】

【発明の実施の形態】図１９によれば、代表的なコンピ
ュータ・システム２０は、ネットワーク・インタフェー
ス２６経由で、ネットワーク２４に接続されたホストコ
ンピュータ２２を、備えている。ネットワーク・インタ
フェース２６は、それぞれメッセージ３４と３２の送信
と受信の処理をする送信側３０と受信側２８とを備えて
いる。そのようなシステムの実施の実状は、下記のよう
な状態である。

【００５４】メッセージ送受信の支援のために、ホスト
コンピュータ２２は、４つの待ち行列を保守するが、そ
の中のそれぞれ２つの待ち行列は、通信の送信側と受信
側用である。送信側では、送信待ち行列８８(ＴＸｉｎ)
は、他のコンピュータに送信されるメッセージの一覧表
である。その一覧表の中の各エントリは、フレーム記述
子と呼ばれ、通常、そのメッセージが送信されるコネク
ション又は仮想チャネル、及びホストメモリ中のメッセ
ージデータの位置の表示を示す。送信完了待ち行列(Ｔ
Ｘｄｏｎｅ)９０は、対応するメッセージの送信が完了
した後、ＴＸｉｎ待ち行列からのエントリが置かれる類
似のエントリの一覧表である。受信側２８では、フリー
バッファ待ち行列(ＲＸｆｒｅｅ)８４は、データ受信に
使用できるホスト中のフリーバッファの一覧表である。
使用済みバッファ一覧表(ＲＸｄｏｎｅ)８６は、受信メ
ッセージからのデータを保存するために、最近使用され
たバッファを示す。

【００５５】ホストコンピュータ２２からネットワーク
２４にメッセージ３４を送信するために、ネットワーク
・インタフェース２６は、ＴＸｉｎ送信待ち行列８８か
ら１つのエントリを読み取り、送られるべきデータのホ
ストメモリ中の位置と、そのメッセージの宛先とを得
る。ネットワーク・インタフェース２６は、ホストメモ
リからネットワーク・インタフェースに、そのデータの
適切な長さの小区分をコピーし、また、ネットワークへ
の送信のために、そのデータの小区分をパケットにす
る。現状のシステムでは、この様なコピーは、通常、直
接記憶アクセス(ＤＭＡ)によって実行される。

【００５６】メッセージ３２をネットワークから受信す
るために、ホストコンピュータは、到着メッセージを保
存するために使用できる、ホストメモリの場所又はフリ
ーバッファを、予め識別する。現在使用可能なフリーバ
ッファの一覧表は、ＲＸｆｒｅｅ待ち行列８４で探すこ
とができる。パケットがネットワーク・インタフェース
に到着すると、ネットワーク・インタフェースは、ＲＸ
ｆｒｅｅ待ち行列８４からフリーバッファを選択して、
そのメッセージデータをホストメモリのフリーバッファ
にコピーする。別のフリーバッファが、必要に応じて追
加されて使用される。メッセージが終了すると、ネット
ワーク・インタフェースは、割込等でホストコンピュー
タに知らせる。現在のシステムでは、ネットワーク・イ
ンタフェースからホストメモリのフリーバッファへのデ
ータのコピーは、直接記憶アクセス（ＤＭＡ）、つま
り、ネットワーク・インタフェースによって始動される
効率的なブロック伝送を通して実行される。

【００５７】図１９に示されるシステムにおいては、メ
ッセージの送受信プロセスは、主にオペレーティング・
システムの対話とメッセージのコピーに起因するコンピ
ュータ処理オーバーヘッドを含んでいる。ホストコンピ
ュータでのアプリケーション・プログラムが、ネットワ
ーク・インタフェースと直接的に対話せず、むしろオペ
レーティング・システム経由で、間接的に対話すること
によって、通常、オペレーティング・システムの対話が
発生する。この対話には、４つの側面がある。第１の側
面は、処理の通知であり、メッセージの到着のとき、又
はＲＸｄｏｎｅ使用済みバッファ一覧表８６の中のメッ
セージ数が所与のしきい置を越えたとき、あるいはその
両方のときに、割込を通して通知される。第２の側面
は、メッセージを送るために、ＴＸｉｎ送信待ち行列８
８に、あるいは、ネットワーク・インタフェースからの
通知に応じてＲＸｄｏｎｅ使用済みバッファ一覧表８６
からの、どちらかのデータの、アプリケーションが始動
する伝送である。第３は、アプリケーション・プログラ
ムによって使用される仮想アドレスを、ホストメモリに
直接的にアクセスするために、ネットワーク・インタフ
ェースによって使用される物理的アドレスに、読み替え
ることである。現在のシステムにおいて、送信側では、
オペレーティング・システムが、送られるべきデータに
ついて、ネットワーク・インタフェースに通知するとき
に、この対話が発生する。受信側では、オペレーティン
グ・システムが、ネットワーク・インタフェースに、受
信メッセージが保存される場所、又はフリーバッファに
ついて通知するときに、同じオーバヘッドが発生する。
第４は、最長経路(クリティカル・パス)ではないＲＸｆ
ｒｅｅを充満させておくような一般的な段取り機能であ
る。オペレーティング・システムの呼び出しや取り扱い
の割込は、通常、高価である。そのようなオペレーティ
ング・システムの割込は、ホスト処理サイクルを浪費
し、アプリケーション・プログラムに使用できるサイク
ル数を減少させて、メッセージの送受信をさらに遅延さ
せる。

【００５８】受信メッセージが保存され、オペレーティ
ング・システムに使用されるバッファが、オペレーティ
ング・システムの中の使用可能なフリーバッファのグロ
ーバルプールから選択されて、コネクションに対して、
フリーバッファの固定的な割当てが無くなるために、一
般に、メッセージのコピーによるオーバーヘッドが発生
する。結果として、フリーバッファの位置は、アプリケ
ーション・プログラムが、メッセージデータに期待して
いるホストメモリの最終位置であることを、保証されな
い。従って、オペレーティング・システムは、フリーバ
ッファから所望の最終位置にデータをコピーする。つま
り、メッセージのコピーも、ホストの処理サイクルを浪
費して、アプリケーション・プログラムに対するサイク
ル数を減少させて、メッセージの受信をさらに遅延させ
る。

【００５９】アプリケーションに、ネットワーク・イン
タフェースと直接的に対話させるネットワーク・インタ
フェースを使用することによって、オペレーティング・
システムの対話が減少する。しかし、適当な防護をする
ために、アプリケーション・プログラムに使用される仮
想アドレスを、図２０及び図２１に示すように、ホスト
メモリにアクセスするために、ネットワーク・インタフ
ェースにより使用される物理的アドレスに置き換える機
構が存在する。そのようなネットワーク・インタフェー
スは、例えば、１９９４年９月にProceedings of ACM S
igComm '94に発表されたPeter Drushel他著の"Experien
ces with a High-Speed Network Adapter: A Software
Perspective"に公表されている。この様なシステムにお
いては、オペレーティング・システムは、置き換えを実
行する必要はないが、仮想アドレスを有するネットワー
ク・インタフェースを提供する。オペレーティング・シ
ステムの対話は減少するが、オペレーティング・システ
ムは、依然として到着通知を処理している。

【００６０】図２０に示すように、受信側２８では、パ
ケットは、入力バッファ１６０(通常、先入れ先出しメ
モリ(ＦＩＦＯ))によって受け取られる。入力バッファ
１６０の最初のメモリ位置である処理バッファ１５８
は、ヘッダ処理回路１６６と出力バッファ１５６との両
方に、接続されている。出力バッファ１５６は、通常、
先入れ先出しメモリ(ＦＩＦＯ)である。そのパケットが
目指している仮想チャネルを、他のものの中から判定す
るために、ヘッダ処理回路１６６は、入力パケットから
ヘッダ情報を抜き取る。この仮想チャネル情報は、任意
のローカルメモリ１５２とアドレス生成回路１６２か
ら、仮想アドレスを得るために使用される。アドレス
は、マルチプレクサ１６３経由で、その仮想アドレスを
物理的アドレスにマッピングするマッピング回路１６４
に、供給される。処理バッファ１５８から出力された書
き込まれるべきデータと、マッピング回路１６４からの
物理的アドレスが、出力バッファ１５８に入力される。
ＤＭＡ部１５４は、データをホストメモリの対応する位
置に直接的に保存するために、出力バッファ１５６で、
そのデータを処理する。

【００６１】送信側３０では、図２１に示すように、仮
想アドレスは、例えば、ネットワーク・インタフェース
のコントローラ（図示せず）から、あるいは、アドレス
生成回路１１２による生成によって、ローカルバス１０
３経由で、受け取られる。ホストメモリにアクセスし
て、データを処理バッファ１０８にコピーするために、
ＤＭＡ回路１０４により使用される物理的アドレスを決
定するマッピング回路１１４に、仮想アドレスが供給さ
れる。ヘッダ処理回路１１６は、ヘッダ情報を処理バッ
ファ１０８に供給する。次に、生成されたパケットは、
ネットワークへの送信のために、出力バッファ(ＦＩＦ
Ｏ)１１０に出力される。

【００６２】ホストプロセッサをバイパスして、ネット
ワーク・インタフェースからアプリケーション・プログ
ラムのアドレス空間に、直接的にデータをコピーする機
構を備えることで、メッセージコピー・オーバーヘッド
を削減できる。このようなシステムは、１９９４年４月
１２日に出願された、Randy B. Osborn発明の米国特許
出願第08/226,541号に公開されている。そのようなシス
テムでは、ネットワークで通信されるメッセージは、宛
先制御情報の領域を有していて、その宛先制御情報は、
ネットワーク・インタフェースによって行われるべき動
作と、場合によっては、その動作の達成に使用される数
項のオペランドを識別する。そのような宛先制御情報の
形式は、図２３の(ａ)乃至(ｄ)に関連して、さらに詳し
く、以下に記述する。ネットワーク・インタフェースの
機構は、受信メッセージを検査して、ホストプロセッサ
と対話することなく、その宛先制御情報に示されている
動作を行う。例えば、メッセージ中のデータが、ホスト
コンピュータによるコピーを排除するために、ホストメ
モリのネットワーク・インタフェースによって決定され
た場所に、直接的に保存されることが可能である。

【００６３】図２２は、そのような、メッセージコピー
・オーバーヘッドを削減するための機構を備えた、コン
ピュータ・システム４０を示している。図２２におい
て、コンピュータ・システムは、ネットワーク・インタ
フェース４４経由で、ネットワーク２４に接続されたコ
ンピュータ２２を備えている。このシステムにおいて、
メッセージ４８と４６は、送信側で供給した宛先制御情
報５０を含んでいる。受信側のネットワーク・インタフ
ェースは、通信遅延(待ち時間)と受信側のホストコンピ
ュータ２２での通信の影響を減らすために、その宛先制
御情報５０を処理する。特に、受信側の処理５２では、
ネットワーク・インタフェースのローカルメモリ５４に
ある状態情報にアクセスするために、その宛先制御情報
を使用する。ＲＸｆｒｅｅ(フリーバッファ待ち行列)内
の次のフリーバッファの位置よりも、むしろ、データが
直接的に保存されるホストメモリ(図示せず)の特定の位
置のアドレスを得るために、その状態情報が処理され
る。同様に、送信メッセージ４８を生成するために、送
信側の処理５６は、ホスト・コンピュータ・メモリ(図
示せず)から直接的にデータを読み取り、さらに、ロー
カルメモリ５４から状態情報を使用して得られた宛先制
御情報を付加する。

【００６４】図２３の(ａ)乃至(ｄ)は、宛先制御情報５
０のデータ内容を表している略図である。図２３の(ａ)
に示す最も簡単な種類の宛先制御情報は、その宛先で行
われるべき動作の表示３００と、その動作に使用される
オペランドの表示３０２とを、含んでいる。そのオペラ
ンドは、その宛先のネットワーク・インタフェースに保
存されている情報、又はその送り元で供給された情報、
あるいはその両方への参照である。３０４で示されてい
るように、データ長(サイズ)とチェックサム情報も、提
供される。宛先制御情報５０(図２２参照)のさらに複雑
な構成は、図２３の(ｂ)に示すようにその宛先制御情報
のサイズの表示３０６(暗示的、又は明示的な表示)を含
む。この形式により、オペランド３０８の数が変わって
も使用できる。

【００６５】そのような宛先制御情報５０は、一般に、
メッセージの先頭に挿入される。どちらにしても、図２
３の(ｃ)に示すようなＡＴＭ、つまり先頭のセル３１０
が、一般に、宛先制御情報を含み、残りのセル３１２と
最後のセル３１４がデータを搬送する場合、メッセージ
は、数個のセルから構成される。しかし、図２３の(ｄ)
の３１６と３１８で示されるように、メッセージが、数
個の制御区分で構成されることも可能である。そのよう
なメッセージは、分割メッセージと呼ばれる。そのよう
な場合、各制御区分は、各制御区分の先頭セル３１０の
先頭に、宛先制御情報５０(図２２参照)を有している。

【００６６】この発明のある実施の形態では、任意のメ
ッセージ・コプロセッサに対する簡単なインタフェース
を設けることにより、ネットワーク・インタフェースに
おけるメッセージ処理支援の複雑さを減らしている。そ
のメッセージ・コプロセッサの実行に応じて定義され
た、任意の組のメッセージ処理動作の実行のために、宛
先制御情報５０が処理される。任意のメッセージ・コプ
ロセッサに対する簡単なインタフェースの使用により、
低レベルメッセージ処理のための支援機能付きのネット
ワーク・インタフェースが、経済的に製造されるように
なる。そのようなシステムは、単に少ない待ち時間だけ
でなく、多種のメッセージ処理動作やそのアプリケーシ
ョンにおける実験や応用も可能にする。

【００６７】実施の形態１．図１を参照すると、この発
明において、コンピュータ・システム６０は、ネットワ
ーク・インタフェース６６経由で、ネットワーク２４に
接続されているホストコンピュータ２２を備えている。
そのネットワーク・インタフェースは、ＶＬＳＩ又はＬ
ＳＩ技術を使用した集積回路として、実用化される。ネ
ットワーク２４は、同様に、ネットワークに接続されて
いる他のコンピュータ・システム(図示せず)に、このコ
ンピュータ・システム６０を接続している。この発明の
ある実施の形態において、ネットワークは、非同期伝送
モード(ＡＴＭ)等のコネクションベースのネットワーク
である。通信処理を支援するために、ホストコンピュー
タは、従来のシステムにおけるようなリング待ち行列８
４、８６、８８、及び９０を備えている。しかし、その
ような実施の形態においては、送信側待ち行列８８と９
０におけるエントリは、宛先制御情報を得る方法を示し
ている下記の送り元制御情報を含んでいる。

【００６８】この発明において、ネットワーク・インタ
フェースは、宛先制御情報７６の無いメッセージ７０と
７２が送信されるか、又は受信されたときに、標準的な
ネットワーク・インタフェースとして動作する。メッセ
ージが、宛先制御情報７６付きで送信又は受信された場
合、そのネットワーク・インタフェースは、任意のメッ
セージ・コプロセッサ６８及び６４を通じて、要求され
た処理を行う。つまり、そのネットワーク・インタフェ
ースは、ローカルバス６９経由で送信側処理用のメッセ
ージ・コプロセッサ６８と、受信側処理用メッセージ・
コプロセッサ６４とに接続されるインタフェースを備え
ている。

【００６９】送信側では、ネットワーク・インタフェー
スは、送信メッセージ・コプロセッサ６８が処理をする
送り元制御情報７４をこのインタフェースを通じて、ホ
ストコンピュータ２２から送信側メッセージ・コプロセ
ッサ６８に送る。その送り元制御情報は、出力メッセー
ジに挿入されるべき宛先制御情報７６を得るための方法
を、メッセージ・コプロセッサ６８に示す。命令を表す
返信７８は、送信側のメッセージ・コプロセッサ６８に
よって、ネットワーク・インタフェース６６に返され
る。この命令は、その出力メッセージに挿入されるべき
宛先制御情報７６を得るための方法を表している。

【００７０】受信側では、受信メッセージが、７６に表
されているように、メッセージ処理で使用される宛先制
御情報を含んでいる場合、その宛先制御情報は、７６に
示すように、受信側のメッセージ・コプロセッサ６４
に、送信される。次に、その受信側のメッセージ・コプ
ロセッサ６４は、ネットワーク・インタフェースに返信
６２を与え、その返信は、そのメッセージ上の、ネット
ワーク・インタフェース６６によって実行される動作を
表す小集合の命令の内の１つの命令を表している。

【００７１】送り元制御情報７４を、送信側メッセージ
・コプロセッサ６８に通信し、また、送信側メッセージ
・コプロセッサ６８からネットワーク・インタフェース
６６に、返信７８を通信するための簡単なインタフェー
スは、ネットワーク・インタフェースと、送信側メッセ
ージ・コプロセッサ６８との間の、アプリケーション・
プログラミング・インタフェースの見本を提供する。同
様に、宛先制御情報７６を受信側メッセージ・コプロセ
ッサ６４に通信し、返信６２を、受信側メッセージ・コ
プロセッサ６４からネットワーク・インタフェース６６
に通信するための簡単なインタフェースは、ネットワー
ク・インタフェースと、受信側メッセージ・コプロセッ
サ６４との間の、アプリケーション・プログラミング・
インタフェースの見本を提供する。

【００７２】使用されている個々のメッセージ・コプロ
セッサの能力と、それが処理する対応する制御情報用の
構文法(シンタックス)とによってのみ制限される、任意
の一組のメッセージ処理機能を実行するために、送信側
と受信側のメッセージ・コプロセッサは、プログラムさ
れ得る。ユーザは、そのメッセージ・コプロセッサが、
ネットワーク・インタフェース６６に備えられた数個の
命令の内の１つの命令を表す返信を常に返す限りは、そ
のメッセージ・コプロセッサによって実行されるべき動
作における、その制御情報の構文法を定義できる。送信
側と受信側のメッセージ・コプロセッサは、図１に暗示
するように物理的に独立したものである必要はない。そ
れらは、１台の物理的なものを多重化してもよい。

【００７３】この発明の一つの実施の形態において、ネ
ットワーク・インタフェースは、ローカルバス６９経由
で、ローカルメモリ９４にも接続されている。このロー
カルメモリは、例えば、現在使用中の仮想チャネルに関
する状態情報の保守のために、使用される表を含むこと
ができる。この実施の形態において、受信又は送信メッ
セージが、宛先制御情報７６を含んでいるかどうかは、
そのメッセージが通信しているコネクション、又は仮想
チャネルによって、決定される。ローカルメモリ９４の
表のエントリを使用して、標識が付けられる「特別に標
識が付けられた」仮想チャネルは、宛先制御情報７６を
有していると考えられるが、他のコネクションや仮想チ
ャネル上のメッセージは、そのような宛先制御情報７６
を有しているとは考えられない。

【００７４】そのようなメッセージ処理用支援機能付き
のネットワーク・インタフェースとメッセージ・コプロ
セッサへのインタフェースの実施については、図２乃至
１８に関連して、以下に詳述する。受信側メッセージ処
理の支援については、先ず、図２、図４及び図５に関連
して、さらに詳述する。

【００７５】図２を参照すると、ネットワーク・インタ
フェースの受信側８２は、ローカルバス６９に接続さ
れ、そのローカルバスには、任意の受信側メッセージ・
コプロセッサ６４と任意のローカルメモリ９４が、接続
されている。そのネットワーク・インタフェースの受信
側８２は、一般に、下記のように動作する。宛先制御情
報７６を有するメッセージが受信されて、８３で、その
内容が宛先制御情報７６とデータ８５に分割される。ヘ
ッダ７７は、仮想チャネル(ＶＣ)データと他の状態情報
を得るために、処理される。その仮想チャネル、状態、
及び宛先制御情報は、ローカルバス６９に供給され、そ
のローカルバスからそれらの情報が、受信側メッセージ
・コプロセッサ６４によって受信される。そのメッセー
ジ・コプロセッサ６４の処理の完了後、返信命令と引数
６２が、メッセージ・コプロセッサによって、ローカル
バス６９経由で、ネットワーク・インタフェースに返さ
れる。そのネットワーク・インタフェースは、コントロ
ーラ８７を備え、そのコントローラは、データ８５をホ
ストメモリの指定された位置に保存する等の指示を表し
ている、データ８５を処理するために、返信６２を使用
する。

【００７６】図３は、受信側処理に関係するネットワー
ク・インタフェースの構成要素の、さらに詳しいブロッ
ク図である。図３において、ローカルメモリは、ＲＸ
ＶＣ表として知られる受信側仮想チャネル表９６を、有
している。ＲＸ ＶＣ表の各エントリに対して、この仮
想チャネルが、メッセージ処理動作を支援するか否かの
表示９８が提供され、支援する場合は、当初の宛先制御
情報の長さの表示９１が、提供される。その表には、残
りのセルを、９３で表されているメッセージの同じ制御
区分に保存するための物理的アドレス等の、ＶＣ単位の
他の状態情報も含まれる。受信側メッセージ・コプロセ
ッサ６４と共に、ローカルメモリ９４は、ローカルバス
６９経由で、受信側(ＲＸ)メッセージ処理コントローラ
１５０に接続されている。ＲＸメッセージ処理コントロ
ーラ１５０は、入力メッセージに関して、メッセージ処
理ステップをとるか否かを決定するＲＸ ＶＣ表を使用
し、また、そのような動作を実行するメッセージ・コプ
ロセッサとの通信の制御も行う。

【００７７】メッセージは、ネットワークから、入力Ｆ
ＩＦＯ１６０によって受信され、次に、そのメッセージ
は、通常、入力ＦＩＦＯ１６０の最初の記憶位置であ
る、処理バッファ１５８に送信される。その処理バッフ
ァ１５８は、ネットワーク・インタフェースによる処理
のために、各セルを保存する。宛先制御情報とヘッダ
は、処理バッファ１５８から読み取られる。ヘッダ処理
回路１６６は、メッセージからヘッダ情報を読み取っ
て、ＶＣ情報を判定し、それをメッセージ処理コントロ
ーラ１５０に供給するために設けられ、そのコントロー
ラ１５０は、受信側仮想チャネル表(ＲＸ ＶＣ表)９６
を使用して、メッセージ処理動作が、実行されるべきで
あるかを判断する。そのようなメッセージ処理が実行さ
れない場合は、通常のネットワーク・インタフェースに
おける場合と同様に、メッセージ処理が続行される。こ
の様態において、図２０に関連して上述したように、ネ
ットワーク・インタフェースの受信側は、アドレス生成
回路１６２、マルチプレクサ１６３、マッピング回路１
６４、出力ＦＩＦＯ１５６、及びＤＭＡ回路１５４を具
備している。

【００７８】メッセージ処理動作を実行するための、ネ
ットワーク・インタフェースの受信側８２の一般的な動
作を、以下に記述する。ネットワーク・インタフェース
の受信側８２には、入力メッセージ７２から宛先制御情
報７６を抽出して(図２参照)、それを受信側メッセージ
・コプロセッサ６４に供給するという、全般的な仕事が
ある。上記のステップ後に、仮想チャネルに、特別に標
識が付けられていて、つまり、メッセージ処理が実行さ
れるべきであることを、ネットワーク・インタフェース
が、確認した場合、ネットワーク・インタフェースは、
ＲＸ ＶＣ表９６を使用して(図３参照)、宛先制御情報
の長さを判断する。次に、メッセージ処理コントローラ
１５０は、処理バッファ１５８中のこの宛先制御情報に
アクセスして、それを受信側メッセージ・コプロセッサ
６４に送る。そのメッセージ・コプロセッサは、このデ
ータを宛先制御情報と判断して、適切な動作をする。そ
の動作は任意であり、メッセージ・コプロセッサのプロ
グラマに任される。そのネットワーク・インタフェース
は、次に、メッセージ・コプロセッサ６４からの返信６
２(図１参照)を読み返す。

【００７９】この発明のある実施の形態による受信側の
ネットワーク・インタフェースと、メッセージ・コプロ
セッサ６８とのインタフェースについて、以下に記述す
る。受信側８２では、ネットワーク・インタフェース
は、２つのメモリ・マッピングされた区画を経由し、さ
らにローカルバス６９を経由して、メッセージ・コプロ
セッサと通信する。使用される区画数は、実施の形態毎
に異なる；しかし、インタフェースは、一般に、少なく
とも２つの区画を必要とする。第１の区画は、宛先制御
区画と呼ばれるが、受信メッセージからの宛先制御情報
を、メッセージ・コプロセッサに書き込むために使用さ
れる。この区画は、開始区画と呼ばれる区画も含み、こ
れは、宛先制御区画に書き込まれた宛先制御情報の処理
を開始するべきであることを示すために、メッセージ・
コプロセッサに、開始信号を与える目的で使用される。
第２の区画は、返信区画と呼ばれるが、メッセージ・コ
プロセッサからネットワーク・インタフェースへの返信
を保存する。ネットワーク・インタフェースは、適当な
ときに、この区画から返信を読み出す。その返信区画
は、ホストメモリにアクセスするためのアドレス、ロー
カルメモリにおけるアドレス、メッセージ・コプロセッ
サでのアドレス、又は他の引数等の引数、及び命令を通
信するために、２つ以上の区画に小分割されることもあ
る。

【００８０】動作において、ネットワーク・インタフェ
ースは、適切なデータ、例えば、受信メッセージからの
宛先制御情報を、宛先制御区画に書き込み、次に、命令
を開始区画に書き込む。メッセージ・コプロセッサは、
その宛先制御情報を処理し、その結果、その情報は、返
信区画に書き込まれる小集合の命令の中の１つの命令
と、可能な場合、１つ以上の引数になる。

【００８１】ネットワーク・インタフェースの受信側
は、そのインタフェースを簡単にするために、受信側
が、メッセージ・コプロセッサから認識する小集合の命
令を有している。これらの命令は、下記のように、ネッ
トワーク・インタフェースによって実行される簡単な動
作に、対応している： １．そのメッセージを破棄する(メッセージのフィルタ
リングのため)。 ２．そのメッセージの先頭に、その制御情報を復元す
る。 ３．フリーバッファに、指定量の残りのメッセージを保
存する。 ４．メッセージ・コプロセッサに指定されたアドレス
に、指定量のその残りのメッセージを保存する。 ５．そのメッセージから、さらに多くのデータを、メッ
セージ・コプロセッサに送り、別の命令を読み返す。 ６．リモート読取り動作に対するような返信を始動す
る。 ７．ホストコンピュータに対して割込を始動する。

【００８２】この命令の一覧表は、単に説明のためだけ
であって、制限をするものではないことを理解された
い。

【００８３】返信区画の構造は、一般に、数バイトのデ
ータであり、その中のある区分は命令を表し、１つ以上
の他の区分は引数を表す。例えば、１バイトのデータが
命令を表す。第２のバイトが、引数を表す。その命令
は、一組になった少数の命令の内のどれを実行するか
を、単に示すだけである。

【００８４】ある実施の形態における、宛先制御区画の
特定の形式と返信区画が、例Ａに説明されている。

【００８５】例Ａ：受信側仕様 １．受信側メッセージ処理支援機能の動作は、下記の通
りである： １．ＡＴＭ ＡＡＬ０又はＡＡＬ５フレームの最初のセ
ルが到着すると、ネットワーク・インタフェースは、レ
ジスタRX MP DATAによって指定された物理的アドレスで
始まるメッセージ・コプロセッサに、そのセルの先頭に
ある、Ｎ(３２ビット)ワードの制御情報を、書き込む。
Ｎは、仮想チャネル(ＶＣ)表で指定され、そのセルが、
ＡＡＬ５の最終フレームであれば、１０以下でなければ
ならず、そうでなければ、１２以下でなければならな
い。 ２．ネットワーク・インタフェースは、レジスタRX_MP_
CNTL_BASEの内容（RX MP CNTL BASEによって示される内
容）によって指定される物理的アドレスに、ＶＣチャネ
ル番号とＧＯ信号を含む単一ワードを、書き込む。 ３．ネットワーク・インタフェースは、<RX MP CNTL BA
SE>+4の位置で、そのメッセージ・コプロセッサから、
命令ワードを読み返す。 ４．ネットワーク・インタフェースは、以下に詳述する
ように、その命令を解釈する。グローバルRX MP enable
フラグがセットされ、ＶＣ毎のフラグMP on rxvcもセッ
トされたときだけ、このメッセージ処理活動が行われ
る。RX MP enableフラグがクリヤされ、しかし、MP on
rxvcはセットされていれば、MP on rxvcがクリヤされ
る。 ２．形式 ２．１ コプロセッサの項目 メッセージ・コプロセッサは、受信側のメッセージ処理
のために下記の項目を有する： アドレス 項目名 機能 RX_MP_CNTL_BASE+0 RX_MP_GO_VC 開始信号と仮想チャネル （書き込み） RX_MP_CNTL_BASE+4 RX_MP_CMD 命令処理（読み取り） RX_MP_CNTL_BASE+8 RX_MP_EXT_ADDR 外部アドレス（読み取り） RX_MP_CNTL_BASE+12 RX_MP_MSG_AGR1 返信メッセージの引数１ （読み取り） RX_MP_CNTL_BASE+16 RX_MP_MSG_ARG2 返信メッセージの引数２ （読み取り） RX_MP_CNTL_BASE+20 RX_MP_MSG_ADDR 返信メッセージのデータアドレス （読み取り） RX_MP_DATA+0 なし フレーム区分の最初のセルから制 から 御情報を受け取るメモリ区画 RX_MP_DATA+48 まで ２．２ ＧＯ ＶＣ項目 コプロセッサの場所MP_RX_GO_VCに書き込まれる値は、
３２ビット長で、下記の形式を有する。 31 30 29 23 19 15 0 g c crc 未使用 長さ 終了 ＶＣチャネル − GO[31]は、その項目が正規のGO命令であるかどうか
を示すgo_flagである。 − GO[30]は、RX_MP_DATAに書き込まれ、このGO命令に
よって送信された情報が、同じ制御区分からの情報の続
き(つまり、send_moreオプションにおけるような、同じ
セルからのデータの多重書き込み)であるかを示すcont_
flagである。 − GO[29]は、セル内容のCRC-10チェックの結果であ
る。 − GO[23:20]は、RX_MP_DATAにたった今、書き込まれ
たワード数である。 − GO[19:16]は、RX_MP_DATAにおける終了位置、つま
り、ベースRX_MP_DATAからコプロセッサに書き込まれる
最後のワードのオフセット）である。 − GO[15:0]は、ＶＣチャネル番号である。 − 他の項目は、未使用である。 ２．３ 命令項目 コプロセッサの場所MP_RX_CMDから読み返される命令
は、３２ビット長で、下記の項目を有する： − [31:24]は、命令である。 − [23:16]は、命令の引数１である。send_moreモード
で、[19:16]は、そのコプロセッサから読み取られる追
加ワード数を示す。send_replyモードでは、[23:16]
は、８ビットの制御情報であり、MSG FIFOのMSG_CNTL経
由で、送信側に渡される。これら２つのモードは、相互
に排他的である。 − [15:2]は、命令の引数２である。length_modeで
は、バッファに保存されるデータ量Pをワード数で表し
ている。 − [1:0]は、２ビットの外部命令である。MP_problem
モードでは、最下位ビットは、MP_RX_enableがクリヤさ
れるべきであるかを示す。 命令は、下記の形式を有する： 31〜 MP_fault send_more send_reply restore length_mode buff_mode skip_ 24 1 0 1st_FD store_rest int_1st_FD cont − CMD[31]--MP_problemは、コプロセッサの問題が発
生したことを示す。CMD[31]が表明されると、MP_on_rxv
cがクリヤされ、その命令は変更されて、「restore（復
元せよ）」に変わり、それにそのフレーム全体をRXfree
バッファに保存する"store_rest"が後続し、さらにホス
トコンピュータに、その問題が通知される。CMD[0]がセ
ットされると、その問題は、致命的な故障となり、MP_R
X_enableはクリヤされ；そうでない場合は、その問題
は、ＭＰエラーである。CMD[0]の値が何であっても、MP
_on_rxvcはクリヤされ、ＶＣ用に書き込まれる次のフレ
ーム記述子は、"MP_prob"を表し、さらに、ＶＣ用の次
のフレーム記述子を保存した後で、「RX MP interrupt
（受信側ＭＰ割込み）」が生成される。 − CMD[30]--send_moreは、ネットワーク・インタフェ
ースは、さらに多くの制御ワードをコプロセッサに送
り、さらに命令を再読すべきであることを示す。セット
されれば、数個の追加ワードが、命令引数１によって指
定される。send_more命令は、セルがＡＡＬ５の最終フ
レームである場合は１０ワードまで、そうでない場合は
１２ワードになるまで、何度も繰り返される。無限ルー
プを避けるために、少なくとも１ワードは送られる。任
意の点で、制御情報の総ワード数が、この数値を超える
と（send_more命令又はＶＣエントリで指定された当初
のcntl_lenのどちらかによって）、状態項目が"MP_size
_err"を表すこと以外は、ＭＰエラーと同じ動作が発生
する。 − CMD[29]--send_replyは、ネットワーク・インタフ
ェースは、送信側に送信を始動させるために、ＭＳＧ
ＦＩＦＯに、メッセージを入れるべきであることを表
す。命令の引数１は、８ビットの制御情報をＭＳＧ項目
に含めることを指定する。ＭＳＧ ＦＩＦＯが空いてい
ない場合は、状態項目が、"MP_msg_full"を示す以外
は、ＭＰエラーと同じ動作が行われる。 − CMD[28]--resoreは、ネットワーク・インタフェー
スは、コプロセッサに書き込まれた制御情報の全ワード
を、そのフレームの先頭に、復元するべきであることを
示す。これは、制御情報をそのフレームに戻させ、"pee
k"動作に影響する。制御情報をコプロセッサに送ること
は、通常は、"pop"動作である。 − CMD[27]--length_modeは、ネットワーク・インタフ
ェースは、入力フレームからの次のＰバイトを、CMD[2
6]によって示される宛先に書き込むべきであることを示
す。命令の引数２は、Ｐを指定する。 − CMD[26]--buff_modeは、ネットワーク・インタフェ
ースは、位置RX_MP_EXT_ADDRか、又はＲＸｆｒｅｅから
取り出したバッファからのどちらかから読み出した外部
アドレスで始まるバッファに、書き出すべきであること
を示している。この外部アドレスは、仮想チャネルとし
て解釈され、そのＶＣに適合した変換表を使用して、物
理的アドレスに変換される。 − CMD[25]--skip_1st_FDは、ネットワーク・インタフ
ェースが、このフレーム用の最初のフレーム記述子を、
ＲＸｄｏｎｅに書き出すことを省くべきか否かを表す。 − CMD[24]--store_restは、ネットワーク・インタフ
ェースが、上記の動作に従った後、そのフレームの残り
を、ＲＸｆｒｅｅから得た１つ以上のバッファ（通常の
送信側の動作におけるように）に保存するべきか否かを
表す。そうでない場合は、ネットワーク・インタフェー
スは、その入力フレームの残りを廃棄する。 − CMD[1]--int_1st_FDは、そのフレーム用の最初のフ
レーム記述子が、ＲＸｄｏｎｅに書き込まれるときに、
ＲＸｄｏｎｅフレーム割込を生成する（skip_1st_FDで
ない場合）。 − CMD[0]--contは、制御区分が後続することを示す。
セットされていると、上記の全ての動作の終了後、ネッ
トワーク・インタフェースは、次のセル境界までの入力
フレームの残りのデータを廃棄し、次に、上記のプロト
コルを繰り返す。 ２．４ ＲＸ ＶＣ表のエントリ ＭＰの受信側は、各ＲＸ ＶＣ表エントリの最初のワー
ドの下記の８ビットを、使用する。MP_control項目の形
式は、下記の通りである： − MP_control[7]は、ＭＰがこのＶＣに対して使用可
能であるかを示すMP_on_rxvcである。 − MP_control[6]は、その受け取ったセルが、制御区
分の先頭であり、ＭＰが、そのＶＣに対して使用可能で
あれば、ＭＰセルとして解釈されなければならないかを
示すstart_of_segmentである。 − MP_control[5]は、FD1であり、ＭＰ状態情報を保持
するために使用される１制御ビットである。 − MP_control[4]は、FD0であり、ＭＰ状態情報を保持
するために使用されるもう１つの制御ビットである。 − MP_control[3:0]は、cntl_lenであり、つまり、Ｍ
Ｐが、そのＶＣに対して使用可能であれば、ネットワー
ク・インタフェースが、そのＶＣの最初のセルの受け取
りの際に、先ず、メッセージ・コプロセッサに送らなけ
ればならない制御情報のワード数である。FD1とFD0は、
命令の実行時に使用される制御状態を定義する。

【００８６】上記例Ａに示す命令構造は、受信メッセー
ジの処理に対して、非常に大きい柔軟性を与える。制御
情報の長さは、固定量の宛先制御情報を、コプロセッサ
に送ることによって、メッセージ毎に変更でき、そのコ
プロセッサは、さらに多くの制御情報を送るように要求
することができる。制御区分の数も、変更することが可
能である。コプロセッサは、別の制御区画が直後に追随
していることを、表すことができる。明示的な分散ＤＭ
Ａは、アドレスデータ対毎に、ある制御区分にマッピン
グする。暗示的な分散ＤＭＡは、メッセージの途中でバ
ッファを変えることによって、支援される：つまり、指
定量のデータを、外部から供給されるか、又はＲＸｆｒ
ｅｅからの、あるバッファに送ることができ、その次
に、残りのデータを、１つ以上のバッファに送ることが
できる。あるバッファにヘッダを送り、別のバッファに
データを送るために処理をするＴＣＰ／ＩＰに、この柔
軟性が利用できる。この場合、ネットワーク・インタフ
ェースは、そのメッセージからのゼロデータをコプロセ
ッサに書き込む。ＴＣＰ／ＩＰのヘッダ長に等しい量の
データを保存した後で、そのバッファを変更することを
表している命令を、そのコプロセッサは、単に返すだけ
である。

【００８７】このインタフェースにより、メッセージ・
コプロセッサは、全てのメッセージの処理を、殆ど実行
し、また、実行可能な動作は、プログラム可能であっ
て、全く、ユーザー次第である。ネットワーク・インタ
フェースは、データスタックからメッセージデータを取
り出して、一組の数個の単純な命令として解釈される情
報を読み戻す。

【００８８】ネットワーク・インタフェースと受信側の
メッセージ・コプロセッサ６４との間の対話処理につい
て、図４と図５を参照しながら、以下に記述する。先
ず、ネットワーク・インタフェースは、受信メッセージ
が、特別に標識が付けられた仮想チャネル用であるか否
かを判断する。そうであれば、図４と図５の処理が、Ｒ
Ｘ ＶＣ表９６に示すように、予め指定された量のデー
タを、メッセージ・コプロセッサ６４に書き込む、ネッ
トワーク・インタフェースのステップ１７０から始ま
る。ネットワーク・インタフェースは、メッセージ・コ
プロセッサに命令して、その情報を処理させ、返される
べき命令をステップ１７２で待つ。そのネットワーク・
インタフェースは、指定回数のローカルバスサイクル
を、単に待つだけで、その命令のために、メモリマッピ
ングされたインタフェースの指定メモリ位置を読む。こ
の命令は、次に、ネットワーク・インタフェースによっ
て解釈される。その命令ワードは、命令とその命令に必
要な引数を表すような形式であり、従って、２つ以上の
項目を有している：１つは、命令の名称用であり、残り
の１つ以上は引数用である。その命令が故障を表す場合
(ステップ１７４)、メッセージ処理動作は、復元動作に
よって元に戻され、そのメッセージは、通常のメッセー
ジとして取り扱われる。その命令が、ステップ１７６で
判定されるように、コプロセッサに、さらに情報を送れ
という要請であれば、ステップ１７８で、さらにデータ
がコプロセッサに送られ、ネットワーク・インタフェー
スは、再度、ステップ１７２で待つことになる。ステッ
プ１７６と１７８により、所与のコネクション向けの可
変長の制御情報が可能になる。

【００８９】処理は、その命令が「send reply(返信を
送れ)」であるか否かを判定するステップ１８０で継続
される。この命令は、他のコンピュータにメッセージを
送るために、ステップ１８２でリモート返信動作を呼び
出すが、これについては図７乃至図１５に関連して以下
に詳述する。

【００９０】その動作が、ステップ１８４で判定するよ
うな、復元動作であれば、入力メッセージから読み出さ
れたデータは、ステップ１８６で、処理バッファ１５８
にあるそのメッセージに返される。処理は、ステップ１
８８から２００まで継続し、ステップ１８９で判定され
るように、そのメッセージからの指定量のデータを、指
定のアドレスにあるメモリ区画か(ステップ１９０)、又
はフリーバッファ一覧表ＲＸｆｒｅｅからのフリーバッ
ファに(ステップ１９２)書き込むことを含む。ステップ
１９６で判定されるように、そのメッセージ処理が完了
するか、又はメッセージ・プロセッサからの命令が、そ
のメッセージの残りの部分を廃棄することを示している
場合は、フレーム記述子がＲＸｄｏｎｅ待ち行列に書き
込まれる。そのフレーム記述子が書き込まれた後、メッ
セージ・コプロセッサからのその命令が、ホストプロセ
ッサに対する割込を生成するべきであることを示してい
る場合（ステップ１９９で判定されるように）、その割
込が、ステップ２０１で生成される。メッセージデータ
が残っていて、また、ステップ２０２で判定されるよう
に、この残ったデータが保存されるべきである場合に
は、そのメッセージは、ステップ２０４で、ＲＸｆｒｅ
ｅから選択されたフリーバッファに保存される。最後
に、ステップ２００で判定しているように、そのメッセ
ージが、後続の制御区分を有している場合、現在の制御
区分の終わりまでのデータが、ステップ２０５で廃棄さ
れ、処理は、そのメッセージの次の制御区画についてス
テップ１７０で、再開される。そうでない場合は、その
データはステップ２０６で廃棄されて、処理が終了す
る。

【００９１】実施の形態２．受信側の処理について記述
したが、ネットワーク・インタフェースにおけるメッセ
ージ処理支援の送信側について、図６から図１６までに
関連して、さらに詳細に、以下に記述する。

【００９２】図６は、ホストコンピュータ、ネットワー
ク・インタフェース、及び送信側メッセージ・コプロセ
ッサ６８による対話とデータの流れを、概略図で示して
いる。送信において、ホストコンピュータは、送り元制
御情報７４と、任意のデータ７３とを含むメッセージを
生成する。その送り元制御情報は、以下に詳述される
が、出力メッセージに挿入されるべき宛先制御情報、そ
れの存在する場所、あるいはそれの生成方法を示してい
る。そのメッセージが、ネットワーク・インタフェース
に送られると、そのネットワーク・インタフェースは、
７５で示すように、そのデータ７３から送り元制御情報
７４を分離して、その送り元制御情報を処理する。その
送り元制御情報７４は、返信７８を返す送信側メッセー
ジ・コプロセッサ６８に送られる。その返信は、ネット
ワーク・インタフェースへの命令であり、出力メッセー
ジ用の宛先制御情報７６を含むか、又は宛先制御情報７
６の位置を示すか、あるいは宛先制御情報７６の生成方
法示している。その宛先制御情報は、次に、７１に示す
ように、データ７３に由来するか又は返信命令７８に指
定されるデータ７２と結合されて、出力メッセージ７０
となる。

【００９３】送り元制御情報７４の形式について、図７
と図８に関連して記述する。送り元制御情報は、一般
に、ＴＸｉｎ待ち行列のフレーム記述子に由来する。そ
のフレーム記述子及び送り元制御情報は、多種の形式が
ある。図７に示すようなこの発明のある実施の形態にお
いて、フレーム記述子４００は、データ毎に、４バイト
で４行の区画を有している。第１行において、第１バイ
ト４０２は状態情報で、第２バイト４０４は、下記の短
命令モードでの送り元制御情報用に使用される。次の２
バイト４０６は、ＶＣチャネル番号用である。次の行４
０８は、下記で参照されるように、バッファアドレス又
はデータポインタである。第３行４１０は、短命令モー
ドにおける４バイトの追加送り元制御情報であるか、又
はＡＴＭＡＡＬ５用のＣＰＣＳ後書き情報である。最後
の行は、１バイトのモード情報４１４，１バイトのバッ
ファ識別子４１６，２バイトのバッファ長４１８を含ん
でいる。

【００９４】ネットワーク・インタフェースが、どの形
式の送り元制御情報を予期しているかを示す、仮想チャ
ネル毎の表のエントリを維持するか、又は、フレーム記
述子が、送り元制御情報の形式を示す。

【００９５】その送り元制御情報を符号化する最も簡単
な方法は、項目４０４と項目４１０を使用して、図７に
示すように、フレーム記述子に、直接的に符号化するこ
とである。そのフレーム記述子４００は、項目４０８に
送られるべきデータ４２０へのポインタも含んでいる。
この「短命令」形式により、送り元制御情報の長さは、
そのフレーム記述子の長さによって制限される。しか
し、送り元制御情報及びフレーム記述子は、１回のメモ
リ動作で、ネットワーク・インタフェースに送られるの
で、この形式は、短い待ち時間用に好適である。

【００９６】さらに長い送り元制御情報に対しては、そ
の送り元制御情報の直接符号化の代わりに、図８のフレ
ーム記述子４２４にあるように、送り元制御情報を含ん
でいるホストメモリ４２２の位置への、項目４０８の参
照子又はポインタが使用される。これらの実施の形態の
どちらにおいても、送り元制御情報は、命令として、送
信側のメッセージ・コプロセッサに送られるべきデータ
である。

【００９７】図９から図１４は、出力メッセージを形成
するための、可能な範囲を示している。図９に示される
形式では、フレーム記述子４２６が、送り元制御情報を
全く含んでいない。項目４０８を使用して表される、送
られるべきデータ４３０は、適当な場所に、宛先制御情
報４２８を、既に含んでいる。このモードは、仮想チャ
ネルに対する送信側が、メッセージ処理の支援をせず、
宛先が行うときに、使用される通常モードである。

【００９８】図１０においては、フレーム記述子４３２
は、図７におけるように、項目４１０を使用して、フレ
ーム記述子で直接的に符号化された送り元制御情報と、
項目４０８にデータ４３４へのポインタとを含んでい
る。ネットワーク・インタフェースは、出力メッセージ
を生成するために、送信側メッセージ・コプロセッサ６
８によって生成された宛先制御情報を、フレーム記述子
によって示されたデータに付加する。

【００９９】図１１において、フレーム記述子４３８
は、図７におけるように、項目４１０を使用して、フレ
ーム記述子で直接的に符号化された送り元制御情報と、
未使用のデータポインタとを含んでいる。送信側メッセ
ージ・コプロセッサ６８は、宛先制御情報４４０の位置
と、データ４４２が読み取られるべきホストメモリの位
置との両方を計算する。

【０１００】図１２から図１４において、送り元制御情
報は、フレーム記述子に組み込まれていない；その代わ
りに、フレーム記述子のデータポインタが、図８におけ
るように、送り元制御情報の位置を示している。図１２
に示すフレーム記述子４４４において、送られるべきデ
ータ４４６は、項目４０８を使用して参照される位置に
ある送り元制御情報に後続する。送信側メッセージ・コ
プロセッサ６８は、宛先制御情報４５０も生成する。

【０１０１】図１３において、フレーム記述子４４７を
使用して、送り元制御情報４５４に後続する任意のデー
タ４５２は無視され、その代わりに、送られるべきデー
タ４５６の位置が、送り元制御情報４５４の中の情報に
基づいて、送信側メッセージ・コプロセッサ６８によっ
て、計算される。送信側メッセージ・コプロセッサ６８
は、宛先制御情報４５０も生成する。

【０１０２】最後に、図１４において、フレーム記述子
４５８は、バッファ４６０の連結された一覧表を表して
いる。第１のバッファの最初の部分は、送り元制御情報
４６２であると解釈される。宛先制御情報４５０の位置
と、供給された送り元制御情報に基づいて、送られるべ
きデータ４６４の位置とを、送信側メッセージ・コプロ
セッサ６８が計算する。一旦、このコプロセッサ指定の
データが送られると、ネットワーク・インタフェース
は、連結一覧表における第１バッファの残りのデータを
無視して、連結一覧表における第２以降のバッファから
データを送る。

【０１０３】図１５は、送信側メッセージ処理に関す
る、ネットワーク・インタフェースの構成要素のブロッ
ク図である。図１５において、メッセージ処理コントロ
ーラ１００は、ネットワーク・インタフェースによるメ
ッセージ処理を制御する。ローカルバス６９は、送信側
メッセージ・コプロセッサ６８と、可能ならば、送信側
仮想チャネル（ＴＸ ＶＣ）表９７を含むローカルメモ
リ９４とに、接続されている。そのＴＸ ＶＣ表は、各
仮想チャネル毎に、メッセージ処理のために、その仮想
チャネルに特別に標識が付けられているか否かを示す表
示９５を有し、そうである場合には、その表は、送信側
メッセージ・コプロセッサに送るために、送り元制御情
報の長さの表示９９を有する。ＴＸ ＶＣ表９７は、そ
の仮想チャネルが、送り元制御情報を直接的に符号化す
る、フレーム記述子を使用しているか否かの表示（図示
せず）も、含んでいる。図示のように、ＴＸ ＶＣ表９
７は、他のＶＣ状態情報も、含んでいる。

【０１０４】送信側の一般的な動作について記述する。
ネットワーク・インタフェースの送信側８０は、宛先制
御情報７６を出力メッセージ７０に付加するという全般
的な仕事がある(図６参照)。その宛先制御情報７６をメ
ッセージに付加するための最も簡単な方法は、図９のよ
うに、ホストコンピュータに、この機能を実行させるこ
とであるが、この方法は、一般に、ホストコンピュータ
の、さらに多くの関与と通信のオーバーヘッドを必要と
する。送信側８０に判断させて、宛先制御情報を出力メ
ッセージに付加させるために、ホストコンピュータは、
メッセージ・コプロセッサ向けの送り元制御情報を含む
フレーム記述子と、任意のメッセージデータとを、ＴＸ
ｉｎ待ち行列に入れる。フレーム記述子は、図９から図
１４に示すような形式のいずれかであるが、それには制
限されない。ネットワーク・インタフェースは、先ず、
適切なときに、ＴＸｉｎ待ち行列から、あるフレーム記
述子を取り出す。そのフレーム記述子は、先ず、それが
対応する仮想チャネルを判断し、ヘッダ処理回路１１６
を使用して、ヘッダを作成するために使用される。メッ
セージ処理動作の必要が無い通常のメッセージに対し
て、ネットワーク・インタフェースは、図１９から図２
１に関連して既に記述したように、そのメッセージを処
理する。しかし、その仮想チャネルに、特別に標識が付
けられている場合は、ネットワーク・インタフェース
は、フレーム記述子を使用して、その送り元制御情報の
位置を識別するか、又は、そのフレーム記述子から直接
的に送り元制御情報を読み取る。次に、ネットワーク・
インタフェースは、指定の処理を実行するために、送り
元制御情報７４を、送信側メッセージ・コプロセッサ６
８に送る。送信側メッセージ・コプロセッサは、次に、
送り元制御情報７４を使用して、宛先制御情報７６と、
ＴＸ ＶＣ表９７によって指定されたメッセージの位置
にある、送信メッセージの中の宛先制御情報に付加する
データの位置を判断する。宛先制御情報は、送信側メッ
セージ・コプロセッサに書き込まれた送り元制御情報に
由来するか、又は送信側メッセージ・コプロセッサによ
って実行された任意の処理から、例えば、コプロセッサ
のレジスタから来るものかのどちらかであり、処理バッ
ファ１０８で出力メッセージに挿入される。そのメッセ
ージデータは、当初に待ち行列に入れられたメッセージ
の残りからか、又は送信側メッセージ・コプロセッサに
よって供給されたアドレスから来るかのどちらかであ
る。処理バッファ１０８で、メッセージに付加されるデ
ータにアクセスするために、そのアドレスは、アドレス
生成モジュール１１２、マッピングモジュール１１４、
及びＤＭＡモジュール１０４によって処理される。

【０１０５】ある実施の形態におけるネットワーク・イ
ンタフェースの送信側と、送信側メッセージ・コプロセ
ッサ６８との間のインタフェースについて、さらに詳述
する。送信側８０では、ローカルバス６９及びメモリマ
ッピングされた区画経由で、ネットワーク・インタフェ
ースは、メッセージ・コプロセッサ６８と通信する。使
用される区画数は、実施状態で変化する；しかし、イン
タフェースは、一般に、少なくとも２つの区画を必要と
する：１つは送り元制御情報をメッセージ・コプロセッ
サに送るための区画で、送り元制御区画と呼ばれ、他の
区画は、返信を読むため区画である。その送り元制御区
画は、開始命令と、ＶＣ番号又は状態情報等の他の情報
とを受け取る要求区画を含んでいる。命令と、宛先制御
情報又はアドレス等の関連引数とを、ネットワーク・イ
ンタフェースに通信するために、返信区画は、メッセー
ジ・コプロセッサによって使用される。

【０１０６】動作において、ネットワーク・インタフェ
ースは、適切なデータ、例えば、送り元制御情報を送り
元制御区画に書き込み、次に、開始命令を書き込む。メ
ッセージ・コプロセッサは、送り元制御情報を処理し
て、宛先制御情報、アドレス、又はたの引数と共に、返
信区画に書き込まれる小集合の命令の中の１命令にす
る。

【０１０７】ネットワーク・インタフェースの送信側
は、そのインタフェースを簡単にするために、メッセー
ジ・コプロセッサから認識する小集合の命令を有してい
る。これらの命令は、下記のような、ネットワーク・イ
ンタフェースによって実行される簡単な動作に、対応し
ている： １．メッセージ・コプロセッサから読み込まれた１メッ
セージのデータを構成する。 ２．そのメッセージから読み出された１メッセージのデ
ータを構成する。 ３．指定されたアドレス、例えば、ホストメモリのアド
レスから読み出された１メッセージのデータを構成す
る。 ４．メッセージ・コプロセッサ、及びメッセージ又は指
定されたアドレスのどちらかから読み出された、１メッ
セージのデータを構成する。 ５．メッセージ・コプロセッサに指定量のデータを書き
込み、さらに、別の命令を読み返す。 ６．故障が、メッセージ・コプロセッサに発生してい
る。

【０１０８】この命令一覧表は、単に説明のためだけで
あって、制限をするものではないことを理解されたい。
命令構造は、一般に、数バイトのデータであり、その中
のある区分は命令を表し、１つ以上の他の区分は引数を
表す。例えば、１バイトのデータが命令を表す。第２の
バイトが、引数を表す。その命令は、小集合の命令の内
のどれを実行するかを、単に示すだけである。

【０１０９】送り元制御区画と返信区画の構造の、ある
例が、例Ｂに示されている。

【０１１０】例Ｂ：送信側仕様 １．送信側メッセージ処理支援機能の動作は、ＭＰモー
ドでの仮想チャネルに対して、下記の通りである： １．ＶＣが短命令モードであり、そのＶＣ用フレーム記
述子が、ＴＸｉｎにあるときは、ネットワーク・インタ
フェースは、そのフレーム記述子に含まれている８.５
バイトの制御情報を、ＴＸ ＶＣ表にある、一時的な場
所に保存する。 ２．ＶＣが短命令でなく、フレームが、先ず送信用に予
定されているときは、ネットワーク・インタフェース
は、ＶＣチャネル番号、ある追加制御情報、及びＧＯ信
号を含む１ワードが追随する、２ワードの制御情報を、
レジスタTX_MP_CNTL_BASEの内容によって指定された物
理的アドレスから始まる位置に、書き込む。ＶＣが短命
令モードではない場合、フレーム制御区分毎の開始点
で、ネットワーク・インタフェースは、指定された当初
のワード数の送り元制御情報を、その制御区分の初めか
ら、TX_MP_DATA_INで始まる連続的なアドレスに、書き
込みをする。次に、ネットワーク・インタフェースは、
ＶＣチャネル番号、コプロセッサに、たった今書き込ま
れたワード数、ＧＯ信号を含む１ワードを、<TX_MP_CNT
L_BASE>+8の場所に、書き込む。 ３．ネットワーク・インタフェースは、<TX_MP_CNTL_BA
SE>+12に含まれている物理的アドレスから、コプロセッ
サからの命令ワードを読み返す。 ４．ネットワーク・インタフェースは、以下に詳述する
ように、その命令を解釈する。グローバルTX_MP_enable
フラグがセットされ、ＶＣ毎のフラグMP_on_txvcもセッ
トされたときだけ、このメッセージ処理活動が行われ
る。MP_on_txvcはセットされ、しかし、TX_MP_enableフ
ラグがクリヤされていれば、フレーム記述子を、その状
態項目において"MP_disable"を有するＴＸｄｏｎｅに書
き込むことによって、そのフレームは、打ち切られる。 ２．形式 ２．１ コプロセッサの項目 メッセージ・コプロセッサは、受信側のメッセージ処理
のために下記の項目を有する： アドレス 項目名 機能 TX_MP_CNTL_BASE+0 TX_MP_CNTL1 制御情報の第１ワード （書き込み） TX_MP_CNTL_BASE+4 TX_MP_CNTL2 制御情報の第２ワード （書き込み） TX_MP_CNTL_BASE+8 TX_MP_GO_VC 開始信号とＶＣチャネル （書き込み） TX_MP_CNTL_BASE+12 TX_MP_CMD 命令処理（読み取り） TX_MP_CNTL_BASE+16 TX_MP_ADDR 宛先制御情報アドレス （読み取り） TX_MP_CNTL_BASE+20 TX_MP_EXT_ADDR 外部アドレス（読み取り） TX_MP_DATA_IN+0 なし ホストから送り元制御情報を受け から 取るメモリ区画 TX_MP_DATA_IN+48 まで ２．２ 制御情報 メッセージ・コプロセッサに送られる制御情報は、フレ
ーム記述子に含まれている。短命令モードに対しては、
８．５バイトの送り元制御情報が、下記のようにフレー
ム記述子から抽出される。TX_MP_CNTL1は、バッファＩ
Ｄの内容からの３．５バイトとバッファ長項目である。
TX_MP_CNTL1の特定の形式は、下記の通りである： ネットワーク・インタフェース（ＴＸ ＶＣ表）によっ
て維持されているバッファ長は、後にコプロセッサ命令
によって変更される。バッファＩＤは、変更されない。
TX_MP_CNTL2は、フレーム記述子のＣＰＣＳ項目の内容
からの４バイトである。最終的な１バイトの制御情報
は、８ビットのＶＰＩ／ＶＣＩ項目から抽出されて、Ｇ
Ｏ＿ＶＣ命令経由で渡される。 ２．３ ＧＯ＿ＶＣ項目 コプロセッサの場所MP_TX_GO_VCに書き込まれる値は、
３２ビット長で、下記の形式を有する。 31 30 29 28 27 26 24 23 16 15 0 g c t m s 未使用 制御／長さと終了 ＶＣチャネル − GO_VC[31]は、その項目が正規のGO命令であるかど
うかを示すgo_flagである。 − GO_VC[30]は、TX_MP_DATA_INに書き込まれ、このGO
命令によって送信された情報が、同じ制御区分からの情
報の続き（つまり、send_moreオプションにおけるよう
な、同じセルからのデータの多重書き込み）であるかを
示すcont_flagである。 − GO_VC[29]は、ＡＡＬタイプフラグである。ＡＴＭ
タイプＡＡＬ０に対しては０であり、タイプＡＡＬ５に
対しては１である。 − GO_VC[28]は、モード表示である：短命令モード
（送り元制御情報がTX_MP_CNTL1とTX_MP_CNTL2にある）
であれば０であり、長命令モード（送り元制御情報が<T
X_MP_DATA_IN>から始まる場所に保存されている）であ
れば１である。 − GO_VC[27]は、送り元を示す：０は、ＴＸｉｎを示
し；１は、ＭＳＧ ＦＩＦＯを示す。 − GO_VC[23:16]は、短命令モードにおける１バイトの
送り元制御情報である。 − GO_VC[23:20]は、長命令モードにおいて、TX_MP_DA
TA_INに、たった今書き込まれたワード数である。 − GO_VC[19:16]は、長命令モードの場合、TX_MP_DATA
_INにおける終了位置である。 − GO_VC[15:0]は、ＶＣチャネル番号である。 ２．４ 命令項目 コプロセッサの場所MP_TX_CMDから読み返される命令
は、３２ビット長で、下記の項目を有する： − [31:24]は、命令である。 − [23:16]は、命令の引数１である。M、つまり、TX_M
P_ADDRによって指定されるアドレスから読み取られるワ
ード数を示す。 − [15:2]は、命令の引数２である。length_modeで
は、送信されるフレーム用に取り出すために、データ量
をワード数で表す。 − [1:0]は、外部命令情報である。MP_problemモード
では、CMD[0}は、MP_TX_enableがクリヤされるべきであ
るかを示す。 命令は、下記の形式を有する： 31〜 MP_fault send_more unused read_coproc length_mode buff_mode no_FD_ 24 1 0 wr fetch_rest unused cont − CMD[31]--MP_problemは、コプロセッサの問題が発
生したことを示す。CMD[0]がセットされると、その問題
は、致命的な故障となり、MP_TX_enableはクリヤされ
る。そうでない場合は、その問題は、ＭＰエラーであ
る。どちらの場合でも、その状態項目にある"MP_prob"
を有するＴＸｄｏｎｅに、フレーム記述子を書き込むこ
とによって、そのフレームは、打ち切られる。 − CMD[30]--send_moreは、ネットワーク・インタフェ
ースは、さらに多くの制御ワードをコプロセッサに送
り、さらに命令を再読すべきであることを示す。セット
されれば、数個の追加ワードが、命令引数１によって指
定される。詳細は、受信側のsend_moreに対するものと
同じである。 − CMD[28]--read_coprocは、ネットワーク・インタフ
ェースは、コプロセッサから読み出すべきであることを
示す。セットされると、ネットワーク・インタフェース
は、TX_MP_ADDRによって与えられる物理的アドレスから
開始するワードを読むことによって、最初のMワードの
送信されるフレーム（通常は、宛先制御情報）を形成す
る。 − CMD[27]--length_modeは、ネットワーク・インタフ
ェースは、データバッファから読み込まれたPバイトを
有するコプロセッサから、それが存在するならば、最初
のMバイトに、従うべきであることを示す。このモード
は、データ場長を変更し、分割表にあるbuf_len項目
を、Pに変更する。Pが最初に指定されたバッファ長より
大きい場合は、MP_pend_errを使用して、エラーが報告
される。Pが最初に指定されたバッファ長より小さい場
合は、そのバッファは、切り捨てられて、最初のバッフ
ァにある残りのデータは、送られない。命令の引数２
は、Pを指定する。 − CMD[26]--buff_modeは、ネットワーク・インタフェ
ースは、外部アドレス又は入力フレームから読み取るべ
きであるか否かを示している。セットされていると、ネ
ットワーク・インタフェースは、位置TX_MP_EXT_ADDRか
ら読まれた仮想チャネルから始めて、命令引数２で指定
された量のデータを取り出す。 − CMD[25]--no_FD_wrは、ネットワーク・インタフェ
ースが、フレーム記述子を、ＴＸｄｏｎｅに書き出すこ
とを、省くべきか否かを表す。フレーム記述子を書き込
むことは、任意であり、この命令ビットで制御される。 − CMD[24]--fetch_restは、ネットワーク・インタフ
ェースが、上記の動作に従った後、そのフレーム記述子
によって示された、そのフレームの残りからのデータを
有する上記のデータに、従うべきであるか否かを表す。
そうでない場合は、ネットワーク・インタフェースは、
そのフレーム記述子によって示された、そのフレームの
残りを廃棄する。 − CMD[0]--contは、制御区分が後続することを示す。
セットされていると、上記の全ての動作の終了後、ネッ
トワーク・インタフェースは、次のセル境界までの入力
フレームの残りのデータを廃棄し、次に上記のプロトコ
ルを繰り返す。 − 他の項目は、未使用である。 ２．５ ＴＸ ＶＣ表のエントリ 送信側のＭＰは、各ＴＸ ＶＣ表エントリの最初のワー
ドの下記の１２ビットを、使用する。MP_control項目の
形式は、下記の通りである： − MP_control[0]は、ＭＰが、このＶＣに対して使用
可能であるかを示すMP_on_txvcである。 − MP_control[1]は、そのフレーム記述子が、送信側
で作成されたものか、つまり、ＭＳＧ ＦＩＦＯで見つ
かったものかを示すMP_src_fRxである。 − MP_control[2]は、バッファ長エラーが発生したこ
とを示すMP_pend_errである。 − MP_control[3]は、ネットワーク・インタフェース
が、フレーム区分の最初のセルを分割していることを示
すStart_segmentである。 − MP_control[4]は、そのＶＣが、短命令モードであ
るか否かを示すshort_commandである。 − MP_control[5]は、ネットワーク・インタフェース
は、フレーム記述子をＴＸｄｏｎｅに書き込むべきでは
ないことを示すskip_FDである。 − MP_control[6]は、ネットワーク・インタフェース
は、そのフレームの残りを廃棄すべきであることを示す
discard_restである。 − MP_control[7]は、未使用である。 − MP_control[11:8]は、ネットワーク・インタフェー
スが、長命令モードでコプロセッサに書き込むべきであ
る最初のワード数の制御情報を示す。送信側が、ＶＣ用
のフレーム記述子をＴＸｄｏｎｅに書き込む場合は、常
に、MP_src_fRxビットと、MP_pend_errビットのＯＲを
取って、そのフレーム記述子の状態項目に入れる。

【０１１１】この例Ｂの命令構造には、大きな柔軟性が
ある。宛先制御情報の長さは、固定量のデータを、コプ
ロセッサに送ることによって、メッセージ毎に変更で
き、そのコプロセッサは、制御情報を表している、さら
に多くのデータを要求することができる。コプロセッサ
は、ＴＸｉｎにあるメッセージの先頭部分から、又はＴ
Ｘｉｎにあるフレーム記述子の他の項目から、送り元制
御情報を得ることができる。宛先制御情報は、コプロセ
ッサ又はＴＸｉｎのメッセージから得られる。最後に、
送信メッセージデータは、ＴＸｉｎにある残りのデータ
又はコプロセッサによって提供されるアドレスから得ら
れる。ＴＸｉｎの各エントリによって、多重制御区分
（宛先制御情報とデータを含む）が、送信メッセージ中
に生成される。

【０１１２】このインタフェースにより、メッセージ・
コプロセッサは、全てのメッセージの処理を、殆ど実行
して、実行される処理の種類は、プログラム可能であっ
て、全く、ユーザー次第である。ネットワーク・インタ
フェースは、データをメッセージ・コプロセッサに書き
込み、小集合の命令として解釈する情報を読み戻すだけ
である。

【０１１３】ネットワーク・インタフェースとメッセー
ジ・コプロセッサとの間の対話処理について、図１６を
参照しながら、以下に記述する。先ず、ネットワーク・
インタフェースは、ＴＸ ＶＣ表にアクセスするため
に、ＴＸｉｎ待ち行列から、次のメッセージの仮想チャ
ネル情報を取り出す。その仮想チャネルが、メッセージ
処理のために特別に標識が付けられている場合、図１６
の処理が実行される。

【０１１４】ステップ１２０において、ネットワーク・
インタフェースは、メモリマッピングされたインタフェ
ースの送り元制御区画経由で、送り元制御情報をメッセ
ージ・コプロセッサに書き込む。そのメッセージが、指
定量の制御データを有していない場合は、エラーが発生
し、メッセージ処理動作が終了するか、又は例外処理手
順が実行される。次に、ネットワーク・インタフェース
は、メッセージ・プロセッサに、任意の必要な処理を実
行するように命令する。ネットワーク・インタフェース
は、必要に応じて、数サイクルのローカルメモリバスサ
イクルの間、待機し(ステップ１２２)、次に、メモリマ
ッピングされたインタフェースの返信区画にある、メッ
セージ・コプロセッサによって書き込まれた命令ワード
を読み込む。ネットワーク・インタフェースは、次に、
この命令ワードを解釈する。その命令ワードは、その命
令と、その命令に必要な引数を表すために、フォーマッ
トされ、従って、２つ以上の項目を含んでいる：１つ
は、命令の名称用であり、残りの１つ以上は引数用であ
る。その命令が故障を表す場合(ステップ１２４)、処理
は終了する。その命令が、ステップ１２６で判断される
ように、コプロセッサに、さらに情報を送れという要請
であれば、ステップ１２８で、さらに多くのデータがコ
プロセッサに送られ、ネットワーク・インタフェース
は、再度、ステップ１２２で待つことになる。その命令
が、ステップ１３０で判定されるように、コプロセッサ
からデータを読み出す要求であれば、ステップ１３２
で、メモリマッピングされたインタフェースの返信区画
から、指定量のデータが読み出され、さらに、出力メッ
セージの一部を形成するために使用される。

【０１１５】処理は、指定量のデータが、メッセージ等
の別の位置から、又はホストメモリにある交代バッファ
の指定アドレスから、読み出されるべきであるか否かを
判断するステップ１３４に続く。次に、指定量のデータ
が、ステップ１３６、１３７、又は１３８で適切な供給
源から読み出され、出力メッセージに形成される。ステ
ップ１４０で判断するように、そのメッセージの残り
が、出力メッセージに使用されるべきである場合は、そ
のデータは、ステップ１４２で出力メッセージとして形
成される。そうでない場合は、別の制御区分が開始する
ときは(ステップ１４３)、処理された制御区分の残り
は、ステップ１４５で廃棄され、そのメッセージ中の次
の制御区分が、ステップ１２０から始まる処理をされ
る。後続の制御区分が無い場合は、そのメッセージの残
りは、ステップ１４４で廃棄される。最後に、必要に応
じて、フレーム記述子が、ステップ１４５と１４６で、
ＴＸｄｏｎｅに書き込まれる。

【０１１６】実施の形態３．リモート読取り動作等の返
信付きリモート動作を実行するための、このシステムの
使用について、この発明によるこの様態の、ある実施の
形態を図示している図１７と図１８を参照しながら説明
する。リモート動作は、書き込みと読み取り動作から成
っている。ホストの介入が無いリモート書き込み動作
は、上記のアーキテクチャによって支援される。リモー
ト書き込み動作に対して、メッセージ中の宛先制御情報
は、そのメッセージに、そのデータを書き込むホストメ
モリの位置を決めるために、復号される。リモート読み
取りが、本質的にさらに難しいのは、受信メッセージ
は、リモート書き込みのように復号されなければならな
いだけでなく、最初の送り元に返信するために、受信終
了時に送信動作が、開始されなければならないためであ
る。そうであっても、リモート読取りの支援も大切であ
るのは、書き込み動作だけしか行わないアプリケーショ
ンは、少ないからである。他の動作も、１通の返信メッ
セージが、最初の送り元に送られるようにするので、リ
モート読取りをするのに似たステップを含んでいる。例
としてリモート読取りを使って、以下の記述を行ってい
る。しかし、支援され得る動作の種類は、返信を当初の
送り元に送らせる動作の全ての動作を、含んでいる。

【０１１７】リモート読取りは、３つの部分に分けられ
て、支援される。第１部分は、ある命令、つまり、宛先
でのリモート書込みの処理である。そのリモート書込み
には、読み取り命令、アドレス、長さ、及び返信の場所
とアドレスが、含まれている。第２部分は、ホストコン
ピュータによる、その命令の解釈である。第３部分は、
要求された読み取り動作に対する返信を含む、戻りのリ
モート書込みの開始である。残念ながら、リモート読取
り動作の実行は、最長経路にあるホストコンピュータ
に、その読み取り命令の解釈をさせるので、読み取り要
求やホストコンピュータへのロードに対応した待ち時間
が、受け入れ難い長さになる。例えば、図１９から図２
１、及び図２２に示すシステムにおいて、ホストコンピ
ュータは、入力メッセージの処理をして、送信待ち行列
にエントリを生成し、さらに、ネットワーク・インタフ
ェースによって、そのエントリが処理されるのを待たな
ければならない。従ってこの実施形態は最後の解決手段
である。

【０１１８】この発明の実施の形態において、ネットワ
ーク・インタフェースは、リモート読取り動作に、ホス
トコンピュータを回避させる支援機能を有している。図
１７を参照すると、この支援機能は、ネットワーク・イ
ンタフェースの受信側８２と、送信側８０との間に配置
されたリモート読取り待ち行列２２０を、備えている。
そのリモート読取り待ち行列は、単一要素待ち行列又は
ＦＩＦＯと同様に小さい。リモート読取り待ち行列２２
０の要素２２２は、それが属している仮想チャネルの表
示２２３と、引数２２４とを含んでいる。ある実施の形
態において、リモート読取り待ち行列の要素２２２の形
式は、ＴＸｉｎ待ち行列８８にあるフレーム記述子２２
５の形式と同一(最初の数バイトにある、数ビットの状
態ビットを除いて)である。代わりに、リモート読取り
待ち行列のエントリ２２０は、フレーム記述子２２５の
形式とは違う数個の引数を含んでいる。フレーム記述子
２２５とリモート読取り待ち行列２２２の両方で、最初
の数バイトは、２２３と２２６に示すような、仮想チャ
ネルの表示を含んでいる。

【０１１９】ネットワーク・インタフェースは、下記の
ようにして、入力リモート読取り動作を処理する。先
ず、ネットワーク・インタフェースは、リモート書込み
と同様に、リモート読取り処理する。つまり、受信側
は、指定量のメッセージデータ、例えば、宛先制御情報
７６を、受信側メッセージ・コプロセッサに書き込み、
次に、命令を読み取る。通常は、受信側メッセージ・コ
プロセッサからの命令は、受信側８２で実行される。し
かし、その命令が「send reply（返信を送れ）」命令で
あれば、ＤＭＡ経由でホストメモリ位置からアクセスさ
れたデータに、ある制御情報を付加するために、ネット
ワーク・インタフェースは、送信側８０によって使用さ
れる同じ機構を呼び出す。

【０１２０】図１８は、リモート読取り動作を支援する
特定の実施の形態の動作を、詳細に説明している。他の
実施の形態も可能である。特に、図１に示すようなシス
テムは、リモート読取り待ち行列２２０を含むように、
変更できる。この実施の形態において、図１８に示すよ
うに、メッセージは、メッセージ処理用に標識が付けら
れたコネクションで受信される(ステップ２３０)。受信
側８２における他の動作に関して、ネットワーク・イン
タフェースは、ステップ２３２で、指定量の宛先制御情
報をメッセージ・コプロセッサに送る。この宛先制御情
報は、そのメッセージを、リモート読取り要求として識
別して、その読み取りのアドレスとサイズを与える。図
１７を参照すると、返信メッセージ５０２に宛先制御情
報５００を生成する支援をするために、宛先制御情報
は、ある返信制御情報５０４も含んでいる。図１８を参
照すると、メッセージ・コプロセッサは、ステップ２３
４で、ネットワーク・インタフェースが受信メッセージ
から、さらに多くのデータを送るべきであることを示す
命令を返す。ネットワーク・インタフェースは、返信の
場所とアドレスとして解釈されるように、要求された量
のデータ、つまり、返信制御情報５０４をメッセージ・
コプロセッサに送る(ステップ２３６)。ステップ２３８
で、メッセージ・コプロセッサは、返信メッセージ用の
宛先制御情報５００を形成して、後で読み出されるべき
メモリ位置に、それを保存する。メッセージ・コプロセ
ッサは、ステップ２４０で、「send reply(返信を送
れ)」命令を、ネットワーク・インタフェースに返す。

【０１２１】ネットワーク・インタフェースが、"send
reply"命令を検出すると、メモリマッピングされたイン
タフェースの命令区画にある、１つ以上の追加データ項
目から、１つ以上のメッセージ引数を読み取る(ステッ
プ２４２)。その引数は、送信側が、宛先制御情報を生
成するために使用するデータと、出力メッセージ用デー
タのための送り元とを含んでいる。ステップ２４４で、
ネットワーク・インタフェースの受信側８２は、送信側
８０が、後で処理をする仮想チャネルと、メッセージ引
数との両方を表しているメッセージを、リモート読取り
待ち行列に入れる。そのリモート読取り待ち行列２２０
を使用することにより、ネットワーク・インタフェース
の送信側８０は、ＴＸｉｎ待ち行列に、ホストメモリへ
のエントリの書き込みを、避けることができる。そのリ
モート読取り待ち行列の実施形態によっては、待ち行列
に入っているデータが、単一ワードか、又は多重データ
ワードであることもあり得る。

【０１２２】送信側は、リモート読取り待ち行列を定期
的にポーリングして、あるときに、送信側８０は、その
リモート読取り待ち行列２２０から、そのエントリを取
り出す(ステップ２４６)。そのリモート読取り待ち行列
の、そのデータを使用して、送信側は、そうでなければ
フレーム記述子から得るはずのデータを、獲得する。こ
の情報を得るために、ホストコンピュータにアクセスす
ることなく、送信側は、送り元制御情報を含むフレーム
記述子を処理できるので、受信側は、リモート読取り待
ち行列に、その送り元制御情報を生成するべきである。
そうでなければ、送信側は、リモート読取り待ち行列の
データを、特別に取り扱わなければならない。図１７に
示すような実施の形態において、リモート読取り待ち行
列の要素は、ＴＸｉｎにあるフレーム記述子と全く同じ
形式を有しているので、送信側は、リモート読取り待ち
行列の要素を、ＴＸｉｎのエントリと全く同じように処
理できる。特に、指示されたコネクションは、特別に標
識が付けられても、付けられなくてもよい。特別に標識
が付けられていない場合、送信側は、送信するバッファ
を表しているＴＸｉｎからのフレーム記述子と全く同様
に、リモート読取り待ち行列の要素を処理する。コネク
ションに特別に標識が付けられている場合は、送信側
は、メッセージ処理、つまり、送り元制御情報として、
リモート読取り待ち行列の要素から、送信側メッセージ
・コプロセッサへの引数を保存することを、始動する。

【０１２３】送信側メッセージ・コプロセッサは、ステ
ップ２５０で、任意の適切な命令、例えば、宛先制御情
報を読むための「read from coprocessor(コプロセッサ
から読め)」という命令と、ホストメモリからデータを
ＤＭＡするための「read fromexternal address(外部ア
ドレスから読め)」命令を、返す。次に、ネットワーク
・インタフェースは、メッセージ・コプロセッサから読
み取られて、以前に保存された宛先制御情報５００を、
そのメッセージの先頭に置き、さらに、読み取り返信デ
ータ用のホストメモリの所与の位置から、ＤＭＡを始動
する(ステップ２５２)。つまり、要求元で使用される要
求されたデータと、制御情報とを含むメッセージが、要
求元に送られる。

【０１２４】リモート返信を支援するためのメッセージ
・コプロセッサ用制御情報や返信命令構造の実施の形態
は、例Ｃに示されている。

【０１２５】例Ｃ：返信メッセージ １．待ち行列の要素 前記のように、受信側のsend_reply命令は、送信側に返
信メッセージを送るように命令する。受信側は、send_r
eply命令に後続し、受信側から送信側へのインタフェー
ス情報を通信するために、ＦＩＦＯ待ち行列を使用す
る。各待ち行列の要素は、下記の４つの項目を有してい
る： MSG_CNTL[32]；タグ、返信メッセージ用ＶＣチャネル番
号、及びある制御情報を含んでいる。 MSG_ARG1[32]；３.５バイトの引数を含み、その引数
は、バイト単位の返信メッセージデータ長を含んでい
る。 MSG_ARG2[32]；４バイトの引数を含んでいる。 MSG_ADDR[32]；返信メッセージデータ用仮想アドレスを
含んでいる。 ２．動作 受信側は、位置RX_MP_MSG_ARG1から下位２８ビットを、
MSG_ARG1に（TX_MP_CNTL1に送られるべきデータ）、位
置RX_MP_MSG_ARG2から３２ビットをMSG_ARG2に（TX_MP_
CNTL2に送られるべきデータ）、及び位置RX_MP_MSG_ADD
Rから読み取られたアドレスを、MSG_ADDRに書き込む。
送信側は、下記のように、フレーム記述子の項目と同様
の形式である、これらのＦＩＦＯ項目を解釈する： MSG_CNTL；フレーム記述子の第１項目に対応する。ＶＣ
チャネル番号、１バイトの制御情報、及び以下に示す８
ビットの項目を含んでいる。 MSG_ARG1；フレーム記述子の第４項目に対応し、２つの
項目を含む：特定の解釈の無い１２ビットの項目と、所
与のデータバッファに送るために、データ長として解釈
される１６ビット項目である。上位４ビットは、未使用
である。 MSG_ARG2；フレーム記述子の第３項目に対応し、引数を
含んでいる。 MSG_ADDR；フレーム記述子の第２項目に対応し、読むべ
きデータバッファのベースアドレス(仮想アドレス)を含
んでいる。これらのレジスタを使用して、受信側は、処
理のために送信側に渡されるフレーム記述子を構成す
る。送信側は、真のフレーム記述子と全く同じ、この工
夫された「フレーム記述子」を処理する。例え送信側が
現在ＴＸｉｎをポーリングしていなくても、送信側は、
継続的にＭＳＧ ＦＩＦＯをポーリングしなければなら
ない。宛先であるＶＣが空きになって、そのフレーム記
述子を受け入れ可能になるまで、フレーム記述子は、Ｍ
ＳＧＦＩＦＯに残る。 ３．形式 MSG_CNTLは、下記の形式を有している： 31 30 29 28 25 24 23 16 15 0 present rsvd daa_num aal_type 0 0 pti_lsb 0 cntl-info VC channel これは、フレーム記述子の第１項目の形式に近く構成さ
れている。MSG_CTRL[31]は、ＭＳＧ待ち行列要素が、占
有しているかを示すビットである。MSG_CTRL[30]は、留
保。MSG_CTRL[29]は、リング待ち行列の設定識別子であ
る。MSG_CTRL[28]は、ＡＡＬタイプの返信メッセージで
ある：ＡＡＬ５又はＡＡＬ０MSG_CTRL[27:26]は、未使
用。MSG_CTRL[25]は、内容タイプの表示項目の最下位ビ
ットである。MSG_CTRL[24]は、未使用。MSG_CTRL[23:1
6]は、８ビットの制御情報である。MSG_CTRL[15:0]は、
返信メッセージ用ＶＣチャネルである。 ４．実施 send_reply要求を引き起こす別のメッセージが到着した
ときに、ＭＳＧ ＦＩＦＯが空いていない場合は、ネッ
トワーク・インタフェースは、MP_on_rxvcをクリヤし、
そのメッセージに関する「restore（復元せよ）」命令
を出し、さらに、そのメッセージ全体を、ホストコンピ
ュータが取り扱うＲＸｆｒｅｅバッファに、ダンプす
る。ネットワーク・インタフェースには、メッセージ処
理を再度可能にするために、ＲＸ ＶＣ表のMP_on_rxvc
ビットを、リセットする責任がある。受信側は、MSG_CN
TLのビットをセットしてはいけないので、そのメッセー
ジの第１セルが処理されるまで、ＭＳＧ待ち行列要素
を、送信側が使用できるようにする。これにより、送信
側が返信メッセージの処理を開始する前に、その第１セ
ルのデータのメッセージ処理と保存が、完了する。その
返信メッセージは、そのメッセージの後続セルに含まれ
ているデータを、参照してはならないが、その理由は、
その返信メッセージに対する送信側の処理が、それらを
参照するときには、それらのセルは、まだ到着していな
い場合があるからである。

【０１２６】このようなリモート読取り動作のこの実施
形態は、受信側と送信側の両方のメッセージ処理支援機
能を利用している。送信側メッセージ・コプロセッサへ
のアクセスに対する競合は、返信メッセージを処理する
ための適切な時間が経過するまで待つことによって、ネ
ットワーク・インタフェースにより取り扱われる。

【０１２７】この発明の少数の実施の形態を説明した
が、前記のものは、単に説明のためであり、制約をする
ものでなく、例としてのみ表されたものであることは、
当業者には明確なはずである。多くの変更や実施の形態
は、通常の技術の範囲内であり、添付する特許請求の範
囲に規定されている本発明の範囲内であると考えられ
る。例えば、勿論、メッセージ処理のための、ネットワ
ーク・インタフェースにおける支援機能の実施形態は、
多種多様である。例えば、順次組み合わせ論理を使用し
た直接的なハードウェアでの実施、順次論理を使用して
いるマイクロプログラム化状態機械、及びマイクロプロ
セッサは、送信側と受信側を実現するために使用され得
る。ネットワーク・インタフェースとメッセージ・コプ
ロセッサとの間のインタフェースの種類は、種々の形態
が可能である。例えば、メッセージ・コプロセッサに、
能動的にネットワーク・インタフェースと通信させる、
バスインタフェースが提供可能である。代わりに、既述
のメモリマッピングされたインタフェース等の受動的な
インタフェースも使用できる。情報交換用プロトコル
も、種々の形態を取れることを理解されたい。

【０１２８】この発明は、コネクションベースの通信ネ
ットワーク用ネットワーク・インタフェースは、種々の
メッセージ処理動作を実行する任意のメッセージ・コプ
ロセッサと通信をするインタフェースを含む、メッセー
ジ処理用支援機能を有している。メッセージ処理は、ホ
ストコンピュータとネットワーク間のメッセージの低レ
ベル処理である。このような処理は、ホストから与えら
れる制御情報に応じて送信され、また、入力メッセージ
に含まれた制御情報に応じて受信される。メッセージ処
理には、待ち時間の少ないリモート読取り及び書込み動
作、メッセージ・フィルタリング、及びメッセージの多
重分離が含まれている。このようなネットワーク・イン
タフェースは、任意のプロセッサを使用して、種々のメ
ッセージ処理動作の支援機能を提供し、一方、この支援
機能によるネットワーク・インタフェースの複雑さとコ
ストを最小にする。ネットワーク・インタフェースは、
メッセージ・コプロセッサに、メッセージ用制御情報を
提供する。その制御情報は、そのメッセージ・コプロセ
ッサによって実行される動作と、可能ならばオペランド
とを示している。その動作とは、入力メッセージを処理
するか、又は出力メッセージを作成するかである。メッ
セージ・コプロセッサは、そのネットワーク・インタフ
ェースによって処理される小集合の命令の内の１命令に
応答する。そのメッセージ・コプロセッサからの命令
は、ホスト、又は離れた宛先にあって、データが保存さ
れる、メモリの位置等の追加データを含むこともある。
ネットワーク・インタフェースとメッセージ・コプロセ
ッサとの間のコネクションは、ネットワーク・インタフ
ェース上で、さらにローカルバス上の、メモリマッピン
グされたインタフェースである。ネットワーク・インタ
フェースは、メッセージ処理を支援するために、メッセ
ージから宛先制御情報を抽出し、また、宛先制御情報を
メッセージに挿入する機構を有している。ネットワーク
・インタフェースは、その宛先制御情報が、接続を経由
して受信又は送信したメッセージのどこにあるかを示し
ている情報を、各接続毎に保守している。この種のイン
タフェースを使用して、そのメッセージ・コプロセッサ
に供給される制御情報は、全く任意であって、メッセー
ジ・コプロセッサの能力にのみ制限される。メッセージ
・コプロセッサは、ネットワーク・インタフェースによ
って使用されるプロトコルに準拠している限りは、任意
に選択され得るので、そのネットワーク・インタフェー
スに関連して、新しい通信プロトコルで実験するのは、
簡単である。そのネットワーク・インタフェース上の送
信側と受信側の間の送信要求の待ち行列を設けることに
より、ホストプロセッサを回避するリモート読取り動作
に対する支援がなされ、また、メッセージ・コプロセッ
サを使用することにより、実行される。

【０１２９】

【発明の効果】以上のようにこの発明の第１〜１４の発
明では、ネットワークにホストコンピュータを接続する
ためのネットワーク・インタフェースの受信側であり、
そこでは、ネットワークは、ホストコンピュータと、複
数のコンピュータを接続している。そのネットワーク・
インタフェースの受信側は、コネクション経由で、複数
のコンピュータから受け取ったメッセージから、宛先制
御情報を抽出するための機構を備えている。この抽出さ
れた宛先制御情報は、そのネットワーク・インタフェー
スに接続された、メッセージ・コプロセッサに通信され
る。その抽出された情報の、メッセージ・コプロセッサ
への通信後、受信側は、その受信メッセージに関する動
作を実行するために、メッセージ・コプロセッサから宛
先制御情報に基づく命令と引数を受け取りそれを実行す
る。これにより、コネクションベースの通信ネットワー
ク用のネットワーク・インタフェースの受信側におい
て、短い待ち時間でかつメッセージ処理のための支援機
能の複雑さを減らしたものを提供できる等の効果が得ら
れる。

【０１３０】またこの発明の第１５〜２５の発明では、
ホストコンピュータと、ネットワークを接続するための
ネットワーク・インタフェースの送信側であり、そこで
は、ネットワークは、ホストコンピュータを、複数のコ
ンピュータに接続している。そのネットワーク・インタ
フェースの送信側は、ホストコンピュータから送り元制
御情報を受け取るための機構と、その送り元制御情報
を、ネットワーク・インタフェースに接続されたメッセ
ージ・コプロセッサに通信するための機構とを、備えて
いる。送信側は、メッセージ・コプロセッサへの送り元
制御情報の通信後に動作可能で、宛先制御情報を得るた
めに、メッセージ・コプロセッサから命令を受け取っ
て、それを実行するための機構も備えている。その宛先
制御情報は、次にコネクション経由で複数のコンピュー
タの内の１台に送信されるべきメッセージに挿入され
る。これにより、コネクションベースの通信ネットワー
ク用のネットワーク・インタフェースの送信側におい
て、短い待ち時間でかつメッセージ処理のための支援機
能の複雑さを減らしたものを提供できる等の効果が得ら
れる。

【０１３１】そしてこの発明の第２６の発明では、ホス
トコンピュータを、複数のコンピュータと接続している
ネットワークとの間で、メッセージを送受するために、
ホストコンピュータに接続されているネットワーク・イ
ンタフェースであり、そこでは、メッセージは、制御情
報と、通信チャネルを示すヘッダとを有している。その
ネットワーク・インタフェースは、送信側と受信側用の
コントローラを備えている。送信側では、コントローラ
は、ホストから送り元制御情報を受け取る。その送り元
制御情報を、メッセージ・コプロセッサに送るために、
コントローラは、送信側メッセージ・コプロセッサとイ
ンタフェースし、そのメッセージ・コプロセッサから、
小集合の命令の中から１つ以上の命令を受け取る。その
メッセージ・コプロセッサからの命令に応じて、そのコ
ントローラは、宛先制御情報を、出力メッセージに挿入
する。受信側では、コントローラは、受信メッセージか
ら宛先制御情報を抽出して、その宛先制御情報を、受信
側メッセージ・コプロセッサに送る。そのメッセージ・
コプロセッサは、小集合の命令から１つ以上の命令を返
す。そのコントローラは、受信した命令に応じて、受信
メッセージを処理する。これにより、コネクションベー
スの通信ネットワーク用のネットワーク・インタフェー
スにおいて、短い待ち時間でかつメッセージ処理のため
の支援機能の複雑さを減らしたものを提供できる等の効
果が得られる。

【図面の簡単な説明】

【図１】 この発明によるネットワーク・インタフェー
スとメッセージ・コプロセッサを有するコンピュータ・
システムのブロック図である。

【図２】 この発明の一実施の形態によるメッセージ処
理支援機能を有するネットワーク・インタフェースの受
信側におけるデータの流れを示す概略図である。

【図３】 この発明によるメッセージ処理支援機能を有
するネットワーク・インタフェースの受信側ブロック図
である。

【図４】 この発明による受信側でのメッセージ処理を
表すフローチャートである。

【図５】 図４のフローチャートの続きのフローチャー
トである。

【図６】 この発明の別の実施の形態によるメッセージ
処理支援機能を有するネットワーク・インタフェースの
送信側におけるデータの流れを示す概略図である。

【図７】 この発明によるネットワーク・インタフェー
スの送信側で使用される送り元制御情報用フォーマット
の概略図である。

【図８】 この発明によるネットワーク・インタフェー
スの送信側で使用される送り元制御情報用フォーマット
の概略図である。

【図９】 この発明によるネットワーク・インタフェー
スの送信側で使用される送り元制御情報用フォーマット
の概略図である。

【図１０】 この発明によるネットワーク・インタフェ
ースの送信側で使用される送り元制御情報用フォーマッ
トの概略図である。

【図１１】 この発明によるネットワーク・インタフェ
ースの送信側で使用される送り元制御情報用フォーマッ
トの概略図である。

【図１２】 この発明によるネットワーク・インタフェ
ースの送信側で使用される送り元制御情報用フォーマッ
トの概略図である。

【図１３】 この発明によるネットワーク・インタフェ
ースの送信側で使用される送り元制御情報用フォーマッ
トの概略図である。

【図１４】 この発明によるネットワーク・インタフェ
ースの送信側で使用される送り元制御情報用フォーマッ
トの概略図である。

【図１５】 この発明によるメッセージ処理支援機能を
有するネットワーク・インタフェースの送信側ブロック
図である。

【図１６】 この発明による送信側でのメッセージ処理
を表すフローチャートである。

【図１７】 この発明の別の実施の形態によるネットワ
ーク・インタフェースにおける返信付きリモート動作に
対する支援機能を示すブロック図である。

【図１８】 返信付きリモート動作の処理を表すフロー
チャートである。

【図１９】 ネットワーク・インタフェースを有する代
表的なコンピュータ・システムのブロック図である。

【図２０】 仮想アドレスをマッピングするための機構
を有しているネットワーク・インタフェースの受信側の
ブロック図である。

【図２１】 仮想アドレスをマッピングするための機構
を有しているネットワーク・インタフェースの送信側の
ブロック図である。

【図２２】 待ち時間が少なくオーバーヘッドも少ない
通信で使用されるホストコンピュータとネットワーク・
インタフェースを有するコンピュータ・システムのブロ
ック図である。

【図２３】 図２２のコンピュータ・システムで使用さ
れる宛先制御情報を有するメッセージの内容の略図であ
る。

【符号の説明】

２２ ホストコンピュータ、２４ ネットワーク、６０
コンピュータ・システム、６２，７８ 返信、６４
受信側メッセージ・コプロセッサ、６６ ネットワーク
・インタフェース、６８ 送信側メッセージ・コプロセ
ッサ、６９ ローカルバス、７０，７２ メッセージ、
７４ 送り元制御情報、７６ 宛先制御情報、７７ ヘ
ッダ、８０ 送信側、８２ 受信側、９４ ローカルメ
モリ。

フロントページの続き (71)出願人 597067574 201 ＢＲＯＡＤＷＡＹ， ＣＡＭＢＲＩ ＤＧＥ， ＭＡＳＳＡＣＨＵＳＥＴＴＳ 02139， Ｕ．Ｓ．Ａ. (72)発明者 ランディ・ビー・オズボーン アメリカ合衆国、マサチューセッツ州、ニ ュートン、ウェセックス・ロード 33

Claims (26)

【特許請求の範囲】
1. 【請求項１】 プロセッサとメモリを有するホストコン
   ピュータを、このホストコンピュータを複数のコンピュ
   ータに接続するネットワークに接続するためのネットワ
   ーク・インタフェースであって、上記ネットワーク・イ
   ンタフェースの受信側が、 上記ネットワーク・インタフェースにおいて、データと
   メッセージデータに関して実施される動作を示す宛先制
   御情報とを含むメッセージを受け取るための手段と、 上記ネットワーク・インタフェースにおいて、上記受信
   メッセージから宛先制御情報を抽出し、抽出された宛先
   制御情報を、上記ネットワーク・インタフェースに接続
   されたメッセージ・コプロセッサに通信するための手段
   と、 上記ネットワーク・インタフェースにおいて上記メッセ
   ージ・コプロセッサへの上記抽出された制御情報の通信
   後に動作可能な、上記メッセージ・コプロセッサによっ
   て発生された命令と引数を受け取るための手段と、 上記受信した命令と引数に応じて、上記受信メッセージ
   に関する小集合の動作の内の少なくとも１つを実行する
   ための手段と、 を備えたことを特徴とするネットワーク・インタフェー
   ス。
2. 【請求項２】 上記メッセージ・コプロセッサが、ネッ
   トワーク・インタフェースの外部にあり、さらに、上記
   ネットワーク・インタフェースが、受信メッセージから
   宛先制御情報を抽出し、上記メッセージ・コプロセッサ
   に上記抽出情報を通信し、上記メッセージ・コプロセッ
   サから上記命令と引数を受け取り、さらに引数を有する
   命令を実行するための上記各手段を実装しているメッセ
   ージ・コントローラを含む集積回路からなることを特徴
   とする請求項１に記載のネットワーク・インタフェー
   ス。
3. 【請求項３】 上記ネットワーク・インタフェース内の
   インタフェースが、上記外部メッセージ・コプロセッサ
   に接続されたメモリマッピングされたローカルバスであ
   ることを特徴とする請求項２に記載のネットワーク・イ
   ンタフェース。
4. 【請求項４】 上記宛先制御情報が、上記ネットワーク
   ・インタフェースを上記メッセージ・コプロセッサに接
   続しているメモリマッピングされたバス上の指定メモリ
   位置に書き込まれることを特徴とする請求項１に記載の
   ネットワーク・インタフェース。
5. 【請求項５】 上記メッセージ・コプロセッサから受け
   取った上記命令が、上記ネットワーク・インタフェース
   によって実行されるべき小集合の動作の中の１つの動作
   を表す第１の項目と、１つ以上のオペランドを表す第２
   の項目とを定義しているフォーマットを有することを特
   徴とする請求項１に記載のネットワーク・インタフェー
   ス。
6. 【請求項６】 上記命令が、上記ネットワーク・インタ
   フェースを上記メッセージ・コプロセッサに接続してい
   るメモリマッピングされたバス上の指定されたメモリ位
   置から読み込まれることを特徴とする請求項５に記載の
   ネットワーク・インタフェース。
7. 【請求項７】 上記命令が、上記ネットワーク・インタ
   フェースによって実行されるべき可能な動作毎に独立し
   た１ビットを含むフォーマットを有していることを特徴
   とする請求項５に記載のネットワーク・インタフェー
   ス。
8. 【請求項８】 上記命令を受け取ってそれを実行する手
   段が、上記命令に応じて動作する、上記受信メッセージ
   からさらに多くのデータを読み取ってそれを上記メッセ
   ージ・コプロセッサに送るための手段と、上記メッセー
   ジ・コプロセッサからさらに別の命令を繰り返し受け取
   りさらに実行するための手段を備えていることを特徴と
   する請求項１に記載のネットワーク・インタフェース。
9. 【請求項９】 上記命令を受け取ってそれを実行する手
   段が、返信動作命令を作成して、上記ネットワーク・イ
   ンタフェースの送信側によってアクセス可能な返信待ち
   行列に返信命令を保存する手段を備えていることを特徴
   とする請求項１に記載のネットワーク・インタフェー
   ス。
10. 【請求項１０】 上記命令を受け取ってこれを実行する
    手段が、上記宛先制御情報を読み終える前に、上記受信
    メッセージを最初の状態に復元するための手段を備えて
    いることを特徴とする請求項１に記載のネットワーク・
    インタフェース。
11. 【請求項１１】 上記命令がネットワーク・インタフェ
    ースによって書き込まれるべきメッセージからのデータ
    の指定長を示し、上記命令を受け取ってそれを実行する
    手段が、 上記指定長のデータが、上記メッセージ・コプロセッサ
    によって指定されたアドレスに書き込まれるべきである
    か否かを判断する手段と、 指定されたアドレスから始まる指定量のデータを保存す
    るための手段と、 を備えていることを特徴とする請求項１に記載のネット
    ワーク・インタフェース。
12. 【請求項１２】 上記命令がネットワーク・インタフェ
    ースによって書き込まれるべきメッセージからのデータ
    の指定長を示し、上記命令を受け取ってそれを実行する
    手段が、 フリーバッファを選択する手段と、 指定量のデータを上記選択されたフリーバッファに保存
    する手段と、 を備えていることを特徴とする請求項１に記載のネット
    ワーク・インタフェース。
13. 【請求項１３】 上記保存手段がさらに、ホスト・プロ
    セッサに対する割込み信号を生成する手段をさらに備え
    たことを特徴とする請求項１１に記載のネットワーク・
    インタフェース。
14. 【請求項１４】 上記受信メッセージが分割メッセージ
    であり、上記命令を受け取ってこれを実行する手段が、
    任意の前の制御区分の処理後に、上記分割メッセージに
    おける任意の次の制御区分を自動的に処理する手段を備
    えていることを特徴とする請求項１に記載のネットワー
    ク・インタフェース。
15. 【請求項１５】 プロセッサとメモリを有するホストコ
    ンピュータを、このホストコンピュータをメッセージを
    通信するために複数のコンピュータに接続するネットワ
    ークに接続するためのネットワーク・インタフェースで
    あって、上記ネットワーク・インタフェースの送信側
    が、 上記ネットワーク・インタフェースにおいて、宛先制御
    情報を出力メッセージから獲得する方法を示す送り元制
    御情報をホストコンピュータから受け取り、上記ネット
    ワーク・インタフェースに接続されたメッセージ・コプ
    ロセッサに通信する手段と、 上記ネットワーク・インタフェースにおいて、上記メッ
    セージ・コプロセッサへの送り元制御情報の通信後に動
    作可能な、上記送り元制御情報に応じて、上記メッセー
    ジ・コプロセッサによって作成された命令と引数を受け
    取る手段と、 上記出力メッセージの受信によって上記出力メッセージ
    に関して実施される動作を表す上記宛先制御情報を得る
    ために、上記受け取った命令と引数に応じて小集合の命
    令の内の少なくとも１つの命令を実行する手段と、 上記ネットワーク・インタフェースにおいて、上記ネッ
    トワーク経由で上記複数のコンピュータの内の少なくと
    も１台に送信されるべき上記出力メッセージに上記宛先
    制御情報を挿入する手段と、 を備えたことを特徴とするネットワーク・インタフェー
    ス。
16. 【請求項１６】 上記メッセージ・コプロセッサが、上
    記ネットワーク・インタフェースに対して外部にあり、
    上記ネットワーク・インタフェースが、上記受け取りお
    よび通信のための上記各手段を実装し、さらに上記外部
    メッセージ・コプロセッサへのインタフェースを有する
    メッセージ・コントローラから成る集積回路であること
    を特徴とする請求項１５に記載のネットワーク・インタ
    フェース。
17. 【請求項１７】 上記ネットワーク・インタフェース内
    のインタフェースが、上記外部メッセージ・コプロセッ
    サに接続されたメモリマッピングされたローカルバスで
    あることを特徴とする請求項１６に記載のネットワーク
    ・インタフェース。
18. 【請求項１８】 上記送り元制御情報が、上記ネットワ
    ーク・インタフェースを上記メッセージ・コプロセッサ
    に接続しているメモリマッピングされたバス上の指定さ
    れたメモリ位置に書き込まれることを特徴とする請求項
    １５に記載のネットワーク・インタフェース。
19. 【請求項１９】 上記メッセージ・コプロセッサから受
    け取った上記命令が、上記ネットワーク・インタフェー
    スによって実行されるべき小集合の動作の内の１つの動
    作を表す第１の項目と、１つ以上のオペランドを表す第
    ２の項目を含むフォーマットを有することを特徴とする
    請求項１５に記載のネットワーク・インタフェース。
20. 【請求項２０】 上記命令が、上記ネットワーク・イン
    タフェースを上記メッセージ・コプロセッサに接続して
    いるメモリマッピングされたバス上の指定されたメモリ
    位置から読み込まれることを特徴とする請求項１９に記
    載のネットワーク・インタフェース。
21. 【請求項２１】 上記命令が、上記ネットワーク・イン
    タフェースによって実行されるべき可能な動作毎に独立
    した１ビットを含むフォーマットを有していることを特
    徴とする請求項１９に記載のネットワーク・インタフェ
    ース。
22. 【請求項２２】 上記命令を受け取ってそれを実行する
    手段が、上記命令に応じて動作する、上記ホストコンピ
    ュータからさらに多くのデータを読み取ってそれを上記
    メッセージ・コプロセッサに送るための手段と、上記メ
    ッセージ・コプロセッサからさらに別の命令を繰り返し
    受け取りさらに実行するための手段を備えたことを特徴
    とする請求項１５に記載のネットワーク・インタフェー
    ス。
23. 【請求項２３】 上記命令が上記ネットワーク・インタ
    フェースによって読み取られるべきデータの指定量を示
    し、上記命令を受け取ってこれを実行するための手段
    が、 上記指定量のデータが上記受け取った命令によって指定
    されるアドレスから読み取られるべきか否かを判断する
    手段と、 上記指定されたバッファにある上記指定量のデータを上
    記出力メッセージに読み込む手段と、 を備えたことを特徴とする請求項１５に記載のネットワ
    ーク・インタフェース。
24. 【請求項２４】 上記命令が上記ネットワーク・インタ
    フェースによって読み出されるべきデータの指定量を示
    し、上記命令を受け取ってこれを実行するための手段
    が、 送信のために上記ホストによって上記ネットワーク・イ
    ンタフェースに提供された上記バッファからのデータを
    選択する手段と、 上記指定量のデータを上記選択されたバッファから読み
    取り、上記読み取ったデータを出力メッセージに挿入す
    る手段と、 を備えたことを特徴とする請求項１５に記載のネットワ
    ーク・インタフェース。
25. 【請求項２５】 上記出力メッセージが分割メッセージ
    であり、上記命令を受け取ってこれを実行する手段が、
    任意の前の制御区分の処理後に、上記分割メッセージに
    おける任意の次の制御区分を自動的に処理する手段を備
    えていることを特徴とする請求項１５に記載のネットワ
    ーク・インタフェース。
26. 【請求項２６】 ホストコンピュータを複数のコンピュ
    ータに接続するネットワークとの間で、実行されるべき
    動作を表す宛先制御情報と通信チャネルを表すヘッダと
    を含むメッセージを送受するために、プロセッサとメモ
    リを有する上記ホストコンピュータに接続されたネット
    ワーク・インタフェースであって、上記ネットワーク・
    インタフェースが、 コントローラと、上記ネットワーク・インタフェースに
    よって送受されるメッセージにおける宛先制御情報の位
    置に関する情報を含む関連メモリと、 制御情報を上記コントローラからメッセージ・コプロセ
    ッサに送信するための手段、上記メッセージ・コプロセ
    ッサから小集合の命令の中の１つの命令を受け取るため
    の手段を備えた上記メッセージ・コプロセッサに接続す
    るためのインタフェースであって、上記コントローラ
    が、上記メッセージ・コプロセッサからの命令に応じ
    て、出力メッセージの宛先で実行されるべき動作を表す
    宛先制御情報を得るための手段、上記宛先制御情報を上
    記出力メッセージに挿入するための手段を有しているも
    のと、 上記コントローラが、上記メッセージ・コプロセッサか
    ら受け取った命令に応じて、受け取ったメッセージを取
    り扱うための手段を有している、 ことを特徴とするネットワーク・インタフェース。