JP4807861B2 - サーバ環境においてオフロードをネットワーク化するためのホスト・イーサネット・アダプタ - Google Patents

Description

本発明は、一般的にはサーバ環境に関し、特にその様な環境において利用されるアダプタに関する。

関連出願との相互参照
本出願は下記の同時係属中の米国特許出願と関連している。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“数個のイーサネット・ポートと、簡易化されたフレーム・バイ・フレーム上部構造により処理されるラップ伝送されるフローとに配慮するための方法及びシステム（Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ａｃｃｏｍｍｏｄａｔｉｎｇ Ｓｅｖｅｒａｌ Ｅｔｈｅｒｎｅｔ Ｐｏｒｔｓ ａｎｄ ａ Ｗｒａｐ Ｔｒａｎｓｍｉｔｔｅｄ Ｆｌｏｗ Ｈａｎｄｌｅｄ ｂｙ ａ Ｓｉｍｐｌｉｆｉｅｄ Ｆｒａｍｅ−Ｂｙ−Ｆｒａｍｅ Ｕｐｐｅｒ Ｓｔｒｕｃｔｕｒｅ）”と題された米国特許出願第 １１／０９６３６３ 号（代理人事件整理番号ＲＰＳ９２００５００６０ＵＳ１／３４８６Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ネットワーク接続テーブルを提供するための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｐｒｏｖｉｄｉｎｇ ａ Ｎｅｔｗｏｒｋ Ｃｏｎｎｅｃｔｉｏｎ Ｔａｂｌｅ）”と題された米国特許出願第 １１／０９６５７１ 号（代理人事件整理番号ＲＰＳ９２００５００６１ＵＳ１／３４８７Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“オペレーティング・システム・パーティションのためのネットワーク通信（Ｎｅｔｗｏｒｋ Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ ｆｏｒ Ｏｐｅｒａｔｉｎｇ Ｓｙｓｔｅｍ Ｐａｒｔｉｔｉｏｎｓ）”と題された米国特許出願第 １１／０９７０５１ 号（代理人事件整理番号ＲＰＳ９２００５００６２ＵＳ１／３４８８Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ホスト・イーサネット・アダプタのための設定可能なポート（Ｃｏｎｆｉｇｕｒａｂｌｅ Ｐｏｒｔｓ ｆｏｒ ａ Ｈｏｓｔ Ｅｔｈｅｒｎｅｔ Ａｄａｐｔｅｒ）”と題された米国特許出願第 １１／０９７６５２ 号（代理人事件整理番号ＲＰＳ９２００５００７３ＵＳ１／３５０２Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ホスト・イーサネット・アダプタ（ＨＥＡ）においてチェックサムを構文解析し、フィルタリングし、計算するためのシステム及び方法（Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｐａｒｓｉｎｇ， Ｆｉｌｔｅｒｉｎｇ， ａｎｄ Ｃｏｍｐｕｔｉｎｇ ｔｈｅ Ｃｈｅｃｋｓｕｍ ｉｎ ａ Ｈｏｓｔ Ｅｔｈｅｒｎｅｔ Ａｄａｐｔｅｒ （ＨＥＡ））”と題された米国特許出願第 １１／０９６３６５ 号（代理人事件整理番号ＲＰＳ９２００５００７４ＵＳ１／３５０３Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ホスト・イーサネット・アダプタ（ＨＥＡ）において待ち時間を短縮する方法のためのシステム及び方法（Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ ａ Ｍｅｔｈｏｄ ｆｏｒ Ｒｅｄｕｃｉｎｇ Ｌａｔｅｎｃｙ ｉｎ ａ Ｈｏｓｔ Ｅｔｈｅｒｎｅｔ Ａｄａｐｔｅｒ （ＨＥＡ））”と題された米国特許出願第 １１／０９６３５３ 号（代理人事件整理番号ＲＰＳ９２００５００７５ＵＳ１／３５０４Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ネットワーク伝送のためのブラインド・チェックサム及び訂正のための方法及び装置（Ｍｅｔｈｏｄ ａｎｄ Ａｐｐａｒａｔｕｓ ｆｏｒ Ｂｌｉｎｄ Ｃｈｅｃｋｓｕｍ ａｎｄ Ｃｏｒｒｅｃｔｉｏｎ ｆｏｒ Ｎｅｔｗｏｒｋ Ｔｒａｎｓｍｉｓｓｉｏｎｓ）”と題された米国特許出願第 １１／０９７０５５ 号（代理人事件整理番号ＲＰＳ９２００５００７６ＵＳ１／３５０５Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“パケット・ヘッダ・ルックアップを実行する方法及びシステム （Ｍｅｔｈｏｄ ａｎｄ Ｓｙｓｔｅｍ ｆｏｒ Ｐｅｒｆｏｒｍｉｎｇ ａ Ｐａｃｋｅｔ Ｈｅａｄｅｒ Ｌｏｏｋｕｐ）”と題された米国特許出願第 １１／０９６３６２ 号（代理人事件整理番号ＲＰＳ９２００５００８２ＵＳ１／３５１２Ｐ）。
本願と同じ日に出願されて本発明の譲受人に譲渡された、“ホスト・イーサネット・アダプタ（ＨＥＡ）においてブラインド・チェックサムを計算するシステム及び方法（Ｓｙｓｔｅｍ ａｎｄ Ｍｅｔｈｏｄ ｆｏｒ Ｃｏｍｐｕｔｉｎｇ ａ Ｂｌｉｎｄ Ｃｈｅｃｋｓｕｍ ｉｎ ａ Ｈｏｓｔ Ｅｔｈｅｒｎｅｔ Ａｄａｐｔｅｒ（ＨＥＡ））”と題された米国特許出願第 １１／０９７４３０ 号（代理人事件整理番号ＲＰＳ９２００５００８９ＵＳ１／３５１６Ｐ）。

図１は、在来のサーバ・システム１０を示す。サーバ・システム１０は、メイン・メモリ１４に接続されたプロセッサ１２を含む。プロセッサ１２は、そのプライベート・バス（ＧＸ）１６を介して、ネットワーク・インターフェース・システム１８を含むシステムに接続される。ネットワーク・インターフェース・システム１８は、ＰＣＩバス２２等を介してアダプタ２０に接続されている。周知されているように、ＰＣＩ２２バスは、それを通って流れることのできるトラフィックの量に影響を及ぼす限られた帯域幅を有する。

インターネット及びそのアプリケーションは、サーバが満たさなければならないクライアントのリクエストの数を途方も無く増やした。各クライアントのリクエストは、ネットワークＩ／Ｏ及び記憶装置Ｉ／Ｏの両方を生じさせる。更に、１０ギガビットのイーサネット及びＩＰ記憶装置の出現はデータ・センタ通信を単一のバックボーン・インフラストラクチャ：イーサネット、ＴＣＰ／ＩＰ、に整理統合することを可能にする。

しかし、１０ギガビットの速度でのＴＣＰ／ＩＰは、主流サーバにおいて膨大な処理及びメモリ帯域幅を消費し、従ってアプリケーションを動作させるサーバの能力を厳しく制限する。

今日のサーバのネットワーク・インターフェース・コントローラ（ＮＩＣ）においては、ＴＣＰ及びＩＰチェックサム、ラージ・センド（Ｌａｒｇｅ Ｓｅｎｄ）（又はＴＣＰセグメンテーション・オフロード）のような機能の限られたオフローディングがサポートされる。しかし、これらの機能は１Ｇまでは充分であるが、１０Ｇ以上のようなより大きな速度については問題を解決しない。

