説明

オフロードユニットを使用したTCP接続のためのデータ処理

【課題】TCP処理をオフロードユニットによるハードウェア処理とCPUによるソフトウェア処理で分担することにより高速化と低価格化を達成する。
【解決手段】TCP接続を経て受信及び送信されるデータを処理するための方法及び装置が説明される。オフロードユニットは、特殊なケースが存在しない受信データを処理してペイロードデータを発生し、これは、アプリケーションメモリへ直接アップロードされる。オフロードユニットは、特殊なケースが存在する受信データを部分的に処理して、その部分的に処理された受信データを、システムメモリに記憶されたバッファへアップロードする。次いで、この部分的に処理された受信データは、TCPスタックにより更に処理されてペイロードデータを発生し、これは、アプリケーションメモリにコピーされる。

【発明の詳細な説明】
【関連出願へのクロスレファレンス】
【0001】
[0001]本出願は、参考として全体をここに援用する、発明者及び譲受人が本出願と共通の2003年6月5日出願の「HARDWARE-OPERATED TCP/IP (HOT) PROCESSING」と題する共通所有の出願中のプロビジョナル米国特許出願第60/476,570号から優先権を請求する。
【発明の分野】
【0002】
[0002]本発明の1つ以上の態様は、一般に、送信制御プロトコル(TCP)処理に係り、より詳細には、TCPベースの通信を最適化することに係る。
【背景】
【0003】
[0003]従来のTCP処理は、クライアントとサーバーとの間のデータ転送を加速するために開発されたシステム及び方法により例示される。例えば、中央処理ユニット(CPU)のようなホストプロセッサで実行されるソフトウェア具現化は、ホストプロセッサからTCP処理をオフロードするように設計された高価な専用のハードウェア具現化に比して、比較的低廉で且つ低速である。
【0004】
[0004]図1は、CPU110と、ネットワークインターフェイスカード(NIC)150とを含む、一般的に100で示された従来のコンピュータシステムの実施形態を例示するブロック図である。このコンピュータシステム100は、デスクトップコンピュータ、サーバー、ラップトップコンピュータ、パルムサイズコンピュータ、タブレットコンピュータ、ゲームコンソール、セルラー電話、コンピュータベースのシミュレータ等でよい。CPU110をシステムコントローラ120に結合しているバス112は、フロントサイドバス(FSB)でよい。従って、コンピュータシステム100は、INTEL(登録商標)ハブアーキテクチャーとしても知られているハブベースのアーキテクチャーでよく、この場合、システムコントローラ120はメモリコントローラハブであり、I/Oブリッジ140がハブ対ハブインターフェイス126を経てシステムコントローラ120に結合される。システムコントローラ120は、メモリバス132を経てシステムメモリ130に結合される。I/Oブリッジ140は、周辺コンポーネントインターフェイス(PCI)バス182のためのコントローラを含むと共に、システムマネージメントバス142、ユニバーサルシリアルバス144等のためのコントローラを含んでもよい。I/Oブリッジ140は、単一集積回路でもよいし、単一半導体プラットホームでもよい。この技術で知られたシステムコントローラ120は、例えば、INTEL(登録商標)ノースブリッジを含む。この技術で知られたI/Oブリッジ140は、例えば、INTEL(登録商標)サウスブリッジ、並びにNVIDIA(登録商標)媒体及び通信プロセッサ(MCP)チップを含む。
【0005】
[0005]NIC150は、PCIバス182を1つ以上のPCIデバイス180とで共有してもよい。NIC150は、PCIインターフェイス145と、専用プロセッサ155と、媒体アクセスコントローラ(MAC)165と、専用メモリ160と、イーサネットネットワーク172へインターフェイスするためのイーサネットインターフェイス170とを備えている。NIC150用のソフトウェアドライバ119は、NIC150と、CPU110で実行されるアプリケーションプログラム117との間で通信する。システムメモリ130内には、アプリケーションメモリスペース125、TCPスタックメモリスペース145及びドライバメモリスペース135が割り当てられる。
【0006】
[0006]NIC150内の専用プロセッサ155は、CPU110がTCPスタック115を実行してTCP処理を遂行するのに代わって、TCP処理に使用される。それ故、NIC150は、CPU110をオフロードし、他のアプリケーションのサイクルを処理するようにCPU110を解放する。同様に、専用メモリ160は、TCPスタックメモリスペース145に置き換わるもので、他のアプリケーションに割り当てるようにTCPスタックメモリスペース145を解放する。しかしながら、専用メモリ160及び専用プロセッサ155を含むNIC150は、CPU110で実行されるTCP処理のためのソフトウェア具現化よりコストが高い。
【0007】
[0007]それ故、ホストプロセッサから幾つかのタスクをオフロードすることによりTCP処理を最適化すると共に、専用ハードウェア具現化に比してシステムコストを低減するような部分ハードウェア具現化が要望される。
【概要】
【0008】
[0008]本発明の方法の種々の実施形態は、オフロードユニットを使用してフレームの第1部分を処理して、第1の処理されたフレームデータを発生するステップと、オフロードユニットを使用してフレームの第2部分を処理して、第2の処理されたフレームデータを発生するステップと、CPUで実行されるアプリケーションプログラムを使用して第2の処理されたフレームデータを処理して、第3の処理されたフレームデータを発生するステップとを備えている。
【0009】
[0009]本発明の方法の種々の実施形態は、オフロードユニットを使用してデレゲートTCP接続を処理するステップと、CPUで実行されるアプリケーションプログラムを使用して、非デレゲートTCP接続を処理するステップと、CPUで実行されるアプリケーションプログラムを使用して、特殊なケースが存在する全てのフレームを処理するステップとを備えている。オフロードユニットは、特殊なケースが存在しないフレームを処理するように構成される。
【0010】
[0010]本発明の方法の種々の実施形態は、TCP接続を確立するステップと、ハードウェアによる処理のためにTCP接続をデレゲートすべきかどうか決定するステップとを備えている。
【0011】
[0011]本発明の方法の種々の実施形態は、デレゲート接続テーブルインデックスを受信するステップと、TCPスタックからプロートタイプヘッダ及び送信用のデータを受信するステップと、デレゲート接続テーブルインデックスを使用してデレゲート接続テーブルエントリーにアクセスするステップと、送信用のデータの一部分に基づいてTCPチェック和を計算するステップと、TCPチェック和及び送信用のデータの一部分を含むフレームを出力するステップとを備えている。
【0012】
[0012]本発明の種々の実施形態は、TCP接続のためのデータを処理するシステムを備えている。このシステムは、TCPスタックと、ソフトウェアドライバと、オフロードユニットとを含む。TCPスタックは、少なくとも1つのレガシーバッファに記憶された受信フレームを処理するように構成される。ソフトウェアドライバは、TCPスタックとオフロードユニットとの間をインターフェイスするように構成される。オフロードユニットは、デレゲート接続において受信されたフレームを処理して、ペイロードデータ及び部分的に処理されたフレームを発生するように構成される。
【0013】
[0013]本発明の種々の実施形態は、TCPスタックとオフロードユニットとの間で通信するシステムを備えている。このシステムは、TCPスタックからオフロードユニットへコマンドを送信する手段と、オフロードユニットからTCPスタックへ通知記述を送信する手段とを含む。
【0014】
[0014]本発明は、TCP接続のためのデータを処理する新規なシステム及び方法を包含する。
【0015】
[0015]添付図面は、本発明の1つ以上の態様に基づく実施形態を示すが、図示された実施形態に本発明を限定するものではなく、本発明を説明し及び理解するためのものに過ぎない。
【図面の簡単な説明】
【0016】
【図1】[0016]ホストコンピュータ及びネットワークインターフェイスカードを含む従来のコンピュータシステムの実施形態を示すブロック図である。
【図2A】[0017]本発明の1つ以上の態様に基づくホストコンピュータを含むコンピュータシステムの実施形態を示すブロック図である。
【図2B】本発明の1つ以上の態様に基づくホストコンピュータを含むコンピュータシステムの実施形態を示すブロック図である。
【図3】[0018]本発明の1つ以上の態様に基づく図2A及び2Bに示されたハードウェア最適化TCPサブユニットを示す図である。
【図4A】[0019]本発明の1つ以上の態様に基づきデレゲート接続を設定する方法の一実施形態を示す図である。
【図4B】[0020]本発明の1つ以上の態様に基づきフレームを受信する方法の一実施形態を示す図である。
【図4C】[0021]本発明の1つ以上の態様に基づくスロースタートシーケンスの一実施形態を示す図である。
【図5A】[0022]本発明の1つ以上の態様に基づく図2A及び2Bに示されたアプリケーションメモリスペースにおけるユーザバッファの一実施形態を示す図である。
【図5B】[0023]本発明の1つ以上の態様に基づくユーザバッファ記述子の一実施形態を示す図である。
【図5C】[0024]本発明の1つ以上の態様に基づく図2A及び2Bに示されたソフトウェアドライバメモリスペースにおけるレガシーバッファの一実施形態を示す図である。
【図5D】[0025]本発明の1つ以上の態様に基づくレガシーバッファタグテーブルの一実施形態を示す図である。
【図5E】[0026]本発明の1つ以上の態様に基づくレガシーバッファ記述子の一実施形態を示す図である。
【図6A】[0027]本発明の1つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへコマンドを転送するためのコマンドリングを示す概念図である。
【図6B】[0028]本発明の1つ以上の態様に基づきオフロードユニットからアプリケーションプログラムへ接続情報を転送するための通知リングを示す概念図である。
【図6C】[0029]本発明の1つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへ受信バッファ情報を転送するための受信記述子リングを示す概念図である。
【図6D】[0030]本発明の1つ以上の態様に基づきアプリケーションプログラムからオフロードユニットへ送信バッファ情報を転送するための送信記述子リングを示す概念図である。
【図7】[0031]本発明の1つ以上の態様に基づき図3に示されたハードウェア最適化TCPサブネットの一部分を含むブロック図である。
【図8A】[0032]本発明の1つ以上の態様に基づき有効フレームを処理する方法の一実施形態を示す図である。
【図8B】[0033]本発明の1つ以上の態様に基づきシーケンスずれフレームを処理する方法の一実施形態を示す図である。
【図8C】[0034]本発明の1つ以上の態様に基づきユーザバッファを待機する方法の一実施形態を示す図である。
【図8D】[0035]本発明の1つ以上の態様に基づきユーザバッファ処理を完了する方法の一実施形態を示す図である。
【図9A】[0036]本発明の1つ以上の態様に基づき通知を決定する方法の一実施形態を示す図である。
【図9B】[0037]本発明の1つ以上の態様に基づきユーザバッファ追従レガシー処理を同期する方法の一実施形態を示す図である。
【図10A】[0038]本発明の1つ以上の態様に基づき送信用のデータを表示するのに使用されるフォーマットを示す図である。
【図10B】本発明の1つ以上の態様に基づき送信用のデータを表示するのに使用されるフォーマットを示す図である。
【図11A】[0039]本発明の1つ以上の態様に基づき出て行くフレームを編集する方法の実施形態を示す図である。
【図11B】本発明の1つ以上の態様に基づき出て行くフレームを編集する方法の実施形態を示す図である。
【図11C】[0040]本発明の1つ以上の態様に基づき送信に含ませる確認を発生する方法の一実施形態を示す図である。
【本発明の詳細な説明】
【0017】
[0041]以下の説明において、本発明をより完全に理解するために多数の特定の細部について述べる。しかしながら、当業者であれば、本発明は、1つ以上のこれら特定の細部を伴わずに実施されてもよいことが明らかであろう。他の事例において、本発明を不明瞭にするのを回避するために、良く知られた特徴は説明しないことにする。
【0018】
[0042]図2A及び2Bは、本発明の1つ以上の態様に基づくCPU110及びハードウェア最適化TCP(HOT)ユニット250を備えたコンピュータシステム200の実施形態を示すブロック図である。図2Aにおいて、オフロードユニットであるHOTユニット250は、CPU110からあるTCP処理をオフロードする。CPU110は、少なくともあるTCP処理、より詳細には、以下に述べるようにHOTユニット250で遂行されないTCP処理を完了するためのコードを含むTCPスタック215を実行する。CPU110は、バス112を経てシステムコントローラ120に結合される。システムコントローラ120は、システムバス132によりシステムメモリ130に結合される。システムメモリ130は、以下に詳細に述べるTCPスタックメモリスペース225と、ドライバメモリスペース235と、接続テーブル(CT)245とを備えている。システムコントローラ120は、ハブ対ハブインターフェイス126を経てI/Oコントローラ240に結合される。
【0019】
[0043]I/Oコントローラ240は、PCIバス282のためのコントローラを含むと共に、システムマネージメントバス(SMBus)142、ユニバーサルシリアルバス(USB)144等のためのコントローラを含んでもよい。別の実施形態では、I/Oコントローラは、PCIエクスプレスバスのためのコントローラを含む。又、I/Oコントローラ240は、HOTユニット250も含み、PCIバス282を経てI/Oコントローラ240に結合されたデバイスからHOTユニット250を効果的に減結合する。より詳細には、ハブ対ハブインターフェイス126は、システムコントローラ120を経てHOTユニット250をシステムメモリ130へ結合する高速工業規格又は所有権バスでよい。I/Oコントローラ240に結合されるデバイスは、PCIバス282に使用可能な帯域巾を共有し、この帯域巾は、通常、ハブ対ハブインターフェイス126に使用可能な帯域巾より狭い。I/Oコントローラ240内にHOTユニット250を配置したことで、HOTユニット250とCPU110及びシステムメモリ130との間の待ち時間が、図1に示されたNIC150とCPU110との間の待ち時間に比して短くなる。従来、ドライバ255を経てNIC150のようなNICとソフトウェアスタックのようなアプリケーションプログラムとの間で通信を行なうには、短い待ち時間が重要となる。例えば、ドライバメモリスペース135に記憶されたフレームデータをアプリケーションメモリスペース125に結合するコピーする準備ができたことを通信するために、NIC150とCPU110との間でコマンドを通過させる上で、短い待ち時間が特に重要である。更に、ハブ対ハブインターフェイス126及びメモリバス132の各々は、PCIバス282より広い帯域巾をサポートするので、HOTユニット250は、PCIバス282を経てI/Oコントローラ240に結合されたデバイスより広い帯域巾でシステムメモリ130にアクセスすることができる。システムメモリ130に広い帯域巾でアクセスできることで、HOTユニット250は、時々「パケット」とも称される受信フレームを、PCIバス282のような狭帯域巾バスを経てI/Oコントローラ240に結合されたデバイスより更に迅速に、アプリケーションメモリスペース227又はドライバメモリスペース235へ転送することができる。
【0020】
[0044]HOTユニット250は、入力/出力インターフェイス242へインターフェイスするコントローラを含む。入力/出力インターフェイス242は、HOTユニット250を、物理層(PHY)、例えば、802.3PHY、HPNA1.0PHY、HPNA2.0PHY等へ結合してもよい。別の実施形態では、PHYがHOTユニット250内に含まれ、入力/出力インターフェイス242は、ギガビットイーサネットのようなイーサネットインターフェイスである。I/Oコントローラ240は、単一集積回路でもよいし又は単一半導体プラットホームでもよい。
【0021】
[0045]図2Bは、一体化コントローラ220を含むコンピュータシステム200の別の実施形態を示す。一体化コントローラ220は、システムコントローラ120及びI/Oコントローラ240により遂行される機能の少なくとも幾つかを遂行すると共に、HOTユニット250を備えている。又、一体化コントローラ220は、付加的なインターフェイスコントローラ(図示せず)、例えば、SMBus、USB、汎用I/O(GPIO)、一体化デバイスエレクトロニックス(IDE)等を含んでもよい。
【0022】
[0046]TCPスタック215は、1つ以上のTCP接続をデレゲート接続として選択する。デレゲート接続(delegated connection)とは、TCPスタック215による介入が最小の状態でHOTユニット250により処理されるTCP接続である。デレゲートされない接続、又は特殊な処理を要求するデレゲートされた接続は、TCPスタック215により完全に、又は部分的に処理される。TCPスタック215は、システムメモリ130内に記憶されたドライバ255を使用して、HOTユニット250内の以下に詳細に述べるデレゲート接続テーブルのエントリーを初期化することにより、デレゲート接続を設定する。ドライバ255は、実際には、TCPスタック215とHOTユニット250との間の変換器であり、TCPスタック215により要求されたときにHOTユニット250へコマンドを発行する。又、ドライバ255は、HOTユニット250から通知が受け取られたときにTCPスタック215にそれを知らせる。TCPスタック215とHOTユニット250との間の通信はドライバ255を使用して遂行されるが、ドライバ255は、これ以降、明確に指示されなくてもよい。
【0023】
[0047]デレゲート接続に対する接続状態データのみを記憶するデレゲート接続テーブルとは異なり、システムメモリ130内の接続テーブル245は、全てのアクティブな接続に対する接続状態データを記憶する。それ故、TCPスタック215は、HOTユニット250により要求されたときにデレゲート接続の処理を行うことができる。TCPスタック215によるデレゲート接続の処理は、「レガシー処理」と称される。
【0024】
[0048]図3は、本発明の1つ以上の態様に基づき図2A及び2Bに示されたHOTユニット250のブロック図である。DMAエンジン310内の直接メモリアクセス(DMA)インターフェイスは、I/Oコントローラ240又は一体化コントローラ220内の1つ以上のサブユニットにインターフェイスする。DMAインターフェイスは、システムメモリ130とHOTユニット250内のサブユニットとの間でデータを送信及び受信し、且つCPU10とHOTユニット250内のサブユニットとの間でコマンドを送信及び受信するのに使用される。
【0025】
[0049]送信エンジン320は、確認の挿入及びチェック和繰り返し冗長チェック計算を含む、出て行くフレームのパーズ及び編集を行なって、出て行くフレームを発生するように構成されたサブユニットを備えている。送信インターフェイス330は、送信用の出て行くフレームを記憶する1つ以上のバッファと、入力/出力インターフェイス242を経てHOTユニット250に結合されるPHYにインターフェイスするよう構成されたサブユニットとを備えている。HOTユニット250の別の実施形態では、PHYがHOTユニット250に一体化される。送信エンジン320は、デレゲート接続に対する接続状態データを記憶するデレゲート接続テーブル(DCT)350に結合される。このデレゲート接続テーブル350は、記憶リソース、例えば、ランダムアクセスメモリ(RAM)、レジスタファイル等である。又、デレゲート接続のための接続状態データの少なくとも一部分は、接続テーブル245にも記憶される。
【0026】
[0050]デレゲート接続テーブル350に記憶される状態情報は、確認状態、接続アドレス、システムメモリバッファに対するポインタ、接続追跡フラグ、事象制御情報、送信ウインドウサイズ、受信ウインドウサイズ、タイムスタンプデータ等を含んでもよい。確認状態は、次に受信が予想されるシーケンス番号のシーケンス番号、確認の適時発生を制御するスレッシュホールド等を含んでもよい。送信エンジン320は、フレーム処理中に接続テーブルインデックス即ちDCTインデックスを使用してデレゲート接続に関連したエントリーにアクセスして、デレゲート接続テーブル350の一部分を読み取り及び書き込みする。このエントリーに記憶された接続状態データは、図7に関連して説明するように、デレゲート接続がアクティブである間に、TCPスタック215、送信エンジン320及び受信エンジン360により更新される。
【0027】
[0051]受信インターフェイス370は、入力/出力インターフェイス242を経てHOTユニット250に結合されたPHYにインターフェイスするように構成されたサブユニットを備えている。又、受信インターフェイス370は、受信エンジン360を行先とする受信フレームを記憶するための受信FIFO(先入れ先出し)バッファも備えている。受信エンジン360は、部分的に処理されたフレーム又は単にTCPペイロードデータを、以下に詳細に述べるように、DMAエンジン310を経てシステムメモリ130へアップロードする。
【0028】
[0052]受信エンジン360は、到来するフレームのパーズを行なって、そのフレームが有効であるかどうか決定し、即ちチェック和を計算し、フラグを確認し、フレーム形式、例えば、IP、UDP、TCP等を識別するように構成されたサブユニットを備えている。パーズされたフレームが有効でないときには、それが、レガシー処理のためにドライバメモリスペース235のレガシーバッファにアップロードされる。受信フレームがIPパケットをTCPセグメントと共に含む場合には、TCPスタック215に通知がなされると共に、このTCPスタックは、必要なTCP処理を実行した後、そのアップロードされたフレームをレガシーバッファからアプリケーションメモリスペース227へコピーする。
【0029】
[0053]パーズされたフレームが有効であると決定された場合には、受信エンジン360は、ソースIPアドレス、TCPシーケンス番号(SN)、TCP確認(ACK)番号、TCPソース及び行先ポート番号、TCPウインドウサイズ、TCPヘッダ長さ等を抽出する。非デレゲート接続において受信されたパーズ済みフレームは、ドライバメモリスペース235のレガシーバッファへ処理のためにアップロードされる。デレゲート接続において受信された、特殊なケースでないパーズ済みフレーム、例えば、順序ずれシーケンス番号、TCPプッシュフラグセット等が処理されると共に、TCPペイロードデータがアプリケーションメモリスペース227のユーザバッファにアップロードされる。TCPペイロードデータをアプリケーションメモリスペース227に直接アップロードするのは、ドライバメモリスペース235を経てペイロードデータをアップロードするより効率的である。というのは、TCPペイロードデータは、その後、ドライバメモリスペース235からアプリケーションメモリスペース227へコピーされる必要がないからである。
【0030】
[0054]図4Aは、本発明の一実施形態に基づきデレゲート接続を設定するための方法ステップを示すフローチャートである。ステップ410において、コンピュータシステム200は、当業者に良く知られたプロセスを使用して三方ハンドシェークによりTCP接続を確立する。ステップ412では、TCPスタック215は、HOTユニット250による処理のために接続をデレゲートすべきかどうか決定する。TCPスタック215は、デレゲート接続の特性、例えば、接続の形式に対して指定されたユーザ定義プライオリティ、接続に対して指定された期間、接続に対して指定されたフレームレート、バルク転送を遂行するのに適したアプリケーションに対して接続が使用されるかどうか、接続により使用される特定のTCPポート等に基づいて、接続をデレゲートするよう決定してもよい。
【0031】
[0055]ステップ412において、TCPスタック215が、HOTユニット250による処理のために接続をデレゲートすべきでないと決定した場合は、ステップ414において、TCPスタック215は、接続を処理するためにCT245のエントリーを設定し、次いで、ステップ422へ進む。ステップ412において、TCPスタック215が、HOTユニット250による処理のために接続をデレゲートすべきであると決定した場合は、ステップ416において、TCPスタック215は、HOTユニット250へコマンドを発行して、DCT350のエントリーを接続状態データで設定する。ステップ418において、TCPスタック215は、以下に詳細に述べるように、後受信バッファ(PRB)コマンドをHOTユニット250へ発行して、システムメモリ130における1つ以上のユーザバッファの位置及びサイズをHOTユニット250に与えるべきかどうか決定する。ステップ418において、TCPスタック215が、PRBコマンドを発行すると決定した場合には、ステップ420において、TCPスタック215は、PRBコマンドを発行する。ステップ418において、TCPスタック215が、PRBコマンドを発行しないと決定した場合には、TCPスタック215は、ステップ422へ進む。ステップ422において、接続設定が完了となる。
【0032】
[0056]図4Bは、本発明の一実施形態に基づきフレームを受信するための方法ステップを示すフローチャートである。ステップ424において、HOTユニット250は、入力/出力インターフェイス242を経てフレームを受信し、そのフレームを部分的に処理して、部分的にパーズされたフレーム及びヘッダデータを発生することができる。ステップ416において、HOTユニット250は、フレームがデレゲート接続において受信されたかどうか決定し、もしそうでなければ、ステップ440において、HOTユニット250は、データリンク層とネットワーク層のプロトコルヘッダデータの完全なセットを含む部分的に処理されたフレームを、1つ以上のレガシーバッファにアップロードする。ステップ442において、TCPスタック215は、レガシーバッファへアップロードされた部分的に処理されたフレームを処理する。
【0033】
[0057]ステップ416において、HOTユニット250が、フレームがデレゲート接続において受信されたと決定した場合には、ステップ426において、HOTユニット250は、フレームのパーズを完了し、TCPペイロードデータを抽出する。ステップ427において、HOTユニット250が、ユーザバッファが使用可能であるかどうか決定し、もしそうであれば、ステップ428において、HOTユニット250は、TCPペイロードデータを1つ以上のユーザバッファにアップロードする。ステップ427において、HOTユニット250が、ユーザバッファが使用できないと決定した場合には、ステップ430において、HOTユニット250は、ペイロードデータの一部分をレガシーバッファにアップロードし、TCPスタック215にそれを通知する。一実施形態において、前記一部分は、デレゲート接続に対応してDCT350のエントリーに記憶された「スタートアップ限界」値により指定される。この「スタートアップ限界」は、最大受信フレームサイズに等しい最大値と、アプリケーションプログラム217又はTCPスタック215により決定された最小値とをとり得る変数である。
【0034】
[0058]ステップ432において、TCPスタック215は、レガシーバッファにアップロードされたTCPペイロードデータの一部分を処理する。ステップ434において、HOTユニット250は、デレゲート接続に対してTCPスタック215により発行された1つ以上のPRBコマンドが処理されたかどうか決定する。ステップ436において、HOTユニット350は、残りのTCPペイロードデータを1つ以上のユーザバッファへアップロードする。ステップ434において、HOTユニット250が、デレゲート接続に対する1つ以上のPRBコマンドが処理されなかったと決定した場合には、ステップ438において、HOTユニット250は、残りのTCPペイロードデータをレガシーバッファにアップロードし、TCPスタック215にそれを通知する。別の実施形態では、TCPスタック215がステップ434を完了し、次いで、ステップ438において、TCPスタック215は、HOTユニット250に、残りのTCPペイロードデータをレガシーバッファにアップロードするように命令する。
【0035】
[0059]一実施形態において、メッセージ信号化割り込み(messagesignaledinterrupt)(MSI)は、HOTユニット250が多数の割り込みベクトルを使用してその種々の割り込みソースを信号するためのメカニズムを与える。MSIを使用すると、ホストの割り込み取り扱い効率を得ることができる。一実施形態では、コンピュータシステム200は、割り込みベクトルを8個まで使用する。
【0036】
[0060]図4Cは、本発明の一実施形態に基づきスロースタートシーケンスを完了するための方法ステップを示すフローチャートである。スロースタート及び混雑回避アルゴリズムは、TCPプロトコル(RFC793、RFC1122及び関連ドキュメントに記載された)により指定され、それ故、当業者に良く知られている。TCPは、スロースタート及び混雑回避を使用して、所与の接続に対する使用可能な帯域巾を決定する。2つの変数、ssthresh(スロースタートスレッシュホールド)及びcwnd(混雑ウインドウ)が、デレゲート接続の振舞いを決定する。HOTユニット250は、受信したACKのカウントを含む特定のACK情報をTCPスタック215へアップロードする。ACKを受信するごとにTCPスタック215に通知するのではなく、HOTユニット250は、ACKを合体するようにTCPスタック215により構成されて、TCPスタック215で指定された頻度でTCPスタック215へACKをアップロードしてもよい。ACKを合体することで、HOTユニット250は、それがデレゲート接続の状態についてTCPスタック215に通知する頻度を減少することが許され、これは、多くの場合に性能を改善することが予想される。より詳細には、ACKを受信するごとにCPU110が割り込まれないので、CPU110の利用が通常減少される。受信したACKのカウントを含ませることで、TCPスタック215は、スロースタート及び混雑回避を実施するための通知のたびに受信されたACKの数を決定することが許される。
【0037】
[0061]ステップ452において、アプリケーションプログラム217は、cwndをデレゲート接続に対して1セグメントにセットし、次いで、TCPスタック215は、送信バッファ記述子をHOTユニット250に出力し、これについては、図6Dを参照して詳細に説明する。ステップ454において、HOTユニット250は、行先からACKが受信されたかどうか決定する。HOTユニット250は、ACKが受信されるまでステップ454に留まり、次いで、HOTユニット250は、TCPスタック215に通知し、ステップ456へ進む。一実施形態において、HOTユニット250は、受信したACKのカウントをTCPスタック215へ出力し、このTCPスタック215は、各通知と通知との間にデレゲート接続に対して受信したACKの数を計算してもよい。
【0038】
[0062]ステップ456において、TCPスタック215は、cwndがデレゲート接続に対してssthresh以上であるかどうか決定し、もしそうであれば、ステップ458において、TCPスタック215は、デレゲート接続に対して受信したACKの数に基づいてcwndを指数関数的に増加し、即ちオープンする。又、ステップ458において、TCPスタック215は、送信バッファ記述子をHOTユニット250へ出力し、ステップ454へ復帰する。
【0039】
[0063]一実施形態では、ステップ458において、TCPスタック215は、ACKを受信するたびにTCPスタック215に通知するようにHOTユニット250を構成する。別の実施形態では、TCPスタック215は、受信したACKのカウントをTCPスタック215に通知し、これにより、幾つかのACKを合体するようにHOTユニット250を構成する。ステップ456において、TCPスタック215が、ssthreshがデレゲート接続に対してcwnd未満であると決定した場合には、ステップ460において、TCPスタック215は、混雑回避段階にある。混雑回避が使用されるときには、cwndが最大送信ウインドウサイズに等しくなるか又はパケットがドロップされるまで、cwndが直線的にオープンとなる。
【0040】
[0064]図5Aは、本発明の1つ以上の態様に基づき図2A及び2Bに示されたアプリケーションメモリスペース227に記憶されたユーザバッファの実施形態を示す。HOTユニット250によりアップロードされるペイロードデータを受信するために、ユーザバッファ510、ユーザバッファ512又はユーザバッファ514のような各ユーザバッファがアプリケーションメモリスペース227に割り当てられる。ユーザバッファアドレス515のような物理的メモリアドレスは、アプリケーションメモリスペース227におけるユーザバッファ510の位置を指示する。同様に、ユーザバッファアドレス520は、ユーザバッファ512の位置を指示し、ユーザバッファアドレス525は、ユーザバッファ514の位置を指示する。ユーザバッファは、アプリケーションメモリスペース227内の物理的に隣接するメモリ位置に記憶されてもよいし、又はアプリケーションメモリスペース227内の物理的に非隣接のメモリ位置に記憶されてもよい。
【0041】
[0065]図5Bは、本発明の1つ以上の態様に基づくユーザバッファ記述子の実施形態を示す。各ユーザバッファは、そのユーザバッファ内に記憶できるバイトの数により決定された対応長さを有する。例えば、ユーザバッファ510の長さは、ユーザバッファ長さ535である。ユーザバッファ記述子は、ユーザバッファアドレス515のようなユーザバッファアドレスと、ユーザバッファ長さ535のような対応ユーザバッファ長さとを含むデータ構造体である。別の実施形態では、ユーザバッファ記述子は、特殊な取り扱い等を含む記述子フラグを含んでもよい。ユーザバッファ記述子フラグは、とりわけ、PRBコマンドに含まれたユーザバッファへペイロードデータがアップロードされるときにHOTユニット350が通知コマンドを発行することを要求するビットを含むことができる。
【0042】
[0065]更に別の実施形態では、ユーザバッファ記述子は、ユーザバッファアドレス、ユーザバッファ長さ及びユーザバッファエンドアドレスの組合せを含んでもよい。上述したように、ユーザバッファ記述子は、TCPスタック215によりPRBコマンドを使用してHOTユニット250に与えられる。アプリケーションメモリスペース227内に位置する物理的メモリアドレスをHOTユニット250へ与えることで、HOTユニット250は、ペイロードデータをアプリケーションメモリスペース227へ直接的にアップロードすることができる。
【0043】
[0067]アプリケーションプログラム217は、オペレーティングシステムにより割り当てられた仮想的に隣接するアドレススペースであるユーザアドレススペースを管理する。アプリケーションプログラム217がユーザアドレススペース情報をTCPスタック215へ転送するときに、TCPスタック215は、オペレーティングシステムがユーザバッファアドレススペースに対応するメモリをロックすることを要求する。オペレーティングシステムは、ある量のメモリをロックすると共に、システムメモリ130の物理的に隣接する部分に対応する1つ以上の物理的アドレス(及び長さ)をTCPスタック215へ戻す。HOTユニット250によりアクセスされる物理的アドレススペースは、TCPスタック215により管理され、必ずしも物理的に隣接していない。TCPスタック215は、ユーザアドレススペースと物理的アドレススペースとの間を変換する。別の実施形態では、ドライバ255は、ユーザアドレススペースと物理的アドレススペースとの間を変換する。
【0044】
[0068]図5Cは、本発明の1つ以上の態様に基づき図2A及び2Bに示されたドライバメモリスペース235に記憶されるレガシーバッファの実施形態を示す。HOTユニット250によりアップロードされた部分的に処理されたフレームを受信するために、レガシーバッファ550、レガシーバッファ552又はレガシーバッファ554のような各レガシーバッファがドライブメモリスペース235に割り当てられる。レガシーバッファアドレス555のような物理的メモリアドレスは、ドライブメモリスペース235におけるレガシーバッファ550の位置を指示する。同様に、レガシーバッファアドレス560は、レガシーバッファ552の位置を指示し、レガシーバッファアドレス565は、レガシーバッファ554の位置を指示する。レガシーバッファは、ドライブメモリスペース235内の隣接するメモリ位置に記憶されてもよいし、又はドライブメモリスペース235内の非隣接のメモリ位置に記憶されてもよい。
【0045】
[0069]図5Dは、本発明の1つ以上の態様に基づくレガシーバッファタグテーブル590の実施形態を示す。各レガシーバッファアドレスは、独特のタグに関連している。例えば、レガシーバッファアドレス555は、タグ575に関連しており、レガシーバッファアドレス560は、タグ580に関連しており、更に、レガシーバッファアドレス565は、タグ585に関連している。レガシーバッファタグテーブル590は、ドライバ255により維持され、一実施形態ではドライバメモリスペース235に記憶されてもよいし、又は別の実施形態ではTCPスタックメモリスペース225に記憶されてもよい。
【0046】
[0070]図5Eは、本発明の1つ以上の態様に基づくレガシーバッファ記述子の実施形態を示す。各レガシーバッファは、そのレガシーバッファに記憶できるバイトの数により決定された対応する長さを有する。例えば、レガシーバッファ550の長さは、レガシーバッファ長さ570である。別の実施形態では、全てのレガシーバッファの長さが等しい。レガシーバッファ記述子は、レガシーバッファアドレス555のようなレガシーバッファアドレスと、レガシーバッファ長さ570のような対応するレガシーバッファ長さと、タグ575のような対応するタグとを含むデータ構造体である。別の実施形態では、レガシーバッファ記述子は、レガシーバッファアドレスと、レガシーバッファ長さと、タグと、レガシーバッファエンドアドレスとの組合せを含んでもよい。レガシーバッファ記述子は、図6Cに関連して更に説明するように、ドライバ255により受信(バッファ)記述子リングを使用してHOTユニット250へ与えられる。
【0047】
[0071]ドライバ255とHOTユニット250との間の通信は、ドライバメモリスペース235に記憶されたデータ構造体を介して遂行される。リングとは、以下に更に述べるように、多数のエントリーを含むデータ構造体である。リングは、ドライバ255により使用されるポインタ及びHOTユニット250により使用される別のポインタと共にエントリーの円形待ち行列として編成される。各リングは、ドライバメモリスペース235の隣接する物理的メモリに記憶される。
【0048】
[0072]図6Aは、ドライバ255からHOTユニット250へコマンドを転送すると共に、HOTユニット250からドライバ255へ状態を転送するためのコマンドリング601を示す概念図である。このコマンドリング601は、DCT350におけるデレゲート接続エントリーを初期化し、ユーザバッファ記述子をDCT350に与えるのに使用される。コマンドリング601は、図6Aにコマンドリングエントリー603として各々示された多数のエントリーを含む。各コマンドリングエントリー603は、そのエントリーがHOTユニット250又はドライバ255のいずれかにより所有されることを指示する「自分(own)」のビットを含む。スタート時に、各エントリーにおける「自分」のビットは、エントリーがドライバ255により所有されたことを指示するように初期化され、コマンド書き込みポインタ607及びコマンド読み取りポインタ605は、コマンドリング601における同じエントリーである。TCPスタック215がドライバ255を経てエントリーへコマンドを書き込むと、「自分」のビットは、そのエントリーがHOTユニット250により所有されたことを指示するようにセットされ、コマンド書き込みポインタ607は、コマンドリング601内の次のコマンドリングエントリー603を指すように変更される。HOTユニット250が、コマンド読み取りポインタ605によりアドレスされたエントリーを読み取って処理を完了すると、「自分」のビットは、そのエントリーがドライバ255により所有されたことを指示するようにセットされる。コマンド読み取りポインタ605は、コマンド書き込みポインタ607を通すことが許されない。コマンド読み取りポインタ605又はコマンド書き込みポインタ607のいずれかがコマンドリング601の最後のエントリーに到達すると、ポインタは、コマンドリング601の最初のエントリーへラップする。当業者であれば、HOTユニット250へコマンドを通信するのに他のメカニズムを使用してもよく、例えば、コマンドのリンクリスト、FIFO、共有メモリ機構等を使用してもよいことが理解されよう。
【0049】
[0073]「自分」のビットに加えて、各コマンドリングエントリー603は、コマンドフィールド、DCTインデックス、コマンド特有の制御及び/又は状態情報、コマンド特有のデータ等を含む。上述したように、DCTインデックスは、デレゲート接続に対応するDCT350のエントリーを識別する。コマンドフィールドは、PRBコマンド、更新テーブルエントリー(UTE)コマンド、無効化テーブルエントリー(ITE)コマンド、ダンプ接続バッファテーブルエントリー(DCBTE)コマンド等のコマンドに対するコマンド識別子を含む。ドライバ255によりコマンドが書き込まれるときには、コマンド特有の制御/状態情報は、コマンド特有の制御を含む。コマンドが読み取られ、HOTユニット350により更新されるときには、コマンド特有の制御/状態情報は、コマンド特有の状態を含むように更新される。コマンド特有のデータは、以下で更に説明するように、ドライバ255により書き込まれ、HOTユニット350により読み取られる。
【0050】
[0074]PRBコマンドは、TCPスタック215及びドライバ255を経てHOTユニット350へユーザバッファ記述子を通すためにアプリケーションプログラム217により使用される。各ユーザバッファ記述子は、ペイロードデータをアップロードするためにHOTユニット350に対するアプリケーションメモリスペース227の物理的アドレスを指示する。TCPスタックは、1つ以上のユーザアドレスを受け取り、ユーザバッファ記述子に含ませるための対応する物理的アドレスを決定する。TCPスタック215は、単一デレゲート接続テーブルエントリーに対して、アプリケーションプログラム217に代わって、PRBコマンドを使用して、ドライバ255を経て1つ以上のユーザバッファ記述子をポスティングすることができる。ドライバ255は、PRBコマンド内のコマンド特有の制御及び/又は状態情報フィールドにユーザバッファの数を含ませる。ドライバ255は、以前にポスティングされたユーザバッファのどれほど多くがHOTユニット350によりアップロードされたか決定するに必要な情報を有していないので、HOTユニット350は、PRBコマンドから受け入れられたユーザバッファの数を指示する値をコマンド特有の制御及び/又は状態情報フィールドに書き込む。
【0051】
[0075]又、PRBコマンドにおけるコマンド特有の制御及び/又は状態情報フィールドは、「同期(sync)」ビットも含む。TCPスタック215は、図9Bに関連して以下に更に説明するように、アサートされたレガシーフラグを含む通知コマンドがHOTユニット350から通知リング611を経て受信されたときに、「同期」ビットを書き込むようにドライバ255に要求する。
【0052】
[0076]ドライバ255により構成されたPRBコマンドにおけるコマンド特有のデータフィールドは、PRBコマンドでポスティングされる第1バッファの第1バイトに対応するスタートTCPシーケンス番号、PRBコマンドに含まれた各ユーザバッファに対するユーザバッファ記述子等を含む。ユーザバッファ記述子は、アプリケーションメモリスペース227における位置を指定する物理的アドレス、ユーザバッファの長さ、特殊な取り扱いを指示する記述子フラグ等を含む。
【0053】
[0077]UTEコマンドは、ドライバ255によりDCT350のエントリーを更新するのに使用されると共に、デレゲート接続がアクティブである間にデレゲート接続を設定し且つ接続データを更新するのに使用される。ITEコマンドは、デレゲート接続を無効化するのに使用される。HOTユニット250は、ITEコマンドを受信すると、そのITEコマンドに指定されたDCTインデックスに対応するデレゲート接続をクリアする前に、送信エンジン320及び受信エンジン360による処理が完了するのを必要に応じて待機する(新たなTCP処理がスタートするのを阻止しながら)。DCBTEコマンドは、HOTユニット350が、DCBTEコマンドに含まれたDCTインデックスで指定されたエントリーの一部分をレガシーバッファへアップロードするようにさせる。
【0054】
[0078]ドライバ255は、PRBコマンドに対する送信又は受信処理に干渉せずに、コマンドリング601にアクセスすることができる。これは、ドライバ255がHOTユニット350に適時に新たなユーザバッファを与えるのを許し、受信フレームを阻止するのではなくHOTユニット350により受け入れできる見込みを改善する。
【0055】
[0079]図6Bは、HOTユニット250からドライバ255へ事象通知記述子を転送するための通知リング611を示す概念図である。この通知リング611は、HOTユニット250からドライバ255を経てTCPスタック215へ接続情報を搬送する。当業者であれば、HOTユニット250からTCPスタック215へ情報を通信するのに、他のメカニズムを使用してもよく、例えば、通信記述子のリンクリスト、FIFO、共有メモリ機構等を使用してもよいことが理解されよう。
【0056】
[0080]通信リング611は、図6Bに通知リングエントリー613として各々示された多数のエントリーを含む。各通知リングエントリー613は、そのエントリーがHOTユニット250又はドライバ255のいずれかにより所有されることを指示する「自分」のビットを含む。スタート時に、各エントリーにおける「自分」のビットは、エントリーがHOTユニット250により所有されたことを指示するように初期化され、通知書き込みポインタ617及び通知読み取りポインタ615は、通知リング611における同じエントリーである。HOTユニット250が通知記述子をドライバ255に書き込むと、「自分」のビットは、そのエントリーがドライバ255により所有されたことを指示するようにセットされ、通知書き込みポインタ615は、通知リング611内の次の通知リングエントリー613を指すように変更される。ドライバ255が、通知読み取りポインタ617によりアドレスされたエントリーを読み取って処理を完了すると、「自分」のビットは、そのエントリーがHOTユニット250により所有されたことを指示するようにセットされる。通知読み取りポインタ617は、通知書き込みポインタ615を通すことが許されない。通知読み取りポインタ617又は通知書き込みポインタ615のいずれかが通知リング611の最後のエントリーに到達すると、ポインタは、通知リング611の最初のエントリーへラップする。
【0057】
[0081]「自分」のビットに加えて、各通知リングエントリー613は、通知フラグフィールド、DCTインデックス、及び任意のタグであって、これが存在する場合に、DCTインデックスで指定されたデレゲート接続に対して、特定のレガシーバッファへの参照、次に予想されるシーケンス番号、最高の受信ACK番号、最も最近受信した送信ウインドウサイズ、現在TCPタイムスタンプ等を与える任意のタグを含む。通知フラグフィールドは、「レガシー」フラグ、「プッシュ通知」フラグ、「複写ACK」フラグ、「シーケンス番号スレッシュホールド」フラグ、「ACKスレッシュホールド」フラグ、「要求バッファ」フラグ等を含む。「レガシー」フラグは、ペイロードデータ又は部分的にパーズされたフレームデータがHOTユニット250によりレガシーバッファへアップロードされたときにアサートされる。「プッシュ通知」フラグ、「複写ACK」フラグ、「シーケンス番号スレッシュホールド」フラグ、「ACKスレッシュホールド」フラグ、及び「要求バッファ」フラグの機能は、図9Aを参照して説明する。
【0058】
[0082]任意のタグは、図8Cに関連して更に説明するように、HOTユニット250がペイロードデータ又は部分的にパーズされたフレームデータをレガシーバッファへアップロードするときに含まれる。このタグは、以下に更に述べるように、ドライバ255から受信記述子リングを経て受け取られ、このタグを使用して、ペイロードデータ又は部分的にパーズされたフレームデータがアップロードされたレガシーバッファに所与の通知を関連付ける。ドライバ255は、通知と共に受け取られたタグを使用して、そのタグに関連したレガシーバッファタグテーブル590のエントリーを読み取ることにより、ドライバメモリスペース235においてレガシーバッファを探索することができる。
【0059】
[0083]HOTユニット250は、通知リング611を使用して、ドライバ255による更なる処理を要求する接続状態を適時にドライバ255に通知し、しかも、HOTユニット250による送信又は受信処理に対する影響がもしあっても最小であるようにすることができる。通知リング611の動作で、ドライバ255は、HOTユニット350に新たなユーザバッファを適時に与えることが許され、受信フレームを阻止するのではなくHOTユニット350により受け入れることのできる見込みを改善する。
【0060】
[0084]図6Cは、本発明の1つ以上の態様に基づきTCPスタック215からドライバ255を経てHOTユニット250へ受信バッファ情報を転送するための受信記述子リング621を示す概念図である。この受信記述子リング621は、HOTユニット250へレガシーバッファ記述子を与えるのに使用される。非TCPフレーム、非デレゲート接続において受信されたフレーム、異常(予期しないフラグ、シーケンスずれ、無効チェック和、等)を含むデレゲート接続において受信されたフレーム、及びDCT350からアップロードされる接続データを含む多数の形式のデータを、HOTユニット250によりレガシーバッファへアップロードすることができる。当業者であれば、HOTユニット250へバッファ記述子を与えるのに他のメカニズムを使用してもよく、例えば、バッファ記述子のリンクリスト、FIFO、共有メモリ機構等を使用してもよいことが理解されよう。
【0061】
[0085]受信記述子リング621は、図6Cに受信記述子リングエントリー623として各々示された多数のエントリーを含む。各受信記述子エントリー623は、そのエントリーがHOTユニット250又はドライバ255のいずれかにより所有されることを指示する「自分」のビットを含む。「自分」のビットの機能は、図6Aに関連して説明した通りである。受信記述子書き込みポインタ627の機能は、コマンド書き込みポインタ607と同じであり、受信記述子読み取りポインタ625の機能は、コマンド読み取りポインタ605と同じである。
【0062】
[0086]「自分」のビットに加えて、各受信記述子リングエントリー623は、レガシーバッファ記述子、受信制御及び/又は状態フィールド、等を含む。図5Eに関連して既に述べたように、レガシーバッファ記述子は、ドライバメモリスペース235内の位置を指定する物理的アドレス、レガシーバッファ長さ、及び任意のタグを含む。
【0063】
[0087]受信記述子リングエントリー623がドライバ255により書き込まれるときには、受信記述子リングエントリー623は、他のビットの中でも、受信記述子リングエントリー623で指定されたレガシーバッファにデータがアップロードされるときにHOTユニット350が割り込みを発行するのを要求するビットを含むことができる。受信記述子リングエントリー623がHOTユニット350により読み取られて更新されるときには、受信制御及び/又は状態情報は、ペイロードデータ又はパーズされたフレームデータがレガシーバッファへアップロードされるときに接続状態を含むように更新される。レガシーバッファにアップロードされた非デレゲート接続に対してHOTユニット350により書き込まれる受信制御及び/又は状態情報は、受信フレーム終了指示子、最大フレームサイズ超過指示子等を含むことができる。レガシーバッファにアップロードされたデレゲート接続に対してHOTユニット350により書き込まれる受信制御及び/又は状態情報は、スタートバッファ指示子、ユーザバッファ使用不可指示子、受信フレーム終了、レンジ外れACK受信指示子、等を含むことができる。
【0064】
[0088]図6Dは、本発明の1つ以上の態様に基づきTCPスタック215からドライバ255を経てHOTユニット250へ送信バッファ情報を転送するための送信記述子リング631を示す概念図である。この送信記述子リング631は、送信バッファ記述子をHOTユニット250へ与えるのに使用される。当業者であれば、バッファ記述子をHOTユニット250へ与えるのに他のメカニズムを使用してもよく、例えば、バッファ記述子のリンクリスト、FIFO、共有メモリ機構等を使用してもよいことが理解されよう。
【0065】
[0089]送信記述子リング631は、図6Dに送信記述子リングエントリー633として各々示された多数のエントリーを含む。各送信記述子エントリー633は、そのエントリーがHOTユニット250又はドライバ255のいずれかにより所有されることを指示する「自分」のビットを含む。自分のビットの機能は、図6Aに関連して説明した通りである。送信記述子書き込みポインタ637の機能は、コマンド書き込みポインタ607と同じであり、送信記述子読み取りポインタ635の機能は、コマンド読み取りポインタ605と同じである。
【0066】
[0090]「自分」のビットに加えて、各送信記述子リングエントリー633は、送信バッファ記述子、DCTインデックス、送信特有制御、送信制御/状態フィールド、送信バッファバイトカウント、等を含む。送信バッファ記述子は、送信のためのフレームデータが記憶されたアプリケーションメモリスペース227又はTCPスタックメモリスペース225内の位置を指定する物理的アドレスを含む。HOTユニット250は、物理的アドレスを使用して、送信のためのフレームデータをドライバメモリスペース235から読み取る。送信特有の制御は、送信エンジン320がフレームの第1バイトのシーケンス番号をDCT350にセーブするための要求を含むことができる。フレームに対してACKが受け取られると、HOTユニット250は、通知コマンドを発生してもよい。
【0067】
[0091]ドライバ255により書き込まれる送信制御及び/又は状態フィールドは、送信フレーム終了指示子、TCPセグメント化をイネーブルするビット、HOTユニット250においてTCPチェック和計算をイネーブルする1つ以上のビット、TCPセグメント化中に使用するための最大セグメントサイズ等を含むことができる。送信記述子リングエントリー633がHOTユニット250により読み取られて更新されるときには、送信特有の制御及び/又は状態情報が、送信特有の状態を含むように更新される。送信特有の状態は、キャリアロス指示子、送信再試みカウント、再試みエラー等を含むことができる。
【0068】
[0092]図7は、本発明の1つ以上の態様に基づく図3に示されたHOTユニット250の一部分を含むブロック図である。DCT350は、ドライバ255からコマンドリング601を経て受け取られたコマンドを処理するためのCMDユニット710を備えている。デレゲート接続情報は、DCT350内において、接続バッファテーブル(CBT)715、接続データテーブル(CDT)720、及び接続一致テーブル(CMT)725に記憶される。CBT715、CDT720、及びCMT725内のデレゲート接続のエントリーは、CMDユニット710により書き込むことができる。CMT725は、デレゲート接続識別情報を記憶し、CMT725は、デレゲート接続が設定されたときにCMDユニット710により書き込まれる。CMT725において、デレゲート接続に対応するエントリーは、接続がデレゲートされたままである限り又は接続が終了するまで、その対応性を維持する。CMT725のエントリーは、行先IPアドレス、ソースIPアドレス、ソースTCPポート、行先TCPポート等を含む。
【0069】
[0093]CDT720のエントリーは、デレゲート接続が設定されたときにCMDユニット710により初期化される。CDT720内のエントリーは、予想されるシーケンス番号、ACK番号、タイムスタンプデータ、非確認(unACKnowledged)フレームのカウント、等のデレゲート接続に対するデレゲート接続状態情報を含む。CDT720のエントリー内のフィールドは、フレームがデレゲート接続上で送信するように構成されたときに、送信エンジン320により読み取られて任意に変更される。同様に、CDT720のエントリー内のフィールドは、デレゲート接続上の到来フレームが処理されるときに、受信エンジン360内のユニットにより読み取られて任意に変更される。CBT715のエントリーは、PRBコマンドがデレゲート接続に対して受信されたときに、CMDユニット710により1つ以上のユーザバッファ記述子と共に書き込まれる。ユーザバッファ情報は、受信エンジン360内のバッファアップロードユニット745により読み取られて任意に変更される。
【0070】
[0094]デレゲート接続情報は、CBT715に影響するユーザバッファポスティングからCDT720に記憶された状態情報のアクセスを減結合するように、CBT715、CDT720及びCMT725間に分布されている。更に、状態情報は、最も最近受信したフレームに基づいて受信エンジン360により更新されるので、送信エンジン320及びTCPスタック215は、フレーム構成中に現在状態情報にアクセスすることができる。同様に、状態情報は、最も最近送信されたフレームに基づいて送信エンジン320により更新されるので、受信エンジン360及びTCPスタック215は、フレーム処理中に最新の状態情報にアクセスすることができる。
【0071】
[0095]受信インターフェイス370内において、バッファである受信FIFO730は、到来するフレームをバッファする。受信インターフェイス370は、受信エンジン360内の前パーズユニット735にフレーム及び有効フレーム指示子を出力する。前パーズユニット735は、有効フレームをパーズして、部分的にパーズされたフレームを発生すると共に、CMT725を読み取って、デレゲート接続上にフレームが受信されたかどうか決定する。前パーズユニット735は、部分的にパーズされたフレームをパージングユニット740へ出力する。このパージングユニット740は、各々の部分的にパーズされたフレームのプロトコル形式、例えば、TCP、UDP、IP等を決定し、そして任意であるが、その部分的にパーズされたフレームをパーズして、パーズされたフレーム及び部分的にパーズされたフレームを発生する。パージングユニット740は、CDT720を読み取り、1つ以上の特殊なケースが存在するかどうか決定し、更に、部分的にパーズされたフレーム、パーズされたフレーム、又はフレームをバッファアップロードユニット745へ出力する。又、パージングユニット740は、任意であるが、通知ユニット750内のレジスタのような記憶素子に記憶された以下で更に説明する通知フラグをセットする。
【0072】
[0096]バッファアップロードユニット745は、CBT715を読み取り、そして任意であるが、CBT715及びCDT720に書き込みを行なう。バッファアップロードユニット745は、フレーム、部分的にパーズされたフレーム、及びパーズされたフレームを、DMAエンジン310を経てシステムメモリ130へアップロードする。バッファアップロードユニット745は、CBT715に記憶されたユーザバッファ記述子又はドライバ255から受信記述子リング621を経て受信したレガシーバッファ記述子に記憶されたデータに基づいて、システムメモリ130に書き込むべき位置を指定する。同様に、送信エンジン320は、ドライバ255から送信記述子リング631を経て受信された送信バッファ記述子に基づいて、システムメモリ130において読み取るべき位置を指定する。通知ユニット750は、ドライバ255への通知を、DMAエンジン310を経て通知リング611へ出力する。
【0073】
[0097]限定された数の接続に対するデレゲート接続情報は、CMT725に記憶され、限定された数に到達した後に、過剰な接続に対する接続情報は、システムメモリ130内のCT245(図2A又は2B)のみに記憶される。一実施形態では、CT245の接続情報にアクセスして、過剰な接続に対して到来するフレーム及び出て行くフレームを処理するのではなく、HOTユニット250が、部分的に処理されたフレームをドライバメモリスペース235内のレガシーバッファにアップロードする。別の実施形態では、HOTユニット250は、DCT350をキャッシュとして取り扱い、必要に応じてCT245にアクセスして、当該接続データを探索する。TCPスタック215は、HOTユニット250により遂行される付加的な到来するフレーム又は出て行くフレームの処理とは独立して、部分的に処理されたフレームの処理を完了する。それ故、過剰接続のレガシー処理は、通常、HOTユニット250なしにコンピュータシステム200でフレームを処理する場合以上のレートで行なわれる。このレートは、フレームがHOTユニット250により部分的に処理されるので良好であり、受信インターフェイス370で遂行されたフレーム確認の結果も、ドライバメモリスペース235へアップロードされる。更に、ドライバ255及びTCPスタック215によるレガシー処理は、HOTユニット250による送信処理又はHOTユニット250による受信処理と同時に進行することができる。
【0074】
[0098]図8Aは、本発明の一実施形態に基づき有効フレームを処理するための方法ステップを示すフローチャートである。ステップ801において、受信エンジン360内の前パーズユニット735により有効フレームが受信される。ステップ803において、前パーズユニット735は、有効フレームがTCPフレームであるかどうか決定し、もしそうでなければ、ステップ805において、当業者に知られた非TCP処理が完了される。一実施形態では、受信エンジン360は、受信したUDPフレームの処理を完了する。別の実施形態では、受信エンジン360は、他のプロトコルの処理を完了する。更に別の実施形態では、受信エンジン360は、他のプロトコルのフレームをドライバメモリスペース235へアップロードし、ドライバ255に通知する。
【0075】
[0099]ステップ803において、前パーズユニット735が、有効フレームがTCPフレームであると決定した場合には、ステップ807において、前パーズユニット735は、CMT725から1つ以上のエントリーを読み取る。ステップ809において、前パーズユニット735は、以下「フレーム」と称されるTCPフレームがデレゲート接続において受信されたかどうか決定し、即ちフレームがCMT725のエントリーに一致するかどうか決定する。前パーズユニット735は、行先IPアドレス、ソースIPアドレス、ソースTCPポート及び行先TCPポートをフレームから抽出し、それらの値を使用して、CMT725における一致エントリーをサーチする。一致は、接続がデレゲートされていることを指示する。ステップ809において、前パーズユニット735が、フレームがデレゲート接続において受信されなかったと決定した場合には、ステップ813において、フレームのレガシー処理が完了となる。前パーズユニット735は、パージングユニット740を経てバッファアップロードユニット745へフレームを出力し、フレームがデレゲート接続において受信されなかったことを指示することにより、レガシー処理を開始する。バッファアップロードユニット745は、少なくとも部分的にパーズされたフレームを、DMAエンジン310を経てドライバメモリスペース235へアップロードし、以下に詳細に述べるように、レガシー処理の要求と共にドライバ255に通知する。
【0076】
[00100]ステップ809において、前パーズユニット735が、フレームがデレゲート接続において受信されたと決定した場合には、ステップ811において、前パーズユニット735は、部分的に処理されたフレームをパージングユニット740へ出力する。ステップ811では、パージングユニット740は、部分的に処理されたフレームをパーズして、パーズされたフレームを発生すると共に、特殊なケース、例えば、IP又はTCPオプション、無効フラグ等があるかどうか決定し、もしそうであれば、ステップ812において、パージングユニットは、パーズされたフレームをバッファアップロードユニット745へ出力して、特殊なケースがあることを指示する。ステップ812において、バッファアップロードユニット745は、デレゲート接続に対応するCBT720のエントリーにおいて「同期要求」フラグをセットし、又、デレゲート接続に対応するCBT715のエントリーにあるユーザバッファ記述子をフラッシュする。ステップ813において、バッファアップロードユニット745は、パーズされたフレームを、DMAエンジン310を経てドライバメモリスペース235へアップロードし、レガシー処理の要求と共にドライバ255に通知する。ステップ812においてデレゲート接続に対して「同期要求」フラグをセットすると、デレゲート接続がレガシー処理を使用して処理されることを指示する。受信エンジン360は、図9Aに関連して更に述べるように、将来のバッファポスティング事象により同期要求フラグがクリアされるまで、デレゲート接続に対するユーザバッファ記述子コマンドを受け入れない。
【0077】
[00101]ステップ811において、パージングユニット740が、特殊なケースがないと決定した場合には、ステップ815において、パージングユニット740は、デレゲート接続に対応するCDT720のエントリーを読み取る。ステップ817において、パージングユニット740及びバッファアップロードユニット745は、図9Aに関連して更に説明するように、通知ユニット750に記憶された通知フラグがもしあれば、どれがセットされたか決定する。ステップ819において、パージングユニット740は、TCPフレームから抽出されたシーケンス番号(SN)が、デレゲート接続に対応してCDT720のエントリーに記憶されたシーケンス番号(DCT SN)に等しくないかどうか決定し、もしそうであれば、ステップ821において、パージングユニット740によりシーケンスずれ回復が要求される。シーケンスずれ回復は、図8Bに関連して更に説明する。
【0078】
[00102]ステップ819において、パージングユニット740が、SNがDCT SNに等しいと決定すると、ステップ823において、パージングユニット740は、パーズされたフレームをバッファアップロードユニット745へ出力する。ステップ823において、バッファアップロードユニット745は、デレゲート接続に対応するCBT715のエントリーを読み取る。ステップ825において、バッファアップロードユニット745は、ユーザバッファが使用可能かどうか決定する。「ユーザバッファ」という語は、「HOTバッファ」という語と交換可能である。HOTバッファが使用できない場合には、ステップ827において、バッファアップロードユニット745は、HOTバッファが使用可能になるのを待機するか、又はパーズされたTCPフレームを、DMAエンジン310を経てレガシーバッファへアップロードする。これについては、図8Cに関連して更に説明する。
【0079】
[00103]ステップ825において、バッファアップロードユニット745が、HOTバッファが使用可能であると決定すると、ステップ829において、バッファアップロードユニット745は、パーズされたフレームの処理を完了し、ペイロードデータの少なくとも一部分をHOTバッファへアップロードする。これについては、図8Dに関連して更に説明する。ステップ831において、ペイロードデータの一部分をHOTバッファにアップロードした後に、バッファアップロードユニット745は、パーズされたフレームに付加的なペイロードデータがあるかどうか決定し、もしあれば、ステップ825及び829を繰り返す。ステップ831において、バッファアップロードユニット745が、全てのペイロードデータが1つ以上のHOTバッファへアップロードされたと決定すると、ステップ833において、バッファアップロードユニットは、パーズされたフレームにおけるTCP「プッシュ」フラグがアサートされたかどうか決定する。ステップ833において、バッファアップロードユニット745が、TCP「プッシュ」フラグがアサートされたと決定すると、バッファアップロードユニット745は、デレゲート接続に対応するCBT715のエントリーに対して「同期要求」フラグをセットし、デレゲート接続に対応するCBT715のエントリーにおけるユーザバッファ記述子をフラッシュする。ステップ833において、バッファアップロードユニット745が、TCP「プッシュ」フラグがアサートされないと決定すると、受信エンジン360は、ステップ801へ進む。
【0080】
[00104]図8Bは、本発明の一実施形態に基づきシーケンスずれフレームを処理するための方法ステップを示すフローチャートである。当業者であれば、図8Bを参照して述べる方法ステップは、図8Aのステップ821を遂行する1つのやり方を構成することが理解されよう。シーケンスずれ回復は、DCT SNに記憶された値に基づいて予想されるものより大きなSN(例えば、1つ以上の失われたフレームから生じる)、又はDCT SN未満のSN(例えば、送信時間切れ又は失われたACKのためにフレームの再送信から生じる)を含むケースを取り扱う。SNがDCT SNより大きいときには、受信エンジン360は、3回までの連続する同一構成のACK(正しいシーケンスで受け取った最後のフレームに各々対応する)の送信を含む「高速回復」アルゴリズムを実行し、デレゲート接続に対してユーザバッファを無効化し(フラッシュし)、次いで、全フレームを1つ以上のレガシーバッファにアップロードする。SNがDCT SN未満であるときには、受信エンジン360は、フレームに対してACKを送信し、デレゲート接続に対してユーザバッファを無効化し、次いで、全フレームを1つ以上のレガシーバッファへアップロードする。
【0081】
[00105]ステップ830において、パージングユニット740は、フレームから抽出されたSNが、図8Aのステップ815においてCDT720から読み取られたDCT SN未満であるかどうか決定し、もしそうであれば、ステップ832において、パージングユニット740は、フレームに対してACKを発生するように送信エンジン320に信号する。又、ステップ832において、パージングユニット740は、パーズされたフレームをバッファアップロードユニット745へ出力し、ステップ838へ進む。ステップ830において、パージングユニット740が、フレームから抽出されたSNがDCT SN未満でないと決定した場合には、ステップ834において、パージングユニット740は、ステップ815においてCDT720から読み取られた「高速ACK」値が3未満であるかどうか決定し、もしそうであれば、パージングユニット740は、ステップ836において、パーズされたフレームに対してACKを発生するように送信エンジン320に信号する。又、ステップ836において、パージングユニット740は、パーズされたフレームをバッファアップロードユニット745へ出力すると共に、CDT720に記憶された「高速ACK」値を増加するようにバッファアップロードユニット745に指示する。
【0082】
[00106]ステップ833において、バッファアップロードユニット745は、CBT715に記憶されたデレゲート接続に対応するHOTバッファをフラッシュする。ステップ840において、バッファアップロードユニット745は、CBT715におけるデレゲート接続に対応する「同期要求」フラグをセットし、そして任意であるが、CDT720に記憶されたデレゲート接続に対する接続状態データ、例えば、高速ACK、DCT SN、ACK番号等を更新する。ステップ813において、バッファアップロードユニット745は、パーズされたTCPフレームを、DMAエンジン310を経てドライバメモリスペース235へアップロードし、レガシー処理の要求と共にドライバ255に通知する。
【0083】
[00107]図8Cは、本発明の一実施形態に基づきユーザバッファを待機するための方法ステップを示すフローチャートである。当業者であれば、図8Cを参照して説明する方法ステップは、図8Aのステップ827を遂行する1つのやり方を構成することが理解されよう。受信エンジン360は、ユーザバッファにアップロードされたデータがTCPスタック215によりドライバメモリスペース235からアプリケーションメモリスペース227へコピーされる必要がないので、パーズされたフレーム又は部分的にパーズされたフレームをレガシーバッファにアップロードするのではなく、ユーザバッファを待機する。更に、デレゲート接続がレガシーバッファを使用して処理されると、TCPスタック215は、「同期要求」フラグに応答しなければならず、その結果、「同期要求」フラグは、デレゲート接続に対するパーズされたフレーム又は部分的にパーズされたフレームが受信エンジン360によりユーザバッファへアップロードされる前に、クリアされる。
【0084】
[00108]ステップ850において、バッファアップロードユニット745は、「要求バッファ」フラグが、デレゲート接続に対応して図8Aのステップ823で読み取られたエントリーにおいてセットされたかどうか決定する。「要求バッファ」フラグがセットされない場合には、ステップ852において、バッファアップロードユニット745は、デレゲート接続に対応するCBT715のエントリーにおける要求バッファフラグをセットし、バッファ要求タイマーを、レジスタに記憶された値に初期化する。別の実施形態では、バッファ要求タイマーは、デレゲート接続に対応するCBT715のエントリーに記憶された値に初期化される。ステップ850において、バッファアップロードユニット745が、「要求バッファ」フラグがセットされたと決定した場合には、バッファアップロードユニット745は、ステップ862へ進む。
【0085】
[00109]ステップ854において、バッファアップロードユニット745は、「スタートアップ限界」値で決定された数のバイトを、DMAエンジン310を経てレガシーバッファへアップロードする。TCPスタック215により初期化されるスタートアップ限界は、デレゲート接続に対応してCDT720のエントリーに記憶される。ステップ856において、バッファアップロードユニット745は、通知ユニット750に記憶された「要求バッファ」フラグをセットし、この通知ユニット750は、通知リングを経てドライバ255へ通知を発行する。通知は、関連レガシーバッファ記述子からのタグフィールドに使用された同じタグ値を含む。通知ユニット750は、通知を送信した後に通知フラグをクリアする。当業者に知られた技術を使用して、パーズされたフレームがドライバメモリスペース235へアップロードされた後、ドライバ255がそれに対応する通知を受信するように確保する。
【0086】
[00110]ステップ858において、バッファアップロードユニット745は、受信FIFO730の「いっぱい状態」を指示する値が限界値、例えば「高水位線」マークより高いかどうか決定し、もしそうであれば、バッファアップロードユニット745は、ステップ862へ進む。一実施形態では、高水位線マークが固定である。別の実施形態では、高水位線マークが、ドライバ255によりプログラムされたレジスタに記憶される。ステップ858において、バッファアップロードユニット745が、受信FIFO730の「いっぱい状態」を指示する値が「高水位線」マークより高くないと決定した場合に、ステップ860において、バッファアップロードユニット745は、バッファ要求タイマーが時間切れしたかどうか決定する。ステップ860において、バッファアップロードユニット745が、バッファ要求タイマーが時間切れしたと決定した場合には、ステップ862において、バッファアップロードユニット745は、CBT715に記憶された「同期要求」フラグ及び通知ユニット750に記憶されたレガシーフラグをセットする。ステップ813において、バッファアップロードユニット745は、パーズされたフレームを、DMAエンジン310を経てドライバメモリスペース235へアップロードする。通知ユニット750は、通知リングを経てドライバ255へ通知を発行し、通知ユニット750は、通知フラグをクリアし、更に、受信エンジン360は、図8Aのステップ801へ復帰する。通知は、関連レガシーバッファ記述子からのタグフィールドに使用された同じタグ値を含む。当業者に知られた技術を使用して、パーズされたフレームがドライバメモリスペース235へアップロードされた後、ドライバ255がそれに対応する通知を受信するように確保する。
【0087】
[00111]ステップ860において、バッファアップロードユニット745が、バッファ要求タイマーが時間切れしないと決定した場合には、ステップ864において、バッファアップロードユニット745は、ユーザバッファが使用可能であるかどうか、即ちアプリケーションプログラムがコマンドリングを経てユーザバッファをポスティングしたかどうか決定する。ユーザバッファが使用可能でない場合には、バッファアップロードユニット745は、ステップ858に復帰する。ユーザバッファが使用可能である場合には、バッファアップロードユニット745は、ステップ829において、パーズされたフレームの処理を完了し、ペイロードデータをユーザバッファへアップロードする。これについては、図8Dに関連して更に説明する。ステップ829に続いて、受信エンジン360は、図8Aのステップ831へ復帰する。
【0088】
[00112]図8Dは、本発明の一実施形態に基づきHOTバッファ処理を完了するための方法ステップを示すフローチャートである。当業者に明らかなように、図8Dを参照して述べる方法ステップは、図8Aのステップ829を遂行する1つのやり方を構成する。HOTユニット250が到来するデータを受信したときには、ACKを送信者(行先接続)へ送信して、どれほど多くのデータをHOTユニット250へ送信できるか指示する受信ウインドウを、受信経路の飽和を許すに充分な巾で開いたままにするよう確保しなければならない。受信したフレームが適時に確認されないときには、受信ウインドウを閉じることが必要となり、さもなければ、送信者の再送信タイマーが時間切れとなって、送信者が1つ以上のフレームを再送信することになる。
【0089】
[00113]ACKを送信者に送信するのに加えて、ドライバ255は、フレームがHOTユニット250により受信されたときに、シーケンス番号、タイマー等に基づいて通知される。CDT720は、受信したTCPペイロードのサイズだけDCT SNを増加することにより更新され、非確認フレームのカウントが増加され、更に、TCPタイムスタンプオプションが受信フレームに適当に含まれていた場合には、受信フレームから抽出された最も最近受信されたTCPタイムスタンプがデレゲート接続に対してCDT720に記憶される。
【0090】
[00114]ステップ876において、パージングユニット740は、非確認フレームのカウントが非確認フレーム限界より大きいかどうか決定し、もしそうであれば、ステップ880へ進む。非確認フレーム限界は、接続に対してCDT720に記憶され、TCKスタック215により決定される。別の実施形態では、パージングユニット740は、ステップ876において、デレゲート接続上で受信された非確認フレームのカウントが、非確認フレーム限界以上であるかどうか決定する。更に別の実施形態では、バッファアップロードユニット745は、非確認フレームのカウントが非確認フレーム限界より大きいかどうか決定する。
【0091】
[00115]ステップ876において、パージングユニット740が、非確認フレームのカウントが非確認フレーム限界以下であると決定した場合には、ステップ878において、パージングユニット740は、送信タイマーが時間切れしたかどうか決定する。送信ACKタイマーは、送信者が適時にACKを受信しないことによる不必要な再送信を最小にするために、送信者の再送信タイマーが時間切れする前に時間切れするように構成される。一実施形態では、送信ACKタイマーの時間切れ周期は、全デレゲート接続に対して一定である。別の実施形態では、送信ACKタイマーの時間切れ周期は、デレゲート接続ごとにTCPスタックによりプログラムされてもよい。
【0092】
[00115]ステップ878において、パージングユニット740が、送信ACKタイマーが時間切れしたと決定した場合には、ステップ880において、パージングユニット740は、パーズされたフレームに対するACKを発生するように送信エンジン320に信号し、送信エンジン320は、パーズされたフレームをバッファアップロードユニット745へ出力する。ステップ882において、バッファアップロードユニット745は、接続に対してCDT720のエントリーに記憶された非確認フレームカウントをゼロにセットすることによりこれを更新すると共に、「最後の送信ACK」値を、フレームから抽出されたSN値へ更新する。又、バッファアップロードユニット745は、増分的ACK番号、増分的シーケンス番号、等の接続状態データも更新し、送信ACKタイマーをリセットした後に、ステップ886へ進む。
【0093】
[00117]ステップ878において、バッファアップロードユニット745が、送信ACKタイマーが時間切れしないと決定した場合には、ステップ884において、バッファアップロードユニット745は、例えば、非確認フレームのカウント等を更新することにより、CDT720におけるデレゲート接続に対応するエントリーを更新する。
【0094】
[00118]ステップ886において、ペイロードデータは、バッファアップロードユニット745によりDMAエンジン310を経てアプリケーションメモリスペース227のHOTバッファTCPへアップロードされる。ステップ888において、通知ユニット750は、通知フラグがセットされたかどうか決定し、もしそうであれば、ステップ890において、通知ユニット750は、通知リングを経てドライバ255へ通知を発行する。通知ユニット750は、通知フラグ、送信ウインドウサイズ、SN、最後のACK番号、TCPタイムスタンプ値、レガシー記述子からのタグ値等を含む事象通知記述子を構成する。通知ユニット750は、通知を送信した後に、通知フラグをクリアする。
【0095】
[00119]通知ユニット750は、事象通知記述子をDMAエンジン310へ出力し、このDMAエンジンは、事象通知記述子を、ドライバメモリスペース235に記憶されたオフロード事象通知リングへ転送する。オフロード事象通知リングは、隣接メモリブロックにおいて円形待ち行列として編成される。HOTユニット250は、オフロード事象通知リングを書き込み、ドライバ255は、オフロード事象通知リングを読み取る。TCPスタック215は、オフロード事象通知リングから読み取られたデータを使用してCT245を更新し、これにより、CT245とDCT350との間にコヒレンスを維持する。又、TCPスタック215は、CDT715からのエントリーを1つ以上のレガシーバッファにアップロードすることによりCT245とDCT350との間にコヒレンスを維持してもよい。
【0096】
[00120]ステップ890に続いて、受信エンジン360は、ステップ801へ戻り、別の有効フレームを処理する。ステップ888において、通知ユニット750が、1つ以上の通知フラグがセットされないと決定した場合には、受信エンジン360は、ステップ801へ戻り、別の有効フレームを処理する。
【0097】
[00121]図9Aは、本発明の一実施形態に基づき通知を決定するための方法ステップを示すフローチャートである。当業者に明らかなように、図9Aを参照して説明する方法ステップは、図8Aのステップ817を遂行する1つのやり方を構成する。各フレームが行先により受信されたことを、ドライバ255を経てTCPスタック215に通知するためにCPU110に割り込むのではなく、スレッシュホールドを使用して、HOTユニット250により受信されたシーケンス番号をドライバ255又はTCPスタック215へ通信する頻度を制御してもよい。同様に、送信フレームごとにACKが受信されたことをドライバ255に通知するためにCPU110に割り込むのではなく、ACKスレッシュホールド又は特定のACK番号を使用して、HOTユニット250により受信されたACKをドライバ255へ送信するのを制御してもよい。
【0098】
[00122]フレーム処理中にCPU110が受ける割り込みの頻度を下げることで、他のアプリケーションを実行するようにCPU110を解放し、通常は、CPU110が実行するアプリケーション命令の数を増加することによりこれらアプリケーションの性能を改善する。スレッシュホールドは、デレゲート接続に対して受信接続状態及び送信接続状態をTCPスタック215に通知するための割り込みと割り込みとの間のバランスを決定する上で融通性を許す。
【0099】
[00123]ステップ901において、パージングユニット740は、送信ウインドウが右から収縮するかどうか決定する。パージングユニット740は、フレームから抽出したACK番号をフレームから抽出した受信ウインドウサイズと加算したものが、デレゲート接続に対してCDT720に記憶された最大送信ウインドウサイズより小さいときに、送信ウインドウが右から収縮すると決定する。バッファアップロードユニット745は、デレゲート接続に対してCDT720に記憶された最大送信ウインドウサイズを、フレームから抽出した送信ウインドウサイズで更新する。ステップ901において、パージングユニット740が、送信ウインドウが右から収縮していると決定した場合には、ステップ903において、パージングユニット740は、通知ユニット750の送信ウインドウ通知フラグをセットする。
【0100】
[00124]ステップ905において、パージングユニット740は、複写ACK(1つ以上の受信フレームにおいて同じACK番号)が受け取られたかどうか決定し、これは、行先が1つ以上のフレームの再送信を要求していることを指示する。ステップ905において、パージングユニット740が、複写ACKが受け取られたと決定した場合には、ステップ903において、パージングユニット740は、通知ユニット750の「複写ACK通知」フラグをセットする。
【0101】
[00125]ステップ907において、パージングユニット740は、SNがスレッシュホールド例えば限界より大きいかどうか決定し、このスレッシュホールドは、増分的シーケンス番号を指示する。この増分的シーケンス番号は、デレゲート接続が設定されるときにTCPスタック215により初期化されると共に、通知がドライバ255へ送信されるときにバッファアップロードユニット745により更新される。一実施形態において、増分的シーケンス番号は、その増分的シーケンス番号をシーケンス増加値で増加することにより更新される。このシーケンス増加値は、固定でもよいし、又はTCPスタック215によりプログラムされてもよい。ステップ907において、パージングユニット740が、SNがスレッシュホールドより大きいことを決定すると、ステップ903において、シーケンス番号スレッシュホールドフラグがセットされる。
【0102】
[00126]ステップ909において、パージングユニット740は、CDT720に記憶された最後のACK番号(デレゲート接続に対して受け取られた最も進んだACK番号)が、増分的ACK番号を指示する限界より大きいかどうか決定する。最後のACK番号は、デレゲート接続が設定されたときにTCPスタック215により初期化され、そしてACKが受け取られたときにバッファアップロードユニット745により更新される。増分的ACK番号は、デレゲート接続が設定されたときにTCPスタック215により初期化され、そして通知がTCPスタック215へ送信されたときにバッファアップロードユニット745により更新される。一実施形態において、増分的ACK番号は、その増分的ACK番号をACK増加値で増加することにより更新される。このACK増加値は、固定でもよいし、又はTCPスタック215によりプログラムされてもよい。
【0103】
[00127]ステップ909において、パージングユニット740は、CDT720に記憶された最後のACK番号が、TCPスタック215によりプログラムされた特定のACK番号を指示する他の限界より大きいかどうか決定してもよい。ステップ909において、パージングユニット740が、最後のACK番号が限界(増分的ACK番号を指示する)又は他の限界(特定のACK番号を指示する)より大きいと決定した場合には、ステップ903において、ACKスレッシュホールドフラグがセットされる。
【0104】
[00128]ステップ911において、パージングユニット740は、1つ以上のタイマーが時間切れしたかどうか決定する。受信ACKタイマーは、不必要な再送信を最小にするために、TCPスタック215の再送信タイマーが時間切れする前に時間切れするように構成される。レジスタに記憶されたデレゲート接続に対する受信ACKタイマーの時間切れ周期は、TCPスタック215によってプログラムされてもよいし、デレゲート接続に対するラウンドトリップ時間に基づいてもよい。受信SNタイマーは、HOTユニット250によりデータが受信されたことをTCPスタック215に通知するように構成される。レジスタに記憶されたデレゲート接続に対する受信SNタイマーの時間切れ周期は、TCPスタック215によりプログラムされてもよい。別の実施形態では、受信ACKタイマー及び受信SNタイマーの時間切れ周期は、デレゲート接続に対応するCMT725のエントリーに記憶される。
【0105】
[00129]ステップ911において、パージングユニット740が、タイマーが時間切れしたと決定された場合には、それに対応する通知フラグがステップ903において更新され、パージングユニット740がステップ913へ進む。例えば、受信SNタイマーが時間切れしたときには、「シーケンス番号スレッシュホールド」フラグがセットされ、一方、受信ACKタイマーが時間切れしたときには、「ACKスレッシュホールド」フラグがセットされる。ステップ911において、受信エンジン360が、1つ以上のタイマーがいずれも時間切れしないと決定すると、パージングユニット740は、ステップ913において、パーズされたフレームをバッファアップロードユニット745へ出力し、このバッファアップロードユニット745は、フレームから抽出したプッシュフラグがアサートされたかどうか決定する。プッシュフラグがアサートされた場合には、ステップ903においてプッシュ通知フラグがセットされ、バッファアップロードユニット745は、図8Aのステップ819へ進む。
【0106】
[00130]図9Bは、本発明の一実施形態に基づきレガシー処理に続いてユーザバッファを同期するための方法ステップを示すフローチャートである。既に述べたように、デレゲート接続は、シーケンス番号が予想シーケンス番号DCT SNより大きいフレームをパージングユニット740が検出したときにレガシーバッファを使用して処理される。例えば、1つ以上のフレームが送信エラーにより失われたときに、通知ユニット750は、接続に対してレガシー処理を要求し、そしてバッファアップロードユニット745は、接続に対してHOTバッファを無効化する。CDT720に記憶されたSNは変化しないので、その後に受け取られる全てのフレームは、再送信が行われるまでシーケンスずれであると考えられる。
【0107】
[00131]再送信フレームが受け取られるまで、バッファアップロードユニット745は、接続に対して受け取られたフレームをレガシーバッファへアップロードする。TCPスタック215は、ペイロードデータをレガシーバッファからユーザバッファへコピーする。再送信フレームがレガシーバッファへアップロードされると、TCPスタック215は、正しいシーケンスで受け取られた全てのフレームに対してACKを送信する。送信エンジン320は、接続に対してCDT720に記憶されたDCT SNを更新する。シーケンス内の全ての再送信フレームがレガシーバッファへアップロードされると、TCPスタック215は、ACKを送信する前にHOTバッファをポスティングする。HOTバッファをポスティングすることで、バッファアップロードユニット745は、ユーザバッファを要求せずにHOTバッファを使用して接続に対する到来フレームの処理を再開することが許される。
【0108】
[00132]ステップ930において、CMDユニット710は、コマンドリングからDMAエンジン310を経てPRBコマンドを受け取る。PRBコマンドは、他のフィールドの中でも、接続に対するエントリーに対応するDCTインデックスと、同期ビットとを含む。ステップ932において、CMDユニット710は、インデックスを使用してCBT715を読み取る。ステップ934において、CMDユニット710は、CBT715のエントリーから読み取られた同期要求フラグがセットされたかどうか決定し、もしそうであれば、ステップ936において、CMDユニット710は、PRBコマンドの同期ビットがセットされたかどうか決定する。ステップ934において、CMDユニット710が、CBT715のエントリーから読み取られた「同期要求」フラグがセットされないと決定すると、CMDユニット710は、ステップ938において、CBT715のエントリーの「同期要求」フラグをクリアし、ステップ940へ進む。「同期要求」フラグがクリアされると、HOTバッファを使用して接続を処理することができる。ステップ936において、CMDユニット710が、PRBコマンドの同期ビットがセットされないと決定すると、「同期要求」フラグはクリアされず、接続は、レガシー処理を使用して処理され続ける。
【0109】
[00133]送信エンジン320は、TCPスタック215から出て行くフレームをオフロード処理するサブユニットを備えている。例えば、送信エンジン320は、TCPセグメント化を遂行し、TCP及びIPv4チェック和を計算し、更に、ACKをピギーバック搬送するように出て行くフレームを編集すると共に、デレゲート接続に対する最新の状態データ(DCT350から読み取られた)を含むように構成されてもよい。ドライバ255又は受信エンジン360によりなされるDCT350に対する更新は、以下に説明するように、送信に含まれてもよい。
【0110】
[00134]図10Aは、例えば、「大型発信」送信中に、本発明の1つ以上の態様に基づきDMAエンジン310によりシステムメモリ130からHOTユニット250へデータが転送されるときに送信用のデータを表わすのに使用されるフォーマットを示す。フィールド1007は、イーサネットヘッダのような媒体特有のMACヘッダである。フィールド1005は、MACヘッダを含むプロートタイプヘッダと、IPヘッダと、SN、送信ACK番号、TCPタイムスタンプ等を含むTCPヘッダである。フィールド1010は、送信用のデータであり、TCPスタックメモリスペース225に配置される。フィールド1007、フィールド1005及びフィールド1010の組合体は、システムメモリ130に存在する。
【0111】
[00135]図10Bは、本発明の1つ以上の態様に基づき送信エンジン320から送信インターフェイス330へデータが送信されるときに送信用のデータを表わすのに使用されるフォーマットを示す。DMAエンジン310は、システムメモリスペース130から図10Aに示すフォーマットを読み取り、そして送信エンジン320は、セグメント化が実行可能となり且つフィールド1010の一部分がセグメントに含まれるときに図10Bに示すフォーマットを発生し、ここで、各セグメントはフレームである。送信インターフェイス330は、図10Bに示すIPデータグラムフォーマットをフレームとして出力する。別の実施形態では、TCPスタック215は、プロトコルヘッダを発生し、そのプロトコルヘッダをTCPスタックメモリスペース225に記憶する。プロトコルヘッダは、HOTユニット250によりTCPスタックメモリスペース225から読み取られ、送信用のデータは、HOTユニット250によりアプリケーションメモリスペース227から読み取られる。
【0112】
[00136]フィールド1015はIPヘッダであり、フィールド1020はTCPヘッダであり、フィールド1025はセグメント化データである。当業者に明らかなように、図10Bに示すフォーマットは、TCPに準拠するフォーマットである。TCPヘッダは、送信ACK番号、送信SN等を含む。セグメント化データは、フィールド1010における送信用データの一部分である。フィールド1030は、任意に更新される送信ACK番号、更新される送信SN等を含む別のTCPヘッダである。更新される送信SNは、以前のセグメントに含まれたデータバイトの量だけ増加され、これは、最大フレームサイズと、データリンク、ネットワーク及び搬送層ヘッダサイズとの間の差と同じである。フィールド1035は、フィールド1010における送信用データの別の部分であるセグメント化データである。
【0113】
[00137]図11Aは、本発明の一実施形態に基づき図10Aに示すフォーマットで表わされた出て行くフレームをセグメントへとセグメント化する方法ステップであって、出て行くフレームを編集することを含む方法ステップを示すフローチャートである。ステップ1101において、DMAエンジン310は、TCPスタック215からドライバ255を経て送信記述子を受け取る。送信記述子は、システムメモリ130に記憶された送信バッファの位置の物理的アドレスを含み、送信バッファは、プロートタイプヘッダ及び送信用データを含む。又、送信記述子は、処理オプションを指定する制御ビット、任意のDCTインデックス、送信オプションを指定する制御ビット等も含む。
【0114】
[00138]ステップ1103において、DMAエンジン310は、送信バッファを読み取り、送信記述子及び送信バッファを送信エンジン320へ出力する。ステップ1109において、送信エンジン320は、プロートタイプヘッダから抽出されたIPヘッダデータに基づいてIPチェック和を計算する。ステップ1111において、送信エンジン320は、セグメント化の後の最大セグメントサイズ(接続設定中に行先によりセットされる)に基づいて、送信バッファに含まれる送信用データの一部分を決定する。ステップ1113において、送信エンジン320は、図11Bを参照して以下に述べるように、送信用のセグメントを構成する。
【0115】
[00139]ステップ1131において、送信エンジン320は、プロートタイプヘッダから抽出されたTCPヘッダデータ、DCT350から読み取られた接続状態データ、及び現在フレームにおける送信用データの部分に基づいて、TCPチェック和を計算する。計算されたチェック和は、フレームのTCPヘッダに記憶される。ステップ1133において、送信エンジン320は、フレームに含まれたデータのサイズ(バイト単位)とヘッダのサイズとの差だけ送信SNを増加することにより、デレゲート接続に対してDCT350に記憶された送信SNを更新する。ステップ1135において、送信エンジン320は、計算されたTCPチェック和を含む構成されたフレームを送信インターフェイス330へ出力する。送信インターフェイス330は、その構成されたフレームを出力する。
【0116】
[00140]図11Bは、本発明の一実施形態に基づき出て行くフレームを構成するための方法ステップを示すフローチャートである。当業者に明らかなように、図11Bを参照して述べる方法ステップは、図11Aのステップ1113を遂行する1つのやり方を構成する。出て行くフレームは、CDT720に記憶された接続状態データを使用して構成され、従って、出て行くフレームは、最も最近受け取られたフレームに対応するACK番号のような接続に対する最新の状態データを含む。セグメント化中を含む送信中に、ACKは、もし可能であれば「ピギーバック」搬送され、即ち送信のためのフレーム出力に含まれ、フレーム(大型発信)が完全にセグメント化されて送信される後まで個別のACKの出力を待機するのではない。この適時のACKは、送信者から見た受信ウインドウがオープンのままで、送信者がデータの送信を続けられるよう確保する。更に、大型発信が完了するまでACKを延期すると、送信者の再送信タイマーが時間切れしたときに送信者による無駄な再送信を招くか、又はACKが「大型発信」間にしか生じないように遅延されるために受信データ流に不必要なバースティネス(burstiness)を招くことがある。
【0117】
[00141]ステップ1115において、送信エンジン320は、送信要求と共にステップ1101で受信されたDCTインデックスを使用して、送信要求がデレゲート接続に対応するかどうか決定し、対応しない場合には、図11Aのステップ1131へ進む。さもなければ、ステップ1117において、送信エンジン320は、ステップ1101で受信されたDCTインデックスを使用してCDT720にアクセスし、デレゲート接続に対する接続状態データを得る。ステップ1119において、送信エンジン320は、構成されたフレームに対する送信SNを決定する。TCPスタック215から受信されるSNが、データ流において、接続に対してCDT720に記憶される送信SNより後であるときには、送信エンジン320は、送信SNを、TCPスタック215から受信されたSNにセットする。
【0118】
[00142]ステップ1121において、送信エンジン320は、処理オプションを指定する制御ビットを検査し、TCPスタック215が、フレームの第1バイトのSNをCDT720にセーブするよう送信エンジン320に要求するかどうか決定する。セーブされたSNは、図9Aのステップ907に使用され、そのセーブされたSNに対応するACKが受信されたときにTCPスタック215の通知を制御する。ステップ1121において、送信エンジン320が、TCPスタック215が特定のACK番号に対する通知を要求すると決定した場合には、ステップ1123において、送信エンジン320は、接続に対してSNを特定のACK番号としてCDT720にセーブする。
【0119】
[00143]ステップ1125において、送信エンジン320は、構成されたフレームに対してACK番号を決定する。TCPスタック215から受信されたACK番号が、データ流において、接続に対して記憶されるDCT SNより後であるときには、送信エンジン320は、DCT SNを、TCPスタック215から受信されたACK番号にセットする。又、送信エンジン320は、接続に対してCDT720に記憶される最後のACK番号を、TCPスタック215から受信されたACK番号又はDCT SNの大きい方にセットする。
【0120】
[00144]ステップ1127において、送信エンジン320は、デレゲート接続に対してCDT720に記憶された接続状態データを検査することによりTCPタイムスタンプオプションがイネーブルされたかどうか決定する。TCPタイムスタンプオプションがイネーブルされないときには、送信エンジンは、図11Aのステップ1131へ進む。さもなければ、ステップ1129において、送信エンジン320は、構成されたフレームのTCPヘッダに自走タイマーの現在値を含ませる。又、送信エンジン320は、TCPスタック215から受信されたタイムスタンプと、接続に対してCDT720に記憶されたタイムスタンプ(最も最近受け取られたタイムスタンプ)との大きい方も含ませる。TCPスタック215から受信されたタイムスタンプが、接続に対して記憶されたタイムスタンプより大きいときには、接続に対して記憶されたタイムスタンプが、TCPスタック215から受信されたタイムスタンプにセットされる。送信エンジン320は、ステップ1131へ進み、構成されたフレームに対するTCPチェック和を計算する。
【0121】
[00145]図11Cは、本発明の一実施形態に基づき送信即ちピギーバック搬送に含ませるためにACKを発生する方法ステップを示すフローチャートである。図11Cに示す方法は、フレームが受信されたときに受信エンジン360により完了される。ステップ1145において、受信エンジン360は、デレゲート接続に対する逐次TCPフレームを受信する。ステップ1147において、受信エンジン360は、デレゲート接続に対応してDCT360において接続状態データ、例えば、TCPタイムスタンプ、SN、送信ウインドウサイズ等を更新する。DCT SNは、次に予想される到来するSNへと更新される。
【0122】
[00146]ステップ1149において、受信エンジン360は、SNと最後のACK番号(DCT350から読み取られた)との間の差であるACK差を計算する。ステップ1151において、受信エンジン360は、このACK差が、受信したフレームに対するACKをトリガーするためにTCPスタック215によりプログラムされた限界より大きいかどうか決定する。ACK差がこの限界より大きい場合には、受信エンジン360は、ステップ1157へ進む。さもなければ、ステップ1153において、受信エンジン360は、DCT SNが、増分的シーケンス番号又は特定のシーケンス番号であるスレッシュホールドより大きいかどうか決定する。DCT SNがこのスレッシュホールドより大きい場合には、受信エンジン360は、ステップ1157へ進む。さもなければ、ステップ1155において、受信エンジン360は、上述した送信ACKタイマーが時間切れしたかどうか決定し、もしそうでなければ、送信ACKタイマー及び非確認カウントが更新される。ステップ1155において、受信エンジン360が、送信ACKタイマーが時間切れしたと決定した場合には、ステップ1157において、受信エンジン360は、デレゲート接続に対してDCT350に記憶された接続状態データを更新し、例えば、非確認カウントをクリアし、最後のACK番号を更新し、増分的シーケンス番号を更新し、等々である。又、受信エンジン360は、送信ACKタイマーをリセットする。ステップ1159において、受信エンジン360は、送信のためのフレームにACKを含ませ、即ちACKをピギーバック搬送するように送信エンジン320に信号する。
【0123】
[00147]HOTユニット350は、デレゲート接続に対して受信した有効TCPフレームのTCP処理をオフロードする一方、ドライバ255又はTCPスタック215が受信ACK及びタイマーに基づいて割り込みのスレッシュホールドを決定する融通性を許す。これらスレッシュホールドを使用して割り込みを減少し、他のアプリケーションを処理するようにCPU110を解放してもよい。更に、HOTユニット350は、送信に対するACKを発生すると共に、ACKをピギーバック搬送し、TCP及びIPv4チェック和を計算し、更に、TCPセグメント化を遂行するように出て行くフレームを編集する。送信者へACKを適時に発生して送信することで、受信ウインドウをオープンに保って、帯域巾利用を改善し、且つ単一方向及び両方向通信中に不必要な再送信を減少することができる。最終的に、アプリケーションメモリスペース227のユーザバッファへのペイロードデータのアップロードは、ドライバメモリスペース235からアプリケーションメモリスペース227へデータをコピーする必要性を低減する。デレゲート接続に対してユーザバッファが使用できず且つ受信FIFOがいっぱいであるときには、到来するデータを受け入れないのではなく、レガシーバッファを使用して受信フレームをアップロードすることができる。HOTユニット250は、大量の専用メモリ又は専用プロセッサに依存しない一方、CPU110から幾つかのTCP処理をオフロードする。又、HOTユニット250は、ホストプロセッサから幾つかのTCP処理をオフロードすると共に、到来するデータを受け入れながら過剰な接続を取り扱う。
【0124】
[00148]別の態様において、本発明は、TCP接続に対するフレームを処理する方法を提供する。この方法は、オフロードユニットを使用してフレームの第1部分を処理して、第1の処理されたフレームデータを発生するステップと、オフロードユニットを使用してフレームの第2部分を処理して、第2の処理されたフレームデータを発生するステップと、CPUで実行されるTCPスタックを使用して前記第2の処理されたフレームデータを処理して、第3の処理されたフレームデータを発生するステップとを備えている。別の態様において、この方法は、更に、各フレームの処理中に特殊なケースが存在するかどうか決定するステップも含む。更に別の態様において、この方法は、更に、第1の処理されたフレームデータをユーザバッファへアップロードするステップも含む。更に別の態様において、この方法は、更に、第2の処理されたフレームデータをレガシーバッファへアップロードするステップも含む。更に別の態様において、この方法は、更に、システムメモリにおけるレガシーバッファの位置に対応するタグをソフトウェアドライバへ送信するステップも含む。
【0125】
[00149]別の態様において、本発明は、TCP接続に対するデータを処理するシステムを提供する。このシステムは、少なくとも1つのレガシーバッファに記憶された受信フレームを処理するように構成されたTCPスタックと、TCPスタックとオフロードユニットとの間をインターフェイスするように構成されたソフトウェアドライバとを備え、前記オフロードユニットは、デレゲート接続において受信されたフレームを処理して、ペイロードデータ及び部分的に処理されたフレームを発生するように構成される。更に別の態様において、オフロードユニットは、特殊なケースが存在しないフレームを処理するように構成される。更に別の態様において、オフロードユニットは、特殊なケースが存在すると決定されたときにTCPスタックに通知するように構成される。更に別の態様において、オフロードユニットは、部分的に処理されたフレームを少なくとも1つのレガシーバッファへアップロードするように構成される。更に別の態様において、オフロードユニットは、ペイロードデータを少なくとも1つのユーザバッファへアップロードするように構成される。更に別の態様において、オフロードユニットは、ペイロードデータをレガシーバッファへアップロードするか又は処理されたフレームをユーザバッファへアップロードしながら、付加的なフレームを受信するように構成される。更に別の態様において、TCPスタックは、少なくとも1つのユーザバッファに対応する位置情報をオフロードユニットに与える。更に別の態様において、オフロードユニットは、ユーザバッファ情報及びデレゲート接続状態情報を記憶するように構成されたデレゲート接続テーブルを備えている。
【0126】
[00150]別の態様において、本発明は、デレゲート及び非デレゲートTCP接続に対するフレームを処理するための方法を提供する。この方法は、特殊なケースが存在しないフレームを処理するように構成されたオフロードユニットを使用してデレゲートTCP接続を処理するステップと、CPUで実行されるTCPスタックを使用して、非デレゲートTCP接続を処理するステップと、CPUで実行されるTCPスタックを使用して、特殊なケースが存在する全てのフレームを処理するステップとを備えている。更に別の態様では、デレゲートTCP接続の処理は、ペイロードデータを発生する。更に別の態様では、ペイロードデータは、オフロードユニットによりシステムメモリの一部分へアップロードされる。更に別の態様では、この方法は、更に、デレゲート接続に対してデータが受信されたときにオフロードユニットに記憶された接続状態情報を更新するステップも含む。更に別の態様において、この方法は、更に、デレゲート接続に対してデータが送信されたときにオフロードユニットに記憶された接続状態情報を更新するステップも含む。
【0127】
[00151]別の態様において、本発明は、デレゲート接続を設定する方法を提供する。この方法は、TCP接続を確立するステップと、ハードウェアによる処理のためにTCP接続をデレゲートすべきかどうか決定するステップとを備えている。更に別の態様において、この方法は、更に、TCP接続をデレゲートすべきと決定したときにデレゲート接続テーブルのエントリーを設定するステップも含む。更に別の態様において、この方法は、更に、デレゲート接続に対するユーザバッファ情報をハードウェアへ転送するステップも含む。
【0128】
[00152]別の態様において、本発明は、TCPスタックとオフロードユニットとの間で通信するためのシステムを提供する。このシステムは、TCPスタックからオフロードユニットへコマンドを送信するための手段と、オフロードユニットからTCPスタックへ通知記述子を送信するための手段とを備えている。更に別の態様では、このシステムは、更に、オフロードユニットからTCPスタックへコマンド特有の状態を送信するための手段も備えている。更に別の態様では、このシステムは、更に、TCPスタックからオフロードユニットへ受信バッファ記述子を送信するための手段も備えている。更に別の態様では、このシステムは、更に、TCPスタックからオフロードユニットへ送信バッファ記述子を送信するための手段も備えている。
【0129】
[00153]別の態様において、本発明は、オフロードユニットを使用して出て行くフレームを編集する方法を提供する。この方法は、デレゲート接続テーブルインデックスを受信するステップと、TCPスタックからプロートタイプヘッダ及び送信用のデータを受信するステップと、デレゲート接続テーブルインデックスを使用してデレゲート接続テーブルエントリーにアクセスするステップとを備えている。又、この方法は、送信用のデータの一部分に基づいてTCPチェック和を計算するステップと、TCPチェック和及び送信用のデータの一部分を含むフレームを出力するステップも備えている。更に別の態様では、この方法は、更に、デレゲート接続テーブルエントリーを更新するステップも備えている。更に別の態様では、この方法は、接続テーブルエントリーにアクセスするステップと、送信用のデータの別の部分に基づいてTCPチェック和を計算するステップと、このTCPチェック和及び送信用データの別の部分を含む付加的なフレームを出力するステップとを備えている。更に別の態様において、アプリケーションプログラムは、行先が特定シーケンス番号の受信を確認したときに通知を要求する。更に別の実施形態では、この方法は、更に、フレームにおいて確認をピギーバック搬送するステップも含む。
【0130】
[00154]以上、特定の実施形態について本発明を説明した。しかしながら、特許請求の範囲に規定された本発明の広い精神及び範囲から逸脱せずに種々の変更や修正がなされ得ることが明らかであろう。従って、以上の説明及び添付図面は、本発明を単に例示するもので、限定するものではない。方法の請求項におけるステップの列挙は、特に指示のない限り、特定の順序でそれらステップを遂行することを意味していない。特許請求の範囲における要素を示す文字(例えば、「a)」、「b)」、「i)」、「ii)」等)は、ステップ又は他のオペレーションを実行するための特定の順序を示すものではなく、それら要素を単に参照するために含まれたものである。
【符号の説明】
【0131】
110…CPU、120…システムコントローラ、126…ハブ対ハブインターフェイス、130…システムメモリ、132…システムバス、142…システムマネージメントバス、200…コンピュータシステム、215…TCPスタック、220…一体化コントローラ、225…TCPスタックメモリスペース、227…アプリケーションメモリスペース、235…ドライバメモリスペース、240…I/Oコントローラ、245…接続テーブル(CT)、250…ハードウェア最適化TCP(HOT)ユニット、255…ドライバ、282…PCIバス、310…DMAエンジン、320…送信エンジン、330…送信インターフェイス、350…デレゲート接続テーブル(DCT)、360…受信エンジン、370…受信インターフェイス。

