JP6188093B2 - 通信トラフィック処理アーキテクチャおよび方法 - Google Patents

Description

本発明は広範には通信に関し、特に、通信トラフィックの処理に関する。

＜関連出願の相互参照＞
本願は、２０１２年１２月２６日に出願された米国仮特許出願第６１／７４５，９５１号に関連する出願であり、その利益を主張するものである。

ＩＰＴＶ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｔｅｌｅｖｉｓｉｏｎ）技術等テクノロジーの出現と、デジタルビデオブロードキャスティング（ＤＶＢ）、ルーターゲートウェイ、デジタルビデオレコーダー（ＤＶＲ）セットトップボックス（ＳＴＢ）の収束によって、処理プラットフォームに対する要求も高まり続けている。

本発明の目的は、メインプロセッサ（ＣＰＵ；中央処理装置）の処理負荷を軽減することができる、通信トラフィック処理アーキテクチャおよび方法を提供することにある。

本発明の通信トラフィック処理アーキテクチャおよび方法は、データ処理タスクを別のハードウェアにオフロードすることで、メインプロセッサ（ＣＰＵ；中央処理装置）の処理負荷を軽減することができる。

以下、添付図面を参照しながら本発明の実施態様の例をより詳細に説明する。

処理アーキテクチャの一例を示すブロック図である。 プロセッサコンプレックスの一例を示すブロック図である。 ネットワークエンジンの一例を示すブロック図である。 オフロード／アクセラレーションサブシステムの一例を示すブロック図である。 処理アーキテクチャの別の一例を示すブロック図である。 処理アーキテクチャの別の一例を示すブロック図である。 処理アーキテクチャの別の一例を示すブロック図である。 処理アーキテクチャの別の一例を示すブロック図である。 処理アーキテクチャの別の一例を示すブロック図である。 パーティション済みデバイスドライバを示すブロック図である。 低速インターフェイスを示すブロック図である。 高速インターフェイスを示すブロック図である。 マルチサービスシステムの一例を示すブロック図である。 ゲートウェイの一例を示すブロック図である。

マルチサービス処理は、安全なデータ、音声、動画、モバイルサービスにサービスの低下を生じることなく、同時に回線速度の帯域幅を提供できる単一の配信プラットフォームで提供される。

データネットワーキングおよびアプリケーション処理は、単一のチップまたは集積回路パッケージに統合される。柔軟なハードウェア設計、複数のデータインターフェイス、オフロードハードウェアと組み合わせた１つ以上の汎用メインプロセッサ、および効率的なプロセッサ間の通信といった特徴が含まれる。

処理の負荷が高い機能向けにハードウェアオフロードまたはアクセラレーションを可能にするために、１つの専用プロセッサ、複数のプロセッサ、および（または）専用ハードウェアが提供されることがある。このアプローチでは、プライマリ汎用プロセッサ（アプリケーションプロセッサ、メインＣＰＵとも呼ばれる）から機能をオフロードして、ＣＰＵの処理能力を、例えば付加価値の高い追加のサービスに確保しておくことができる。

処理プラットフォーム内の汎用メインＣＰＵ（中央処理装置）にはネットワーキングまたはデータ通信タスク実行の負荷がかかり、残りの処理能力がその他のタスク、例えばアプリケーション関連またはサービス関連のタスク実行に不十分となることがある。ネットワーキングに関するパフォーマンスを維持するために、アプリケーションやサービスのパフォーマンスが限定的になる、または低下することがある。例えば、ネットワーキングタスクがメインＣＰＵ処理サイクルの７５〜８０％を占め、アプリケーションやサービスの処理には限られたリソースしか残らないことがある。

メインＣＰＵリソースの高い使用率は、消費電力および（または）動作温度にも影響を生じる場合がある。例えば、ＳＴＢのメインＣＰＵは比較的高消費電力の部品であり、そのデバイスの中で潜在的消費電力が最も高い部品である可能性がある。

ＣＰＵによる実際の消費電力はその使用率によって異なり、使用率が高いほど消費電力も高い。高使用率は熱の生成も増加し、ヒートシンクやその他温度制御対策に対する要求も高まる。本発明で開示されるような、専用の再構成可能な（ｒｅｃｏｎｆｉｇｕｒａｂｌｅ）エンジンを利用することを通じて、大幅な効率向上が得られる。

処理アーキテクチャの例

図１は処理アーキテクチャの例を示すブロック図である。図１に示すアーキテクチャ例１００は、デュアルプロセッサメインＣＰＵアーキテクチャで、２つのメインＣＰＵ１０２、１０４を備えている。任意の多様なインターフェイスを提供してもよい。アーキテクチャ例１００には複数のインターフェイスがあり、これらには、同一の物理レイヤ（ＰＨＹ）インターフェイスコンポーネントを共有する３セットのＰＣＩｅコントローラとＳＡＴＡコントローラを表す３つのＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｅｘｐｒｅｓｓ）またはＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）インターフェイス１１８、１２０、１２２、ＳＡＴＡインターフェイス１２４、ＵＳＢホストインターフェイス１２６、ユニバーサルシリアルバス（ＵＳＢ）ホスト／デバイスインターフェイス１２８、液晶ディスプレイ（ＬＣＤ）インターフェイス１３０、単一のインターフェイスまたは２つの同時ＰＣＭインターフェイス、Ｉ^２Ｓ（ＩＣ間サウンド）バスインターフェイス、またはＳＰＤＩＦ（Ｓｏｎｙ(登録商標)／Ｐｈｉｌｉｐｓ Ｄｉｇｉｔａｌ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｆｏｒｍａｔ）インターフェイスのいずれかをサポートするパルス符号変調（ＰＣＭ）インターフェイスとして構成可能なＳＳＰ（Ｓｙｎｃｈｒｏｎｏｕｓ Ｓｅｒｉａｌ Ｐｏｒｔ）インターフェイス１３２、Ｉ^２Ｃ（ＩＣ間）バスインターフェイス１３４、ＳＤ（セキュアデジタル）インターフェイス１３６、ＪＴＡＧ（Ｊｏｉｎｔ Ｔｅｓｔ Ａｃｔｉｏｎ Ｇｒｏｕｐ）インターフェイス、この例では５つまでのチップセレクトを備えたＳＰＩ（Ｓｅｒｉａｌ Ｐｅｒｉｐｈｅｒａｌ Ｉｎｔｅｒｆａｃｅ）、およびＧＰＩＯ（Ｇｅｎｅｒａｌ Ｐｕｒｐｏｓｅ Ｉｎｐｕｔ Ｏｕｔｐｕｔ）インターフェイスの例を含むインターフェイスセット１３８、４つのＵＡＲＴ（Ｕｎｉｖｅｒｓａｌ Ａｓｙｎｃｈｒｏｎｏｕｓ Ｒｅｃｅｉｖｅｒ／Ｔｒａｎｓｍｉｔｔｅｒ）インターフェイス１４０、フラッシュメモリインターフェイス１４２、この例では６つまでのトランスポートストリームをサポートするトランスポートストリーム受信（Ｒｘ）インターフェイス１４４、ＧＭＡＣ（Ｇｉｇａｂｉｔ Ｍｅｄｉａ Ａｃｃｅｓｓ Ｃｏｎｔｒｏｌｌｅｒ）インターフェイス１４６、１４８、１５０、が含まれる。

また、図１は例えばＳＴＢで導入される場合これらのインターフェイスの一部に結合されるコンポーネントの例も示す。提示された例において、これらのコンポーネントには、８０２．１１ｎワイヤレスモジュール、ＳＬＩＣ（加入者回線インターフェイスコントローラ）、フラッシュメモリ、無線（ＲＦ）チューナー、ＨＰＮＡ（Ｈｏｍｅ Ｐｈｏｎｅ Ｎｅｔｗｏｒｋｉｎｇ Ａｌｌｉａｎｃｅ）アダプタ、スイッチおよび物理レイヤ（ＰＨＹ）コンポーネント、ワイヤレスモデムが含まれる。別の実施態様において、図１に示すものに加えて、またはそれらに代えて、その他種類のコンポーネントをインターフェイスに結合することができる。

アーキテクチャ例１００は、２５６ｋＢ Ｌ２キャッシュ１５２、８ｋＢセキュアブートＲＯＭ（Ｒｅａｄ Ｏｎｌｙ Ｍｅｍｏｒｙ）１５４、キャッシュコヒーレンシポート１５６、ネットワークエンジン１５８、セキュリティエンジン１６０、パケットエンジン１６２、トラフィックマネージャ１６４、ＤＭＡ（Ｄｉｒｅｃｔ Ｍｅｍｏｒｙ Ａｃｃｅｓｓ）コントローラ１６５、２５６ｋＢパケットバッファ１６６、１６ビットまたは３２ビットＤＤＲ（Ｄｏｕｂｌｅ Ｄａｔａ Ｒａｔｅ）メモリコントローラ１６８を含んでもよい。
別の実施態様において、図１に示すメモリのサイズおよびタイプに加えて、またはそれらに代えて、その他のサイズおよび（または）タイプのメモリを提供することができる。

図１のアーキテクチャ例１００、およびその他の図の内容は、例示のみを目的としており、かつこの開示は図に明確に示された、および本明細書で説明されている、特定の実施態様に制限されないことを理解されたい。

アーキテクチャ例１００のコンポーネントはすべて同一のチップまたは集積回路パッケージに統合するか、複数の集積回路に跨ることもできる。単一のチップまたはパッケージの場合ネットワーキングとデータ処理コンポーネント両方を含む。例えば、特定の処理タスクをネットワークエンジン１５８、セキュリティエンジン１６０および（または）パケットエンジン１６２内のあまり強力ではないながらも電力効率により優れたプロセッサに割り当て、それによって、より強力な汎用メインＣＰＵ１０２、１０４の処理サイクルをアプリケーション関連またはサービス関連タスクなどのその他のタスクの実行に利用可能にすることができる。

この種のアーキテクチャは、あまり強力ではないが特定のタスク向けに最適化されたプロセッサで実行できるタスクのためのメインＣＰＵ１０２、１０４の利用率を下げることで、より電力効率を高めることができる。パフォーマンスの向上は、より多くのメインＣＰＵ１０２、１０４の処理サイクルをその他のタスク実行に利用可能にすることでも実現可能である。

例えば、セキュリティタスクがメインＣＰＵ１０２、１０４からセキュリティエンジン１６０にオフロードされた場合、メインＣＰＵはより多くの処理サイクルをアプリケーション関連またはサービス関連タスクに利用することができる。
メインＣＰＵアーキテクチャを備えたデバイスは、アーキテクチャ例１００に基づいたアーキテクチャを備えたデバイスと類似または同等のデータレートを提供できるかもしれないが、アーキテクチャ例１００に基づいたアーキテクチャを備えたデバイスは、１つ以上のエンジン１５８、１６０、１６２にタスクをオフロードすることでメインＣＰＵの可用性がより高められているため、より機能が豊富なアプリケーションまたはサービスおよび（または）より優れたアプリケーション／サービス応答時間をサポートできる可能性がある。

これはサービスプロバイダネットワークにおけるより高度なパフォーマンスを実現するためのハードウェアアクセラレーション機能の例である。
一実施態様において、ハードウェアアクセラレーション機能は、上位レイヤのソフトウェアコンポーネントおよびアプリケーションに対してハードウェアを透過的にするカスタマイズされたソフトウェアデバイドライバを通じてアクセスされる。Ｌｉｎｕｘ（登録商標）環境では、例えば、オープンソースドライバおよび若干変更を加えたカーネルを使用することができる。これによりユーザーはカーネルをさらにカスタマイズし、Ｌｉｎｕｘ環境に加えてソフトウェアアプリケーションを実行することができる。この種のハードウェア抽象化アプローチを使用してその他のオペレーティングシステムをサポートすることができる。

アーキテクチャ例１００は、ネットワークエンジン１５８でのネットワーキング作業、セキュリティエンジン１６０でのセキュリティ、およびパケットエンジン１６２でのパケット処理作業（トランスポートストリームフレームアグリゲーションなど）のためのアクセラレーションハードウェアを統合する。ネットワーキング作業には、例えば、クラス分けとＡＣＬ（アクセス制御リスト）処理、ＶＬＡＮ（仮想ローカルエリアネットワーク）の運用、例えばＬｉｎｕｘ(登録商標) ＱＤｉｓｃモデルを通じたＱｏＳ（サービス品質）、転送、ＮＡＴ（Ｎｅｔｗｏｒｋ Ａｄｄｒｅｓｓ Ｔｒａｎｓｌａｔｉｏｎ）／Ｎｅｔｆｉｌｔｅｒの運用、マルチキャスティング、および（または）キューイング／スケジューリングの１つ以上が含まれる。
アーキテクチャ例１００でメインＣＰＵ１０２、１０４からセキュリティエンジン１６０にオフロードできる機能と関連処理には、ＩＰＳｅｃ（Ｉｎｔｅｒｎｅｔ Ｐｒｏｔｏｃｏｌ Ｓｅｃｕｒｉｔｙ）、ＤＴＣＰ（Ｄｉｇｉｔａｌ Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｅｎｔ Ｐｒｏｔｅｃｔｉｏｎ）、ＳＲＴＰ（Ｓｅｃｕｒｅ Ｒｅａｌ−ｔｉｍｅ Ｔｒａｎｓｐｏｒｔ Ｐｒｏｔｏｃｏｌ）、および（または）ＳＳＬ（Ｓｅｃｕｒｅ Ｓｏｃｋｅｔｓ Ｌａｙｅｒ）の１つ以上が含まれる。前述は図１に示すアーキテクチャ例１００の全般的な説明である。より詳細には以下の実施例で説明する。

プロセッサコンプレックス

一実施態様において、各メインＣＰＵ１０２、１０４は市販の汎用プロセッサである。プロセッサの一例は速度が６００ＭＨｚ〜７５０ＭＨｚである。図１には３２ｋＢのレイヤ１またはＬ１インストラクション（Ｉ）とデータ（Ｄ）キャッシュ１１０、１１２、１１４、１１６が示されている。
メインＣＰＵは、コードサイズ削減とアプリケーションアクセラレーションのためのソフトウェアアクセラレーション、シングルまたはマルチオペレーティングシステム（Ｏ／Ｓ）アプリケーション向けの非対称型マルチプロセッシング（ＡＭＰ）と対称型マルチプロセッシング（ＳＭＰ）、グラフィックス／演算処理向けのＳＩＭＤ（Ｓｉｎｇｌｅ Ｉｎｓｔｒｕｃｔｉｏｎ Ｍｕｌｔｉｐｌｅ Ｄａｔａ）命令セット、ＪＴＡＧ／プログラムとレースインターフェイス（ＰＴＭ）、パフォーマンスモニタリング、および（または）例えば、仮想アドレストランスレーションを加速するためのバッファリングなどのその他機能をサポートすることができる。本発明の開示はいかなる特定のメインＣＰＵまたはメインＣＰＵのタイプにも限定されない。また、アーキテクチャ例１００はデュアルＣＰＵアーキテクチャであるが、本発明の開示の要素はシングルＣＰＵアーキテクチャおよび（または）２つを超えるメインＣＰＵを備えたアーキテクチャにも適用できる。