ＴＣＰ／ＩＰプロトコル・スタック全体をサーバから完全にオフロードするためにＴＣＰオフロード・エンジンを用いることが知られている。しかし、ＴＯＥのインプリメンテーションは、一般に、ハードウェアで、或いは割合に複雑なピコ・プロセッサ・アーキテクチャにおいてはピココードで、実現される。デバッグ、問題判別及びスタック・メンテナビリティ問題もある。更に、ピコエンジンはメイン・プロセッサ・ロードマップに従わないのでピココードを用いるときにはスカビリティ（ｓｃａｂｉｌｉｔｙ）問題がある。最後に、オフロード・エンジンは、通例、新しいプロトコルとＡＰＩとを導入し、従ってアプリケーション及び相互接続性問題における変化を必要とする。

従って、必要とされるのは、上で特定された問題を克服する、イーサネット環境で大帯域幅データを考慮するシステム及び方法である。本発明は、このような必要に対処する。

イーサネット・アダプタが開示される。このイーサネット・アダプタは、このアダプタがプロセッサからパケットを受け取り、またプロセッサにパケットを送ることを可能にする複数の層を含む。この複数の層は、プロセッサの分割を考慮する多重分離メカニズムを含む。

ホスト・イーサネット・アダプタ（ＨＥＡ）は、イーサネット及びＴＣＰ高速化への新しいアプローチを提供する統合イーサネット・アダプタである。ＴＣＰ／ＩＰ高速化特徴のセットがツールキット・アプローチに導入されており、サーバＴＣＰ／ＩＰスタックは、必要とされるときに必要に応じてこれらのアクセラレータを使用する。サーバとネットワーク・インターフェース・コントローラとの間のインターフェースは、ＰＣＩバスを回避することによって合理化されている。

ＨＥＡは、ネットワーク仮想化をサポートする。ＨＥＡは、その性能に影響を及ぼすこと無く必須の絶縁及び保護を提供する複数のＯＳにより共有され得る。

本発明は一般的にサーバ環境に、特にその様な環境で利用されるアダプタに関連する。以下の記述は、当業者が本発明を製造し使用することを可能にするために、特許出願及びその要件という関係において提示されている。本明細書に記載されている好ましい実施態様及び一般的原理及び特徴に対する種々の改変が当業者にとっては自明であろう。従って、本発明は、示されている実施態様に限定されるように意図されてはおらず、本明細書に記載されている原理及び特徴と矛盾しない最も広い範囲を与えられるべきである。

図２は、本発明によるサーバ・システム１００のブロック図である。サーバ・システム１００は、メモリ１０４とインターフェース・アダプタ・チップ１０６との間に接続されたプロセッサ１０２を含む。インターフェース・アダプタ・チップ１０６は、プロセッサ１０２のプライベート（Ｇｘ）バスとのインターフェース１０８と、ホスト・イーサネット・アダプタ（ＨＥＡ）１１０とを含む。ＨＥＡ１１０は、プロセッサ１０２から信号を受信し、またプロセッサ１０２に信号を送信する。

ＨＥＡ１１０は統合イーサネット・アダプタである。サーバ内において、アクセラレータ特徴のセットがＴＣＰ／ＩＰスタックに設けられている。プロセッサ１０２とインターフェース・アダプタ・チップ１０６との間のインターフェース１００は、ＰＣＩバスを回避することによって合理化されて、多重分離及びマルチキューイング及びパケット・ヘッダ分離を可能にするインターフェース技術を提供している。

ＨＥＡ１１０は、ＧＸ＋バスに直接接続され、従って非常に大きな帯域幅（８６６Ｍｈｚで５５．４２Ｇｂｐｓ）を持っていて２つの１０Ｇｂｐｓポートの全４０Ｇｂｐｓ帯域幅を実際にサポートすることにより、無比の性能レベルを達成する。６４ビットＰＣＩ−Ｘ１３３ＭＨｚバスは８．５１Ｍｂｐｓに限定されており、２つの１０Ｇｂｐｓポートのスループットと調和するように少なくともＰＣＩ Ｅｘｐｒｅｓｓ ｘ８バスが要求されるということに注意しなければならない。ＧＸバス上に存在することは、中間の論理を除去するので、転送待ち時間を改善する。

そのとき、レガシー・サーバ環境との両立性に配慮しながら高速システムでの改善された機能性に配慮するイーサネット・アダプタが設けられる。この改善された機能性の重要な特徴のうちの幾つかが以下に記載される。

高速化機能
ＨＥＡ１１０は、高度な高速化特徴をサポートする。１つの重要な所見は、現在の高速化機能は送信側（すなわち、プロセッサからパケットを送信する）では充分に働くが受信側（すなわちアダプタを通してパケットを受信する）では充分ではないということである。ＨＥＡ１１０は、パケット多重分離及びマルチキューイング、及びヘッダ分離のような新しい特徴を導入することによってこのギャップに対処する。

ＨＥＡ１１０の新しい特徴の全てはオプションであり、必要なときにそれらを利用することはＴＣＰ／ＩＰスタック次第である。例えば、ＴＣＰ／ＩＰスタックは、ＨＥＡ１１０を使用し、またスループット、短待ち時間及び仮想化サポートのようなＨＥＡの他の特徴を利用することができる。

パケット多重分離及びマルチキューイング
マルチキューイング及び多重分離は、仮想化、パー・コネクション・キューイング、及びＯＳバイパスのような機能をサポートする重要な特徴である。ＨＥＡ多重分離は、キュー・ペア、完了キュー及びイベント・キューというコンセプトを用いる。ＯＳプロトコル・スタック要件及び短パケット待ち時間短縮により良く対処するために拡張機能が付け加えられている。

システム要件及び構成に依存して、ＨＥＡは、入ってくるパケットを、
− 宛先ＭＡＣアドレス（通例、１つのＭＡＣアドレスと、パーティションあたりに１つのデフォルト・キューと）、
− 確立された接続についての接続識別子（プロトコル、ソースＩＰアドレス、宛先ＩＰアドレス、ソース・ポート、宛先ポート）、
− 宛先ポート及びオプションでＴＣＰ接続セットアップ・パケット（ＳＹＮ）についての宛先ＩＰアドレス、
に基づいて多重分離することができる。

パケット・ヘッダ分離
ＨＥＡ１１０は、ＴＣＰ／ＩＰヘッダをデータ・ペイロードから分離することができる。この特徴は、アプリケーションにより掲示された受信バッファを汚さずに処理されるようにヘッダをプロトコル・スタックに向けることを可能にする。

拡張された特徴
サーバ環境においてＨＥＡ１１０により多くの拡張された特徴が提供される。それらの特徴のうちの幾つかが以下に列挙される。

１． 複数の受信キュー。キュー・ペアのコンセプトが、ペアあたりに２つ以上の受信キューをサポートするように拡張される。これは、スタックがそのバッファ・プール・メモリをより良く管理することを可能にする。例えば、１つのキューを小さなパケットに、１つを中型のパケットに、そして１つを大きなパケットに割り当てることができる。ＨＥＡ１１０は、受信されたパケットのサイズに応じて、そのためのキューを選択する。

２． 短待ち時間キュー。送信側においてディスクリプタ（ＷＱＥ）は即値データを含むことができ、その様な場合にはデータを送信するためにインダイレクションすなわちシステム・メモリからの付加的なＤＭＡは不要である。受信側において、短待ち時間キューはバッファを供給せずに、即値パケット・データを受信する。ＨＥＡ１１０は受信キューに直接書き込む。短いパケットはこの特徴を利用し、ＤＭＡ動作の劇的減少という結果をもたらす。すなわち、パケットあたりに１つのＤＭＡリード及び１つのＤＭＡライトに対してパケットあたりに唯一のＤＭＡライト。

受信短待ち時間キューは、パケット・ヘッダ分離をサポートするためにも使用される。ヘッダは短待ち時間キューに書き込まれ、ペイロードはその場合の受信キューにおいて示されているバッファにＤＭＡされる。