【特許請求の範囲】
【請求項1】
TCP接続のためのフレームを処理する方法において、
オフロードユニットを使用して前記フレームの第1部分を処理して、第1の処理されたフレームデータを発生するステップと、
前記オフロードユニットを使用して前記フレームの第2部分を処理して、第2の処理されたフレームデータを発生するステップと、
CPUで実行されるTCPスタックを使用して前記第2の処理されたフレームデータを処理して、第3の処理されたフレームデータを発生するステップと、
を備える方法。
【請求項2】
TCP接続のためのデータを処理するシステムにおいて、
少なくとも1つのレガシーバッファに記憶された受信フレームを処理するように構成されたTCPスタックと、
前記TCPスタックとオフロードユニットとの間をインターフェイスするように構成されたソフトウェアドライバと、
を備え、前記オフロードユニットは、デレゲート接続において受信されたフレームを処理して、ペイロードデータ及び部分的に処理されたフレームを発生するように構成されているシステム。
【請求項3】
デレゲート及び非デレゲートTCP接続のためのフレームを処理する方法において、
特殊なケースが存在しないフレームを処理するように構成されたオフロードユニットを使用して、デレゲートTCP接続を処理するステップと、
CPUで実行されるTCPスタックを使用して、非デレゲートTCP接続を処理するステップと、
前記CPUで実行される前記TCPスタックを使用して、特殊なケースが存在する全てのフレームを処理するステップと、
を備える方法。
【請求項4】
デレゲート接続を設定する方法において、
TCP接続を確立するステップと、
ハードウェアによる処理のために前記TCP接続をデレゲートすべきかどうか決定するステップと、
を備える方法。
【請求項5】
TCPスタックとオフロードユニットとの間で通信するシステムにおいて、
前記TCPスタックから前記オフロードユニットへコマンドを送信する手段と、
前記オフロードユニットから前記TCPスタックへ通知記述を送信する手段と、
を備えるシステム。
【請求項6】
オフロードユニットを使用して出て行くフレームを編集する方法において、
デレゲート接続テーブルインデックスを受信するステップと、
TCPスタックからプロートタイプヘッダ及び送信用のデータを受信するステップと、
前記デレゲート接続テーブルインデックスを使用してデレゲート接続テーブルエントリーにアクセスするステップと、
前記送信用のデータの一部分に基づいてTCPチェック和を計算するステップと、
前記TCPチェック和及び前記送信用のデータの一部分を含むフレームを出力するステップと、
を備えた方法。