一実施態様におけるメインＣＰＵ１０２、１０４の構成は、コンフィギュレーションレジスタでの構成パラメータ設定を含む。各メインＣＰＵ１０２、１０４がリセット後にブートされると、構成パラメータを読み込む。これらのパラメータは、メインＣＰＵコア１０２、１０４のデフォルト構成に加えてＬ２キャッシュ１５２のデフォルト構成も提供することができる。構成パラメータを変更するには、適切なレジスタを変更し、メインＣＰＵ１０２、１０４のいずれかまたは両方に再起動またはリセットが発行される。
一実施態様において、システム内のレジスタはメモリマッピングされている。その場合、構成パラメータは各レジスタがメモリ空間内で割り当てられたアドレスに書き込むことで変更される。

図２はプロセッサコンプレックス例のブロック図である。このプロセッサコンプレックス例２００には図１に示すコンポーネントの多くが含まれており、さらにコンポーネントが追加されている。追加コンポーネントには、グローバル制御インターフェイス２７０と、動的制御可能フレキシブル相互接続２７２が含まれ、前記グローバル制御インターフェイス２７０を通じて割り込みおよび（または）その他制御信号をメインＣＰＵ１０２、１０４とその他コンポーネントに提供することができ、前記動的制御可能フレキシブル相互接続２７２は、例えば、ネットワークエンジン制御モジュール２７４、（手動のオン／オフ切り替えを可能にするための）電源／（赤外線リモートコントロールデバイスを通じた制御を可能にするための）コンシューマー赤外線（ＣＩＲ）／（タイマーベースの制御を可能にするための）リアルタイムクロック（ＲＴＣ）インターフェイス２７６、シリアライザ／デシリアライザ（ＳｅｒＤｅｓ）コントローラ２７８（これを通じてメインＣＰＵ１０２、１０４および（または）その他コンポーネントがＳｅｒＤｅｓコンポーネントの構成を制御する、以下でさらに説明する）、一般に図１に示すようなＧＭＡＣ、ＵＡＲＴ、ＳＰＩ、ＧＰＩＯインターフェイスなどのペリフェラルインターフェイスを指定する、「汎用ペリフェラル」ブロック２８０、のようなスイッチングファブリックを１つ以上使用して実装することができる。

図２に示すように、メインＣＰＵ１０２、１０４は多様なインターフェイスに、そしてこれらのインターフェイスに前記フレキシブル相互接続２７２を通じて接続されたあらゆるペリフェラルに接続される。ネットワークエンジン１５８、セキュリティエンジン１６０、パケットエンジン１６２もインターフェイスおよび前記フレキシブル相互接続２７２を通じてペリフェラルに接続され、直接これらのペリフェラルと通信する、またはこれらを制御することができる。
前記フレキシブル相互接続２７２、メインＣＰＵ１０２、１０４および別個の「オフロード」用プロセッサを含むシステム内のあらゆるプロセッサ、または、例えばネットワークエンジン１５８、セキュリティエンジン１６０、および（または）パケットエンジン１６２を実装したオフロード用サブシステム内のハードウェアが、システム内の任意のリソースを制御できる。これによって、システムのソフトウェアはランタイムでどのプロセッサがどの入力／出力（Ｉ／Ｏ）を制御するかを割り当てることができる。これによって別個のオフロード用プロセッサまたはハードウェアが、ＰＣＩｅインターフェイスなど高帯域幅のＳｅｒＤｅｓ Ｉ／Ｏの制御に取って代わり、メインＣＰＵ１０２、１０４から関連処理をオフロードすることが可能になる。

図２はメインＣＰＵ１０２、１０４でのキャッシュコヒーレントペリフェラル入力も示す。
一実施態様において、各メインＣＰＵ１０２、１０４はキャッシュコヒーレンシポートを備えている。完全なＩ／Ｏコヒーレンシを提供するため、特定のメモリアドレスをキャッシュコヒーレンシポートに割り当てることができる。キャッシュコヒーレンシポートでの読み出しがいずれかのメインＣＰＵのＬ１データキャッシュにヒットし、キャッシュコヒーレンシポートでの書き込みがＬ１キャッシュ内のいずれかの古いデータを無効にしてＬ２キャッシュ１５２にライトスルーすることが可能である。これによりシステムパフォーマンスの大幅な向上と節電を可能にし、同時にドライバソフトウェアを簡素化することができる。Ｌ２／Ｌ３メモリシステムが最新であることを確約するためにデバイスドライバがキャッシュクリーニングやフラッシュを実行する必要がなくなる。キャッシュコヒーレンシについては以下で詳細に説明する。

ネットワークエンジン

図１と図２に示すネットワークエンジン１５８は、高速パケット転送、編集、キューイング、シェーピング、ポリシングなどの機能を提供できる。ネットワークエンジン１５８は、ＰＰＰｏＥ（Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ Ｐｒｏｔｏｃｏｌ ｏｖｅｒ Ｅｔｈｅｒｎｅｔ）トンネリングおよびＴＣＰ（Ｔｒａｎｓｍｉｓｓｉｏｎ Ｃｏｎｔｒｏｌ Ｐｒｏｔｏｃｏｌ）セグメンテーションなどのパケットサービスをメインＣＰＵの介入なしで切り替え、ルーティング、実行することができるため、これらのネットワーキングタスクをメインＣＰＵ１０２、１０４からオフロードすることができる。

図３はネットワークエンジン例のブロック図である。ネットワークエンジン例３００には、イングレスおよびイグレスネットワークインターフェイス３０２、３１０、転送エンジン３０４、キューマネージャ３０６、スケジューラ３０８が含まれる。一実施態様において、ネットワークエンジン例３００は構成可能かつハードコードされたハードウェアに実装される。

参照を容易にするため、ネットワークエンジン例３００が相互作用するその他コンポーネントも示されている。これらのその他コンポーネントには、メモリ３１２、１つ以上のオフロード／アクセラレーションエンジンプロセッサ３１６、ＤＭＡコントローラ１６５、メインＣＰＵ１０２、１０４が含まれる。メモリ３１２には１つ以上の記憶素子が含まれる。一実施態様において、メモリ３１２はＤＤＲメモリを含む。

一実施態様において、ネットワークエンジン例３００は、Ｌｉｎｕｘ ＩＰスタックパケット転送スキームを達成するために複数のフォワーディングテーブルを使用することができる。Ｌｉｎｕｘルールテーブルとフローテーブルはハードウェアに実装することができる。ルールテーブルは現在のパケットに含まれる情報に基づいている。ファイアウォールエントリなど一部のルールベースのエントリは、システムソフトウェアによってトラフィックのフローが開始される前に構成することができる。他のオペレーティングシステムまたはカスタムフォワーディングスタックへの適用にも対応することができる。

フローテーブルはフローの最初のパケットが受信されたときにシステムソフトウェアによってプログラムすることができ、その後そのフローの後続の各パケットをネットワークエンジン例３００によってメインＣＰＵ１０２、１０４による介入なく処理することができる。マッチしないパケットはメインＣＰＵ１０２、１０４に送り、フィルタリングオプションに基づいて破棄するか、学習プロセスを開始することができる。例えば、フローに関連付けられたペイロードによりディープなパケット検査が必要な場合、アクセラレーションにネットワークエンジン例３００を使用しているハードウェアフローの合計数がハードウェアフローの特定数を超過する場合、および（または）あらゆる組み合わせの任意のパケットフィールドに基づいたハードウェアルックアップ数がルックアップの特定数を超過する場合など、選択されたフロー中のパケットをメインＣＰＵ１０２、１０４に送ることができる。
一実施態様において、ネットワークエンジン例は、メインＣＰＵ１０２、１０４に選択されたフローが転送されるまでに、最大８１９２のハードウェアフローと１２０００のハードウェアルックアップをサポートする。ネットワークエンジン例３００を使用したハードウェアアクセラレーションは、フローごと／ルールごとにオンまたはオフにすることもできる。

カーネルによってＬｉｎｕｘベースのフロー接続を確立した後、ハードウェアテーブルにプログラムすることができる。このネットワークエンジンモデルによって、Ｌｉｎｕｘカーネルとネットワーキングアプリケーションが新たなフローについてすべてを決定することが可能になる。

ここで言及するデータフローまたはフローは、何らかの共通の特性を共有するデータと関連付けられていてもよい。例えば、特定のタイプのデータに特定の処理タスクが実行される。その場合、そのタイプのデータ用のデータフローは、ここで開示されるように、メインＣＰＵ１０２、１０４がそのタイプのデータに最初に遭遇し、特定したときに構成され、それによりそれ以降受信されるそのタイプのデータが既知のデータフローと関連付けられていると特定され、それに従ってオフロード用サブシステムでメインＣＰＵの関与なく処理されるようにすることができる。データのタイプは、異なるデータフローを差別化できる特性またはパターンの一例である。その他の例としては、送信元（ソース）アドレスおよび（または）宛先アドレスが含まれる。

ネットワークエンジン例３００の運用について、以下の例でさらに説明する。パケットが、例えば、イーサネット(登録商標)ＧＭＡＣインターフェイス１４６、１４８、１５０（図１）のいずれかを通じて、イングレスネットワークインターフェイス３０２に到着するが、それが既知のトラフィックフローの一部ではないと仮定する。不明のフローはドロップされるか、メインＣＰＵ１０２、１０４に転送されて検査が行われる。パケットがドロップされると、それ以上何も起こらない。例示のため、この例では受信したパケットが検査のためにメインＣＰＵ１０２、１０４に転送されるシナリオを考察する。

一実施態様において、パケットはＰＳＰＩＤ（物理ソースポートＩＤ）と呼ばれるものに到着し、パケット、いくつかのアーリーＬ２解析情報、タイムスタンプが転送エンジン３０４に渡される。転送エンジン３０４はいくつかのルックアップのステージを実行することができる。
ＰＳＰＩＤ→ＬＳＰＩＤ（論理ソースポートＩＤ）マッピング。このマッピングは、例えば、ポートアグリゲーションの場合など、例えば、物理ポートと仮想ポート間で遷移（ｔｒａｎｓｉｔｉｏｎ）がある場合に適用されることがある。転送エンジン３０４自体はＬＳＰＩＤを理解する一方で、この例では、ネットワークインターフェイス３０２はＰＳＰＩＤで動作する。
パケットクラス分け。パケットがアップストリームに向かっている、またはユーザーポート（ユーザーネットワークインターフェイス、ＵＮＩ）アップストリームからである、またはパケットがネットワークダウンストリームのサービスプロバイダ側からきている場合、例えば、クラス分けはパケットで実行される。クラス分けから、パケットに対するサービスまたは一般運用（ｇｅｎｅｒａｌ ｏｐｅｒａｔｉｏｎ）が決定される。
一実施態様において、サービスデータベース（ＳＤＢ）がパケットに対して実行される検索のタイプと、転送のクラス分けに基づいたいくつかの全体的構成を設定する。
次にハッシュとプレフィックスロンゲストマッチ検索が実行される。これらはパケットを転送する方法、ＱｏＳを設定する方法などを決定することができる。それらがさらにＩＰおよびＭＡＣ（メディアアクセス制御）アドレステーブルに差し向けられ、ＮＡＴが必要な場合パケットヘッダで何を置き換えるかを決定する。
また、一実施態様において、レイヤ２転送検索のためＶＬＡＮのメンバーとしてポートを割り当てるためのＶＬＡＮメンバーシップテーブルもある。
最後に、ＶＬＡＮとＱｏＳの結果テーブルにより、ＶＬＡＮの追加／削除およびＱｏＳ値の変更のため、パケットを変更することができる。

ルックアップの結果は、それら結果の中のヒットと優先マッピングに基づいて決定される。転送ルックアップの結果に基づき、転送エンジン３０４は送信のためパケットを変更することができる。パケットヘッダが変更されなくても、（例えばメインＣＰＵキューに）転送されるパケットの要素、ポリシングインデックス等が決定され、考慮される。転送結果はＡＣＬに基づいて変更またはオーバーライドされることがある。

一例として、ＡＣＬはパケットのタイプを観察し、ＡＣＬにおけるデフォルトのアクションと異なるあらゆる転送エンジンのアクションをオーバーライドするように設定することができる。また、ＡＣＬエントリは相互に論理的につなげることもできる。例えば、いくつかのＡＣＬエントリは異なるアクションに対して書かれているが、それらの結果を「ＡＮＤ」でつなげてそれらＡＣＬ規則の上位集合を形成することができる。

不明のフローからのパケットの例に戻り、例示の目的のため、異なるアクションを指定するＡＣＬがないと仮定すると、この特定のパケットは転送エンジンポートへの通常の転送がされない（この例では既知のフローの一部ではない）ため、メインＣＰＵ１０２、１０４向けに意図されたＶＯＱ（仮想出力キュー）に置かれる。
図３に示すように、このエンキュー操作はキューマネージャ３０６を通じてメモリ３１２に置かれる。パケットは、パケットがメインＣＰＵキューを出るスケジューリングをするスケジューラ３０８による命令を受けてデキューされるまでＶＯＱに留まる。

スケジューラ３０８がパケットをデキューすると、メモリに対するインターフェイス、またはＤＭＡコントローラ１６５のいずれかを通じて、メインＣＰＵ１０２、１０４がメモリ３１２でのキューからパケットをデキューする。その後パケットはメインＣＰＵ１０２、１０４によって解析される。この例の目的のため、パケットの検査で新しいフローが特定され、メインＣＰＵ１０２、１０４がいくらかの変換を加えて転送エンジン３０４ポートに転送する必要があると決定したものと仮定する。転送エンジン３０４は変換されたパケットにそのポートを通過させることができる。メインＣＰＵ１０２、１０４は変換されたパケットをそれが失われないようにこの時点で転送するか、フレームロスが懸念されない場合次のフレームまで待つことができる。
上述したようにフレキシブル相互接続２７２（図２）はシステム内のメインＣＰＵ１０２、１０４を含むあらゆるプロセッサ、およびオフロードサブシステムをあらゆるリソースと通信させ、制御を担うことを可能にするため、メインＣＰＵ１０２、１０４は変換されたパケットを転送することができる。また、この例において、メインＣＰＵ１０２、１０４はフローテーブルも更新する。

次回同じタイプのパケットがイングレスネットワークインターフェイス３０２で受信されると、転送エンジン３０４はフォワーディングテーブル内にヒットがあり（クラス分け後）、前に決定されたパケット変換が行われてパケットが変更され、アウトバウンドのＶＯＱがネットワークインターフェイス３１０ポート（例えばイーサネットポート）にマークされる。

これでパケットがキューマネージャ３０６ハードウェアＶＯＱにエンキューされたことになり、やがてスケジューラ３０８によってデキューされる。スケジューラ３０８で構成されたアップストリームまたはダウンストリームＶＯＱがイーサネットポート宛のパケットをデキューする。キューマネージャ３０６はパケットをイグレスネットワークインターフェイス３１０に渡す。パケットがデキューされるとき、エラーチェックを実行することができ、例えば巡回冗長検査（ＣＲＣ）コードをチェックして、メモリのエラー（ソフトエラー）がパケットに生じていないことを確認することができる。エラーチェックはキューマネージャ３０６または別の要素によって実行することができる。エラーチェックにパスしない場合、オプションとしてパケットにはＣＲＣコード無効とスタンプすることができ、それにより受け取り側がエラーを受信し、フレームをドロップすることを確約することができる。パケットはその後送信ポートにキューされ、送信される。