要約すると、多重分離及びマルチキューイング、及びパケット・ヘッダ分離は、仮想化の基本的構成要素であり、短待ち時間操作を提供する。更に、これらの特徴が在来のＯＳプロトコル・スタック性能を改善するためにも使用され得ることに留意するべきであり、例えばパー・コネクション・キューイングは、コードの除去に配慮しており、そしてもっと重要なことに、メモリ内の適切な情報の位置を突き止めるために消費されるメモリ・アクセスと、関連した機能停止／キャッシュ汚染とを減少させる。

ＨＥＡ１１０の特徴をより詳しく記述するために、以下の記述を添付図面と関連させて参照されたい。

図３は、本発明によるＨＥＡ１１０の略ブロック図である。見たとおりに、ＨＥＡ１１０は３層アーキテクチャを有する。第１層は、イーサネット・ネットワーク上の他の装置からの及びそれらの装置への複数のインターフェースを提供する媒体アクセス・コントローラ（ＭＡＣ）及び並直列変換回路（Ｓｅｒｄｅｓ）層２０２を含む。層２０２において、複数のインターフェースを提供するために同じチップＩ／Ｏが使用される。例えば、好ましい実施態様では、１０ギガビット・インターフェース又は１ギガビット・インターフェースを提供するために同じチップＩ／Ｏが利用される。

第２層は、パケット高速化及び仮想化層２０４を含む。層２０４は、パケットを受信して、仮想化を可能にするためにパケットのフローを多重分離することに配慮している。層２０４は、パケットに基づくサーバのオペレーティング・システムの仮想化又は分割を可能にする。層２０４は、ゼロ・コピー操作を可能にし、従って改善された待ち時間を提供するためにパケット・ヘッダ分離も提供する。また、層２０４はホスト・インターフェース層２０６を通してプライベート・バス（Ｇｘ）と直接相互に作用するので、短待ち時間、大帯域幅接続が提供される。

第３層はホスト・インターフェース層２０６を含む。ホスト・インターフェース層２０６は、プロセッサのＧｘ又はプライベート・バスへのインターフェースを提供し、層２０４と通信する。層２０６は、ＴＣＰスタックのために効率的バッファ管理を可能にするためにキュー・ペア（ＱＰ）あたりに複数の受信サブ・キューに配慮している。ホスト層２０６は、データ・パケットの所与のフローのためにコンテクスト管理を提供する。

ＨＥＡ１００の層２０２，２０４及び２０６の各々の特徴をより詳しく記述するために、以下の検討を添付図面と関連させて参照されたい。

ＭＡＣ及びＳｅｒｄｅｓ層２０２
図４は、ＭＡＣ及びＳｅｒｄｅｓ層２０２をより詳しく示すＨＥＡ１１０のブロック図である。見たとおりに、この実施態様には１つの１０ギガビットＭＡＣ３０２と４つの１ギガビットＭＡＣ３０４ａ及び３０４ｂとがある。ＭＡＣ３０２，３０４及び３０４ｂは、受信されたパケットを整列させて符号化するためのアナログ符号化ユニット３０８ａ、３０８ｂ及び３０８ｃを含む。ＭＡＣ３０２，３０４ａ及び３０４ｂは高速並直列変換回路（ＨＳＳ）３０６に接続されている。高速Ｓｅｒｄｅｓ３０６は、１つの１０ギガビット・ソース又は４つの１ギガビット・ソースからデータを受信することができる。

受信イーサネット機能（ＲｘＮｅｔ）概観
このセクションは、層２０２内の受信イーサネット機能の高レベル構造及びフローを示す。以下でより詳しく説明されるＲｘアクセラレータ・ユニット４００は、パケット高速化及び仮想化層２０４の一部である。

図５は、ＲｘＮｅｔの１つについてコンポーネント及びデータフローを示す。データは、インターフェース３０２に到着して、この実施態様ではパケット・データを６４ビット（１０Ｇ）又は３２ビット（１Ｇ）のパラレル・データ・バスにおいてアセンブルし整列させ高速Ｓｅｒｄｅｓ３０４と、アナログ符号化ユニット３０８ａ及び３０８ｂと、ＭＡＣとによって処理される。フレームの開始及び終了及び他のパケット情報を示す制御信号も生成される。データ及び制御は、層２０６（図２）の受信パケット・プロセッサ（ＲＰＰ）による処理に備えて構文解析、フィルタリング、チェックサム及びルックアップ機能を実行するＲｘＡｃｃｅｌユニット４００を通過する。この実施態様では、ＲｘＡｃｃｅｌユニット４００に入るとクロックは４．６ｎｓクロックに変換され、データ幅は１２８ｂに変換される。

データがＲｘＡｃｃｅｌユニット４００を通ってホスト層２０６内のデータ・バッファに流れるとき、ＲｘＡｃｃｅｌユニット４００は制御及びデータを調査してその処理を開始する。ＲｘＡｃｃｅｌユニット４００の結果がパケットの末端と同期化されるようにデータ・フローはＲｘＡｃｃｅｌユニット４００内で遅延させられる。このとき、ＲｘＡｃｃｅｌユニット４００の結果は、ＭＡＣ３０２からの何らかのオリジナル制御情報と共にコマンド・キューに渡される。この制御情報は、データと共にバッファに格納される。

ＲｘＡｃｃｅｌユニット４００は、ルックアップ・エントリがキャッシングされていなければ、ＧＸバス・インターフェースを通してメイン・メモリに行かなければならないかもしれない。ＧＸバスは４．６ｎｓで動作する。ホスト層２０６は、ＲｘＡｃｃｅｌユニット４００からのキュー・ペア解像度（ｑｕｅｕｅ ｐａｉｒ ｒｅｓｏｌｕｔｉｏｎ）情報を非同期的に読むことができる。

送信イーサネット機能（ＴｘＥｎｅｔ）概観
このセクションは、イーサネット及び高速化機能の送信構造及びフローの概観を提供する。以下でより詳しく説明されるＴｘアクセラレータ・ユニット５００は、パケット高速化及び仮想化層２０４の一部である。

図６は、１つのＴｘＥｎｅｔについてのコンポーネント及びデータフローを示す。パケット・データ及び制御はＨＥＡ１１０のＴｘＡｃｃｅｌ５００コンポーネントから到着する。Ｔｘアクセラレータ（ＴｘＡｃｃｅｌ）ユニット５００は、制御情報を解釈して、ユニット５００を通って流れるパケットのヘッダのフィールドを改変する。それは、制御情報又はパケット・ヘッダにおいて見出された情報に基づいてラップ対ポート決定（ｗｒａｐ ｖｅｒｓｕｓ ｐｏｒｔ ｄｅｃｉｓｉｏｎ）を行う。それは、また、ＴｘＭＡＣ３０２及び３０４のための適切な制御を生成する。ＴｘＡｃｃｅｌユニット５００がパケット・ヘッダを、ＭＡＣ３０２及び３０４へ流れる前に、更新できるように、データ・フローはＴｘＡｃｃｅｌユニット５００において遅延させられる。出口で、データ幅は１２８ビットから６４ビット（１０Ｇ）又は３２ビット（１Ｇ）に変換される。データ及び制御は、ＭＡＣ３０２及び３０４の異なるクロック・ドメインに入るためにＴｘＡｃｃｅｌユニット５００のクロック変換機能を通過する。ＭＡＣ３０２及び３０４、アナログ変換器５０８ａ及び５０８ｂ、及び高速Ｓｅｒｄｅｓ３０６は、イーサネット・インターフェースのためにパケットをフォーマットする。