【図1】
image rotate

【図2A】
image rotate

【図2B】
image rotate

【図3】
image rotate

【図4A】
image rotate

【図4B】
image rotate

【図4C】
image rotate

【図5A】
image rotate

【図5B】
image rotate

【図5C】
image rotate

【図5D】
image rotate

【図5E】
image rotate

【図6A】
image rotate

【図6B】
image rotate

【図6C】
image rotate

【図6D】
image rotate

【図7】
image rotate

【図8A】
image rotate

【図8B】
image rotate

【図8C】
image rotate

【図8D】
image rotate

【図9A】
image rotate

【図9B】
image rotate

【図10A】
image rotate

【図10B】
image rotate

【図11A】
image rotate

【図11B】
image rotate

【図11C】
image rotate


【公開番号】特開2010−136414(P2010−136414A)
【公開日】平成22年6月17日(2010.6.17)
【国際特許分類】
【外国語出願】
【出願番号】特願2010−9082(P2010−9082)
【出願日】平成22年1月19日(2010.1.19)
【分割の表示】特願2006−515176(P2006−515176)の分割
【原出願日】平成16年6月4日(2004.6.4)
【公序良俗違反の表示】
(特許庁注:以下のものは登録商標)
1.イーサネット
【出願人】(501261300)エヌヴィディア コーポレイション (166)
【Fターム(参考)】