上述したように、パケットは転送プロセスの間に変換されてもよい。パケット変換または編集機能は、例えば、次を含むことができる。
・ ＴＣＰおよびＵＤＰ（Ｕｓｅｒ Ｄａｔａｇｒａｍ プロトコル）パケットの送信元および宛先ポート変更
・ ＰＰＰｏＥ／ＰＰＰヘッダ挿入／削除
・ ＭＡＣ送信元アドレス（ＳＡ）／宛先アドレス（ＤＡ）の変更と置換
・ ＩＰｖ４およびＩＰｖ６のＩＰ送信元／宛先アドレス変更
・ 現在のＩＰオプションおよび（または）拡張ヘッダの維持
・ ＩＥＥＥ８０２．１ｐ／ＤＳＣＰ（Ｄｉｆｆｅｒｅｎｔｉａｔｅｄ Ｓｅｒｖｉｃｅｓ Ｃｏｄｅ Ｐｏｉｎｔ）−サービスタイプ（ＴｏＳ）などのＱｏＳフィールド変更
・ １つまたは２つのＶＬＡＮペアでのＶＬＡＮ運用（ＱｉｎＱサポート）
・ ＩＰｖ４ヘッダチェックサムの更新
・ Ｌ４（ＴＣＰまたはＵＤＰ）ヘッダチェックサムの更新

ＰＰＰｏＥ／ＰＰＰカプセル化／カプセル化解除の例を考察する。この例はパケット変換だけでなく、転送エンジン３０４とオフロード／アクセラレーションエンジンプロセッサ３１６間の相互作用も示す。

メインＣＰＵ１０２、１０４で稼働するソフトウェアがフローで最初のＰＰＰｏＥパケットを受け取ると、転送エンジン３０４のフローテーブルでワイドエリアネットワーク（ＷＡＮ）インターフェイスからＰＰＰｏＥ／ＰＰＰヘッダを削除するようにフローを構成する。その後、転送エンジン３０４のフローテーブルでＷＡＮ宛てのトラフィックにＰＰＰｏＥ／ＰＰＰヘッダを追加するように別のフローを構成し、これ以降このフロー中の各パケットがハードウェアのみによって処理される。

ＰＰＰｏＥ／ＰＰＰパケットのカプセル化を解除するには、パケットエンジン（この例ではオフロード／アクセラレーションエンジンプロセッサ３１６によりサポートされる）にＰＰＰｏＥ／ＰＰＰからのパケットをＩＰｖ４／ＩＰｖ６に変換するように通知するため、転送エンジン３０４がパケットヘッダにビットを設定する。
パケットはそれがＩＰｖ４またはＩＰｖ６パケットに変換される前に、０ｘ８８６４のイーサネットタイプ、あるいは０ｘ００２１または０ｘ００５７いずれかのＰＰＰタイプを有する必要がある。変換中に、イーサネットタイプは、ＩＰｖ４の場合０ｘ０８００、またはＩＰｖ６の場合０ｘ８６ＤＤのいずれかで置き換えられる。次の６バイト、ＰＰＰｏＥヘッダ（Ｖ、Ｔ、コード、セッションＩＤ、長さ）およびＰＰＰタイプはすべて取り除かれる。

パケットのカプセル化解除はＶＬＡＮタグ付きパケットで可能である。パケットエンジンはカプセル化されたＰＰＰタイプを超えるパケットのＩＰ部分を解析することもできる。これによってＰＰＰｏＥ／ＰＰＰパケットのＩＰ／ＶＬＡＮ／ＭＡＣ運用が可能となる。

ＩＰ／ＶＬＡＮおよびＭＡＣの運用は、この例ではパケットをＰＰＰｏＥ／ＰＰＰにカプセル化する、パケットエンジン下で利用できる。転送エンジン３０４は、そのフロー結果に基づいてどのパケットをカプセル化するかを特定することができる。その後パケットエンジンはフローから内部パケットのＩＰバージョンとともに提供されるセッションＩＤを使用して、パケットをカプセル化する。バージョン、タイプ、コードを含むイーサネットタイプフィールドとＰＰＰｏＥフィールドがこの例では転送エンジン３０４で構成される。

以下にフィールド設定例を示す。
・ Ｖｅｒｓｉｏｎ＝１
・ Ｔｙｐｅ＝１
・ Ｃｏｄｅ＝０

ＰＰＰｏＥのＶｅｒｓｉｏｎ、Ｔｙｐｅ、Ｃｏｄｅのフィールドが、パケットエンジンによってカプセル化のために元のパケットに挿入される１６ビットのヘッダを構成する。セッションＩＤ、長さ、ＰＰＰタイプも挿入される。長さのフィールドはＰＰＰｏＥヘッダとパケットの残りを含むパケットの長さである。この例で、メインＣＰＵ１０２、１０４は最初のフロー識別と転送エンジン３０４フローテーブルの構成に関与する。
フローテーブルが構成されたら、カプセル化／カプセル化解除タスクとセキュリティタスク（あれば）は、オフロード／アクセラレーションプロセッサ３１６によって実行される。カプセル化／カプセル化解除とセキュリティタスクは、ここで開示されるデータ処理タスクの例であり、メインＣＰＵ１０２、１０４で多くの処理サイクルを占用し、その他のタスクに利用可能な処理サイクルはわずかしか残らないことがある。

オフロード／アクセラレーションプロセッサ３１６にこれらのタスクをオフロードすることで、データ処理タスクの実行のためメインＣＰＵ１０２、１０４の処理負荷を軽減する。
オフロード／アクセラレーションエンジンプロセッサ３１６と転送エンジン３０４の相互作用は、上述したようにパケットがメインＣＰＵ１０２、１０４に検査のため転送される状況においてＶＯＱを通じて行うことができる。
一実施態様において、パケットエンジンに１ポート、セキュリティエンジンに１ポートあり、これらの各ポートがそれぞれスケジューラ３０８により制御され、宛先ＶＯＱとして設定可能な８つのキューを有する。パケットがパケットエンジン、または同様にセキュリティエンジンに到着すると、パケットが処理され、そのヘッダがパケットエンジンにより変更されたり、セキュリティエンジンにより暗号化または暗号化解除されたりすることがある。処理後のパケットは、例えば、オフロード／アクセラレーションエンジンプロセッサ３１６のオンボードローカルＤＭＡコントローラを通じて、最終的にパケットエンジンポートまたはセキュリティエンジンポートの外に移動されるか、メモリ３１２に戻される。この種のポートとキューの配備は、この例ではメインＣＰＵ１０２、１０４とオフロード／アクセラレーションエンジンプロセッサ３１６間で、効率的なプロセッサ間の通信を提供する。

キューイングをより詳細に考察すると、ネットワークエンジン例３００は上述のようにＶＯＱを使用して、どのパケットキューが送信を待つ間パケットを格納するかを特定する。
一実施態様においては、１１２のＶＯＱがある。パケットがＧＭＡＣ１４６、１４８、１５０（図１）、メインＣＰＵ１０２、１０４、またはその他ソースなど任意のソースにより受け取られると、それらは転送エンジン３０４に渡され、それがパケットをドロップするか転送するか（適切であれば変更する）を最終的に決定する。パケットが転送される場合、スケジューラ３０８によってパケットの放出がスケジュールされるまでそのパケットを保持するキューを転送エンジン３０４が特定する。Ｌｉｎｕｘなどのオペレーティングシステムの場合、これはパケットのスケジューリングができるトラフィック制御モジュールによって制御されることがある。

例えば音声、ビデオ、制御されたメッセージなどの優先トラフィックにＱｏＳを提供するため、１ポートに複数のキューがある場合がある。一実施態様において、キューはすべてのギガビットポート、パケットエンジン（ＩＰフラグメンテーションの再アセンブリ、ＩＰＳｅｃ等のタスクのため）、パケットレプリケーション（ｒｏｏｔスケジューラ）、およびメインＣＰＵ１０２、１０４に提供される。メインＣＰＵ１０２、１０４は異なるトラフィックのタイプに対する多様な優先度をサポートするため多数のキューがある場合がある。ユーザータイプは、例えばよりハイエンドの企業向けアプリケーションをサポートするためにクラス分けすることができる。

ネットワークエンジン例３００のキューマネージャ３０６は、転送エンジン３０４からパケットを受け入れてメモリ３１２内のキューにそれらを格納する。キューマネージャ３０６はメモリバッファを管理するため優先度とサービスクラスを維持するように構成することができる。

スケジューラ３０８は次のような機能を提供することができる。
・ 絶対優先（ＳＰ）サービス
・ 不足ラウンドロビン（ＤＲＲ）スケジューリングサービス
・ マルチキャストサービス向けＲｏｏｔキューサポート
・ 物理ポート当たりのＳＰ／ＤＲＲキューの組み合わせ階層
・ ポート、ｒｏｏｔキュー、メインＣＰＵスケジューラを扱うメインスケジューラ

任意の多様なスケジューリングタイプ、および場合によっては複数のスケジューリングタイプがスケジューラ３０８により提供される。
一実施態様において、スケジューラ３０８は階層型スケジューリングを実装する。例えば、ｒｏｏｔキュースケジューラ、メインＣＰＵスケジューラ、ポート毎のスケジューラがトラフィックキューをトップレベルのスケジューラにすべてスケジュールすることができる。より下のレベルのスケジューラはそれぞれＳＰキューとＤＲＲキューをスケジュールすることができる。ＤＲＲスケジューラはＤＲＲキューからのトラフィックをスケジュールすることができ、その後ＳＰキューとＤＲＲスケジュール済みキューがトップレベルのスケジューラにフィードする次のレベルのＳＰまたはＤＲＲスケジューラでスケジュールされる。ポート毎のスケジューラはさらにすべてのポートに対する次のレベルのスケジューラ、例えば、トップレベルのスケジューラにフィードするラウンドロビン（ＲＲ）スケジューラにフィードすることができる。

ＳＰスケジューリングはすべてのキューに、それらの優先度に従って、サービスを提供する。より優先度の高いキューはより優先度の低いキューより前にサービスが提供される。音声およびビデオアプリケーションは高優先度のキューで低ジッタ、低遅延、低パケット損失のサービスを受けることができる。
ＳＰスケジューリングは高優先度のアプリケーションに良好なサービスを提供する一方で、低優先度のパケットは枯渇してしまう可能性がある。この問題を克服するために、パケットポリサーおよび（または）シェイパーを最高優先度のサービスに使用し、ＤＤＲスケジューリングを残りに使用することができる。ＤＲＲを使用することで帯域幅がすべてのサービスで共有され、同時にＱｏＳを維持できる。ユーザー要件に従って異なる優先度に重み付けを適用することができる。

図３には具体的に示されていないが、トラフィックマネージャ１６４（図１）を使用してパケットのポリシングとキューイングパラメータを制御することができる。また、キューデプス（ｄｅｐｔｈ）および（または）その他トラフィック管理機能に基づいてリンク上で一時停止フレームをいつ送信するかを決定する能力も提供する。

一実施態様において、輻輳回避機能も提供される。例えば、ＷＲＥＤ（Ｗｅｉｇｈｔｅｄ Ｒａｎｄｏｍ Ｅａｒｌｙ Ｄｉｓｃａｒｄ）機能は、ＡＱＤ（平均キューデプス）に基づいてトラフィックキューに対するパケットの破棄可能性を決定することができる。ＡＱＤはソフトウェア設定可能な重み付けで計算でき、線形の破棄プロファイルを、例えば、最小ＡＱＤ、最大ＡＱＤ、最大破棄可能性インターセプトポイントによって定義することができる。バックプレッシャは、輻輳および（または）輻輳によるパケット破棄の減少または回避のために利用できるもう１つの機能の例である。この種の機能はキューマネージャ３０６またはその他の場所に実装することができる。

ネットワークエンジンにより、その他の機能も代わりに提供することができる。前述は例示のみを目的としている。

オフロード／アクセラレーションサブシステム

図４は、オフロード／アクセラレーションサブシステム例４００のブロック図である。このサブシステム例４００は、パケットインターフェイス４０２、１つ以上のパケットエンジンプロセッサ４０４、１つ以上のセキュリティエンジン４０８、メモリブロック４１０、ＤＭＡコントローラ４１２、ＳＡ（セキュリティアソシエーション）データベース４１４、非パケットインターフェイス４１６を含む。
セキュリティエンジン１６０とパケットエンジン１６２は図１と図２で別々に示されているが、サブシステム例４００はこれらのエンジンを両方実装している。

パケットインターフェイス４０２は、サブシステム例４００がこの例では少なくともデータ、パケットを他のコンポーネントと交換することを可能にする。パケットインターフェイス４０２を通じて、処理のためトラフィックキューからパケットが送られてきたり、処理後にキューまたはその他コンポーネントに返されたりする。パケットインターフェイス４０２、または場合によっては別のインターフェイスは、上述のようにＶＯＱからオフロード／アクセラレーションエンジンプロセッサ３１６（図４にパケットエンジンプロセッサ４０４として示される）へのパケットをスケジューリングするスケジューラ３０８（図３）へのバックプレッシャ信号など、その他のタイプの信号交換をサポートすることができる。
一実施態様において、パケットインターフェイス４０２はパケットエンジンプロセッサ４０４とセキュリティエンジン４０８に接続するための複数の仮想内部ポートを提供する。この内部インターフェイスは、上述したように一実施態様においてポートおよびＶＯＱを使用して、ＩＰＳｅｃ、ＧＲＥ（汎用ルーティングカプセル化）、またはその他トンネルあるいはブリッジされたフレームなど、複数のパス（ｐａｓｓ）でパケットに極めて高速のターンアラウンドを実現する。非パケットインターフェイス４１６は同様に、サブシステム例４００が他のコンポーネントと少なくともデータを交換することを可能にするが、非パケットインターフェイスの場合、このデータはパケットの形式ではない。
一実施態様において、パケットインターフェイス４０２はイーサネットインターフェイスであり、非パケットインターフェイスは、例えば、ＰＣＩｅ、ＳＡＴＡ、および（または）ＵＳＢインターフェイスを含むことができる。

パケットエンジンプロセッサ４０４（またはより一般的に、任意のオフロードプロセッサ）は、メインＣＰＵ１０２、１０４（図１から図３）と同じタイプのプロセッサ、または異なるタイプのプロセッサとすることができる。しかし、メインＣＰＵ１０２、１０４と異なり、パケットエンジンプロセッサ４０４などのオフロードプロセッサは、特定のタイプの機能を実行するための特殊用途または専用プロセッサとして構成される。
サブシステム例４００において、これらの機能はパケットエンジンのパケット処理機能を含む。この例におけるパケットエンジンはメモリ４１０または別のメモリに格納されたソフトウェアに実装され、パケットエンジンプロセッサ４０４によって実行される。パケットエンジンプロセッサ４０４または別のオフロードプロセッサのタイプは、メインＣＰＵ１０２、１０４からオフロードされる特定機能によって異なる。一般に、メインＣＰＵ１０２、１０４はオフロードプロセッサより強力であるため、メインＣＰＵのオフロードは、オフロードされるハードウェア（メインＣＰＵ）ほど複雑ではない追加のハードウェアに依存しない。これはまた、メインＣＰＵからオフロードプロセッサまたはその他のオフロードハードウェアへのタスクの移動時に電力を節約できることにもつながる。