パケット高速化及び仮想化層２０４
図７は、パケット高速化及び仮想化層２０４をより詳しく示すＨＥＡ１１０のブロック図である。ＨＥＡ層２０４は、前記の受信（ＲｘＡｃｃｅｌ）高速化ユニット４００と送信高速化（ＴｘＡｃｃｅｌ）ユニット５００とを含む。ＲｘＡｃｃｅｌユニット４００は、受信バックボーン（ＲＢＢ）４０２と、パーサ・フィルタ・チェックサム・ユニット（ＰＦＣ）４０４と、ルックアップ・エンジン（ＬＵＥ）４０６と、ＭＩＢデータベース４０８とを含む。ＴｘＡｃｃｅｌユニット５００は、送信バックボーン５０２と、ルックアップ・チェック５０４と、ＭＩＢエンジン５０６とを含む。Ｒｘ高速化ユニット４００及びＴｘ高速化ユニット５００の動作が以下で詳しく説明される。

受信高速化（ＲｘＡｃｃｅｌ）ユニット４００
このセクションはＲｘＡｃｃｅｌユニット４００の高レベル構造を説明する。図８は、ＲｘＡｃｃｅｌユニット４００の詳細図である。ＲｘＡｃｃｅｌユニット４００は、受信バックボーン（ＲＢＢ）４０２と、パーサ、フィルタ及びチェックサム・ユニット（ＰＦＣ）４０４と、ローカル・ルックアップ・ユニット（ＬＬＵ）４０６と、リモート・ルックアップ・ユニット（ＲＬＵ）４０８と、ＭＩＢデータベース４１０とを含む。

データは、受信ＭＡＣからＲｘＡｃｃｅｌユニット４００を通って変更されずに流れる。ＲＢＢ４０２はデータのフローを管理し、クロック及びデータ・バス幅変換機能を担う。受信ＭＡＣから受信された制御及びデータは、高速化機能を実行し廃棄決定を行うためにＰＦＣ４０４により使用される。ＰＦＣ４０４は、ＲＢＢ４０２のためにキュー・ペア番号（ＱＰＮ）を解明するためにフレームから抽出された５タプル・キーを含む制御及びデータをＬＬＵ４０６に渡す。ＬＬＵ４０６は、ＱＰＮを直ちに見出すか、又はスロットを確保するためにキャッシュ・エントリを割り当てる。もし現在のキーがキャッシュ内に無ければ、ＬＬＵ４０６はメイン・メモリにおいてキーを捜す。ＰＦＣ４０４は、パケット統計を格納するためにＭＩＢデータベース４１０へインターフェースする。

Ｔｘ高速化５００
このセクションは、送信高速化ユニット５００（ＴｘＡｃｃｅｌ）の高レベル構造とフローを説明する。

図９は、ＴｘＡｃｃｅｌユニット５００が２つの送信バックボーン（ＸＢＢ）５０２ａ及び５０２ｂ、２つの送信チェックサム・ユニット（ＸＣＳ）５０４ａ及び５０４ｂ、２つの送信ＭＩＢ５０６ａ及び５０６ｂ、１つのラップ・ユニット（ＷＲＰ）５０８、及び１つのポーズ・ユニット（ＰＡＵ）論理５１０から構成されていることを示す。データは，ＥＮｏｐからＴｘＡｃｃｅｌを通って流れて、ＩＰ及びＴＣＰチェックサム・フィールドを調整するために改変される。ＸＢＢ５０２ａ及び５０２ｂは、データのフローを管理し、クロック及びデータ・バス幅変換機能を担う。ＥＮｏｐから受信された制御及びデータは、チェックサム機能を実行するためにＸＣＳ５０４ａ及び５０４ｂにより使用される。パケットがＭＡＣ層２０２によって送信（又は廃棄）された後、送信ステータスはアカウンティングのためにＴｘＡｃｃｅｌに戻る。ＸＢＢ５０２は、情報をＴｘＡｃｃｅｌユニット５００のクロック・ドメインに変換する。ステータス情報は、ＸＣＳ５０４によりパケットから得られたオリジナル情報と合併されてＭＩＢカウンタ論理５０６ａ及び５０６ｂに渡される。ＭＩＢ論理５０６ａ及び５０６ｂは、ＭＩＢアレイ内の適切なカウンタを更新する。ラップ・ユニット（ＷＲＰ）５０８は、ＸＣＳ５０４ａ及び５０４ｂがラッピングするように決定したパケットを受信側に転送する役割を担う。ポーズ・ユニット（ＰＡＵ）５１０は、受信バッファの占有率に基づいてポーズ・フレームを送信するようにＭＡＣに命令する。

ホスト・インターフェース層２０６
図１０は、ホスト・インターフェース層２０６をより詳しく示すＨＥＡ１１０のブロック図である。ホスト・インターフェース層２０６は、層２０４からパケットを受信するための入力バッファ６０２とパケットを層２０４に提供するための出力バッファ６０４とを含む。層２０６は、入力バッファ内のパケットを適切に処理するための受信パケット・プロセッサ（ＲＰＰ）６０６を含む。コンテクスト管理メカニズム９０８は、ＴＣＰスタックのための有効なバッファ管理を可能にするために、前のキューあたりに複数のサブ・キューを提供する。

多重分離機能
ホスト・インターフェース層２０６のコンポーネントと関連する層２０４のＲｘユニット４００は、パケットがプロセッサの適切な部分に提供されることを確実にするためにパケットを多重分離する。従って、受信されたパケットは、それらがサーバの適切な部分へ流れることを確実にするために、多重分離されなければならない。

この多重分離機能の詳細を説明するために、図８及び９と関連させて下記を参照されたい。

ＨＥＡアダプタにおける多重分離インプリメンテーション
受信パケット・プロセッサ（ＲＰＰ）６０６が受信されたパケットに対して作用し得るようになる前に、キュー・ペア・コンテクストが検索されなければならない。ＱＰ接続マネージャは、ＱＰ番号を用いてこれを実行する。ＱＰ番号はＴＣＰ／ＩＰパケットで運ばれないので、該番号は他の手段で判定されなければならない。２つの一般的種類のＱＰ、すなわちパー・コネクションＱＰ及びデフォルトＱＰ、がある。

パー・コネクション・キュー・ペア（ＱＰ）
パー・コネクションＱＰは、ＩＰパケットのフラグメンテーションが予期されなくて短待ち時間が予期される長命の接続のために使用されるように意図されている。それは、ＨＥＡ１１０により提供されるユーザ・スペーシング・キューイング・メカニズムをアプリケーションがサポートすることを必要とする。この実施態様では、宛先ＭＡＣアドレスを用いて初めに論理ポートが見出されなければならない。パー・コネクションＱＰのために３つのタイプのルックアップが存在する。

１． 特定の宛先ＩＰアドレス及び宛先ＴＣＰポートのための新しいＴＣＰ接続。もしパケットがＴＣＰ ＳＹＮパケットであったならば、ＴＣＰ／ＩＰ（ＤＡ，ＤＰ、論理ポート）に基づいてルックアップが実行される。

２． 特定の宛先ＴＣＰポートだけのための新しいＴＣＰ接続（ＤＡを無視する）。もしパケットがＴＣＰ ＳＹＮパケットであったならば、ＴＣＰ／ＩＰ（ＤＰ、論理ポート）に基づいてルックアップが実行される。

３． 現存するＴＣＰ／ＵＤＰ接続。もしパケットが断片化されていないユニキャストＴＣＰ又はＵＤＰパケットであったならば、ＴＣＰ／ＩＰ５タプル及び論理ポートに基づいてルックアップが実行される。

デフォルト・キュー・ペア
パケットについてパー・コネクションＱＰを見出し得ないか、又はＭＡＣアドレスについてパー・コネクション・ルックアップが可能にされないか、又はパケットが再循環させられたマルチキャスト／ブロードキャスト・パケットであれば、デフォルトＱＰが使用される。一般にデフォルトＱＰはカーネル・ネットワーキング・スタックによって処理される。これらのタイプのデフォルトＱＰがＨＥＡ１１０に存在する。

