(57)【要約】ネットワーク（２０２）を介して受信されたパケットを処理するためのシステムおよび方法が提供される。使用において、データパケットおよび制御パケットは、ネットワーク（２０２）を介して受信される。さらに、該データパケットは、該制御パケットと並行（２０４および２０６）して処理される。ネットワークを介して受信されたパケットを処理する方法であって、該方法は、ネットワークを介してデータパケットと制御パケットとを受信することと、該制御パケットの処理と並行して該データパケットを処理することとを包含する方法である。
2008517565.tif 000002
【特許請求の範囲】
【請求項１】
ネットワークを介して受信されたパケットを処理する方法であって、該方法は、
ネットワークを介してデータパケットと制御パケットとを受信することと、
該制御パケットの処理と並行して該データパケットを処理することと
を包含する、方法。
【請求項２】
前記制御パケットは、第１処理経路を利用して処理され、前記データパケットは、該第１処理経路とは別個の第２処理経路を利用して処理される、請求項１に記載の方法。
【請求項３】
前記パケットの前記処理は、該パケットに関係する正しいソケット制御ブロックを識別するために、ルックアップテーブルとキャッシュとを並行して利用することを含む、請求項１に記載の方法。
【請求項４】
前記データパケットの前記処理は、前記パケットに関係する正しいソケット制御ブロックを識別するために、並行して、実質的に２重のロジックを利用することを含む、請求項１に記載の方法。
【請求項５】
前記パケットに関係する制御ブロックは、その後のパケットの処理とともに、並行して更新される、請求項１に記載の方法。
【請求項６】
タグ情報は、前記データパケットにあらかじめ付加される、請求項１に記載の方法。
【請求項７】
タグ情報は前記データパケットにあらかじめ付加され、その一方で、受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファにおいてバッファされる、請求項６に記載の方法。
【請求項８】
前記タグ情報は、対応するパケットの種類と、対応するパケットに関係するソケットハンドルと、対応するパケットと関係する状態情報と、対応するパケットに関係する制御情報とを含むグループから選択される、請求項６に記載の方法。
【請求項９】
ネットワークを介して受信されたパケットを処理する方法であって、該方法は、
フロントエンドモジュールを利用して受信したパケットを処理することと、
バックエンドモジュールを利用して受信したパケットを処理することと
を包含し、
受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファは、該フロントエンドモジュールと該バックエンドモジュールとの間に結合され、それらの間に境界を提供する、方法。
【発明の詳細な説明】
【技術分野】
【０００１】
（本発明の技術分野）
本発明は、ネットワークコミュニケーションに関し、より詳しくは、受信した（ＲＸ）パケットの処理に関する。
【背景技術】
【０００２】
（本発明の背景）
トランスポートオフロードエンジン（ＴＯＥ）は、処理能力を最適化する目的、および、プロセッサ利用を減らす目的のために高速システムにおいて人気を得ている技術を含む。ＴＯＥ構成要素は、しばしば、ネットワークインターフェースカード（ＮＩＣ）、ホストバスアダプタ（ＨＢＡ）、マザーボード、または、他のあらゆる所望されるオフローディングコンテクストなどのプリント回路基板のうちの１つに組み込まれる。
【０００３】
近年、システムにおける通信スピードは、処理速度よりも速さを増した。これは、入力／出力（Ｉ／Ｏ）ボトルネックを生成している。Ｉ／Ｏ用ではなく、主に演算用に設計されたプロセッサは、通常、ネットワークを介して流れるデータについていけない。結果として、データフローは、ネットワークの速度よりも遅いレートで処理される。ＴＯＥ技術は、プロセッサおよび／またはＩ／Ｏサブシステムから負担（すなわちオフローディング）を取り除くことによって、この問題を解決する。
【０００４】
ＴＯＥにしばしばオフロードされる処理の種類の１つは、トランスミッション制御プロトコル（ＴＣＰ）パケット処理を含む。ＴＣＰは、インターネットプロトコル（ＩＰ）とともに用いられるルール（プロトコル）のセットで、インターネットを介したコンピュータ間でメッセージユニットの形式でデータを送る。ＩＰが、データの実際の伝送を取り扱うことを担当する一方で、ＴＣＰは、インターネットを介した効果的なルーティングのために、メッセージが分割された個別のパケットの追跡を担当する。
【０００５】
高速ネットワーク上でＴＣＰパケットを取り扱うことは、多くの処理を必要とする。パケットは、順序がばらついて到着し得、従って、データを次々とアプリケーションに渡す場合、パケットは格納されなくてはならない。さらに、受信したパケットの処理は、ネットワーク接続の回線レートに遅れないようにしなくてはならない。
【０００６】
従って、ＴＣＰおよび他のパケット処理を加速させる技術の必要がある。
【発明の開示】
【課題を解決するための手段】
【０００７】
（本発明の概要）
ネットワークを介して受信したパケットを処理するためのシステムおよび方法が提供される。使用において、データパケットおよび制御パケットは、ネットワークを介して受信される。さらに、データパケットは、制御パケットと並行して処理される。
【０００８】
一実施形態において、制御パケットは、第１処理経路を利用して処理され得、データパケットは、第１処理経路とは別個の、第２処理経路を利用して処理され得る。
【０００９】
別の実施形態において、パケットの処理は、パケットと関係する正しいソケット制御ブロックを識別するために、ルックアップテーブルおよびキャッシュを、並行して利用することを含み得る。同様に、データパケットの処理は、パケットと関係する正しいソケット制御ブロックを識別するために、実質的に２重のロジックを、並行して利用することを含み得る。
【００１０】
さらに別の実施形態において、パケットに関係する制御ブロックは、その後のパケットの処理と並行して更新され得る。
【００１１】
さらなるオプションとして、タグ情報は、データパケットにあらかじめ付加され得る。そのようなタグ情報は、さらに、一方で受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファにおいてバッファとして働き、データパケットにあらかじめ付加され得る。オプションとして、タグ情報は、対応するパケットの種類、対応するパケットに関係するソケットハンドル、対応するパケットと関係する状態情報、および／または対応するパケットに関係する制御情報を含み得る。
【００１２】
使用において、データパケットは、ＲＸ  ＦＩＦＯバッファを利用して、バッファとして働き得る。
【発明を実施するための最良の形態】
【００１３】
図１は、一実施形態に従って、ネットワークシステム１００を説明する。示されるように、ネットワーク１０２が提供される。該ネットワークシステム１００のコンテクストにおいて、ネットワーク１０２は、ローカルエリアネットワーク（ＬＡＮ）、インターネットのような広域ネットワーク（ＷＡＮ）などを含むが、しかしそれらに限定されず、あらゆる形式を取り得る。
【００１４】
ローカルホスト１０４およびリモートホスト１０６は、ネットワーク１０２に連結されており、ネットワーク１０２を介して通信することが可能である。本明細書のコンテクストにおいて、そのようなホスト１０４および１０６は、ウエブサーバ、格納デバイスまたはサーバ、デスクトップコンピュータ、ラップトップコンピュータ、ハンドヘルドコンピュータ、プリンタ、またはあらゆる他の種類のハードウエア／ソフトウエアを含み得る。前述の構成部品のそれぞれ、および他のあらゆる例証されていないデバイスは、１つ以上のネットワークによって相互接続され得るということに留意されたい。
【００１５】
図２は、一実施形態が実装され得る例示的な構造２００を説明する。一実施形態において、構造２００は、図１のホスト１０４または１０６のうちの１つを表し得る。しかし、勿論、構造２００は、あらゆる所望されるコンテクストにおいて実装され得ることを留意されたい。
【００１６】
例えば、構造２００は、一般的なコンピュータシステム、回路基板システム、娯楽目的専用のゲームコンソールシステム、セットトップボックス、ルータ、ネットワークシステム、格納システム、アプリケーション特定システム、またはネットワーク１０２に関係する他のあらゆる所望されるシステムのコンテクストにおいて実装され得る。
【００１７】
示されるように、構造２００は、バス２０２を介して結合された複数の構成部品を含む。少なくとも１つのプロセッサ２０４は、処理データのために含まれている。プロセッサ２０４があらゆる形式を取り得るのに対して、一実施形態において、中央処理装置（ＣＰＵ）、グラフィックモジュール、チップセット（すなわち、関連する機能を行う、ユニットとして設計され販売されている集積回路の群）、それらの組み合わせ、または他のあらゆる関連する集積回路の形式を取り得る。グラフィックモジュールの例において、そのような集積回路は、変換モジュール、照明モジュール、およびラスター化モジュールを含み得る。前述のモジュールのそれぞれは、単一半導体プラットフォーム上に位置し得、グラフィック処理装置（ＧＰＵ）を形成する。
【００１８】
データを格納するためにプロセッサ２０４と通信する、プロセッサシステムメモリ２０６が、さらに含まれる。そのようなプロセッサシステムメモリ２０６は、オンボードまたはオフボードのランダムアクセスメモリ（ＲＡＭ）、ハードディスクドライブ、取外し可能格納ドライブ（すなわち、フロッピー（登録商標）ディスク、磁気テープドライブ、コンパクトディスクドライブ、など）、および／または他のあらゆる種類の所望される、データを格納することが可能なメモリの形式を取り得る。
【００１９】
使用において、プログラムまたは制御ロジックアルゴリズムは、プロセッサシステムメモリ２０６内にオプションとして格納され得る。そのようなプログラムは、実行されるとき、構造２００が様々な機能を行うことを可能とする。勿論、構造２００は、単に、ハードワイヤードゲートレベル回路に直接実装され得る。
【００２０】
プロセッサ２０４およびネットワーク（例えば、図１のネットワーク１０２を参照）と通信するトランスポートオフロードエンジン２１２が、さらに示される。一実施形態において、トランスポートオフロードエンジン２１２は、バス２０２を介してプロセッサ２０４と通信を維持し得る。しかし、勿論、トランスポートオフロードエンジン２１２は、プロセッサ２０４と通信し得るのは、それら２者間の通信を提供する任意の機構を介してである。トランスポートオフロードエンジン２１２は、トランスポート（すなわちＴＣＰ／ＩＰ）オフロードエンジン（ＴＯＥ）システム、または、ネットワークに送信されるデータを管理することが可能な、あらゆる集積回路を含む。
【００２１】
単一バス２０２が、前述の構成部品間の通信を提供するように示されるのに対して、任意の数のバス（または他の通信機構）が構成部品間の通信を提供するのに用いられ得ることを理解されたい。単なる例として、追加のバスが、プロセッサ２０４とプロセッサシステムメモリ２０６との間の通信を提供するのに用いられ得る。さらに、一実施形態において、図２に示される２つ以上の任意の構成部品は、単一集積回路上で一体化され得る。
【００２２】
動作中に、トランスポートオフロードエンジン２１２、プロセッサ２０４、および／またはソフトウエアは、ネットワーク（すなわち、例えば、図１のネットワーク１０２、その他を参照）を介して受信したパケットを処理するように働く。一実施形態に従って、データパケットおよび制御パケットはネットワークを介して受信される。さらに、データパケットは、制御パケットの処理と並行して処理される。
【００２３】
本明細書のコンテクストにおいて、「データパケット」とは、データを通信するために用いられる任意のパケットをいい、一方で、「制御パケット」とは、ネットワーク通信を介した制御の任意の局面を示す、任意のパケットをいう。さらに、「並行」とは、データパケットおよび制御パケットの任意の局面が、少なくとも部分的に、同時に処理される処理をいう。このために、受信したパケット処理が向上される。
【００２４】
別の実施形態において、パケットの処理は、パケットと関係する正しいソケット制御ブロック（ＣＢ）を識別するために、実質的に２重のロジック、および／または多重データ構成（すなわち、ルックアップテーブルおよびキャッシュ、など）を、並行して利用することを含み得る。オプションとして、そのようなサーチモード中（すなわち、そのようなＣＢが識別されているとき）に、正しいソケット制御ブロックがキャッシュにない場合、正しいソケット制御ブロックは、メインメモリから検索されるが、サーチモード中は、検索された正しいソケット制御ブロックはキャッシュには格納されない。本明細書のコンテクストにおいて、ＣＢは、接続の試み、および／または接続を探知するのに用いられることが可能なあらゆる情報を含み得る。
【００２５】
最初に正しくＣＢを識別するデータ構成の情報識別結果を利用することによって、前述の情報識別処理は加速される。さらに、実質的に２重のロジックを利用することによって、ＣＢ情報識別処理は、多重パケットに対して同時に実行され得、これによってさらなる加速を提供する。
【００２６】
さらなるオプションとして、タグ情報は、パケット（すなわち、データパケットおよび／または制御パケット、など）にあらかじめ付加され得る。そのようなタグ情報は、受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファにおいて、バッファとして働いている期間、さらに、パケットにあらかじめ付加され得る。タグ情報をあらかじめ付加することによって、受信したパケットは、前述のＣＢ認識情報が実行されている間、格納され得る。さらに、オプションとして、タグ情報のための別個のバッファは、あるいは必要あり得ない。
【００２７】
さらなる別の実施形態において、ＣＢは、追加のパケットが受信されると、更新され得る。このようにして、使用において、第１に関係するＣＢは、更新され得る。さらに、少なくとも第１パケットに関係するＣＢの更新が開始された後と、更新が完了する前とで、第２パケットの処理が開始され得、これによって、性能が向上する。この終わりにおいて、パケット処理はＣＢ更新と並行して実行され得、これによって、他の処理でボトルネックを作り出している処理のうちの１つのボトルネックの可能性を減らす。
【００２８】
さらなるオプションの特徴、および例示的な実装の詳細は、上記実施形態に関して、以下に明らかにされる。以下の詳細は、例証としての目的のみに述べられ、いかなる方法によっても限定するように解釈されるべきではないことに留意されたい。
【００２９】
図３は、一実施形態に従って、受信したパケットを処理するための例示的な構造３００を説明する。オプションとして、構造３００は、図２の例示的な構造２００のコンテクストにおいて実装され得る。しかし、勿論、構造３００は、あらゆる所望されるコンテクストにおいて実装され得るということを留意されたい。
【００３０】
示されるように、複数のメディアアクセス制御（ＭＡＣ）ＲＸバッファ３０２は、複数のネットワーク１０２からデータおよび制御パケットの両方を受信するために提供される。ＲＸバッファ３０２は、必ずしも複数のネットワーク１０２のためにあるのではないことに留意されたい。一実施形態は、単一のネットワークに対する１つのバッファを含み得る。そのような、ＭＡＣ  ＲＸバッファ３０２は、イーサネット（登録商標）ＲＸ３０６を供給し、次に、該イーサネット（登録商標）ＲＸ３０６は、インターネットプロトコル（ＩＰ）ＲＸ３１０と例外ハンドラ３１４との両方を供給する。全てのＩＰパケットは、ＩＰ  ＲＸ３１０に送られ、他の全てのパケットは、例外ハンドラ３１４に送られる。
【００３１】
ＩＰ  ＲＸ３１０内において、パケットＩＰヘッダは分析（ｐａｒｓｅ）される。全てのインターネットプロトコルセキュリティ（ＩＰＳＥＣ）プロトコルパケットは、その次に、ＩＰＳＥＣ  ＲＸハンドラ３０８に送られ、かつ、ＩＰＳＥＣ  ＲＸバッファ３０４に格納され、そして、全てのＴＣＰまたはＵＤＰパケットは、ＴＣＰ  ＲＸフロントエンドモジュール３１６に送られる。他の全てのパケットは、例外ハンドラ３１４に送られる。マルチプレクサ３１２は、ＩＰ  ＲＸ３１０からの通常のＴＣＰ／ＵＤＰパケットとＩＰＳＥＣ  ＲＸハンドラ３０８からの処理されたＩＰＳＥＣパケットとの間で選択する。
【００３２】
使用において、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、入ってくるＴＣＰパケットを分析し、受信したパケットが、ＴＣＰデータを含むか、またはＴＣＰ制御パケットであるかどうかを決定する。別個の処理経路は、その次に、それぞれのパケットの種類を提供される。このために、本明細書に上述された方法で、パケット処理は向上される。さらに、パケットの処理は、パケットに関係する正しいソケットＣＢを識別するために、実質的に２重のロジック、および／または多重データ構成［例えば、ルックアップテーブル（ＣＢルックアップテーブル３１８を参照）およびＣＢキャッシュ（ＣＢデータキャッシュ３２４を参照）、など］を、並行して利用することを含み得る。
【００３３】
その上に、本明細書に上述される理由のために、データパケットは、ＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２に格納され、その一方で、パケットに関係した対応するＣＢを同時に探索する。データパケットが格納され、ルックアップが完全となった後、タグ情報は、ＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２内のデータパケットにあらかじめ付加され得る。ＴＣＰ  ＲＸフロントエンドモジュール３１６のさらに続く別の局面において、第１パケットに関係するＣＢは、更新され得る。第１パケットに関係するＣＢの更新が少なくとも開始された後と、更新が完了する前とで、第２パケットの処理が開始され得、これによって、性能が向上する。
【００３４】
そのようなＴＣＰ  ＲＸフロントエンドモジュール３１６の機能性、およびオプションの実装の詳細に関するさらなる情報は、図４と付随する記述とを参照する間にさらに詳しく説明される。
【００３５】
図３を引き続き参照すると、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、例外ハンドラ３１４を供給する。あらゆるロジック例外を引き起こすと識別された全てのパケットは、例外ハンドラ３１４に送られる。例として、受信したフィルター設定にマッチするか、またはサポートされないオプションを含むパケットは、例外ハンドラ３１４に送られ得る。上述されたように、通常のデータパケットは、ＲＸバッファコントローラ３２０を介してＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２に格納される。このＲＸバッファコントローラ３２０は、例外ハンドラ３１４か、またはＴＣＰ  ＲＸフロントエンドモジュール３１６のどちらかからのパケットを格納する要求を受け、２つの情報源の間を取り持つ（ａｒｂｉｔｒａｔｅ）。そのような相互作用に関するさらなる情報は、本明細書の以下において、さらに詳しく述べられる。
【００３６】
ＲＸバッファコントローラ３２０は、追加のＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２を供給し、ＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２は、その次に、ＲＸバックエンドモジュール３２６を供給する。ＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２は、このように、フロントエンドモジュールとバックエンドモジュールとの間に結合され、それらの間に境界を提供し、それらを非干渉化させる。
【００３７】
図３に示されるように、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、ＲＸバックエンドモジュール３２６に、パケットが、ＭＡＣ  ＲＸ  ＦＩＦＯバッファ３２２において情報提供のために利用できるということを示す。やがて明白になり得るが、ＲＸバックエンドモジュール３２６は、インターネット小型コンピュータシステムインターフェース（ｉＳＣＳＩ）プロトコルか、または他の任意の所望されるプロトコル［すなわち、ＲＤＭＡ（リモートデータメモリアクセス）、その他］のようなアプリケーションレベル処理を取り扱う。そのようなＲＸバックエンドモジュール３２６の機能性、およびオプションの実装の詳細に関するさらなる情報は、図５と付随する記述とを参照する間にさらに詳しく説明される。
【００３８】
最後に、ＲＸバックエンドモジュール３２６は、分散収集リスト（ＳＧＬ）３３４［および／または、可能であれば、メモリ記述子リスト（ＭＤＬ）］と、匿名バッファリスト３２８との両方を、直接メモリアクセス（ＤＭＡ）ロジック３３０とも併せて使用し、ホストメモリ内に受信したパケットを格納する（すなわち、例えば図２のプロセッサシステムメモリ２０６および１０６を参照）。本明細書のコンテクストにおいて、ＳＧＬは、メモリ内の様々な位置を記述するために提供される、任意のデータリストオブジェクトを含み得、該メモリには、入ってくるデータが最終的に格納される。
【００３９】
図４は、一実施形態に従って、受信したパケットを処理するための例示的なＴＣＰ  ＲＸフロントエンドモジュール３１６を説明する。オプションとして、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、図３の例示的な構造３００のコンテクストにおいて実装され得る。しかし、勿論、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、あらゆる所望されるコンテクストにおいて実装され得るということを留意されたい。
【００４０】
図４に示されるように、ＴＣＰ  ＲＸフロントエンドモジュール３１６は、ＩＰ層からデータを受信し（すなわち、例えば図３のＩＰ  ＲＸ３１０を介して、など）、パケットを処理するか、または例外として扱うかのどちらかを行う。このことを達成するために、ＴＣＰ  ＲＸパーサ４１４およびソケットロケータモジュール４０２が提供される。オプションとして、多重ＴＣＰ  ＲＸパーサ４１４およびソケットロケータモジュール４０２が、提供され得る。そのことに関して、本明細書に開示された任意のロジックモジュールは、実質的に２重か、または、さらに３重で提供され得、処理を向上させる。
【００４１】
使用において、ＴＣＰ  ＲＸパーサ４１４は、受信したＴＣＰおよびユーザーデータグラムプロトコル（ＵＤＰ）パケットを分析することに対して責任がある。オプションとして、全てのＵＤＰパケットは、例外として送られ得るか（すなわち、例えば図３の例外ハンドラモジュール３１４などを介して）、ＴＣＰデータパケットに類似した手段で処理され得る。さらなるオプションとして、ＵＤＰチェックサムは、確認され得、かつ、不良の場合、パケットは中止され得る。
【００４２】
ＴＣＰパケットのために、全てのデータパケットはＲＸ  ＦＩＦＯバッファ３２２に格納され、全ての制御パケットは、制御パケットキュー４０４に送られる。この決定は、ＴＣＰヘッダ内のＦＬＡＧビットおよびパケットの長さを調べることによって達成され得る。このようにして、制御パケットは、第１処理経路を利用して処理され得、データパケットは、第１処理経路とは別個の、第２処理経路を利用して処理され得る。
【００４３】
パケットがデータパケットの場合、ソケットハッシュは、ソケットロケータモジュール４０２によって計算される。バックグラウンドを介して、それぞれのデータパケットは、１組のＩＰアドレスおよび１組のＴＣＰまたはＵＤＰポートの両方を有し、それらは各データパケットに関連付けられている。ハッシュは、そのようなＩＰアドレスおよびポートに基づいて生成され得る（例えば、「ソケット４つ組」を利用することによって、など）。
【００４４】
このハッシュは、その次に、ＣＢルックアップテーブル３１８に索引を作るために用いられ得る。ＣＢルックアップテーブル３１８のサンプルが、表１に示される。
表１
ハッシュ１／（メモリ内のソケットＣＢ１に対するアドレス１）
ハッシュ２／（メモリ内のソケットＣＢ２に対するアドレス２）
ハッシュ３／（メモリ内のソケットＣＢ３に対するアドレス３）
ＣＢアドレスは、メモリ内の適切なＣＢの位置を識別するのに用いられ得、ＣＢに関係するソケットハンドル識別子として倍にする。ＣＢは、通常、ソケット状態、およびその他のような他の情報のほかに、そのようなソケットハンドルを含む。ＣＢ構成内には、同一の生成されたハッシュ値を含む、次のＣＢを指すフィールドがある。このようにして、一致しないハッシュ値を伴うソケットは無効とされ得る。
【００４５】
その次に、ＣＢに関係するソケットは、正しいソケットか否かが、ソケットハンドルと現在のパケットに関係している実際のソケットとの比較に基づいて決定される。例えば、パケットの４つ組が、ソケットＣＢのパラメータとマッチする場合、正しいＣＢは見つけられる。マッチしない場合、次のリンクしたソケットハンドルは、ＣＢから読み取られ、ソケットＣＢは、その次にフェッチされる。
【００４６】
この、次のリンクしたソケットハンドルを検索する処理は、正しいソケットＣＢが見つけられるか、または受信したパケットに関係し得るＣＢは存在しないと決定されるまで続けられる。オプションとして、ＣＢルックアップテーブル３１８のサイズは、ハッシュ衝突の数を減らすためにサポートされたソケットの最大数の２倍であり得、また、外部メモリに位置し得る。
【００４７】
ＣＢルックアップテーブル３１８のこの使用に並行して、ルックアップは、ＣＢデータキャッシュ３２４において行われる。ＣＢデータキャッシュ３２４は、最も新たに用いられた「ｎ」ソケットＣＢ（すなわち３２、など）を含む。ＣＢデータキャッシュ３２４は、ＣＢデータキャッシュ３２４に存在する、それぞれのＣＢエントリのために生成されたハッシュを示すハッシュ関係テーブルをさらに含む。ソケットロケータモジュール４０２は、その次に、ＣＢデータキャッシュ３２４を照会し、ＣＢデータキャッシュ３２４内にマッチするＣＢハッシュが存在するか否かを決定する。このために、設定時間内（すなわち、ハッシュ生成のクロック）に、ＣＢデータキャッシュ３２４に可能なＣＢマッチがあるか否かを決定することができる。
【００４８】
最初に正しくＣＢを識別するデータ構成（すなわち、ＣＢルックアップテーブル３１８、またはＣＢデータキャッシュ３２４）の情報識別結果を利用することによって、前述の情報識別処理は加速される。例えば、ＣＢがＣＢデータキャッシュ３２４にないときに、正しいソケットを見つけるために必要な、最大数のメモリ読み取りは、方程式＃１によって与えられる。
方程式＃１
クロックの＃＝１＋ｐ（ｎ）、ここで：
・最初の読み取りはＣＢルックアップテーブル３１８のルックアップに与えられる。
・ｎは、その特定のハッシュに対するＣＢハッシュ衝突の数である。
・ｐは、ＣＢエントリからソケットポートおよびＩＰアドレスを読み取るために必要なクロックサイクルの数である。
【００４９】
ＣＢデータキャッシュ３２４にＣＢがある場合、ＣＢを見つけるのに必要なクロックの最大数は、方程式＃２によって与えられる。
方程式＃２
クロックの＃＝ｍ、ここで：
・ｍは、特定のハッシュを有するＣＢデータキャッシュ３２４内のＣＢの数をいう。
【００５０】
キャッシュバス幅は理想的なサイズ（すなわち、１２８ビット、など）になっているので、ＣＢデータキャッシュ３２４からパラメータは素早く読み取られ得る。
【００５１】
さらなる特徴として、ＣＢデータキャッシュ３２４は、ソケットロケータモジュール４０２が、ＣＢルックアップテーブル３１８によって参照されるＣＢを探索しているとき、モードを介して特別な読み取りを許可し得る。この特別な読み取りモードにおいて、要求されたＣＢは、ＣＢデータキャッシュ３２４内に位置するか否かを見るために最初にチェックされる。要求されたＣＢが、ＣＢデータキャッシュ３２４にある場合、コンテンツは直ちに戻され得る。しかし、要求されたＣＢが、ＣＢルックアップテーブル３１８に位置していない場合、メインＣＢメモリから読み取られるが、しかし、このモードにおいて、ＣＢは、ＣＢルックアップテーブル３１８内に引き込まれない。これは、この時点での探索ロジックは、まだ受信したパケットに関係するＣＢを探しているからである。一度正しいＣＢの位置付けられると、ＣＢに関係するハンドルは、ＣＢデータキャッシュ３２４を介してＣＢを読み取るＴＣＰ  ＲＸ状態コントローラ４１２に渡される。その時点で、ＣＢは、メインＣＢメモリから検索され、ＣＢデータキャッシュ３２４に置かれる。
【００５２】
データパケットは、ＣＢルックアップが行われると同時に、ＲＸ  ＦＩＦＯバッファ３２２に格納される。このようにして、所定のサイズ（すなわち、８０バイト、など）よりも大きいデータパケットに対して、適切なＣＢを見つけるために、最小の時間が、平均して失われる。正しいＣＢを位置付けることは、時間的に重大（ｔｉｍｅ  ｃｒｉｔｉｃａｌ）なタスクであるので、このロジック（すなわち、ＴＣＰ  ＲＸパーサ４１４および／またはソケットロケータモジュール４０２、など）は、ＴＣＰ  ＲＸフロントエンドモジュール３１６内で実質的に２重であり得、その結果、ＩＰ層から受信した多重パケットは、同時に処理され得る。
【００５３】
これは、第１パケットがまだ処理されている一方で、ロジックが、先取りし、次のパケットのためのＣＢを探索することを許可する。一度ＣＢが見つかり、コンテントがフェッチされると、パケット処理（すなわち、パケットをどうするかという決定、など）は、２，３のクロックサイクル内に終了する。
【００５４】
受信処理に戻ると、正しいＣＢが、ＣＢデータキャッシュ３２４内にない場合、正しいＣＢは、メインＣＢメモリから読まれ、それと同時に、ＣＢデータキャッシュ３２４に置かれる。ＣＢが、既にＣＢデータキャッシュ３２４内にある場合、ＣＢは、直接読まれ得る。ソケット状態、制御ビット、およびパラメータ（ＳＥＱおよびＡＣＫ数、などを含む）は、全てＣＢを用いて取得され得る。
【００５５】
一度全てのＣＢパラメータが取り込まれると、パケットの処理は、ソケットの状態によって、設定時間内（すなわち、およそ２クロックサイクル）に完了する。これにより、所定のサイズ（すなわち、平均して３００バイト）よりも大きいデータパケットに対して、処理は、データがＲＸ  ＦＩＦＯバッファ３２２に格納されるまでには完了し得る。たとえ、ＣＢが、メインＣＢメモリからフェッチされる必要があっても、これは、適用され得る。ＣＢが、既にＣＢデータキャッシュ３２４内にある場合、より小さなデータパケットでさえ、パケット処理に必要な最小の余分な時間内に処理され得る。
【００５６】
ＲＸ  ＦＩＦＯバッファ３２２内のそれぞれのパケットにあらかじめ付加されたものは、タグ情報である。このタグ情報は、パケットの種類の情報（すなわち、例外、ＴＣＰデータパケット、など）、タグ情報に関係するソケットハンドル、および／または他の制御および状態情報を含み得る。タグ情報は、完全なパケットが受信され、有効であると検証された後に、書き込まれ得る。
【００５７】
そのようなタグ情報は、ＲＸ  ＦＩＦＯバッファ３２２内でバッファされる間、さらに、パケットにあらかじめ付加され得る。そのようにして、タグ情報をあらかじめ付加することによって、受信したパケットは、前述のＣＢ識別情報が実行される間に、格納され得る。さらに、オプションとして、タグ情報のための別個のバッファは、あるいは必要あり得ない。
【００５８】
ＴＣＰパーサ４１４の別の機能は、ＴＣＰチェックサムを確認することである。この機能は、パケットが、（データパケットのために）ＲＸ  ＦＩＦＯバッファ３２２か、または（ＴＣＰ制御パケットのために）制御パケットキュー４０４のいずれかにおいて、分析され、格納されるので、パケットをスヌーピングすることによって終了する。結果としてのチェックサムは、ＩＰ層によって提供された擬ヘッダチェックサムと組み合わされ、最終のチェックサムを提供する。このチェックは、ＩＰモジュールからの最後の文字が読まれた後の、設定時間フレーム（すなわち３クロック）内に有効である。パケットが、ＴＣＰチェックサムエラーか、または、任意の下位層からの任意の他のエラーによってかのいずれかから、不良だと考えられる場合、パケットは、ＲＸ  ＦＩＦＯバッファ３２２か、または制御パケットキュー４０４のいずれかから落とされる。
【００５９】
図４を継続して参照すると、ＴＣＰ  ＲＸ状態コントローラ４１２が、提供される。ＴＣＰ  ＲＸ状態コントローラ４１２は、受信したＴＣＰデータパケットに対する行動方針を決定する責任がある。パケットパラメータは、ソケットＣＢ内のＴＣＰデータパケットに対してチェックされる。これは、パケットのシーケンス番号のチェッキング、ソケットの状態、などを含む。
【００６０】
しかし、パケットは良いものになるかのように処理される。そうすることにより、完全なパケットが受信された後、全ての処理は、すでに行われていることになり、最小の後続計算（ｆｕｒｔｈｅｒ  ｃａｌｃｕｌａｔｉｏｎ）のみが必要となるからである。パケットが不良であるとなると、ＣＢは更新されず、パケットは、ＲＸ  ＦＩＦＯバッファ３２２か、または制御パケットキュー４０４のいずれかから落とされる。この場合、それぞれのバッファの書き込みポインタは、パケットが到着した前の点にリセットされる。
【００６１】
一度完全なデータパケットが、ＲＸ  ＦＩＦＯバッファ３２２に格納されると、ＴＣＰ  ＲＸ状態コントローラ４１２は、ＴＣＰトランスミッタモジュール（不表示）を介してＡＣＫをスケジュールする。４つのＡＣＫモードがサポートされ得る：通常即時ＡＣＫ、通常遅延ＡＣＫ、ホストモード即時ＡＣＫ、およびホストモード遅延ＡＣＫ。
【００６２】
通常モードにおいて、ＡＣＫまたは遅延ＡＣＫは、データパケットが受信され、有効であると決定された直後に、要求されるか、または待ち行列に入れられる。２つのホストモードにおいて、ＡＣＫは、ホストがＲＸ  ＤＭＡを介してデータの受信に応答した後に、ただ、要求されるか、または待ち行列に入れられる。
【００６３】
ＴＣＰ  ＲＸパーサ４１４に再び戻ると、ロジックブロックは、データパケットから、純粋ＴＣＰ制御パケット（すなわち、どのようなデータも含まないパケット）を分離し得る。これは、純粋ＴＣＰ制御パケットは、通常、短いパケットであり、処理するのに時間的に重大ではないからである。これらのＴＣＰ制御パケットは、ＴＣＰヘッダ内のＦＬＡＧビット設定によって検知され、パケットの全長を用いて組み合わされる。パケットになにもデータが含まれておらず、プッシュ（ＰＳＨ）ビットが設定されていない場合、パケットは、純粋制御パケットとして見なされる。
【００６４】
これらのパケットは、図４の制御パケットキュー４０４に転送される。それぞれのパケットのチェックサムは、パケットが転送されると同時に計算され、不良パケットは処分（ｄｉｓｃａｒｄ）される。ソケットハッシュは、また、別個のセッションにおいて、計算され、かつ、あらかじめ付加される。制御パケットハンドラ４１６は、その次に、キューの外のパケットを読み取り、該パケットを処理する。表２の以下の動作は、制御パケットのために、その次に行われる。
表２
１．ソケットハッシュは、ＣＢルックアップテーブル３１８でルックアップされる。同時に、ハッシュはチェックされ、ＣＢが既にＣＢデータキャッシュ３２４にあるか否かを見る。
２．ＣＢが、既にＣＢデータキャッシュ３２４にあると仮定して、適応可能なフィールドが読み取られる。
３．ＢＣが、ＣＢデータキャッシュ３２４にない場合、メインＣＢメモリから読み取られ、データキャッシュ３２４に置かれる。
４．行動は、それから、受信したパケットの種類と、ソケットの現在の状態とによって決定される。これらの行動は、以下のいずれかであり得、しかし、限定されるものではない。
ａ．ＴＣＰトランスミッタから応答を要求する
ｂ．ホストに状態メッセージを送る
ｃ．パケットを無視する
ｄ．パケットを、例外として送る
５．必要な行動が決定した後、ＣＢはしかるべく更新される。
【００６５】
ルックアップおよびソケットの読み取りと、パケットの処理と、ＣＢの更新とは、全てパイプラインで繋がった動作であり、これによって、先の制御パケットがまだ処理されている間、ハンドラが次のソケットを見つけ始めるのを許可する。
【００６６】
図５は、一実施形態に従って、受信したパケットを処理するための例示的なＲＸバックエンドモジュール３２６を説明する。オプションとして、ＲＸバックエンドモジュール３２６は、図３の例示的な構造３００のコンテクストで実装され得る。しかし、勿論、ＲＸバックエンドモジュール３２６は、任意の所望されるコンテクストにおいて実装され得るということを留意されたい。
【００６７】
一度パケットがＲＸ  ＦＩＦＯバッファ３２２内に完全に格納され、パケットバッファヘッダが書き込まれると、ＲＸバックエンドモジュール３２６は、同内容の処理を開始する。ＲＸバックエンドモジュール３２６は、パケットバッファヘッダを分析およびストリップすることによって開始し、データ調整およびＲＸバッファヘッダ分析モジュール５０２を利用する。これは、ＲＸバックエンドモジュール３２６に、パケットの種類（すなわち、例外またはＴＣＰデータパケット）と、パケットに関係するＣＢハンドルと、上述されるような、他の状態および制御情報とを述べる。一実施形態において、ヘッダは、２５６ビットの長さであり得る。
【００６８】
パケットバッファヘッダが分析およびストリップされた後、パケットは、再調整される。この再調整は、必要であり得るが、それは、通常ＴＣＰ（およびオプションでＵＤＰ）データパケットにとって、パケットイーサネット（登録商標）、ＩＰ、およびＴＣＰヘッダもまた、ストリップされるからである。これらのヘッダのストリッピングは、結果のデータを非ＦＩＦＯ語調整とさせ得、再調整は、実質的なロジックモジュールがパケットデータ上で動作することを単純化させる。
【００６９】
再調整の後、パケットは、オプションで、アプリケーション特定処理ロジック５０４を介して通過され得る。このロジックは、ｉＳＣＳＩプロトコル、またはリモート直接メモリアクセス（ＲＤＭＡ）機能を実装するロジックを含み得、しかしそれらに限定されない。ｉＳＣＳＩサポートのために、このモジュールは、ｉＳＣＳＩサイクル冗長チェッキング（ＣＲＣ）検証と、ｉＳＣＳＩプロトコルデータユニット（ＰＤＵ）ヘッダ分析と、定時マーカー（ＦＩＭ）除去とを行い得る。
【００７０】
全ての例外パケット（ネットワークスタック内の全ての層から）は、例外バッファリスト（すなわち、一時的バッファ、ホールディングバッファ、エディバッファ、など）内に条件として指定されているとおり、ホストメモリに送られる。例外リスト（すなわち、例えば図３のリスト３２８、その他、を参照）は、ホストドライバによって提供される。リストは、バッファが用いられるにつれて、継続的に、ホストによって増やされる。例外バッファアドレスの検索、および例外バッファリストの管理は、ＳＧＬ処理ロジック５０６によって管理される。
【００７１】
ソケット上に到着する通例のＴＣＰデータは、通常、ソケットスペシフィックＳＧＬを用いて、ホストメモリのどこにデータが格納されるべきかを条件として指定する。ＳＧＬ（すなわち、たとえば図３のＳＧＬ３３４、その他、を参照）は、ホストドライバによって提供される。リストは、リストが用いられるにつれて、継続的に、ホストによって増やされる。本明細書のコンテクストにおいて、ＳＧＬは、メモリ内の様々な位置を記述するために提供される、任意のデータリストオブジェクトを含み得、該メモリには、入ってくるデータが最終的に格納される。データがソケット上で受信され、しかし、ソケットに関係するＳＧＬは、なにも有効なバッファアドレスを含まないとき、受信したデータは、また、例外バッファリストを用いて、ホストメモリに送られる。ＳＧＬ管理は、また、ＤＧＬ処理ロジック５０６によって取り扱われる。
【００７２】
通常ＴＣＰデータパケットのために、ＳＧＬエントリは、最初に、ＳＧＬメモリ３３４から検索される。受信したパケットのシーケンス番号は、ＳＧＬのどこにデータが置かれるべきかを示す。これは、シーケンス（ＯＯＳ）データの外でさえも、適切に、正しい調整を許可する。順序だって受信したデータのために、ＳＧＬから１つの読み取りのみが、データをどこへ格納するかというホストアドレスを取得するために必要とされる。
【００７３】
プロセッサシステムメモリへデータをＤＭＡ化する要求は、その次に、なされ得る。ＤＭＡ化要求が承諾されるとき、データはＲＸ  ＦＩＦＯバッファ３２２から読み取られ、特定のアドレスでプロセッサシステムメモリ２０６内にＤＭＡ化された、ホストＤＭＡインターフェース３３０（図３を参照）に送られる。多重ＳＧＬは、各ソケットによってサポートされ、その結果、動作のピンポンモードが可能となる。これは、ホストドライバが、１つが満期になったら、どのデータも匿名バッファに転送させることなく、次のＳＧＬを提供させることを可能とする。
【００７４】
単一データパケットが２つ以上のＳＧＬエントリに及ぶ場合、次のＳＧＬエントリは、パケットの最初の部分がＤＭＡ化されている間、フェッチされ得、かつ、処理され得る。このようにして、実質的なＤＭＡ化要求は、それぞれの要求の完了後、直ちになされる。
【００７５】
一度ＤＭＡ化が完了すると、状態メッセージは、オプションとして、データが到着したことをホストドライバに知らせるために生成され得る。この時点で、いくらかのＣＢパラメータは、また、ＴＣＰ  ＲＸ  ＣＢ更新および状態メッセージ要求モジュール５０８を用いて、更新される。
【００７６】
パケットヘッダの分析、ＳＧＬの取り込み、データのＤＭＡ化、およびＣＢの更新は、全てパイプラインで繋がった動作である。これは、先のパケットに対するＤＭＡがまだ完了中であっても、ＲＸバックエンドモジュール３２６が、次のパケットヘッダの処理を開始するのを許可し、データの最大処理能力を保証する。さらに、本明細書に開示された任意のロジックモジュールは、実質的は２重あるいは３重で提供され得、処理を向上させる。
【００７７】
図６は、一実施形態に従って、受信したパケットの処理のための例示的なフロントエンド方法６００を説明する。オプションとして、該方法６００は、図２の例示的な構造２００のコンテクストにおいて、または図３〜図５の例示的なフレームワークにおいてさえも、実行され得る。しかし、勿論、方法６００は、あらゆる所望されるコンテクストにおいて実装され得ることを留意されたい。さらに、様々な機能が例示的な構成要素（すなわち、本明細書上記に述べられるようなもの）に属する一方で、様々な機能性は、任意の所望されるエンティティによって実行され得るといことを理解することが重要である。
【００７８】
図６は、ＲＸバッファ（すなわち、例えば図３のＲＸ  ＦＩＦＯバッファ３２２を参照）まで受信したパケットに対する処理フローを図示し、このようにして、フロントエンド処理に焦点を合わせる。
【００７９】
オペレーション６０２において、インターネットプロトコル（ＩＰ）層は、受信したパケットが利用できるか否かを示す。そのような表示に応答して、決定６０４において、ＲＸパーサ（すなわち、例えば図４のＲＸパーサ４１４を参照）が利用できるか否かが決定される。
【００８０】
ＲＸパーサが利用できないと決定された場合、方法６００は、利用できるＲＸパーサを待つ。オペレーション６０６に留意されたい。利用できる場合、受信したパケットは、オペレーション６０８において、利用できるＲＸパーサに送られる。
【００８１】
一度ＲＸパーサが利用できるようになると、ハッシュは、パケットヘッダ６２４内に含まれるパラメータに基づいて、パケットに対して生成される。ＲＸパーサは、その次にＴＣヘッダを見て、パケットの種類を決定し（決定６１０を参照）、パケットパラメータを分析する。パケットが純粋ＴＣＰ制御パケット（すなわち、ＴＣＰデータを含まないパケット）である場合、パケットは制御パケットキュー（すなわち、例えば図４の制御パケットキュー４０４を参照）に送られる。オペレーション６１２を参照されたい。
【００８２】
パケットがＴＣＰデータを確かに含む場合、ＣＢ探索は、オペレーション６１６および６１８において開始される。探索は、並行して２重データ構造（すなわち、例えばＣＢルックアップテーブル３１８およびＣＢデータキャッシュ３２４、その他、を参照）を介してされ得る。どちらかの経路が最初に完了した時点で、探索処理を終了する。しかし、ＣＢデータキャッシュの探索がマッチするＣＢエントリを見つけられなかった場合、ロジックは、オペレーション６２０に示されるように、ＣＢルックアップテーブルルックアップが完了するまで待つ。一実施形態において、ＣＢルックアップテーブルは、ＣＢを見つけられないが、ＣＢが、ＣＢデータキャッシュで見つかるということは決してない。
【００８３】
ＣＢを見つけることと並行して、ＴＣＰデータはＲＸバッファ（すなわち、例えばＲＸ  ＦＩＦＯバッファ３２２、その他、を参照）内に格納される。オペレーション６１４に留意されたい。一度全てのデータが書き込まれると、オペレーション６２２において、タグセクションは、ＲＸ  ＦＩＦＯに、データセクションにあらかじめ付加される。このタグは、パケットに対するパラメータ（すなわち、どのようなデータの種類か）、およびＣＢエントリから取得された、いくつかの状態情報を含む（１つタグが見つかった場合）。タグがＲＸ  ＦＩＦＯに書き込まれた後、特定のパーサは、別の受信したパケットを受け入れることができる。
【００８４】
図７は、一実施形態に従って受信したパケットを処理する、例示的なバックエンド方法７００を説明する。オプションとして、方法７００は、図２の例示的な構造２００のコンテクストにおいて、または図３〜図５の例示的なフレームワークにおいてさえも、実行され得る。その上に、方法７００は、図６のフロントエンド方法６００に関係して実行され得る。
【００８５】
しかし、勿論、方法７００は、あらゆる所望されるコンテクストで実装され得ることに留意されたい。さらに、様々な機能が例示的な構成要素（すなわち、本明細書の上記で述べられたようなもの）に属する一方で、様々な機能性は、任意に所望されるエンティティによって実行され得るといことを理解することが重要である。
【００８６】
図７は、ＲＸバッファ（すなわち、例えば図３のＲＸ  ＦＩＦＯバッファ３２２を参照）の後に受信したパケットに対する処理フローを図示し、このようにして、バックエンド処理に焦点を合わせる。
【００８７】
ＲＸ  ＦＩＦＯバッファ（すなわち、例えばＲＸ  ＦＩＦＯバッファ３２２、その他、を参照）の出力で利用できるとき、図７のフローは開始する。最初に、オペレーション７０２および７０４において、ＲＸ  ＦＩＦＯバッファエントリに対するヘッダセクションは、パケットが利用できる場合に読み取られる。これは、バックエンドロジックに、データパケットの種類、および他の状態情報を示す。
【００８８】
パケットバッファヘッダが分析された後、イーサネット（登録商標）ＩＰ、およびＴＣＰ／ＵＤＰヘッダ（オフロードされた接続で受信されたパケットに対する）とともにストリップされ、データは再調整される。オペレーション７０６を参照されたい。
【００８９】
データは、その次に、オプションで、オプションの割振特定処理ロジックを介して渡される。オペレーション７０８を参照されたい。このロジックは、例えば、ｉＳＣＳＩおよびＲＤＭＡサポート処理が行われるところである。
【００９０】
パケットがオフロードされた接続に属する（すなわち、ＣＢエントリがパケットパラメータにマッチするように見つかった）場合、チェックが行われ、任意のＳＧＬバッファが、データのために利用できるかどうかが調べられる。決定７１０に留意されたい。バッファが利用できる場合、データは、プロセッサシステムメモリにおいてソケットバッファにＤＭＡ化される。これは、データがプロセッサシステムメモリにＤＭＡ化された後、オペレーション７１２のソケットのＳＧＬからホストバッファアドレスを取得することによって達成される。オペレーション７１６を参照されたい。
【００９１】
どのソケットバッファも利用できない場合、データは、大域リストの例外バッファアドレスを用いて、一般例外バッファ（プロセッサシステムメモリにまた、位置する）にＤＭＡ化される。オペレーション７１４を参照されたい。通知は、その次にホストに送られ得、ホストが処理するデータがあるということを示す。
【００９２】
ＣＢが、（決定７１８によって）パケットに用いられた場合、ＣＢは、オペレーション７２２において更新される。そうでない場合、（オペレーション７２０において言及されるように）追加のオペレーションは何も必要ない。並行して、バックエンドロジックは、ＲＸ  ＦＩＦＯバッファから次のパケットの処理を開始し得る。
【００９３】
図８は、一実施形態に従って、受信したパケットの処理のための例示的な制御パケット処理方法８００を説明する。オプションとして、方法８００は、図２の例示的な構造２００のコンテクストにおいて、または図３〜図５の例示的なフレームワークにおいてさえも、実行され得る。その上に、方法８００は、図６および図７の方法６００および７００に関係して、それぞれ実行され得る。
【００９４】
しかし、勿論、方法８００は、任意の所望されるコンテクストにおいて実装され得るということを留意されたい。さらに、様々な機能が例示的な構成要素（すなわち、本明細書上記に述べられるようなもの）に属する一方で、様々な機能性は、任意の所望されるエンティティによって実行され得るということを理解することが重要である。
【００９５】
図８の方法８００は、制御パケットが、制御パケットキューの出力において利用できるとき、開始する（すなわち、例えば図４の制御パケットキュー４０４を参照）。オペレーション８０２に留意されたい。最初に行われることは、パケットバッファヘッダが分析されるということである。オペレーション８０４を参照されたい。このヘッダは、制御パケットに関係する他の状態情報のほかに、生成されたパケットハッシュを含む。
【００９６】
次に、マッチするＣＢの探索は、検索されたハッシュ値を用いて開始される。データパケットのためのフロントエンドロジックに用いられる図６の方法６００に類似して、２重データ構造（すなわち、例えばＣＢルックアップテーブル３１８およびＣＢデータキャッシュ３２４、その他、を参照）が、並行して参照される。オペレーション８１０の結果に対するウェイトが続く、オペレーション８０６および８０８を参照されたい。
【００９７】
決定８１２を介して受信したＴＣＰ制御パケットにマッチするＣＢが何も見つからなかった場合、パケットは、オペレーション８１６のＤＭＡを介してホストに送られるようにスケジュールされ、ＲＸ制御ロジックは、キューからの次の制御パケットを処理することを開始し得る。ロジックは、オペレーション８２４において、継続前に、制御パケットがホストにＤＭＡ化されるのを必ずしも待たない。
【００９８】
決定８１２を介して制御パケットに対してマッチするＣＢが見つかった場合、パケットは、オペレーション８１４において処理される。チェックは、その次に行われ、ソケットＣＢが、パケット処理の結果として更新が必要かどうかを見る。決定８１８を参照されたい。ＣＢが更新をまさに必要とする場合、ＣＢは、オペレーション８２０および８２２において更新のためにスケジュールされる。制御パケットロジックは、その次に、キューからの次の制御パケットの処理を開始し得る。並行して、ＣＢは、既に説明されたように、現在の制御パケットに対して更新される。
【００９９】
様々な実施形態が上述されたが、それらは例示的に表されただけであり、限定されるものではないということを理解されたい。それ故に、好ましい実施形態の広さと範囲は、上述の例示的な実施形態のいずれによっても限定されるべきではなく、先述の請求項およびそれに相当するものに従ってのみ定義されるべきである。
【図面の簡単な説明】
【０１００】
【図１】図１は、一実施形態に従った、ネットワークシステムを説明する。
【図２】図２は、一実施形態が実装され得る構造を説明する。
【図３】図３は、一実施形態に従った、受信したパケットを処理するための構造の特定例を説明する。
【図４】図４は、一実施形態に従った、受信したパケットを処理するための例示的なフロントエンドモジュールを説明する。
【図５】図５は、一実施形態に従った、受信したパケットを処理するための例示的な受信機バックエンドモジュールを説明する。
【図６】図６は、一実施形態に従った、受信したパケットを処理するための例示的なフロントエンド方法を説明する。
【図７】図７は、一実施形態に従った、受信したパケットを処理するための例示的なバックエンド方法を説明する。
【図８】図８は、一実施形態に従った、受信したパケットを処理するための例示的な制御パケット処理方法を説明する。
【図１】
2008517565.tif 000003
【図２】
2008517565.tif 000004
【図３】
2008517565.tif 000005
【図４】
2008517565.tif 000006
【図５】
2008517565.tif 000007
【図６】
2008517565.tif 000008
【図７】
2008517565.tif 000009
【図８】
2008517565.tif 000010
【手続補正書】
【提出日】平成19年6月19日(2007.6.19)
【手続補正１】
【補正対象書類名】特許請求の範囲
【補正対象項目名】全文
【補正方法】変更
【補正の内容】
【特許請求の範囲】
【請求項１】
ネットワークを介して受信されたパケットを処理する方法であって、該方法は、
ネットワークを介してデータパケットと制御パケットとを受信することと、
該制御パケットの処理と並行して該データパケットを処理することと
を包含する、方法。
【請求項２】
前記制御パケットは、第１処理経路を利用して処理され、前記データパケットは、該第１処理経路とは別個の第２処理経路を利用して処理される、請求項１に記載の方法。
【請求項３】
前記パケットの前記処理は、該パケットに関係する正しいソケット制御ブロックを識別するために、ルックアップテーブルとキャッシュとを並行して利用することを含む、請求項１に記載の方法。
【請求項４】
前記データパケットの前記処理は、前記パケットに関係する正しいソケット制御ブロックを識別するために、実質的に２重のロジックを並行して利用することを含む、請求項１に記載の方法。
【請求項５】
前記パケットに関係する制御ブロックは、その後のパケットの処理と並行して更新される、請求項１に記載の方法。
【請求項６】
タグ情報は、前記データパケットにあらかじめ付加される、請求項１に記載の方法。
【請求項７】
前記タグ情報は、前記データパケットにあらかじめ付加され、その一方で、受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファにおいてバッファされる、請求項６に記載の方法。
【請求項８】
前記タグ情報は、対応するパケットの種類と、対応するパケットに関係するソケットハンドルと、対応するパケットと関係する状態情報と、対応するパケットに関係する制御情報とを含む群から選択される、請求項６に記載の方法。
【請求項９】
ネットワークを介して受信されたパケットを処理する方法であって、該方法は、
フロントエンドモジュールを利用して、受信したパケットを処理することと、
バックエンドモジュールを利用して、受信したパケットを処理することと
を包含し、
受信機（ＲＸ）先入れ先出し（ＦＩＦＯ）バッファは、該フロントエンドモジュールと該バックエンドモジュールとの間に結合され、該フロントエンドモジュールと該バックエンドモジュールとの間に境界を提供する、方法。
【請求項１０】
ネットワークを介してデータパケットと制御パケットとについてバスと通信するオフロードエンジンであって、該制御パケットと並行して該データパケットを処理するオフロードエンジンを備える、サブシステム。
【請求項１１】
バスと、
該バスと通信するメモリと、
該バスと通信するプロセッサと、
ネットワークを介してデータパケットと制御パケットとについて該バスと通信するオフロードエンジンであって、該制御パケットと並行して該データパケットを処理するオフロードエンジンと
を備える、システム。
【請求項１２】
前記システムは汎用コンピュータを含む、請求項１１に記載のシステム。
【請求項１３】
前記システムはゲームコンソールを含む、請求項１１に記載のシステム。
【請求項１４】
前記プロセッサは、中央処理装置と、グラフィック処理ユニットと、チップセットに内蔵された複数の集積回路のうちの１つの集積回路とからなる群から選択される、請求項１１に記載のシステム。
【請求項１５】
前記システムは回路基板を含む、請求項１１に記載のシステム。
【国際調査報告】
2008517565.tif 000011