サブシステム例４００のセキュリティエンジン４０８は、セキュリティ機能のハードウェア実装を表す。一実施態様において、セキュリティエンジン４０８は構成可能であるがハードコードされたコアである。従ってサブシステム例４００は２つのタイプのオフロードエンジンを示しており、ソフトウェアエンジンを実行する１つ以上のオフロードプロセッサ（この例ではパケットエンジンソフトウェアを実行するパケットエンジンプロセッサ４０４）と、１つ以上のハードウェアエンジン、すなわちセキュリティエンジン４０８を含んでいる。

サブシステム例４００のメモリ４１０は、一実施態様において、１つ以上のソリッドステートメモリを含むことができる。例えば、メモリ４１０はＳＲＡＭ（Ｓｔａｔｉｃ Ｒａｎｄｏｍ Ａｃｃｅｓｓ Ｍｅｍｏｒｙ）の複数のブロックを含むことができる。ＳＡデータベース４１４もメモリに格納されるが、図４ではメモリ４１０とは別に示されている。
一実施態様において、セキュリティエンジン４０８、および場合によっては複数のセキュリティエンジンが実装されていても１つのセキュリティエンジンのみが、ＳＡデータベース４１４に対する完全なダイレクトアクセスを有する。サブシステム例４００のその他のコンポーネントおよび（または）サブシステム例が実装されているシステムのコンポーネントは、ＳＡデータベース４１４が格納されているメモリデバイスまたは領域にライトオンリーのアクセスを有することがある。

ＤＭＡコントローラ４１２はオンボードＤＭＡコントローラを表し、サブシステム例４００に図３において３１２で示されるメモリ、ＳＲＡＭ、および（または）１つ以上のオンチップメモリなどの外部メモリへのアクセスを提供する。ＤＭＡコントローラ４１２は、一実施態様において、セキュリティキーおよびデータを移動して遅延と処理オーバーヘッドを減少するためＬｉｎｕｘドライバとも共有される。

パケットエンジンは、専有のおよび（または）新しいカプセル化プロトコルをアクセラレーションするためにカスタマイズできる、強力で再構成可能なブロックである。
一実施態様において、パケットエンジンは異なるプロトコルを橋渡しする。例えば、一実施態様において、ネットワークエンジン例３００（図３）はイーサネットスイッチングを処理するためにハードコードされており、パケットエンジンがネットワークエンジンとその他非イーサネットインターフェイス間のトラフィックを橋渡しする。この場合、パケットは最初の処理またはイーサネットへのトランスレーション／変換のため非パケットインターフェイス４１６を通じてパケットエンジンプロセッサ４０４に渡され、その後ネットワークエンジンに提供される。

パケットエンジンにサポートされる機能の例には、次を１つ以上含むことができる。
・ ＩＰＳｅｃパケット処理（リプレイ、ＳＡ変更、カプセル化、カプセル化解除）
・ ＩＰフラグメント再アセンブリ
・ ディスクブロック暗号化／暗号解除
・ ＩＰトンネリング作成および終了
・ ワイヤレスブリッジング、ＩＥＥＥ８０２．１１とＥｔｈｅｒｎｅｔ ＩＩ／ＩＥＥＥ ８０２．３間の変換など

ディスクブロック暗号化／暗号解除などのセキュリティ関連タスクには、セキュリティエンジン４０８も関与する。

上掲の例のようなデータ処理タスクは、メインＣＰＵ１０２、１０４からサブシステム例４００にオフロードすることができ、それによりメインＣＰＵのデータ処理実行の負荷を減少できる。それでより多くのメインＣＰＵ処理サイクルが、より上位のレイヤアプリケーション、またはサービス関連タスクなど、他のタスク実行に利用できるようになる。オフロードエンジン、またはより一般的に、そのようなエンジンをサポートするオフロードサブシステムは、オフロードされる特定のデータ処理タスク向けに最適化することもでき、それによりそれらのタスクがメインＣＰＵ１０２、１０４に留まった場合よりも効率的かつ高速にそれらのタスクを実行することができる。
一実施態様において、パケットエンジンは、メインＣＰＵ１０２、１０４（セキュリティエンジン４０８と合わせて暗号化をサポートするため）と、カプセル化、暗号化、ブリッジング、再アセンブリをサポートするためのネットワークエンジン１５８、３００を含む２つのユーザータイプを有することができる。これらのユーザーは、一部の実施態様においては同時に、各ユーザーに対してチップ上で複数のセキュリティアソシエーションをあらかじめ構成するためにセキュリティエンジン４０８を使用できる。

セキュリティエンジン４０８は任意の多様なアルゴリズム、暗号、ハッシュ、およびＩＰＳｅｃ暗号化／暗号解除、ディスクブロック暗号化／暗号解除、ベースステーション暗号化／暗号解除などのセキュリティ機能をサポートすることができる。

またセキュリティエンジン４０８はメインＣＰＵ１０２、１０４から暗号タスクをオフロードするために使用することもできる。そのようなタスクは、純粋にソフトウェアに実装した場合、処理負荷が高い。実装可能なモデルとしては、メインＣＰＵ１０２、１０４が直接セキュリティエンジン４０８を制御するモデルと、パケットエンジンプロセッサ４０４などのオフロードプロセッサがセキュリティエンジンを制御するモデルの２つがある。

直接制御する場合、メインＣＰＵ１０２、１０４で実行するソフトウェアが、暗号化／暗号解除など１つ以上のセキュリティ機能を実行するように、例えばセキュリティエンジンを制御するメモリマップドレジスタを使用して、セキュリティエンジン４０８をプログラムする。その後メインＣＰＵ１０２、１０４がセキュリティエンジン４０８により処理される１つ以上のパケットの場所を示すメモリポインタを提供できる。セキュリティエンジン４０８はパケットの暗号化／暗号解除またはその他処理を行ってから、ポインタをメインＣＰＵ１０２、１０４に返す。この例では、データがメインＣＰＵ１０２、１０４とセキュリティエンジン４０８間でメモリポインタの交換を通じて共有される。その他のデータ共有または交換メカニズムも、または代わりに、セキュリティエンジン４０８へのセキュリティタスクのオフロードを可能にするために利用することができる。
メインＣＰＵ１０２、１０４ではなく、オフロードプロセッサがセキュリティエンジン４０８を制御する「間接的な」制御の実施態様の場合、メインＣＰＵが処理される１つ以上のパケットをオフロードプロセッサに示すか、または提供する。例えば、メモリポインタをパケットエンジンプロセッサ４０４に提供してもよい。その後オフロードプロセッサがセキュリティエンジン４０８をプログラムして、セキュリティエンジン４０８によるパケットの暗号化／暗号解除またはその他セキュリティ処理を調整する。これにはセキュリティエンジン４０８にメモリポインタを提供すること、およびセキュリティ処理が完了したときセキュリティエンジンからメモリポインタを受け取ることが含まれる。その後オフロードプロセッサが、例えばメモリポインタをメインＣＰＵに返すことで、メインＣＰＵ１０２、１０４に完了を示す。

当然のことながら、パケットエンジンプロセッサ４０４とセキュリティエンジン４０８は、オフロードまたはアクセラレーションエンジンの例である。その他の実施態様は追加のエンジンおよび（または）異なるエンジンを含むことができる。例えば、パケットエンジンプロセッサ４０４は、他のエンジンのためのソフトウェア実行にも使用される共有プロセッサとすることができる。
セキュリティエンジン４０８同様に、専用のハードウェアに他のオフロードまたはアクセラレーションエンジンを実装することができる。連結リストウォーカーエンジン、バッファアロケータエンジン、ＳＡＭＢＡオフロードエンジンは、さらに機能性を高めるためにオフロードまたはアクセラレーションサブシステムに実装できる他のオフロードまたはアクセラレーションエンジンの例である。これらの追加エンジン例は図４に示されていないが、パケットエンジンプロセッサ４０４およびセキュリティエンジン４０８と同じように、セキュリティエンジンについて示されているＳＡデータベース４１４への直接のフルアクセスを例外として、図４のその他コンポーネントと相互接続することができる。

連結リストウォーカーエンジンは、例えば、連結リストウォーキングのタスクをオフロードするハードウェアモジュールとして実装することができる。パケットを処理するソフトウェアは連結リストデータ構造に配置されたパケットの格納と取得に時間がかかることがある。これらの構造はかなり複雑になり、パケットが格納されているリーフノードを追跡するために数多くのメモリ読み出しを要する場合がある。
連結リストウォーカーエンジンはメインＣＰＵ１０２、１０４で実行されるソフトウェアからこの処理をオフロードするために使用することができる。連結リスト構造で数多くのメモリ読み出しを行う代わりに、メインＣＰＵ１０２、１０４は、連結リスト構造をリーフノードレベルまで辿った連結リスト構造のヘッドを連結リストウォーカーエンジンに提供することができる。これが行われると、パケットのソフトウェアによる読み出し／書き込みが簡単になる。

一実施態様において、連結リストウォーカーエンジンは、次のポインタのアドレスを示すバイトを見つける場所およびリストの構造に関するその他フォーマット情報など、リストのフォーマットでプログラムすることができる。連結リストウォーカーエンジンは、例えば、各フォーマットがインデックスによって識別される、複数の異なるフォーマットをプログラムすることができる。メインＣＰＵ１０２、１０４で稼働するソフトウェアがリストをウォークするとき、連結リストウォーカーエンジンに、リストのヘッドのアドレス、リストのフォーマットを説明するインデックス番号、実行するアクションのインジケータを提供することができる。
実行できるアクションには、例えば、リストの終わりに１つ以上の新規項目を挿入すること（その場合挿入する項目を含むメモリ内のアレイへのポインタをメインＣＰＵ１０２、１０４が提供できる）、リストから最後のＮ項目を削除すること（その場合連結リストウォーカーエンジンが埋めることができるメモリ内の空きアレイへのポインタをメインＣＰＵが提供できる）、および（または）その他のアクションが含まれる。連結リストウォーカーエンジンは、一実施態様において、割り込みを設定することでメインＣＰＵに完了を知らせる。

バッファアロケータエンジンは、例えば、メモリアロケーションコールのハードウェア実装として、実装することができる。メインＣＰＵ１０２、１０４で稼働するソフトウェアがメモリに何かを格納したいとき、メモリアロケーションコールを使用してカーネルにメモリ割り当てを要求することがある。このコールはたくさんのメインＣＰＵサイクルを使用し、毎秒何回も発生することがある。オフロードエンジンアーキテクチャでは、ソフトウェアがメモリを必要とするとき代わりにバッファアロケータエンジンからメモリを要求することができる。バッファアロケータエンジンはシステム内の利用可能なメモリを追跡し、ソフトウェアに要求されたバッファを返す特殊なハードウェアオフロードエンジンとすることができる。
一実施態様において、バッファアロケータエンジンによりメインＣＰＵ１０２、１０４に返されるのは、割り当てられたバッファ（のメモリアドレス、例えば）へのポインタである。

ＳＡＭＢＡオフロードエンジンはＳＡＭＢＡプロトコルをアクセラレートする実装である。ＳＡＭＢＡプロトコルはハードディスクドライブなどのストレージをネットワーク上でアクセス可能にする。このプロトコルはネットワーキングトラフィックを受け取り、ディスク上への格納に適したフォーマットに処理することを必要とする。ネットワーキングインターフェイスで受け取る各パケットをＳＡＭＢＡで処理する必要があるため、たくさんのＣＰＵサイクルを要することがある。
ＳＡＭＢＡオフロードエンジンは、メインＣＰＵ１０２、１０４がディスク宛てのネットワークトラフィックをＳＡＭＢＡオフロードエンジンにただ転送することを可能にする。その後ＳＡＭＢＡオフロードエンジンはＳＡＭＢＡプロトコルに従ってトラフィックを処理し、すべての得られたファイルシステム管理を処理するため、メインＣＰＵで実行されるはずであったデータ処理タスクを実行することで、メインＣＰＵ１０２、１０４の処理負荷を軽減する。

詳細な実施例−ＷｉＦｉ(登録商標)（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）ウェブフィルタリング

処理アーキテクチャのコンポーネントは図１から図４を参照した例として上述されている。ＷｉＦｉアプリケーションのコンテキストでオフロードを提供する実施態様の詳細な実施例について、処理アーキテクチャの更なる例のブロック図である図５から図８を参照しながら、以下で説明する。

図５のアーキテクチャ例５００は、５ＧＨｚ ＩＥＥＥ ８０２．１１ａｃ ＷｉＦｉモジュール５０２を含む。他の実施態様はその他のタイプのＷｉＦｉモジュールを含むことができる。イーサネットネットワークインターフェイスカード（ＮＩＣ）５０４も示されている。これらモジュールの両方がこの例ではＰＣＩｅインターフェイスに接続されている。ＰＣＩｅインターフェイスは図５で別途示されていないが、図１と図２では１１８、１２０、１２２で示されている。デュアルメインＣＰＵアーキテクチャが図５に示されている。複雑化を回避するために、メインＣＰＵは１つのブロック５１０で示されている。
各メインＣＰＵ５１０がＬｉｎｕｘネットワーキングプロトコルスタック５１２をサポートし、別の実施態様ではその他のオペレーティングシステムをサポートしてもよい。ＷｉＦｉドライバ５１４は下位レイヤドライバ５１６と上位レイヤドライバ５１８を含む。イーサネットドライバが５２０で示され、メインＣＰＵ５１０はネットワークインターフェイスドライバ５２２も実行する。ＣＰＵポート５２４はメインＣＰＵ５１０とネットワークエンジン５３０間の通信を可能にする。

ネットワークエンジン５３０は転送エンジン５３２を含み、ネットワークエンジン５３０のその他ハードコードされた機能は５３４で示されている。アーキテクチャ例５００には、５３６で示すように、１ポートにつき８つの優先キューがある。ネットワークエンジン５３０内の１つ以上のネットワークインターフェイスがギガビットイーサネット（ＧＥ）０、ＧＥ１、ＧＥ２として示されるイーサネット接続上で通信を可能にする。これらの接続は、一実施態様において、ＧＭＡＣインターフェイス１４６、１４８、１５０を介している（図１）。

図５のアーキテクチャ例５００は、ネットワークエンジン５３０の形式でハードウェアオフロードエンジンまたはアクセラレータを含む。さらにオフロード／アクセラレーションハードウェアが図６のアーキテクチャ例６００に示されている。セキュリティエンジン０、セキュリティエンジン１、パケットエンジン０、パケットエンジン１は追加のオフロードとアクセラレーションを可能にする。
ここで説明されるように、セキュリティエンジンはセキュリティ関連機能を処理し、パケットエンジンはデータプレーン機能を処理する。セキュリティエンジンはハードコードされているがメインＣＰＵ５０１で稼働するシステムソフトウェアにより構成可能であり、パケットエンジンはパケットエンジンプロセッサ６０２、６１２、パケットメモリ６０４、６１４、およびＤＭＡコントローラ６０６、６１６をそれぞれ含む。

メインＣＰＵ５１０は、上述のとおり、Ｌｉｎｕｘネットワーキングプロトコルスタック５１２をサポートし、ネットワークエンジン５３０およびネットワークインターフェイスドライバ５２２との通信にＣＰＵポート５２４を提供する。ネットワークエンジンカーネルモジュール６２６が転送機能を制御し、Ｌｉｎｕｘネットワーキングプロトコルスタック５１２インターフェイスと５３０で示されるネットワークエンジンハードウェア間のインターフェイスを実装する。ネットワークエンジンカーネルモジュール６２６はネットワークエンジン５３０でオフロードとフロー管理機能を可能にするためのカーネルフックも提供し、ネットワークエンジンの操作、構成、モニタリングを制御する。