１． 論理ポートあたりのデフォルトＯＳキュー。論理ポートは、それ自身のデフォルト・キューを有する論理イーサネット・インターフェースに対応する。各論理ポートは論理スイッチ上に別のポートを有する。
ＭＡＣアドレスに基づいてルックアップが実行される。
デフォルトＯＳキューへのダイレクト索引（論理ポート番号）に、再循環させられた（ラッピングされた）マルチキャスト／ブロードキャスト・パケットが供給される。

２． マルチキャスト（ＭＣ）又はブロードキャスト（ＢＣ）キュー。
パケットがＭＡＣルックアップ・テーブル内のＭＡＣアドレスのうちの１つと一致しないマルチキャスト又はブロードキャスト・パケットである場合の、設定された値。

３． スーパー・デフォルト・ユニキャスト（ＵＣ）キュー。
ＵＣパケットが設定されたＭＡＣアドレスのうちの１つと一致しなければ、デフォルトＵＣ ＱＰＮが使用され得る。

このメカニズムは、接続ごとのキューイングと論理ポートごとのキューイング（ＯＳキュー）という両極端の間の柔軟性に配慮している。両方のモデルが、それ自身のキューイングを有する幾つかの接続、及びデフォルト論理ポート・キューで待ち合わせさせられる幾つかの接続と共に働くことができる。

接続ルックアップはＲｘＡｃｃｅｌユニット４００によって実行される。１つのその様なユニットが各ポート・グループのために存在する。ＲｘＡｃｃｅｌユニット４００内で、各コンポーネントはプロセスの一部分を実行する。ＰＦＣ４０４は、パケット・ヘッダから必要とされるフィールドを抽出し、宛先ＭＡＣアドレスに基づいて論理ポート番号を判定する。ローカル・ルックアップ・ユニット（ＬＬＵ）４０６とリモート・ルックアップ・ユニット（ＲＬＵ）４０８とは、ＱＰ番号を解明する責任を有する。ＬＬＵ４０６は、ローカル・リソースだけ（キャッシュ及びレジスタ）を用いてＱＰＮを見出そうと試みる。

ＬＬＵ４０６の目的は、受信されたパケットに関連付けられているＱＰ番号を判定しようと試みることである。ＱＰ番号は、ＶＬＩＭ及びＲＰＰ６０６により必要とされる。それは、可能ならばこのタスクをローカルに（すなわち、システム・メモリに行かずに）実行する。

ＱＰ番号は、数個の方法、すなわち
− ＴＳキャッシュにおけるルックアップ
− デフォルト・パーティションＱＰ
− デフォルトＵＣ ＱＰ
のうちの１つでローカルに見出され得る。

もし一致がローカルに見出されなければ、エントリがシステム・メモリ内に現在あるか否か調べるために予備チェックが行われる。もしあるならば、検索を実行するためにＲＬＵ４０８が呼び出される。もしＲＬＵ４０８が使用中ならば、リクエストのキューを形成することができ、それはＲＬＵ４０８に、それが自由になると、提供される。

ＬＬＵ４０６は、一時的キューイングに用いるＱＰ番号又はキュー・インデックス或いはその両方を提供するＲＢＢ４０２と通信する。もし適格なエントリがキャッシュにおいて利用できなければ、ＬＬＵ４０６はＲＢＢ４０２に検索がビジーであることを示す。この場合にはそのパケットは落とされなければならない。

キュー・インデックス解明が要求されて解明されたときにＬＬＵ４０６はＱＰＮをホスト層４０６に提供する。ＲＬＵ４０８は、システム・メモリ・テーブルを用いてＱＰＮを見出そうと試みる。

ＬＬＵ４０６は、ＴＣＰ／ＵＤＰパケットのためのＱＰＮを見出すためにローカル６４エントリ・キャッシュを利用する。もしそのエントリが該キャッシュにおいて見出されたならば、ＲＬＵ４０８は呼び出されなくてもよい。もしそのエントリが該キャッシュにおいて見出されなければ、そのエントリが接続テーブル内にあるか否か調べるために予備チェックが該キャッシュにおいて行われる。該キャッシュは、数個の設定されたキューがあるときにメイン・メモリへの不要なアクセスを無くするのに役立つ。

もしＲＬＵ４０８が呼び出されたならば、それは、メモリ？？？から１２８バイトのダイレクト・テーブル（ＤＴ）エントリを取り出すために６タプル（論理ポート番号を含む）のハッシュを使用する。このＤＴエントリは８個に及ぶ６タプル・パターンと関連するＱＰＮとを含む。もし一致が見出されれば、それ以上の動作は不要である。

ＲＬＵ４０８が呼び出されなければならないときには、パケットが入力バッファに入れられるときにＱＰＮを急いで判定することはできない。実際には、ＱＰＮは数パケット後に判定され得る。この理由から、ＲｘＡｃｃｅｌユニット４００は、パケット・キューイングのためにＱＰＮ又はキュー・インデックスをホスト層２０６に提供することができる。ＱＰＮが提供されるのであれば、ホスト層２０６（アンローダ）は、ＲＰＰにより処理されるようにパケットを直接キューに入れることができる。キュー・インデックスが提供されるのであれば、ホスト層２０６は、ＱＰＮの解明を待つためにこのパケットを保持しなければならない。ＱＰＮは、常に、ＲＰＰがディスパッチされる時までに判定される。

仮想化
高速データ経路は複数のパーティションにより共有されそうであり、また高速イーサネット処理能力がサーバにおいては重要なので、ＨＥＡが
− 複数のパーティションによるアダプタ・シェアリングを提供し、
− ネイティブの処理能力、すなわち、“専用アダプタの場合のように（ａｓ ｗｉｔｈ ａ ｄｅｄｉｃａｔｅｄ ａｄａｐｔｅｒ）”、を考慮に入れ、
− ネイティブの価値付加特徴、すなわち、“専用アダプタの場合のように”（ラージ・センド、パー・コネクション・キューイング、・・・）を考慮に入れ、
− パーティション間の分離を考慮に入れ、
− パーティション接続性を提供する
ことが非常に重要である。

パーティションは、トランスペアレントに、すなわちそれらが同じ物理的サーバに配置されているか、それとも本物のイーサネットによって接続された別々の物理的サーバに配置されているかにかかわらず同じように、通信することができなければならない。

今日、イーサネット仮想化は、アダプタを持っているサーバ・パーティションにおけるスイッチング又はルーティングによってサポートされ、この余分のホップは性能ボトルネック（データ・コピー、３ドライブ・ドライバ、・・・）を生じさせる。ＨＥＡ１１０は、使用パーティションとアダプタとの間の直接データ及び制御経路（余分のホップではない）を提供するように設計される。換言すれば、ＨＥＡは、各パーティションに、それ自身の“仮想”アダプタ及び“論理”ポートを供給する。ＨＣＡの場合のように、全てのＨＥＡリソース及び機能はパーティションごとに割り当て／イネーブルされ得、パーティション相互の保護及び分離を提供するために正確に同じメカニズムが使用される。

データ経路
データ経路に関して、図１１に示されているように、ＨＥＡ１１０は、マルチキャスト処理及びパーティション９１０ａ−９１０ｃ間通信を提供するために、物理的ポート９０２及び９０４ごとに論理層２スイッチ９０６及び９０８を提供する。ＨＥＡ内でのこのサポートの実現は、全体としてのシステムのソリューションを簡単に保ち（特に、ソフトウェアについての透明性）、高性能を提供する。パーティション間の通信のために全てのＨＥＡハードウェア高速化及び保護が利用可能である。

上記のフローをサポートするために、考えやすい方法は、所与の物理的ポートに関連付けられた全ての論理ポートとその物理的ポート自体とが取り付けられている論理層２スイッチ９０２及び９０４を想像することである。問題は、この論理スイッチをどのようにしてどこに実現するかであり、選択肢は、ファームウェア／ソフトウェアにおける完全なエミュレーションからＨＥＡハードウェアにおける完全なインプリメンテーションまでにわたる。物理的ポートごとに１つの論理層２スイッチがあり、これらの論理スイッチは互いに接続されない。

