JP4916482B2 - ギガビット・イーサネット・アダプタ - Google Patents

ギガビット・イーサネット・アダプタ Download PDF

Info

Publication number
JP4916482B2
JP4916482B2 JP2008139758A JP2008139758A JP4916482B2 JP 4916482 B2 JP4916482 B2 JP 4916482B2 JP 2008139758 A JP2008139758 A JP 2008139758A JP 2008139758 A JP2008139758 A JP 2008139758A JP 4916482 B2 JP4916482 B2 JP 4916482B2
Authority
JP
Japan
Prior art keywords
module
arp
tcp
packet
network
Prior art date
Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
Expired - Lifetime
Application number
JP2008139758A
Other languages
English (en)
Other versions
JP2008259238A (ja
Inventor
ジョン エス ミナミ
ロビン ヤス ウエシロ
マイケル ダブリュー ジョンソン
スティーブ スー
Original Assignee
エヌヴィディア コーポレイション
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Priority claimed from US10/093,340 external-priority patent/USRE39501E1/en
Priority claimed from US10/131,118 external-priority patent/US8218555B2/en
Application filed by エヌヴィディア コーポレイション filed Critical エヌヴィディア コーポレイション
Publication of JP2008259238A publication Critical patent/JP2008259238A/ja
Application granted granted Critical
Publication of JP4916482B2 publication Critical patent/JP4916482B2/ja
Anticipated expiration legal-status Critical
Expired - Lifetime legal-status Critical Current

Links

Images

Landscapes

  • Communication Control (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)

Description

本発明は、電気通信に関するものである。より特定的には、本発明は、データを送受信するために用いられる通信プロトコルに関連するデータを処理するための方法および装置に関するものである。
コンピュータ・ネットワークは、データを送受信するために、種々の通信プロトコルの設置を必要とする。通常、コンピュータ・ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、および、他のコンピュータ周辺装置のようなデバイスのシステムを有している。データは、通信プロトコル標準を用いてネットワーク中を伝わるデータ・パケットを通して、それらのデバイスの各々の間を転送される。多くの相異なるプロトコル標準が、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX)、シーケンス・パケット交換(SPX)、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)がある。各ネットワーク・デバイスには、プロトコルとプロセスデータとを中継するハードウェアとソフトウェアとのコンビネーションが含まれている。
一例は、ローカル・エリア・ネットワーク(LAN)システムに配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ハードウェアを用いて、リンク層プロトコルをハンドルし、ソフトウェアを用いて、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコル、および、通信データ・ハンドリングをハンドルしている。ネットワーク・デバイスは、通常、ハードウェア内にただ1つのリンク層プロトコルをインプリメントしており、配されているコンピュータを、その特定のLANプロトコルのみに制限している。データ・ハンドラとともに、より高位のプロトコル、例えば、ネットワーク・プロトコル、トランスポート・プロトコル、通信プロトコルは、データがネットワーク・デバイス・ハードウェアを通ってシステム・メモリに渡されるとすぐに、それらのデータを処理するソフトウェアプログラムとしてインプリメントされている。このインプリメンテーションの利点は、それが、コンピュータのような多目的デバイスを、多くの相異なるネットワークセットアップに用い、また、必要とされるどんな任意のネットワークアプリケーションをもサポートさせることを可能にするということである。しかしながら、このインプリメンテーションの結果として、そのシステムは、高いプロセッサ・オーバーヘッド、大量のシステム・メモリ、相異なるソフトウェア・プロトコルを協働させるためのコンピュータユーザ側の複雑な構成セットアップ、および、コンピュータのオペレーティング・システム(O.S.)とコンピュータとネットワーク・ハードウェアとを通信させ合うデータ・ハンドラを必要とする。
処理時間に必要とされるこの高いオーバーヘッドは、1つのデバイス上で同一のプロトコルをインプリメントしている複数のソフトウェア・プロトコル・スタックを動作させる方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのインプリメンテーションは、マイクロソフト・ウィンドウズを走らせている、ディスク・オペレーティング・システム(DOS)ベースのマシンで用いられている。通常動作中、ハードウェアが、トランスポート・プロトコルまたはリンク層プロトコルを確認すると、結果として生じるデータ・パケットが、パケットフレームフォーマットを決定して、任意の特定のフレーム・ヘッダを取り除くソフトウェアレイヤに送られる。そのパケットは、次に、さまざまなプロトコル・スタックに送られ、そこで、特定のプロトコルに対して評価される。しかしながら、そのパケットは、いくつかのプロトコルのスタックに送られた後で、受け入れられる、または、拒絶されるかもしれない。ソフトウェア・プロトコル・スタックによって作り出される時間遅れは、オーディオおよびビデオ伝送をリアルタイムに処理することを妨げる。即ち、それらのデータを、再生の前にバッファしなければならない。1つのプロトコルを処理するために必要な処理オーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、強力な中央処理装置(CPU)と大量のメモリとを用いるアプリケーションに向くことが、明白である。
ネットワーク・デバイスの従来のモデルにはまらないコンシューマ製品が、市場に参入してきている。それらの製品の新しい例は、ページャ（ポケベル）、携帯電話、ゲームマシン、スマート電話、テレビジョンである。それらの製品の大多数は、小さなフットプリント、8ビットコントローラ、限られたメモリを持っており、あるいは、非常に限定されたフォーム・ファクタを必要とする。それらのようなコンシューマ製品は、単純であり、低価格および低電力消費を必要とする。上述のプロトコル・インプリメンテーションは、それらの必要条件をかなえるには、あまりにも大きなハードウェアおよびプロセッサ能力を必要とする。そのようなインプリメンテーションの複雑さは、費用効率を高く、コンシューマ製品に組み込むことを困難にする。ネットワーク・アクセスが、低価格、低電力、小フォーム・ファクタのデバイス上に容易につくりあげられるほどに単純化できるようになれば、それらの製品は、インターネットのようなネットワーク・サービスにアクセスできるようになる。
通信ネットワークは、データを送受信するためにプロトコルを用いる。通常、通信ネットワークは、互いに通信し合うように接続されたコンピュータ、プリンタ、記憶デバイス、および、他のコンピュータ周辺装置のような、ノードとも呼ばれるネットワーク・デバイスの集合を有している。データは、プロトコルを用いて通信ネットワーク中を伝わるデータ・パケットを用いて、それらのネットワーク・デバイスの各々の間を転送する。多くの相異なるプロトコルが、今日、用いられている。一般的なプロトコルの例としては、インターネット・プロトコル(IP)、インターネット・ワーク・パケット交換(IPX) プロトコル、シーケンス・パケット交換(SPX) プロトコル、トランスミッション・コントロール・プロトコル(TCP)、ポイント・ツー・ポイント・プロトコル(PPP)、および、開発中の他の同様の新しいプロトコルがある。ネットワーク・デバイスには、プロトコルとデータ・パケットとを処理するハードウェアとソフトウェアとのコンビネーションが含まれている。
1978年に、標準設定母体である国際標準化機構(ISO)が、オープン・システム・インターコネクション(OSI)モデルとして知られるネットワーク参照モデルを作り出した。OSIモデルは、7つの概念層：1）ネットワーク・デバイスをネットワークに接続する物理的な構成要素を決定する物理(PHY)層、2）データ・パケットを含むフレームとして知られている離散形状にデータの動きを制御するデータリンク層、3）特定のプロトコルにしたがってデータ・パケットを組み立てるネットワーク層、4）データ・パケットの信頼性の高い送付を確実にするトランスポート層、5）ネットワーク・デバイス間の双方向通信を可能にするセッション層、6）データを表現する態様を制御し、そのデータが正しい形式にあることを確実にするプレゼンテーション層、7）ファイル共有、メッセージ・ハンドリング、プリンティング等を供給するアプリケーション層、を含有している。セッション層およびプレゼンテーション層は、このモデルから除外されることもある。最新の通信ネットワークおよびインターネットがどのようにISOの7層モデルに関係しているかに関する説明については、例えば、Douglas E. Comerによるテキスト“Internetworking with TCP/IP”（第1巻、第4版、国際標準図書コード0201633469）の第11章、および、W. Richard Stevensによるテキスト“TCP/IP Illustrated” （第1巻、国際標準図書コード0130183806）の第1章を参照されたい。
ネットワーク・デバイスの一例は、ローカル・エリア・ネットワーク(LAN)に配されたコンピュータであり、そこでは、ネットワーク・デバイスが、ホスト・コンピュータ内のハードウェアを用いて物理層およびデータリンク層をハンドルし、ホスト・コンピュータ上を走るソフトウェアを用いてネットワーク層、トランスポート層、セッション層、プレゼンテーション層、アプリケーション層をハンドルする。ネットワーク層、トランスポート層、セッション層、プレゼンテーション層は、プロトコル・スタックとも呼ばれるプロトコル処理ソフトウェアを用いてインプリメントされる。アプリケーション層は、データがネットワーク・デバイス・ハードウェアおよびプロトコル処理ソフトウェアを通ったときに、そのデータを処理するアプリケーション・ソフトウェアを用いてインプリメントされる。このソフトウェアベースのプロトコル処理インプリメンテーションの利点は、それが、多目的コンピュータを、多くの相異なるタイプの通信ネットワークに用い、また、必要とされるどんなアプリケーションをもサポートさせることを可能にするということである。しかしながら、このソフトウェアベースのプロトコル処理インプリメンテーションの結果として、ネットワーク層、トランスポート層、セッション層、プレゼンテーション層を処理するために、ホスト・コンピュータの中央処理装置(CPU)上を走るプロトコル処理ソフトウェアのオーバーヘッドが、非常に高いものになる。ソフトウェアベースのプロトコル処理インプリメンテーションは、また、データが、ソフトウェアによって処理されるときにコピーされ、そして、移動されなければならないから、ホスト・コンピュータ上に大量のメモリをも必要とする。プロトコル処理ソフトウェアによって必要とされる高いオーバーヘッドは、複数のソフトウェア・プロトコル・スタックの動作方法を教示している、1996年1月16日にSchrier等に公告された米国特許番号5,485,460に明示されている。このタイプのソフトウェアベースのプロトコル処理インプリメンテーションは、例えば、マイクロソフト・ウィンドウズを走らせているコンピュータで用いられている。
ネットワーク・デバイスの通常動作中、ネットワーク・デバイス・ハードウェアは、その後にホスト・コンピュータ内のプロトコル処理ソフトウェアに送られることになるデータ・パケットを抽出する。プロトコル処理ソフトウェアは、ホスト・コンピュータ上で走り、このホスト・コンピュータは、そのタスクがプロトコル処理ソフトウェアによって遂行されるように最適化されてはいない。プロトコル処理ソフトウェアと多目的ホスト・コンピュータとのコンビネーションは、プロトコル処理に対して最適化されておらず、それは、遂行能力限界に導く。プロトコル処理ソフトウェアの実行によって作り出される時間遅れのような、プロトコル処理中の遂行能力限界は有害で、例えば、オーディオおよびビデオ伝送のリアルタイム処理を妨げるであろうし、また、通信ネットワークの最大速度、最大容量での使用を妨げるであろう。1つのプロトコルを処理するために必要なホスト・コンピュータCPUオーバーヘッドの総計は、非常に高く、極端にかさばって扱いにくく、そして、ホスト・コンピュータ内にCPUと大量のメモリとの使用を必要とすることが明白である。
ネットワーク・デバイスの従来のモデルにはまらない新しいコンシューマ製品および工業製品が、市場に参入してきており、同時に、ネットワーク速度が、上昇し続けている。それらのコンシューマ製品の例には、インターネット接続可能なセルフォン、インターネット接続可能なTV、インターネットアプライアンスが含まれる。工業製品の例には、ネットワーク・インターフェイス・カード(NIC)、インターネット・ルータ、インターネット・スイッチ、インターネット・ストレージ・サーバが含まれる。ソフトウェアベースのプロトコル処理インプリメンテーションは、それらの新しいコンシューマ製品および工業製品の必要条件をかなえるには、あまりにも非能率的である。ソフトウェアベースのプロトコル処理インプリメンテーションは、その複雑さのために、費用効率を高くコンシューマ製品に組み込むことが困難である。ソフトウェアベースのプロトコル処理インプリメンテーションは、必要とされる処理電力のために、高速の工業製品にインプリメントすることが困難である。プロトコル処理が、低価格、低電力、高性能、集積化、小フォーム・ファクタのデバイス上に容易につくりだされるように単純化でき、最適化できれば、それらのコンシューマ製品および工業製品は、インターネットのような任意の通信ネットワーク上のデータを読み込んだり、書き込んだりできるようになる。
ソフトウェアベースのプロトコル処理インプリメンテーションとは対照的に、ハードウェアベースのプロトコル処理インプリメンテーション、即ち、インターネット・チューナが、J. Minami, R. Koyama, M. Johnson, M. Shinohara, T. Poff, D.Burkes,“Multiple network protocol encoder/decoder and data processor”, 米国特許番号6,034,963（2000年3月7日）（ ‘963特許）に記述されている。このインターネット・チューナは、プロトコルを処理するためのコア技術を提供する。
高いネットワーク通信速度に対するハードウェア解を備えたギガビット・イーサネット・アダプタを提供することは、有益なことである。さらに、複数の通信プロトコルを適合させるギガビット・イーサネット・アダプタを提供することも、有益なことである。
米国特許番号5,485,460 米国特許番号6,034,963 DouglasE. Comer 著 「TCP/IPとのインターネットワーキング（Internetworkingwith TCP/IP）」第1巻、第11章 W.Richard Stevens著 「図解TCP/IP（TCP/IP Illustrated）」 第1巻 第1章
本発明は、ギガビット・イーサネット・アダプタを提供する。そのシステムは、高ネットワーク通信速度を扱うためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュールの構築および設計を介して、複数の通信プロトコルに適合する。
本発明の好適な一実施例は、低メモリ要請しか持たず、かつ、高度に効率的なプロトコルデコードを供給する、低価格で、低電力で、容易に製造可能で、小フォーム・ファクタのネットワーク・アクセス・モジュールを提供する。本発明は、複数のネットワーク・プロトコルを同時にバイト・ストリーム態様でデコードもし、また、パケット・データを1つのパスで処理もし、それによって、システム・メモリおよびフォーム・ファクタの要求条件を減少させ、また、ソフトウェアCPUオーバーヘッドを排除する、ハードウェア統合システムを有する。
本発明の好適な一実施例は、TCP, IP, ユーザ・データグラム・プロトコル(UDP), PPP, ローソケット, RARP, ICMP, IGMP, Iscsi, RDMA, FCIPのようなネットワーク・プロトコルを、各バイトが受信されたときに同時にデコードする、複数のプロトコル・ステートマシンを有している。各プロトコル・ハンドラは、中間メモリを要求せずに、パケットからヘッダー情報を直接に構文解析し、インタプリトし、剥ぎ取る。
本発明は、インターネット・チューナ・コア、周辺装置、および、外部インターフェイスを提供する。ネットワーク・スタックは、ネットワーク・パケットを処理し、生成し、受信する。プログラム可能な内部プロセッサは、ネットワーク・スタックを制御し、任意の他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接サポートされていない他のプロトコルに対応するパケットをハンドルする。
バーチャル・メモリ・マネージャが、最適化されたハード・ワイヤード・ロジックにインプリメントされる。そのバーチャル・メモリ・マネージャは、バーチャル・ナンバのネットワーク・コネクションの使用を可能にする。ネットワーク・コネクションのバーチャル・ナンバは、利用可能な内部メモリ量および外部メモリ量によってしか制限されない
どの出ていくネットワーク・パケットも、データ・ステートマシンによって作り出され、そして、そのパケットにフォーマットを付加して、ヘッダ情報のチェックサムを行い、その結果生じたネットワーク・パケットを物理的な輸送レベルメカニズムを介して配布するネットワーク・プロトコル・ステートマシンを通る。
ハードウェア・ゲートレベル・インプリメンテーションは、設計者が、特定の応用に必要とされる機能を精選しながら、なおかつ、低価格で低電力で小フォーム・ファクタを維持することができる、モジュール性で嵌め込み可能な設計を提供する。
本発明の他の観点および利点は、添付の図面と組み合わせて、例として本発明の原理を例証する、以下の詳細な記述から明白になる。
本発明は、ギガビット・イーサネット・アダプタで具体的に表現される。本発明による1システムは、高ネットワーク通信速度をハンドリングするためのコンパクトなハードウェア解を提供する。さらに、本発明は、モジュール構造および設計を介して複数の通信プロトコルを適合させる。
図1を参照すると、本発明は、ネットワーク・プロトコル層101、データ・ハンドラ102、メモリ制御モジュール103、オペレーティング・システム(O.S.)ステートマシン・モジュール104を有し、その各々が、ハードウェア・ゲートレベルでインプリメントされている。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットをデコードし、出て行くネットワーク・パケットをエンコードする。ネットワーク・プロトコル層101は、入ってくるネットワーク・パケットを同時にデコードする種々のネットワーク・プロトコル・スタック（即ち、PPP, TCP, IP, UDP, ローソケット）を表わす複数のステートマシンを有している。ゲートレベルロジックでのプロトコル・スタックのインプリメンテーションは、ネットワーク・パケットを受信しながら、そのパケットをリアルタイムにデコーディングすることを可能にし、それによって、一時メモリ記憶を全く不要にする。パケット・ヘッダ情報の全てが、はがされ、そして、ステートマシンによって確認された後、その結果として得られたデータが、データ・ハンドラ102に渡される。データ・ハンドラ102は、複数のステートマシンを有し、それらの各々は、特定のデータタイプ（即ち、HTTP、eメール・フォーマット（ポスト・オフィス・プロトコル(POP3)、インターネット・メッセージ・アクセス・プロトコル(IMAP4)、シンプル・メール・トランスファ・プロトコル(SMTP)）、グラフィックス標準（ジョイント・フォトグラフィック・エキスパーツ・グループ(JPEG)、グラフィックス・インターチェンジ・フォーマット(GIF)）、Java、HTML）を処理する。データ・ハンドラのゲートレベル・インプリメンテーションは、本発明が受信データをリアルタイムで同時に処理することを可能にし、特に、データ・ストリームを受信しながら、それらのデータ・ストリームをハンドルする応用、即ち、Java, HTML, POP3 eメール、および、オーディオ応用、ビデオ応用に適している。2つ以上のデータ・ステートマシンによって必要とされるどのデータも、同時に供給される。特定のデータ・ステートマシンによって2回以上必要とされるどのデータも、それらのデータを指定するポインタをつけて、特定のメモリ位置に置かれる。全てのメモリアクセスは、メモリ制御モジュール103によって調停される（アービトレーションを行われる）。その結果、どのディスプレイデータも、メモリ制御モジュール103によって発送される。O.S.ステートマシン104は、リソース制御、システム、ユーザインターフェイスのためのステートマシン全体の間のアービトレータ（アービタ）として働く。どのユーザ入力も、O.S.ステートマシンによってインタプリトされ、データ・ハンドラ102に発送される。
一例として、HTMLフォーマットをインタプリトするデータ・ハンドラは、サイクリック・リダンダンシ・チェック(CRC)計算を用いてHTMLタグをデコードできる。HTMLフォーマットには、タグとして知られているキャラクタ・ストリングが含まれており、それは、後に続くテキストブロックが、ビデオ出力デバイス上に表示されるときに、そのフォーマティングを制御する。それらのタグは、1つの与えられたタグに対して1つのCRCナンバーを生成し、当該ナンバーを用いてフォーマティング命令をイネーブルにすることによって、効率的にデコードすることができる。そのようなデコーディングアルゴリズムは、ゲートレベル・インプリメンテーションに適しており、HTMLエンコードされたドキュメントを、今日可能であるよりもずっと敏速にビデオ出力デバイス上に表示させる。
本発明は、ハードウェア・ゲートレベルであるとして記述されるが、当業者であれば、それらの機能は、プログラマブル・アレイ・ロジック(PAL)、ジェネラル・アレイ・ロジック(GAL)、読み出し専用メモリ(ROM)、ソフトウェアのような多くの他の仕方でインプリメントできるということを、容易に認識できる。さらに、特定のプロトコルおよびデータタイプが指示されてきたが、当業者であれば、本発明のモジュール性は、本発明を、それらの特定のプロトコルあるいはデータタイプに限定させないということを、容易に認識できる。
図2を参照すると、本発明が、ハイレベル・ブロック・ダイアグラムで表現されている。このダイアグラムは、本発明の完全なインプリメンテーションにおける各モジュールの動作タスクを記述している。O.S.ステートマシン208は、システム“グルー”ロジック、および、デバイス制御インターフェイスを具備し、他のモジュールのステートマシン間の“トラフィックコップ”として働く。ネットワーク・プロトコル層207は，TCP/IPプロトコル, UDPプロトコル, ローソケット・プロトコル、PPPプロトコルに対するステートマシンを具備している。メモリ制御モジュール206は、システム・メモリとビデオ・ディスプレイ・メモリとが、同一のメモリエリアに存在することを可能にするユニファイド・メモリ・アーキテクチャ(UMA)のためのロジックを具備している。ディスプレイ・コントローラ205は、テレビジョン標準であるVGA、あるいは、他のタイプのディスプレイの制御を提供する。4つのデータ・ハンドラが、このインプリメンテーションに用いられている。Eメール・データ・ハンドラ201は、POP3フォーマットとIMAP4フォーマットとの両方をインタプリトする。JPEGフォーマットおよびGIFフォーマットをデコードする（商業標準および電話通信標準もデコードできる）インタプリタ202が、インプリメントされている。Java言語をバイトコード（中間言語）にインタプリトするJavaマシン203も、含まれている。ワールド・ワイド・ウェブ(WWW)ブラウザ204は、HTMLデコーダ／アクセラレータ、HTTPデータ・ハンドラ、および、集積されたeメール・ステート・マシンを具備している。
一例として、モデム物理トランスポートを想定して、入ってくるJPEG映像パケットが、システムによって追跡される。その要求は、ユーザが、定められたJPEG映像をダウンロードするという願望を、キーボード321をタイピングすることによって指示するとともに開始する。この入力は、キーボード・インターフェイス316によってインタプリトされ、O.S.ステートマシン315に渡される。O.S.ステートマシン315は、その入力を処理し、それを、1つのコマンドとして、HTTPクライアント311に渡す。HTTPクライアントは、要求されたパケットを生成し、それを、ポート・デコーダ309を介してTCP層308に渡す。TCP層は、適切なTCPヘッダをプリペンド（前方に追加）し、それを、IP層307に渡す。IP層は、次いで、適切なIPヘッダをプリペンドし、そのパケットを、PPP層306に渡す。PPP層は、適切なヘッダをプリペンドし、FCSをアペンド（後方に追加）し、そして、そのデータを物理トランスポート・インターフェイス305に渡す。物理トランスポート・インターフェイスは、そのデータをビットストリームに連続化し、そのパケットをモデム・ユニット304に送る。要求がホストサーバによって受け入れられると、ホストサーバは、要求されたJPEG映像をクライアント・システムに送り返す。そのデータは、最初に、データが存在することを物理トランスポート・インターフェイス305に指示するモデム 304によって受信される。物理トランスポート・インターフェイスは、次に、そのモデムからビット・シリアル・データを読み出し、それを、パラレル・バイト・データに変換し、そして、データが存在することをPPP層306に指示する。PPP層は、受信されたバイトを読み出す。PPP層が、有効なスタート・バイトを検出すると、そのPPP層は、入ってくるバイトを構文解析する。バイト・ストリームが、PPPプロトコル・フィールドに達すると、PPP層は、それをデコードし、そして、この例においては、埋め込まれているパケットを、タイプIPであるとしてデコードする。このプロトコルバイトに応えて、PPP層は、IP層307をイネーブルにし、そして、それに、IPデータが受信されていることを指示する。全てのそれ以降の受信データ・バイトは、今や、IP層に直接渡される。IP層は、次いで、入ってくるデータ・バイトの構文解析を始める。それが、IPヘッダ・プロトコル・フィールドまで来ると、それは、どのより高位のプロトコルがイネーブルにされるかを決定する。この例においては、IP層は、そのプロトコル・フィールドを、タイプTCPであるとしてデコードする。この時点で、IP層は、TCP層308をイネーブルにし、そして、TCPデータが受信されているときはいつでも、それに指示する。このインジケータがアクティブになると、全てのそれ以降の受信パケット内のデータ・バイトは、IP層とTCP層との両方に渡される（IP層は、チェックサム計算を完成させるためにデータ・バイトを必要とする）。TCP層は、その後、入ってくるデータ・バイトの構文解析を始める。それが、TCPヘッダ送信先ポート・フィールドまで来ると、それは、どのデータ・ハンドラがイネーブルにされるかを決定する。この例においては、そのポート・フィールドは、HTTPクライアント311をデコードする。この時点で、ポート・デコーダは、HTTPクライアントをイネーブルにし、そして、それに、HTTP要求データが受信されていることを指示する。HTTPクライアントは、次に、受信されたデータ・バイトの構文解析を始める。HTTPクライアントが、そのパケットがタイプJPEG映像であると決定すると、HTTPクライアントは、JPEGデコーダ313をイネーブルにする。この時点で、全てのデータ・バイトが、JPEGデコーダに発送される。JPEGデコーダは、次いで、全てのそれ以降に入ってくるデータ・バイトを受信し、したがって、それらを処理する。結果としてデコードされた映像が、メモリ・コントローラ312を介してディスプレイ・メモリに送られ、そして、ディスプレイデバイス326に出力するために、ディスプレイ・コントローラ324によって処理される。
図3に、また、示されているように、様々な層が、共有メモリリソースへのアクセスを必要とする。全てのメモリアクセスは、単一のメモリ・コントローラによって調停される。このメモリ・コントローラは、どの層あるいはどのハンドラが、任意の定められたサイクルでユニファイド・メモリ・バッファにアクセスを持つかを決定する。このメモリ・コントローラは、全てのシステム・メモリ・バッファおよびディスプレイ・メモリ・バッファが、単一のメモリ・バッファ・ユニットの内部に共有されるという事実のために必要とされる。ユニファイド・メモリ・コントローラ312は、様々な層からの読み出し要求および書き込み要求を取り上げ、一定の優先順位重み付けをなした動的循環アービトレーションスキームに基づいて、それらの要求を調停する。このアルゴリズムが、図3Aに描かれている。図示されている構成において、デバイスD2 302AとデバイスD3 303Aとの両方が、同時にメモリアクセスを要求すると、アービタ307Aが、最も最近にメモリアクセスを持たなかったデバイスにサイクルを振る。アービタ307Aは、次に、そのメモリ要求を、アービタ309AのA入力に渡す。アービタ309AのB入力がアイドル状態であれば、その要求は、アービタ310AのB入力に登る。アービタ310AのA入力がアイドル状態であれば、その要求は、メモリユニットに進む。全てのアービトレーション決定は、組み合わせ論理を用いて遂行され、それによって、どのデバイスに対しても、他のメモリ要求が全くなされていなければ、どんな待ち時間もなくしてしまう。優先順位重みは、アービトレーション樹構造を構成することによって割り当てられる。図3Aにおいて、デバイスDO 300AとデバイスD1 301Aとは、全てのデバイスが、不断のメモリ使用を要求した場合、それら2つのデバイスが、各々、25％時間アービトレーションを得ることのできる25％優先順位重み効力を、各々、持っている。デバイスD2 302A, D3 303A, D4 304A, D5 305Aは、各々、12.5％優先順位重みを持っている。メモリ・コントローラ設計は、個々のアービトレーション・ユニットの各々に同一の論理構造を持たせることによって、簡単になる。この仕組みにおいては、要求を出すデバイスの数、および、それらの優先順位重みは、アービタユニットを加え、そして、それらを配置することによって、簡単に構成できる。
図4を参照すると、本発明が提示している速度的な優位性は、現在用いられている従来のアーキテクチャよりもずっと高い。図は、各タスクを完了するのに必要な時間を示している。HTMLダウンロード401、HTMLのデコード402、JPEGダウンロード403、JPEGのデコード404、JAVAダウンロード405、JAVAバイトのデコード406、および、ストリーミングオーディオ407を要求する一連のパケットに対して、それらのタスクに要する総時間が、従来のアーキテクチャ408と本発明（iReadyアーキテクチャ）409とにおいて示されている。本発明409は、それらのタスクにおいて、従来のアーキテクチャ408よりもはるかに速い。
図5を参照すると、このタイプのネットワーク・アクセスの応用の発展が、示されている。現在、ネットワーク・クライアントの従来のモデル、即ち、コンピュータ501が、用いられている。ネットワークPC 502、ハンド・ヘルド・デバイス503、スマート電話504、セット・トップ・アプライアンス505、スマートテレビジョン506のコンシューマアプライアンス概念が、今や、現実となってきている。本発明は、コスト効率が高く、空間、速度、電力を重視したネットワーク・アクセスを備えた、それらの製品を供給する。
図6を参照すると、本発明は、テレビジョンチューナ602あるいはラジオチューナ611とほとんど同じように動作する…信号（パケット）は、遅延なく即座に処理され、そして、ディスプレイ出力あるいはオーディオ出力に送られる。用語「インターネット・チューナ」608は、そのような信号処理デバイスとの類似性として、本発明を記述するために用いられる。インターネット・チューナ608は、インターネット信号609と、スマートテレビジョン604、セット・トップ・アプライアンス605、スマート電話606、ハンド・ヘルド・デバイス607のような応用製品との間のインターフェイスとして働く。それは、テレビジョンチューナ602やラジオチューナ611のように、リアルタイムでインターネット信号609を処理する。
図7は、O.S.ステートマシン701、ネットワーク・プロトコル層702、メモリコントロール703、ディスプレイ・コントローラ704、eメール・データ・ハンドラ708、インタプリタ707、JAVAマシン706、WWWブラウザ705を用いた本発明の完全インプリメンテーションが、2つの分離したモジュールに分離されてもよいということを図解している。本発明のモジュール性は、データ・ハンドラ713（eメール・データ・ハンドラ717、インタプリタ716、JAVAマシン715、WWWブラウザ714）のような機能が、いくつかの応用において、1つの高水準ROMコード内に分離して置かれることを可能にする。
以下の応用例は、本発明のモジュール設計の万能性をさらに図解する。
図8は、ネットワークPC用として可能な本発明の構成を明示している。1つの変形例は、O.S.ステートマシン801、ネットワーク・プロトコル層802、メモリコントロール803、ディスプレイ・コントローラ804、eメール・データ・ハンドラ808、インタプリタ807、JAVAマシン806、WWWブラウザ805を含んでいる。これは、eメール817、インタプリタ816、JAVAマシン815、WWWブラウザ814コードに対するデータ・ハンドラを、1つのマイクロプロセッサ813上を走る高水準ROM（コード）内に置くことによって変形できる。マイクロプロセッサ813は、O.S.ステートマシン809を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。第3の変形は、サードパーティROM 823を使うマイクロプロセッサ822が、ネットワーク・プロトコル層819およびO.S.ステートマシン818から入ってくるデータをインタプリトすることを可能にする。マイクロプロセッサ822は、ディスプレイ・コントローラ821を通してデータを表示する。
図9を参照すると、ハンド・ヘルド・デバイスは、ネットワーク・プロトコル層901しか用いず、それを、カスタム・トランスポート・メカニズム902および現行マイクロコントローラ904にインターフェイス接続するのであってもよい。Eメール機能が、この構成にeメール・データ・ハンドラ905を含ませることによって、付加されてもよい。本発明のモジュール性をさらに明示すると、ネットワーク・プロトコル層911およびJAVAマシン910を、ハンド・ヘルド・デバイスに加えてもよく、それによって、ハンド・ヘルド・デバイスは、JAVAアプレットを処理することが可能になる。
図10を参照すると、スマート電話は、O.S.ステートマシン1001、ネットワーク・プロトコル層1002、メモリコントロール1003、eメール・データ・ハンドラ1006、ディスプレイ・コントローラ1004をインプリメントすることによって、eメール能力を付加されてもよい。ディスプレイ・コントローラ1004は、発光ダイオード(LED) ディスプレイ、液晶ディスプレイ(LCD)、あるいは、ビッグ・マップ・ディスプレイ(big-mapped display)を制御することができる。物理トランスポート・コントロール1005は、スマート電話の接続要件に応じて、オプション的に付加されてもよい。O.S.ステートマシン1007、ネットワーク・プロトコル層1008、メモリ・コントローラ1009が、現行マイクロコントローラ1010と一緒にスマート電話に付加されてもよい。マイクロコントローラ1010は、サードパーティeメール・クライアント・コード1011を用いて、eメール機能を遂行する。
最後に図11を参照すると、スマートテレビジョン、ケーブルボックス、ビデオ・カセット・レコーダ(VCR)、デジタルビデオディスク(DVD)プレーヤ、ゲームマシンが、本発明によって提示されるネットワーク・アクセス可能性を利用することができる。O.S.ステートマシン1102、ネットワーク・プロトコル層1103、メモリ・コントローラ1104、WWWブラウザ1107、JAVAマシン1106、および、（オプション的に）ディスプレイ・コントローラ1105が、現行コントローラ1101にインターフェイス接続されている。コントローラ1101が存在しないとき、ディスプレイ・コントローラ1105が、用いられる。eメール1115機能は、本発明のモジュール性の故に、容易に付加される。前述のように、eメール1124、インタプリタ1123、JAVAマシン1122、WWWブラウザ1121コードに対するデータ・ハンドラが、マイクロプロセッサ1120上を走る高水準ROM（コード）内にオプション的に置かれる。マイクロプロセッサ1120は、O.S.ステートマシン1116を通じて、ネットワーク機能およびディスプレイ機能に対して交信する。
パケット受信の例
図12は、受信されたネットワーク・パケットを描いている。そのパケットには、以下のアイテムが、左から右に示すように含まれている。
PPPヘッダ
IPヘッダ
TCPヘッダ
JPEGデータ
PPP FCS（フィールド・チェックサム）
PPPレイヤイネーブルと表わされているラインが、有効なスタート・バイトが検出されたときにアクティブになり、図13のPPPブロックの内部に生成される。このラインがハイレベルになると、PPPブロックの残りの部分がアクティブになる。PPPヘッダ内には、PPPパケットがカプセル化されているプロトコルのタイプを指示するフィールドが存在する。圧縮されていないPPPヘッダでは、それらは、4バイトであり、（スタート・バイト0x7Eを含めて合計すると）5バイトである。図12において、それらのバイトは、カプセル化されているデータがIPパケットであることを指示する、0x00および0x21である。このフィールドをデコードした後、PPPブロックは、IPレイヤイネーブル信号およびPPPデータフィールド信号をアクティブにし、そして、それら両方が、図13のIPブロックをイネーブルにする。IPレイヤ・イネーブル・ラインは、PPPプロトコル・タイプ・フィールドによってデコードされ、PPPデータ・フィールド・ラインは、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。これら2ラインは、IPブロックがイネーブルになるためには、アクティブでなければならない。IPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、PPPヘッダの直ぐ後に続くデータは、IPヘッダである。IPヘッダ内には、IPパケットの内部にカプセル化されているデータタイプを指示するフィールドが存在する。図12において、このフィールドは、カプセル化されているデータがTCPパケットであることを指示する0x06であることが示されている。TCPレイヤ・イネーブル・ラインは、このフィールドをデコードするIPブロックに応えてアクティブになる。IPヘッダ・プロトコル・フィールドとIPデータフィールドの先頭との間にくるいくつかのバイトが存在するから、IPデータ・フィールド・ラインは、数バイトの後にアクティブになる。IPデータフィールド信号は、入ってくるデータ・バイト・ストリームがネットワーク・パケットのデータフィールド部にあることを指示する。図13のTCPブロックがイネーブルになるためには、TCPレイヤ・イネーブル・ラインとIPデータ・フィールド・ラインの両方ともが、アクティブでなければならない。TCPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。図12を参照し直すと、IPヘッダの直ぐ後に続くデータは、TCPヘッダである。TCPヘッダ内には、送信先ポートに対する2バイトフィールドが、存在する。このフィールドは、カプセル化されたデータが、どのアプリケーションあるいはデータ・ハンドラに充てられているかを指示する。図12において、このフィールドは、ポート0x0003に対してデコードする。図13において、ポート3が、HTTPポートとして指定されている。TCPヘッダ内部の送信先ポート・フィールドをデコードした後、HTTPイネーブルラインが、アクティブになる。送信先ポート・フィールドとTCPデータフィールドの開始との間にいくつかの中間バイトが存在するから、TCPデータ・フィールド・ラインは、数バイトの後にアクティブになる。HTTPイネーブルラインとTCPデータ・フィールド・ラインの両方は、図13のHTTP/ポート3ブロックがイネーブルになるためには、アクティブでなければならない。HTTPブロックがイネーブルになると、それは、入ってくるデータ・バイトの構文解析を開始する。それが、JPEGヘッダをデコードすると、それは、図13のJPEGデコーダブロックをイネーブルにする。JPEGデコーダがイネーブルになると、それは、入ってくるデータ・バイトの処理を開始する。JPEGイネーブルラインは、JPEGブロックをイネーブルにするのに必要な唯一のラインである。
この詳細な記述は、TCP/IP処理の分野で十分に理解されている用語を用いている。これらの用語の詳細な記述を含む参照文献は、W. Richard Stevensによるテキストブック “TCP/IP Illustrated” 第1巻（国際標準図書コード0201633469）、第20刷であり、それは、ここで引用により援用される。適切な場所で、このテキストブックで説明されている、本記述に用いられる用語あるいは概念の説明が、適切なセクション番号あるいは図番によって示される。例えば、Stevens 2.2のような参照は、このテキストブックのセクション2.2のことを言っている。
頭字語
以下の定義が、本明細書で、以下の頭字語に対して用いられる。
ADPCM 適応的差分パルス符号変調
ARP アドレス解決プロトコル
CPU 中央処理装置
DHCP 動的ホスト構成プロトコル
HATR ハードウェア・アシステッド・テキスト・ラスタライゼーション
ICMP インターネット制御メッセージプロトコル
IP インターネット・プロトコル
IPV4 インターネット・プロトコル・バージョン4
MAC メディア・アクセス・コントローラ
MDIO マネージメントデータ入力／出力
MII メディア・インデペンデント・インターフェイス
MIME 多目的インターネット・メール・エクステンション
PPP ポイント・ツー・ポイント・プロトコル
QoS クォリティ・オブ・サービス
RARP 逆アドレス解決プロトコル
SPI シリアル・ペリフェラル・インターフェイス
TCP トランスポート・コントロール・プロトコル
TTL タイム・ツー・ライブ（生存時間）
ToS タイプ・オブ・サービス
UDP ユーザ・データグラム・プロトコル
UI ユーザインターフェイス
モジュールリスト
以下の名称は、本明細書に記述されるモジュールに対して用いられ、参照のためにここにまとめられている。
アドレス・フィルータ・モジュール
ARPキャッシュモジュール
ARPモジュール
データ・アライナ・モジュール
DMAエンジン・モジュール
イーサネット・フレーム・タイプ・パーザ・モジュール
イーサネット・インターフェイス・モジュール
イーサネットMACインターフェイス・モジュール
例外ハンドラ・モジュール
ICMPエコー応答モジュール
ICMPエコー応答プロセッサ・モジュール
ICMPエコー応答受信モジュール
インターナルプロセッサ
IP分割コントローラ・モジュール
IP分割モジュール
IPヘッダ・パーザ・モジュール
IP IDジェネレータ・モジュール
IPモジュール
IPパーザ・モジュール
IPルータ・モジュール
malloc1モジュール
メモリ・アロケータ・モジュール
NATとIPマスカレーディング・モジュール
パケット・スケジューラ・モジュール
パケット・タイプ・パーザ・モジュール
受信データ・メモリ・コントローラ・モジュール
受信DMAエンジン・モジュール
受信TCPパーザ・モジュール
受信器インターフェイス・モジュール
受信状態ハンドラ・モジュール
RSTジェネレータ・モジュール
ソケット受信インターフェイス・モジュール
ソケット受信モジュール
ソケット送信インターフェイス・モジュール
ソケット送信モジュール
TCPモジュール
TCPパーザ・モジュール
TCP受信インターフェイス・モジュール
TCP状態モジュール
TCP送信インターフェイス・モジュール
TCP送信モジュール
送信スケジューラ・モジュール
送信DMAエンジン・モジュール
送信器インターフェイス・モジュール
VSOCKメモリ・アロケータ・モジュール
VSOCKモジュール
バンド幅が増加し続けるにつれて、TCP/IP通信を処理する能力は、システムプロセッサに対するオーバヘッドがますます大きくなる。イーサネット・データ・レートは、秒当り10ギガビットのレートに達するから、TCP/IPプロトコル処理は、ホストCPUの処理パワーの100％近くを消費する。イーサネット・データ・レートが、秒当り10ギガビットまで増加すると、全TCP/IPプロトコル処理は、専用のハードウェアにおろされなければならない。インターネット・チューナ10Gは、一連のステートマシンとして、ARP, RARP, IP ホストルーティングのような関連プロトコルとともに、TCP/IPをインプリメントしている。インターネット・チューナ10Gコアは、インターネット・チューナ10Gネットワーク・スタックの特徴を拡張するためにプロセッサを用いることができるような接続が設けられるが、なんらのプロセッサもソフトウェアも用いない。
図14を参照すると、インターネット・チューナ10G 1404コアの使用の一例は、ギガビット・イーサネット・アダプタ・カード用に意図されたギガビット・イーサネット・アダプタ・チップにある。応用の一例として、ギガビット・イーサネット・アダプタは、サーバ内にプラグインされ、TCP/UDP/IPパケットあるいは他のパケットに、同様のプロトコルを用いて、固有の処理を行う。
インターネット・チューナ10Gコア 1404は、単一のギガビット・イーサネット・アダプタ・チップ内で、内部プロセッサ1406、システムペリフェラル1412、システムバスインターフェイス1414と連結している。このギガビット・イーサネット・アダプタ・チップは、イーサネット物理(PHY)デバイス1418、コンフィギュレーションEEPROM（コンフィギュレータ） 1410、インターネット・チューナ10Gコア 1404のためのオプションの外部メモリ1400と連結しており、ギガビット・イーサネット・アダプタを形成している。内部プロセッサ用のメモリ（ROMおよびRAMとも）は、ギガビット・イーサネット・アダプタ・チップ上（内部）にあってもよいし、ギガビット・イーサネット・アダプタ・チップの外側（外部）にあってもよい。
図15に関すると、インターネット・チューナ10G 1546は、例えば、ネットワークに配されたデバイス（記憶ユニット、プリンタ、カメラ等々のような）へのインターフェイスとして用いることができる。そのような応用において、カスタム・アプリケーション・ソケット1542が、第6層および第7層のプロトコルを処理し、そして、応用に特定のデータ移動を容易にするために、インターネット・チューナ10G 1546に付加されてもよい。このタイプの使用の例としては、ストリーミングメディアのためのカスタム・データ・パス、バルクデータ移動、および、iSCSI, RDMA, FCIPのようなプロトコルのためのサポートが、含まれる。
インターネット・チューナ10Gは、秒当り10ギガビットレートで処理する回線速度をサポートするように設計されているが、それと同じアーキテクチャおよび論理を、より低い速度においても同様に用いることができる。そのような場合には、イーサネット・メディア・アクセス・コントローラ(MAC)およびPHYのみが異なるのみである。より低い回線速度でインターネット・チューナ10Gアーキテクチャを用いる利点には、より低い電力消費が含まれる。
高速バンド幅に対する課題は、無線回線速度でTCP/IPパケットを処理することにある。秒当り1ギガビットレベルで始めると、TCP/IPの処理オーバーヘッドがシステムの主要な消耗源となり、したがって、他の解が必要なことは、明らかである。インターネット・チューナ10Gは、種々のアーキテクチャ・インプリメンテーションによって、これに取り組む。それらには、以下の特徴が含まれる。
・入ってくるデータのストリーム処理
・広いデータ・パス
・プロトコル・ステートマシンの並列実行
・共有リソースのインテリジェント・スケジューリング
・最小のメモリコピー
インターネット・チューナ10Gは、インターネット・チューナ中にインプリメントされた、それらのアーキテクチャ概念を取り付けており、上述のエンハンスメントを付加している。
以下のセクションは、さまざまなデータ・パスおよび転送タイプにおける動作の理論の説明とともに、システムのブロックレベルの記述を提供する。
ギガビット・イーサネット・アダプタ・チップは、インターネット・チューナ10G、内部プロセッサ、および、他の部品を具備する。ネットワーク・スタックが、プロトコル処理の大多数を遂行する。
図16を参照すると、ギガビット・イーサネット・アダプタ・チップのブロックレベルダイアグラムが、示されている。
このセクションは、内部プロセッサの使用の概要を提供する。ギガビット・イーサネット・アダプタ・チップは、プログラム組み込みを可能にすることが要求されるところでは、プログラム組み込みを可能にするために内部プロセッサ1688を利用する。この内部プロセッサ1688は、周辺装置にも配されている。通常の動作条件では、内部プロセッサ1688は、ネットワーク・スタック1610を制御する。
内部プロセッサ1688は、メモリ（RAM、ROM、あるいは、その両方のいずれでも）の可変量にアクセスする能力を持っている。メモリは、インターネット・チューナ10Gチップと同じチップ上にあってもよいし、外部メモリであってもよい。内部プロセッサ周辺装置の全て、即ち、RAM、ROM、および、インターネット・チューナ10Gネットワーク・スタック1610は、内部プロセッサメモリのアドレス空間の内部に位置している。内部プロセッサRAM空間のうちの64キロバイトが、インターネット・チューナ10Gネットワーク・スタック1610に対するユニファイド・メモリとして構成されている。このユニファイド・メモリは、例外ハンドリングのために、また、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタック1610によって送信または受信されるロー・イーサネット・パケットを組み立てるために、用いられる。このセクションは、インターネット・チューナ10Gアーキテクチャの概要を提供し、次いで、それに続くセクションは、個々のインターネット・チューナ10Gモジュールを記述する。インターネット・チューナ10Gは、上述のインターネット・チューナの元々のハードウェア・プロトコル処理のアイディアを採用しており、インターネット・チューナ10Gが、秒当り10ギガビット、および、それ以上のデータレートをハンドルすることをイネーブルにするエンハンスメントを付加している。
元々のインターネット・チューナに対する最も重要な付加は、増大されたデータ・パス幅、ステートマシンの並列実行、および、共有ハードウェアリソースのインテリジェント・スケジューリングである。さらに、インターネット・チューナ10Gは、RARP, ICMP, IGMP、および、iSCSIやRDMAのような新しい、より上位のプロトコルに対する直接のサポートを含めて、元々のインターネット・チューナよりも、プロトコルに対するさらなるサポートを供給する。
以下のセクションは、インターネット・チューナ10Gの基本的な構成要素の概要を提供する。その後のセクションは、インターネット・チューナ10Gの構成要素の全ての詳細な記述を提供する。
このセクションは、ソケット初期化を記述する。インターネット・チューナ10Gへの／からの任意のデータ転送に先立って、ソケットは、初期化されなければならない。ソケット初期化は、コマンド・ブロックを用いることによって遂行してもよいし、ソケットレジスタを直接プログラムすることによって遂行してもよい。全てのソケットに対してプログラムされなければならないパラメータには、送信先IPアドレス、送信先ポート番号、および、コネクションタイプ（TCPかUDPか、および、サーバかクライアントか）が含まれる。オプションのパラメータには、クォリティ・オブ・サービス(QoS)レベル、送信元ポート、タイム・ツー・ライブ(TTL)、および、タイプ・オブ・サービス(ToS)のセッティングが、含まれる。適切なパラメータがプログラムされると、そのソケットは、アクティブにされてもよいし、必要であれば、パケットを送受信するための接続が、確立されてもよい。UDPソケットの場合には、パケットは、即座に送信あるいは受信されてもよい。TCPクライアントにおいては、接続が、最初に確立されなければならない。TCPサーバにおいては、SYNパケットが、クライアントから受信されなければならず、そして、その後、接続が、確立されなければならない。
このセクションは、ホスト・コンピュータに接続されたインターネット・チューナ10Gによるパケットの送信の概要を提供する。
図17に関すると、インターネット・チューナ10Gがパケットを送信するために、ホスト・コンピュータ上を走るソフトウェア・アプリケーションが、最初に、インターネット・チューナ10Gに接続されているソケット・バッファ・メモリ1742内のソケット・バッファに、そのパケット・データを書き込む。そのパケット・データは、ソケット・バッファ・メモリ1742内のソケット・バッファに書き込まれているパケット・データとして察知され（あるいは、モニタされ）、そのパケット・データの部分チェックサムが、保存される。この部分チェックサムの計算は、さらなるチェックサムの計算に対する開始シードとして用いられる。この部分チェックサムの計算は、パケットの送信に先立って、再度パケット・データを読み出す必要を取り除く。ソフトウェア・アプリケーションは、32ビット単位あるいは64ビット単位で、ソケット・バッファ・メモリ内のソケット・バッファにパケット・データを書き込むことができる。32ビット単位あるいは64ビット単位のパケット・データのどのビットが有効であるかを指示する信号が、用いられる。
ソフトウェア・アプリケーションが、ソケット・バッファ・メモリ1742内のソケット・バッファにパケットを書き込むと、ソフトウェア・アプリケーションは、インターネット・チューナ10Gに、送信コマンドを配給することができる。ソフトウェア・アプリケーションが、送信コマンドを配給すると、TCPモジュール1752が、パケット長を計算し、TCPチェックサムおよびIPチェックサムを計算し、そして、TCPヘッダおよびIPヘッダを組み立てる。TCP/UDPモジュールが、次に、それらのヘッダを、ソケット・バッファ1746内のパケットのデータ部の前面に挿入して、送信の準備のできた完全なパケットを形成する。次いで、TCPモジュール1752が、送信優先順位キューに基づいて、ソケット・バッファ・メモリ内のその完全なパケットに、ソケットQoSレベルといっしょに、ポインタを置く。
送信スケジューラ・モジュールは、送信優先順位キューをモニタしている。送信スケジューラ・モジュールは、送信を待っているパケットを持つ全てのソケットを調べて、最も高いソケットQoSレベルを備えたパケットを選択する。送信スケジューラ・モジュールは、TCP, UDP, ICMP, ARP, RARP、および、ロー・イーサネット・パケットを含む、送信を待っている全てのパケットを調べる。送信スケジューラ・モジュールは、最小バンド幅アルゴリズム(minimum-bandwidth algorithm)を用いて、どのソケットも、完全にはスターブされないことを確保する（後のセクションにおいて、最小バンド幅アルゴリズムが、記述される）。送信スケジューラ・モジュールは、送信のための1つのパケットを選択して、そのパケットのソケット・バッファ・メモリ・ポインタを、MAC TXインターフェイス・モジュールに渡す。MAC TXインターフェイス・モジュールは、そのソケット・バッファ・メモリ・ポインタを用いて、ソケット・バッファ・メモリからそのパケットを読み出して、そのパケットをMACモジュール1770に渡す。パケットが再送信の必要のある（イーサネット衝突のため、あるいは、他の理由のために）場合には、そのパケットは、MAC TXインターフェイス・モジュール・スニファ・バッファ1764にも記憶される。パケットが、ソケット・バッファ・メモリから送信されると、そのソケット・バッファ・メモリは、解放される。有効な送信ステータス信号が、MACモジュールから受信されると、MAC TXインターフェイス・モジュール・スニファ・バッファは、クリアされ、MACモジュールは、次のパケットを送信することができる。無効な送信ステータスが、MACモジュールから受信されると、その後、MAC TXインターフェイス・モジュール・スニファ・バッファに記憶された最後のパケットが、再送信される。
以下のセクションは、インターネット・チューナ10Gによるパケットの受信の概要を提供する。
1つのパケットが、MACモジュールから受信されると、MACアドレス・フィルータ・モジュールが、イーサネット・ヘッダを調べて、そのパケットがハードウェア・インターフェイスに向けて送信されているかどうかを決定する。MACアドレス・フィルータ・モジュールは、ユニ・キャスト・アドレス、プログラムされたマスクの範囲内に収まるユニ・キャスト・アドレス、ブロードキャスト（一斉同報通信）アドレス、あるいは、マルチ・キャスト・アドレスを受信するようにプログラムできる。
受信されたパケットが、ARPパケットあるいはRARPパケットであれば、その受信されたパケットは、ARPモジュール1762に渡される。ARPモジュールは、受信されたパケットのOPフィールドを調べて、受信されたパケットがARP応答か（OPフィールドが1）、ARP要求か（OPフィールドが2）、RARP要求か（OPフィールドが3）、RARP応答か（OPフィールドが4）を決定する。受信されたパケットが、ARP要求パケットまたはRARP要求パケットであれば、ネットワーク上のあるデバイスが、そのARP要求パケットまたはRARP要求パケットに指定されているターゲットIPアドレスを持つネットワーク・デバイスからの情報を要求している。ARP要求パケットまたはRARP要求パケットのターゲットIPアドレスが、インターネット・チューナ10Gに属していれば、ARPモジュールが、ARP/RARP応答モジュールに、応答要求を渡す。受信されたパケットが、ARP応答パケットまたはRARP応答パケットであれば、受信されたパケットからの送り手のイーサネット・アドレスおよび受信されたパケットからの送り手のIPアドレスが、ARP/RARP要求モジュールに渡される。
受信されたパケットが、IPパケットであれば、そのパケットは、IPモジュールに渡される。IPモジュールは、受信されたIPパケットのIPヘッダの最初の4ビットにある4ビットIPバージョン・フィールドを調べて、そのパケットが、どのようにハンドルされなければならないかを決定する。パケットは、１度に64ビットずつ処理されるから、最初の64ビットが受信されただけでは、IPモジュールは、IPバージョン（IPv4かIPv6か）に関して、何らの想定もなすことができない。IPパケットの最初の64ビットが受信され、そして、処理されたときに、IPバージョンが、既知となる。この時点で、IPモジュールは、不用のIPバージョンデコードを中止し、そのIPバージョンデコーダをデフォルト状態にリセットする。
IPバージョンが既知になれば、IPモジュールは、IPヘッダの8ビット・プロトコル・フィールドをデコードする。デコードされたプロトコルに応じて、受信されたIPパケットが、さらなる処理のために、適切なモジュールに送られる。専用ハードウェア回路によって現在、直接的にサポートされているプロトコルには、TCP, UDP, ICMPが含まれる。
インターネット・チューナ10Gの現在のバージョンでは、各ICMPエコー要求パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPエコー要求パケットであれば、そのICMPエコー要求パケットは、記憶され、そして、通知が、ICMP応答モジュールに渡される。ICMP応答モジュールは、ICMPエコー要求パケットのICMPコード・フィールドを、ICMPエコー応答パケットに対応する値に変更し、ICMPエコー応答パケットチェックサムを調整し、そして、送信のためにICMPエコー応答パケットをスケジュール化する。
インターネット・チューナ10Gの現在のバージョンでは、各ICMPリダイレクト・パケットが、専用ハードウェアによって直接的にハンドルされる。受信されたパケットが、ICMPリダイレクト・パケットであれば、そのICMPリダイレクト・パケットは、構文解析され、そして、IPルートテーブルの適切なエントリが更新できるように、情報がIPルータ・モジュールに送られる。
他のタイプのICMPパケット、IGMPパケット、あるいは、専用ハードウェアによって直接的にサポートされていない他のプロトコルに対応するパケットは、内部プロセッサがそれらをハンドルできるIPバッファにコピーされる。タイム・クリティカル・データを携行しないプロトコルは、しばしば、ハウス・キーピング・プロトコルと呼ばれる。どのハウス・キーピング・プロトコルが専用ハードウェア回路によって処理されるかの決定は、インターネット・チューナ10Gのインプリメンテーションに依存する。インターネット・チューナ10Gのアーキテクチャは、さまざまなインプリメンテーションが、ハウス・キーピング・プロトコルを処理するために、専用ハードウェア回路と内部プロセッサとのどちらをも用いることができるほどに、十分にフレキシブルである。
受信されたパケットが、オ−プン・ソケットに対応するTCPパケットである場合には、そのソケット情報が構文解析され、そのソケットの状態情報が検索され、そして、受信されたTCPパケットのタイプに基づいて、そのソケット状態情報が更新される。受信されたTCPパケットのデータ・セクション（それが当てはまる場合には）が、そのソケットの受信データ・バッファに記憶される。ACKパケットが、TCPパケットを受信した結果として生成される必要のある場合には、TCP状態モジュールが、ACKパケットを生成し、そして、そのACKパケットを、送信のためにスケジュール化する。オ−プン・ソケットに対応していないTCPパケットが受信された場合には、TCP状態モジュールが、RSTパケットを生成し、そして、そのRSTパケットが、送信のためにスケジュール化される。
受信されたパケットが、UDPパケットである場合には、そのソケット情報が構文解析され、そのUDPパケット・データが、そのソケットの受信データ・バッファに記憶される。オ−プン・ソケットが、そのUDPパケットに全く存在しない場合には、そのUDPパケットは黙って放棄され、そして、ICMP送信先到達不能あるいは他のメッセージが生成される。
インターネット・チューナ10Gネットワーク・スタックは、内部プロセッサに対する周辺装置であるようにみえる。インターネット・チューナ10Gネットワーク・スタックに対する基準アドレスは、レジスタを介してプログラムされる。全てのレジスタアドレスは、この基準アドレス・レジスタに対するオフセットである。このアーキテクチャは、内部プロセッサが、インターネット・チューナ10Gネットワーク・スタックを、内部プロセッサメモリあるいはI/O空間の任意の位置に置くことを可能にする。
以下のセクションは、インターネット・チューナ10Gの構成要素の詳細な記述を提供する。
このセクションは、イーサネット・インターフェイス・モジュール1766を詳述する。イーサネット・インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュール1770、ARPモジュール1762、および、IPモジュール1758と通信する。イーサネット・インターフェイス・モジュールは、受信パスおよび送信パスの両方のデータをハンドルする。
送信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。
・送信のためにパケットをスケジュール化すること。
・送信のためにDMAチャネルをセットアップすること。
・イーサネットMACインターフェイス送信信号をハンドルすること。
受信パス上では、イーサネット・インターフェイス・モジュールは、以下のことに責を負っている。
・イーサネット・ヘッダを構文解析すること。
・アドレスフィルタセッティングに基づいて、受信されたパケットを受け入れるべきか排除すべきかを決定すること。
・受信されたパケットのフレーム・ヘッダのイーサネット・フレームタイプ・フィールドに基づいて、適切なプロトコル・モジュールをイネーブルにすること。
・受信されたパケットのデータ・セクションが、64ビット境界から始まるように、受信されたパケット・データを境界整列させること。
このセクションは、送信スケジューラ・モジュールを扱う。送信スケジューラ・モジュールは、ARPモジュール, IPモジュール, TCPモジュール、および、ロー送信モジュールからパケット送信要求を受け取り、どのパケットが次に送信されるべきかを決定することに責を負っている。送信スケジューラ・モジュールは、各パケット送信要求のQoSレベルを比較することによって、次に送信されるべきパケットを決定する。QoSレベルとともに、各パケット送信要求には、そのパケットの開始メモリ・ブロックに対するポインタが、パケット長とともに含まれている。送信スケジューラ・モジュールは、コネクション型に属するパケットの送信に優先順位をつけるようにプログラムされる適応性を持っている。例えば、TCPモジュールからのQoSレベル5を持つパケット送信要求は、IPモジュールからのQoSレベル5を持つパケット送信要求よりも高い優先順位を持つようにすることができる。以下は、パケット送信優先順位を決定するために送信スケジューラ・モジュールによって用いられるアルゴリズムである。
・何らのパケットチャネルも、スターブされた状態に達していないことを確かめるためにチェックする。これは、送信スケジューラ・モジュールがQoSレベルに応じないで、パケットを送信する以前に、そのパケットが見過ごされる回数に対応する、プログラムに組めるレベル（パケット型にしたがって、あるいは、コネクション型にしたがって）である。2つ以上のパケットが、同時にスターブされた状態に達している場合には、より高いQoSレベルを持つチャネルに属するパケットが、優先される。より低いQoSレベルを持つチャネルに属するパケットは、次に送信されるようにスケジュール化される。2つ以上のパケットが、同一のQoSレベルを持っている場合には、それらは、次の順番；TCPまたはUDPパケット、その次にARPパケット、その次にIPパケット、その次にロー・イーサネット・パケット、にしたがって、順に送り出される。
・ スターブされた状態のパケットを持つチャネルが、何ら存在しない場合には、最も高くQoSレベルとチャネル重みとが結合されたチャネルが、送信される。
・ただ1つのチャネルしか、送信されるべき1つのパケットを持たない場合には、そのパケットは、直ちに送信される。
1つのチャネルに属する1つのパケットが、送信のために選択されると、そのチャネルのメモリ・ポインタ、パケット長、および、パケット・タイプが、DMAエンジン・モジュールに転送される。転送が完了すると、そのDMAエンジン・モジュールは、送信スケジューラ・モジュールに信号を送る。この時点で、送信スケジューラ・モジュールは、DMAエンジン・モジュールに、次のパケットのパラメータを転送する。
このセクションは、DMAエンジン・モジュールについて記述する。送信スケジューラ・モジュールは、DMAエンジン・モジュールに、パケットパラメータ情報を渡す。パケットパラメータ情報には、パケット・タイプ、パケット長、および、パケット・データの開始に対するメモリ・ポインタが含まれる。DMAエンジン・モジュールは、パケット長を用いて、どれくらい多くのデータが、メモリ・バッファから転送されるかを決定する。パケット・タイプは、DMAエンジン・モジュールに、どのメモリ・バッファからパケット・データを検索するかを指示し、また、メモリ・ポインタは、どこからパケット・データの読み出しを開始するかを指示する。1つのパケットが、複数のメモリ・ブロックに渡ることができるから、DMAエンジン・モジュールは、そのチャネルのパケットに用いられているメモリ・ブロックの各々が、どのくらいの大きさであるかを理解する必要がある。DMAエンジン・モジュールは、メモリ・コントローラから、一度にデータ64ビットずつを受け取り、送信器インターフェイス・モジュールに、一度にデータ64ビットずつを渡す。
このセクションは、送信器インターフェイス・モジュールを扱う。送信器インターフェイス・モジュールは、DMAエンジン・モジュールからの出力を受け取り、イーサネットMACインターフェイス・モジュールに対する信号を生成する。64ビット・データ・バスが、DMAエンジン・モジュールとイーサネットMACインターフェイス・モジュールとを接続する。
このセクションは、受信器インターフェイス・モジュールを扱う。受信器インターフェイス・モジュールは、イーサネットMACインターフェイス・モジュールとインターフェイスしている。受信器インターフェイス・モジュールは、イーサネット・フレームを受け取り、そして、それらを、状態カウント情報とともに、アドレス・フィルータ・モジュールおよびイーサネット・フレームタイプ・パーザ（構文解析プログラム）モジュールに提出する。
このセクションは、アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールを扱う。アドレス・フィルータ・モジュールおよびイーサネット・タイプ・パーザ・モジュールは、イーサネット・ヘッダを構文解析し、以下の2つの機能を遂行する。
・そのイーサネット・フレームが、インターネット・チューナ10Gに属するハードウェア・インターフェイスに対するものであるかどうかを決定する。
・イーサネット・フレームタイプを構文解析して、イーサネット・フレームの残りを渡す場所を決定する。
アドレス・フィルータ・モジュールおよびイーサネット・フレーム・タイプ・パーザ・モジュールは、以下のフィルタオプションを用いてプログラムできる。
・プログラムされたユニ・キャスト・アドレスを受け入れる。
・ブロードキャスト・アドレスを受け入れる。
・マルチ・キャスト・アドレスを受け入れる。
・ネットマスクによって指定される範囲内のアドレスを受け入れる。
・無差別モード（全てのイーサネット・フレームを受け入れる）。
これらのフィルタオプションを制御するパラメータは、ホスト・システムのソフトウェアによって設定される。
以下のイーサネット・フレームタイプが、イーサネット・フレーム・タイプ・パーザ・モジュールによってサポートされている。
・イーサネット・フレームタイプ = 0x8000を持つIPv4パケット
・イーサネット・フレームタイプ = 0x86DDを持つIPv6パケット
・イーサネット・フレームタイプ = 0x0806を持つARPパケット
・イーサネット・フレームタイプ = 0x8035を持つRARPパケット
イーサネット・フレームタイプ・パーザは、他のイーサネット・フレームタイプを、例外ハンドラ・モジュールに渡す。
イーサネット・フレームタイプ・パーザは、また、802.2/802.3フォーマット・イーサネット・フレームとDIXフォーマット・イーサネット・フレームとの両方もハンドルする。802.2/802.3フォーマット・イーサネット・フレームでは、DIXフォーマット・イーサネット・フレームに存在するイーサネット・フレームタイプ・フィールドに替わって、長さパラメータが存在する。802.2/802.3イーサネット・フレームは、イーサネット・フレームタイプ・フィールドの値が、1500（10進）以下になったときに検出される。この事例が検出されると、イーサネット・フレームタイプ・パーザは、ARPモジュールとIP受信モジュールとの両方に、そのイーサネット・フレームに含まれるパケットを送るとともに、以後の各モジュールが、パケットがそのモジュール用ではないこともあるということを認識しながら、パケットをデコードしなければならないということを知るような信号をアサートする（アクテイブにする）。0x8000と0x86DDとのどちらのイーサネット・フレームタイプが受信されても、IPパケット信号がアサートされる。そうすると、IPヘッダ・パーザ・モジュールは、そのパケットがIPv4パケットであるか、IPv6パケットであるかを決定する。IPヘッダのプロトコル・バージョン・フィールドは、インターネット・チューナ10Gがパケットのプロトコルを決定する場合には、イーサネットパケット・タイプ・フィールドに優先する。
このセクションは、データ・アライナ・モジュールを扱う。データ・アライナ・モジュールは、データ・アライナ・モジュールに続くプロトコル処理モジュールのためにデータ・バイトを境界整列させる。データ・アライナ・モジュールは、イーサネット・ヘッダが64ビットのちょうど倍数でないために必要とされる。VLAN（バーチャルLAN）タグが、イーサネット・ヘッダに存在するか否かに依存して、データライナが、イーサネット・ヘッダに64ビット・データを再整列させて、イーサネット・ヘッダが、データ・アライナ・モジュールに続くプロトコル処理モジュールに対して長さのそろったMSBで現れるようにする。そうすると、イーサネット・フレームのデータ・セクションが、常に、ちょうど64ビット境界に境界整列する。データ・アライナ・モジュールは、また、データ・アライナ・モジュールに続くプロトコル処理モジュールに対する準備信号も生成する。
このセクションは、ARPモジュール1762およびARPキャッシュモジュール1750について記述する。ARPモジュールは、RARPプロトコルもサポートするが、ARPキャッシュを含まない。パケットを送信できる各モジュールは、それに先立ってARPキャッシュに照会を行うから、ARPキャッシュは、ARPモジュールから分離しておかれる。ARPモジュールは、受信されたイーサネット・フレームタイプに基づいて、ARPキャッシュに更新を送ることができる。
ARPモジュールの能力は、以下の通りである。
・ARP応答を生成することによってARP要求に応えることができる。
・ARPキャッシュに応えてARP要求を生成することができる。
・複数のIPアドレス（マルチホームホストの場合に、あるいは、ARPプロキシの機能を遂行するために用いられる）にARP応答を提供することができる。
・ターゲットされた（ユニキャスト）ARP要求を生成することができる。
・不法なイーサネット・アドレスおよび不法なIPアドレスを取り除く。
・整列されたARPデータを内部プロセッサに渡す。
・gratuitousARPを遂行することができる。
・内部プロセッサは、ARPデータを例外ハンドラにコピーして、自動的なARP応答の生成を回避することができる。
・内部プロセッサは、カスタムARP応答を生成することができる（回避モードにおいて）。
ネットワーク状態に依存してのARPパケットの可変優先順位。
RARPモジュールの能力は、以下の通りである。
・IPアドレスを要求する。
・特定のIPアドレスを要求する。
・はいってくるRARP要求が、例外ハンドラに渡される。
・イレギュラーRARP応答（ARP OPフィールドを持つRARPイーサネット・フレームタイプ、または、その逆）をハンドルする。
・整列したRARPデータを内部プロセッサに渡す。
・内部プロセッサは、カスタムRARP要求および応答を生成することができる。
ARPキャッシュモジュールの能力は、以下のようである。
・動的なARPテーブルサイズ。
・自動的に更新されるARPエントリ情報。
・送り手のハードウェアアドレスが変化したときに、ステータス・メッセージを生成する。
・ARPデータを無差別に収集できる。
・ARPモジュールを介するARP要求能力。
・静的なARPエントリをサポートする。
・静的なARPエントリを、動的なARPデータによって置き換えることをイネーブルにするためのオプション。
・ARPプロキシをサポートする。
・ARPキャッシュ・エントリに対して構成可能な終了時。
以下のセクションは、ARPモジュールの動作の理論を説明する。
このセクションは、ARPモジュールによるパケットの受信および構文解析を扱う。図18を参照すると、ARPモジュールは、ARPパケットとRARPパケットとの両方を処理する。ARPモジュールは、イーサネット受信モジュール1896から受信される、データに利用可能な信号を待っている。データに利用可能な信号が受信されると、入ってくるイーサネット・フレームのイーサネット・フレームタイプが、チェックされる。そのイーサネット・フレームタイプが、ARPまたはRARPに対応していなければ、ARPモジュールは、そのイーサネット・フレームに含まれているパケットを無視する。そうでなければ（対応していれば）、ARPモジュールは、そのイーサネット・フレームに含まれているパケット1898の構文解析を始める。
パケットは、イーサネット・インターフェイス・モジュールから、64ビット・ワードで読み出される。28バイトARPパケット（イーサネット・ヘッダを除いて）は、3.5個の64ビット・ワードを占める。
ARPパケットの最初の64ビット・ワードの最初の48ビットには、ハードウェアアドレスのタイプ、プロトコルアドレスのタイプ、バイト単位でのハードウェアアドレス長、および、バイト単位でのプロトコルアドレス長が、含まれる。ARPパケットのアドレスタイプ、および、長さフィールドの値が、イーサネット上でIPv4におけるARP要求に対して期待される値と比較される。それらの値が一致しなければ、そのARPパケットは、例外ハンドラ1894に渡される。そうでない場合には（一致していれば）、ARPモジュールが、ARPパケットの構文解析を続ける。ARPパケットの最初の64ビット・ワードの最後の16ビットには、ARP OPフィールドが、含まれる。ARPモジュールは、ARP OPフィールドを記憶し、そのARP OPフィールドが有効であるかどうかを確かめるためにチェックする。有効なARPパケットは、1, 2, 3または4に等しいARP OPフィールドを持つ。ARP OPフィールドが有効でない場合には、そのARPパケットは、例外ハンドラに渡される。そうでない場合には、ARPモジュールは、ARPパケットの構文解析を続ける。
ARPパケットの2番目の64ビット・ワードには、送り手ハードウェアアドレス、および、送り手プロトコルアドレスの半分が含まれなくてはならない。ARPモジュールは、、送り手ハードウェアアドレス・レジスタに、ARPパケットの2番目の64ビット・ワードの最初の48ビットを記憶する。次に、ARPモジュールは、送り手ハードウェアアドレスが有効かどうかをチェックする。送り手ハードウェアアドレスは、それがインターフェイスのイーサネット・アドレスと同様であるか、あるいは、それがブロードキャスト・アドレスであれば、無効である。送り手ハードウェアアドレスが無効であれば、そのパケットは、破棄される。ARPパケットの2番目の64ビット・ワードの最後の16ビットは、送り手プロトコルアドレス・レジスタの上部半分に記憶される。
ARPパケットの3番目の64ビット・ワードには、送り手プロトコルアドレスの後半が含まれており、また、ターゲットハードウェアアドレスも含まれている。ARPモジュールは、ARPパケットの3番目の64ビット・ワードの最初の16ビットを、送り手プロトコルアドレス・レジスタの下部の16ビットに記憶し、そして、送り手プロトコルアドレスが有効なことをチェックする。送り手プロトコルアドレスは、それがハードウェア・インターフェイスのIPアドレスと同様であるか、あるいは、その送り手プロトコルアドレスがブロードキャスト・アドレスであれば、無効である。送り手プロトコルアドレスが無効であれば、ARPモジュールは、そのARPパケットを破棄する。
ARPモジュールは、ターゲットハードウェアアドレスとインターフェイスのイーサネット・アドレスとを比較する。ターゲットハードウェアアドレスが、そのインターフェイスに属するイーサネット・アドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットハードウェアアドレスが、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスと同様であれば、ARPモジュールは、そのARPパケットの処理を続ける。
ARPパケットの4番目（最後）の64ビット・ワードの最初の32ビットには、ターゲットプロトコルアドレスが含まれている。ARPパケットは、長さが、3.5ワード即ち28バイト（224ビット）でなければならないので、この4番目の64ビット・ワードの最初の32ビットだけしか有効でない。ARPモジュールは、ターゲットプロトコルアドレスを、ターゲットプロトコルアドレス・レジスタに記憶する。ARPモジュールは、ターゲットプロトコルアドレスと、インターフェイスのIPアドレスとを比較する。ターゲットプロトコルアドレスが、インターフェイスのIPアドレスと一致しなければ、ARPモジュールは、そのARPパケットを破棄する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがARP要求であれば、ARPモジュールは、ARP応答を生成する。ターゲットプロトコルアドレスがインターフェイスのIPアドレスに一致し、また、ARPパケットがRARP応答であれば、ARPモジュールは、割り当てられたIPアドレスを、RARPハンドラ・モジュールに渡す。
ターゲットプロトコルアドレスが、インターネット・チューナ10GのインターフェイスのIPアドレスと一致すれば、ARPモジュールは、いずれもARPパケットから受け取られた送り手イーサネット・アドレスと送り手IPアドレスとを、ARPキャッシュモジュールに渡す。
このセクションは、ARPモジュールによるARPパケットの送信を扱う。ARPモジュールは、3つのソース；ARPキャッシュモジュール（ARP要求パケットおよびARPプロキシ応答のためのソース）、および、ARP応答FIFOを介してARPパーザから内部的に（ARP応答パケットのためのソース）、および、内部プロセッサから(カスタムARPパケットおよび全てのRARPパケットのためのソース)、からARPパケットを送信するための要求を受け取ることができる。ARPパケットおよびRARPパケットの複数のソースをハンドルするために、ARP送信スケジューラ1890は、ARPパケットおよびRARPパケットの送信をスケジュール化するために、送信優先順位キューを用いる。
送信要求は、2つ以上のソースが送信を望むときを除いて、先着順にARP送信優先順位キューに置かれる。その場合（2つ以上のソースが送信を望むとき）には、ARP送信優先順位キューに置かれる次の送信要求は、送信要求の優先順位に依存する。RARP要求送信要求が、一般に最も高い優先順位を持ち、その後に、ARP要求送信要求が続く。ARP応答送信要求が、最も低い送信優先順位を持っている。
ARP応答送信要求が最も高い送信優先順位を持つ1つの状況がある。これは、ARP応答FIFO 1892が一杯なときに起こる。ARP応答FIFOが一杯なとき、入ってくるARP要求送信要求が無視される。これが起こると、ARP応答送信要求は、ARP要求の再送信を余儀なくされることを回避するために、最も高い送信優先順位を与えられる。
ARP送信優先順位キューが一杯になると、ARP送信スケジューラ1890は、1つ以上の送信要求が完了するまで(そして、その送信要求がARP送信キューから取り除かれてしまうまで)、さらなる送信要求を受け入れない。ARPモジュールが、一杯になったARP送信キューを検出すると、ARPモジュールは、イーサネット送信スケジューラに、送信優先順位を増やすことを要求する。
イーサネット送信スケジューラが、ARPモジュールが送信することを許可すると、ARPパケットあるいはRARPパケットが、送信されるARPパケットのタイプに依存して生成される。ARP OPフィールドが、ARPパケット・タイプを決定する。ARP OPフィールドは、ARP送信優先順位キューに、各送信要求とともに記憶される。
このセクションは、入ってくるARPパケットの自動的な処理を回避する、ARPモジュールのARP回避モードの動作を扱う。ARPバイパスフラグがセットされ、そして、例外がイネーブルになると、入ってくるARPパケットおよびRARPパケットが、例外ハンドラバッファにコピーされる。次に、内部プロセッサが、例外ハンドラバッファにアクセスし、ARPパケットおよびRARPパケットを処理する。ARPバイパスモード中の場合、内部プロセッサは、ARP送信スケジューラに、ARP応答パケットを要求することができる。出て行くARPパケットおよびRARPパケットにカスタマイズできるフィールドは、送り手プロトコルアドレス、送信元ハードウェアアドレス、ターゲットプロトコルアドレス、および、ARP OPフィールドである。ARPパケットあるいはRARPパケットの他の全てのフィールドは、イーサネット上のIPv4におけるARPパケットおよびRARPパケットに使用される標準値にセットされる。送信元ハードウェアアドレスは、インターネット・チューナ10Gのインターフェイスのイーサネット・アドレスにセットされる。ARPパケットあるいはRARPパケットの他のフィールドを修正することが必要な場合には、内部プロセッサが、ローイーサネット・フレームを生成しなければならない。
以下のセクションは、ARPキャッシュモジュールの動作について説明する。
このセクションは、ARPキャッシュモジュール1750によるARPキャッシュへのARPキャッシュ・エントリの付加を扱う。ARPモジュール1762が、インターネット・チューナ10Gのイーサネット・インターフェイスに属するIPアドレスのうちの1つに対するARP要求あるいはARP応答を受け取ったとき、ARPキャッシュモジュールは、ARPキャッシュに動的なARPキャッシュ・エントリを作り出す。内部プロセッサが、ARPキャッシュモジュールがARPキャッシュ・エントリを作り出すことを要求したとき、静的なARPキャッシュ・エントリが、ARPキャッシュに作り出される。内部プロセッサは、また、動的なARPキャッシュ・エントリを作り出すこともできる。動的なARPキャッシュ・エントリがユーザによって指定された時間だけ存在してから、そのARPキャッシュ・エントリは満了し、また、ARPキャッシュモジュールが、そのキャッシュ・エントリを除去する。動的なARPキャッシュ・エントリの満了時間は、通常、5〜15分である。静的なARPキャッシュ・エントリは、一般に満了しない。ARPキャッシュに入力されることになる新しいARPデータは、2つの可能なソース：ARPレジスタを介しての内部プロセッサあるいはARPパケットパーザからARPキャッシュモジュールに渡される。両方の可能なソースが、ARPキャッシュモジュールに、ARPキャッシュ・エントリを加えることを同時に要求したときには、ARPパケットパーザからの動的なARPキャッシュ・エントリ要求の方が、優先順位を持っている。ARPパケットパーザからの動的なARPキャッシュ・エントリ要求は、入ってくるARPパケットをできるだけ速く処理することができるように、また、イーサネット・インターフェイスが動かなくなることを防ぐことができるように、優先順位を与えられる。
ARPキャッシュモジュールが、新しいARPキャッシュ・エントリのソースを選択すると、ARPキャッシュモジュールは、そのARPキャッシュ・エントリを、ARPモジュールメモリのどこに記憶するかを決定する。ARPキャッシュモジュールは、ARPルックアップテーブル(LUT)を用いて、ARPモジュールメモリ内の1つの位置に1つのIPアドレスをマップする。ARP LUTには、256個のARP LUTエントリが含まれる。各ARP LUTエントリは、広さ16ビットで、ARPコードによって割り付けられたm1メモリの位置に対するポインタ、および、ARPポインタ有効(PV)ビットを含んでいる。ARPキャッシュモジュールは、ARP PVビットを用いて、m1メモリ・ポインタが、ARPキャッシュによって割り付けられたm1メモリ内の有効なアドレスを指しているかどうかを決定する。m1アドレスは、それが、ARPキャッシュモジュールによって割り付けられたm1メモリのブロックの開始アドレスと等しければ、有効である。
ARPキャッシュモジュールは、ARP LUT内の8ビットインデックスを用いて、ARP LUTからm1メモリ・ポインタを検索する。ARPキャッシュモジュールは、8ビットARP LUTインデックスとして、32ビットIPアドレスの最後の8個を用いる。32ビットIPアドレスの最後の8個を用いる理由は、ローカル・エリア・ネットワークにおいては、最後の8個が、ホスト間で最も大きく変化するIPアドレスの部分であるということである。
ARPキャッシュモジュールが、ARP LUT中のどのARP LUTエントリを用いるかを決定すると、ARPキャッシュモジュールは、そのARP LUTエントリが、有効なm1メモリ・ポインタを含有しているかどうかを確かめるためにチェックする。そのm1メモリ・ポインタが有効であると、ARPキャッシュモジュールは、そのm1メモリ・ポインタを用いて、ターゲットIPアドレスのためのARP情報を検索するためにm1メモリにアドレス指定する。ARP LUTエントリが、有効なm1メモリ・ポインタを含有していなければ、ARPキャッシュモジュールは、メモリ・アロケータ・モジュールを用いて、m1メモリ・ブロックを割り付ける。ARPキャッシュモジュールが、m1メモリ・ブロックを割り付けると、ARPキャッシュモジュールは、ARP LUTエントリのm1メモリ・ポインタ・フィールドに割り付けられたm1メモリ・ブロックの最初の128ビット・ワードのアドレスを記憶する。
メモリ・アロケータ・モジュールを用いてm1メモリを割り付け、そして、ARP LUTにm1メモリ・ポインタを記憶した後、ARPキャッシュモジュールは、ARPキャッシュ内のARPデータをm1メモリに記憶する。m1メモリに記憶されたARPデータには、ARPモジュールが、ARPキャッシュルックアップ中に用いるのに必要である送り手IPアドレスが含まれている。ARPキャッシュモジュールは、ARPキャッシュ・エントリの一連のARP制御フィールドを用いる。ARPモジュールは、リトライ（再試行）カウンタARP制御フィールドを用いて、与えられたIPアドレスに対して遂行されるARP要求試みの回数を記録する。ARPモジュールは、エントリタイプ制御フィールドを用いて、ARPキャッシュ・エントリのタイプを指示する（000=動的なエントリ；001=静的なエントリ；010=プロキシエントリ；011=ARPチェックエントリ）。ARPモジュールは、解決フラグ制御フィールドを用いて、現在のARPキャッシュ・エントリのIPアドレスが、イーサネット・アドレスに成功のうちに解決されて（IPアドレスがイーサネット・アドレスに置き換えられて）しまっていることを指示する。ARPモジュールは、有効フラグ制御フィールドを用いて、このARPキャッシュ・エントリが有効なデータを含有することを指示する。一番最初のARP要求が遂行されている間は、ARPキャッシュ・エントリは、有効で、かつ、解決されていないことに注意されたい。ARPモジュールは、ソース制御フィールドを用いて、ARPキャッシュ・エントリのソースを指示する（00=動的に加えられた、01=システム・インターフェイス・モジュール、10=IPルータ・モジュール、11=システム・インターフェイス・モジュールとIPルータ・モジュールとの両方）。ARPキャッシュモジュールは、インターフェイス制御フィールドを用いて、インターネット・チューナ10Gに接続された複数のイーサネット・インターフェイスの使用を可能にする。ARP制御フィールドのセットに続いて、以後のARPキャッシュ・エントリのm1メモリ位置を指すARPキャッシュリンク・アドレスが存在する。ARPキャッシュリンク・アドレスの最上位ビットは、リンク有効フラグである。リンク有効フラグは、現在のARPキャッシュ・エントリに続いて、別のARPキャッシュ・エントリが存在することを指示する。ARPキャッシュ・エントリの最後の2つのフィールドは、IPアドレスが解決されてしまったイーサネット・アドレスおよびタイム・スタンプである。タイム・スタンプは、ARPキャッシュ・エントリがいつ作られたかを指示し、そのARPキャッシュ・エントリが満了したかどうかを決定するために用いられる。
256以上のホストを備えた、あるいは、複数のサブネットを備えたネットワークでは、異なるIPアドレス間での衝突が、ARP LUTに起きることがある。2つ以上のIPアドレスが、同一のARP LUTインデックスにマップしていると、ARP LUT内での衝突が起きる。この衝突は、2つ以上のホストが、IPアドレスの最後の8個において同じ値を持っていることによる。衝突に対処するために、ARPキャッシュモジュールは、ARP LUT中でエントリをチェーン状につなぐ。
ARPキャッシュモジュールが、ARP LUTのルックアップを遂行し、そして、有効なARP LUTエントリが、そのスロットに既に存在することが見出されたときには、ARPキャッシュモジュールは、m1メモリによって指し示されているARPエントリを検索する。ARPキャッシュモジュールは、ARPキャッシュ・エントリに記憶されているIPアドレスを検査し、そして、それを、ターゲットIPアドレスと比較する。IPアドレスが一致すれば、ARPキャッシュモジュールは、単純にARPキャッシュ・エントリを更新することができる。しかしながら、アドレスが一致しなければ、ARPキャッシュモジュールは、ARPキャッシュ・エントリのリンク有効フラグおよびリンク・アドレスを検査する。ARPキャッシュ・エントリの最後の16ビットには、同一のLUTエントリにマップする別のARPエントリを指すARPキャッシュリンク・アドレスが含まれている。リンク有効フラグがセットされていると、ARPキャッシュモジュールは、ARPキャッシュリンク・アドレスが指しているARPキャッシュ・エントリを検索する。この第2のARPキャッシュ・エントリのIPアドレスが、ターゲットIPアドレスと比較される。一致すれば、ARPキャッシュモジュールは、ARPキャッシュ・エントリを更新する。そうでない場合には、一致が見出されるか、あるいは、ARPキャッシュモジュールが、リンク有効フラグのセットされていないARPキャッシュ・エントリに到達するまで、ARPキャッシュルックアップ処理が、継続する(ARPキャッシュ・エントリのチェーンのリンクをたどって)。
ARPキャッシュモジュールが、一連のARPキャッシュ・エントリの端に到達し、そして、一致が見つからなかった場合には、ARPキャッシュモジュールが、新しいARPキャッシュ・エントリを作り出す。新しいARPキャッシュ・エントリを作り出すために、メモリ・コントローラ・モジュールに、m1メモリの割り付けを要求できる。m1メモリの各ブロックは、サイズが128バイトである。m1メモリの各ブロックは、8つのARPキャッシュ・エントリを収容することができる。ARPキャッシュモジュールが、m1メモリ・ブロックを、ARPキャッシュ・エントリで満たしてしまうと、ARPキャッシュモジュールは、メモリ・コントローラ・モジュールに、新しいメモリ・ブロックを要求する。
ユーザは、静的なARPキャッシュ・エントリを作り出すことができる。静的なARPキャッシュ・エントリは、一般に永続し、満了しない。ユーザは、動的なARPデータが、静的なARPキャッシュ・エントリと置き換わることを可能にするオプションを持っている。言い換えれば、ARPデータが、既に静的なARPキャッシュ・エントリを持っているIPアドレスに対して受信されたときには、その静的なARPキャッシュ・エントリを、受信された動的なARPキャッシュデータで置き換えることができる。この静的なARPキャッシュ・エントリの置き換えの利益は、これが、静的なARPキャッシュ・エントリが陳腐になるのを防ぐことができるということである。ARPキャッシュ・エントリ置き換えは、動的なARPキャッシュデータを、静的なARPキャッシュデータに重ね書きすることを可能にし、それによって、より最新のARPキャッシュに帰着する。ユーザが、IPアドレスのイーサネット・アドレスへのマッピングが不断に繰り返されていると確信している場合（例えば、IPアドレスとルータインターフェイスのイーサネット・アドレスとを記憶している場合)には、このARPキャッシュ・エントリ置き換え能力は、デセーブルにすることもできる。ユーザは、ネットワーク上のARPブロードキャストの数を最小限にするために、静的なARPキャッシュ・エントリを保存することを選ぶこともできる。注：ARPキャッシュプロキシエントリが、動的なARPキャッシュ・エントリによって重ね書きされることは決してない。
このセクションは、ARPキャッシュにおけるARPキャッシュ・エントリのルックアップを扱う。ARPキャッシュにおけるARPキャッシュ・エントリのルックアップは、ARPエントリの創出に対するそれと同様の処理に従う。図19に関して、ARPキャッシュルックアップは、ARP LUT 1920をチェックして、m1メモリが、与えられたARP LUTエントリに対して割り付けられているかどうかを決定することによって始まる。その通りであれば、ARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュヒットがある）か、あるいは、アサートされていないリンク有効フラグを持つARPキャッシュ・エントリが見つかる（その場合には、ARPキャッシュミスがある）まで、そのARP LUTエントリに連係したm1メモリが、探索される 1922。
ARPキャッシュミスが起こった場合には、ARPキャッシュモジュールは、ARP要求を生成する 1934。ARP要求には、ARPキャッシュによって割り付けられるm1メモリ内への新しいARPエントリの創出、および、必要であれば、新しいARPLUTエントリの創出が含まれる。ターゲットIPアドレスが、新しいARPキャッシュ・エントリに記憶され、新しいARPキャッシュ・エントリの解決ビットは、0にセットされ、そして、新しいARPキャッシュ・エントリの有効ビットは、1にセットされる。新しいARPエントリの要求カウンタも、0にセットされる。次に、ARPキャッシュ・エントリが、タイム・スタンプされ、また、ARP要求が、ARPモジュールに渡される。ARP応答が、1秒の間隔の後にARPモジュールから受信されない場合には、ARPキャッシュ・エントリの要求カウンタが、インクリメントされて、別のARP要求が送信される。3度のARP要求が、ARP応答なく送信されたら、ターゲットIPアドレスを解決する試みは、中断される。注：ユーザは、ARP再試行間隔およびARP要求再試行の最大数を指定することができる。
ARPキャッシュルックアップを要求しているモジュールは、ARPキャッシュミスが起こったとき、ARPキャッシュミスの通知を受ける。このARPキャッシュミスの通知は、内部プロセッサあるいはIPルータ・モジュールに、現在のターゲットIPアドレスに対するARP返答を待つことを決めるか、または、別のIPアドレスのための新しいARPキャッシュルックアップを始めて、現在のIPアドレスを送信優先順位キューの奥（最後）に置くかする機会を与える。この処理は、複数の接続を確立するときに、ARPキャッシュミスの衝撃を最小限にするのに役立つ。
一致するARPキャッシュ・エントリが、ARPキャッシュに見出されると、解決されたイーサネット・アドレスが、ARPキャッシュルックアップを要求したモジュールに返される。そうではなくて、ターゲットIPアドレスが、ARPキャッシュに見出されず、そして、全てのARP要求試行が、時間切れになった場合には、ARPキャッシュルックアップを要求したモジュールは、ターゲットIPアドレスが解決できなかったことを通知される。
注：IPルータ・モジュールからのARPキャッシュルックアップ要求が、イーサネット・アドレスに解決できなかった場合には、IPルータ・モジュールは、そのターゲットIPアドレスのための別のARPキャッシュルックアップを始める前に、最小20秒間待たなければならない。
このセクションは、ARPキャッシュ・エントリの満了を扱う。動的なARPキャッシュ・エントリは、限定された時間量においてしか、ARPキャッシュに存在できない。これは、IPアドレスのイーサネット・アドレスへのマッピングが陳腐になる（古臭くなる、としても知られている）のを防ぐためである。例えば、ネットワークが、複数のホスト間で一溜まりのIPアドレスを共有するためにDHCPを用いている場合、あるいは、デバイスのイーサネット・インターフェイスが、接続の間に変更される場合に、陳腐なアドレスマッピングが起こり得る。
キャッシュ・エントリの創出からの経過時間を記録するために、ARPキャッシュモジュールは、ARPキャッシュ満了タイマとして、16ビットARPキャッシュモジュールカウンタを用いる。ARPキャッシュ満了タイマは、2ヘルツの周波数で動作し、ARPキャッシュモジュールが創出してから経過した秒数を追跡するために用いられる。各ARPキャッシュ・エントリは、ARPキャッシュ満了タイマによって用いられる16ビットARPキャッシュモジュールカウンタから受け取られる16ビットARPキャッシュモジュールタイム・スタンプを含んでいる。この16ビットARPキャッシュモジュールタイム・スタンプは、IPアドレスが成功のうちに解決された時刻を示している。
ARPキャッシュ・エントリは、ARPキャッシュモジュールがアイドル状態の間に、満了することができる。ARPキャッシュモジュールは、ARPキャッシュモジュールによって現在処理されているARP要求またはARPキャッシュルックアップが全く存在しないときには、アイドル状態にある。ARPキャッシュモジュールがアイドル状態にある間、8ビットARPキャッシュモジュールカウンタが、ARP LUTの間をサイクル動作して、それを探索するために用いられる。ARP LUTの各エントリが、有効なm1メモリ・ポインタを含んでいるかどうかを確かめるためにチェックされる。m1メモリ・ポインタが有効であれば、対応するm1メモリ位置が、m1モジュールメモリ・ポインタを用いて検索される。次に、そのm1メモリ位置のARPキャッシュ・エントリは、ARPキャッシュ満了タイマから受け取られた、そのARPキャッシュ・エントリのタイム・スタンプと現在の時刻との間の差が、ARPキャッシュ・エントリの最大寿命以上であるかどうかを確かめるためにチェックされる。ARP LUTエントリに連係する第1のARPキャッシュ・エントリが、静的なARPキャッシュ・エントリであり、また、他のm1メモリ位置が、第1のm1メモリ位置と遮断されている場合には、それらのm1メモリ・ブロックに含まれるARPキャッシュ・エントリも、チェックされる。動的なARPキャッシュ・エントリが見出されるか、あるいは、与えられたARP LUTエントリに連係する全てのARPキャッシュ・エントリがチェックされれば、続いて、次のARP LUTエントリがチェックされる。
ARPキャッシュ・エントリが満了したことが見出されると、そのARPキャッシュ・エントリの有効ビットが、0にセットされる。同一のm1メモリ・ブロック内に他の有効なARPキャッシュ・エントリが全く存在しなければ、そのm1メモリ・ブロックは、割り付けを解放され、メモリ・コントローラ・モジュールに返される。割り付けを解放されているm1メモリ・ブロックが、与えられたARP LUTエントリに連係するただ一つのARPモジュールメモリ・ブロックである場合には、そのARP LUTエントリのPVビットも0にセットされ、それによって、そのポインタが無効になる。
このセクションは、ARP プロキシィングを遂行するARPキャッシュを扱う。そのARPキャッシュは、ARPプロキシキャッシュ・エントリをサポートしている。ARP プロキシィングは、インターネット・チューナ10Gがルータとして働くか、あるいは、ARP照会に応えることができないネットワーク上のデバイスがあるときに、用いられる。
ARPプロキシィングがイネーブルのとき、ARPモジュールは、ARPキャッシュモジュールに、インターネット・チューナ10Gのハードウェア・インターフェイスに属さないIPアドレスに対するARP要求を渡す。そうすると、ARPキャッシュモジュールは、ターゲットIPアドレスを探索するためにARPプロキシキャッシュ・エントリルックアップを遂行する。ARPキャッシュモジュールが、一致するIPアドレスを備えたARPキャッシュ・エントリを見出すと、ARPキャッシュモジュールは、そのARPキャッシュ・エントリのタイプ・フィールドをチェックして、そのARPキャッシュ・エントリが、ARPプロキシキャッシュ・エントリであるかどうかを決定する。そのARPキャッシュ・エントリが、ARPキャッシュプロキシエントリであれば、ARPキャッシュモジュールは、ARPモジュールに、そのARPプロキシキャッシュ・エントリからの対応するイーサネット・アドレスを渡し返す。次に、ARPモジュールは、送信元イーサネット・アドレスとしてARPプロキシキャッシュ・エントリに見出されたイーサネット・アドレスを用いて、ARP応答を生成する。ARPプロキシルックアップは、ARPモジュールによって受信されたARP要求に対してしか起こらない。
このセクションは、ARPキャッシュモジュールアクセス優先順位を扱う。相異なるARPタスクが、ARPキャッシュモジュールメモリへのアクセスに関して、相異なる優先順位を持つ。入ってくるARPパケットは、非常に高レートで受信されることもあり、再送信を回避するために、できるだけ速く処理されなければならない。ARPキャッシュプロキシエントリルックアップは、最高の優先順位を持っている。ARPモジュールからのデータを用いるARPキャッシュへの動的なARPキャッシュ・エントリの付加は、2番目の優先順位にある。IPルータ・モジュールからのARPキャッシュルックアップは、3番目の優先順位にある。内部プロセッサからのARPキャッシュルックアップは、4番目の優先順位にある。ARPキャッシュ・エントリの手動創出は、5番目の優先順位にある。ARPキャッシュ・エントリの満了は、最低の優先順位にある。
以下のセクションは、IPモジュール1758を扱う。IPモジュールは、イーサネットモジュール1766、TCPモジュール1752、メモリ・アロケータ・モジュール、例外ハンドラ1768、および、内部プロセッサとインターフェイスで接続している。
以下のセクションは、IPモジュールを有するモジュールについて記述する。
図20に関して、このセクションは、IPヘッダ・フィールド構文解析モジュール2062を扱う。IPヘッダの以下のフィールドは、IPヘッダ・フィールド構文解析モジュールによって構文解析される。
プロトコル・バージョン・フィールドIPヘッダ・フィールド構文解析モジュールは、IPv4とIPv6とのどちらの IPパケットも検出する。プロトコル・バージョン・フィールドは、プロトコル・バージョンを決めるために用いられる。0x4または0x6のプロトコル・バージョン・フィールドを備えたIPパケットしか、デコードされない。サポートされていないIPバージョン・フィーチャがイネーブルであると、受信された他の全てのプロトコル・バージョンが、ホスト・システムに送られる。サポートされていないIPバージョン・フィーチャがイネーブルでないと、そのIPパケットは、黙って捨てられる。
タイプ・オブ・サービス(ToS)フィールドは、構文解析されずに、受信されるIPパケットのために、使わないでおかれる。
IPパケット全長フィールド−IPヘッダ・フィールド構文解析モジュールは、受信されたIPパケット内のバイトの全数を決定するために、IPパケット全長フィールドを用いる。そうすると、IPヘッダ・フィールド構文解析モジュールは、以後のプロトコル・プロセッサ・モジュールに、IPパケットのデータ・セクションの端部の位置を指示することができる。指示されたバイト数を超えるIPパケット内のデータで、IPパケット信号がディアサートする（非アクティブになる）前に受信されたIPパケット内のデータは全て、パディング・バイトとみなされる。IPパケット内のパディング・バイトは、黙って破棄される。
識別フィールド、フラグフィールド、および、分割オフセット・フィールド・インターネット・チューナ10Gは、IPパケットを再構築するために、これらのフィールドを用いる。IP分割についてのセクションは、これらのフィールドがどのように用いられるかを記述する。
TTL（タイム・ツー・ライブ）フィールド−タイム・ツー・ライブ・フィールドは、構文解析されず、受信されるIPパケットのために、使わないでおかれる。
プロトコル・フィールドIPヘッダ・フィールド構文解析モジュールが、IPパケットにカプセル化されているプロトコルを決定するためにプロトコル・フィールドを用いる。表1は、インターネット・チューナ10Gにサポートされているプロトコル・フィールド値を示す。
Figure 0004916482
サポートされているプロトコル・フィールドデコード
IPパケットが、サポートされていないプロトコル・フィールド値を持って受信されたとき、そして、そのサポートされていないプロトコル・フィーチャがイネーブルであるとき、IPモジュールは、そのIPパケットを、ホスト・システムに渡す。サポートされていないプロトコル・フィーチャがイネーブルでないとき、IPモジュールは、そのIPパケットを、黙って破棄する。
ヘッダ・チェックサム・フィールドIPヘッダ・フィールド構文解析モジュールは、IPヘッダ・チェックサム・フィールドを、黙って破棄して解析しないか、そうでなければ、使わないでおく。IPモジュールは、IPヘッダ・チェックサム・フィールドを用いて、IPヘッダ・チェックサムが正しいことを確かめる。IPチェックサムが正しくなければ、IPモジュールは、以後の全てのプロトコル処理モジュールに届く不良チェックサム信号をアサートする。IPモジュールは、不良チェックサム信号が確認応答されるまで、不良チェックサム信号をアサートし続ける。
送信元IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信元IPアドレスを構文解析して、それを以後のTCPプロトコル処理モジュールおよびUDPプロトコル処理モジュールに送る。ICMPエコー要求パケットが受信された場合には、送信元IPアドレス・フィールドは、ICMPエコー応答パケットの送信に先立って、送信先IPアドレス・フィールドと交換される。
送信先IPアドレス・フィールドIPヘッダ・フィールド構文解析モジュールは、送信先IPアドレス・フィールドを構文解析して、それを、インターネット・チューナ10Gネットワーク・スタックが応えるべき有効IPアドレスのリストと比較する。このIPアドレス比較は、2クロック周期以上取ってもよいが、受信されたIPパケットの構文解析は、継続する。その後、IPアドレス比較の結果、受信されたIPパケットが、誤った宛名を書かれているということが判明した場合には、IPモジュールは、不良IPアドレス信号をアサートする。IPモジュールは、不良IPアドレス信号が確認応答されるまで、不良IPアドレス信号をアサートし続ける。
IPオプション・フィールド・セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、IPオプション・フィールドをホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルであると、IPモジュールは、また、受信されたIPパケット・ヘッダも、ホスト・システムに渡す。セーブ・オプション・フィーチャがイネーブルでなければ、受信されたIPパケットのオプション・フィールドは、黙って破棄される。
このセクションは、ローIP受信モジュール2066を扱う。ローIP受信モジュールは、内部プロセッサ1688が、インターネット・チューナ10Gネットワーク・スタック1610に、任意のIPパケットを送ることをイネーブルにする。ローIP受信モジュールは、診断の目的のために用いてもよいし、あるいは、例えば、内部プロセッサが、IPパケットデフラグやIPsec解読のような機能を遂行することを可能にするために用いてもよい。ローIP受信モジュール・フィーチャを用いるために、内部プロセッサは、最初に、メモリ・バッファにIPパケット・データを書き込む。次に、内部プロセッサは、ロー受信アドレス・レジスタに、このメモリ・バッファの開始アドレスを書き込む。次いで、内部プロセッサは、ロー受信コマンドレジスタの受信ビットをアサートし、それによって、IPパケット・データの転送が起きる。IPパケット・データの転送が完了すると、IPステータスレジスタにロー受信ビットが、セットされる。IP割り込みイネーブル・レジスタの一部であるロー受信割り込みイネーブル・ビットがセットされると、ローIP受信モジュールが、内部プロセッサに割り込みを渡す。次に、ローIP受信モジュールが、ロー受信割り込みイネーブル・ビットに1を書き込むことによって、その受信ステータス・ビットをクリアする。
このセクションは、ICMPエコー応答生成2060を扱う。ICMPエコー応答モジュールが、ICMPエコー応答パケットの生成をハンドルする。ICMPエコー応答モジュールは、全ての受信されるICMPパケットをハンドルする。ICMPエコー応答モジュールは、最初に、ICMPパケットの8ビットICMPタイプ・フィールドおよび8ビットICMPコード・フィールドを構文解析して、受信されたICMPパケットのメッセージタイプを決定する。受信されたICMPパケットのICMPメッセージタイプがエコー要求であれば、ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、エコー応答で、これらのエコー要求に自動的に応えるようにプログラムすることができる。この自動ICMPエコー応答フィーチャがイネーブルであると、受信されたICMPパケットのデータ・セクションが、メモリ・バッファに記憶される。ICMPエコー応答モジュールは、受信されたICMPパケット全体を確認する。受信されたICMPパケットが誤りのないものであれば、ICMPエコー応答モジュールは、メモリ・バッファに記憶されている受信されたICMPパケットのデータ・セクションに、イーサネット・ヘッダ、IPヘッダ、および、ICMPヘッダを加える。ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのタイプ・フィールドを、0x00に変更する。次に、ICMPエコー応答モジュールは、1の補数演算を用いて、0x08を加えることによりICMPチェックサム・フィールドを修正する。次いで、ICMPエコー応答モジュールは、メモリ・バッファに記憶されているICMPパケットのIPヘッダの送信元IPアドレス・フィールドと送信先IPアドレス・フィールドとを交換する。ICMPエコー応答モジュールは、また、メモリ・バッファに記憶されているICMPパケットのイーサネット・ヘッダの送信元イーサネット・アドレス・フィールドと送信先イーサネット・アドレス・フィールドとを交換する。新しいIPヘッダおよびイーサネット・ヘッダが生成されると、ICMPエコー応答モジュールは、ICMPエコー応答パケットを送信するために、送信アービトレータに対して送信要求をアサートする。
受信されたICMPパケットのメッセージタイプは、エコー要求でないこともある。受信されたICMPパケットのメッセージタイプがエコー要求でなければ、そのパケットは、例外ICMPパケットである。ユーザは、ホスト・システムを通じて、ICMPエコー応答モジュールが、次の2つの方法のうちの1つで例外ICMPパケットを処理するようにプログラムすることができる。ICMPエコー応答モジュールは、例外ICMPパケットを内部プロセッサに渡してもよく、あるいは、ICMPエコー応答モジュールは、例外ICMPパケットを黙って破棄してもよい。ICMP例外パケットが内部プロセッサに渡されることになる場合には、ICMPエコー応答モジュールは、IPヘッダを含む、受信されたICMPパケット全体を内部プロセッサに渡す。ICMP例外パケットは、IP例外ハンドラ・モジュールを介して内部プロセッサに送られる。
図21および22に関して、ICMPエコー応答モジュール2060は、ICMPエコー応答受信モジュール2180、および、ICMPエコー応答プロセッサ・モジュール2182から成っている。ICMPエコー応答受信モジュールは、ICMPパケットを受信し、ICMPパケットのコンテンツをm1メモリに記憶する。ICMPエコー応答受信モジュールは、受信されたICMPパケットが、誤りのないものであることを確認する2206。受信されたICMPパケットが、誤りのないものであれば、ICMPエコー応答受信モジュールは、受信されたICMPパケットからのIPヘッダ情報を、受信されたICMPパケット2202を含んでいるm1メモリ・ブロック2200のアドレスとともに、ICMPエコー応答プロセッサ・モジュール2182に渡す。
図23を参照すると、ICMPエコー応答プロセッサ・モジュールは、エコー応答パケット2322に対するイーサネット・ヘッダおよびIPヘッダを生成する。次に、ICMPエコー応答プロセッサ・モジュールは、アドレスがICMPエコー応答受信モジュールから受け取られたm1バッファブロックに、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答プロセッサ・モジュールは、受信されたICMPエコー要求のICMPチェックサムに0x08を加えることによって、ICMPチェックサムを生成する 2326。ICMPチェックサムに影響するエコー要求とエコー応答との間の唯一の相違は、ICMPコード・フィールドの相違（それは、0x08から0x00に変わる）だけであるので、この付加は、エコー応答に対する正しいICMPチェックサムを作り出す。
ICMPエコー応答プロセッサ・モジュールは、m1メモリ2322に、ICMPエコー応答パケットをアセンブルする。ICMPエコー応答パケットのアセンブリが完了すると、ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答パケット送信キュー2324に、ICMPエコー応答パケットの開始アドレスを置く。ICMPエコー応答パケット送信キューは、8つのエントリのための空きを持っている。ICMPエコー応答パケット送信キューが一杯になると、そのあと受信されるどのICMPパケットも、破棄される。ICMPエコー応答パケットが送信の準備を整えると、ICMPエコー応答プロセッサ・モジュールが、イーサネット送信器モジュール1766に合図を送る。その後、ICMPエコー応答パケットが、成功のうちに送信されると、イーサネット送信器モジュールは、ICMPエコー応答プロセッサ・モジュールに合図を送り返す。次に、ICMPエコー応答プロセッサ・モジュールが、ICMPエコー応答パケットを含有しているm1メモリ・ブロックを解放する 2328。ICMPエコー応答プロセッサは、複数のm1ブロックにまたがる大きなICMPエコー応答パケットをサポートする。
ICMPエコー応答受信モジュールは、ICMPエコー要求パケットの受信の間にエラーを検出することができる（エラーには、不良チェックサム、無効IPアドレスなどを含むことができる）。ICMPエコー応答受信モジュールがエラーを検出すると、それは、現在書き込まれているm1メモリ・ブロック（および、同じICMPエコー要求パケットに用いられた全ての以前のm1メモリ・ブロック）を解放する。ICMPエコー応答プロセッサ・モジュールは、ICMPエコー応答受信モジュールとICMPエコー応答プロセッサ・モジュールとの間で渡されるパケット中断信号によって、このエラー状態をハンドルする。
このセクションは、IP分割を扱う。インターネット・チューナ10Gは、IP分割を、直接ハードウェアにおいてハンドルすることもできるし、あるいは、内部プロセッサを用いてハンドルすることもでき、IPパケットを再構築して、次に、その再構築されたIP データグラムを、インターネット・チューナ10Gネットワーク・スタックに注入し返す。インターネット・チューナ10Gは、識別フィールド、送信元フィールド、送信先フィールド、および、プロトコル・フィールドにおいて同一の値を持つフラグメント（断片）を組み合わせることによって、IPデータグラムのフラグメントをアセンブルする。インターネット・チューナ10Gは、各フラグメントの各データ・セクションを、そのフラグメントのIPヘッダの分割オフセットによって指示される相対位置に置く。最初のフラグメントは、0にセットされた分割オフセットを持ち、また、最後のフラグメントは、0にセットされたmore-fragmentフラグを持つ。
このセクションは、分割されたIPパケットを、ハードウェアで直接的にハンドルするIP分割モジュール2064を扱う。図24に関して、IPパケットが、分割されたIPデータグラムに属するときには、そのIPパケットは、IPパケット・ヘッダにセットされたフラグメントフラグを持つ。そのとき、IP分割モジュールは、次のステップを実行する。
・IP分割モジュールは、IPパケット・ヘッダの16ビット識別フィールド、および、IPパケット・ヘッダの32ビット送信元IPアドレスを用いて、8ビットのハッシュ値を生成する 2456。
・エントリ使用中フラグとともに、32ビットメモリ・アドレスをルックアップするために、8ビット・ハッシュ値を用いる 2450。エントリ使用中フラグがセットされていなければ、それは、これが、この受信されたIPパケットの最初に受信されたIPフラグメントであることを指示している。
・次に、エントリ使用中フラグがセットされ、IPパケット・データベースが、初期化される。IPパケット・データベース2454, 2458は、VSOCKモジュール・オーバーフロー・ソケット・データベース・メモリ・エリアに存在する。IPパケット・データベースの内部には、IPパケット・データを保持するメモリ(ソケット受信データ・メモリ空間の)に対するポインタが、ある。このIPパケットセグメントが、どれくらい長く保持されているかがわかるように、タイム・スタンプも、IPパケットCBに含まれている。タイマが満了すると、全ての受信されたIPパケットセグメントが、破棄される。
・分割オフセットが、IPパケット・ヘッダにセットされていれば、その分割オフセットを用いて、メモリ・バッファ内をどれくらい下った位置で、受信されたIPパケット・データを書き込み始められるかを決定する 2452。
・カウンタが、受信されたバイトの総数を記録し、IPパケット2462, 2460, 2464とともに保持される。このカウンタに受け取られた総バイトが、最後のIPパケット・フラグメント（IPヘッダの制御フラグフィールドのmore fragmentフラグが0にセットされるという事実によって指示される）のデータ量と、最後のIPパケット・フラグメントの分割オフセットとの和と比較される。分割されたIPデータグラムの全データが届いていると計算されると、そのソケット情報が、TCP/UDPプロトコル処理層に渡される。
図25を参照すると、IPパケット・データベースに記憶されるさらなる情報に、IPパケット衝突テーブル2590、および、IPパケット・ポインタ・テーブル2588が含まれる。使用中の各ルックアップテーブルエントリ2580は、IP送信元アドレス、および、IPパケット識別ペアと連係している。そのペアは、衝突テーブルに記憶されている。ハッシング（ハッシュ法）2598が、既に使用中のルックアップテーブル中のエントリをヒットした場合、以下の2つの可能性がある。
・受信されたIPパケット・フラグメントが、既に考慮にはいっているIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致する。
・受信されたIPパケット・フラグメントが、未知のIPデータグラムに属している。受信されたIPパケット・フラグメントのIP送信元アドレス・フィールドおよびIPパケット識別フィールドが、衝突テーブルエントリに記憶されている値と一致しない。それは、衝突が起こり、したがって、その受信されたIPパケット・フラグメントが棄てられるということを意味する。
使用中のフラグのほかに、LUT 2580の各エントリは、パケットが受信データ・バッファ・メモリに収まるために振り当てられる開始アドレスを記憶する。ハッシング2598が、まだ使用されていないLUTのエントリをヒットしたら、メモリ要求が、開始アドレスを計算するVSOCKモジュール・メモリ・アロケータ・モジュール2500に送られる。メモリ・アロケータ・モジュールによって分割ブロックに配給されるメモリ・ブロックのサイズは、固定されている（2キロバイト）。再構築されるべきIPパケットが、1ブロックのメモリにぴったり合う場合には、IPパケット・フラグメントが、切れ目なく記憶され、そして、メモリ・ブロック内の正確な位置が、開始アドレスおよびIP分割オフセットから計算できる。メモリ・アロケータ・モジュールは、メモリ・ブロックを、切れ目なく割り当てない。再構築されるべきIPデータグラムが、2つ以上のメモリ・ブロックを必要とする場合には、受信データ・バッファ・メモリへのパケット・フラグメントのマッピングは、より難しくなる。開始アドレス、IP分割オフセット、および、IP長フィールドに基づいて、ユーザは、メモリ・ブロック境界が、再構築されたIPデータグラムによって交差されようとするときを計算することができる。最初にメモリ・ブロック境界が交差されるとき毎に、メモリ要求が、次に利用可能なブロックの開始アドレスをその後に配給するVSOCKメモリ・アロケータ・モジュールに送られなければならない。さらなるブロックの開始アドレスが、有効フラグとともに、ポインタテーブルに記憶される。イーサネット・ジャンボ・フレーム（最大9キロバイト）に収容されたパケットをハンドルできることが望ましいから、8メモリ・ブロックまで必要となることもある。これは、LUT内の各エントリに対して、ポインタテーブルに7つのポインタを記憶できるようにする必要があるということを意味する（256 x 7=1792 ポインタ）。
IP分割モジュールは、IP分割モジュールコントローラ2594を必要とする。IP分割モジュールコントローラのタスクは、以下の通りである。
・ポインタテーブルおよび受信データ・メモリ・バッファに対するアドレス信号、書き込み信号、および、読み出し信号の生成。
・VSOCKメモリ・アロケータ・モジュール2500に、メモリ・ブロックを要求する（メモリ・アロケータ・モジュールが、配るべき、さらなるメモリ・ブロックを何ら持たない場合には、パケット・アセンブリ・タイマが満了し、それによって、IPパケットが棄てられるのを待たなければならない）。
・IPデータグラムの再構築が完了したことを、TCP層に合図する。
・IPデータグラムの再構築が完了すると、LUT中の全ての使用中のフラグ、および、ポインタテーブル中の有効フラグが、クリアされる。
・タイムアウトの管理
・IPパケットのために受信されたバイトの総数をモニタする。
・入ってくるIPデータ・ストリームから、必要とされるフィールドを抽出する。
このセクションは、IP再構築をハンドルする別の方法を扱う。インターネット・チューナ10Gは、内部プロセッサおよびローIP受信モジュールを用いることによっても、IP再構築をハンドルすることができる。受信されたIPパケットが分割されていると、受信されたIPパケットは、内部プロセッサに渡される。そうすると、内部プロセッサは、そのパケット・フラグメントを完全なIPデータグラムにアセンブルするステップをハンドルする。IPデータグラムが完成すると、それは、ローIP受信モジュールを介してネットワーク・スタックの最後尾に注入し返される。
このセクションは、IP識別フィールド生成アルゴリズムを扱う。内部プロセッサは、IP識別フィールド・スタート・レジスタ2682に任意の16ビット値を書き込むことによって、IP識別フィールドシード値をセットすることができる。IP識別フィールド・ジェネレータ・モジュールは、この16ビット値を受け取り、そして、16ビットのマッピングを遂行して、IP識別フィールドを生成する 2686。次に、IP識別フィールドは、要求モジュールによって用いられる。内部プロセッサ、TCPモジュール、および、ICMPエコー応答ジェネレータ・モジュールは全て、IP識別フィールドを要求できる。
IP識別フィールド・ジェネレータ・モジュール・シード・レジスタは、新しいIP識別フィールドが要求される度毎にインクリメントされる 2684。識別フィールド・ジェネレータ・モジュール・ビット・マッパ2686は、IP識別フィールド・レジスタ値IP_ID_Regを、識別フィールド・ジェネレータ・モジュールバスIP_ID_Outが各要求に対して単純に値をインクリメントしないように再配置する。
以下のセクションは、TCPトランスポート・プロトコルおよびUDPトランスポート・プロトコルの両方をハンドルするTCPモジュール1752を扱う。図27を参照すると、TCPモジュールは、4つのより小さな主要モジュール；ソケット送信インターフェイス2700、TCP送信インターフェイス2704、TCP受信インターフェイス2708、および、ソケット受信インターフェイス2702に分かれる。
以下のリストは、インターネット・チューナ10GアーキテクチャにサポートされているTCP能力について記述している。
・64,000ソケットまでのサポート
・TCPアウト・オブ・オーダ・パケットのサポート
・スロー・スタート・アルゴリズム
・高速再送アルゴリズムおよび高速回復アルゴリズム
・選択可能なNagle（ナグル）アルゴリズム
・スケーリング・ウィンドウサポート
・セレクティブACK（SACK：選択確認応答）サポート
・周回シーケンス番号に対する保護(PAWS) サポート
・タイム・スタンプ・サポート
・キープ・アライブ・タイマ
ソケット制御ブロック(CB)2706には、各接続に特有であり、インターネット・チューナ10Gにおけるバーチャル・ソケット即ちVSOCKアーキテクチャの重要な構成要素である情報、状態およびパラメータのセッティングが含まれている。
このセクションは、TCP受信モジュール2708を扱う。図28は、TCP受信データ・フローを示している。
標準のIPトラフィックにおいては、IPパケットは、64ビットTCP受信データ・パスを介して受信される。IPパケット・ヘッダは、TCPパーザ・モジュール2846に渡され、また、パケット・データは、受信データ・メモリ・コントローラ2848に渡される。分割されたIPパケットにおいては、パケット・データは、メモリ・ブロックを介して渡され、一方、パケット・ヘッダ情報は、標準の受信パスを介して渡される。これは、IP分割からのメモリ・ブロックが、受信データ・メモリ・コントローラによって書き込まれたデータブロックと同じフォーマットを持つことを可能にする。内部プロセッサも、受信データ・メモリ・コントローラを介して受信されたパケット・データを注入するために、メモリ・ブロックを用いる。
受信TCPパーザは、TCPヘッダー情報を構文解析し、パラメータを、VSOCKモジュール2834および受信状態ハンドラ・モジュール2832に渡す責を負っている。受信TCPパーザが、パケット・データに関して何を行うべきか知らない場合には、それは、そのパケット・データを例外ハンドラ・モジュール2838に渡す。さらに、受信TCPパーザ・モジュールは、全てのパケット・データを、例外ハンドラ・モジュールに送るようにプログラムすることもできる。
VSOCKモジュール（他で詳細に記述される）は、ローカルIPアドレス、リモートIPアドレス、および、ポート・アドレスを受け取り、CBにポインタを返す。
NATとIPマスカレーディング・モジュール2842（他で詳細に記述される）は、受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであるかどうかを決定する。受信されたパケットが、NATパケットまたはIPマスカレーディング・パケットであれば、そのNATパケットまたはIPマスカレーディング・パケットが、ロー・パケットとして内部プロセッサに渡される。
受信状態ハンドラ・モジュール（他で詳細に記述される）は、各接続の状態を追跡し、その接続に対応するCBを更新する。
このセクションは、受信TCPパーザ・モジュール2846を扱う。受信TCPパーザ・モジュールは、TCPパケット・ヘッダ情報を、他のTCP受信モジュールに渡す。TCPパーザ・モジュールには、内部プロセッサから、インターネット・チューナ10Gネットワーク・スタックの受信データ・パスにデータを注入するために必要とされる内部プロセッサレジスタが含まれている。内部プロセッサは、メモリ・ブロックをセットアップし、そして、必要な情報を用いて受信TCPパーザ・レジスタをプログラムしなければならない。受信TCPパーザ・モジュールは、TCPヘッダの部分チェックサムを遂行し、受信データ・メモリ・コントローラからの部分チェックサムにこの部分チェックサムを加えて、このチェックサム足し算の結果と、TCPヘッダのチェックサムとを比較する。分割されたIPパケットにおいては、受信TCPパーザ・モジュールが、送られてきた最後のIPパケット・フラグメント中のチェックサムに対して、TCPヘッダのチェックサムをチェックする。
IPモジュールは、IP分割ビットをセットし、適切なパケット・フラグメントのデータ・パスに最初のメモリ・ブロック・ポインタ、最後のメモリ・ブロック・ポインタ、インデックス、および、部分チェックサムを挿入しなければならない。また、TCP受信モジュールは、TCP擬似ヘッダを計算するために、IPプロトコル・フィールドを必要とする。
このセクションは、受信データ・メモリ・コントローラ・モジュール2848を扱う。受信データ・メモリ・コントローラ・モジュールは、IPモジュールとTCPモジュールとの間の64ビットバスから、受信データ・メモリのデータ・メモリ・ブロックにデータを転送する。データ転送の2つのモードがある。データ転送の標準モードが、メモリ・ブロックにTCPデータを記憶するために用いられる。データ転送のロー・モードが、メモリ・ブロックにパケット全体を記憶するために用いられる。データ転送のロー・モードが、NATとIPマスカレーディングのために用いられる。
このセクションは、VSOCKモジュール2834を扱う。VSOCKモジュールは、バーチャル・メモリ管理に等価な最適化されたハード・ワイヤード・ロジックをインプリメントしている。それに匹敵する機能が、プログラム可能なプロセッサ上で走る複雑なソフトウェアによって標準的に実行される。VSOCKモジュールを用いる結果として、インターネット・チューナ10Gが、仮想数(virtual number)のソケットを利用できる。ソケットの数は、オンチップに接続された、あるいは、外部的に接続された、あるいは、オンチップと外部的との両方で接続されたメモリ量によってしか制限されない。ソケットは、常設のコネクションである。コネクションは、以下の3つのステージ：ハーフ・オ−プン(HO)2858、オープン2840、タイム・ウェイト(TW)2850を通る。各コネクションに関する情報は、制御ブロック(CB)に記憶される。
図29は、VSOCKおよび受信状態ハンドラ制御ブロックの探索解決フローを示している。VSOCKモジュール2834は、受信されたパケットから、送信元IPアドレス、送信先IPアドレス、および、ポート・アドレスを渡される。VSOCKモジュールは、受信状態ハンドラ・モジュールに、ソケット・オープンCBポインタまたはTW CBポインタを返す。ロッキング機構が、1つのモジュールがある1つのソケットCB上で動作している間、他のどのモジュールもそのソケットCB上で動作できないことを確実にする。VSOCKは、送信元IPアドレス、送信先IPアドレス、送信元ポート・アドレス、送信先ポート・アドレス上でハッシュを実行する。ハッシュ関数2980は、オープン/TW CBルックアップテーブル(LUT)2986のインデックスとしての役割をする17ビット値を生成する。そのインデックスが付けられた位置のオープン/TW CB LUTエントリが、オープンCB 2988あるいはTW CB 2994に対するポインタを保持する。
HOCBのハンドリングの説明に対しては、受信状態ハンドラ・モジュールについて記述しているセクションを参照されたい。
オープン/TW CB LUTからのポインタは、各々異なるIPアドレスおよびポート・アドレスを持つが、同一のハッシュ番号に帰着する(ハッシュ衝突に起因して)、ゼロ以上のソケットCBのリンクされたリストの最初のCBを指し示す。VSOCKは、受信されたパケットのIPアドレスおよびポート・アドレスと、チェーン状につながれたソケットCB中のエントリとを比較しながら、一致が見つかるか、または、チェーンの終点に到達するまで、このチェーンを下っていく。一致が見つかれば、そのソケットCBに対するポインタが、受信状態ハンドラ・モジュールに渡される。VSOCKモジュールが、このチェーンの終点に到達すれば、それは、エラーである。そのときには、VSOCKモジュールは、TCPパーザ・モジュールにエラーを通知する。
オープン/TWソケットCB LUTエントリに接続されたソケットCBのチェーンには、オープンCBおよびTW CBが、含まれている。オープンCBは、チェーンの上位にある。オープンCBには最大数が存在し、チェーン・セッティング当りの受信TCPの最大オープンCBによって決定される。TW CBは、オープンCBの後にチェーン状につながれている。チェーン当たりのTW CBにも、最大数が存在する。オープンCBは、3ウェイTCPハンドシェークが完成したときに生成され、また、HO CBは、受信状態ハンドラ・モジュールによってオープンCBに移動される。TW CBは、最後のACKがFINシーケンスに送られたときに、受信状態ハンドラ・モジュールによって、オープンCBから生成される。いずれの場合にも、もはや空きがないときには、エラーが、受信状態ハンドラ・モジュールに返される。
オープンCBのためのCBキャッシュが、LUTエントリからのリンクのセット番号と違うオープンCBにインプリメントされる。オープンCBがCBキャッシュ内にあるとき、そのオープンCBに1ビットがセットされる。そのCBキャッシュが、17ビット・ハッシュおよびLUT動作と同時に探索される。
このセクションは、受信状態ハンドラ・モジュール2832を扱う。SYNパケットが受信されると、12ビット・ハッシュが、VSOCKの起動（17ビット・ハッシュを遂行して、オープンCBまたはTW CBを探索する）に加えて作動し、送信先ポートが、認証されたポートリストと照合される。そのポートが、認証されたポートリストに載っており、VSOCK 2834が、一致するオープンCBまたはTW CBを見出さなかった場合には、その12ビット・ハッシュの結果が、HO CBテーブル2858のインデックスとして用いられる。VSOCKが、一致するオープンCBまたはTW CBを見出した場合には、重複CBエラーが、内部プロセッサに送られ、そして、そのSYNパケットは、棄てられる。異なるIPアドレスおよびポート・アドレスを持つHO CBテーブル中のエントリが、既に存在する場合には、受信されたパケット情報が、古い情報に重ね書きされる。この重ね書き動作は、リソースを、SYNパケット・フラッド攻撃あるいはサービス不能(DOS)攻撃に対して保護することを可能にする。重ね書き動作は、また、HO CBテーブルをエージする(age)必要も除去する。1つの側面の結果は、既にSYN/ACKされていたコネクションを、黙って棄てることができるということである。HO CBに対するポインタが、受信状態ハンドラ・モジュールに渡される。ローカル側によってオープンされたコネクション（ローカル側は、SYN/ACKパケットではなく、SYNパケットを受信する）しか、HO CBテーブルに入力されない。
ACKパケットが受信されると、12ビット・ハッシュが作動し、また、VSOCKが起動する。12ビット・ハッシュを介してHO CBにヒットが存在するが、VSOCKが、オープンCBまたはTW CBを見出さず、また、シーケンス番号およびACKパケット番号が有効であれば、そのコネクションの3ウェイ・ハンドシェークが完成し、そして、そのCBが、受信状態ハンドラ・モジュールによってオープンCBテーブルに転送される。VSOCKが、オープンCBまたはTW CBを見出すが、12ビット・ハッシュによるヒットが存在しなければ、そのACKパケットが、重複ACKパケットでないかだけではなく、受信状態ハンドラ・モジュールによって、有効なシーケンス番号およびACK番号でないかチェックされる。
VSOCKモジュールが、正しいソケットCBを見出すと、他の関連する情報が、受信状態ハンドラ・モジュールによって読み出されて、更新される。TCPデータは、大きな（2 キロバイト）メモリ・バッファか、小さな（128バイト）メモリ・バッファかのいずれにでも記憶される。単一のセグメントが、メモリ・バッファ間にまたがることができる。1つのサイズのメモリ・バッファが尽きると、別のサイズのメモリ・バッファが用いられる。データが、与えられたソケットに対して受信されると、ソケット・ハッシュLUTにも、そのData_Availビットがセットされる。
受信状態ハンドラ・モジュールは、スティーブンズによって記述されているようなステートマシンを用いる（スティーブンズのセクション18.6の図18.12を参照のこと）。
受信状態ハンドラ・モジュールが、RSTパケットが必要であると決定すると、それは、RSTパケット・ジェネレータ・モジュール2830に適切なパラメータを配布する。SYN/ACKパケットまたはACKパケットが必要なときには、それはRX-TX FIFO 2860にCBハンドルを送る。
このセクションは、RSTパケット・ジェネレータ・モジュール2830を扱う。図30を参照すると、RSTパケット・ジェネレータ・モジュールは、RSTパケット応答を必要とするパケット中に受信されるMACアドレス、4つのソケット・パラメータ、および、シーケンス番号を受け取って、RSTパケットを組み立てる。それは、最初に、MTXメモリ3014にパケットを構築するためのブロックを要求する。RSTパケットは、常に40バイト長であるから、RSTパケットは、どんなサイズのMTXブロックにもはまる。RSTパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。RSTパケットは、0x0000に固定されたIP識別フィールドを持ち、それらのdon't fragmentビットが、IPヘッダに1とセットされる。
RSTパケット・ジェネレータ・モジュールが、RSTパケットを組み立てた後、RSTパケット・ジェネレータ・モジュールは、RSTパケット送信キューに、RSTパケットを含有しているMTXブロックの開始アドレスを記憶する。RSTパケット送信キューは、m1メモリに組み立てられる 3010。m1メモリの1ブロックが要求され 3016、それが一杯になるまで用いられる。各m1ブロックの最後のエントリが、用いられる次のm1ブロックのアドレスを指し示す。したがって、RSTパケット・キューは、動的に成長することができる。RSTパケット・ジェネレータ・モジュールは、m1メモリに一度に32ビットアクセスする（MTXブロック・アドレスが26ビットでしかないから）。RSTパケット送信キュー長は、m1メモリが利用可能な限り、成長することができる。最早、これ以上のm1メモリが、RSTパケット送信キューに利用可能でなくなれば、RSTパケット・ジェネレータ・モジュールは、受信状態ハンドラ・モジュールからのRSTパケット要求3018を黙って破棄する。RSTパケットの破棄は、送信中にRSTパケットを棄てるのと同等のネットワーク上の効果を持つ。コネクションが全く存在しないから、この状況においてRSTパケットを棄てることは、遂行に深刻な影響を持たない。
RSTパケット送信キューの出力が、TCP送信パケット・スケジューラ・モジュールに渡される。TCP送信パケット・スケジューラ・モジュールが、RSTパケットが送られてしまったことを、RSTパケット・ジェネレータ・モジュールに指示すると、そのRSTパケットのために使用されていたMTXブロックは、解放される。1つのm1メモリ・ブロック中の全てのエントリが送られ、次のm1ブロックに対するリンク・アドレスが読み出されると、そのm1メモリ・ブロックは、解放される。
このセクションは、RX to TX FIFO 2860を扱う。このFIFOは、受信状態ハンドラ・モジュール2832が、受信されたパケットに応えて送る必要があると決定したSYN/ACKパケットおよびACKパケットのキューをつくるに用いられる。受信状態ハンドラ・モジュールは、RX to TX FIFOに、以下の情報を渡す。
・ソケット情報を含有しているCBアドレス（16ビット）
・CBタイプ（2ビット；00 = HO、 01 = オープン、 10 = TW）
・送られるべきパケット（1ビット；0 = SYN/ACK, 1 = ACK）
各RX to TX FIFOエントリは、4バイト長で、雑メモリに記憶される。一般に、RX toTX FIFOは、1,000エントリのFIFO深さを供給する4キロバイトを割り付けられる。RX to TX FIFOの出力は、SYN/ACKパケット・ジェネレータ・モジュールに流れ込む。
このセクションは、SYN/ACKパケット・ジェネレータ・モジュール2841を扱う。SYN/ACKパケット・ジェネレータ・モジュールは、RX to TX FIFO 2860から情報出力を受け取り、そして、指定されたCB（HOCB 2858、オープンCB2840、TW CB2850のいずれか）から別の関連する情報をルックアップして、望みのパケット(SYN/ACKパケット、ACKパケットのいずれか)を組み立てる。RSTパケット・ジェネレータ・モジュール2830のように、SYN/ACKパケット・ジェネレータ・モジュールは、最初に、MTXメモリにパケットを構築するためのブロックを要求する。SYN/ACKパケットおよびACKパケットは、常に40バイト長であるから、そのパケットは、どんなサイズのMTXブロックにもはまる。SYN/ACKパケット・ジェネレータ・モジュールは、常に、利用可能な最小のブロック（標準的に128バイト・ブロック）を要求する。
SYN/ACKパケットまたはACKパケットを組み立てた後、SYN/ACKパケット・ジェネレータ・モジュールは、開始MTXブロック・アドレスを、深さ16のキューに置き、それは、その後、TCP送信パケット・スケジューラ・モジュールに流れ込む。RXto TX FIFOが、プログラム可能な高いウォーター・マークを渡すと、送信パケット・スケジューラ・モジュールが、その状況を通知されて、これらのパケットの送信優先順位を増加させる。
このセクションは、NATとIPマスカレーディングを扱う。NATとIPマスカレーディング・モジュール2842は、VSOCKモジュールと並列に働く。NATとIPマスカレーディング・モジュールは、入ってくるパケットをデコードして、そのパケットが、あらかじめ指定されたNATかIPマスカレーディングのポート範囲にあるかどうか確かめる。そのパケットが、NATかIPマスカレーディングのポート範囲にあれば、信号通知メカニズムを用いて、そのパケットがNATパケットであることをVSOCKブロックに指示する。これが起こると、パケット全体が、受信メモリ・バッファに記憶される。次に、そのパケットが、どこかのポイントでホスト・システムに転送される。ホスト・システムのドライバが、経路制御機能を遂行し、ヘッダパラメータを置き換え、そして、適切なネットワーク・インターフェイスにパケットを送る責を負う。
このセクションは、例外ハンドラ・モジュール2838を扱う。例外ハンドラ・モジュールは、インターネット・チューナ10Gネットワーク・スタックによってハンドルできないパケットを、インターネット・チューナ10G内部プロセッサに送る。
このセクションは、メモリ・ブロック制御回路を扱い、以下の機能について説明する。
リザーブ・メモリ・ブロックメモリ・ブロック制御回路は、1つの小さなメモリ・ブロックおよび1つの大きなメモリ・ブロックを蓄えとして常に使用可能にしておく。この蓄えは、データがメモリ・ブロックに書かれなければならないとき、遅れがほとんど出ないことを保証する。メモリ・ブロック制御回路は、また、できるだけ並列に、ブロック要求とデータ書き込みとを処理する。リザーブ・メモリ・ブロックは、リセットによって初期化される。
初期化とメモリ・ブロックサイズ選択−TCPセグメントまたはUDPセグメントのパラメータが、初期化される。用いられるメモリ・ブロックのサイズは、IPパーザ・モジュールからのTCP長情報およびTCPヘッダ長情報によって決定される。データ・セクションのサイズ（TCPヘッダ長を引いたTCP長）が、小さなメモリ・ブロックにはまれば、そのリザーブ・メモリ・ブロックが、用いられ、そして、他の1つの小さなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。そうでない場合には、蓄えられている大きなメモリ・ブロックが用いられ、そして、他の1つの大きなメモリ・ブロックが要求されて、リザーブ・メモリ・ブロックが補充される。小さなブロックが利用可能でない場合に、大きなブロックが用いられる。しかしながら、大きなブロックが、必要であるが利用可能でない場合、小さなブロックは、用いられない。上記のtcp_in_rd生成を参照されたい。
境界整列したTCPデータのメモリ・ブロックへの書き込み−ヘッダに奇数個のオプション半ワード（各32ビット幅）が存在すれば、TCPパケット内のデータは境界整列し、64ビット境界で開始するデータに帰着する。データが境界整列すると、それがIPから出たときに、それをメモリ・ブロックに直接入れることができる。そのセグメントのための最初のブロックのアドレスが、ステートマシンに送られる。TCPセグメントに残されているデータだけではなく、そのブロックの残りの空間に対するカウントが、維持される。メモリ・ブロックが既に一杯でないかどうかの記録も、維持されていなければならない。TCPセグメントの終端に到達するとき、その前のブロックが一杯であったならば、それは、現在のブロックにリンクされなければならない。さらに、現在のブロック・ヘッダのリンクがクリアされ、また、データのデータ長およびランニング・チェックサムが、そのブロック・ヘッダに書き込まれる。その長さは、ip_in_bytes_val中のビットによって決定されるから、最後の64ビット・ワード中のバイト数の関数である。そのブロックが、セグメントの終端の前で空きを使い果たした場合には、データ長およびランニング・チェックサムが、ブロック・ヘッダに書き込まれ、そして1つのブロックが終了したことを指示するフラグがセットされる。セグメントの残りのデータを用いて、大きいリザーブ・メモリ・ブロックと小さいリザーブ・メモリ・ブロックとのどちらを用いるかが決定される。ブロックサイズが尽きた場合には、前のパラグラフと同じ規則が用いられる。最後のメモリ・ブロックのアドレスが、ステートマシンに送られなければならない。
境界整列していないTCPデータのメモリ・ブロックへの書き込み−セグメントのデータが、境界整列していない場合には（ip_in_data[63:0]は、2つの異なるメモリ・ブロックの書き込みとなるデータを含んでいる）、そのメモリ・ブロックに、IPからの最初のロー32ビット半ワードを、ハイ32ビット半ワードとして書き込むことができるように、初めに、その最初のロー32ビット半ワードを記憶する余分のサイクルが存在しなければならない。IPからの次のバス・サイクルにおけるハイ32ビット半ワードは、記憶された半ワードと同じサイクルにおけるロー32ビット半ワードとして書き込まれる。カウントおよびチェックサム計算も、これをハンドルするために適合されなければならない。そうでなければ、境界整列していないデータは、境界整列しているデータと同じようにハンドルされ、同じ結末状態となる。
UDPデータのメモリ・ブロックへの書き込み−UDPデータは、常に境界整列しており、したがって、UDPデータは、境界整列しているTCPデータと同じようにハンドルされる。同じ結末状態が、当てはまる。
チェックサム計算-チェックサムは、RFC 1071に記載されているように計算される。このブロックでは、チェックサムは、データ上でしか計算されない。パーザ・モジュールが、ヘッダ・チェックサムを計算し、そして、ステートマシンが、2つを組み合わせて、チェックサムエラーを持つパケットを、どう処理すべきか決定する。
このセクションは、ソケット受信モジュール2702を扱う。ソケット受信モジュールは、インターネット・チューナ10Gとホスト・システムとの間の受信されたデータのインターフェイスをハンドルする。
図31を参照すると、その処理は、受信ロジック3140が、ソケット受信DAVビット・マップ・テーブル3142にビットをセットすることから始まる。これは、64K個のソケットの各々に連係して1ビットを持つテーブルである（したがって、このテーブルは、8キロバイトである）。CBの位置を知ることによって、適切なビットが、セットされる。
Socket_DAV照会モジュール3146は、バックグラウンドにおいて、このビット・マップ・テーブルを連続的に走査しているブロックである。それが、セットされているビットに遭遇したとき、それは、対応するCBアドレスを生成し、そして、CB構造3148をチェックして、それが有効なlink_listブロックを含むかどうかを確かめる 3144。このブロックは、64ビットのメモリ・アドレスから構成され、16ビット長である。CBが有効なlink_listブロックを持っていれば、CBアドレスおよびlink_list情報が、DMA準備モジュール3152に渡される（2段パイプラインレジスタペアを介して）。Socket_DAVモジュール3144は、また、その時、CBの対応するビットをクリアする。CBが有効なlink_listブロックを含んでいなければ、そのソケットでデータは利用可能であるが、そのソケットに有効な転送ブロック情報は存在しないということをホストに通知するステータス・メッセージが、そのソケットに対して生成される 3162。この場合には、ビット・マップ・テーブル中の対応するビットは、まだクリアされない。link_listブロックを求めているホストに既にステータス・メッセージを送り出したことが認識されているこの場合には、CBも、更新することができる（これは、同じCBに対するステータス・メッセージを重複して送ることに陥らないために必要である)。
有効なlink_listブロックが存在したときには、次のステップは、CBおよび転送情報が、DMA準備モジュール3152に送られることである。このモジュールは、ソケット・データ・バッファからデータを読み出して、それを、DMAエンジンのための2つのピンポン転送FIFO 3160, 3156のうちの1つに入れる責を負っている。これが完了すると、それは、転送されるべきデータが存在するという要求を、送信DMAエンジン3164に送る。link_list情報も、送信DMAエンジン3164に渡される。
送信DMAエンジンがこの要求を得ると、それは、ホストへのDMA転送を行うことを求められているということを主DMAエンジンに合図する。バスが与えられると、DMAエンジンは、ピンポン・バッファからデータを読み出して、それらを、ホストに送る。転送が完了すると、そのソケットのCBが更新され、そして、データがホストに送られたことを指示するステータス・メッセージが生成される。
ステータス・メッセージ・ジェネレータ3162は、メッセージを実際に生成して、それらを、メモリ3154（1キロバイト）のステータス・メッセージ・ブロックに書き込む責を負っているモジュールである。ステータス・メッセージ生成要求は、送信DMAエンジン、ソケットDAV照会モジュール、あるいは、CPUから来ることができる。
このセクションは、ソケット送信モジュール2700を扱う。次のモジュールは、インターネット・チューナ10Gとホスト・システムとの間にデータを送信するためのインターフェイスをハンドルする。
図32を参照すると、フローが、ホストからのコマンド・ブロック・リストの受け取りで始まる。これは、DMA転送を介して受信され、コマンドリスト3202に置かれる。ここから、ブロックが、コマンド・パーザ・モジュール3204によって抽出されて、解析される。パーザによって認識されたコマンドは実行され、認識されなかったコマンドは、ローカルプロセッサに送られる。
そのコマンドが、データを転送するためのものである場合には、link_list情報が、CBアドレスとともに、コマンド・ブロックから抽出されて、転送キュー3206に置かれる。
受信DMAエンジン・モジュール3208が、このキューからエントリを受け取り、ホストメモリからのデータ転送を実行する。データは、1対のピンポンFIFOバッファ3296, 3298に置かれる。ちょうど受信されたデータに連係するCBアドレスが、ソケット送信データ制御モジュール3294に渡される。
ソケット送信データ制御モジュールは、FIFOからデータを受け取って、それらを、送信ソケット・データ・メモリ3292に置く。それは、malloctxメモリ・アロケータ3200から、ブロック・アドレスを得る。制御モジュールは、また、ソケットCBに、そのソケットの優先順位レベルに関して照会を行う。全てのデータが、データ・バッファに転送されてしまうと、そのモジュールは、そのCBアドレスを、4つの優先順位キュー3280, 3282, 3284, 3286のうちの1つに入れる。ソケット送信制御モジュールは、また、ソケットCB 3290を、新しいデータ送信カウント情報で更新する。
データが、DMA受信FIFOからソケット・データ・メモリに転送されると、ランニング・チェックサムが、そのときに遂行される。そのチェックサムは、ブロックごとに計算される。これは、その後、データが再度通読される必要がないから、送信待ち時間を縮小するのに役立つ。
以下のセクションは、TCP送信モジュール2704を扱う。TCP送信モジュールは、どのソケットが、データ送信のために次に情報を提供されなければならないかを決定し、そして、それにしたがってソケットCBブロックを更新する責を負っている。
図33を参照すると、TCP送信データ・フローは、ソケット照会モジュールが、XMT_DAVビット・テーブルを通過して、送信データに利用可能なビット・セットを持つエントリを捜すことでスタートする。それが、1つのエントリを見つけると、それは、その後、そのエントリを、ソケットのUser_Priorityレベルにしたがって、4つのキュー3330, 3332, 3334, 3336のうちの1つに入れる。優先順位レベル7または6のソケットは、キューリスト3 3336に入れられ、レベル5および4のソケットは、キューリスト2 3334に入れられ、レベル3および2のソケットは、キューリスト1 3332に入れられ、レベル1および0のソケットは、キューリスト0 3330に入れられる。
これらのリストはすべて、パケット・スケジューラ3350に流れ込む。このスケジューラは、スターブしないように優先順位キューからパケットを抜き取る責を負っている。実際のアービトレーション・パターンはプログラム可能で、次のセクションで扱われる。このスケジューラは、また、HOサポートモジュールから生成されるSYN_ACKパケット間およびRSTパケット間のほかに、送信データ・パケット間も調停する。
パケット・スケジューラが、どのパケットを次に送り出すかを決定すると、それは、この情報を、ソケット送信ハンドラ・モジュール3352に配布する。ソケット送信ハンドラ・モジュールは、ソケットCB情報3338, 3342, 3344を読み出し、パケット・ヘッダを生成し、CBを更新し、そして、パケット送信情報を送信キュー3354に渡す。パケット・ヘッダは全て、別個のメモリ・バッファ3340, 3346内で生成され、それは、その後、データ・バッファにプリペンドされる。これは、また、送られるべきデータが、データ・バッファの中央でスタートする場合に当てはまる。この場合には、パケット・ヘッダデータ・バッファからのポイントが、送られるデータの最初のバイトを指す。このモジュールが、同時に別のモジュールが動作させているかもしれない同様のソケットCBを修正してしまわないようなロッキング機構が用いられる。
送信キュー・モジュールは、マスタ送信アービトレータに送られるデータ・パケットのキューをつくる責を負っている。
このセクションは、パケット・スケジューラ・モジュール3350を扱う。パケット・スケジューラ・モジュールは、どのパケットが次に送信されるかを決定する責を負っている。図34は、パケット・スケジューラ・モジュールのブロック図を示している。
そのプロセスは、コンパレータ3482が、現在の状態にあるキュー番号を受け取って、そのキューに、送られるべき何かがあるかどうかを確かめることでスタートする。そのキュー番号は、キューリスト3480のうちの1つ、あるいは、TCP受信パケットを表わすことができる。待機している、そのタイプのパケットが存在すれば、そのエントリは、次に送信されるパケット3484として抜き取られて、スケジュール化される。そのキューに何らのパケットも存在しなければ、状態カウンタがインクリメントされて、次のキュー状態がチェックされる。これは、キュー#が、送信の準備ができているパケットを持っているキューリスト(あるいはTCP受信パケット)と一致するまで、または、状態エントリのエンドビットがセットされるまで、継続する。エンドビットがセットされると、状態カウンタは、0にリセットバックされる。キュー・アービトレーション・シーケンスは、プログラム可能である。アプリケーションが、最初に、Queue_Stateレジスタを0x00にセットし、次に、キュー番号およびエンドビットをQueue _Entryレジスタに書き込むことによって、これをセットすることができる。Queue_Stateレジスタのフラット・ビットとステープビットとのどちらかをアサートすることによってセットすることができる2つの内蔵アービトレーション・シーケンスがある。これらの内蔵シーケンスが、以下に記述される。
・フラット・シーケンス。これは、スケジューラが任意のリセットの後に用いるデフォルト・シーケンス状態である。これは、また、Tシーケンス・レジスタのseq_progフィールドを、01に書き込むことによってセットすることができる。
・ステープ・シーケンス。前もってプログラムされたフラット・シーケンスに換わるものが、ステープ・シーケンスである。このシーケンスは、優先順位の高いキューほど大きな重みを与え、多くの優先順位の高いアプリケーションが同時に走っている場合に有用である。これは、Tシーケンス・レジスタのseq_progフィールドを、10に書き込むことによってセットされる。
このセクションは、ハッシュ・アルゴリズムを扱う。インターネット・チューナ10Gで用いられているハッシュ・アルゴリズムは、ソケットの送信元ポートと送信先ポート、および、送信元IPアドレスと送信先IPアドレスを組み合わせて、単一の17ビット・ハッシュ値を形成する。そのアルゴリズムは、極度に単純化するように設計されており、それによって、ハッシュLUT衝突を最小限にするのに十分な広がりの分布範囲を持つと同時に、単一クロック・サイクル結果を生じる。
このセクションは、ISNアルゴリズムを扱う。インターネット・チューナ10Gで用いられているISNアルゴリズムは、RFC1948に記載されているそれと同様であり、4つのマイクロ秒をベースとしたタイマ、本システムによってセットできる任意のブート（起動）値、および、4つのソケット・パラメータ（送信元と送信先とのポートおよびIPアドレス）を組み込んでいる。
このセクションは、TCP送信データ・バッファ・ヘッダ定義を扱う。TCPデータが記憶される各MTXブロック内に、128ビット・ヘッダが保持される。このヘッダのフォーマットは、以下のように定義される。
最初のビット・ワード
[63:62] tcp_block_size（01= 2K、00 = 128）
[61:59] tcp_block_type（000 = データ、001 = RST）
[58] 有効な次のリンク・フィールド
[57:32] 次のブロック・リンク
[31:28] 使用未定の4ビット
[27:16] ブロック・データ長（ヘッダ・ワードを含まない）
[15:0] tcp_block_checksum
2番目の６４ビット・ワード
[63:32] 使用未定の32ビット
[31:0] ブロックのシーケンス番号
このセクションは、ソケット特定iAPIレジスタ・マップを扱う。これらのレジスタは、与えられたソケットに特定のものである。これらのレジスタは、以下の2通りのうちの1つでアクセスされる。第1の方法は、新しいソケットが初期化されるべきときに用いられる。この場合には、Socket_Controlレジスタ(0x46)のNew_Sckビットが、アサートされる。このビットがアサートされると、TCP_Statレジスタのsck_reg_valビットがディアサートする。次に、システムが、これらのレジスタに新しいソケット情報を書き込むことができる。ソケットを確立するために、システムは、最初に、Socket_Handleレジスタを書き込む。これは、sck_reg_valビットおよびNew_Sckビットをクリアする。ソケットの制御ブロック(CB)情報が検索されると、TCP_Statusレジスタのsck_reg_valビットが、再アサートする。
このセクションは、確立したソケットCB構造を扱う。表2は、確立したソケットに対するメモリのCB構造の全フィールドをリストしている。
表2. 確立されたソケット制御ブロック構造
表3は、HOソケットのためのメモリ内のメインCB構造を定義している。さらに、次のセクションで記述されるアネックスCBが存在する。
表3. ハーフ・オ−プン・ソケットのメインCB構造
表4は、HOソケットのためのメモリ内のアネックスCB構造を定義している。メインCB構造は、前のセクションで定義されている。アネックスHOCBは、メイン・セクションにはまらないオーバーフロー情報を記憶する。各HO CBは、1つのメイン・セクションおよび1つのアネックス・セクションを持っている。
表4. ハーフ・オ−プン・ソケットのアネックスCB構造
表5は、TW状態のソケットのためのメモリ内のCB構造を定義している。
表5. タイム・ウェイト制御ブロック構造
このセクションは、TCP輻輳制御サポートを扱う。インターネット・チューナ10Gは、スロー・スタート、輻輳回避、高速再送、高速回復のアルゴリズムをインプリメントしている。
さらに、そのチューナは、同時に2つ以上のセグメントの時間を測定することをイネーブルにする往復遅延時間(round-trip time)TCPオプションをサポートしている。この特徴は、高バンド域環境のために必要である。
このセクションは、往復遅延時間測定を扱う。インターネット・チューナ10Gは、2通りに往復遅延時間(RTT)を測定することができる。在来の方法では、時間測定は、PSHパケットのためのACKが受信されるときのTCP PSHパケットから受け取られた。時間測定されるパケットのシーケンス番号が、CBの時間測定されるパケットフィールドのシーケンス番号に記憶され、また、そのパケットのタイム・スタンプが、CBの最後の送信フィールドのタイム・スタンプに記憶される。時間測定されるパケットのACKが受信されたとき、現在（そのとき）のタイム・スタンプと記憶されているタイム・スタンプとの間の差が、RTTである。ACKが受信されると、そのソケットCBのRTO[1]ビットがクリアされて、次のパケットの時間が測定できることを指示する。
RTTオプションが、TCPハンドシェークの開始している状態においてネゴシエートされているときには、RTT測定は、受信された各ACKから受け取ることができる。
RTT測定を得るために用いられる方法がどうであっても、その値を受け取って、再送タイムアウト(RTO)値を決定する論理フローは、同じである。
計量化されて平滑化されたRTT、平均偏差、および、RTOはすべて、ソケットCBに記憶される。
このセクションは、スロー・スタート・アルゴリズムを扱う。ネットワーク・スタックは、すべてのTCPコネクションにスロー・スタート・アルゴリズムをサポートしている。このアルゴリズムは、ソケットが最初に確立されるときに1 MSSに初期化される輻輳ウィンドウ・パラメータ(cwnd)を用いる。
スロー・スタート・アルゴリズムは、ソケットが最初に確立されたとき、1つのパケットしか送り出すことができず、そのパケットのACKが受信されるまでは、それ以上のデータを送信することができないことを命令する。ACKが受信されると、cwndは、1 MSSだけ増加する。それは、2つのパケットまで送信されることを可能にする。ACKが受信される毎に、cwndは、1 MSSだけ増加する。
これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。これは、cwndが、ピアから通知されるウィンドウ・サイズを越えるまで継続する。ネットワーク・スタックは、常に、cwndの最小値および通知されるウィンドウを送る。
ネットワーク・スタックが、ICMP送信元喪失メッセージを受け取った場合には、それは、cwndを、1 MSSにリセットし直す。しかしながら、スロー・スタートしきい変数(ssthresh)は、その同じ値に維持される（ssthreshについてのより詳細な情報に関しては次のセクションを参照のこと）。
このセクションは、輻輳回避アルゴリズムを扱う。ネットワーク・スタックは、cwndの最小値およびピアから通知されるウィンドウを送り出し続ける。輻輳回避アルゴリズムは、また、0xFFFFに初期化されるスロー・スタートしきい変数(ssthresh)を用いる。
輻輳が、タイムアウトを介して検出されると、ssthreshは、現在の送信ウィンドウ（cwndの最小値およびピアから通知されるウィンドウ）の2分の1にセットされる。この値が、そのとき、MSSの2倍よりも小さければ、この値が、替わって用いられる。また、cwndは、1 MSSにセットされる。
新しいデータが確認応答されると、cwndは、それがssthreshより大きくなるまで、1 MSSだけ増加する（それで、この名前がついている）。その後は、cwndが、1/cwndだけずつ増加する。これは、輻輳回避フェーズである。
このセクションは、高速再送アルゴリズムおよび高速回復アルゴリズムを扱う。ネットワーク・スタックが、ACKを二重に受信した場合には、それは、パケットが失われたという強い徴候である。n重に重複したパケットが受信されたら、失われたセグメントは、たとえその再送タイマがまだ満了していなかったとしても、直ちに再送される。これが、高速再送アルゴリズムである。再送信が起きる前に受信されなければならない重複ACKの数は、TCP_Dup_ACKレジスタ(0x36)を介してセットでき、3つまで不履行とされる。
指定された数の重複ACKパケットが受信されると、ssthreshは、輻輳回避アルゴリズムの場合がそうであったように、この場合にも、現在のウィンドウ・サイズの2分の1にセットされるが、このとき、cwndは、ssthresh + (3 * MSS)にセットされる。これは、重複ACKパケットを受信した後、スロー・スタート・アルゴリズムではなく、輻輳回避アルゴリズムに戻ることを確実にする。他の重複ACKパケットが受信されるごとに、cwndは、1 MSSずつ増加する。これが、高速回復アルゴリズムである。
新しいデータに対するACKパケットが受信されると、cwndは、ssthreshにセットされる。
このセクションは、どのようにMSSオプションが導出されるかを概説する。TCP処置をイネーブルにするに先立って、ホスト・システムは、以下のパラメータおよびセッティングをセットアップしなければならない。
・レジスタ0x1A4A-0x1A4Bで用いられるデフォルト非ローカルMSS
・レジスタ0x1A4C-0x1A4Dで用いられるデフォルトローカルMSS
このセクションは、MSS選択アルゴリズムを扱う。任意のコネクションに用いるために、2つのMSS値のどちらかを選択する時、TCPエンジン・モジュールは、IPルータ・モジュール照会を行う。送信先経路がゲートウェイを通る場合には、非ローカルMSSが用いられる。
このセクションは、サポートされているTCPオプションおよびそれらのフォーマットを概説する。サポートされている4つのオプションは、次の通りである。
・MSS
・ウィンドウ・スケーリング
・タイム・スタンプ
SACK
このセクションは、MSSオプションを扱う。このオプションは、常に組み入れられている。用いられるMSS値は、前のセクションで説明されたアルゴリズムを通じて決定される。このオプションのフォーマットは、以下の通りである。
このセクションは、ウィンドウ・スケーリング・オプションを扱う。ウィンドウ・スケーリング・オプションは、Sl_Win_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットに常に組み入れられる。それは、そのオプションが、SYN/ACKパケット応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットに組み入れられない。そのオプションのフォーマットは、以下の通りである。そのオプションが4バイト境界上にならぶように、1つのNOPバイトが、常に、それに先行することに注意されたい。
このセクションは、タイム・スタンプ・オプションを扱う。このオプションは、SYNパケットに常に組み入れられ、また、そのオプションが、SYN/ACK応答を生成したSYNパケットに含まれていた場合しか、SYN/ACKパケットには組み入れられない。それは、そのオプションが4バイト境界上にならぶように、2つのNOPバイトに常に先行されることに注意してされたい。タイム・スタンプ・オプションのフォーマットは、以下の通りである。
このセクションは、選択ACK(SACK)オプションを扱う。このオプションは、SACK_EnビットがTCP_Controlレジスタにセットされている限り、SYNパケットおよびSYN/ACKパケットに常に組み入れられる。SACKは、2つの相異なるTCPオプション種類を用いる。1つは、SYNパケットで用いられ、他の1つは、データ・パケットで用いられる。それらのオプションのフォーマットが、以下に示される。
SACK可能
SACKオプション
SACKオプションは、1穴報告(one-hole reporting)に制限されている。
以下のセクションは、IPルータ・モジュールを扱う。IPルータ・モジュールの特徴は、以下の通りである。
・デフォルトルーティング（経路制御）能力を備える。
・複数のホストIPアドレスに対するルーティングを備える。
・ホスト指定経路およびネットワーク指定経路を供給する。
・ICMPがリダイレクトした後、動的に経路を更新する。
・IPブロードキャスト（リミテッド・ブロードキャスト、サブネット・ディレクテッド・ブロードキャストおよびネットワーク・ディレクテッド・ブロードキャスト）アドレスをハンドルする。
・IPループ・バック・アドレスをハンドルする。
・IPマルチ・キャスト・アドレスをハンドルする。
このセクションは、IPルータ・モジュールがどのように経路を要求するか説明する。図35に関すると、ローカル・ホスト・システムが、IPパケットを送信したいとき、それは、そのパケットをどこに送るべきであるか−そのローカル・エリア・ネットワーク上の他のホストにか、外部ネットワークにか、それとも、そのローカル・ホスト・システム自体に戻すのかのいずれかに−決めなければならない。出ていくIPパケットを適切なホストに宛てるのが、IPルータ・モジュールのタスクである。
送信モジュールが、経路を要求するとき、その送信モジュールは、パケットの送信先IPアドレスをIPルータに渡す。次に、IPルータは、ターゲットとされたIPアドレスを、IP経路リスト3520に記憶されている送信先のリストと比較する。一致が見出されると、IPルータは、適切なイーサネット・アドレスに解決しようとする。そのルータは、この解決を、ARPキャッシュ中の送信先IPアドレスに対するARPルックアップを要求することによって遂行する。送信先イーサネット・アドレスが解決されると、それは、このイーサネット・アドレスを、出ていくイーサネット・フレームの送信先として用いる送信モジュールに渡される。
経路情報は、3つの別々の構成要素：デフォルト経路レジスタ3522、カスタム経路リスト3520、アンルータブル・アドレス・キャッシュ3526、によって供給される。これらの構成要素は全て、経路要求が出されたとき、同時に照会される。
このセクションは、IPルータ・モジュールがどのようにデフォルト経路を決定するかを説明する。パケット送信先は、ローカルか外部かのどちらかであるとして記述される。ローカル送信先は、送信しているホストと同じローカル・エリア・ネットワークに配されている。外部送信先は、送信しているホストのローカル・エリア・ネットワークと別個のネットワークに属している。
出ていくパケットの送信先IPアドレスが、ローカル・エリア・ネットワークに配されたホストに属することが見出されると、IPルータは、ARPを用いて、送信先IPアドレスを、その対応するイーサネット・アドレスに解決しようとする。送信先IPアドレスが、外部ネットワークに属すると決定されると、IPルータは、出ていくパケットを、その外部ネットワークに伝えるために、どのゲートウエイ・ホストを用いるべきであるか決めなければならない。ゲートウエイ・ホストが選択されれば、出ていくIPパケットは、それらの送信先イーサネット・アドレスとして、そのゲートウエイ・ホストのイーサネット・アドレスを用いる。IPルータ・モジュールが、パケットの送信先IPアドレスに対する経路を見出すことができない場合には、そのパケットは、デフォルト経路によって指定されるゲートウエイ・ホストを用いなければならない。デフォルト経路は、他のどんな経路も、与えられた送信先IPアドレスに対して見出すことができないときしか、用いられない。
ARPキャッシュへのアクセス数を最小限にするために、デフォルト経路がセットされたとき、IPルータ・モジュールは、デフォルト・ゲートウェイのイーサネット・アドレスをキャッシュする。デフォルト・ゲートウェイのイーサネット・アドレスは、最大で、エントリがARPキャッシュに動的にキャッシュされていることを許される時間に等しい時間量の間、キャッシュされる。
このセクションは、IPルータ・モジュールが、どのようにブロードキャスト送信先とマルチ・キャスト送信先とをハンドルするかを説明する。送信先IPアドレスが、ブロードキャストIPアドレスまたはマルチ・キャストIPアドレスである場合には、ARPルックアップは、必要ではない。その代りに、IPルータ・モジュールは、IPアドレスのタイプに依存して、動的に送信先イーサネット・アドレスを生成する。IPブロードキャスト・アドレス(255.255.255.255)にセットされた送信先IPアドレスを持つパケットは、イーサネット・ブロードキャスト・アドレス(FF:FF: FF:FF)に送られる。マルチ・キャストIPアドレス(224.x.x.x)にセットされた送信先IPアドレスを持つパケットは、そのマルチ・キャストIPアドレスから計算される送信先イーサネット・アドレスを持つ。
このセクションは、IPルータ・モジュールがどのように静的経路を扱うかを説明する。デフォルト経路に加えて、IPルータ・モジュールは、送信先IPアドレスを、特定のイーサネット・インターフェイスあるいはゲートウエイ・ホストにマップするために、静的経路を生ぜしめることを可能にする。IP経路エントリには、送信先IPアドレス、ネットマスク、および、ゲートウェイIPアドレスが含まれる。ネットマスクは、一連の送信先IPアドレスを、IP経路エントリの内部に記憶された送信先IPアドレスと一致させるために用いられる。ネットマスクは、また、特定のホストの経路とネットワークの経路の区別を可能にする。ゲートウェイIPアドレスは、ARPを介して送信先イーサネット・アドレスを解決するときに用いられる。
IP経路リストには、多数の経路を持つことが可能であるから、IP経路エントリは、動的に割り付けられたm1メモリに記憶される。各IP経路エントリは、128ビットを用いる。各エントリの最後の32ビットは、何らのデータも記憶しないで、64ビット境界に沿ってIP経路エントリを整列させるためのパディングとして用いられる。
各IP経路エントリのフォーマットは、以下の通りである。
IP経路エントリ・フォーマット
IP経路リストは、ソートされたリンクリストとしてインプリメントされる。IP経路が、IP経路リストに加えられると、それらは、最上位に特定的なIP経路がIP経路リストの最前に現われ、最下位に特定的なIP経路がIP経路リストの最後になるように、それらのネットマスクにしたがって順序づけられる。IP経路エントリの経路ポインタ・フィールドには、次のIP経路エントリをm1メモリで見出すことができるm1メモリ・アドレスが含まれている。経路ポインタ・フィールドの最初の（最上位の）ビットは、そのm1メモリ・アドレスが有効で、かつ、現在の経路に続く経路が存在するかどうかを決定するためのフラグとして用いられる。経路ポインタ・フィールドのポインタ有効ビットが、アサートされていなければ、IP経路リストに、それ以上のIP経路が全く存在せず、IP経路リストの終端に達している。
送信先IPアドレスがブロードキャストIPアドレスまたはマルチ・キャストIPアドレスであると決定されない場合には、そのIP経路リストが、一致するIP経路エントリを求めて探索される。一致が、IP経路リストで見つからない場合には、デフォルト経路が、ゲートウェイ情報を供給するために用いられる。
IPルータ・モジュールは、また、複数の物理インターフェイスおよびループ・バックインターフェイスの使用を可能にする。IP経路エントリのインターフェイス識別フィールドを用いて、IPルータは、出ていくパケットを、インターネット・チューナ10Gの特定のイーサネット・インターフェイスに向けることができる。インターフェイス識別フィールドは、また、ARP要求を、適切なイーサネット・インターフェイスに向けるためにも使用される。
このセクションは、IPルータ・モジュールが、どのようにループ・バック・アドレスをハンドルするかを説明する。送信先IPアドレスが、ローカル・ホスト・システムのIPアドレスの1つ即ちループ・バック・アドレス(127.x.x.x)と同じであれば、出ていくパケットは、ホスト・システムにフィードバックされることになっている。ループ・バック送信先の経路は、静的経路リストに記憶されている。ホスト・システムに割り当てられないIPアドレスも、ループ・バック・アドレスとして構成してもよい。このローカルリダイレクションをイネーブルにするために、インターフェイス識別は、0x0000(ループ・バック)にセットされなければならない。そうでなければ、インターフェイス識別は、イーサネット・インターフェイス(0x0001, 0x0002など)のうちの1つにセットされなければならない。
このセクションは、IPルータ・モジュールがどのように経路を作り出すかを説明する。新しいIP経路は、内部プロセッサから来ることができる。内部プロセッサによって作り出されるIP経路は、それらが、内部プロセッサによって削除されるまでテーブルに存続しているということを意味する、静的経路である。内部プロセッサは、IPルータ・モジュールのレジスタインターフェイスを介して経路を加え、また、除去する。
IPパケットが、間違ったゲートウエイ・ホストに送られているとき、ICMPリダイレクト・メッセージが、送信される。ICMPリダイレクト・メッセージは、普通、間違った経路のIPパケットに対して使用するために、正しいゲートウエイ・ホストの情報を含んでいる。ICMPリダイレクト・メッセージが受信されると、そのメッセージは、システム・インターフェイスによって処理される。IPルータのレジスタインターフェイスを介して経路リストを更新することは、システム・インターフェイスの責任であり、そのときに存在しているIP経路を更新し、あるいは、新しいIP経路を作り出す。
このセクションは、IPルータ・モジュールが、どのようにローカル・ネットワーク上のホストに対するルーティングをハンドルするかを説明する。ローカルイーサネットネットワーク上の他のホストにパケットを直接発送するために、インターネット・チューナ10GのサブネットマスクによってIP経路が、作り出されなければならない。この経路に対するゲートウェイとして、もう1つのホストを指定する代わりに、ゲートウェイIPアドレスは、この経路が、ローカル・ネットワークを通る直接接続に帰することを指示する0.0.0.0にセットされなければならない。
このセクションは、IPルータ・モジュールが、どのように経路要求信号制御をハンドルするかを説明する。各送信モジュールは、IPルータ内に、経路要求のためのそれ自身のインターフェイスを持っている。
図36は、経路を要求し、また、受信するために用いられる信号制御を図解している。
モジュールが、経路を要求しているとき、それは、経路要求信号(例えば、TCP_Route_Req)をアサートし、そして、ルータに送信先IPアドレス(TCP_Trgt_IP)を供給する。ルータが、経路を見出すと、それは、経路完了信号をアサートし、そして、送信先イーサネット・アドレスを出力する。経路が成功のうちに見出されると、route_valid信号が、それを送信モジュールに指示するために用いられる。経路完了信号がアサートされたときに、それがアサートされると、有効な経路が、見出されたことになる。route_validビットがアサートされないと、それは、ルーティングが、失敗だったことを意味する。これは、デフォルト・ルートやゲートウェイをダウンさせないで、かつ、ARP要求に応えないような、いくつかの原因によるものであり得る。経路失敗の場合において、その後再度、経路を待ち受け、そして、解決しようとする、あるいは、現在の接続試みを終了させることは、送信モジュールの責任である。
経路が、ホストまたはゲートウェイのイーサネット・アドレスを解決するために、ARPルックアップを必要とする場合、そのイーサネット・アドレスがARPキャッシュ内に見出されなければ、遅延を起こすことは可能である。キャッシュミスがあったとき、そのキャッシュは、IPルータに通知する。その後、ルータは、キャッシュミスが生じたことを、適切な送信器(IP TX, TCP TX, ローTX)に合図する。この時点で、送信モジュールは、現在の接続を遅らせ、キュー中の次の接続を出し、別の経路を要求することを選ぶことができる。送信構成要素が、その経路要求を取り消したとしても、ARPルックアップは継続し、そのゲートウェイが、アクティブであれば、そのイーサネット・アドレスは、後の使用を可能にするために、ARPキャッシュに加えられる。注：IPルータは、複数の出ていくARP要求を持つことができる。
このセクションは、IPルータ・モジュールが、どのように個々の経路の表示をハンドルするかを説明する。静的経路を作り出した後、ユーザは、経路テーブルに記憶されたエントリを、2通りに読み返すことができる。ユーザが、与えられた経路のターゲットIPアドレスを知っていれば、Show_Routeコマンドコードを用いて、その経路のネットマスクおよびゲートウェイを表示することができる。
経路テーブル内の全てのエントリを表示するために、Show_Indexコマンドを用いることができる。Route_Indexレジスタを用いて、システム・インターフェイスは、特定性の順に経路にアクセスすることができる。特定性の大きい（ホスト）経路が、最初に表示され、特定性の小さい（ネットワーク）経路が、その後に続く。例えば、route_index 0x0001を備えたIP経路エントリは、IP経路リストで最も特定性の大きい経路である。注：デフォルトは、インデックス0(0x0000)に記憶される。経路が、成功のうちに見出されると、Route_Foundレジスタが、アサートされ、そして、経路データが、Route_Trgtレジスタ、Route_Maskレジスタ、および、Route_Gwレジスタに記憶される。
このセクションは、IPルータ・モジュールが、どのようにして解決不能の送信先のキャッシングをハンドルするかを説明する。IPルータ・モジュールが、送信先ホストまたは送信先ゲートウェイに対するイーサネット・アドレスを解決することができないとき、そのIPルータ・モジュールは、その送信先IPアドレスを20秒間キャッシュしておく。その時間の間に、IPルータ・モジュールが、それらのキャッシュされている解決不能の送信先のうちの1つに対する要求を受信すると、そのIPルータ・モジュールは、直ちに、経路を要求しているモジュールに、経路失敗で応答する。この解決不能の送信先のキャッシングは、ARPキャッシュ・エントリが記憶されている共有m1メモリへのアクセス回数を減少させるためのものである。解決不能の送信先のキャッシングは、また、冗長なARP要求を回避するのに役立つ。解決されないアドレスをキャッシュできる時間量は、Unres_Cache_Timeレジスタを介して、ユーザが構成可能である。
以下のセクションは、システム例外ハンドラ・モジュール1768を扱う。図37を参照すると、システム例外ハンドラ・モジュールは、インターネット・チューナ10Gの専用の処理ハードウェアが直接ハンドルすることができないデータが存在するときにはいつでも、呼び出される。このデータは、未知のイーサネット・タイプパケット、IGMPパケット、TCPオプション、あるいは、IPオプションなどであり得る。これらの場合の各々において、初期パーザが、例外の場合を検知したときに、このモジュールをイネーブルにする。その後、システム例外ハンドラ・モジュールは、データを記憶し 3742, 3746、ハンドルされるべき例外データが存在することをシステムに通信し 3744、そして、そのデータをホスト・システムに渡す 3740、責を負う。
このセクションは、システム・インターフェイス・モジュールを扱う。システム・インターフェイス・モジュールは、システム・コントローラとインターフェイス接続している。システムに利用可能な何らかの例外データが存在するとき、それは、割り込みを介してシステムに信号で知らせる。システム・インターフェイスは、利用可能な例外データのタイプを、利用可能なデータ量とともに指示する。次に、システム・コントローラは、このモジュールを通して、そのデータを読み出すこともできるし、あるいは、このモジュールから、そのデータに対するメモリ・ポインタを得ることもできる。後者の場合には、次いで、システム・コントローラは、そのデータを直接読み出すことができる。この場合、システムは、メモリ・バッファを自由に使えるようにするために、全てのデータを読み出したときに、例外ハンドラに通信しなければならない。
このセクションは、Mem_Blockリクエスタを扱う。このモジュールは、メモリ・アロケータにメモリ・ブロックを要求する責を負っている。それは、また、メモリアクセス中のアドレス生成もハンドルする。ブロックが自由に使えるようになると、このモジュールは、また、それらのブロックをメモリ・アロケータに戻して渡す責も負う。このモジュールは、任意の与えられた時間に利用可能な、少なくとも1つの予備メモリ・ブロックを常に持っている。
このセクションは、制御信号ジェネレータ・モジュールを扱う。制御信号ジェネレータ・モジュールは、メモリ・コントローラ・モジュールとインターフェイス接続して、メモリ制御信号を生成する責を負っている。このインターフェイスは、要求/授与ハンドシェークプロトコルを用いる。
全ての入力信号および出力信号は、クロックの立ち上がりエッジに同期している。
これは、メモリ書き込みを制御するためのFIFOである。このFIFOは、16ワード深さ（即ち、16 x 64 ビット)である。
以下のセクションは、IPモジュール、ARPキャッシュ、経路テーブル、および、内部プロセッサのために用いられるメモリ・アロケータ・モジュールを詳述する。メモリ・アロケータ・モジュールは、最初にm1メモリを個別のブロックに分け、それらを要求に割り付け、そして、自由に使えるようになったブロックをスタックに戻す責を負っている。メモリ・アロケータ・モジュールは、その動作を始めるに先立って、2つのパラメータを入力される必要がある。それらは、m1メモリ・ブロックの総サイズ、および、各メモリ・ブロックのサイズである。1つのメモリサイズしか、メモリ・アロケータ・モジュールのこのインプリメンテーションにはサポートされていない。
それら2つの必要とされるパラメータが入力された後、システムは、m1_Controlレジスタのm1_Enableビットをアサートする。これが起こると、メモリ・アロケータ・モジュールは、m1メモリ・ブロックのトップからスタートして、ブロック・アドレスを書き込み始める。例えば、m1メモリ・ブロックが、総計4キロバイト深さであり、 ブロックサイズが、512バイトであれば、m1メモリ・マップは、図38に示されるようになる。
m1ブロック・アドレスのm1アドレス位置当り、4つのアドレスが、保持される。メモリに開始ブロック・アドレスを保持することに加えて、メモリ・アロケータ・モジュールは、また、16-エントリキャッシュも含有する。初期化に際して、最初の16アドレスが、キャッシュに保持される。ブロックが要求されたとき、それらは、キャッシュから受け取られる。キャッシュ数が0に達したとき、4つのアドレス（1メモリ読み出し）が、メモリから読み出される。さらに、キャッシュが、アドレスで一杯になったときには常に、4つのアドレスが、メモリに書き戻される（これは、メモリ・アロケータ・モジュールが、一番初めにm1メモリからアドレスを読み出した後でしか作用しない）。
このセクションは、TX, RX, CBメモリ・アロケータ・モジュールを扱う。これらのメモリ・アロケータ・モジュールは、ソケット送信メモリ(malloctx)、ソケット受信メモリ(mallocrx)、および、CB(malloccb)メモリに対して用いられるメモリ・アロケータである。これらのメモリ・アロケータ・モジュールは、メモリ・ブロックを要求に割り付け、自由に使えるようになったブロックをスタックに戻し、そして、メモリの使用を調停する責を負っている。
メモリ・アロケータ・モジュールは、動作を開始するに先立って、いくつかのパラメータを入力される必要がある。これらのパラメータは、MPメモリ空間内の開始アドレス・ポインタ位置および終了アドレス・ポインタ位置、および、各メモリ空間内の利用可能な各ブロックを表わすビット・マップである。2つのサイズのブロックが、ソケット・データ・メモリに利用可能である：128バイトおよび2キロバイト。CBメモリは、128バイトに固定したブロックを持っている。全てのアロケータは、また、ブロック・アドレス（各メモリサイズに対する）に対して8-エントリキャッシュを利用する。
これらのパラメータが入力された後、システムは、制御レジスタにイネーブル・ビットをアサートする。そうすると、アロケータは、メモリ・ブロックの割り付け、および、割り付けの解放を開始することができる。
このセクションは、TX SDRAMインターフェイスおよびデータ・フローを扱う。コアロジックのアービトレータは、TX SDRAMへの読み出しサイクルか、書き込みサイクルか、どちらかに決める。1つのサイクルが始まれば、それは、完結させられる。TX SDRAMに書き込まれているデータは、PCIバスとデータ・メモリとの間にある128 x 128ビットFIFOペアから来る。TXデータ・メモリから読み出されたデータが、MACモジュールとインターフェイス接続している64 x 128ビットFIFOに入れられる。
このセクションは、512キロバイト雑メモリバンクを詳述する。雑メモリバンクは、以下にリストされた目的のために使用される。それらの特徴は、他のところで詳細に記述されている。
・ハーフ・オ−プンCB（メイン）
・ハーフ・オ−プンCB（アネックス）
・TCPポート許可テーブル
・UDPポート許可テーブル
・送信元ポート使用テーブル
・タイム・ウェイトCB割り付けテーブル
・確立されたCB割り付けテーブル
・TXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・RXメモリ・ブロック割り付けテーブル（128バイト・ブロックと2キロバイト・ブロックとの両方に対する）
・TCP RXからTCP TXへのパケットに対するFIFO
・ソケット・データ使用可能ビット・マップ
・サーバ・ポート情報
このセクションは、雑メモリの編成および性能を扱う。図39を参照すると、この雑メモリは、物理的に256k x 16ビットとして編成されているが、この雑メモリを用いるモジュールの大部分は、この雑メモリを、あたかも、それが512k x 8ビットメモリであるかのように載せる。これは、全ての許可テーブルおよびアロケーションテーブルが、一度に1バイトしかメモリにアクセスする必要がないからである。HO CBデータ・パス、および、TCP RXからTCP TXに対するFIFO、および、サーバ・ポート情報は、フル16ビット・データ・パスを利用するリソースである。16ビット・データ・パスの必要性は、非常にわずかのクロック・サイクル内でデータにアクセスしなければならないHO CBから生じる。雑メモリは、単一サイクルメモリを用いてインプリメントされなければならない。性能要求は高くないが、アービトレーション・オーバヘッドのために、アクセス時間は、できるだけ短く保たれるべきである（ここでも、HO CBのために）。
・HOCB（メイン）3902。これらは、HO TCPコネクションのCBである。各CBは、サイズとして32バイトであり、合計4,000のCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4キロバイト x 32 = 128キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。
・HOCB（アネックス）3984。これらは、HO TCPコネクションのCBで、CBのメイン部にはまらなかった、補足情報を含んでいる。各アネックスCBは、サイズとして16バイトであり、合計4,000のアネックスCBがある。したがって、それらのHO CBに必要なバイトの合計数は、4,000 x 16バイト = 64キロバイトである。このリソースは、フル16ビット・データ・バスを用いる。
・TCPポート許可テーブル3900。このテーブルは、どのTCPポートが、コネクションをを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。
・UDPポート許可テーブル3998。このテーブルは、どのUDPポートが、コネクションを受け取ることを許可されるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8 キロバイトを用いる。
・送信元ポート使用テーブル3996。このテーブルは、どのポート番号が、ローカルに着手されるコネクションに用いられる送信元ポートに利用可能であるかを追跡する。64,000の可能なポートの各々の1ビットが、保持されている。したがって、このテーブルは、64,000ビット/8 = 8キロバイトを用いる。
・TWCB割り付けテーブル3988。これは、TW CBのための割り付けテーブルである。32,000のTW CBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、32,000ビット/8 = 4 キロバイトを用いる。このテーブルは、フル16ビット・データ・バスを用いる。
・確立されたCB割り付けテーブル3994。これは、確立されたCBのための割り付けテーブルである。64,000のCBの各々に対して1ビットが、保持されている。したがって、この割り付けテーブルは、64,000ビット/8 = 8キロバイトを用いる。
・TXソケット・データ・バッファブロック割リ付けテーブル3982。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる送信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。
・RXソケット・データ・バッファブロック割リ付けテーブル3980。このテーブルは、2キロバイト・ブロック割リ付けテーブルと128バイトブロック割り付けテーブルとから構成され、動的に割り付けられる受信データ・バッファ・メモリに使用される。各タイプのブロック数は、構成可変であるが、組み合わされた両方の割り付けテーブルのサイズは、72 キロバイトに固定される。これには、最大で475,000の128バイト・ブロックを充てることが許可されている。このレベルで、2キロバイト・ブロックの数は、98,000である。
・TCPRX FIFO 3990。このFIFOは、TCP受信ロジックからTCP送信ロジックへのパケット送信要求を追跡するために用いられる。各FIFOエントリは、いくつかの制御フラグおよび1つのCBアドレスから構成され、合計4バイト(4つのフラグ、26ビットのアドレス、および、未使用の2ビット)である。このFIFOは、1024ワード深さで、したがって、1024 x 4バイト = 4キロバイトを必要とする。
・ソケット・データ利用可能ビット・マップ 3992。このビット・マップは、64,000のソケットのどれが、ホスト・システムに送られる準備ができているデータを持っているかを表わす。ソケットの各々に対して1ビットが、保持されている。したがって、このビット・マップは、64,000ビット/8 = 8 キロバイトを必要とする。
・サーバ・ポート情報3986。このデータベースは、待機状態にオープンされているTCPポートのパラメータ情報を記憶するために用いられる。それらのサーバ・ポートは、それらがオープンされるまで、それらに連係するCBを持たないから、ポートに特定のパラメータが、このエリアに保持される。各ポートエントリは、2バイトから構成され、64,000の可能なポートがある。したがって、このデータベースは、64,000 x 2バイト = 128 キロバイトを必要とする。
このセクションは、雑メモリ・マップを扱う。雑メモリに使用されるメモリ・マップは、構成可変である。
このセクションは、雑メモリ（即ちmiscmem）アービトレーションスキームを扱う。雑メモリ・アロケータは、さまざまな送信元からメモリ要求を受け取り、メモリ・ブロックへのアクセスについて、それらのメモリ要求間の調停をする。すべての要求のうち、HO CBへのアクセスに対するメモリサイクルが、最優先順位を与えられる。他のすべての送信元は、ラウンドロビン態様で、等しい優先順位に調停される。
雑メモリアービトレータをアクティブにするのに先立って、内部プロセッサが初期化する必要のあることは、ほとんどない。デフォルト・メモリ・マップが、用いられるべきときには、内部プロセッサは、MiscMem_ControlレジスタのMM_Enableビットをアサートすることによって、アービトレータを簡単にイネーブルにすることができる。
非デフォルト・メモリ・マップが、用いられるべきときには、基準アドレス・レジスタはすべて、アービトレータをイネーブルにするに先立って、初期化されなければならない。プログラムされた基準アドレスが、何らの重複するメモリエリアを引き起こさないことを保証するのは、ソフトウェアの責任である。これをチェックするどんなハードウェアも、用意されない。
内部プロセッサは、雑メモリ内のどの位置にもアクセスすることができる。最初に、MM_CPU_Addレジスタ(0x1870―0x1872)内の1つのアドレスにプログラムし、次に、MM_CPU_Dataレジスタ(0x1874)に1バイトを読み出すか、または、書き込むことによって、これがなされる。アドレス・レジスタは、データ・レジスタがアクセスされる度毎に、自動的にインクリメントする。
このセクションは、シリアル・ポート、SPI、および、テスト・インターフェイスを扱う。AUXシリアル・ポートは全て、標準の8ビット・シリアル・データ・フォーマットを用いる。シリアル・ポートは、16バイト受信FIFOおよびハードウェアフローの制御をサポートする。内部プロセッサが、全てのポート上で用いられるボーレートを制御し、それによって、全てのポートが、独立したボーレートをサポートすることができる。シリアル・ポート・テストモードは、内部プロセッサのテストモード・レジスタ(0x0000f0)にser_tstビットをセットすることにより、イネーブルとされる。オンチップ・プロトコル・プロセッサが、スレーブ（従）SPIデバイスを制御することができるように、マスター（主）SPIポートが設けられる。
このセクションは、システムで用いられる割り込みコントローラ(INTC) 1688の概要を提供する。INTCは、全システム割り込みを集めて、それらを、内部プロセッサに流し込む。各割り込み元を、内部プロセッサ上でnFIQ割り込みかnIRQ割り込みかの一方に独立に導くことができる。
このセクションは、インターネット・チューナ10Gで用いられる多目的タイマおよび監視タイマの概要を提供する。前のタイマと縦続接続されていてもよいし、あるいは、独立に用いられてもよい、8つの多目的32ビットタイマが、設けられる。全てのタイマが、単発モードか、あるいは、ループ（繰り返し）モードで動作することができる。さらに、メインのコアクロックを、それが各々のタイマによって用いられるのに先だって、分周できるクロック・プレスケーラが、設けられる。これは、異なるコアクロック周波数の変化を最小にする。
このセクションは、コマンド・ブロック構造を詳述する。ホスト・システムは、コマンド・ブロックを用いて、コマンドをインターネット・チューナ10Gに渡す。コマンドは、ステータスを要求したり、ソケットを制御したり、データを送ったり、ホスト状態を報告したりすることを、含むことができる。コマンド・ブロックは、通例、DMAを用いてホスト・システムから転送される。インターネット・チューナ10Gが、コマンドを受信すると、それらのコマンドは、コマンドリストに入れられる。次に、コマンドは、コマンド・パーザ・モジュールによって、一度に1つ、構文解析される。次いで、コマンド・パーザ・モジュールが理解したコマンド・ブロックのどれをも、コマンド・パーザ・モジュールが、実行する。コマンド・パーザ・モジュールが、どのようにデコードするのか分からないコマンド・ブロックのどれをも、コマンド・パーザ・モジュールは、内部プロセッサに送る。
コマンド・ブロックは、長さが可変である。コマンドのタイプにかかわらず、各コマンド・ブロックは、偶数のバイトから構成されなければならない。奇数バイト・コマンド・ブロックには全て、パディング・バイトが、用いられなければならない。
ホストとインターネット・チューナ10Gとの間にコマンド・ブロック通信をインプリメントするときには、特別の注意を払わなくてはならない。コマンド・ブロックは、ホストメモリ内に循環キューで作り出される。その後、周期的に、あるいは、ホストの手引きによって、これらのコマンド・ブロックは、DMAを用いてインターネット・チューナ10Gに転送される。ホスト・システムとインターネット・チューナ10Gとの間の信頼できる通信を確実にするために、いくつかの手続きが続く必要がある。
このセクションは、受信コマンド・ブロックについて説明し、また、内部プロセッサが、ホスト・システムからコマンド・ブロックを受け取るために通過しなければならないステップの要点を述べる。
・内部プロセッサは、受け取ったコマンド・ブロックをハードウェアに記憶させたいメモリ領域を割り付けなければならない。
・このメモリの開始アドレスが、Cmd_Addレジスタにプログラムされなければならない。
・このバッファの長さが、Cmd_FIFO_Lenレジスタにプログラムされなければならない。
・コマンド・ブロックが利用可能なときに、内部プロセッサが、割り込みを介して通知してもらいたければ、それは、Cmd_Stat_ControlレジスタにCmd_Int_Enビットをセットしなければならない。
・これがすべて入力されたとき、内部プロセッサは、Cmd_Stat_ControlレジスタにCmd_Enビットをアサートする。このビットのセッティングは、ハードウェア・コマンド・パーザが、コマンドを内部プロセッサに渡し始めることをイネーブルにする。このビットがアサートされる前に、ハードウェアパーザがコマンド・ブロックを受け取ったら、そのハードウェアパーザは、そのコマンド・ブロックを黙って破棄する。
・ハードウェアが、コマンド・ブロックを受信すると、そのハードウェアは、Cmd_Addレジスタによって指定されたバッファに、それらを記憶し始める。ハードウェアが、内部プロセッサメモリへのコマンド・ブロックの書き込みを完了した後、そのハードウェアは、Cmd_Stat_StatレジスタにCmd_Recビットをアサートする。Cmd_Recビットがアサートされてしまった後、さらなるコマンド・ブロックが受け取られたら、ハードウェアは、内部プロセッサによって指定されたFIFOに、それらの書き込みを継続する。
・それがFIFOの終端まで達したら、アドレスは、始点（Cmd_Addレジスタによって指定される）に周回する。
・内部プロセッサは、それが、提出される全てのコマンド（Cmd_Rec_Lenレジスタによって指定される）を読み出して処理したときでなければ、Cmd_Recビットをクリアしてはいけない。Cmd_Recビットがクリアされるまで、ハードウェアは、それらのFIFO位置に重ね書きしない。したがって、Cmd_Recビットをクリアすることは、新しいコマンドのためにそれらのメモリ位置を再使用することができるハードウェアパーザに対するACKとして働く。
このセクションは、ステータス・ブロック構造を詳述する。インターネット・チューナ10Gは、ステータス・ブロックを用いて、システムに情報を戻し渡す。ステータスは、受信されたデータの報告から、例外事例、エラー状態、あるいは、接続統計に及ぶことができる。ステータス・ブロックは、通例、DMAを用いてホスト・システムに転送される。インターネット・チューナ10Gは、最初に、ステータスコマンド・ブロックのリストを生成する。さまざまな元がステータス・メッセージを生成することができ、また、それらのステータス・メッセージは全て、1つのマスターステータス・メッセージ・ジェネレータに流し込まれる。これらのメッセージは、メッセージリストに入れられ、その後、送信DMAエンジン・モジュールに利用可能になる。
ステータス・メッセージ・ブロックは、長さが可変で、以下のようなフィールド構造を持っている。ステータスのタイプにかかわらず、各ブロックは、偶数バイトから構成されなければならない。奇数バイト・ステータス・メッセージ・ブロックには、全て、パディング・バイトが、用いられなければならない。
ステータス・ブロックハンドリングのホスト側インプリメントは、コマンド・ブロックメカニズムを補完する。適切なインプリメントが、正しい動作のために付けられなければならない。不適当なインプリメントは、行き詰まった状況に導くことがある。
ステータス・ブロック循環キューは、ホストメモリ内に作り出され、また、インターネット・チューナ10Gは、その開始(statqstart)アドレスおよびその終了(statqend)アドレスを付けて構成される。したがって、ステータス・ブロックは、周期的に、あるいは、要求に応じて、DMAを用いて、インターネット・チューナ10Gハードウェアから、このキューに転送される。
このセクションは、ステータス・メッセージを送る動作について説明し、内部プロセッサが、ステータス・メッセージをホスト・システムに送り返すために通過しなければならないステップを詳述する。
・内部プロセッサは、メッセージ・ブロックを作り出して、それらのメッセージ・ブロックを、メモリ空間の連続的なセクションに入れなければならない。
・このメモリ空間の開始アドレスが、Stat_Addレジスタ内にプログラムされる。
・ステータス・メッセージの全長が、Stat_Lengthレジスタ内にプログラムされる。
・内部プロセッサは、ステータス・メッセージがホスト・システムに転送され終わったときについて、割り込みを介して通知してもらいたい場合には、Cmd_Stat_Int_EnレジスタにStat_Int_Enビットをセットしなければならない。
・これが全て、初期化されたときに、内部プロセッサは、Cmd_Stat_ControlレジスタにSend_Statビットをアサートする。このビットのセッティングによって、ホスト・システムに渡すために内部プロセッサによって生成されたステータス・メッセージが存在するということが、ハードウェアに通知される。
・ハードウェアは、内部プロセッサ状態メッセージの送信を完了したとき、Cmd_Stat_ControlレジスタのSend_Statビットをクリアし、Cmd_Stat_StatレジスタにStat_Sentビットをセットする。
・Stat_Int_Enビットもセットされていたら、ステップ番号6は、また、内部プロセッサ割り込みのトリガもする。
ここから、もし望めば、内部プロセッサが、新しいステータス・メッセージを入力する。
本明細書において、本発明が、好適な実施例に関して記述されているが、当業者であれば、他の応用が、本発明の精神および範囲から逸脱することなく、本明細書に説明されている応用に置き換えることのできるものであることが容易に認識される。したがって、本発明は、以下に含まれる請求項によってしか制限されるべきではない。
本発明によるコアシステムのハイレベルデータ・フロー図である。 本発明によるシステムのハイレベルブロック図である。 本発明による完全システムインプリメンテーション、および、UMAメモリコンントローラ(3A)の機能ブロック図である。 従来のアーキテクチャと本発明で必要とされるデータタスク時間を例証する時間比較チャートである。 本発明による応用の可能な発展を例証している。 本発明によるインターネット・チューナの概念を例証している。 本発明による2つのインプリメンテーションを例証している。 本発明によるネットワークPCインプリメンテーションを例証している。 本発明によるハンドヘルドデバイスインプリメンテーションを例証している。 本発明による電話インプリメンテーションを例証している。 本発明によるスマートテレビジョン、ケーブルボックス、ビデオ・カセット・レコーダ(VCR)、デジタルビデオディスク(DVD)、ゲームマシンのインプリメンテーションを例証している。 本発明による受信パケットを分配するタイミング図である。 本発明による図12のパケットの信号フローを示すブロック線図である。 本発明による、内部プロセッサと組み合わせた本発明のインターネット・チューナ10Gを用いたアダプタ・インプリメンテーションのブロック線図である。 本発明によるインターネット・チューナ10Gを用いた、ネットワークに配されたデバイスのブロック線図である。 本発明によるギガビット・イーサネット・アダプタ・チップのブロック線図である。 本発明によるインターネット・チューナ10Gのブロック線図である。 本発明によるARPモジュールのブロック線図である。 本発明によるARPキャッシュルックアップ処理のブロック線図である。 本発明によるIPモジュールのブロック線図である。 本発明によるICMPエコー応答モジュールのブロック線図である。 本発明によるICMPエコー応答受信モジュールのブロック線図である。 本発明によるICMPエコー応答プロセッサのブロック線図である。 本発明による、再構築がハードウェアで遂行されるときの、IP再構築中の情報フローのブロック線図である。 本発明によるIP分割モジュールのブロック線図である。 本発明によるIP識別フィールド・ジェネレータ・モジュールのブロック線図である。 本発明によるTCPモジュールの先頭図のブロック線図である。 本発明によるTCP受信データ・フローのブロック線図である。 本発明によるVSOCKおよび受信状態ハンドラ制御ブロックの探索解決フローのブロック線図である。 本発明によるRSTパケット生成データ・フローのブロック線図である。 本発明によるソケット受信データ・フローのブロック線図である。 本発明によるソケット送信データ・フローのブロック線図である。 本発明によるTCP送信モジュールデータ・フローのブロック線図である。 本発明によるパケット・スケジューラ・モジュールのブロック線図である。 本発明によるIPルータのブロック線図である。 本発明によるIPルータ要求信号制御のブロック線図である。 本発明によるシステム例外ハンドラのブロック線図である。 本発明による典型的なm1メモリ・マップのブロック線図である。 本発明による雑メモリ・マップのブロック線図である。
符号の説明
1752 TCPモジュール
1758 IPモジュール
1762 ARPモジュール
1766 イーサネット・インターフェイス・モジュール
1770 イーサネットMACインターフェイス・モジュール
1890 ARP送信スケジューラ
1896 イーサネット受信モジュール
2062 IPヘッダ・フィールド構文解析モジュール
2064 IP分割モジュール
2180 ICMPエコー応答受信モジュール
2182 ICMPエコー応答プロセッサ・モジュール
2500 VSOCKモジュール・メモリ・アロケータ・モジュール
2830 RSTパケット・ジェネレータ・モジュール
2832 受信状態ハンドラ・モジュール
2834 VSOCKモジュール
2841 SYN/ACKパケット・ジェネレータ・モジュール
2842 NATとIPマスカレーディング・モジュール
3350 パケット・スケジューラ
3352 ソケット送信ハンドラ・モジュール