アーキテクチャ例７００（図７）には、ＰＣＩｅインターフェイスを介してパケットエンジンに接続する、２．４ＧＨｚ ＩＥＥＥ８０２．１１ｎモジュール７０２と、５ＧＨｚ ＩＥＥＥ８０２．１１ａｃモジュール７０４を含む２つのＷｉＦｉモジュールがある。パケットエンジン０とパケットエンジン１は図７においてこれらのエンジンによってこの実施態様で実行される機能を例示する機能ブロックで主に表されている。
図に示すように、パケットエンジン０は下位レイヤＷｉＦｉ送信（Ｔｘ）ドライバ７１４を実行し、パケットエンジン１は下位レイヤＷｉＦｉ受信（Ｒｘ）ドライバを実行する。各パケットエンジンは、メモリに格納されるプロセッサ間通信（ＩＰＣ）メールボックス７１６、７２６と、例えばトンネリング作成と終了を処理するためのＷｉＦｉドライバトンネルモジュール７１８、７２８を含む。１つ以上のセキュリティモジュールも提供され、パケットエンジンおよび（または）メインＣＰＵ５１０により使用されるが、図の複雑化を回避するために図７には示されていない。メインＣＰＵ５１０はＬｉｎｕｘネットワーキングプロトコルスタック５１２をサポートし、かつネットワークインターフェイスドライバ５２２と、ネットワークエンジンカーネルモジュール６２６を含む。また各メインＣＰＵ５１０は、ネットワークエンジン５３０と通信するためのＣＰＵポート５２４、ＩＰＣメールボックス７３４、上位レイヤドライバ７４０とＷｉＦｉオフロードアダプテーションレイヤ（ＷＯＡＬ）７３８を含むＷｉＦｉドライバ７３６、およびＷｉＦｉドライバトンネルモジュール７４２、７４４も含む。

メインＣＰＵ５１０とパケットエンジンでＷｉＦｉドライバトンネルモジュール７４２、７４４により提供されるＷｉＦｉドライバトンネルは、８０２．１１（ＷｉＦｉ）フレームをネットワークエンジン５３０経由でメインＣＰＵに送達することができる８０２．３（イーサネット）フレームにカプセル化する。
一実施態様において、ネットワークエンジン５３０は標準のイーサネットに基づいており、８０２．３フレームを把握して転送することができる。ＷｉＦｉモジュール７０２、７０４経由で送受信されるフレームは８０２．３フレームとは非常に異なる８０２．１１フレームの形式である場合がある。

ＩＰＣメールボックス７３４はパケットエンジンのＩＰＣメールボックス７１６、７２６と共に動作し、メインＣＰＵ５１０とパケットエンジン間の効率的な通信メカニズムを提供する。これについては以下で詳細に説明する。
メインＣＰＵ５１０とパケットエンジン間のＩＰＣメカニズムは、一実施態様において、構成、制御、管理機能に使用される。現在のＷｉＦｉオフロード例では、ステーションごとに、８０２．１１フレームと８０２．３フレーム間の相互変換を直接制御および更新するために使用される。また、診断およびパフォーマンスモニタリングなどの管理にも使用できる。

ＷｉＦｉテクノロジーにおける「ステーション」とは、アクセスポイント（ＡＰ）に接続された任意のクライアントデバイスを指す。ここで開示されるプロセッサアーキテクチャは、例えば、家庭用ゲートウェイなどのＡＰに実装することができる。ステーション対ステーションの通信は、通常ＡＰを経由する。各ステーションで、８０２．１１フレームヘッダが異なることがあり、一実施態様において、パケットエンジンが各ステーション、または各宛先ＭＡＣアドレスに対するトランスレーションテーブルを保持する。

ＷｉＦｉドライバ７３６について、例えば図５において、ＷｉＦｉユーザーデータフレームの処理時にメインＣＰＵの利用率が高い理由は、高コンテキストスイッチと長いメモリアクセスレイテンシである。図７に示すＷｉＦｉオフロードの目的は、ユーザーデータトラフィックを移し、パケットエンジンとネットワークエンジン５３０に転送してこのボトルネックを排除することにある。その結果、それらのデータフレームはメインＣＰＵパスを通過しなくなる。
図７に示すオフロード設計の例では、パケットエンジンがデータインターフェイスを処理し、ユーザーデータフレームをＷｉＦｉモジュール７０２、７０４に、およびＷｉＦｉモジュール７０２、７０４から移動させる。したがって、パケットエンジンは７１４、７２４で示されるように下位のレイヤドライバ機能を実行し、プロトコル管理とコントロールに関連する上位レイヤドライバ機能は、７４０で示されるように、メインＣＰＵ５１０上のＷｉＦｉドライバ７３６に留まる。ＷＯＡＬ７３８はこのオフロードを可能にするが、これについては以下でより詳細に説明する。

ネットワークエンジン５３０は、転送、フレームバッファリング、ＱｏＳ機能などの提供を継続する。下位レイヤドライバ７１４、７２４は主に、ＷｉＦｉモジュール７０２、７０４とパケットエンジン間（オフロードケース、図７）で、またはメインＣＰＵ５１０間（非オフロードケース、図５）でのデータフレームの移動に関与する。さらに、下位レイヤドライバ７１４、７２４は、イーサネットベースのネットワークエンジン５３０のための８０２．１１形式から８０２．３フレーム形式への変換、フレームアグリゲーション、速度コントロール、省電力などのその他データ処理タスクを選択的に処理する。フレーム変換が行われる場合、８０２．１１ヘッダ情報はステーションごとに異なるため、パケットエンジンが各ステーション用の変換テーブルを保持する。このテーブルは、コントロールおよび管理フレームを使用して各テーブルとステーションの関連付けを担っているメインＣＰＵ５１０によりＩＰＣメールボックス７３４、７２６、７１６経由で動的に更新される。

運用において、ＷｉＦｉモジュール７０２、７０４はＰＣＩｅまたはホストインターフェイスで、８０２．１１フレーム形式または８０２．３フレーム形式の２つのユーザーデータフレーム形式のいずれかをサポートする。例示の目的で、フレームが宛先ＭＡＣアドレスに基づいて転送されるブリッジングモードになるようにＬｉｎｕｘネットワーキングプロトコルスタック５１２が構成された実施例を考察する。

ＷｉＦｉドライバトンネルモジュール７１８、７２８、７４２、７４４により提供されるＷｉＦｉドライバトンネルは、パケットエンジンとメインＣＰＵ５１０上のＷｉＦｉデバイスドライバ７３６の上位レイヤドライバ７４０間でフレームを送信する内部経路である。これらのトンネルは、一実施態様において、ネットワークエンジン５３０内の専用フローとして確立され、ネットワークエンジンによって認識可能な８０２．３フレーム内に８０２．１１フレームをカプセル化する機能を有する。このカプセル化は、一実施態様において、ＷｉＦｉドライバトンネルモジュール７１８、７２８、７４２、７４４によって提供される。ＷｉＦｉドライバトンネル７４２、７４４はＣＰＵポート５２４上の別個の論理インターフェイスとすることができ、それぞれ８つの仮想優先キューを持つ。この実装例において、ＣＰＵポート５２４は８つの論理インターフェイスまたは６４の仮想優先キューをサポートする。ネットワークエンジン５３０に接続された各ＧＥインターフェイスもネットワークインターフェイスドライバ５２２上に８つの仮想優先キューを有することができる。

受信（Ｒｘ）の動作では、フレームタイプにより識別される管理フレームがＷｉＦｉモジュール７０２、７０４のいずれかからパケットエンジン１によって受信されると、パケットエンジンはＷｉＦｉドライバトンネルモジュール７２８、７４４間のＷｉＦｉドライバトンネルを介してこのフレームを直接メインＣＰＵ５１０に送信する。このフレームは上位レイヤドライバ７４０に透過的に送達される。ＷＯＡＬ７３８はデータ処理タスクのオフロードを可能にし、上位レイヤドライバ７４０と下位レイヤドライバ７１４、７２４間のインターフェイスを提供して、オフロードが上位レイヤドライバに透過的に行われる。

異なるフレームタイプによって識別されたデータフレームが、ＷｉＦｉモジュール７０２、７０４の１つからパケットエンジン１に受信されると、パケットエンジンの下位レイヤドライバ７２４がまず送信またはフォワーディングテーブルをチェックし、宛先ＭＡＣアドレスについてテーブルにすでにエントリがあるか判断する。エントリがある場合、このフレームはデータフロー中でその宛先ＭＡＣアドレスに対する最初のデータフレームではなく、ネットワークエンジン５３０に送られて転送・処理される。エントリがない場合、それはその宛先ＭＡＣアドレスに対する最初のデータフレームであり、ＷｉＦｉドライバトンネルを介してメインＣＰＵ５１０に転送される。
上位レイヤドライバ７４０は、８０２．１１から８０２．３へのフレーム形式の変換を含め、図５の上位レイヤドライバ５１８と同じようにそのフレームを処理する。その後そのフレームがＬｉｎｕｘネットワーキングプロトコルスタック５１２に渡され、そこで転送決定が行われる。この決定はフレームの転送先となるイグレスポートを提供する。ネットワークエンジンカーネルモジュール６２６はソースのＭＡＣアドレスについてネットワークエンジン５３０内にフローエントリを作成する。フレームはネットワークインターフェイスドライバ５２２に渡され、さらにそこからネットワークエンジン５３０に送信されて転送される。

一方、送信（Ｔｘ）の動作では、フレームがネットワークエンジン５３０のイーサネットインターフェイスのいずれかで受信され、その宛先ＭＡＣアドレスにフローエントリの一致がない場合、メインＣＰＵ５１０のネットワークインターフェイスドライバ５２２に転送される。ネットワークインターフェイスドライバ５２２はフレームをＬｉｎｕｘネットワーキングプロトコルスタック５１２に渡し、転送の決定が行われる。このフレーム用のイグレスポートがＷｉＦｉインターフェイスの場合、８０２．３形式のフレームがＷｉＦｉデバイスドライバ７３６の上位レイヤドライバ７４０に渡されて処理される。その後、または実質的に同時に、ネットワークエンジンカーネルモジュール６２６によってフローエントリがネットワークエンジン５３０で作成され、それ以降同じ宛先ＭＡＣアドレスを備えたフレームはメインＣＰＵ５１０の関与なくネットワークエンジン５３０から直接パケットエンジン０に転送され、これによりオフロードの効果が提供される。
フレームがネットワークエンジン５３０により直接転送されたときのＷｉＦｉ下位レイヤデバイスドライバ７１４での基本動作は、他の処理機能の中でも特に、８０２．３フレームを８０２．１１フレームに変換することである。フレームはＷｉＦｉドライバトンネルを介してパケットエンジン０に送信される。その後、または実質的に同時に、ＷＯＡＬ７３６はパケットエンジン０にコンフィギュレーションメッセージを送信し、送信テーブルにエントリが作成され、その宛先ＭＡＣアドレスによりインデックスされる。このエントリによって、その宛先ＭＡＣアドレスを持つ８０２．３フレームが８０２．１１フレームに変換され、適切なＷｉＦｉモジュール７０２、７０４に直接送信することが可能となる。

図８のアーキテクチャ例８００は、図７のアーキテクチャ例７００に実質的に類似しているが、パケットエンジン０とパケットエンジン１の両方が送信および受信の動作を処理する点が異なる。したがって、下位レイヤドライバ８１４、８２４、ＩＰＣメールボックス８１６、８２６、およびＷｉＦｉドライバトンネルモジュール８１８、８２８、８４２、８４４は双方向通信をサポートする。ＩＰＣメールボックス８１６、８２６間の相互作用もアーキテクチャ例８００では若干異なり、この例ではＩＰＣメールボックスが相互に直接相互作用する必要がなく、パケットエンジンが送受信両方を処理する。
図７のアーキテクチャ例７００と図８のアーキテクチャ例８００の違いの１つは、前者はＷｉＦｉモジュール７０２、７０４の処理能力要件が非対称な場合、ロードバランシングが可能である点である。しかし、両方のＷｉＦｉモジュール７０２、７０４をアーキテクチャ例８００におけるパケットエンジン０と１両方に相互接続することも可能である。

図９の処理アーキテクチャ例９００はウェブフィルタリングに関連する。この実施態様において、ウェブフィルタリングに関連するデータ処理タスクがメインＣＰＵ５１０からハッシュクラシファイア９０８、トラフィックマネージャ９０６、転送エンジン９３２を含むネットワークエンジン９３０にオフロードされる。ネットワークエンジン９３０は他の実施態様と同じように実装できるが、図９では、一部の実施態様における転送タスクに加えて、ウェブフィルタリングタスクのオフロードを提供することを示すため、異なるラベル付けがされている。
ネットワークエンジン９３０はインターネット９０２と通信する。プロトコル管理または制御タスクは、図９においてＵＲＬ（Ｕｎｉｆｏｒｍ Ｒｅｓｏｕｒｃｅ Ｌｏｃａｔｏｒ）プロセッシング９１０として示されているメインＣＰＵ５１０に留まる。ＵＲＬプロセッシング９１０はこの実施例においてメインＣＰＵ５１０により実行されるソフトウェアの形式である。ローカルＵＲＬデータベース９１２は、データトラフィックがどのようにフィルタされるかを指定するフィルタリング制御情報を格納する。
一実施態様において、ローカルＵＲＬデータベース９１２は「ホワイトリスト」または許可されているデータトラフィックを指定した許可済みフロー情報（許可されていないフローがドロップされる、または別の方法でフィルタされる）を格納することができる。ローカルＵＲＬデータベース９１２は、示された例において、クラウドセキュリティサーバー９０４からのＵＲＬデータベース更新によって自動入力される。これらの更新は毎日、および（または）その他自動化されたスケジュール、および（または）要求により実行することができる。ネットワークエンジンカーネルモジュール９１４も図９に示されている。

ハッシュクラシファイア９０８、転送エンジン９３２、およびトラフィックマネージャ９０６は、一実施態様において、ハードウェアベースであり、例えば、コンフィガラブルながらもハードコードされたハードウェアに実装される。ハッシュクラシファイア９０８は、処理アーキテクチャ例９００において、ネットワークエンジンドライバ９１４によるホワイトリスト構成に基づき、ＨＴＴＰフローを識別する。例えば、フロー中の新しいパケットの場合など、ＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ Ｔｒａｎｓｆｅｒ Ｐｒｏｔｏｃｏｌ）フロー（１）がハッシュクラシファイア９０８に識別されない場合、そのフローは識別のためメインＣＰＵに転送される（２）。ＵＲＬプロセッシング９１０の一部として、ローカルＵＲＬデータベース９１２、および（または）クラウドサービスセキュリティサーバー９０４がコンサルトされる（３）、（４）。フローが許可されたフローの場合（５）、ネットワークエンジンカーネルモジュール９１４によってその許可されたフローに対してハッシュクラシファイア９０８のハッシュテーブルが構成される（６）か、ＵＲＬプロセッシング９１０が拒否されたフローに対するＴＣＰセッションリセットとともにＨＴＴＰ応答、または、ＵＲＬリダイレクトメッセージ（図示しない）を送信する（５−拒否）。このＨＴＴＰ応答またはリダイレクトがネットワークエンジン９３０を通じて要求しているユーザーシステムに返される。