システム構成
レガシーＯＳ ＴＣＰ／ＩＰスタックを伴う仮想化されたＨＥＡ
図１２は、レガシーＯＳ ＴＣＰ／ＩＰスタック１１０２，１１０４及び１１０６と共に使用されるＨＥＡを示す。
− アプリケーション１１０８ａ−１１０８ｃは変化していない
− ＴＣＰ／ＩＰスタック１１０２，１１０４及び１１０６は変化していない
− ＨＥＡ１１０をサポートするデバイス・ドライバ１１０７ａ，１１０７ｂ及び１１０７ｃが必要とされる。

ＴＣＰ／ＩＰスタック（ＯＳ）は、ＴＣＰ接続ごとの短パケット（単数又は複数）多重分離のための短待ち時間キューのような特徴を利用するためにオプションで拡張され得る。見たとおり、パケットの多重分離はＭＡＣアドレスとパーティションごとのＱＰＮとに基づいて実行される。

レガシーＯＳスタック及びユーザ・スペースＴＣＰ／ＩＰを伴う仮想化されたＨＥＡ
図１３は、幾つかのパーティションがユーザ・スペースＴＣＰスタック１２２０及びレガシーＯＳスタック１０８ａ及び１２０８ｂをサポートするシステムにおいて使用されたＨＥＡ１１０を示す。
− ユーザ・スペースＴＣＰをサポートするアプリケーションはソケット拡張ＡＰＩを使用するように要求され得る
− 他のパーティションは通常のＯＳ ＴＣＰ／ＩＰスタックを使用することができる
− ユーザ・スペースＴＣＰ（Ｕｓｅｒ Ｓｐａｃｅ ＴＣＰ）をサポートするパーティション内の或るアプリケーションも通常のＴＣＰ／ＩＰスタックを使用することができる（デフォルト経路）。ユーザ・スペースＴＣＰ１２２０は、カスタマー識別（Ｃｉｄ）情報とカスタマーのためのＱＰＮとに基づいてＨＥＡにより多重分離される。

論理スイッチは、アダプタにおいて完全にサポートされる。ＨＥＡハードウェアの複雑さを最小にするために、ＨＥＡは、マルチキャスト／ブロードキャスト・パケット複製のためにソフトウェア・エンティティー、すなわちマルチキャスト・マネージャ、に依拠する。ＨＥＡは、パケット・コピーを宛先パーティションに渡すためにマルチキャスト・マネージャにアシストを提供する。

外部ユニキャスト・トラフィック
送信ユニキャスト・トラフィックは、パーティションに割り当てられたＱＰを通して処理される。それは接続ごとの専用キュー・ペア又は論理ポートごとの単一キュー・ペア或いはその両方であり得る。送信キューの間での公平なスケジューリングがＨＥＡにより提供される。システム構成に依存して、ＱＰアクセスはアプリケーション（ユーザ・スペース）に又はＯＳスタック（特権）にだけ与えられ得る。

受信されたユニキャスト・トラフィックは次のように多重分離される。
− 宛先論理ポートを見出すために宛先ＭＡＣアドレスでルックアップが行われる
− もし宛先論理ポートのためにパー・コネクション・キューイングが可能にされるならば、その接続に関連するＱＰを見出すために接続ＩＤで第２ルックアップが行われる
− もしパー・コネクション・キューイングが可能にされないか、又は接続ＱＰが特定の接続のためにセットアップされていなければ、入ってくるメッセージは、宛先論理ポートに関連する“デフォルト”ＱＰにキューイングされる。

パーティション間ユニキャスト・トラフィック
図１４は、サポートされるパー・コネクション・キューイングを含む全てのＨＥＡ高速化特徴を示すブロック図である。完全な透明性がパーティションのデバイス・ドライバに提供される。

パーティション・スタックは、パケットを送信するためにパー・コネクションＱＰ又はデフォルトＱＰを使用する。パケットがＨＥＡ送信側によって処理されるとき、ＨＥＡは、宛先ＭＡＣアドレスが同じ物理的ポート上に定義された論理ポートに関連するＭＡＣアドレスであることを検出する（換言すれば、宛先ＭＡＣアドレスは、送信論理リンクとは同じ層２論理スイッチに属する受信論理リンクを識別する）。従って、ＨＥＡはパケットをラップする。ＨＥＡ受信側は、パケットを、あたかもそれが物理的リンクから受信されたかのように処理し、従ってまさに同じ高速化特徴が使用される。

ＩＰの場合には、ＩＰスタックは、同じＩＰサブネット上に位置する宛先パーティションの宛先ＭＡＣアドレスを発見するために通常のメカニズムを使用することができる。このパーティションは同じサーバ上に配置されてもされなくても良く、これはスタック及びデバイス・ドライバの両方のためにトランスペアレントである。

外部及びパーティション間マルチキャスト／ブロードキャスト・トラフィック
ＨＥＡは、関係のあるパーティションにマルチキャスト・パケット及びブロードキャスト・パケットを複製するための備えを持っていない。代わりに、それは、受信した全てのＭＣ／ＢＣパケットを、マルチキャスト・マネージャ機能により所有されるＱＰに転送する。この機能は、必要に応じてパケットを複製し、ＨＥＡトランスポート能力を使用してコピーを関係のあるパーティションに配布する。

受信
図１５は、インバウンド・マルチキャスト送信を示す。受信されたマルチキャスト・パケット及びブロードキャスト・パケットは初めにＨＥＡフィルタリング機能を通る。もし廃棄されなければ、パケットは、マルチキャスト・マネージャ１５００により所有されるＱＰに向けられる。パケットはシステム・メモリに転送され、マルチキャスト・マネージャ１５００は起動される。マルチキャスト・マネージャ１５００は、どの論理ポートがパケットのコピーを受信するべきかを決定し（マルチキャスト・フィルタリング）、パケット複製を処理する。マルチキャスト・マネージャは、パケットを受信側パーティション１５０２ａ−１５０２ｃに再分配するためにＨＥＡ１１０機能を使用することができる。

そうするためにマルチキャスト・マネージャは、受信されたパケットを参照するｎ個の受け側−ディスクリプタ（ＷＱＥ）をその送信キューにエンキューする。パケットはその受け側にそっくりそのまま送られなければならず、特にマルチキャスト宛先ＭＡＣアドレスの代わりにその種々の受け側のユニキャスト・アドレスを用いることは容認できないということに注意しなければならない。従って、パケット・ディスクリプタは、ＨＥＡがパケットをその適切な宛先に向けることができるように情報を含んでいなければならない。この情報は、受け側のデフォルトＱＰ又はその論理ポートＩＤ又はそのＭＡＣアドレスであり得る。パケットが送信されるべく選択されると、ＨＥＡ送信側は、ＱＰ及びＷＱＥの両方に含まれている情報のおかげで、パケットがラップを介して送られる必要があると判定する。データと共に、受け側ＱＰを判定する情報がＨＥＡ受信側に転送される。ＨＥＡ受信側は、パケットを受け側ＱＰにエンキューするためにこの情報を使用する。

送信
図１６は、アウトバウンド・マルチキャスト送信を示す。ブロードキャスト／マルチキャスト・パケットは、発信パーティションにより通常の手続きを用いて送信される。パケットがＨＥＡ送信側によって処理されるとき、ＨＥＡは、宛先ＭＡＣアドレスがブロードキャスト又はマルチキャストされることを検出し、またＷＱＥにおいて“フォースアウト（Ｆｏｒｃｅ＿Ｏｕｔ）”オプションがセットされていないことを検出する。従って、ＨＥＡはパケットをラップする。ＨＥＡ受信側は、パケットを上記のように処理する。マルチキャスト・マネージャは、下記の追加事項を伴って上記のようにパケットを処理する。
− それは、センダが受け側のリストから除去されることを確実にしなければならず、それはパケットのソースＭＡＣアドレスをフィルタとして用いて行う。
− パケット複製プロセス中にＶＬＡＮフィルタリングが実行され得る。パケットはＶＬＡＮの構成要素に送られるだけである。
− 内部複製が行われると、パケットは物理的ポートから送出されなければならない。それは、そのＱＰのフォースアウト機能をイネーブルしてＷＱＥの“フォースアウト”ビットをセットすることによって、その様に行う。このビットがセットされるたとき、ＨＥＡは直ぐにパケットを物理的リンク上に送り出す。

