JPH07221780A - データパケットの受信の速度を上げるためのシステム - Google Patents

データパケットの受信の速度を上げるためのシステム

Info

Publication number
JPH07221780A
JPH07221780A JP6271140A JP27114094A JPH07221780A JP H07221780 A JPH07221780 A JP H07221780A JP 6271140 A JP6271140 A JP 6271140A JP 27114094 A JP27114094 A JP 27114094A JP H07221780 A JPH07221780 A JP H07221780A
Authority
JP
Japan
Prior art keywords
buffer
data
controller
descriptor
packet
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.)
Withdrawn
Application number
JP6271140A
Other languages
English (en)
Inventor
Matthew J Fischer
マシュー・ジェームズ・フィッシャー
Glen Gibson
グレン・ギブソン
Thomas J Runaldue
トーマス・ジェファーソン・ルナルデュー
Jeffrey Dwork
ジェフェリー・ドゥワーク
Current Assignee (The listed assignees may be inaccurate. Google has not performed a legal analysis and makes no representation or warranty as to the accuracy of the list.)
Advanced Micro Devices Inc
Original Assignee
Advanced Micro Devices Inc
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 Advanced Micro Devices Inc filed Critical Advanced Micro Devices Inc
Publication of JPH07221780A publication Critical patent/JPH07221780A/ja
Withdrawn legal-status Critical Current

Links

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/38—Information transfer, e.g. on bus
    • 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
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F13/00—Interconnection of, or transfer of information or other signals between, memories, input/output devices or central processing units
    • G06F13/10—Program control for peripheral devices
    • G06F13/12—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor
    • G06F13/124—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine
    • G06F13/128—Program control for peripheral devices using hardware independent of the central processor, e.g. channel or peripheral processor where hardware is a sequential transfer control unit, e.g. microprocessor, peripheral processor or state-machine for dedicated transfers to a network
    • 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/9021—Plurality of buffers per packet
    • 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/9057—Arrangements for supporting packet reassembly or resequencing
    • 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/9063—Intermediate storage in different physical parts of a node or terminal
    • H04L49/9068—Intermediate storage in different physical parts of a node or terminal in the network interface card
    • H04L49/9073—Early interruption upon arrival of a fraction of a packet
    • 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/9063—Intermediate storage in different physical parts of a node or terminal
    • H04L49/9078—Intermediate storage in different physical parts of a node or terminal using an external memory or storage device