ハッシュクラシファイア９０８に認識されたフローは、メインＣＰＵ５１０の関与なくネットワークエンジン９３０により処理され、それにより最初の識別後は、メインＣＰＵからデータ処理がオフロードされる。

図５から図９のＷｉＦｉとウェブフィルタリングの例は、メインＣＰＵ５１０からの実質的なデータ処理タスクのオフロードを可能にする最初のパケット処理の形態を示している。フローがオフロードエンジンによって認識されないときメインＣＰＵ５１０は関与するが、メインＣＰＵ５１０で実行されるソフトウェアに最初に識別された後のフローに対するデータ処理はオフロードすることができる。管理または制御タスクはメインＣＰＵ５１０に留まり、データ処理はオフロードエンジンにオフロードされる。
図７と図８のＷｉＦｉの例では、メインＣＰＵ５１０が上位レイヤＷｉＦｉプロトコル管理または制御タスクをやはり処理しているため、オフロードすることでプロトコルがどのように運用されるかが変化したり、あるいはＷｉＦｉモジュール７０２、７０４に変更が必要になったりすることはない。同様に、図９のウェブフィルタリング例では、ＵＲＬプロセッシング９１０がメインＣＰＵ５１０にあり、ネットワークエンジン９３０のハッシュクラシファイア９０８へのフィルタリングのオフロードはＨＴＴＰとＴＣＰの動作に影響しない。ＨＴＴＰとＴＣＰのプロトコル管理または制御タスクはメインＣＰＵ５１０によって処理され、データ処理はネットワークエンジン９３０にオフロードされる。

ソフトウェアパーティショニング／スプリッティング

ここで開示される処理アーキテクチャは、１つ以上のメインＣＰＵから１つ以上のオフロードまたはアクセラレーションエンジンにタスクをオフロードすることを可能にする。例えば、周辺デバイスドライバなどのソフトウェアがプロトコル管理または制御タスクとデータ処理タスクを含むことがある。
一実施態様において、管理または制御タスクはメインＣＰＵに留まるため、オフロードによってプロトコルまたはＷｉＦｉモジュールなどのインターフェイスデバイスが運用される方法が変化することはなく、下位レイヤデータ処理タスクがオフロードされる。そのようなソフトウェアパーティショニングまたはスプリッティングは、どのソフトウェアまたはどのタスクをオフロードエンジンに移すとよいか、どのソフトウェアまたはタスクをメインＣＰＵに留めるべきかを特定することを必要とする。
一実施態様において、ほとんどのデータトラフィックを処理し、そのため汎用アプリケーションプロセッサ上で最も低効率であるソフトウェアドライバは、書き換え、修正、またはその他の方法でオフロードエンジンに移され、メインＣＰＵにより実行されるために留まるソフトウェアから除外される。

図１０にパーティション済みデバイスドライバの例を示す。パーティション済みデバイスドライバ例１０００は、上位レイヤドライバ７４０がメインＣＰＵ５１０に残り、下位レイヤドライバ８１４、８２４がパケットエンジンにオフロードされる、図７のＷｉＦｉデバイスドライバのパーティショニングに関連する。このオフロードはＷＯＡＬ７３８によって可能とされる。ＷｉＦｉドライバトンネルモジュール７４２、７４４とＩＰＣメールボックス７３４が図７ではＷＯＡＬ７３８から分離して示されているが、図１０ではＷＯＡＬの一部として示されている。これは、ＷＯＡＬがこれらのコンポーネントと相互作用して下位レイヤドライバ８１４、８２４と上位レイヤドライバ７４０間のアダプテーションレイヤまたはインターフェイスを提供するためである。パーティション済みデバイスドライバ例１０００において、ＷＯＡＬ７３８はアプリケーションプログラミングインターフェイス（ＡＰＩ）である。このＡＰＩの目的は、下位レイヤドライバと上位レイヤドライバの分離を可能にして、いずれかにおける変更の他方に対する影響をほぼ、またはまったくなくすことである。

一実施態様において、上位レイヤドライバ７４０は８０２．１１プロトコル管理タスクを実行し、Ｌｉｎｕｘネットワーキングスタック５１２（図７、図８）にデバイスドライバインターフェイスを提供する。下位レイヤドライバ８１４、８２４は、示された例ではＰＣＩｅインターフェイスとＰＣＩｅコントローラドライバ９１４を介して、周辺デバイス、すなわちＷｉＦｉモジュール７０２、７０４（図７、図８）との間の実際のデータ移動を処理する。１００２でのフレームコンバータによる８０２．１１／８０２．３フレーム変換、１００４でのフレームアグリゲータによるフレームアグリゲーション、１００６での速度コントローラによる速度制御、１００８での電源コントローラによる省電力機能などのタスクは、この例では下位レイヤドライバ８１４、８２４でオフロードされる。

ＷｉＦｉモジュール７０２、７０４と下位レイヤドライバ７１４、７２４、８１４、８２４間のデータの移動は、一実施態様において、パケットリング構造を介したＤＭＡ操作により実行される。このパケットリング構造には、パケットメモリに格納されたパケットをリードポインタとライトポインタで記述するパケットディスクリプタを含む。各パケットディスクリプタ１０１０、１０１２は、そのパケットに対するメモリロケーションやパケット長などのパケット情報を有する。パケットをＷｉＦｉモジュール７０２、７０４からパケットエンジンに転送する準備ができると、割り込み信号がパケットエンジンに送信される。その後パケットエンジンが受信パケットリング内のリードポインタから送信を開始する。パケットエンジンからＷｉＦｉモジュール７０２、７０４への送信用に類似のパケットリングがある。

上位レイヤドライバ７４０と下位レイヤドライバ８１４、８２４間に、ＷＯＡＬ７３８は上位レイヤドライバに透過的な方法でオフロード機能を可能にする「ｓｈｉｍ」またはインターフェイスレイヤを提供する。ＷＯＡＬ７３８は、ＩＰＣメールボックス７３４を介してオフロードエンジン、この例ではすなわちパケットエンジンを制御し、これと通信するとともに、透過的なデータ送達のためのＷｉＦｉドライバトンネルも提供する。
ＷＯＡＬ７３８により提供されるオフロードＡＰＩとの互換性のために下位レイヤドライバ８１４、８２４を書き換えまたはその他修正することができ、それがその後上位レイヤドライバ７４０とのインターフェイスとなる。オフロードは、ＷＯＡＬ７３８がインターフェイス定義または仕様と一貫した上位レイヤドライバへのインターフェイスを提供し、それを通じてメインＣＰＵ５１０に残るルーチンまたは関数（図７、図８）とオフロードされるルーチンまたは関数を相互作用させることで、完全に上位レイヤドライバ７４０に透過的にすることができる。例えば、ＷＯＡＬ７３８はドライバの「ネイティブ」型で上位レイヤドライバ７４０からの関数またはルーチン呼び出しを受け入れ、結果もネイティブ型で上位レイヤドライバに返すように適応されることもできる。ネイティブ型とオフロードされたタスクまたは機能の実行に使用されるその他の型間のトランスレーションはＷＯＡＬ７３８により処理することができる。ＷｉＦｉドライバトンネルモジュール７４２、７４４はこの種の例を表しており、パケットエンジンとメインＣＰＵ５１０間でネットワークエンジン５３０を通じてＷｉＦｉフレームをトランスポートすることができる（図７）。

図１０は、１つ以上のメインＣＰＵからオフロードプロセッサおよび（または）その他ハードウェアへの機能をオフロードするためのＷｉＦｉデバイスドライバソフトウェアのスプリッティングまたはパーティショニングに関するものである。類似のソフトウェアスプリットまたはパーティションを図８の処理アーキテクチャ例８００で使用することができる。他の実施態様においては、その他タイプのデバイス用ドライバおよび（または）さらにはその他タイプのソフトウェアをスプリットまたはパーティションして特定のタスクをオフロードすることができる。例えば、図９の処理アーキテクチャ例９００では、ウェブフィルタリングソフトウェアメインＣＰＵ５１０とネットワークエンジン９３０間でスプリットされている。プロトコル管理または制御タスクを処理するＵＲＬ処理は、メインＣＰＵに留まる。データ処理タスク（この場合はフィルタリング）は、ネットワークエンジン９３０にオフロードされる。
ソフトウェアスプリッティングをより一般的に考慮すると、メインＣＰＵからのタスクオフロードの目的の１つは、汎用プロセッサ上では非効率なタスクを、あまり強力ではないものの専用に構成されたプロセッサまたはその他オフロードハードウェアに移すことである場合がある。この種のアプローチは例えば、メインＣＰＵ処理のボトルネックおよび（または）高いメインＣＰＵの使用状況に動機付けられる可能性がある。また、オフロード戦略の開発において、プロトコルを変更しないことが望ましく、変更すると処理負荷の増加および（または）処理アーキテクチャに接続するデバイスにおける変更を生じる場合があるためである。
ＷｉＦｉオフロードを例としてみると、一部のタスクはデータがＰＣＩｅインターフェイスに到着する前に「フロントエンド」で実行されるように、ＷｉＦｉモジュール７０２、７０４（図７、図８）を変更することが可能であるかもしれない。しかしながら、このアプローチは、ＷｉＦｉデバイスの設計に大きな影響を与える。従来、ＷｉＦｉデバイスはインテリジェントではなく、処理のインテリジェンスは処理システム内のほかの場所に存在する。そのインテリジェンスをＷｉＦｉデバイス自体に移すことはデバイス設計に大きな変化を必要とし、ＷｉＦｉプロトコルにも重大な影響を与える。

一実施態様において、デバイスドライバソフトウェアおよび（または）その他のタイプのソフトウェアの分析を実施し、一実施態様において、単一のレイヤのみでのデータ処理を含む下位レイヤ（例：レイヤ１またはレイヤ２）データ処理のボトルネックを特定することができる。プロトコル管理または制御タスクはあまりプロセッサに負荷をかけない傾向があり、一般的にデータ処理タスクよりも頻繁に実行されないため、プロトコル管理または制御タスクはメインＣＰＵに残す好ましい候補となり得る。
データ処理タスクがオフロードに特定されると、それらのタスクを実行するソフトウェアをオフロードハードウェアで実行できるように書き換えまたはその他修正することができる。一部の実施態様において、そのようなタスクはソフトウェアのタスクを模擬するハードウェアにハードコードすることができる。オフロードタスクのハードコーディングは速度の面でさらにメリットを提供できる。

例えば、デバイスドライバは、特定のデータ対応に特定のタスクを実行する場合がある。したがって、特定のタイプまたはパターンの入力について（ここでは一般的に「フロー」と呼ばれる）、特定のタスクまたは特定の一連のタスクが常に実行される。この種のアクションはオフロードエンジンにソフトコードまたはハードコードすることができる。
一実施態様において、新しいデータフローのための最初のパケットがヘッダ処理またはその他プロトコル管理処理に基づく識別のためにメインＣＰＵに提供される。続いてメインＣＰＵで実行されるソフトウェアがオフロードエンジンテーブルを更新するか、その他の方法でオフロードエンジンに識別情報を提供することができ、それ以降同じフロー内のその他のパケットを識別し、メインＣＰＵの関与なく同じデータ処理タスクを実行することができる。この例においてそのようなメインＣＰＵによる「最初のパケット」処理は一元化されたプロトコル管理処理を提供すると同時に、データ処理タスクのオフロードを可能にする。最初のパケットは、一実施態様において、オフロードのためのフローがメインＣＰＵで特定されるまで複数のパケットを含むように延長することができる。

メモリサブシステム

ソフトウェア機能のスプリッティングまたはパーティショニングはメインＣＰＵとオフロードプロセッサ間に通信オーバーヘッドを生じる。一部の実施態様においてはキャッシュコヒーレンシハードウェアが提供され、プロセッサ間のシステムバスに跨るトランザクションが各プロセッサのメモリサブシステムの観点からコヒーレントであるようにすることを可能にする。これによってリソースのロックとロック解除に費やされるオーバーヘッドの量を減少し、結果的にプロセッサの通信をより高速化することができる。キャッシュコヒーレンシの実装は同種のメインＣＰＵ／オフロードプロセッサアーキテクチャ（すなわち、メインＣＰＵとオフロードプロセッサが同じタイプのものである）または異種プロセッサアーキテクチャに提供できる。

キャッシュコヒーレンシは、スピンロックやメールボックスなどメッセージを渡すメカニズムを待つオーバーヘッドを生じることなく、メインＣＰＵがメモリとキャッシュを使用してオフロードエンジンと通信することを可能にする。これにより、メインＣＰＵクロックサイクルの浪費を減らし、それによって消費電力を最小化すると同時にパフォーマンスを最大化する。

一実施態様において、キャッシュコヒーレンシは、オフロードエンジンにプロセッサキャッシュコヒーレンシポートを介してメインＣＰＵのＬ１キャッシュとＬ２キャッシュへのアクセスを提供することにより実装される。オフロードエンジンがキャッシュコヒーレントアクセスを使用するように構成されているとき、メインＣＰＵのＬ１キャッシュまたはＬ２キャッシュを通じ、ＤＤＲまたはＳＲＡＭメモリロケーションからの読み出しとそれらへの書き込みを行う。

例えば、メインＣＰＵはオフロードエンジンに格納されたパケットの場所を示すメモリポインタを渡す場合がある。非キャッシュコヒーレント構成において、その後オフロードエンジンはメモリから直接パケットを読み出し、それを処理する。続いてそのパケットを再びメモリに書き込むが、オンチッププロセッサの速度に対してメモリの速度が遅いため、時間がかかることがある。メインＣＰＵがオフロードエンジンの作業中に同じパケットデータを読み出そうとすると、誤ったデータを取得する。これを回避するため、代わりにメインＣＰＵはソフトウェアサイクルを使用してポーリングまたはその他の方法でオフロードエンジンがメモリへの書き込み完了を示すまで待ってから、メモリからのパケットデータ再読み出しを行う必要がある。

コヒーレンスが有効なシステムでは、オフロードエンジンがメインＣＰＵのＬ１／Ｌ２キャッシュ構造を通じてパケットを読み出す。これは、メインＣＰＵにパケットデータをメモリから読み出させ、そのパケットデータをそのキャッシュに暴露させる。オフロードエンジンがパケットの変更を終えると、パケットを再びメインＣＰＵのＬ１／Ｌ２キャッシュ構造に書き込む。これにより、ＣＰＵは変更されたデータがメモリに再び書き込まれるのを待つ必要なく、すぐにそのデータにアクセスすることができる。

ここで開示された処理アーキテクチャは、キャッシュコヒーレントモードまたは非キャッシュコヒーレントモードで動作できる。非キャッシュコヒーレントモードの場合、オフロードエンジンとメインＣＰＵ間の通信を促進するＩＰＣメールボックスが提供される。
図７と図８に示すようなメールボックスは、相対的に低いＣＰＵオーバーヘッドで信頼性の高いメッセージを渡すことができる。オフロードエンジンがタスクを完了すると、メインＣＰＵ向けに完了を示すメッセージをメールボックスに配置できる。一実施態様において、これはメインＣＰＵに割り込みの発生を引き起こす。続いてメインＣＰＵは、割り込み処理ルーチンの一部として、メッセージを読み出し、タスクの完了を知ることができる。これはメインＣＰＵとオフロードエンジンの相互同期を維持する。