マルチパーティション環境におけるマルチキャスト・フィルタリング
受信側において、ＨＥＡはマルチキャスト・フィルタリングを提供する。ＨＥＡは、他の“直ぐに入手可能な（ｏｆｆ ｔｈｅ ｓｈｅｌｆ）”アダプタと同様に、宛先ＭＡＣアドレスのハッシュ値と物理的ポートあたりに１つのフィルタリング・テーブルへのルックアップとに基づいてベスト・エフォート・フィルタリングを提供する。この機能の意図は、マルチキャスト・トラフィックを制限することであるが、“最終の”フィルタリングはスタックに任される。マルチ・パーティションの場合、関与する全てのパーティションからのフィルタリング要求はマルチキャスト・マネージャにより併合され、その後にＨＥＡで設定されるべきである。

マルチキャスト・マネージャは、関係するパーティションへのパケット配布を処理するときにパーティションごとのマルチキャスト・フィルタリングを行うことができる。

パケット・ヘッダ分離
ＨＥＡ１１０は、データ・ペイロードからＴＣＰ／ＩＰヘッダを分離することができる。この特徴は、ゼロ・コピー操作を可能にし、従って待ち時間を改善する。

パケット・ヘッダ分離は、ＱＰコンテクストで設定されたときＨＥＡ１１０により実行される。設定されたとき、イーサネット／ＩＰ／ＴＣＰ又はイーサネット／ＩＰ／ＵＤＰヘッダは、パケットのボディから分離されて異なるメモリに置かれる。通常、ＴＣＰ／ＩＰスタックはヘッダを処理し、アプリケーションはボディを処理する。ハードウェアでの分離は、ユーザ・データをユーザ・バッファに整列させ、従ってコピーを回避することを可能にする。

層２０４内のＰＦＣ４０４（図８）は、ヘッダ全長（８ビット）をホスト・インターフェース２０６のＲＰＰ６０６（図１０）に渡して、イーサネット、ＩＰ及びＴＣＰ／ＵＤＰヘッダのバイト数を示す。ヘッダ分割が行われないときにはヘッダ長さは０にセットされる。

ＱＰは２つ以上の受信キュー（ＲＱ）のために設定されなければならない。

パケットがＴＣＰ又はＵＤＰ（ヘッダ長さがゼロでない）ならば、ＲＰＰ６０６はヘッダをＲＱ１ ＷＱＥの中に置く。ＲＰＰ６０６は、その後、パケットのデータ部分のために適切なＲＱを選択する（ＲＱ２又はＲＱ３）を選択する。ＲＱ２又はＲＱ３ ＷＱＥのディスクリプタは、残りのデータを配置するために使用される。ＲＰＰ６０６は、完全な情報でＣＱＥが生成されるべきことを示す。ヘッダ分割フラグがセットされる。ＣＱＥのコリレータ（ｃｏｒｒｅｌａｔｏｒ）フィールドのコリレータが、使用されたＲＱ２又はＲＱ３ ＷＱＥからコピーされる。第１ＷＱＥに置かれたヘッダ・バイトの総数もＣＱＥに置かれる。

もしヘッダがＲＱ１ ＷＱＥ内の使用可能なスペースより大きければ、ＷＱＥはなるべく多くのデータで満たされ、ＣＱＥにおいてヘッダ長すぎフラグ（Ｈｅａｄｅｒ Ｔｏｏ Ｌｏｎｇ ｆｌａｇ）がセットされる。ヘッダの残りの部分はデータと共にＲＱ２／ＲＱ３ ＷＱＥに置かれる。

ヘッダ分割モードがＡＬＬにセットされてヘッダ分割が実行される（ヘッダ長さがゼロでない）時には、パケットのボディはＲＱ１ ＷＱＥには決して置かれない。ＱＰは、オプションで、短いパケットを完全にＲＱ１ ＷＱＥの中に置くように設定され得る（ヘッダ分割モード＝ＭＬ）。もしその様に設定されれば、パケット長さがＲＱ２スレショルドより小さければ、ＲＱ１ ＷＱＥだけが使用され、ヘッダ分離は行われない。ボディがＲＱ１及びＲＱ２／ＲＱ３に決して分割されないことに注意しなければならない。

もしパケットがＩＰフラグメントであるか又はＴＣＰでもＵＤＰでもなく（ヘッダ長さがゼロ）、またパケットが大きすぎてＲＱ１ ＷＱＥに入らなければ、パケット全体がＲＱ２又はＲＱ３ ＷＱＥを用いて配置される。ヘッダ総数はゼロにセットされる。ヘッダ分割フラグはオフである。（競争情報がＲＱ１ ＷＱＥに置かれないのであれば）ＲＱ１ ＷＱＥは消費されない。

従ってＨＥＡ１１０はＴＣＰ／ＩＰヘッダをデータ・ペイロードから分離することができる。この特徴は、アプリケーションにより掲示された受信バッファを汚さずに処理されるようにヘッダをプロトコル・スタックに向けることを可能にし、従って或るトランザクションのために待ち期間を短縮する。

概要
従って、本発明のホスト・イーサネット・アダプタ（ＨＥＡ）は、プロセッサのプライベート・バスに直接接続され、従って２つの１０Ｇｂｐｓポートの全４０Ｇｂｐｓ帯域幅をサポートする充分な帯域幅（例えば８６６Ｍｈｚで５５．４２Ｇｂｐｓ）を有することによって無比の性能レベルを達成する。プロセッサのプライベート・バス上に該アダプタを有することで中間の論理を除去し、従って転送待ち時間を改善する。ＨＥＡ１１０を利用して、在来のＮＩＣの場合より高速で、短待ち時間で簡単な論理を考慮したネットワーク・インターフェース・コントローラ（ＮＩＣ）を提供することができる。

本発明は、示された実施態様に従って記述されたけれども、当業者は、それらの実施態様に変化形があり得ること、それらの変化形が本発明の範囲内にあることを直ぐに認めるであろう。従って、添付されている請求項の範囲から逸脱せずに当業者により多くの改変がなされ得る。

在来のサーバ・システムを示す。 本発明によるサーバ・システムのブロック図である。 本発明によるＨＥＡの簡単なブロック図である。 ＭＡＣ及びＳｅｒｄｅｓ層をより詳しく示す、ＨＥＡのブロック図である。 ＲｘＮｅｔのうちの１つのためのコンポーネント及びデータフローを示す。 １つのＴｘＥｎｅｔのためのコンポーネント及びデータフローを示す。 パケット高速化及び可視化層をより詳しく示すＨＥＡのブロック図である。 ＲｘＡｃｃｅｌユニットのより詳しい図である。 ＲｘＡｃｃｅｌユニットが２つの送信バックボーン（ＸＢＢ）と、２つの送信チェックサム・ユニットと、２つの送信ＭＩＢと、１つのラップ／ユニットと１つのポーズ・ユニットとから構成されることを示す。 ホスト・インターフェース層をより詳しく示すＨＥＡ１１０のブロック図である。 １つの物理的ポートにつき１つの論理層２スイッチを提供するＨＥＡを示す。 レガシーＯＳ ＴＣＰ／ＩＰスタックと共に使用されるＨＥＡを示す。 幾つかのパーティションがユーザ・スペースＴＣＰスタックをサポートしているシステムに使用されたＨＥＡを示す。 パー・コネクション・キューイングを含む全てのＨＥＡサポート高速化特徴を示す。 インバウンド・マルチキャスト送信を示す。 アウトバウンド・マルチキャスト送信を示す。