Landscapes

  • Engineering & Computer Science (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Theoretical Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • General Engineering & Computer Science (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Microelectronics & Electronic Packaging (AREA)
  • Computer And Data Communications (AREA)
  • Small-Scale Networks (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Abstract

(57)【要約】 【目的】 ネットワークからのデータパケットの受信の
速度を上げる。 【構成】 データパケットを受信する際に、ネットワー
ク環境においてバスの待ち時間および中央処理装置（Ｃ
ＰＵ）利用を最適化するようイーサネットコントローラ
（２２）が動作するのを確実にするためのシステムを提
供する。複数個のバッファメモリ（１、２、３）および
ドライバを有効に用いることによって、ならびにコント
ローラに関連してバスを利用することによって、ネット
ワークの待ち時間の間イーサネットコントローラからの
データパケットの受信および送信に備える。これを行な
うことによって、ネットワークの全体的なパフォーマン
スが向上する。

Description

【発明の詳細な説明】
【０００１】
【発明の分野】本発明はイーサネットコントローラの動
作に関し、より特定的には、ネットワーク環境内におい
てこのようなコントローラによる効率のよいデータ転送
に関する。
【０００２】
【発明の背景】ネットワークの種類によっては、たとえ
ばイーサネット（ＥＴＨＥＲＮＥＴ）（登録商標）で
は、ノードが一旦データパケットを送信または受信し始
めると、パケット全体が処理されるまで、データはネッ
トワークによって決定される速度で割込なしで続けられ
なければならない。ノードは、たとえば、ネットワーク
に接続されるコンピュータである場合がある。典型的に
は、コンピュータは、ネットワークおよび内部システム
バスに結合されているネットワークインタフェースを有
する。コンピュータの種々のコンポーネント、サブシス
テム、および周辺装置も同様にシステムバスに接続され
ている。
【０００３】コンポーネントは典型的には記憶装置およ
びある種類のプロセッサを含む。大部分のコンピュータ
システムは種々のコンポーネント間のすべてのデータを
システムバスを用いて動かす。システムバスへのアクセ
スは、種々のサービスが関連した優先権を有する割込シ
ステムを用いることによってしばしば厳しく制御され、
装置は部分的にはその優先順位に基づいてシステムバス
を用いることができる。
【０００４】ネットワークから受信したデータパケット
について、コンピュータはシステムバスを介してデータ
を記憶装置に転送し、さらなる処理を待つ。他のコンピ
ュータコンポーネントもシステムバスを用いるので、記
憶装置にすぐアクセスできるとは限らない。システムバ
スを介する記憶装置へのアクセスは、アクセス時間が前
もって予測できないので可変な待ち時間または遅延を有
するといわれている。
【０００５】この可変な待ち時間の問題に対するよく知
られている解決策は、ネットワークとシステムバス間の
バッファメモリをコンピュータに設けることである。コ
ンピュータによってシステムバスへのネットワークイン
タフェースのアクセスが否定されると、ネットワークイ
ンタフェースはデータをバッファメモリ内にストアす
る。コンピュータがシステムバスを介する記憶装置への
アクセスを与えると、コンピュータはバッファメモリを
空にし、ネットワークに「キャッチアップ」する。シス
テムバスのデータ速度はネットワークの実効データ伝送
速度よりはるかに速いので、コンピュータはキャッチア
ップすることができる。コンピュータがあまりにも長い
時間システムバスのバッファメモリへのアクセスを否定
しかつバッファメモリが容量一杯になると、オーバーフ
ロー状態となる。データの受信を中断する方法はないの
で、ネットワークからのさらなるデータは失われる。ネ
ットワークプロトコルはオーバーフロー状態を検出し、
ノードにデータパケット全体を再送信させることによっ
て、この状態を処理している。したがって、ネットワー
ク効率を向上させるためには、コンピュータシステムの
オーバーフロー状態の回数を最小限にすることが望まし
い。
【０００６】記憶装置からデータをネットワークに伝送
する際にも同様の問題が起こる。一旦ネットワークのア
クセスが与えられると、コンピュータは所定の一定速度
でデータを送信しなければならないが、記憶装置はシス
テムバスの協働を必要とする。システムバスの可変な待
ち時間の問題は確実な伝送を損う。伝送経路にさらなる
バッファメモリを設けることによってネットワークイン
タフェースは、コンピュータが記憶装置へのアクセスを
否定した場合でもネットワークに限定された量のデータ
を与えることを可能にする。速度が固定されたネットワ
ークへの伝送に対して、コンピュータが記憶装置へのバ
ッファメモリのアクセスをあまりにも長い時間否定しか
つネットワークインタフェースがバッファメモリを完全
に空にした場合に、バッファメモリがアンダーフロー状
態となる可能性がある。アンダーフローを検出すると、
伝送は止まり、ネットワークは不完全なデータパケット
をパージする。ネットワークはコンピュータにデータパ
ケットを再伝送することを要求する。
【０００７】通信システムのバッファメモリを管理する
ための従来的設計では、送信および受信動作は互いに全
く独立したものとして扱われている。受信動作が進行中
なら、バッファメモリマネージャーは、少なくともノー
ドが完全なデータパケットを受取りかつそれを記憶装置
にストアするまで、受信動作の完了に対して優先権を与
える。この後でしか可能な送信動作は考慮されないが、
他の受信動作が始まると、コンピュータは送信動作をア
ボートする。混んでいるネットワークでは、受信動作は
バッファメモリマネージャーの時間を独占するので、コ
ンピュータからの送信を不定時間の間遅延させる可能性
がある。この問題は伝送の受信ロックアウトと呼ばれる
ことがある。
【０００８】別の解決策では、記憶装置に相対して受信
および送信の動作をインタリーブする。この解決策によ
って、受信動作に起因する記憶装置へのすべてのデータ
転送が、完了していなくても、コンピュータが送信動作
を開始することを可能にする。この解決策は、ネットワ
ーク通信チャネルをより積極的に使用するという利点を
有するが、同じ時間帯にシステムバスはより多くのデー
タを運ばなければならないので、オーバーフローおよび
アンダーフローしやすいという不利点を有する。
【０００９】この分野において依然として求められてい
るのは、バッファメモリのオーバーフローおよびアンダ
ーフロー状態を最小限にし、またはなくしながら、最小
限のデータ損失で送信および受信動作を積極的に共用す
る、より効率のよいバッファメモリ管理システムであ
る。先行技術においては多くの理由により小さいバッフ
ァが望ましいことは認識されているが、自明な解決策と
してはオーバーフローおよびアンダーフロー状態が望ま
しいレベルに下がるまでバッファメモリの大きさを増や
すことである。しかし、バッファメモリの大きさを増や
すことはハードウェアのコストを増加させ、送信および
受信経路の両方においてさらなる時間的遅延を与える。
【００１０】他の解決策としては、バス速度またはデー
タ経路幅を増やすことによって単純にシステムバスのデ
ータ速度を向上させ、システムバスアクセスに対する相
反する要求が、用いられるバッファ管理技術を著しく改
善する必要なく満たされるようにすることである。この
解決策もハードウェアのコストを上げるので完全に満足
のいくものではない。
【００１１】パケット間の待ち時間（すなわち、あるパ
ケットの受信から次のパケットの送信までの時間）が長
ければ長いほど、ネットワークパフォーマンスが低くな
ることは知られている。この待ち時間は、あるパケット
を受信してから次の出力パケットを送信するまでの間に
行なわなければならないタスクの数による。この動作に
はかなりの時間が必要である。したがって、ネットワー
クの全体的パフォーマンスは、受信パケットが完全に受
取られるまでタスクが開始されない場合、低下する。
【００１２】これらの問題のいくつかは、１９９３年５
月２７日に出願され、「フルドゥープレックスバッファ
管理および装置」と題される米国特許出願連続番号第０
８／０６８，６９６号で扱われており、複数個のＦＩＦ
Ｏの１つに優先権が与えられている。しかし、これはネ
ットワークのコントローラに関連するＣＰＵ利用および
バス待ち時間の問題に常に適切に対処できるわけではな
い。
【００１３】以上により、ローカルエリアネットワーク
中の同期コンポーネントおよび可変待ち時間を有する記
憶装置間をインタフェースするのに使用し、かつパケッ
ト間待ち時間を減らすための、より効率のよいバッファ
メモリ管理システムが必要である。本発明はこの目的に
向けられている。
【００１４】
【発明の概要】ネットワークからのデータパケットの受
信速度を上げるためのシステムが開示されている。シス
テムは複数個のバッファメモリ手段と、ネットワークか
ら受信したデータを少なくとも３つのバッファメモリ手
段に書込むためのコントローラ手段と、コントローラ手
段の動作を制御するためのドライバ手段とを含む。ドラ
イバ手段はアプリケーションメモリ手段を含む。コント
ローラ手段は、第１のバッファメモリ手段がネットワー
クからのデータで満杯になると割込を発生させる。コン
トローラ手段は第１のバッファメモリ手段からのデータ
を、ドライバ手段に応答してアプリケーションメモリ領
域の第１の部分に書込む。次にコントローラ手段は、第
２のバッファメモリ手段がデータで満杯になることに応
答して、第２のバッファメモリ手段からデータをアプリ
ケーションメモリ領域の第２の部分に書込む。次に、コ
ントローラ手段はパケットからの残りのデータを最後の
バッファメモリ手段に書込む。最後に、コントローラ手
段は残りのデータをアプリケーションメモリ領域の最後
の部分に書込むことができる。
【００１５】本発明によって全体的なネットワークパフ
ォーマンスを向上させることができる。これは、完全な
データパケットが受信される前に、特定情報をメモリに
書込むことを可能にすることによって達成される。
【００１６】
【詳細な説明】本発明はイーサネットコントローラの改
良に関する。以下の説明は、特定の応用およびその要件
という環境内で与えられる本発明を、当業者が作成しか
つ使用することができるように与えられる。好ましい実
施例に対して種々の変形ができることは当業者にとって
明らかだろう。さらに、義される包括的原理は他の実施
例に適用することができる。したがって、本発明は示さ
れる実施例に限定されるものではなく、ここに開示され
る原理および新規な特徴に従う最も広い範囲が与えられ
るべきである。
【００１７】図１は本発明の好ましい実施例を含むノー
ド１０のブロック図である。ノード１０はシステムバス
１４に接続されるシステムインタフェースアダプタ１２
を含む。システムバス１４はシステムインタフェースア
ダプタ１２を、記憶装置１６、中央処理装置（ＣＰＵ）
２０、およびイーサネットコントローラ２２に相互接続
する。システムインタフェースアダプタ１２は、他のシ
ステム周辺装置を拡張バス１３に接続することによって
これらの周辺装置をシステムに追加することを可能にす
る。
【００１８】一般にイーサネットコントローラ２２のド
ライバでは、パケット全体がコントローラ２２によって
受信されてから、ＣＰＵが受信パケットデータをコント
ローラのバッファ領域からアプリケーションバッファ領
域にコピーすることを要求する。ピンポンウィンドウ型
を用いるアプリケーションでは、現在のパケットがアプ
リケーションスタック全体によって完全に処理されるま
で、ネットワークのトラフィックは停止される。
【００１９】図２を参照して、典型的な先行技術のイー
サネットコントローラの動作をソフトウェアの動作と関
連付ける図が示される。クライアントのイーサネットコ
ントローラに受信パケットの最後のバイトが到着してか
らクライアントの次の出力パケットの最初のバイトが送
信されるまでの時間は、いくつかの動作に分けられる。
【００２０】Ｓ１：クライアントのＣＰＵの割込プロシ
ージャがソフトウェア制御を現在のタスクからドライバ
に渡すのにかかる時間と、 Ｓ２：さらにクラアントドライバがヘッダデータをアプ
リケーションに渡し、アプリケーションバッファをリク
エストするのにかかる時間に加えて、アプリケーション
がバッファポインタを生成し、そのバッファポインタを
ドライバに返すのにかかる時間、 Ｓ３、Ｓ４：さらにクライアントドライバがパケットデ
ータ全部をコントローラのバッファ領域からアプリケー
ションバッファ領域に転送し、完全なパケットを処理す
るために再度アプリケーションを呼出すのにかかる時
間、 Ｓ５：さらにアプリケーションがそのパケットを処理
し、次の出力パケットを生成するのにかかる時間 Ｓ６：さらにクライアントドライバがコントローラの記
述子をセットアップし、ＴＤＭＤビットをＣＳＲＯに書
込むのにかかる時間。
【００２１】これらの時間の和はワイヤで実際にパケッ
トを伝送するのにかかる時間とほぼ同じであることも多
く、それによってネットワーク利用率は５０％未満とな
ってしまう。
【００２２】注意するべきことは、バッファ領域へのイ
ーサネットコントローラのデータ転送はバーストされる
ので、システムバスは時間のおよそ４％の間イーサネッ
トコントローラによって要求される。これによって中央
処理装置（ＣＰＵ）に対してシステムバスの帯域幅の９
６％が残り、可能ならネットワークの受信動作の完了前
にいくつかのパケット間動作を行なうことができる。そ
こで次の問題が出てくる。すなわち、あるパケットの受
信と次のパケットの送信との間に行なわなければならな
いタスクのうちいくつを、ネットワークでパケットの受
信が実際に終了する前に行なうことができるのか、およ
びこのネットワークの受信時間の間にこれらのタスクを
行なう様にどのようにしてＣＰＵに指示できるかであ
る。
【００２３】この答えはドライバおよびアプリケーショ
ンコードにおいて起こっている内容に直接依存するが、
受信データが到着するのと同時に行なうことができるス
テップは、上記で示したシーケンスの最初の３または４
ステップまでをも含む。パケット全部が到着する前にこ
れらを行なうことによって、ネットワークのパケットス
ループットはかなり増加される。
【００２４】ネットワークの受信動作が終るまでに最初
の３つのステップを行なえば、パフォーマンスにおいて
かなりの向上を見ることができる。イーサネットコント
ローラがパケットデータをアプリケーションバッファ領
域に直接置くことができるのならパフォーマンスをさら
に著しく増加させることができる。これを実現するに
は、パケットが完全に到着するまでにアプリケーション
バッファポインタを決定する必要があり、受信パケット
に対する次の記述子のバッファポインタは、イーサネッ
トコントローラがアプリケーションバッファに直接書込
むことを指示するために変更しなければならない。この
動作についての詳細は本明細書の後で説明される。
【００２５】既存システムに代替的な変形を行なえば、
小さいがそれでもなお著しいパフォーマンスの向上を得
ることができる。この代替システムでは、ＣＰＵはまだ
コピー動作を行なわなければならないが、パケットが完
全にコントローラによって受信されるまでにコピー動作
のかなりの部分が行なわれることを可能にする。ＣＰＵ
は、パケットデータがネットワークから完全に到着する
までに受信データをコントローラのバッファ領域からア
プリケーションバッファ領域にコピーする動作を行なう
ことができる。これによって第４ステップのコピー動作
が、ネットワーク受信アクティビティの終了後に順次的
に行なわれるのではなく、ネットワークデータの到着と
平行に行なわれることを可能にする。この機能をパケッ
ト受信開始割込（ＳＰＲＩＮＴ）と呼ぶ。
【００２６】図３を参照すると、本発明に係るイーサネ
ットコントローラに関連して、ソフトウェアドライバの
動作のタイムラインが示される。
【００２７】Ｎ０：ワイヤにパケットプリアンブルが現
われ、その後にＳＦＤおよび行先アドレスが続く。
【００２８】Ｎ１：パケットデータの６４番目のバイト
がワイヤから到着する。これによってイーサネットコン
トローラは第１のバッファに対するパケットデータのＤ
ＭＡ動作を開始する。
【００２９】Ｃ０：メッセージの６４番目のバイトが到
着すると、イーサネットコントローラは次の受信記述子
に対して先読み動作を行なう。この記述子はイーサネッ
トコントローラによって所有されなければならない。
【００３０】Ｃ１：イーサネットコントローラはパケッ
トデータがワイヤに到着するとそれを第１バッファに転
送するようバスに対して断続的にリクエストする。
【００３１】Ｓ０：非クライアントドライバタスクがシ
ステムで走っている。 Ｃ２：イーサネットコントローラが第１のバッファを完
全に満たすと、状態を第１の記述子に書込む。
【００３２】Ｃ３：パケットに対する第１の記述子が書
込まれると、所有権をイーサネットコントローラからＣ
ＰＵに移し、イーサネットコントローラはパケット受信
開始割込（すなわちＳＴＰ ＩＮＴＥＲＲＵＰＴ）を発
生させる。（この割込はＣＳＲ０においては割込ＲＥＣ
ＥＩＶＥ ＩＮＴＥＲＲＵＰＴとして現われる）。ソフ
トウェアは記述子のＳＴＰを調べて、ＲＩＮＴがパケッ
ト開始割込（ＳＴＰ）または受信パケット終了（ＥＮ
Ｐ．）によって引き起こされることを決定する。
【００３３】Ｓ１：ＳＴＰ ＩＮＴＥＲＲＵＰＴによっ
てＣＰＵはタスクをスイッチして、イーサネットコント
ローラのドライバが走ることを可能にする。
【００３４】Ｃ４：ＣＰＵの割込発生によるタスクスイ
ッチングの際、イーサネットコントローラは第３の記述
子に対して先読み動作を行なっている。この時点におい
て、第３記述子の所有権はＣＰＵにある。第３のバッフ
ァはイーサネットコントローラによって所有されていな
いが、既存のイーサネットコントローラはコントローラ
が既に所有しているバッファ領域（すなわちバッファ番
号２）にデータＤＭＡを行ない続ける。コントローラは
バッファ番号２のバッファ領域がこのパケットに対して
十分であるかどうかは知らないが、メッセージ全体をそ
の領域内に移すことを試みること以外に知る方法はな
い。メッセージがフィットしない場合にのみコントロー
ラはバッファエラー状態の信号を発生する。
【００３５】Ｓ２：ドライバの割込サービスルーチンの
最初のタスクは、イーサネットコントローラの第１のバ
ッファからヘッダ情報を取出し、それをアプリケーショ
ンに渡すことである。
【００３６】Ｓ３：アプリケーションはアプリケーショ
ンバッファポインタをドライバに返す。ドライバはアプ
リケーションデータバッファポインタに対してオフセッ
トを加える。なぜならイーサネットコントローラはメッ
セージの最初の部分を第１および第２のバッファに入れ
るからである。（変更されたアプリケーションデータバ
ッファポインタは、第３のバッファに到達した場合のみ
イーサネットコントローラによって直接使用される。）
ドライバは変更されたデータバッファポインタをそのグ
ループ（バッファ＃３）の最後の記述子に入れ、この記
述子の所有権をイーサネットコントローラに与える。
【００３７】Ｃ５：Ｓ２、Ｓ３およびＳ４のドライバ動
作とインタリーブされて、イーサネットコントローラは
パケットデータをバッファ番号２に書込む。
【００３８】Ｓ４：次にドライバはイーサネットコント
ローラの第１のバッファの内容をアプリケーション領域
の最初にコピーし始める。このコピーはアプリケーショ
ンによって渡されたそのままの（変更されていない）バ
ッファポインタである。
【００３９】Ｓ５：第１のバッファからすべてのデータ
をアプリケーションデータバッファの最初にコピーし終
えると、ドライバは第２の記述子の所有権ビットのポー
リングを始める。ドライバはイーサネットコントローラ
が第２のバッファを満たし終えるのを待っている。
【００４０】Ｃ６：この時点では、前に第３の記述子を
所有しておらず、かつ現行メッセージが終了していない
（ｆｉｆｏにまだデータがある）ことを知っている上
で、イーサネットコントローラは最後の（第３の）記述
子に対して「最後のディッチ先読み」を行なう。このと
き、所有権は真である（すなわちコントローラにあ
る）。なぜならドライバはアプリケーションポインタを
この記述子に書込み、Ｓ３において所有権を変えてその
記述子をイーサネットコントローラに戻しているからで
ある。もしステップＳ１，Ｓ２およびＳ３がこの時点で
まだ完了していなければ、ＢＵＦＦエラーとなる。
【００４１】Ｃ７：第２のバッファを満杯にし、次の記
述子へのラストチャンスの先読みを行なうと、イーサネ
ットコントローラは状態を書込んで記述番号２の所有権
ビットを変える。
【００４２】Ｓ６：記述子番号２の所有権がイーサネッ
トコントローラによって変えられた後、２番目の記述子
の次のドライバのポーリングは所有権がＣＰＵに与えら
れていることを示す。ここでドライバはデータをバッフ
ァ番号２からアプリケーションバッファ領域の「中間
部」にコピーする。この動作はＣ７およびＣ８の動作と
インタリーブされる。
【００４３】Ｃ８：イーサネットコントローラは、ポイ
ンタがアプリケーション領域を指している最後のバッフ
ァにデータＤＭＡを行なう。最後のバッファに入るデー
タは、アプリケーションバッファ領域に直接入れられる
ので、既存ドライバが必要とする悪名高い「ダブルコピ
ー」を必要としない。
【００４４】Ｎ２：ワイヤのメッセージが終了する。 Ｓ７：ドライバがバッファ番号２データのアプリケーシ
ョンバッファ領域へのコピーを完了すると、記述子番号
３のポーリングが始まる。
【００４５】Ｃ９：イーサネットコントローラがすべて
のデータＤＭＡ動作を完了すると、状態を書込み、記述
子番号３の所有権を変更する。
【００４６】Ｓ８：ドライバは記述子番号３の所有権が
変わったことを見て、アプリケーションを呼出してパケ
ットが到着したことをアプリケーションに知らせる。
【００４７】Ｓ９：アプリケーションは受信パケットを
処理し、次のＴＸパケットを生成し、それをＴＸバッフ
ァに入れる。
【００４８】Ｓ１０：ドライバはイーサネットコントロ
ーラのＴＸ記述子をセットアップする。
【００４９】セットアップ：図５で示される好ましい実
施例において、ドライバは３の記述子のグループをセッ
トアップする。３つの記述子の各セットのＯＷＮおよび
パケット開始（ＳＴＰ）ビットは、１１，１０，００と
なる。
【００５０】オプションビットであるＳＰＲＩＮＴ可能
化ビット（ＳＰＲＩＮＴＥＮ）がレジスタに存在する。
この実施例では、これは５のビット位置にあるが、その
位置は任意のものである。ソフトウェアがこのビットを
セットする。セットされると、ＳＴＰがイーサネットコ
ントローラによって受信記述子に書かれた場合にＳＰＲ
ＩＮＴＥＮビットはイーサネットコントローラがＩＮＴ
ＥＲＲＵＰＴを発生するよう指示する。
【００５１】イーサネットコントローラは、メッセージ
が到着する前にある時点において現在の受信記述子をポ
ーリングする。現在の記述子はＯＷＮ＝１およびＳＴＰ
＝１となるべきである。イーサネットコントローラがこ
れが真であると判定すると、記述子情報をストアしてメ
ッセージが到着したときに用いる。記述子がＯＷＮ＝０
およびＳＴＰ＝１であることをイーサネットコントロー
ラが識別すると、ＯＷＮ＝１およびＳＴＰ＝１となるま
でこの位置のポーリングを続ける。記述子がＯＷＮ＝０
およびＳＴＰ＝０であることをイーサネットコントロー
ラが識別すると、この記述子を飛ばしてリングにおける
次の記述子のＯＷＮおよびＳＴＰのビットをチェックす
る動作に移る。
【００５２】受信パケットは３記述子グループ化におい
て３つのバッファ全部を満たすのに十分大きくないかも
しれないことに注意しなければならない。ソフトウェア
はこの可能性について認識する必要があり、常にＥＮＰ
およびＥＲＲ（エラービットのＯＲ化である）を調べな
ければならない。ＥＮＰ＝１またはＥＲＲ＝１のどちら
かであれば、現在の記述子は受信パケットの終りを含む
ことを示す。
【００５３】［パケット受信開始割込（ＳＰＲＩＮＴ）
ソフトウェアの必要要件：］パケット受信開始割込の１
割込システムのソフトウェアフローチャートが図４にお
いて示される。
【００５４】ソフトウェアは、記述子が３のグループに
形成される受信リングをセットアップしなければならな
い。各グループの第１の記述子はＯＷＮ＝１およびＳＴ
Ｐ＝１となっていなければならない。各グループの第２
の記述子はＯＷＮ＝０およびＳＴＰ＝０となっていなけ
ればならない。各グループの３番目の記述子はＯＷＮ＝
０およびＳＴＰ＝０となっていなければならない。第１
のバッファのサイズ（第１記述子において示される）は
少なくとも予期される最も大きいヘッダサイズと等しく
なければならない。しかし、ＣＰＵを最大限効率よく利
用するには、第１のバッファサイズはヘッダサイズより
大きくなければならない。この大きさは、予期されるメ
ッセージバイトの数から、割込待ち時間に必要な時間
と、アプリケーション呼出待ち時間と、ドライバが第３
の記述子を書込むのに必要な時間と、ドライバがバッフ
ァ＃１からデータをアプリケーションバッファ領域にコ
ピーするのに必要な時間と、ドライバがバッファ＃２か
らデータをアプリケーションバッファ領域にコピーする
のに必要な時間とをマイナスしたものに等しくなるべき
である。
【００５５】ドライバが行なうコピーに必要な時間は第
２バッファおよび第３バッファのサイズに依存し、第２
バッファおよび第３バッファのサイズはデータコピー動
作に必要な時間に従って設定されなければならないこと
に注意すべきである。これは、最適動作のために正しい
バッファサイズを決定するのに、反復自己調整機構をソ
フトウェアに設けなければならないことを意味する。バ
ッファサイズに対して固定値を用いることはでき、この
ような場合でも、ＳＰＲＩＮＴシステムはパフォーマン
スにおいて著しい増加を示すが、そのパフォーマンスの
増加は最大限のものではない。図５はサイズが９である
受信リングのセットアップを示す。
【００５６】［記述子を解析するためのＳＰＲＩＮＴ規
則］ＳＰＲＩＮＴ方法を用いる場合、ソフトウェアは以
下のような変形された形の記述子解析を使用しなければ
ならない。
【００５７】ソフトウェアはＯＷＮおよびＳＴＰを調べ
て、ＲＣＶパケットがどこで始まるかを決定する。ＲＣ
ＶパケットはＯＷＮ＝０およびＳＴＰ＝１を有するバッ
ファでしか始まらない。
【００５８】ソフトウェアはＥＮＰ＝１またはＥＲＲ＝
１を見つけるまでパケットが続くものとみなす。
【００５９】ソフトウェアは新しいパケットの始まりを
サーチする場合、ＯＷＮ＝０およびＳＴＰ＝０の記述子
をすべて捨てて次の記述子に移らなければならない。こ
のサーチの際、ソフトウェアはＥＮＰおよびＥＲＲを無
視するべきである。
【００６０】ソフトウェアがＳＴＰ記述子の所有権を持
っているとしても、リングの最初のセットアップが完了
すると受信記述子リングのＳＴＰ値を変更することはで
きない。ただし、そのリングにおける前のＳＰＴの記述
子の所有権がソフトウェアにある場合はこの限りではな
い。
【００６１】ＳＰＲＩＮＴＥＮ＝１の場合、ハードウェ
アは次のような変形された形の記述子解析を用いる：コ
ントローラはどこでＲＣＶパケットを入れ始めるかを決
定するためにＯＷＮおよびＳＴＰを調べる。新しいＲＣ
Ｖパケットは、ＯＷＮ＝１およびＳＴＰ＝１を有するバ
ッファにおいてのみ始まる。
【００６２】コントローラは、チェーンとして次のバッ
ファを使用できるかできないかを決定するためにＯＷＮ
ビットに従う。
【００６３】コントローラはＥＮＰ＝１またはＥＲＲ＝
１によってパケットの終りを常にマークする。
【００６４】コントローラは新しいパケットを始める場
所をサーチする場合、ＯＷＮ＝１およびＳＴＰ＝０であ
る記述子をすべて捨てて、次の記述子に移る。所有権ビ
ットをＯＷＮ＝１からＯＷＮ＝０に変えることによって
これらの記述子を捨てる。このような記述子はコントロ
ーラによる受信目的のために使われていないので、ドラ
イバはこれを認識しなければならない（ドライバはソフ
トウェア規則に従っているのならこれを認識するであろ
う）。
【００６５】コントローラは新しいパケットを始める場
所をサーチする場合に、ＯＷＮ＝０およびＳＴＰ＝０の
記述子をすべて無視して、次の記述子に移る。言換える
と、コントローラはリング内において所有していないエ
ントリを飛ばすことができるが、これは新しいパケット
を始める場所を探す場合のみである。
【００６６】新しいパケットを始める場所をサーチする
場合、コントローラは、ＯＷＮの状態にかかわらず、Ｓ
ＴＰ＝１に遭遇すると記述子リング内での進行を止め
る。ＯＷＮ＝１でありＳＴＰ＝１であるのなら、記述子
情報はコントローラによってストアされ、次の受信パケ
ットが到着したときに用いられ、この記述子位置の読取
はこれ以上行なわれない。ＯＷＮ＝０でありＳＴＰ＝１
であるのなら、その記述子情報は捨てられて、ＯＷＮビ
ットがＯＷＮ＝１に変わるのを待ちながら、この記述子
位置を定期的に読出す（記述子をポーリングする）。
【００６７】［ＳＰＲＩＮＴ記述子相互作用の例］１０
６０バイトの予期されるパケットサイズを選択するもの
とする。
【００６８】８００、２００および２００バイトのバッ
ファサイズを選択するものとする。記述子は図６に示さ
れる表１に従って変わる。１０６０バイトのパケットが
正しく到着し、コントローラがステップＣ６に達する前
にソフトウェアがステップＳ３に到達すると仮定する。
これは、本発明が正しく実現された場合の典型的なシー
ケンスである。
【００６９】次に、図６の表２を参照する。ネットワー
クにエラーがあるから、またはファイル伝送シーケンス
の最終パケットであるという理由で、予期される１０６
０バイトのパケットの代わりに９００バイトのパケット
が到着すると仮定する。
【００７０】＊イーサネットコントローラは第３記述子
のＥＮＰ位置に「ゼロ」を書込むかもしれないことに注
意。ここでは２つの可能性がある。
【００７１】（１） ドライバがアプリケーションの変
更されたバッファポインタを第３の記述子に書込んだ後
でコントローラがバッファ番号２へのデータ転送を完了
すると、コントローラはこのバッファに対してＥＮＰに
ゼロを書込み、さらにＯＷＮおよびＳＴＰに対してゼロ
を書込む。
【００７２】（２） ドライバがアプリケーションの変
更されたバッファポインタを第３の記述子に書込む前に
コントローラがバッファ番号２へのデータ転送を終了す
ると、コントローラはバッファ番号２におけるパケット
を完了させ、次の所有されていない第３のバッファに飛
ぶ。この場合、イーサネットコントローラはこの記述子
内のＥＮＰビットをリセットする機会がない。ソフトウ
ェアは前回リングを通った後、このビットをＥＮＰ＝１
のままにしておいた可能性がある。したがって、ソフト
ウェアはその位置をドントケアとして扱わなければなら
ない。記述子番号２においてＥＮＰ＝１（またはＥＲＲ
＝１）を見つけた後、ソフトウェアは次のＳＴＰ＝１を
見つけるまでＥＮＰビットを無視しなければならないの
が規則である。
【００７３】次に図６の表３を参照する。ネットワーク
にエラーがあることにより、またはファイル転送シーケ
ンスの最終パケットであるという理由により、またはひ
ょっとしてこのパケットが肯定アクノレッジパケットで
あるからという理由により、１０６０バイトパケットの
代わりに、１００バイトのパケットが到着したと仮定す
る。
【００７４】イーサネットコントローラは第３記述子の
ＥＮＰに対してゼロを書込むかもしれないことに注意し
なければならない。ただしこの場合、イーサネットコン
トローラが次の記述子のポーリングを完了するまでに、
ドライバがこの割込に応答してアプリケーションからポ
インタを得る可能性はあまりない。つまり、表３に示さ
れるケースが発生するほとんどすべての場合において、
イーサネットコントローラはこの記述子に対して設定さ
れたＯＷＮビットを見つけることはなく、したがってＥ
ＮＰビットは常に古い値を含むことを意味する。なぜな
ら、イーサネットコントローラにはそれを変更する機会
がないからである。
【００７５】イーサネットコントローラが表３の記述子
＃２のＥＮＰ位置にゼロを書込むだろうとしても、ソフ
トウェアはその位置をドントケアとして扱わなければな
らないことに注意する必要がある。なぜなら、記述子番
号２にＥＮＰ＝１を見つけた後は、ソフトウェアは次の
ＳＴＰ＝１を見つけるまでＥＮＰビットを無視するべき
だからである。
【００７６】［バッファサイズ調節］最大限のパフォー
マンスを得るためには、バッファサイズは予期されるパ
ケットサイズ、割込待ち時間の値およびアプリケーショ
ン呼出待ち時間に従って調整されるべきである。最良の
ドライバコードであれば、ＣＰＵの利用を最小限に抑
え、さらにネットワークのパケット終了からドライバか
らアプリケーションへのパケット送信の待ち時間（パケ
ット待ち時間）を最小にするだろう。これらの目的は、
ＣＰＵ利用を減らしながらネットワークのスループット
を増やすことにある。
【００７７】リングのバッファサイズは、対応する記述
子の所有権をＣＰＵが有する間ならいつでも変更できる
ことに注意しなければならない。バッファサイズを正し
く選択すると、ドライバがアイドルである時間を最大限
にし、それによって他のアプリケーションが走るための
利用できるＣＰＵ時間を最大限にし、イーサネットコン
トローラが最終バイトを書込んでからデータがドライバ
からアプリケーションに渡されるまでの時間を最小限に
する。図面において、これは図３に示されるＣ９および
Ｃ８間の時間を最小にしながらＳ０を最大にすることに
対応する。（タイムラインはたまたまＣ９からＣ８の最
小時間を示す。）バッファ番号１のサイズを増やすこと
によって、Ｓ０の値を増分させる。しかし、バッファ番
号１のサイズを増やす場合、Ｓ４の値も増加させる。バ
ッファ番号１のサイズが大きすぎる場合、ドライバには
Ｓ２、Ｓ３、Ｓ４、Ｓ５およびＳ６のタスクを行なう時
間が十分にはない。その結果、タスクＣ９の実行からタ
スクＳ８の実行までに遅延が出る。正しくタイミングさ
れたシステムは、Ｓ５およびＳ７の値が最小となる。
【００７８】図５のバッファサイズに対する一般的ガイ
ドラインに従うのなら、パフォーマンスにおいて平均的
な増加を達成することができる。しかし、前に述べたよ
うに、バッファの正しいサイズ合せは予期されるメッセ
ージサイズに依存する。予期されるメッセージサイズを
正しいバッファサイジングに関連させるのに、２つの問
題がある。
【００７９】（１） メッセージサイズは必ずしも正確
に予期することができない。なぜなら単一のアプリケー
ションでも、異なるときには異なるメッセージサイズを
受けるかもしれないからである。したがって、選択され
たバッファサイズが常にスループットを最大限にすると
は限らない。
【００８０】（２） 単一のアプリケーションにおいて
は、メッセージサイズは多少は予期できるかもしれない
が、同じドライバを複数のアプリケーションで共有する
場合、共通の予期できるメッセージサイズがないかもし
れない。
【００８１】正しくサイズを規定しようとするときにさ
らなる問題が起こる。なぜなら正しいサイズは、各シス
テムに取付けられるハードウェアおよびソフトウェアの
両方に応じてシステムごとに異なる、割込待ち時間にも
依存するからである。予期できないメッセージサイズに
対処するためには、ドライバは次のようにタスクＳ５お
よびＳ７で費される時間を調べる自己調節機構を実現す
ることができる。ドライバが各記述子にポーリングを行
なう間、行なわれたポーリング動作の数をカウントし
て、ポーリング動作の数がｘより大きいのなら、バッフ
ァカウントにｔバイトを加えることによりナンバー１の
バッファサイズをより大きい値に調整することができ
る。各Ｓ５およびＳ７に対してｘより少ないポーリング
動作が必要なら、ソフトウェアは、ｙバイトをバッファ
カウントから引算することによってバッファサイズをよ
り小さい値に調整する。ｔ、ｘ、およびｙに対する最良
値を決定するのに、このような調節機構の実験を行なわ
なければならない。
【００８２】バッファ番号１のサイズが調整されるとき
はいつも、バッファ番号２およびバッファ３のバッファ
サイズも調整しなければならないことに注意すべきであ
る。
【００８３】クライアントがスライディングウィンドウ
プロトコルを用いるファイル転送にかかわる場合のよう
に、クライアントアプリケーションに対するネットワー
クの受信パケットの典型的な混合がほとんど大型データ
パケットであり、小型パケットが非常に少ない場合、バ
ッファサイジングの効率を最大限にするためには、パケ
ットがあるサイズ制限よりも小さいサイズで到着した場
合、ドライバはこうした短いパケットに応答してバッフ
ァサイズを調整してはならない。典型的なクライアント
受信パケットサイズがそれほど明確に予期できない場
合、バッファサイズの調整量（すなわち、上記のｔ、ｘ
およびｙの値）はおそらくより大きなものにする必要が
ある。ＳＰＲＩＮＴドライバの正味の効果はこのような
アプリケーションではより小さなものとなる。
【００８４】［代替のＳＰＲＩＮＴフロー−２つの割込
方法］上記で述べたフローの代替は、図７で示されるよ
うに２つの割込を用いることである。上記のＳＴＰ割込
をただ探す代わりに、Ｃ３におけるＳＴＰの割込および
ＣＩＤにおけるＥＮＰ割込である。この代替方法は、ソ
フトウェアが記述子のＯＷＮビットをポーリングすると
きに「無駄にする」時間を減らすことを目的とする。そ
うすればこの時間を他のＣＰＵタスクに利用することが
できる。さらに、ＣＰＵがデータコピーに要する時間も
減らす。この節約した時間は他のＣＰＵタスクに用いる
ことができる。
【００８５】ワイヤでのパケット到着終了からアプリケ
ーションへのパケット配送の時間は、パケット待ち時間
と呼ばれる。１割込方法では、パケット待ち時間が減
り、ＣＰＵ利用が増える。２割込方法では、パケット待
ち時間は増え、ＣＰＵ利用は減る。
【００８６】非イーサネットタスクに与えることができ
るＣＰＵ時間のいくらかはＣＰＵのタスクスイッチング
に用い得ることに注意しなければならない。非イーサネ
ットタスクをＣＰＵにスワップする（Ｓ７Ａ後）ために
１つのタスクスイッチが必要であり、（Ｓ８Ａで）イー
サネットドライバを再度スワップするのに２つめのタス
クスイッチが必要である。これらのタスクスイッチング
を行なうのに必要な時間が、記述子をポーリングしない
ことによって節約した時間を超えると、この方法ではパ
フォーマンスに損失が出てくる。したがって、実現する
ＳＰＲＩＮＩＴ方法は注意して選択しなければならな
い。
【００８７】１割込方法と２割込方法との唯一の違い
は、ステップＳ７Ａ、Ｓ７およびＳ８Ａにある。１割込
方法のステップＳ７は第３記述子の所有権ビットに対す
るドライバのポーリングによって費される時間を表わす
が、２割込方法ではステップＳ７はＣＰＵで走るべき他
のタスクが利用できる時間である。なぜなら、Ｓ７Ａで
は、ドライバがスワップアウトされるからである。２割
込方法におけるステップＳ８Ａは、最終の記述子所有権
がイーサネットコントローラによってＣＰＵに渡された
後にドライバが再度スワップインされるのに必要なさら
なる割込待ち時間である。記述子所有権転送は、イーサ
ネットコントローラの割込を介してＣＰＵに知らされ
る。
【００８８】１割込および２割込の方法の双方におい
て、イーサネットコントローラが、受信パケット終了の
表示を含む記述子に対して割込を知らせることに注意す
べきである。ＳＰＲＩＮＴＥＮビットをセットすること
によって、受信パケットの第１の記述子／バッファの完
了の際にイーサネットコントローラはさらなる割込を発
生することができる。ＳＰＲＩＮＴＥＮは受信パケット
の最終記述子／バッファの割込発生に対しては何ら影響
を与えない。
【００８９】図８は２割込方法のバッファサイズ調整を
示す。なお、第２のバッファサイズは各々の方法におい
てほぼ同じである。
【００９０】図９はＳＰＲＩＮＴ２割込方法のソフトウ
ェアのフローチャートである。さらなる代替があり、こ
れは前の２つの方法の結合である。この第３の方法は２
割込方法によってセットされたバッファサイズを用いる
が、パケット終了を決定するポーリング方法を用いる。
これは良いパケット待ち時間を与えるが、より高いＣＰ
Ｕ利用という代償を要する種々の固定バッファサイズお
よび１割込方法のフローを有効に用いるさらなる折衷案
がある。これらはヒューリスティックなバッファサズ調
節コードを取除くことによって１割込方法の複雑さを減
らすが、ヒューリスティックなコードより効率が落ち
る。
【００９１】装置の実現：イーサネット装置の好ましい
実施例は、マイクロコードステートマシンを用いてコン
トローラのＳＰＲＩＮＴフローにおけるタスクのうち、
コントローラが負担すべき分を行なうのに必要な動作シ
ーケンスを作成する。
【００９２】本発明に係るイーサネットコントローラ２
２の動作を示す状態図は図１０で示される。最初に、ス
テップ１０２で、パケットの開始（ＳＴＰ）を示すアド
レスマッチがある。その後、ステップ１０４で、ＳＴＰ
ビットは１にセットされ、パケット終了（ＥＮＤ）は０
にセットされる。その後、ステップ１０６を介して現在
の記述子がチェックされる。現在の記述子が見つからな
い場合は再試行される。バッファが見つからないと、ス
テップ１０８を介してエラーが処理される。現在の記述
子をチェックする別のサブルーチンがある。これは明細
書の後で説明される。さらに、処理エラーサブルーチン
もある。これも後で説明される。
【００９３】バッファが見つかると、ステップ１１０を
介してインタリーブステップが行なわれる。このステッ
プにおいて、受信データは現在のバッファに転送され、
次の受取られた記述子が読出され、ペンディングしてい
るすべての送信パケット記述子および送信バッファデー
タが処理される。このインタリーブ機能を行なうシステ
ムは、本出願の譲受人に譲渡された、「フルデュプレッ
クスバッファ管理および装置」と題された、米国特許第
０８／０６８，６９６号に記載されている。このインタ
リーブ動作からバッファ終了、パケット出力、およびエ
ラー信号の３つの信号が出力される。バッファ終了信号
なら、もうバッファ領域がないので、ステップ１１２を
介して次の受信記述子がチェックされたかどうかが問わ
れる。チェックされていないのなら、ステップ１１４を
介して次の記述子の先読み読出がある。既にチェックさ
れているのなら、ステップ１１６を介してＯＷＮ記述子
がリセットされ、現在の記述子の状態が書込まれる。次
に、ステップ１１８を介してＳＴＰが１であるかどうか
が決定されなければならない。１と等しいのなら、ステ
ップ１２０を介して割込が発生され、スタートアップパ
ケットはゼロに変えられる。１に等しくないのなら、ス
テップ１２２を介して次の記述子の内容がコピーされ、
増分される。増分が行なわれた後、ステップ１２４を介
して現在の記述子ＯＷＮが１に等しいかどうか決定しな
ければならない。答えがノーなら、現在の記述子がステ
ップ１２６を介して読出される。答えがイエスなら、ス
テップ１２８を介して現在のＯＷＮが１に等しいかどう
か再度決定される。答えがイエスなら、ステップ１１０
のインタリーブ動作に戻り、上記のステップを繰り返
す。答えがノーなら、エラー信号が発生され、ステップ
１０８に送られる。ステップ１０８を介して処理エラー
サブルーチンは、ステップ１３０を介して割込を発生す
るように進み、次にリターンする。
【００９４】インタリーブステップ１１０からパケット
ＥＮＤが出力されると、パケットＥＮＤは１に等しい
（ステップ１３４）。その後、最終の記述子はステップ
１３６を介してパケットＯＷＮ＝１と書込まれる。次
に、ステップ１３８を介してＳＴＰビットは１にセット
され、ＥＮＤは０にセットされる。次に、ステップ１４
０を介して次の記述子の内容が装置の内部作業領域にコ
ピーされる。次に、ステップ１４２を介して再度現在の
記述子がチェックされる。アプリケーションソフトウェ
アが上記の機構に従って動作するなら、以前はシステム
バスの帯域幅を利用する際に待ち時間を引起こしていた
多くのステップはなくなっている。
【００９５】上記で述べたように、システムの適切な動
作を確実にするために実行しなければならない２つのサ
ブルーチンがある。具体的には、現在の記述子チェック
ルーチンおよび処理エラールーチンである。図１１に示
される現在の記述子チェックルーチンを参照すると、現
在のＳＴＰがチェックされて１に等しいかどうか調べ
る。しかしＳＴＰ＝１の答えがノーであるのなら、ステ
ップ１０７２を介して現在のＯＷＮが１に等しいかどう
か決定しなければならない。答えがイエスなら、ステッ
プ１０７４を介して現在の記述子にＯＷＮ＝０を書込
む。ステップ１０７２またはステップ１０７４の後の答
えがイエスであるのなら、ステップ１０７６を介して次
の記述子が読出される。その後、ステップ１０７８を介
して、次の記述子の内容が装置の内部作業領域に書込ま
れる。他方で、ステップ１０６４を介して現在のＳＴＰ
が１に等しいのなら、ステップ１０６６で現在のＯＷＮ
記述子が１に等しいかどうか決定しなければならない。
現在のＯＷＮが１に等しくないのなら、バッファがない
（ステップ１０６８）。現在のＯＷＮが１に等しいのな
ら、バッファが見つかっている（ステップ１０７０）。
【００９６】図１２を参照すると、処理エラースタート
が開始され、ステップ１０８０で現在のＯＷＮが１に等
しいかどうか決定しなければならない。１に等しくない
のなら、コントローラレジスタにエラービットをセット
し、終了する。１に等しいのなら、ステップ１０８４で
エラー表示を現在の記述子に書込み、ステップ１０８２
でコントローラレジスタにエラービットをセットし、終
了する。
【００９７】この状態図は好ましくはマイクロコードで
実現される。１割込ＳＰＲＩＮＴおよび２割込ＳＰＲＩ
ＮＴ実現の状態図は同じである。したがって、本発明の
動作によって、ネットワークの受信動作の終了前に、特
定のパケットに関連したネットワークで受取られたデー
タをストアすることによって、ネットワークパフォーマ
ンスを目に見えて上げるシステムが示される。これを行
なうことによって、ネットワークのパケット間の期間、
すなわちあるパケットの受信から次のパケットの送信ま
での期間はより有効に使用することができる。
【００９８】本発明は示される実施例に従って記載され
ているが、当業者は実施例に対して変形を行なうことを
容易に認識し、かつその変形は本発明の精神および範囲
内にあることを認識するであろう。したがって、前掲の
特許請求の範囲および精神から逸脱することなく多くの
変形が当業者によって行なわれ得る。
【図面の簡単な説明】
【図１】ネットワークにおけるノードのブロック図であ
る。
【図２】先行技術のイーサネットコントローラの動作の
タイムラインを示す図である。
【図３】本発明に係るイーサネットコントローラの動作
のタイムラインを示す図である。
【図４】本発明に係るイーサネットコントローラで用い
られた場合の第１のアプリケーションソフトウェアの動
作のフローチャート図である。
【図５】図３に従ってリング記述子のバッファグループ
化を示す図である。
【図６】データパケットストレージを示す表を示す図で
ある。
【図７】本発明に係るイーサネットコントローラの第２
の実施例の動作のタイムラインを示す図である。
【図８】図６に係るリング記述子のバッファグループ化
を示す図である。
【図９】本発明に係るイーサネットコントローラで用い
られた場合の第２のアプリケーションソフトウェアの動
作のフローチャート図である。
【図１０】本発明に係るイーサネットコントローラの動
作の状態図である。
【図１１】本発明に係る「現在の記述子ゲット」サブル
ーチンの状態図である。
【図１２】本発明に係る「処理エラー」サブルーチンの
状態図である。
【符号の説明】
１０ ノード １２ システムインタフェースアダプタ １４ システムバス １６ 記憶装置 ２０ 中央処理装置 ２２ イーサネットコントローラ １３ 拡張バス
───────────────────────────────────────────────────── フロントページの続き (72)発明者 マシュー・ジェームズ・フィッシャー アメリカ合衆国、94043 カリフォルニア 州、マウンテン・ビュー、メドック・コー ト、426 (72)発明者 グレン・ギブソン アメリカ合衆国、94583 カリフォルニア 州、サン・ラモン、バーネイ・クリーク・ プレイス、609 (72)発明者 トーマス・ジェファーソン・ルナルデュー アメリカ合衆国、95117 カリフォルニア 州、サン・ホーゼイ、ブラックフォード・ アベニュ、3701 (72)発明者 ジェフェリー・ドゥワーク アメリカ合衆国、95124 カリフォルニア 州、サン・ホーゼイ、トゥポロ・ドライ ブ、1682

Claims (14)

    【特許請求の範囲】
  1. 【請求項１】 ネットワークからのデータパケットの受
    信の速度を上げるためのシステムであって、 複数個のバッファメモリ手段と、 前記ネットワークから受信したデータを複数個のバッフ
    ァメモリ手段に書込むためのコントローラ手段と、 前記コントローラ手段の動作を制御するためのドライバ
    手段とを含み、前記ドライバ手段はアプリケーションメ
    モリ手段を含み、前記コントローラ手段は第１のバッフ
    ァメモリ手段が前記ネットワークからのデータで満たさ
    れた後割込を発生し、前記コントローラ手段は前記デー
    タを前記第１のバッファ手段に書込み、前記コントロー
    ラ手段は前記データを前記第２のバッファ手段に書込
    み、前記ドライバ手段は前記第１のバッファ手段からデ
    ータを前記アプリケーションメモリ手段の第１の部分に
    書込み、前記ドライバ手段はデータを第２のバッファメ
    モリ手段から前記アプリケーションメモリの第２の部分
    に書込み、前記コントローラは前記パケットからの残り
    のデータを最後のバッファメモリ手段に書込み、前記コ
    ントローラはデータの残りを前記アプリケーションメモ
    リ手段の最終部分に書込む、システム。
  2. 【請求項２】 前記複数個のバッファメモリ手段は３つ
    のバッファメモリを含む、請求項１に記載のシステム。
  3. 【請求項３】 前記ドライバ手段は複数個の受信記述子
    レジスタをセットアップする、請求項１に記載のシステ
    ム。
  4. 【請求項４】 前記コントローラ手段は現在の受信記述
    子レジスタをポーリングする、請求項３に記載のシステ
    ム。
  5. 【請求項５】 前記割込は前記ドライバ手段の動作を引
    起こす、請求項４に記載のシステム。
  6. 【請求項６】 前記割込は前記データパケットのヘッダ
    情報を集め、前記ヘッダ情報を前記アプリケーションメ
    モリ領域に与えることを引起こす、請求項５に記載のシ
    ステム。
  7. 【請求項７】 前記データパケットの指定されたバイト
    がコントローラ手段に与えられると、前記コントローラ
    手段は次の受信される記述子レジスタに対して最初の先
    読みオペレータを行なう、請求項６に記載のシステム。
  8. 【請求項８】 前記ドライバ手段はデータを前記アプリ
    ケーションメモリ領域の最初にコピーする、請求項７に
    記載のシステム。
  9. 【請求項９】 前記ドライバ手段は前記コントローラ手
    段が前記第２のバッファメモリ手段を前記データパケッ
    トからのデータで満たすまで、データが前記アプリケー
    ションメモリ領域の最初にコピーされた後、第２の記述
    子レジスタをポーリングする、請求項８に記載のシステ
    ム。
  10. 【請求項１０】 前記コントローラ手段は第３の記述子
    レジスタに対して第２の先読みを行ない、前記第２のバ
    ッファが満たされていると、前記コントローラ手段は第
    ２の記述子レジスタの所有権情報を変更し、前記コント
    ローラはデータを残りのバッファメモリ手段に書込む、
    請求項９に記載のシステム。
  11. 【請求項１１】 前記複数個の記述子レジスタは３のグ
    ループにある、請求項１２記載のシステム。
  12. 【請求項１２】 前記ドライバ手段は前記第１のバッフ
    ァの内容を前記アプリケーションメモリ手段の最初の部
    分にコピーする、請求項１１に記載のシステム。
  13. 【請求項１３】 前記レジスタの所有権が前記コントロ
    ーラ手段にあるのかまたは他の装置にあるのかを決定す
    るために、第１および第２のポーリングが行なわれる、
    請求項１２に記載のシステム。
  14. 【請求項１４】 前記残りのバッファはポインタを含
    み、それによってデータを直接前記アプリケーションメ
    モリ手段に入れることを可能にする、請求項１３に記載
    のシステム。
JP6271140A 1993-11-05 1994-11-04 データパケットの受信の速度を上げるためのシステム Withdrawn JPH07221780A (ja)

Applications Claiming Priority (2)

Application Number Priority Date Filing Date Title
US14737093A 1993-11-05 1993-11-05
US147370 1993-11-05

Publications (1)

Publication Number Publication Date
JPH07221780A true JPH07221780A (ja) 1995-08-18

Family

ID=22521308

Family Applications (1)

Application Number Title Priority Date Filing Date
JP6271140A Withdrawn JPH07221780A (ja) 1993-11-05 1994-11-04 データパケットの受信の速度を上げるためのシステム

Country Status (4)

Country Link
US (1) US5533203A (ja)
EP (1) EP0657824A1 (ja)
JP (1) JPH07221780A (ja)
KR (1) KR950015106A (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7783769B2 (en) 2004-03-31 2010-08-24 Intel Corporation Accelerated TCP (Transport Control Protocol) stack processing

Families Citing this family (14)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
GB9602552D0 (en) * 1996-02-08 1996-04-10 Madge Networks Ltd Communication network end station and adaptor card
US5864714A (en) 1996-04-16 1999-01-26 Comsys Communication & Signal Processing Ltd. Communication system which dynamically switches sizes of sample buffer between first size for quick response time and second size for robustness to interrupt latency
US5963720A (en) * 1996-08-13 1999-10-05 Advanced Micro Devices, Inc. Method and system for expediting transfer of data over a network using an additional field
US5881296A (en) * 1996-10-02 1999-03-09 Intel Corporation Method for improved interrupt processing in a computer system
GB9704368D0 (en) * 1997-03-03 1997-04-23 Madge Networks Ltd Interface device and method
US6016513A (en) * 1998-02-19 2000-01-18 3Com Corporation Method of preventing packet loss during transfers of data packets between a network interface card and an operating system of a computer
GB9822550D0 (en) * 1998-10-15 1998-12-09 British Telecomm Computer communications
US6691178B1 (en) * 2000-02-22 2004-02-10 Stmicroelectronics, Inc. Fencepost descriptor caching mechanism and method therefor
US6775693B1 (en) * 2000-03-30 2004-08-10 Baydel Limited Network DMA method
GB2372914B (en) * 2001-02-28 2003-12-24 3Com Corp Direct data placement and message reassembly
US20030145097A1 (en) * 2002-01-28 2003-07-31 Connor Patrick L. Ingress throttling via adaptive interrupt delay scheduling
US6981074B2 (en) * 2003-10-14 2005-12-27 Broadcom Corporation Descriptor-based load balancing
US8190698B2 (en) * 2006-06-30 2012-05-29 Microsoft Corporation Efficiently polling to determine completion of a DMA copy operation
US11875183B2 (en) * 2018-05-30 2024-01-16 Texas Instruments Incorporated Real-time arbitration of shared resources in a multi-master communication and control system

Family Cites Families (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CH584488A5 (ja) * 1975-05-05 1977-01-31 Ibm
US4075691A (en) * 1975-11-06 1978-02-21 Bunker Ramo Corporation Communication control unit
US4493021A (en) * 1981-04-03 1985-01-08 The United States Of America As Represented By The Administrator Of The National Aeronautics And Space Administration Multicomputer communication system
JPS6273844A (ja) * 1985-09-27 1987-04-04 Ricoh Co Ltd テレマテイ−ク端末のフレ−ム送出方式
US5163132A (en) * 1987-09-24 1992-11-10 Ncr Corporation Integrated controller using alternately filled and emptied buffers for controlling bi-directional data transfer between a processor and a data storage device
US5265261A (en) * 1989-08-14 1993-11-23 Microsoft Corporation Method and system for network communications using raw mode protocols
US5255371A (en) * 1990-04-02 1993-10-19 Unisys Corporation Apparatus for interfacing a real-time communication link to an asynchronous digital computer system by utilizing grouped data transfer commands
US5412782A (en) * 1992-07-02 1995-05-02 3Com Corporation Programmed I/O ethernet adapter with early interrupts for accelerating data transfer

Cited By (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7783769B2 (en) 2004-03-31 2010-08-24 Intel Corporation Accelerated TCP (Transport Control Protocol) stack processing
US7788391B2 (en) 2004-03-31 2010-08-31 Intel Corporation Using a threshold value to control mid-interrupt polling
US8121125B2 (en) 2004-03-31 2012-02-21 Intel Corporation Accelerated TCP (transport control protocol) stack processing
US8238360B2 (en) 2004-03-31 2012-08-07 Intel Corporation Header replication in accelerated TCP (transport control protocol) stack processing
US9602443B2 (en) 2004-03-31 2017-03-21 Intel Corporation Header replication in accelerated TCP (transport control protocol) stack processing
US10015117B2 (en) 2004-03-31 2018-07-03 Intel Corporation Header replication in accelerated TCP (transport control protocol) stack processing

Also Published As

Publication number Publication date
KR950015106A (ko) 1995-06-16
US5533203A (en) 1996-07-02
EP0657824A1 (en) 1995-06-14

Similar Documents

Publication Publication Date Title
US6574694B1 (en) Interrupt optimization using time between succeeding peripheral component events
US6742076B2 (en) USB host controller for systems employing batched data transfer
EP0577115B1 (en) Programmed I/O Ethernet adapter with early interrupts for accelerating data transfer
Kleinpaste et al. Software support for outboard buffering and checksumming
US6272499B1 (en) Linked lists of transfer descriptors scheduled at intervals
JP3553634B2 (ja) 相互接続インターフェース
US6070200A (en) Host adapter having paged data buffers for continuously transferring data between a system bus and a peripheral bus
US5721955A (en) System for transferring portion of data to host from buffer if size of packet is greater than first threshold value but less than second threshold value
US7496699B2 (en) DMA descriptor queue read and cache write pointer arrangement
EP0617368B1 (en) Arbitration process for controlling data flow through an I/O controller
US5367643A (en) Generic high bandwidth adapter having data packet memory configured in three level hierarchy for temporary storage of variable length data packets
US6473808B1 (en) High performance communication controller for processing high speed data streams wherein execution of a task can be skipped if it involves fetching information from external memory bank
US6393457B1 (en) Architecture and apparatus for implementing 100 Mbps and GBPS Ethernet adapters
JPH07221780A (ja) データパケットの受信の速度を上げるためのシステム
US5617424A (en) Method of communication between network computers by dividing packet data into parts for transfer to respective regions
US6351785B1 (en) Interrupt optimization using varying quantity threshold
JP3127523B2 (ja) 通信制御装置およびデータ送信方法
US20040153588A1 (en) Fencepost descriptor caching mechanism and method therefor
WO2004019165A2 (en) Method and system for tcp/ip using generic buffers for non-posting tcp applications
US6192440B1 (en) System and method for dynamically selecting interrupt storage time threshold parameters
US6529986B1 (en) Interrupt optimization using storage time for peripheral component events
US5522039A (en) Calculation of network data check sums by dedicated hardware with software corrections
US6189067B1 (en) System and method for dynamically selecting interrupt quantity threshold parameters
US8072884B2 (en) Method and system for output flow control in network multiplexers
US7729259B1 (en) Reducing latency jitter in a store-and-forward buffer for mixed-priority traffic

Legal Events

Date Code Title Description
A300 Application deemed to be withdrawn because no request for examination was validly filed

Free format text: JAPANESE INTERMEDIATE CODE: A300

Effective date: 20020115