フレキシブルＩ／Ｏ

一実施態様において、図２の２７２で示されるような、フレキシブルで動的に制御可能な相互接続は、処理システム内の任意のプロセッサまたはオフロード／アクセラレーションエンジンがシステム内の任意のリソースを制御することを可能にする。これにより、ソフトウェアによってどのプロセッサまたはハードウェアがどのＩ／Ｏをランタイムで制御するかを割り当てることができる。例えば、オフロードプロセッサは、特定のＰＣＩｅインターフェイスがＷｉＦｉモジュールに接続され、ＷｉＦｉのためのデータ処理タスクがオフロードされるときなど、そうすることが意味を成すときに、ＰＣＩｅなど高帯域幅のＳＥＲＤＥＳ Ｉ／Ｏを制御することができる。

また、一部の実施態様は代わりに同一のピンまたはポート上でインターフェイスの多重化を提供する場合がある。Ｉ／Ｏにおけるこの種の柔軟性が低速インターフェイスを示すブロック図である図１１の例で示されている。図１１に示すように、ＰＣＭインターフェイス１３２、フラッシュインターフェイス１４２、ＬＣＤインターフェイス１３０などの低速インターフェイスは、ＧＰＩＯインターフェイス１３８向けのＧＰＩＯ機能と多重化することができる。これにより、ソフトウェアがＩ／Ｏピンを機能に動的に割り当てることを可能にする。

図１２は高速インターフェイスと類似の多重化機能を示すブロック図である。インターフェイス配置例１２００はＳｅｒＤｅｓベースのフレキシブルＩ／Ｏを示す。図１に１１８、１２０、１２２として示すように、ＰＣＩｅインターフェイスおよびＳＡＴＡインターフェイスは２つの異なるプロトコルであっても同じＩ／Ｏで共有できる。これはインターフェイス配置例１２００でＳｅｒＤｅｓ１２０２、マルチプレクサ１２０４、ＰＣＩｅインターフェイスおよびＳＡＴＡインターフェイス１２０６、１２０８を含めて実装できる。
システムソフトウェアによりＳｅｒＤｅｓのＩ／ＯがＰＣＩｅインターフェイスまたはＳＡＴＡインターフェイスとして動作すべきか否かを決定し、チップの動作中、そのプロトコルに構成することができる。他の高速インターフェイスは同様の方法で多重化でき、ＵＳＢインターフェイス１２１０は図１２のようなインターフェイスの一例として示されている。

ここで開示したアプリケーション処理アーキテクチャ例は任意の多様なアプリケーションにおいて実装することができる。

例えば、サービスプロバイダービデオゲートウェイにおいて、ＰＣＩｅ統合インターフェイス１１８、１２０、１２２（図１）を使用して２つの独立したＷｉＦｉ接続と追加の高速マルチチャネルトランスコーディング／デコーディングを提供し、完全なビデオソリューションを促進することができる。ＵＳＢポート１２６、１２８の１つを処理アーキテクチャへのアクセスに使用し、一実施態様において、他方をホストまたはデバイスユーザーのプリンターやディスクアタッチドストレージ接続用に利用可能にしておくことができる。統合ＳＡＴＡポート１２４、および（または）１つ以上のＰＣＩｅインターフェイス／ＳＡＴＡインターフェイス１１８、１２０、１２２はこの種のアプリケーションにおいてパーソナルビデオレコーダ（ＰＶＲ）および（または）ネットワークアタッチドストレージ（ＮＡＳ）機能に使用することができる。

プロセッサアーキテクチャにおける拡張性の高いインターフェイスとパフォーマンスは、幅広いコストとパフォーマンスのメディアサーバーモデルをサポートできる。図１のアーキテクチャ例１００は、例えば、１１８、１２０、１２２、１２４で４つまでのＳＡＴＡポートをサポートし、それらのいずれも、またはすべてを幅広いＮＡＳソリューションの実装に使用できる。ＬＣＤインターフェイス１３０は、一実施態様において、ピクチャーフレーム機能を直接サポートし、また例えばハイデフィニションマルチメディアインターフェイス（ＨＤＭＩ（登録商標））コンバータを通じてパネルに接続し、低コストの中解像度ディスプレイを提供することもできる。

ルーター／ＶＰＮコンセントレータでの実装においては、２つのＵＳＢポート１２６、１２８の１つをデバイスデバイスモードで構成し、ＵＳＢストレージとその他ＵＳＢデバイスの接続を可能にすることができる。ＵＳＢデバイスモード下で、ＵＳＢポートはＰＣまたはその他接続されたシステムにＵＳＢマスストレージデバイスとみなされる。１１８、１２０、１２２、１２４のＳＡＴＡポートも外付けストレージに使用することができる。ＶＰＮアプリケーションはセキュリティエンジン１６０により提供される暗号化機能を使用することもできる。

また、アーキテクチャ例１００は、カメラ数の多いビデオコンバータ向けの３つのＰＣＩｅインターフェイス１１８、１２０、１２２を通じて、セキュリティ施設設備向けの低コストのソリューション提供にも役立てることができる。セキュリティエンジン１６０に搭載された暗号化機能により、エンコードされたビデオの安全な格納が可能である。メインＣＰＵ１０２、１０４の処理能力は追加のハードウェアサポートを必要とすることなく、複数のカメラのトランスコーディングをサポートできる。ビデオキャプチャデバイスがコーディングをサポートする場合、アーキテクチャ例１００はセキュリティエンジン１６０によりストレージデータの暗号化と暗号解除のみを提供することができる。

図１３はマルチサービスシステム例を示すブロック図である。このマルチサービスシステム例１３００は、ピコクラウド１３０２（家庭用または中小企業（ＳＭＥ）向け設備を表すことができる）を含む。ここに開示される処理アーキテクチャはピコクラウド１３０２内に実装し、図１３に示される任意の、またはすべての多様なサービスをサポートすることができる。フェムトセル１３０４は、例えば、ＬＴＥ（Ｌｏｎｇ Ｔｅｒｍ Ｅｖｏｌｕｔｉｏｎ）ワイヤレス接続上で提供される。１つ以上のＵＳＢデバイス１３０６がＵＳＢ接続を介してピコクラウド１３０２に接続される。ＮＡＴサービスは１つ以上のＳＡＴＡ接続とディスクストレージ１３０８を通じて実現できる。１つ以上のＷｉＦｉデバイス１３１０は上で詳細に説明したＰＣＩｅ接続を通じてピコクラウド１３０２に接続することができる。ＴＶサービス１３１２は１つ以上のトランスポートストリーム（ＴＳ）接続を介して実現される。
マルチサービスシステム例１３００において、ＬＡＮサービス１３１４は１つ以上のイーサネット接続を介して提供できる。１３１６では、例えばホームセキュリティ用に、ディープパケットインスペクション（ＤＰＩ）モジュールを提供してもよい。ＤＰＩモジュール１３１６は、ピコクラウド１３０２内の処理アーキテクチャ中のネットワークエンジンに接続可能な別個のハードウェアモジュールとすることができる。電話サービスは、１３１８で示される１つ以上のＰＣＭ接続上でサポート可能であり、インターネット１３２０へのＷＡＮ接続も提供可能である。

ＤＰＩモジュール１３１６に関して、ただＬ２、Ｌ３またはＬ４ヘッダを見てパケットの許可／遮断／ルーティングを決定する代わりに、このモジュールは非常にディープに、例えば、パケットのＬ７コンテンツなどを見てどうするかを決定することができる。ＤＰＩモジュール１３１６は何を見るか、およびどんなアクションをするかを指定する「規則」を採用し、例えば、パケットを見てウイルスを見つけるためなどに使用することができる。感染したパケットは特定され、遮断される。これはクラウド環境において、任意の「エッジ」で悪意あるアクティビティをクラウドネットワークに侵入する前に防止するために利用できる。

一実施態様において、ピコクラウド１３０２は、処理アーキテクチャと複数のインターフェイスを含むゲートウェイにより提供される。図１４はゲートウェイ例を示すブロック図である。

ゲートウェイ例１４００は、この例では１１０Ｖ電源に接続されたレギュレータ１４０４と、バッテリー１４０６などの電源コンポーネントを含む。バッテリー１４０６は、例えば、動作に電力を必要とする電話のための「ライフライン」保護に実装することができる。ゲートウェイ例１４００を家庭の電話サービスに使用すれば、停電が起きても、バッテリー１４０６が電話サービスを少なくとも一時的に維持することができる。
ここに提供される教示に基づいた処理アーキテクチャ１４０２は、さまざまなインターフェイスを通じ、この例ではＤＲＡＭ１４０４とフラッシュメモリ１４２２の形式のメモリに接続される。ＷｉＦｉ無線１４０６、１４０８は、組み込まれたＰＣＩｅインターフェイスを通じて処理アーキテクチャ１４０２に接続される。１４１０、１４１２で示されるＵＳＢポートには、外付けＵＳＢデバイスを接続できる。また、ゲートウェイは、処理アーキテクチャ１４０２のＳＡＴＡインターフェイスに接続されたハードドライブ１４１４などのディスクストレージも含むことができる。電話用ジャックなどの電話インターフェイス１４１６は、組み込まれた１つ以上のＰＣＭインターフェイス、および（または）、例えばＶｏＩＰ（Ｖｏｉｃｅ ｏｖｅｒ ＩＰ）電話の場合、処理アーキテクチャ１４０２内の他のインターフェイスに接続することができる。ビデオ対応ゲートウェイは、処理アーキテクチャ１４０２内のトランスポートストリームインターフェイスに接続された１つ以上のＴＶチューナー１４１８を含むことができる。１４２０で示されるイーサネットポートは、１つ以上のスタンドアロンコンピュータおよび（または）ネットワーク化されたコンピュータに対するインターネット接続の提供に使用することができる。

本明細書の説明は、本発明の実施態様の原理のアプリケーションを例示したのみであり、本発明の範囲から逸脱することなく当業者はその他の配置および方法も実施可能である。例えば、図面は例示のみを目的としている。その他の実施態様には、類似の配置で相互接続された、より多い、より少ない、および（または）追加コンポーネントを含むことができる。各メインＣＰＵ１０２、１０４（図１）は、例えばそれぞれがデータキャッシュと命令キャッシュを備えたデジタルシグナルプロセッサ（ＤＳＰ）を含んでもよい。一実施態様において、これらのキャッシュはそれぞれ３２ｋＢであるが、異なる数および（または）容量のキャッシュも検討できる。

さらに、方法とシステムのコンテキストで主に説明されているが、例えばコンピュータで判読可能な媒体に格納された命令（ｉｎｓｔｒｕｃｔｉｏｎｓ）など、本発明のその他の実施も検討可能である。

本明細書における単数形または複数形の特徴は、実施態様を任意の数のインスタンスまたはコンポーネントに制限することを意図していない。例えば、本明細書で開示された処理アーキテクチャは、複数のメインＣＰＵと組み合わせて実装する必要はない。

また、パケットは例であり、ここで開示されるとおりに処理可能なデータブロックの非限定的な例であることに注意する。セル、フレーム、および（または）その他のデータブロックをパケットと同じまたは類似の方法で処理することができる。

１００ アーキテクチャ例
１０２、１０４ メインＣＰＵ
１１８、１２０、１２２、１２４ ＰＣＩｅまたはＳＡＴＡポート
１２６、１２８ ＵＳＢポート
１３０ ＬＣＤインターフェイス
１３２ ＰＣＭインターフェイス
１３４ Ｉ^２Ｃバスインターフェイス
１３６ セキュアデジタル
１３８ ＪＴＡＧ、ＳＰＩ、ＧＰＩＯインターフェイス
１４０ ４つのＵＡＲＴインターフェイス
１４２ フラッシュインターフェイス
１４４ トランスポートストリームインターフェイス
１４６、１４８、１５０ ＧＭＡＣインターフェイス
１５２ Ｌ２キャッシュ
１５４ セキュアブートＲＯＭ
１５６ キャッシュコヒーレンシポート
１５８ ネットワークエンジン
１６０ セキュリティエンジン
１６２ パケットエンジン
１６４ トラフィックマネージャ
１６５ ＤＭＡコントローラ
１６６ パケットバッファ
１６８ ＤＤＲメモリコントローラ
２７０ グローバル制御
２７２ 相互接続
２７４ ネットワークエンジン制御
２７６ 電源／ＣＩＲ／ＲＴＣインターフェイス
２７８ ＳｅｒＤｅｓコントローラ
２８０ 汎用ペリフェラル
３００ ネットワークエンジン例
３０２ イングレスネットワークインターフェイス
３０４ 転送エンジン
３０６ キューマネージャ
３０８ スケジューラ
３１０ イグレスネットワークインターフェイス
３１２ メモリ
３１６ オフロード／アクセラレーションエンジンプロセッサ
４００ サブシステム例
４０２ パケットインターフェイス
４０４ パケットエンジンプロセッサ
４０８ セキュリティエンジン
４１０ メモリブロック
４１２ ＤＭＡコントローラ
４１４ セキュリティアソシエーションデータベース
４１６ 非パケットインターフェイス
５００ アーキテクチャ例
５０２ ＷｉＦｉモジュール
５０４ ネットワークインターフェイスカード（ＮＩＣ）
５１０ メインＣＰＵ
５１２ Ｌｉｎｕｘネットワーキングプロトコルスタック
５１４ ＷｉＦｉドライバ
５１６ 下位レイヤドライバ
５１８ 上位レイヤドライバ
５２０ イーサネットドライバ
５２２ ネットワークインターフェイスドライバ
５２４ ＣＰＵポート
５３０ ネットワークエンジン
５３２ 転送エンジン
５３４ 分類／ポリシング／スケジューリング／バッファ管理
５３６ １ポートにつき８つの優先キュー
６００ アーキテクチャ例
６０２、６１２ パケットエンジンプロセッサ
６０４、６１４ パケットメモリ
６０６、６１６ ＤＭＡコントローラ
６２６ ネットワークエンジンカーネルモジュール
７００ アーキテクチャ例
７０２、７０４ ＷｉＦｉモジュール
７１４ 下位レイヤドライバ
７１６、７２６ ＩＰＣメールボックス
７１８、７２８ ＷｉＦｉドライバトンネルモジュール
７３４ ＩＰＣメールボックス
７３６ ＷｉＦｉドライバ
７３８ ＷＯＡＬ
７４０ 上位レイヤドライバ
７４２、７４４ ＷｉＦｉドライバトンネルモジュール
７１６、７２６ ＩＰＣメールボックス
８００ アーキテクチャ例
８１４、８２４ 下位レイヤドライバ
８１６、８２６ ＩＰＣメールボックス
８１８、８２８、８４２、８４４ ＷｉＦｉドライバトンネルモジュール
９００ 処理アーキテクチャ例
９０２ インターネット
９０４ クラウドサービスセキュリティサーバー
９０６ トラフィックマネージャ
９０８ ハッシュクラシファイア
９１０ ＵＲＬプロセッシング
９１２ ローカルＵＲＬデータベース
９１４ ネットワークエンジンドライバ
９１４ ネットワークエンジンカーネルモジュール
９１４ ＰＣＩｅコントローラドライバ
９３０ ネットワークエンジン
９３２ 転送エンジン
１００２ フレームコンバータ
１００４ フレームアグリゲータ
１００６ 速度コントローラ
１００８ 電源コントローラ
８１４、８２４ 下位レイヤドライバ
１２００ インターフェイス配置例
１２０２ ＳｅｒＤｅｓ
１２０４ マルチプレクサ
１２０６、１２０８ ＰＣＩｅインターフェイスおよびＳＡＴＡインターフェイス
１２１０ ＵＳＢインターフェイス
１３００ マルチサービスシステム例
１３０２ ピコクラウド
１３０４ フェムトセル
１３０６ ＵＳＢデバイス
１３０８ ディスクストレージ
１３１０ ＷｉＦｉデバイス
１３１２ ＴＶサービス
１３１４ ＬＡＮサービス
１３１６ ＤＰＩモジュール
１３１８ ＰＣＭ接続
１３２０ インターネット
１４００ ゲートウェイ例
１４０２ 処理アーキテクチャ
１４０４ レギュレータ
１４０４ ＤＲＡＭ
１４０６ バッテリー
１４０６、１４０８ ＷｉＦｉ無線
１４１０、１４１２ ＵＳＢポート
１４１４ ハードドライブ
１４１６ 電話インターフェイス
１４１８ ＴＶチューナー
１４２０ イーサネットポート
１４２２ フラッシュメモリ