Claims (19)

1. イーサネット・アダプタであって、
   少なくとも１つのプロセッサからパケットを受信し、且つ少なくとも１つのプロセッサへパケットを送信することを可能にする複数の層を含んでおり、
   前記複数の層は、前記少なくとも１つのプロセッサのパーティション化を考慮に入れた多重分離メカニズムを含み、
   １つの論理スイッチが前記イーサネット・アダプタの各物理ポートのために利用され、各論理ポートが論理スイッチ上に個々のポートを有しており、１つの論理スイッチが複数の論理ポートを提供し、前記複数の論理ポートの各々は前記プロセッサのパーティションをサポートし、そして、前記パーティション間の通信が可能にされる、前記イーサネット・アダプタ。
2. 前記複数の層は、
   媒体アクセス・コントローラ（ＭＡＣ）及び並直列変換回路（Ｓｅｒｄｅｓ）層（以下、第１層）であって、ネットワーク上の他の装置からの及びネットワーク上の他の装置への複数のインターフェースを提供し、及び、当該提供のために同じチップのＩ／Ｏが使用される、前記第１層と、
   パケット高速化及び仮想化層（以下、第２層）であって、前記第１層からパケットを受信し、且つ前記第１層にパケットを提供する、前記第２層と、
   ホスト・インターフェース層（以下、第３層）であって、前記第２層と通信し、且つ前記プロセッサのプライベート・バスとインターフェースする、前記第３層と
   を含む、請求項１に記載のイーサネット・アダプタ。
3. 前記第２層が、適切なときにはパケット・ヘッダをデータ・ペイロードから分離することによってパケット・ヘッダ分離を提供し、且つ、受信バッファを汚さずに処理されるように当該パケット・ヘッダをプロトコル・スタックに向け、それによって或るトランザクションのために待ち期間を短縮する、請求項２に記載のイーサネット・アダプタ。
4. 前記第３層がコンテクスト管理を提供する、請求項２に記載のイーサネット・アダプタ。
5. 前記第１層は、パケットを受信するための受信イーサネット機能と、パケットを送信するための送信イーサネット機能とを含む、請求項２に記載のイーサネット・アダプタ。
6. 前記複数の層は、
   媒体アクセス・コントローラ及び並直列変換回路（ＭＡＣ及びＳｅｒｄｅｓ）層と、
   前記ＭＡＣ及びＳｅｒｄｅｓ層からパケットを受信し、且つ前記ＭＡＣ及びＳｅｒｄｅｓ層にパケットを提供するパケット高速化及び仮想化層と、
   前記パケット高速化及び仮想化層と通信し、前記プロセッサのプライベート・バスとインターフェースするホスト・インターフェース層と
   を含む、請求項１に記載のイーサネット・アダプタ。
7. 前記ＭＡＣ及びＳｅｒｄｅｓ層は、パケットを受信するための受信イーサネット機能と、パケットを送信するための送信イーサネット機能とを含む、請求項６に記載のイーサネット・アダプタ。
8. 前記多重分離メカニズムは、前記プロセッサ内で利用される複数のオペレーティング・システムへの直接経路を考慮に入れている、前記プロセッサ内で利用される複数のアプリケーションへの直接経路を考慮に入れている、又は前記プロセッサ内で利用される複数のオペレーティング・システムへの直接経路と前記プロセッサ内で利用される複数のアプリケーションへの直接経路とを考慮に入れている、請求項１〜７のいずれか一項に記載のイーサネット・アダプタ。
9. 或るトランザクションのための待ち期間を短縮するために、適切なときにはパケット・ヘッダがデータ・ペイロードから分離される、請求項６又は７に記載のイーサネット・アダプタ。
10. ネットワーク・インターフェース・コントローラ（ＮＩＣ）であって、
    プロセッサのプライベート・バスに接続されるように成されているインターフェースと、
    イーサネット・アダプタと
    を含んでおり、
    前記イーサネット・アダプタは、少なくとも１つのプロセッサからパケットを受信し、且つ少なくとも１つのプロセッサへパケットを送信することを可能にする複数の層を含んでおり、
    前記複数の層は、前記少なくとも１つのプロセッサのパーティション化を考慮に入れた多重分離メカニズムを含み、
    １つの論理スイッチが前記イーサネット・アダプタの各物理ポートのために利用され、各論理ポートが論理スイッチ上に個々のポートを有しており、１つの論理スイッチが複数の論理ポートを提供し、前記複数の論理ポートの各々は前記プロセッサのパーティションをサポートし、そして、前記パーティション間の通信が可能にされる、前記ＮＩＣ。
11. 前記複数の層は、
    媒体アクセス・コントローラ（ＭＡＣ）及び並直列変換回路（Ｓｅｒｄｅｓ）層（以下、第１層）であって、ネットワーク上の他の装置からの及びネットワーク上の他の装置への複数のインターフェースを提供し、及び、当該提供のために同じチップのＩ／Ｏが使用される、前記第１層と、
    パケット高速化及び仮想化層（以下、第２層）であって、前記第１層からパケットを受信し、且つ前記第１層にパケットを提供する、前記第２層と、
    ホスト・インターフェース層（以下、第３層）であって、前記第２層と通信し、且つ前記プロセッサのプライベート・バスとインターフェースする、前記第３層と
    を含む、請求項１０に記載のＮＩＣ。
12. 前記第２層が、適切なときにはパケット・ヘッダをデータ・ペイロードから分離することによってパケット・ヘッダ分離を提供し、且つ、受信バッファを汚さずに処理されるように当該パケット・ヘッダをプロトコル・スタックに向け、それによって或るトランザクションのために待ち期間を短縮する、請求項１０に記載のＮＩＣ。
13. 前記第３層がコンテクスト管理を提供する、請求項１０に記載のＮＩＣ。
14. 前記第１層は、パケットを受信するための受信イーサネット機能と、パケットを送信するための送信イーサネット機能とを含む、請求項１０に記載のＮＩＣ。
15. 前記複数の層は、
    媒体アクセス・コントローラ及び並直列変換回路（ＭＡＣ及びＳｅｒｄｅｓ）層と、
    前記ＭＡＣ及びＳｅｒｄｅｓ層からパケットを受信し、且つ前記ＭＡＣ及びＳｅｒｄｅｓ層にパケットを提供するパケット高速化及び仮想化層と、
    前記パケット高速化及び仮想化層と通信し、前記プロセッサのプライベート・バスとインターフェースするホスト・インターフェース層と
    を含む、請求項１０に記載のＮＩＣ。
16. 前記ＭＡＣ及びＳｅｒｄｅｓ層は、パケットを受信するための受信イーサネット機能と、パケットを送信するための送信イーサネット機能とを含む、請求項１５に記載のＮＩＣ。
17. 前記多重分離メカニズムは、前記プロセッサ内で同時に利用される複数のオペレーティング・システムへの直接経路を考慮に入れている、前記プロセッサ内で利用される複数のアプリケーションへの直接経路を考慮に入れている、前記プロセッサ内で利用される複数のオペレーティング・システムへの直接経路と前記プロセッサ内で利用される複数のアプリケーションへの直接経路とを考慮に入れている、請求項１０〜１６のいずれか一項に記載のＮＩＣ。
18. 或るトランザクションのための待ち期間を短縮するために、適切なときにはパケット・ヘッダがデータ・ペイロードから分離される、請求項１５又は１６に記載のＮＩＣ。
19. 請求項１０乃至１８のいずれか１項に記載のＮＩＣを含むサーバ・システム。

Images