Claims (91)

  1. ネットワークプロトコルをデコードおよびエンコードして、データを処理するためのアダプタであって、
    パケットを受信および送信し、また、パケットをエンコードおよびデコードするためのネットワークスタックと、
    複数の専用ハードワイヤードロジックプロトコルモジュールと、
    各プロトコルモジュールと接続されているシステム例外ハンドラ・モジュールと、
    を備え、
    各プロトコルモジュールが、特定のネットワークプロトコルに最適化され、
    当該プロトコルモジュールが、並列実行を行い、
    当該システム例外ハンドラ・モジュールが、当該プロトコルモジュールのいずれも処理することができない例外データをメモリ・バッファに記憶し、当該例外データを、システム・コントローラがすべての例外データを読み出したときに当該システム例外ハンドラ・モジュールに通信することで当該メモリ・バッファを自由に使えるようにするホストシステムに渡す、
    アダプタ。
  2. プログラム可能な内部プロセッサをさらに備え、
    当該内部プロセッサが、当該ネットワークスタックを制御する、請求項1に記載のアダプタ。
  3. 専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項2に記載のアダプタ。
  4. 当該プロトコルモジュールに、TCPプロトコルモジュールが含まれている、請求項1に記載のアダプタ。
  5. 当該TCPモジュールが、TCPネットワークトラフィックおよびUDPネットワークトラフィックを処理する、請求項4に記載のアダプタ。
  6. 当該TCPモジュールが、メモリ管理ハードウェアを用いることによってバーチャルナンバのコネクションをサポートする、請求項4に記載のアダプタ。
  7. 当該TCPモジュールが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、アウトオブオーダパケットの再アセンブリをサポートする、請求項4に記載のアダプタ。
  8. ネットワークプロトコルをデコードしかつエンコードし、かつデータを処理するアダプタであって、
    パケットを受信しかつ送信しかつパケットをエンコードしかつデコードするネットワークスタックと、
    複数の専用ハードワイアドロジックプロトコルモジュールと、
    各プロトコルモジュールと接続されているシステム例外ハンドラ・モジュールと
    を備え、
    各プロトコルモジュールが、特定のネットワークプロトコルに最適化され、
    当該プロトコルモジュールが、並列実行を行い、
    当該システム例外ハンドラ・モジュールが、当該プロトコルモジュールのいずれも処理することができない例外データをメモリ・バッファに記憶し、当該例外データを、システム・コントローラがすべての例外データを読み出したときに当該システム例外ハンドラ・モジュールに通信することで当該メモリ・バッファを自由に使えるようにするホストシステムに渡す、
    アダプタ。
  9. 当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、TCPキープアライブタイマをサポートする、請求項4に記載のアダプタ。
  10. 当該TCPモジュールが、TCPスロースタートアルゴリズムをサポートしている、請求項4に記載のアダプタ。
  11. 当該TCPモジュールが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項4に記載のアダプタ。
  12. 当該TCPモジュールが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項4に記載のアダプタ。
  13. 当該TCPモジュールが、TCP選択確認応答(SACK)オプションをサポートしている、請求項4に記載のアダプタ。
  14. 当該TCPモジュールが、パケット往復遅延時間(round-trip time)を測定する、請求項4に記載のアダプタ。
  15. 当該TCPモジュールが、輻輳回避アルゴリズムを遂行する、請求項4に記載のアダプタ。
  16. 当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、TCPスケーリングウィンドウをサポートする、請求項4に記載のアダプタ。
  17. 当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、最大セグメントサイズ(MSS)探索(MSS discovery)をサポートする、請求項4に記載のアダプタ。
  18. 当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、タイムーウェイト アセシネーション(time-wait assassination)をサポートする、請求項4に記載のアダプタ。
  19. 当該TCPモジュールが、専用の最適化されたハードワイヤードロジックを用いて、ポートフォワーディングをサポートする、請求項4に記載のアダプタ。
  20. IPルータモジュールをさらに備え、
    当該IPルータモジュールが、
    ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
    複数のホストIPアドレスに対する経路制御と、
    ホスト指定経路およびネットワーク指定経路に対する経路制御と、
    ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
    リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
    ループバックIPアドレスを伴う経路制御と、
    IPマルチキャストアドレスを伴う経路制御と、
    のうちの任意の1つ以上を遂行する、請求項１に記載のアダプタ。
  21. 当該プロトコルモジュールが、IPプロトコルモジュールを具備し、そして、当該IPモジュールが、IPネットワークパケットを処理し、生成し、応える、請求項1に記載のアダプタ。
  22. 当該IPモジュールが、IPネットワークパケットを再構築するための専用の最適化されたハードワイヤードロジックを有する、請求項21に記載のアダプタ。
  23. 当該プロトコルモジュールが、ICMPネットワークメッセージまたはIGMPネットワークメッセージを処理し、生成し、応えるための専用の最適化されたハードワイヤードロジックを有するICMPモジュールを具備する、請求項1に記載のアダプタ。
  24. 当該プロトコルモジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハードワイヤードロジックから成るICMPモジュールを具備する、請求項1に記載のアダプタ。
  25. 当該プロトコルモジュールが、バーチャルナンバのネットワークコネクションの使用を可能にするバーチャルソケットモジュールを具備する、請求項1に記載のアダプタ。
  26. 当該プロトコルモジュールが、ARPプロトコルモジュールを具備し、そして、当該ARPモジュールが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項1に記載のアダプタ。
  27. 当該ARPモジュールが、
    ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
    複数のIPアドレスに対するARP要求と、
    ユニキャストARP要求と、
    グラシアス（gratuitous） ARP要求と、のうちの任意の1つ以上を生成する、請求項２６に記載のアダプタ。
  28. 当該ARPモジュールが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項２６に記載のアダプタ。
  29. 当該ARPモジュールが、優先順位を変化できるようにプログラムされている、請求項２６に記載のアダプタ。
  30. 最適化されたハードワイヤードロジックを用いて構築されたARPアドレスのためのキャッシュをさらに備え、
    当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
    当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
    当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、請求項２６に記載のアダプタ。
  31. 当該プロトコルモジュールが、RARPプロトコルモジュールを具備し、そして、当該RARPモジュールが、IPアドレスを要求するか、または、供給することができる、請求項1に記載のアダプタ。
  32. 当該RARPモジュールが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項３１に記載のアダプタ。
  33. ハードワイヤードバーチャルメモリ管理を可能にするメモリ構造をさらに備え、
    当該メモリ構造が、
    各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
    各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有する、請求項1に記載のアダプタ。
  34. 当該ハードワイヤードバーチャルメモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項３３に記載のアダプタ。
  35. プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューをさらに有する、請求項1に記載のアダプタ。
  36. ネットワークパケットが処理されるべき優先順位を計算して、割り当てるシーケンサをさらに有する、請求項1に記載のアダプタ。
  37. ネットワークサービス不能攻撃から保護するように、各ネットワークコネクションの状態についてのネットワーク情報を記憶するメモリアーキテクチャをさらに有する、請求項1に記載のアダプタ。
  38. 当該ネットワークスタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワークスタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項1に記載のアダプタ。
  39. 当該ネットワークスタックが、iSCSIまたはRDMAを含む、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項1に記載のアダプタ。
  40. ハードワイヤードロジック中にインプリメントされたバーチャルメモリマネージャをさらに有する、請求項1に記載のアダプタ。
  41. 当該バーチャルメモリマネージャが、バーチャルナンバのネットワークコネクションの使用を可能にし、そして、当該ネットワークコネクションのバーチャルナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項４０に記載のアダプタ。
  42. 当該バーチャルメモリマネージャが、ハードワイヤードロッキングメカニズムを用いて、メモリ位置間の干渉を防止する、請求項４０に記載のアダプタ。
  43. 当該バーチャルメモリマネージャが、一続きのメモリ構造を用いて、メモリにネットワークコネクション情報を記憶する、請求項４０に記載のアダプタ。
  44. 当該バーチャルメモリマネージャが、専用ハードワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項４０に記載のアダプタ。
  45. 当該バーチャルメモリマネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワークコネクション情報を、前記ネットワークコネクションの状態に依存して記憶する、請求項４０に記載のアダプタ。
  46. ネットワークプロトコルをデコードおよびエンコードして、データを処理するためのプロセスであって、
    パケットを受信および送信し、かつ、パケットをエンコードおよびデコードするためのネットワークスタックを提供するステップと、
    複数の専用プロトコルステートマシンを提供するステップと、
    各プロトコルステートマシンと接続されているシステム例外ハンドラ・モジュールを提供するステップと
    を含み、
    各プロトコルステートマシンが、特定のネットワークプロトコルに対して最適化されており、
    各プロトコルステートマシンが、並列実行を行い、
    前記システム例外ハンドラ・モジュールが、当該プロトコルステートマシンのいずれも処理することができない例外データをメモリ・バッファに記憶し、当該例外データを、システム・コントローラがすべての例外データを読み出したときに当該システム例外ハンドラ・モジュールに通信することで当該メモリ・バッファを自由に使えるようにするホストシステムに渡す、
    プロセス。
  47. プログラム可能な内部プロセッサを備えるステップをさらに有するプロセスであって、
    当該内部プロセッサが、当該ネットワークスタックを制御する、請求項４６に記載のプロセス。
  48. 専用ハードウェアによって直接サポートされていない他のプロトコルに対応する他のタイプのパケットが、当該内部プロセッサによって処理される、請求項４７に記載のプロセス。
  49. 当該プロトコルステートマシンに、TCPプロトコルステートマシンが含まれている、請求項４６に記載のプロセス。
  50. 当該TCPステートマシンが、TCPネットワークトラフィックおよびUDPネットワークトラフィックを処理する、請求項４９に記載のプロセス。
  51. 当該TCPステートマシンが、メモリ管理ハードウェアを用いることによってバーチャルナンバのコネクションをサポートする、請求項４９に記載のプロセス。
  52. 当該TCPステートマシンが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、アウトオブオーダパケットの再アセンブリをサポートする、請求項４９に記載のプロセス。
  53. ネットワークプロトコルをデコードしかつエンコードし、かつデータを処理するプロセスであって、
    パケットを受信しかつ送信しかつパケットをエンコードしかつデコードするネットワークスタックを提供するステップと、
    複数の専用ハードワイアドロジックプロトコルモジュールを提供するステップと、
    各プロトコルモジュールと接続されているシステム例外ハンドラ・モジュールを提供するステップと
    を含み、
    各プロトコルモジュールが、特定のネットワークプロトコルに最適化され、
    当該プロトコルモジュールが、並列実行を行い、
    当該システム例外ハンドラ・モジュールが、当該プロトコルモジュールのいずれも処理することができない例外データをメモリ・バッファに記憶し、当該例外データを、システム・コントローラがすべての例外データを読み出したときに当該システム例外ハンドラ・モジュールに通信することで当該メモリ・バッファを自由に使えるようにするホストシステムに渡す、
    プロセス。
  54. 当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、TCPキープアライブタイマをサポートする、請求項４９に記載のプロセス。
  55. 当該TCPステートマシンが、TCPスロースタートアルゴリズムをサポートしている、請求項４９に記載のプロセス。
  56. 当該TCPステートマシンが、TCP高速再送アルゴリズムおよび高速回復アルゴリズムをサポートしている、請求項４９に記載のプロセス。
  57. 当該TCPステートマシンが、内部プロセッサまたは専用ハードワイヤードロジックのいずれかを用いて、TCP Nagleアルゴリズムをサポートしている、請求項４９に記載のプロセス。
  58. 当該TCPステートマシンが、TCP選択確認応答(SACK)オプションをサポートしている、請求項４９に記載のプロセス。
  59. 当該TCPステートマシンが、パケット往復遅延時間を測定する、請求項４９に記載のプロセス。
  60. 当該TCPステートマシンが、輻輳回避アルゴリズムを遂行する、請求項４９に記載のプロセス。
  61. 当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、TCPスケーリングウィンドウをサポートする、請求項４９に記載のプロセス。
  62. 当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、最大セグメントサイズ(MSS)探索をサポートする、請求項４９に記載のプロセス。
  63. 当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、タイムーウェイト アセシネーション(time-wait assassination)をサポートする、請求項４９に記載のプロセス。
  64. 当該TCPステートマシンが、専用の最適化されたハードワイヤードロジックを用いて、ポートフォワーディングをサポートする、請求項４９に記載のプロセス。
  65. IPルータモジュールを備えるステップをさらに含み、
    当該IPルータモジュールが、
    ネットワークアドレス中継のためのハードウェアを含むデフォルトIP経路制御能力と、
    複数のホストIPアドレスに対する経路制御と、
    ホスト指定経路およびネットワーク指定経路に対する経路制御と、
    ICMPリダイレクトパケットメッセージ受信後の経路制御情報の動的な更新と、
    リミテッドブロードキャスト、サブネットディレクテッドブロードキャストおよびネットワークディレクテッドブロードキャストを含むが、それらに制限されないIPブロードキャストアドレスを伴う経路制御と、
    ループバックIPアドレスを伴う経路制御と、
    IPマルチキャストアドレスを伴う経路制御と、のうちの任意の1つ以上を遂行する、請求項４６に記載のプロセス。
  66. 当該プロトコルステートマシンが、IPプロトコルステートマシンを具備し、そして、当該IPステートマシンが、当該IPネットワークパケットを処理し、生成し、応える、請求項４６に記載のプロセス。
  67. 当該IPモジュールが、当該IPネットワークパケットを再構築するための専用の最適化されたハードワイヤードロジックを有する、請求項６６に記載のプロセス。
  68. 当該プロトコルモジュールが、ICMPネットワークメッセージまたはIGMPネットワークメッセージを処理し、生成し、応えるための専用の最適化されたハードワイヤードロジックを有するICMPモジュールを具備する、請求項４６に記載のプロセス。
  69. 当該プロトコルモジュールが、一定のICMP機能またはIGMP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムできる最適化されたハードワイヤードロジックから成るICMPモジュールを具備する、請求項４６に記載のプロセス。
  70. 当該プロトコルステートマシンが、バーチャルナンバのネットワークコネクションの使用を可能にするバーチャルソケットステートマシンを具備する、請求項４６に記載のプロセス。
  71. 当該プロトコルステートマシンが、ARPプロトコルステートマシンを具備し、そして、当該ARPステートマシンが、ネットワークARP応答を生成することによって、ネットワークARP要求に応える、請求項４６に記載のプロセス。
  72. 当該ARPモジュールが、
    ハードウェアARPアドレスキャッシュと組み合ったARP要求と、
    複数のIPアドレスに対するARP要求と、
    ユニキャストARP要求と、
    グラティアス（gratuitous） ARP要求と、
    のうちの任意の1つ以上を生成する、請求項７１に記載のプロセス。
  73. 当該ARPステートマシンが、一定のARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項７１に記載のプロセス。
  74. 当該ARPステートマシンが、優先順位を変化できるようにプログラムされている、請求項７１に記載のプロセス。
  75. 最適化されたハードワイヤードロジックを用いて構築されたARPアドレスのためのキャッシュを備えるステップをさらに含み、
    当該ARPキャッシュが、専用ハードウェアによって制御される、動的に分類されるテーブルを用い、
    当該ARPキャッシュが、ARPプロキシとして働く能力をサポートし、そして、
    当該ARPキャッシュが、専用ハードワイヤードロジックを用いて、ARPキャッシュエントリの満了時間を制御する、請求項７１に記載のプロセス。
  76. 当該プロトコルステートマシンが、RARPプロトコルステートマシンを具備し、そして、当該RARPステートマシンが、IPアドレスを要求するか、または、供給することができる、請求項４６に記載のプロセス。
  77. 当該RARPステートマシンが、一定のRARP機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項７６に記載のプロセス。
  78. ハードワイヤードバーチャルメモリ管理を可能にするメモリ構造を備えるステップをさらに有する、請求項４６に記載のプロセスであって、
    当該メモリ構造が、
    各々が自らの目的に対して最適化された、様々に分類された制御ブロックのセットと、
    各制御ブロックに記憶されたポインタを用いて、制御ブロックをリンクするメカニズムと、を有するプロセス。
  79. 当該ハードワイヤードバーチャルメモリ管理が、制御ブロックを割り付け、制御ブロックを更新し、そして、制御ブロックの割り付けを解放する、請求項７８に記載のプロセス。
  80. プログラム可能な優先順位にしたがって送信するためにパケットをスケジュール化する優先順位キューを備えるステップをさらに有する、請求項４６に記載のプロセス。
  81. ネットワークパケットが処理されるべき優先順位を計算して、割り当てるシーケンサを備えるステップをさらに有する、請求項４６に記載のプロセス。
  82. ネットワークサービス不能攻撃から保護するように、各ネットワークコネクションの状態についてのネットワーク情報を記憶するメモリアーキテクチャを備えるステップをさらに有する、請求項４６に記載のプロセス。
  83. 当該ネットワークスタックが、TCPパケットおよびIPパケットを処理し、生成し、受信し、そして、当該ネットワークスタックが、一定のIPパケット処理機能またはTCPパケット処理機能を内部プロセッサまたは外部プロセッサに渡すようにプログラムされている、請求項４６に記載のプロセス。
  84. 当該ネットワークスタックが、iSCSIまたはRDMAを含む、より上位レベルのプロトコルをカプセル化するIPパケットを処理し、生成し、受信する、請求項４６に記載のプロセス。
  85. ハードワイヤードロジック中にインプリメントされたバーチャルメモリマネージャを備えるステップをさらに有する、請求項４６に記載のプロセス。
  86. 当該バーチャルメモリマネージャが、バーチャルナンバのネットワークコネクションの使用を可能にし、そして、当該ネットワークコネクションのバーチャルナンバが、利用可能な内部メモリ量または外部メモリ量によってしか制限されない、請求項８５に記載のプロセス。
  87. 当該バーチャルメモリマネージャが、ハードワイヤードロッキングメカニズムを用いて、メモリ位置間の干渉を防止する、請求項８５に記載のプロセス。
  88. 当該バーチャルメモリマネージャが、一続きのメモリ構造を用いて、メモリにネットワークコネクション情報を記憶する、請求項８５に記載のプロセス。
  89. 当該バーチャルメモリマネージャが、専用ハードワイヤード回路を用いて、リンクリストまたは一続きのメモリ構造にエントリの探索、更新、挿入、削除を行う、請求項８５に記載のプロセス。
  90. 当該バーチャルメモリマネージャが、いくつかの相異なるタイプの制御ブロックを用いて、ネットワークコネクション情報を、前記ネットワークコネクションの状態に依存して記憶する、請求項８５に記載のプロセス。
  91. ネットワークスタックと、
    複数の専用ハードウェアモジュールと、
    各ハードウェアモジュールと接続されているシステム例外ハンドラ・モジュールと
    を備え、
    各ハードウェアモジュールが、プログラムにより最適化され、
    当該ハードウェアモジュールが、並列実行を行い、
    当該システム例外ハンドラ・モジュールが、当該ハードウェアモジュールのいずれも処理することができない例外データをメモリ・バッファに記憶し、当該例外データを、システム・コントローラがすべての例外データを読み出したときに当該システム例外ハンドラ・モジュールに通信することで当該メモリ・バッファを自由に使えるようにするホストシステムに渡す、
    アダプタ。