Claims (30)

1. 統合処理システムであって、集積回路パッケージ内に、
   前記統合処理システム外部の外部コンポーネントからデータパケットが受信されるときに使用されるパケットベースのプロトコル中の管理または制御パケットに関連付けられたプロトコル管理タスクを実行するメインプロセッサと、
   前記パケットベースのプロトコルに従って受信されたデータパケットに対してデータ処理タスクを実行するオフロードサブシステムと、
   前記外部コンポーネントとの通信を可能にするインターフェイスと、
   前記メインプロセッサ、前記オフロードサブシステム、前記インターフェイスに接続され、前記メインプロセッサと前記オフロードサブシステムの両方が、前記インターフェイスを介して前記外部コンポーネントと通信することを可能にする相互接続と、を含むことを特徴とする、
   統合処理システム。
2. 前記オフロードサブシステムが、データ転送タスクを実行するためのネットワークエンジンを含むことを特徴とする、請求項１に記載の統合処理システム。
3. 前記ネットワークエンジンが、受信したデータパケットが既知のデータフローに関連付けられているか否かを判断し、前記受信したデータパケットが既知のデータフローに関連付けられている場合、前記受信したデータパケットを転送し、前記受信したデータパケットが既知のデータフローに関連付けられていない場合、前記受信したデータパケットをフロー識別のため前記メインプロセッサに転送するように構成され、前記メインプロセッサが、前記受信したデータパケットが前記ネットワークエンジンにより前記メインプロセッサに転送された場合、前記受信したデータパケットが関連付けられているデータフローを識別し、前記識別されたデータフローを既知のデータフローとして前記ネットワークエンジンに設定するように構成されたことを特徴とする、請求項２に記載の統合処理システム。
4. 前記ネットワークエンジンが、前記受信したデータパケットが前記メインプロセッサにより以前に前記ネットワークエンジン内に設定されたデータフローに関連付けられているか否かを判断することで、前記受信したデータパケットが既知のデータフローに関連付けられているか否かを判断するように構成されたことを特徴とする、請求項３に記載の統合処理システム。
5. 前記メインプロセッサが、学習プロセスにおいてオフロードエンジンテーブルを更新し、それ以降受信されるデータパケットが前記識別されたデータフローと関連付けられることによって、前記ネットワークエンジンで処理可能に構成されていることを特徴とする、請求項３または４に記載の統合処理システム。
6. データフローが、特定のタイプのデータパケット、ソースに関連付けられたデータパケット、宛先に関連付けられたデータパケットの１つ以上を含むことを特徴とする、請求項３乃至５のいずれかに記載の統合処理システム。
7. 前記オフロードサブシステムが、受信したデータパケットに対してセキュリティ関連タスクを実行するためのセキュリティエンジンを含むことを特徴とする、請求項１乃至６のいずれかに記載の統合処理システム。
8. 前記セキュリティエンジンが、コンフィギュラブルなハードコードされた暗号化コアを含むことを特徴とする、請求項７に記載の統合処理システム。
9. 前記オフロードサブシステムがパケットエンジンを含むことを特徴とする、請求項１乃至８のいずれかに記載の統合処理システム。
10. 前記パケットエンジンが、パケットエンジンソフトウェアを実行する追加のプロセッサを含むことを特徴とする、請求項９に記載の統合処理システム。
11. 前記メインプロセッサが第１のプロセッサタイプであり、前記追加のプロセッサが、前記第１のプロセッサタイプと異なる第２のプロセッサタイプであることを特徴とする、請求項１０に記載の統合処理システム。
12. 前記メインプロセッサが、相互接続を介して前記オフロードサブシステムによるメインプロセッサメモリキャッシュへのアクセスを可能としていることを特徴とする、請求項１乃至１１のいずれかに記載の統合処理システム。
13. さらに、前記相互接続に接続され、前記メインプロセッサおよび前記オフロードサブシステムにより読み出し可能な、関連付けられた各メールボックスを格納するメモリと、前記メインプロセッサが前記オフロードサブシステムに関連付けられた前記メールボックスにメッセージを書き込むことを可能にし、前記オフロードサブシステムが前記メインプロセッサに関連付けられたメールボックスにメッセージを書き込むことを可能にする、前記相互接続と、を含むことを特徴とする、請求項１乃至１１のいずれかに記載の統合処理システム。
14. 前記外部コンポーネントが、ソフトウェアドライバを介して制御可能な外部コンポーネントを含み、前記メインプロセッサが前記ソフトウェアドライバの第１部分を実行し、前記オフロードサブシステムが前記ソフトウェアドライバの第２部分を実行することを特徴とする、請求項１に記載の統合処理システム。
15. 前記インターフェイスが、コンフィギュラブルインターフェイスを含み、前記コンフィギュラブルインターフェイスが、複数の異なる物理インターフェイスのいずれかと組み合わせた動作向けに構成可能なコンフィギュラブルコンポーネントを含むことを特徴とする、請求項１乃至１１のいずれかに記載の統合処理システム。
16. 前記コンフィギュラブルコンポーネントが、前記メインプロセッサにより構成可能なＳｅｒＤｅｓ（シリアライザ／デシリアライザ）を含むことを特徴とする、請求項１５に記載の統合処理システム。
17. 前記複数の異なる物理インターフェイスが、ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｅｘｐｒｅｓｓ）インターフェイス、ＳＡＴＡ（Ｓｅｒｉａｌ Ａｄｖａｎｃｅｄ Ｔｅｃｈｎｏｌｏｇｙ Ａｔｔａｃｈｍｅｎｔ）インターフェイス、ＵＳＢ（ユニバーサルシリアルバス）インターフェイスを含むことを特徴とする、請求項１６に記載の統合処理システム。
18. 集積回路パッケージ内に、統合処理システム外部の外部コンポーネントからデータパケットが受信されるときに使用されるパケットベースのプロトコル中の管理または制御パケットに関連付けられたプロトコル管理タスクを実行するメインプロセッサを提供する工程と、
    前記集積回路パッケージ内に、前記パケットベースのプロトコルに従って受信されたデータパケットに対してデータ処理タスクを実行するオフロードサブシステムを提供する工程と、
    前記集積回路パッケージ内に、前記外部コンポーネントとの通信を可能にするインターフェイスを提供する工程と、
    前記集積回路パッケージ内に、前記メインプロセッサ、前記オフロードサブシステム、前記インターフェイスに接続され、前記メインプロセッサと前記オフロードサブシステムの両方が、前記インターフェイスを介して前記外部コンポーネントと通信することを可能にする相互接続を提供する工程と、を含むことを特徴とする、
    方法。
19. 集積回路パッケージ内のメインプロセッサにより、前記集積回路パッケージ外部の外部コンポーネントからデータパケットが受信されるときに使用されるパケットベースのプロトコル中の管理または制御パケットに関連付けられたプロトコル管理タスクを実行する工程と、
    前記集積回路パッケージ内のオフロードサブシステムにより、前記パケットベースのプロトコルに従って受信したデータパケットに対してデータ処理タスクを実行する工程と、
    前記メインプロセッサと前記オフロードサブシステムの両方により、前記外部コンポーネントを制御する工程と、を含むことを特徴とする、
    方法。
20. 前記データ処理タスクが、特定のタイプのデータパケットに対して実行される１つ以上のタスクを含み、前記方法がさらに、前記オフロードサブシステムにより、受信したデータパケットが前記特定のタイプのデータパケットであるか否かを判断する工程と、前記受信したデータパケットが前記特定のタイプのデータパケットであると判断された場合、前記オフロードサブシステムにより、１つ以上のタスクを実行する工程と、前記受信したデータパケットのデータパケットタイプが前記オフロードサブシステムにより判断できない場合、前記受信したデータパケットを前記オフロードサブシステムからデータパケットタイプの識別のために前記メインプロセッサに転送する工程と、前記受信したデータパケットが前記メインプロセッサに転送された場合、前記メインプロセッサにより、前記受信したデータパケットのデータパケットタイプを識別する工程と、識別された前記データパケットタイプを前記オフロードサブシステム内に設定する工程と、を含むことを特徴とする、請求項１９に記載の方法。
21. さらに、前記データ処理タスクを実行するように、前記オフロードサブシステム内のコンフィギュラブルなハードコードされたハードウェアを構成する工程を含むことを特徴とする、請求項１９または２０に記載の方法。
22. さらに、前記オフロードサブシステムによるメインプロセッサメモリキャッシュへのアクセスを可能とする工程を含むことを特徴とする、請求項１９乃至２１のいずれかに記載の方法。
23. 前記外部コンポーネントが、ソフトウェアドライバを介して制御可能な外部コンポーネントを含み、前記メインプロセッサが実行する工程が、前記ソフトウェアドライバの第１部分の実行を含み、前記オフロードサブシステムが実行する工程が、前記ソフトウェアドライバの第２部分に関連付けられたタスクの実行を含む、ことを特徴とする、請求項１９に記載の方法。
24. 処理アーキテクチャであって、
    集積回路パッケージ内に、
    統合処理システム外部のＷｉＦｉ(登録商標)デバイスからデータパケットが受信されるときに使用されるＷｉＦｉ（Ｗｉｒｅｌｅｓｓ Ｆｉｄｅｌｉｔｙ）プロトコル中の管理または制御パケットに関連付けられたプロトコル管理タスクを実行するメインプロセッサと、
    前記ＷｉＦｉプロトコルに従って受信されたデータパケットに対してデータ処理タスクを実行するオフロードサブシステムと、
    前記ＷｉＦｉデバイスとの通信を可能にするインターフェイスと、
    前記メインプロセッサ、前記オフロードサブシステム、前記インターフェイスに接続された相互接続と、を含むことを特徴とする、
    処理アーキテクチャ。
25. さらに、前記相互接続に接続され、イーサネット（登録商標）パケットの転送を実行するネットワークエンジンと、それぞれがＷｉＦｉドライバトンネルモジュールを含む前記メインプロセッサおよび前記オフロードサブシステムを含み、前記ネットワークエンジンを介して、前記メインプロセッサと前記オフロードサブシステム間で交換するためにＷｉＦｉパケットがイーサネットパケットにカプセル化されることを特徴とする、請求項２４に記載の処理アーキテクチャ。
26. 前記メインプロセッサが、上位レイヤＷｉＦｉドライバソフトウェアを実行するように構成され、前記オフロードサブシステムが、下位レイヤＷｉＦｉドライバソフトウェアを実行するように構成され、前記下位レイヤＷｉＦｉドライバソフトウェアが、前記オフロードサブシステムに、未知のフローの最初に受信したＷｉＦｉデータパケットをフロー識別のために前記メインプロセッサに転送させ、前記メインプロセッサによるフロー識別後、そのフローからの後続のパケットを処理させることを特徴とする、請求項２４に記載の処理アーキテクチャ。
27. 前記インターフェイスが、ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ ｅｘｐｒｅｓｓ）インターフェイスを含むことを特徴とする、請求項２４乃至２６のいずれかに記載の処理アーキテクチャ。
28. 周辺デバイス用のドライバソフトウェア内において、周辺デバイスが動作に使用するパケットベースのプロトコル内の管理または制御パケットに関連付けられたプロトコル管理タスクを特定する工程と、
    前記プロトコル管理タスクを含む前記ドライバソフトウェアの部分を、前記ドライバソフトウェアの残り部分から分離する工程と、
    前記ドライバソフトウェアの残り部分の実装を提供する工程と、
    前記ドライバソフトウェアの前記部分と前記ドライバソフトウェアの前記残り部分間のインターフェイスと一致する上位レイヤインターフェイスと、前記ドライバソフトウェアの前記残り部分の実装と一致する下位レイヤインターフェイスを含み、前記ドライバソフトウェアの前記残り部分の実装から、前記ドライバソフトウェアの前記部分を異なるハードウェア上で実行可能とする、ソフトウェアアダプテーションレイヤを提供する工程と、を含むことを特徴とする、
    方法。
29. 統合処理システムであって、
    前記統合処理システム外部の外部コンポーネントからデータが受信されるときに使用されるプロトコルに関連付けられたプロトコル管理タスクを実行するメインプロセッサと、
    前記メインプロセッサに接続され、前記プロトコルに従って受信され、既知のデータフローに関連付けられたデータに対してデータ処理タスクを実行するオフロードサブシステムと、を含み、
    前記オフロードサブシステムが、受信したデータが既知のデータフローに関連付けられているか否かを判断し、前記受信したデータが既知のデータフローに関連付けられている場合、前記受信したデータに対してデータ処理タスクを実行し、前記受信したデータが既知のデータフローに関連付けられていない場合、フロー識別のため前記受信したデータを前記メインプロセッサに転送するように構成され、
    前記メインプロセッサが、前記受信したデータが前記オフロードサブシステムにより前記メインプロセッサに転送された場合、前記受信したデータが関連付けられているデータフローを識別し、前記識別されたデータフローを既知のデータフローとして前記オフロードサブシステムに設定するように構成されたことを特徴とする、
    統合処理システム。
30. 統合処理システム内のメインプロセッサにより、集積回路パッケージ外部の外部コンポーネントからデータが受信されるときに使用されるプロトコルに関連付けられたプロトコル管理タスクを実行する工程と、
    前記統合処理システム内の前記メインプロセッサに接続されたオフロードサブシステムにより、前記プロトコルに従って受信されたデータが、前記オフロードサブシステム内に設定された既知のデータフローに関連付けられているか否かを判断する工程と、
    前記受信したデータが既知のデータフローに関連付けられている場合、前記オフロードサブシステムにより、前記受信したデータに対してデータ処理タスクを実行する工程と、
    前記受信したデータが既知のデータフローに関連付けられていない場合、前記受信したデータを前記オフロードサブシステムから前記メインプロセッサにデータフロー識別のために転送する工程と、
    前記受信したデータが前記メインプロセッサに転送された場合、前記メインプロセッサにより、前記受信したデータが関連付けられているデータフローを識別する工程と、
    前記メインプロセッサにより、前記識別されたデータフローを既知のデータフローとして前記オフロードサブシステムに設定する工程と、
    前記オフロードサブシステムにより、前記識別されたデータフローに関連付けられた後続の受信データに対してデータ処理タスクを実行する工程と、を含むことを特徴とする、
    方法。

Images