JP2008139758A 2001-04-24 2008-05-28 ギガビット・イーサネット・アダプタ Expired - Lifetime JP4916482B2 (ja)

Applications Claiming Priority (6)

Application Number Priority Date Filing Date Title
US28626501P 2001-04-24 2001-04-24
US60/286,265 2001-04-24
US10/093,340 2002-03-06
US10/093,340 USRE39501E1 (en) 1996-10-31 2002-03-06 Multiple network protocol encoder/decoder and data processor
US10/131,118 US8218555B2 (en) 2001-04-24 2002-04-23 Gigabit ethernet adapter
US10/131,118 2002-04-23

Related Parent Applications (1)

Application Number Title Priority Date Filing Date
JP2002584131A Division JP2005502225A (ja) 2001-04-24 2002-04-24 ギガビット・イーサネット・アダプタ

Publications (2)

Publication Number Publication Date
JP2008259238A JP2008259238A (ja) 2008-10-23
JP4916482B2 true JP4916482B2 (ja) 2012-04-11

Family

ID=39982279

Family Applications (1)

Application Number Title Priority Date Filing Date
JP2008139758A Expired - Lifetime JP4916482B2 (ja) 2001-04-24 2008-05-28 ギガビット・イーサネット・アダプタ

Country Status (3)

Country Link
JP (1) JP4916482B2 (ja)
AT (1) ATE493821T1 (ja)
DE (1) DE60238751D1 (ja)

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5278358B2 (ja) * 2010-03-15 2013-09-04 三菱電機株式会社 ネットワ−ク接続装置
CN115695591A (zh) * 2022-10-27 2023-02-03 天津津航计算技术研究所 一种基于fpga的多路gps报文上报系统

Family Cites Families (9)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2993728B2 (ja) * 1990-02-23 1999-12-27 株式会社日立製作所 プロトコル高速処理装置
JP3282205B2 (ja) * 1992-01-08 2002-05-13 株式会社日立製作所 受信データ処理方式及び通信制御装置
JPH06309251A (ja) * 1993-04-26 1994-11-04 Hitachi Ltd 高速の通信アダプタを実装した計算機
US5448558A (en) * 1994-04-05 1995-09-05 International Business Machines Corporation Method and apparatus for managing packet FIFOS
JPH09153924A (ja) * 1995-11-28 1997-06-10 Nec Corp 通信制御システムの手順誤り検出方式
US6034963A (en) * 1996-10-31 2000-03-07 Iready Corporation Multiple network protocol encoder/decoder and data processor
US6389479B1 (en) * 1997-10-14 2002-05-14 Alacritech, Inc. Intelligent network interface device and system for accelerated communication
US6141705A (en) * 1998-06-12 2000-10-31 Microsoft Corporation System for querying a peripheral device to determine its processing capabilities and then offloading specific processing tasks from a host to the peripheral device when needed
JP2000235536A (ja) * 1999-02-15 2000-08-29 Fuji Xerox Co Ltd データ通信方式及び装置

Also Published As

Publication number Publication date
JP2008259238A (ja) 2008-10-23
ATE493821T1 (de) 2011-01-15
DE60238751D1 (de) 2011-02-10

Similar Documents

Publication Publication Date Title
EP1382145B1 (en) Gigabit ethernet adapter
US20070253430A1 (en) Gigabit Ethernet Adapter
US7535913B2 (en) Gigabit ethernet adapter supporting the iSCSI and IPSEC protocols
US9264366B2 (en) Method and apparatus for processing received network packets on a network interface for a computer
US8059680B2 (en) Offload system, method, and computer program product for processing network communications associated with a plurality of ports
US7472156B2 (en) Transferring control of a TCP connection between devices
US8782199B2 (en) Parsing a packet header
US7535907B2 (en) TCP engine
JP4875126B2 (ja) Ｉｓｃｓｉおよびｉｐｓｅｃプロトコルをサポートするギガビットイーサネットアダプタ
JP4916482B2 (ja) ギガビット・イーサネット・アダプタ
WO2002059757A1 (en) Communications processor

Legal Events

Date Code Title Description
A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20110412

A601 Written request for extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A601

Effective date: 20110712

A602 Written permission of extension of time

Free format text: JAPANESE INTERMEDIATE CODE: A602

Effective date: 20110715

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20110812

A131 Notification of reasons for refusal

Free format text: JAPANESE INTERMEDIATE CODE: A131

Effective date: 20111025

A521 Request for written amendment filed

Free format text: JAPANESE INTERMEDIATE CODE: A523

Effective date: 20111205

TRDD Decision of grant or rejection written
A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

Effective date: 20120110

A01 Written decision to grant a patent or to grant a registration (utility model)

Free format text: JAPANESE INTERMEDIATE CODE: A01

A61 First payment of annual fees (during grant procedure)

Free format text: JAPANESE INTERMEDIATE CODE: A61

Effective date: 20120124

FPAY Renewal fee payment (event date is renewal date of database)

Free format text: PAYMENT UNTIL: 20150203

Year of fee payment: 3

R150 Certificate of patent or registration of utility model

Ref document number: 4916482

Country of ref document: JP

Free format text: JAPANESE INTERMEDIATE CODE: R150

Free format text: JAPANESE INTERMEDIATE CODE: R150

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

R250 Receipt of annual fees

Free format text: JAPANESE INTERMEDIATE CODE: R250

EXPY Cancellation because of completion of term