特許 6377844 ＳＦＥＮＣＥを用いずに最適化されたＰＩＯ書込みシーケンスを用いるパケット送信

(19)【発行国】日本国特許庁(JP)

(12)【公報種別】特許公報(B2)

(11)【特許番号】6377844

(24)【登録日】2018年8月3日

(45)【発行日】2018年8月22日

(54)【発明の名称】ＳＦＥＮＣＥを用いずに最適化されたＰＩＯ書込みシーケンスを用いるパケット送信

(51)【国際特許分類】

   G06F 13/38 20060101AFI20180813BHJP

   G06F 13/12 20060101ALI20180813BHJP

【ＦＩ】

   G06F13/38 330Z

   G06F13/12 330D

   G06F13/38 310A

【請求項の数】25

【全頁数】49

(21)【出願番号】特願2017-516268(P2017-516268)

(86)(22)【出願日】2015年6月5日

(65)【公表番号】特表2017-525065(P2017-525065A)

(43)【公表日】2017年8月31日

(86)【国際出願番号】US2015034359

(87)【国際公開番号】WO2015199946

(87)【国際公開日】20151230

【審査請求日】2016年12月6日

(31)【優先権主張番号】14/316,670

(32)【優先日】2014年6月26日

(33)【優先権主張国】US

(73)【特許権者】

【識別番号】593096712

【氏名又は名称】インテル コーポレイション

(74)【代理人】

【識別番号】100107766

【弁理士】

【氏名又は名称】伊東 忠重

(74)【代理人】

【識別番号】100070150

【弁理士】

【氏名又は名称】伊東 忠彦

(74)【代理人】

【識別番号】100091214

【弁理士】

【氏名又は名称】大貫 進介

(72)【発明者】

【氏名】デバッジ，マーク

(72)【発明者】

【氏名】ムータ，ヤティン エム．

【審査官】 田上 隆一

(56)【参考文献】

【文献】 米国特許出願公開第２０１１／０１４５４５０（ＵＳ，Ａ１）

【文献】 特開２００７−２８７１４２（ＪＰ，Ａ）

【文献】 米国特許第０８１２２１７７（ＵＳ，Ｂ１）

(58)【調査した分野】（Int.Cl.，ＤＢ名）

Ｇ０６Ｆ １３／３８

Ｇ０６Ｆ １３／１２

(57)【特許請求の範囲】

【請求項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】

前記装置は、請求項２４に記載のホストファブリックインタフェースのために定義された構成を有する複数のホストファブリックインタフェースを備える、請求項２４に記載の装置。

【発明の詳細な説明】

【背景技術】

【0001】

高性能計算（ＨＰＣ：Ｈｉｇｈ−Ｐｅｒｆｏｒｍａｎｃｅ Ｃｏｍｐｕｔｉｎｇ）の利用および興味は近年著しく増加してきた。歴史的に見て、ＨＰＣは一般的に、いわゆる「スーパーコンピュータ」と関連付けられていた。スーパーコンピュータは、主にＣｏｎｔｒｏｌ Ｄａｔａ Ｃｏｒｐｏｒａｔｉｏｎ（ＣＤＣ）、Ｃｒａｙ Ｒｅｓｅａｒｃｈ、および「Ｃｒａｙ」の名前またはモノグラムを有する後続企業のＳｅｙｍｏｕｒ Ｃｒａｙによって、１９６０年代に導入され、最初およびその後の数十年にわたって作られていた。１９７０年代のスーパーコンピュータは数個のプロセッサしか使用しなかったが、１９９０年代には何千個ものプロセッサを有するマシンが出現し始め、より最近には数十万個の「既製品」プロセッサを有する超並列スーパーコンピュータが実現されている。

【0002】

様々なレベルの規模および性能とともに、実現および研究志向の両方の、多くのタイプのＨＰＣアーキテクチャが存在する。しかしながら、共通のテーマは、協働的に並列でタスクを実行するためプロセッサおよび／またはプロセッサコアなどの多数の計算ユニットの相互接続である。最近のシステムオンチップ（ＳｏＣ）設計および提案の下で、二次元（２Ｄ）アレイ、トーラス、リング、またはその他の構成を用いて、単一のＳｏＣ上に多数のプロセッサコアなどが実現されている。加えて、研究者らは、数百個または数千個のプロセッサコアが３Ｄアレイで相互接続される３ＤＳｏＣを提案してきた。個別のマルチコアプロセッサおよびＳｏＣもまたサーバボード上で近接していてもよく、これは同様に、バックプレーンなどを介して通信的に相互接続されている。別の一般的なアプローチは、サーバのラック（たとえば、ブレードサーバおよびモジュール）内で計算ユニットを相互接続させることである。かつて世界最速のスーパーコンピュータと言われたＩＢＭのセコイア（Ｓｅｑｕｏｉａ）は、サーバブレード／モジュールのラックを９６個、合計１，５７２，８６４個のコアを備え、最大能力で動作しているときは７．９メガワットものとてつもない電力を消費した。

【0003】

ＨＰＣの性能的ボトルネックの１つは、計算ノード間の相互接続上のデータ伝送に起因する遅延である。通常、相互接続は、ヒエラルキーレベルが下がるにつれて遅延が増加する一方で、ヒエラルキーの頂上でプロセッサ／ＳｏＣの中の最高速度および最短相互接続を有する、相互接続ヒエラルキーにおいて構築される。たとえば、プロセッサ／ＳｏＣレベルの後に、相互接続ヒエラルキーはプロセッサ間相互接続レベル、ボード間相互接続レベル、および個々のサーバまたは個々のサーバの集合を別のラック内のサーバ／集合に接続する１つ以上の追加レベルを、含んでもよい。

【0004】

近年、バックプレーンまたは銅ケーブル上での１００Ｇｂ／ｓのための物理層（ＰＨＹ）仕様および管理パラメータを定義する、ＩＥＥＥ８０２．３ｂｊドラフト規格で規定されるような、１００ギガビット毎秒（１００Ｇｂ／ｓ）の速度を有する相互接続リンクが導入されている。（１００Ｇｂ／ｓと）類似の速度を有するリンクを含むメッシュ状相互接続構造が、ＨＰＣ環境向けに開発および設計されている。このような高速リンクおよび相互接続の利用可能性は性能限界を、ファブリックから、相互接続との間で転送されるパケットのソフトウェア生成およびパケットデータの取り扱いに、移行させる。

【0005】

上記の態様および本発明に付随する利点の多くは、別途指定されない限り様々な図面にわたって類似参照番号が類似部品を示す添付図面と併せると、以下の詳細な説明を参照することによってより良く理解されるので、より容易に理解されるだろう。

【図面の簡単な説明】

【0006】

【図1】一実施形態による、ホストファブリックインタフェース（ＨＦＩ）を含むシステムの概略図である。

【図2】一実施形態による、ＰＩＯ送信メモリおよびＳＤＭＡメモリの様々な態様を示す概略図である。

【図3】ＰＩＯ送信物理アドレス空間の一例を示すブロック図である。

【図4】仮想アドレス空間、装置物理アドレス空間、およびＰＩＯ送信メモリアドレス空間の間の例示的アドレスマッピングを示すブロック図である。

【図5】一実施形態による、送信バッファのレイアウトを示すブロック図である。

【図6a】図１のシステムの選択的要素のさらなる詳細を示す概略図である。

【図6b】ストアバッファに書き込まれ、ＰＩＯ送信メモリ内の送信バッファに転送される、パケットデータの２つのブロックを示す概略図である。

【図7a】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図7b】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図7c】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図7d】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図7e】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図7f】パケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図8a】５１２ビット書込み命令を用いてパケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図8b】５１２ビット書込み命令を用いてパケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図8c】５１２ビット書込み命令を用いてパケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図8d】５１２ビット書込み命令を用いてパケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図8e】５１２ビット書込み命令を用いてパケット放出を通じてメモリからＰＩＯ送信メモリへのパケットデータの例示的転送に対応する送信時間枠を示す、概略図である。

【図9a】ｓｆｅｎｃｅありでのＰＩＯ送信書込みでのデータ転送遅延の比較を示す時間フロー図である。

【図9b】ｓｆｅｎｃｅなしでのＰＩＯ送信書込みでのデータ転送遅延の比較を示す時間フロー図である。

【図10】一実施形態による、放出ブロックの概略図である。

【図11】ＨＦＩに結合されたファブリックリンク上のアウトバウンド放出のためのパケットデータの準備において実現される動作、段階、および状態を示すフローチャートである。

【図12】一実施形態による、ＰＩＯ送信アドレスＦＩＦＯおよびクレジット返信ＦＩＦＯを示す図である。

【図13】一実施形態による、ＨＦＩを含むシステムノードの概略図である。

【図14】２つのＨＦＩを含むＡＳＩＣの概略図である。

【発明を実施するための形態】

【0007】

ｓｆｅｎｃｅを用いずに最適化されたＰＩＯ書込み（ｗｒｉｔｅ、ライト）シーケンスを用いてパケットを送信する方法および装置の実施形態が、本明細書に記載される。以下の説明において、本発明の実施形態の徹底的な理解を提供するために、多くの具体的詳細が明記される。しかしながら当業者は、具体的詳細の１つ以上を伴わずに、またはその他の方法、構成要素、材料などを用いても、本発明が実践可能であることを、認識するだろう。別の例では、本発明の態様が曖昧にならないように、周知の構造、材料、または動作は詳細に図示または記載されない。

【0008】

明確さのため、本明細書図中の個々の構成要素は、特定の参照番号ではなくむしろ図中のラベルで呼ばれることもある。加えて、（特定の構成要素に対抗して）特定のタイプの構成要素を指す参照番号は、「典型的」を意味する「（ｔｙｐ）」が付いた参照番号で示されてもよい。これらの構成要素の構成は、図面に示されるが簡潔さおよび明確さのためラベル付けされていない類似構成要素の典型となることは、理解されるだろう。反対に、「（ｔｙｐ）」は、構成要素、要素などが一般的にその開示される機能、実現、目的などのために使用されると意味するよう解釈されるべきではない。

【0009】

図１は、システムメモリとファブリックインタフェースとの間のパケットデータスループットの向上を容易にするパケットデータ取り扱い技術の態様を説明するために本明細書で使用される、例示的なシステム１００を示す。システム１００は、メモリ相互接続１０７を介してメモリ１０６（一般的にシステムメモリとも称される）に同様に結合された、Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｎｅｔ Ｅｘｐｒｅｓｓ（ＰＣＩｅ；ピーシーアイエクスプレス）相互接続１０５を介してホストプロセッサ１０４に結合された、ホストファブリックインタフェース（ＨＦＩ）１０２を含む。ＨＦＩ１０２は、ファブリックポート１１２の伝送ポート１１０に結合された伝送エンジン１０８と、ファブリックポート１１２の受信ポート１１６に結合された受信エンジン１１４と、を含む。伝送エンジン１０８および受信エンジン１１４の各々はまた、ＰＣＩｅ相互接続（ｉｎｔｅｒｃｏｎｎｅｃｔ）１０５を介したＨＦＩ１０２とプロセッサ１０４との間の通信を容易にするＰＣＩｅインタフェース（Ｉ／Ｆ）１１８にも結合されている。

【0010】

伝送（ｔｒａｎｓｍｉｔ）エンジン１０８は、送信（ｓｅｎｄ）メモリ１２０、複数の送信（ｓｅｎｄ）ＤＭＡ（ＳＤＭＡ）エンジン１２３を含む送信ダイレクトメモリアクセス（送信ＤＭＡ）ブロック１２２、バッファ１２４、放出（ｅｇｒｅｓｓ）ブロック１２６、およびクレジット返信機構（ｃｒｅｄｉｔ ｒｅｔｕｒｎ ｍｅｃｈａｎｉｓｍ）１２７を含む。受信（ｒｅｃｅｉｖｅ）エンジン１１４は、Ｒｘ受信（ｒｅｃｅｉｖｅ）ブロック１２８、受信（ｒｅｃｅｉｖｅ）バッファ１３０、ＤＭＡエンジン１３２、中央制御エンジン（ＣＣＥ）１３４、パーサ１３６、１セットのパイプラインブロック１３８、および受信レジスタアレイ（Ｒｃｖ Ａｒｒａｙ）１４０を含む。「送信（ｓｅｎｄ）」エンジンとも称される伝送エンジン１０８は、ファブリックリンク（たとえば、図示されないが伝送ポート１１０に結合されたファブリックリンク）への放出用のパケットを生成する。送信エンジンによって提供される２つの異なる機構は、ＰＩＯ送信および送信ＤＭＡである。

【0011】

ＰＩＯ送信は、「プログラム入力／出力（Ｐｒｏｇｒａｍｍｅｄ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）」送信の略である。ＰＩＯは一部の人々に、「メモリマップ入力／出力（ＭＭＩＯ；Ｍｅｍｏｒｙ−ｍａｐｐｅｄ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）としても知られている。ＰＩＯ送信のため、ホストプロセッサ１０４は、格納命令を用いてメモリマップ送信バッファにパケットのヘッダおよびペイロードを書き込むことによって、パケットを生成する。ＰＩＯ送信は、プロセッサがパケットをＨＦＩ１０２に向かって押すという意味において、パケット「プッシュ」と見なされることも可能である。送信メモリ１２０内で実現される送信バッファは、送信バッファへのプロセッサ書込みが、ＰＣＩｅ相互接続１０５およびＰＣＩｅインタフェース１１８上で送信メモリ１２０に転送されるＰＣＩｅ書込みトランザクションになるように、アダプタの物理アドレス空間の中にある。

【0012】

送信メモリ１２０内の多数の送信バッファプラス送信バッファクレジットをホストプロセッサ１０４に返信するために使用される機構は、「送信コンテキスト」と呼ばれる。一実施形態において、最大１６０個の独立した送信コンテキストがＨＦＩ１０２によって提供され、ＰＩＯ送信機構の最大１６０の並行して独立したユーザを許容する。ＰＩＯ送信は、送信コンテキストをユーザプロセスの仮想アドレスマップに直接マッピングすることによって、ユーザモードソフトウェアから直接使用されることが可能である。

【0013】

ＰＩＯ送信は、送信されたパケットの低遅延および高メッセージ速度を送達する、超低オーバーヘッド送信機構を提供する。適切であれば、帯域幅を改善するためにＰＣＩｅ相互接続およびインタフェース上で細かい書込みを６４Ｂ（バイト）書込みに凝集するため、ホストプロセッサ１０４のライトコンバイニング（ｗｒｉｔｅ―ｃｏｍｂｉｎｉｎｇ：書込み結合）およびストアバッファ機能が使用される。ホストプロセッサ１０４は送信バッファへのパケットのバイトの書込み（本質的にメモリコピー）に関わるので、ＰＩＯ送信機構はプロセッサに集約される。これらの性能特性は、ＰＩＯ送信を小型から中型メッセージ向けに非常によく最適化させる。

【0014】

送信ＤＭＡまたはＳＤＭＡと略される送信ダイレクトメモリアクセスは、著しく低いプロセッサ利用でパケットが伝送エンジン１０８に送信されるように、プロセッサメモリコピーを排除する。ＰＩＯ送信機構のようにプロセッサ書込みを用いてパケットをＨＦＩ１０２に対して押す代わりに、送信ＤＭＡブロック１２２内のＳＤＭＡエンジン１２３は、ファブリックリンクに放出されるパケットを形成するために、ホストメモリ１０６から直接パケットヘッダおよびペイロードを引き出す。一実施形態において、送信ＤＭＡブロック１２２は１６個の独立したＳＤＭＡエンジン１２３をサポートし、各々は自身のＳＤＭＡ待ち行列に関連付けられている。

【0015】

送信ＰＩＯおよびＳＤＭＡのいずれも、パケットの送信に蓄積転送アプローチを使用する。ヘッダおよびペイロードは、パケットがリンクに放出され始めるようになる前に、伝送エンジン１０８上の送信バッファによって完全に受信されなければならない。送信メモリ１２０およびＳＤＭＡバッファ１２４として図１に示されるように、送信バッファメモリがこの目的のためＨＦＩ１０２上に提供され、別の送信バッファメモリが送信ＰＩＯおよびＳＤＭＡのために提供される。一実施形態において、この分割はＨＦＩ設計にハードワイヤドで組み込まれており、ソフトウェア構成可能ではない。しかしながら、送信ＰＩＯ用の送信メモリ１２０は、送信バッファクレジットの粒度でのソフトウェア制御の下で送信コンテキストに割り当てられることが可能である。同様に、ＳＤＭＡバッファ１２４内の送信バッファメモリは、同じ粒度でＳＤＭＡエンジン１２３に割り当てられることが可能である。

【0016】

受信エンジン１１４の基本機能は、受信ポート１１６で受信した（ファブリックからの）インバウンドパケットのヘッダおよびペイロードを分離して、パケットヘッダおよびペイロードデータをホストメモリ１０６に書き込むことである。一実施形態において、ＨＦＩ１０２のために設計されたパケットデータは、受信ポート１１６で受信された「フリット（ｆｌｉｔ）」（フリットストリーム）を備えるデータユニットのストリームとしてファブリックのリンクを介して転送されるが、フリットはパケットに再構築され、これらはその後受信エンジン１１４に転送される。着信するパケットデータはまずＲｘ受信ブロック１２８で処理されるが、ここでパケットのヘッダ内の様々なフィールドが、パケットのタイプを判断するために抽出およびチェックされる。パケットデータ（そのデータペイロード）は受信バッファ１３０内に格納され、その一方でパケットヘッダはパーサ１３６に転送され、これはその宛先アドレスおよびその他のフィールドデータを抽出するためにヘッダデータを解析し、同時にさらなる動作がパイプライン演算１３８によって実行される。該当するパイプライン演算と併せて、パケットデータが受信バッファ１３０から読み出されてＤＭＡエンジン１３２を介して転送されるが、これはＰＣＩｅ ＤＭＡ書込みを介してメモリ１０６にパケットデータを転送するように構成されている。

【0017】

図１は、ＣＬＫ１およびＣＬＫ２で示される２つのクロックドメインの使用を示すために用いられる垂直な点線１４６を、さらに示す。いくつかの実施形態において、ＰＣＩｅインタフェース１１８に使用されるクロック周波数は、残りのＨＦＩ構成要素のために使用されるクロック周波数とは異なってもよく、各クロックドメインには別の基準クロックが用いられる。図示されないものの、伝送ポート１１０および受信ポート１１６内で使用されるクロックドメインもまた、伝送エンジン１０８および受信エンジン１１４によって採用されるクロックドメインとは別であってもよい。

【0018】

図２は、送信ＰＩＯおよびＳＤＭＡ動作のさらなる詳細を示す。図示されるように、最大１６０個の送信コンテキストが、送信ＰＩＯパケットデータに関連して採用されてもよい。各送信コンテキストは、その送信コンテキストに割り当てられたＰＩＯ送信メモリ１２０の隣接したスライスを備える。したがって送信コンテキスト用の送信バッファは、ホスト物理アドレス空間の中で隣接することになる。ユーザプロセスのためのユーザ仮想アドレス空間内へのこの送信バッファの通常マッピングもまた通常は、実質的に隣接する。一実施形態において、各送信コンテキストがｎ×６４Ｂを備えるように、送信バッファ内の送信ブロックは６４Ｂのブロックを備え、ここでｎは０より大きい整数である。一実施形態において、送信ブロックは６４Ｂの境界上に揃えられるが、しかし送信バッファ割り当てに対しては何ら追加アライメント制約は設けられない。一実施形態において、送信コンテキストのために割り当てられた送信バッファのサイズは限界を有する。たとえば、一実施形態においてＰＩＯ送信メモリ１２０のサイズは１ＭＢ（１，０４８，５７６バイト）であり、最大送信バッファサイズは６４ＫＢ（ｎ＝１０２４）である。

【0019】

一実施形態において、ホストプロセッサ１０４は４ＫＢページ粒度を用いるメモリページングを採用する。しかしながら、ホスト仮想アドレス空間内への送信バッファメモリマッピングは、４ＫＢページ粒度である必要はない。

【0020】

このアーキテクチャ選択は、送信バッファが６４Ｂの粒度であるときに、ホストプロセッサの４ＫＢのページング機構が２つの送信コンテキストの間に保護を提供するのに十分ではないことを意味している。単純なアドレス空間再マッピングは、ベースオフセットを用いてＨＦＩ１０２によって実施され、送信コンテキストによって区切られる。これは、特定のコンテキストのため送信バッファにアクセスするために使用される物理アドレス内に送信コンテキスト番号を含むことによって、達成される。このため送信コンテキスト番号は、ドライバがユーザプロセスのために設定するマッピングの物理アドレス内に含まれる。ＨＦＩ１０２は、現在書き込まれている送信コンテキストを識別するために、送信バッファへの書込みに関する情報を使用し、送信コンテキストが送信バッファメモリ内のその特定の送信ブロックへのアクセスを有することを認証し、その後送信バッファメモリ内に指数へのアドレスを再マッピングするために、その送信コンテキストの情報を調べるためその値を使用する。このアプローチは、各送信バッファの開始がＨＦＩのアドレスマップ内の４ＫＢのページに揃えられるようにしながら、まだ６４Ｂの粒度で送信バッファメモリを共有できるようにする。

【0021】

先に論じられたように、送信バッファごとの送信バッファメモリの最小量は、１送信ブロックに対応する６４Ｂである（ｎ＝１）。送信バッファごとの送信バッファメモリの最大量は、１０２４個の送信ブロックとなる６４ＫＢである。一実施形態において、この制限は、ＰＩＯ送信機構によるアドレス指定に使用される物理アドレスマップの量を制限するために設けられる。加えて、新規パケットの開始（ＳＯＰ）である送信ブロックと新規パケットの開始ではない送信ブロックとを区別するために、１つ以上のアドレスビットが使用される。この符号化は、パケット境界が区切られるようにし、ＰＩＯ送信機構の使用の正当性に対するサニティチェックを提供する。加えて、ＳＯＰ送信ブロック内の最初の８Ｂは、Ｐｅｒ Ｂｕｆｆｅｒ Ｃｏｎｔｒｏｌ（ＰＢＣ）情報をＨＦＩ１０２に渡すために使用される。ＰＢＣは、パケットデータ自体の一部ではない６４ビット制御クワッドワード（ＱＷ）であるが、しかしパケットに関する重要な制御情報を包含する。アドレス内のＳＯＰビットは、アダプタが送信バッファへの書込みの着信ストリーム内でＰＢＣ値を位置特定できるようにする。

【0022】

一実施形態において、ＰＩＯ送信物理アドレス空間の復号化が、以下の表１に定義され、図３に示される。図３に示される実施形態において、ＰＩＯ送信バッファメモリによって占有される物理アドレス空間の総量は３２ＭＢである。

【0023】

【表1】

アドレスマッピングプロセスの３つの例が、図４に示される。なお、３つの例示的コンテキストは、送信バッファメモリ内で隣接しており、４ＫＢページ上では揃っておらず、送信コンテキストにわたって共有することなくホスト仮想アドレス空間内にマッピングされ得るように、コンテキスト番号によって装置物理アドレス空間内で分離していることに、注意する。この極端な例は、ＰＩＯ送信メモリ１２０内の送信バッファメモリに値する同じ４ＫＢ上に各々マッピングされた１つの６４Ｂ送信ブロックの６４個の異なる送信コンテキストを使用する、６４のユーザプロセスであろう。

【0024】

例として、送信コンテキスト０のアドレスマッピングを検討する。この送信コンテキストは、６４ブロックすなわち４ＫＢのユーザプロセス仮想アドレス空間を備える。コンテキストは装置物理アドレス空間のビット［２３：１６］で符号化され、その一方で仮想アドレスビット［１１：０］が仮想−物理アドレス変換において確保される。送信コンテキストが新規パケットの開始に対応する場合にはビット２４が設定（「１」）され、そうでなければビット２４が解除される（「０」）ことに、さらに注意する。物理アドレス−ＰＩＯ送信メモリアドレスマッピングは、アドレスのコンテキストベースビット［１５：０］にコンテキストアドレスビット［２４：１６］を加える。さらに図示されるように、送信コンテキストのサイズは、仮想メモリ、物理メモリ、およびＰＩＯ送信メモリの各々において同じである。送信コンテキスト１および送信コンテキスト２には、類似のアドレスマッピングが採用される。

【0025】

ＰＩＯ送信のためのパケット充填は、ホストアドレス空間内にマッピングされた送信バッファ内へのホストプロセッサ書込みを使用する。マッピングは通常、プロセッサ書込みがＨＦＩ１０２へのＰＣＩｅ上のポステッドライトトランザクションとして押し出される前にキャッシュ格納される代わりに、６４Ｂプロセッサストアバッファサイズまで都合よく凝集されるように、ライトコンバイニングとして構成される。

【0026】

一実施形態において、ＨＦＩアーキテクチャは、８Ｂ粒度のＰＩＯ送信書込みトランザクションを採用する。したがって、各トランザクションは８Ｂの倍数のサイズであり、８Ｂで揃えられたアドレス上で開始する。一実施形態において、各書込みは、各書込みが６４Ｂ送信ブロック内に包含されることを保証するために６４Ｂ境界を超えないという要件がある。したがって、一実施形態において、ＰＩＯ送信は、サイズが６４Ｂであって６４Ｂに揃えられたＰＣＩｅ書込みを採用する。

【0027】

最高性能のため、ソフトウェアはアドレス昇順で送信バッファを充填し、６４Ｂ転送のために最適化されることが、推奨される。一実施形態において、ソフトウェアは、ＰＩＯ送信動作のために使用されるすべての送信ブロックが正確に充填されるように、６４Ｂの倍数まで書込みシーケンスを生成するためのパディングを（適宜）採用する。このため、命令の観点から、ソフトウェアは次の６４Ｂ送信ブロックへの書込みを開始して最後の６４Ｂ送信ブロックまで継続する前に、１つの６４Ｂ送信ブロックのすべてを書き込むべきである。プロセッサライトコンバイニング機構はこれらの書込みを並べ替えることができ、したがってＨＦＩハードウェアはＰＣＩｅ上でこの順番で到着するこれらの書込みシーケンスに依存しない。ＨＦＩハードウェアは、８Ｂレベルの書込みシーケンスの任意の並べ替えをサポートする。書込みシーケンスに順序を付与するために、ソフトウェアによってｓｆｅｎｃｅ命令が使用可能である。しかしながら、ｓｆｅｎｃｅは高額な動作であるので、ＨＦＩハードウェアは、以下に記載されるようにｓｆｅｎｃｅの必要性を排除するための最適化を提供する。

【0028】

各送信コンテキストは、ホストメモリ内にマッピングされた書込み専用送信バッファを提供する。先に記載されたように、４ＫＢで揃えられたアドレスの送信バッファ開始は、サイズが最大６４ＫＢであり、６４Ｂ送信ブロックの単位である。ＰＩＯ送信機構は、ＦＩＦＯ順で送信バッファにパケットを書き込むことによって進められる。一実施形態において、各パケットは、８ＢＰＢＣを書込み、その後ヘッダおよびペイロードがアドレス昇順で続くことにより、充填される。このシーケンスによって占有される送信バッファの量は、整数の隣接する６４Ｂ送信ブロックとなるように（送信バッファメモリを中心とした隣接法のように）切り上げられ、ソフトウェアはこれらの６４Ｂ送信ブロックのすべてを正確に充填するために、その書込みシーケンスまで引き上げるように構成されている。
ＰＢＣは、各ＰＩＯ送信の最初の６４Ｂ送信ブロックの最初の８Ｂである。最も小さいＰＩＯ送信は１つの送信ブロックであり、その一方でサポートされる最大のパケットサイズは１２８Ｂ＋１０ＫＢ ＭＴＵ（最大転送単位：Ｍａｘｉｍｕｍ Ｔｒａｎｓｆｅｒ Ｕｎｉｔ）に対応する１６２送信ブロックを必要とする。書込み上のパケットサイズは４Ｂの倍数であり、そのためより粒状の６４Ｂ送信ブロックの使い方における柔軟性が提供される：
・４Ｂの倍数の回線上のパケット長は、ＰＢＣのＰｂｃＬｅｎｇｔｈＤＷｓフィールドに指定される。
・６４Ｂの倍数の充填サイズは、ＰｂｃＬｅｎｇｔｈＤＷｓを６４Ｂの倍数まで切り上げることによって決定される。
・充填サイズは、８ＢのＰＢＣプラスパケット長プラス書込みシーケンスを６４Ｂの倍数にするためにいずれか必要なパディングに及ぶ。すべての送信ブロックが完全に充填されるので、６４Ｂパディング要件はハードウェア実装を簡素化する。加えて、このアプローチは、６４Ｂまで充填されるパケットの最後の部分のためのライトコンバイニングストアバッファが明確なｓｆｅｎｃｅ命令を使用せずこれを自動的にＨＦＩにドレインさせることを保証することにより、性能を改善する。パディングバイトは、回線に放出されるパケットに寄与しない。

【0029】

一実施形態による、送信バッファのレイアウトが図５に示される。送信バッファメモリは、ＦＩＦＯ的セマンティックとともに使用される。ＦＩＦＯ順は、送信バッファマッピングで各パケットに使用される送信ブロックのアドレス順によって定義される。なお、送信バッファはラップアラウンド的に使用される（たとえば円形ＦＩＦＯとして実施される）ことに、注意する。これは、一旦ソフトウェアが送信バッファの最後の６４Ｂを書き込んだら、アドレスを更新して送信バッファのベースに戻す必要があることを、意味する。送信バッファへのこの書込みは、ホストプロセッサが、まだファブリックに放出されていない前のパケットからまだ使用中の送信バッファブロックに上書きしないことを保証するための、クレジット制限およびクレジット返信ポリシーの対象である。ＦＩＦＯ的セマンティックとは、
・ライトコンバイニングの実施に内在する書込みの並べ替えに対処する再構築機能があっても、パケットはＦＩＦＯ順で充填される。
・パケットは引き続きＦＩＦＯ順で発信する。発信後、パケットはＶＬ調停の対象となる。
・パケットは引き続きｐｅｒ−ＶＬ発信ＦＩＦＯから放出され、同じＶＬの同じコンテキストからのパケットでは順序通りとなるが、異なるＶＬでは同じ送信コンテキストからのパケットでも順序通りにならないだろう。
・クレジット返信は元のＦＩＦＯ順である。これは、無秩序に放出されるパケットのクレジットは、その送信コンテキスト上の先のパケットがすべて既に放出されるまで回復されないことを意味する。

【0030】

ライトコンバイニングマッピングは、パケットを構築するために使用される書込みをホストプロセッサが並べ替えられるようにする。従来のアプローチの下では、順序を付与するプロセッサアーキテクチャ機構はｓｆｅｎｃｅ命令である。これにより、ｓｆｅｎｃｅ命令より前のすべての書込みがｓｆｅｎｃｅ命令後のすべての書込みに先立つＨＦＩから見えるようになることを保証する。しかしながら、この順序付けは、ホストプロセッサ内でストアを発行するＣＰＵコアから統合入出力ブロック（ＩＩＯ；Ｉｎｔｅｇｒａｔｅｄ Ｉｎｐｕｔ−Ｏｕｔｐｕｔ）内の順序付けポイントまでの往復を要するので、著しいコストを伴う。これは著しい遅延を加え、またｓｆｅｎｃｅ順序付けが確認されるまでその他すべてのストアがＣＰＵコア内で完了するのを妨げる。ＣＰＵのアウトオブオーダー能力は、命令による何らかの前進がこの遅延をカバーできるようにするが、しかしこれらのリソースはすぐに尽きる可能性があり、回復すべき生きている命令の重要なバックログが生じる。ＨＦＩアーキテクチャは、ｓｆｅｎｃｅ命令がライトコンバイニングシーケンスを順序付ける必要性を最小化または排除しようとする。

【0031】

第一の最適化は、パケット内のｓｆｅｎｃｅの排除である。ここで１つのパケットのＰＩＯ送信動作を備える書込みはプロセッサによって並べ替えられることが可能であり、ＨＦＩは正しい順序を再構築し、パケット充填が完了してパケットが発信されるようにすべての書込みが到着したときを検出する機構を提供する。この最適化は、パケット内の送信ブロックの数についてさらなる利益を提供する。第二の最適化は、パケット間のｓｆｅｎｃｅの排除であり、これはＨＦＩが、インターリーブされた書込みを異なるパケットＰＩＯ送信からそれぞれのパケットに再構築することを必要とする。この最適化は、単一の６４Ｂ送信ブロックに適合するパケットの一般的な例など、短いパケットにとって非常に重要である。ＨＦＩによって提供される機構は、両方の最適化をカバーする。

【0032】

ＨＦＩは、アドレスを復号化することによっていずれのＰＩＯ送信書込みの正確なデータ配置も決定する。コンテキストはより高次のアドレスビットで利用可能であり、これは、送信コンテキストがベースの使用へのアクセスを有する送信バッファ部分を決定し、既に記載された再マッピングとの境界を示す。アドレスの最も低い１６ビットは、その送信バッファ内の書込み済みデータの配置を決定する。このアプローチは、これらの書込みが８Ｂ粒度に並べ替え／分割／統合したとしても、８Ｂ粒度の書込みが送信バッファメモリのパケットにいつも正しく再構築されることを保証する。

【0033】

図６ａは、一実施形態によるシステム１００のさらなる詳細を示す。プロセッサ１０４は、アウトオブオーダー実行をサポートする複数のプロセッサコアを備えるＣＰＵ６００を含む。一実施形態において、各物理プロセッサコアは、Ｉｎｔｅｌ（登録商標）ＣｏｒｐｏｒａｔｉｏｎｓのＨｙｐｅｒｔｈｒｅａｄｉｎｇ（商標）アーキテクチャの下でサポートされるものなど、２つの論理コアとして実現されてもよい。一実施形態において、プロセッサ１０４は６４ビットプロセッサであり、各コアは複数の６４ビット（６４ｂ）レジスタを含む。プロセッサ１０４はまた、レベル２（Ｌ２）キャッシュ６０２と、各コアについて命令キャッシュ６０４およびデータキャッシュ６０６に分割されるレベル１（Ｌ１）キャッシュと、を含む。簡潔さのため図示されないものの、プロセッサ１０４は、プロセッサコアにわたって共有される最終レベルキャッシュ（ＬＬＣ）も採用してよい。プロセッサ１０４は、ストアバッファ制御論理６０９を介して制御されるストアバッファ６０８、ＩＩＯブロック６１０、およびＰＣＩｅインタフェース６１２を、さらに含む。プロセッサ１０４の内部構造の一実施形態のさらなる詳細は、図１７に示され、以下に記載される。

【0034】

一実施形態において、メモリ１０６およびＬ２キャッシュ６０２の各々は６４バイトのキャッシュラインを採用し、その一方でストアバッファ６０８は６４バイトのストアブロックを採用する。さらに図示されるように、一実施形態においてデータは、「ｍｏｖ」命令を用いて６４ビット（８バイト）単位でＣＰＵ６００内の６４ｂレジスタからストアバッファ６０８に書き込まれる。簡潔さのため、ｍｏｖ命令は、本明細書の図中において「ｍｏｖ．ｑ」と記される。

【0035】

選択的に、データは１６Ｂおよび３２Ｂなどその他のサイズを有するストアユニットを用いてストアバッファ６０８に書き込まれてもよい。以下により詳細に記載されるように、一実施形態において、６４Ｂのデータを６４Ｂのストアブロックに書き込むために５１２ビット書込み命令が使用されるが、各６４Ｂ書込みは１つのストアブロックを充填する。

【0036】

ＰＩＯ送信メモリ１２０は、２つの送信コンテキスト（送信コンテキスト１および送信コンテキスト２）を含むように示されている；しかしながら、実際の実施ではＰＩＯ送信メモリ１２０は一般的により多くの送信コンテキスト（最大１６０まで）を有することが、認識されるだろう。送信コンテキストは、ソフトウェアアプリケーションに（さもなければ別途ソフトウェアアプリケーションによる使用のための送信コンテキストの割り当ての要求に応えて）割り当てられる。この例において、ソフトウェアアプリケーション「Ａ」は割り当てられた送信コンテキスト１であり、ソフトウェアアプリケーション「Ｂ」は割り当てられた送信コンテキスト２である。送信コンテキスト１および２のサイズはそれぞれｘ個およびｙ個の６４Ｂ送信ブロックである。送信コンテキストの初回割り当て時に、送信コンテキスト内の送信ブロックの各々は空白すなわち「フリー」となる（たとえば、データの追加に利用可能）。実行中の動作の間、送信コンテキストは円形ＦＩＦＯとして動作し、ＦＩＦＯ中の６４Ｂ送信ブロックは、ストアバッファ６０８から充填され、パケットが放出ブロック１２６に転送される際にＦＩＦＯから取り除かれ（以下に記載されるように送信ブロックの放出と称される）、放出された送信ブロックを再利用のためフリーにする。ＦＩＦＯコンテキストの下で、各送信ブロックはＦＩＦＯスロットに対応し、データが追加されるスロットはＰＩＯ送信メモリ１２０内の対応するメモリマップアドレスを有する。

【0037】

各パケット６１４は、ＰＢＣフィールド、様々なヘッダフィールド（簡潔さのため組み合わせて図示される）、ＰＳＭ（Ｐｅｒｆｏｒｍａｎｃｅ Ｓｃａｌｅ Ｍｅｓｓａｇｉｎｇ）ヘッダおよびＰＳＭデータ、ならびにＩＣＲＣ（不変ＣＲＣ）フィールドを含む、複数のヘッダフィールドを含む。図示されるように、パケット６１４の最小サイズは６４Ｂであり、これはストアバッファ６０８内のストアブロックサイズと一致し、送信コンテキストＦＩＦＯの各スロットに使用される６４Ｂ送信ブロックサイズと一致する。

【0038】

実行中の動作の間、ＰＩＯ送信メモリ１２０内の送信コンテキストにメモリ１０６内のパケットデータのコピーが書き込まれるようにするため、ＣＰＵ６００のコア上でソフトウェア命令が実行される。

【0039】

まず、対応する命令とともにパケットデータがメモリ１０６からＬ２キャッシュ６０２にコピーされ、命令およびデータはＬ２キャッシュ６０２から命令キャッシュ６０４およびデータキャッシュ６０６にコピーされる。選択的に、パケットデータおよび命令は既にＬ２キャッシュ６０２の中または命令キャッシュ６０４およびデータキャッシュ６０６の中にあってもよい。ＣＰＵ６００内のレジスタからストアバッファ６０８内の８Ｂストアユニットへパケットデータを書き込むためのｍｏｖ命令のシーケンスは、パケットにグループ分けされたものとして本明細書の図に示されている；しかしながら、プロセッサコアがｍｏｖ命令を包含する命令スレッドを継続的に実行していることは、認識されるだろう。図６ｂに示されるように、プロセッサコアレジスタからストアバッファ６０８内の８Ｂストアユニットにデータをコピーする（書き込む）ためのｍｏｖ命令が処理されるにつれて、６４Ｂストアブロックが充填される。一実施形態において、ストアバッファ６０８はランダムアクセスで動作するが、このときストアブロックのアドレスは、ＰＩＯ送信メモリ１２０にデータを格納するために使用されるアドレス指定とは無関係である。任意の６４Ｂストアブロックが充填されたときを判断するために、ストアバッファブロック充填検出機構がストアバッファ制御論理６０９内で実施される。ストアブロックが充填されたことを検出すると、ストアブロックは、ＰＩＯ送信メモリ１２０内の適切なＦＩＦＯスロットでストアバッファ６０８から６４Ｂ送信ブロックへの６４ＢのＰＣＩｅポステッドライトを実行することにより、「ドレイン」される。用語「ドレイン（ｄｒａｉｎｅｄ）」は本明細書において、６４ＢのＰＣＩｅポステッドライトがハードウェア（たとえば、ストアバッファ制御論理６０９）によって生成されることを伝えるために使用されるものであり、一般的にソフトウェア命令によって実施されるバッファの「フラッシュ（ｆｌｕｓｈｉｎｇ）」と対立する。図６ｂに示されるように、時間Ｔ_ｍにおいて、ストアブロック６１６は満杯であるとして検出され、その結果ストアブロック６１６は、送信コンテキスト１のために割り当てられたＰＩＯ送信メモリ１２０の送信バッファ内の送信ブロック６１８へ、６４ＢのＰＣＩｅポステッドライトを介してドレインされる。同様に、続く時間Ｔ_ｎにおいて、ストアバッファ６０８内のストアブロック６２０は満杯であるとして検出され、その結果ストアブロック６２０は、ＰＩＯ送信メモリ１２０の送信ブロック６２２へ、第二の６４ＢのＰＣＩｅポステッドライトを介してドレインされる。丸で囲まれた「１」および「２」の使用は、本明細書の図６ｂおよびその他の図においてＰＣＩｅポステッドライトが発生する順番を示すためのものである。６４Ｂストアブロックのドレインと併せて、その格納空間は再利用のためフリーにされる。一実施形態において、ストアバッファ６０８は、書込みに利用可能なフリーのストアブロック（６４Ｂ境界上の８つの連続する８Ｂブロック）をプロセッサコアが識別できるようにするためにプロセッサ（またはプロセッサコア）から見えるようになっている、ストアブロック使用情報を含む。加えて、本明細書の図の例において、ストアブロックは順次充填されるものとして示されてもよい。しかしながら、データを格納するために使用される特定のストアブロックはデータが書き込まれるＰＩＯ送信メモリアドレスとは無関係となる、ランダムアクセスを用いてストアバッファが動作する場合があるので、これはデータの移動の表示を簡素化するためのものである。

【0040】

図７ａから図７ｆは、パケットデータがＰＩＯ送信メモリ１２０に追加され、８Ｂストアユニットへの８Ｂ書込みを用いて引き続き放出される様を示す、例示的な時間経過シーケンスを示す。図７ａから図７ｆの各々は、ストアバッファ６０８およびＰＩＯ送信バッファ１２０のさらなる詳細を示す。上述のように、ＰＩＯ送信バッファのメモリ空間は、最大１６０個の送信コンテキスト用のバッファに分割されてもよい。図７ａから図７ｆの各々は、図６ａおよび図６ｂにも示されて先に論じられた送信コンテキスト１および２に加えて、送信コンテキスト３および送信コンテキスト４を示している。送信コンテキスト３および４は、ＰＩＯ送信バッファ１２０のバッファ空間を共有する、追加送信コンテキストを表している。加えて、送信コンテキスト３および４は、これらの送信コンテキストが別のプロセッサコア上で起動しているソフトウェアによって使用されていることを示すために、異なるクロスハッチパターンで示されている。

【0041】

一般的に、マルチコアＣＰＵにおいて、様々なタスクおよびサービスに対応する命令スレッドは、プロセッサコアに割り当てられてその間に分散している。一実施形態の下で、ＰＩＯ送信バッファ１２０は、これらの命令スレッドの一部を備える構成要素、モジュールなどを含むソフトウェアアプリケーションの間で共有される。これらの命令スレッドは、別のコア上で実行中の命令スレッドに対して非同期で実行され、このため複数のソフトウェアアプリケーションは、コアごとにＰＩＯ送信バッファ内の送信コンテキストに非同期で追加されているパケットデータを生成するため、並行して実施されてもよい。

【0042】

したがって、各コアはｍｏｖなどの単一の命令しか同時に実行できないが、複数の命令スレッドが並行して実行されており、その結果、図示されない送信コンテキストのみならず送信コンテキスト３および４など、その他の送信コンテキストに採用されている図７ａから図７ｆに示されるものへの類似のデータ転送が行われる。これらの共起的で非同期のデータ転送をサポートするため、具体的なプロセッサアーキテクチャに応じて、ストアバッファが複数のコアの間で共有されるように構成されてもよく、あるいはプライベートなストアバッファが各コアに割り当てられてもよい。

【0043】

図７ａは、最初の６４Ｂストアブロック７００に対応する８つすべての８Ｂストアユニットにデータが追加されている、最初の時間枠Ｔ_１に対応し、その結果、送信コンテキスト１の３つ目のＦＩＦＯスロットで６４バイトのデータが送信ブロックに書き込まれる。データが書き込まれる送信ブロックは、図４に示され上記で論じられたような、ＰＩＯ書込み命令および仮想−物理−ＰＩＯ送信メモリアドレス変換に基づくその送信ブロックのメモリマップアドレスに基づくことになる。この送信ブロックは、（該当すればパディングを含む）ブロックｊ個分の長さの充填サイズを有するパケット内の、最初のブロックに対応する。先に論じられたように、ＰＢＣヘッダは、４Ｂの倍数のパケット長を規定するＰｂｃＬｅｎｇｔｈＤＷｓフィールドを含む。送信コンテキスト内のパケットによって占有される空間の量（パケットの充填サイズ）はｎ個の６４Ｂブロック（およびひいてはｎ個のＦＩＦＯスロット）を備え、ここでｎは、ＰｂｃＬｅｎｇｔｈＤＷｓフィールド値を次の６４Ｂの倍数に切り上げることによって決定される。図７ａに示される例において、ｊ＝ｎであり、ＰｂｃＬｅｎｇｔｈＤＷｓフィールド値によって決定される通りである。

【0044】

パケットの充填サイズの決定に関連して、ＰＩＯ送信メモリ１２０の送信コンテキスト内へのパケットデータ全体（フルパケット）の転送を完了するためにパケットデータが追加される最後の送信ブロックを識別するための制御情報が生成される；本明細書の図中、まだ受信されていないパケットデータの一部を格納するために使用されるものとして識別される送信ブロックは、「充填予定（Ｔｏ Ｆｉｌｌ）」（充填対象を意味する）と記される。蓄積転送の実施下で、パケット内容全体がＰＩＯ送信メモリ１２０内に格納されるまで、パケット用のデータは放出ブロック１２６に転送されることは不可能である。ＰＩＯ送信ブロック放出制御情報は、（最後の送信ブロックを充填するためのいずれか適用可能なパディングを含む）パケットの内容全体がＰＩＯ送信メモリ１２０に書き込まれてしまったときを検出する伝送エンジン（図示せず）内の論理において実施されるフルパケット検出機構によって、使用される。一実施形態において、このフルパケット検出機構は、対応するＦＩＦＯスロット内の送信ブロックが充填されるときを追跡し、制御情報は、各パケットの開始および終了ＦＩＦＯスロットのアドレス（または送信ブロック番号またはＦＩＦＯスロット番号など、その抽出）を備える。一般的に、アドレスはＰＩＯ送信メモリ１２０のベースアドレスに対するもの、またはＦＩＦＯバッファに関連付けられた送信コンテキストのベースアドレスに対するものである。

【0045】

図７ａから図７ｆにおいて、それぞれのパケットのｍｏｖ命令が、Ｐａ−ｂのラベル付けスキームを用いてパケットごとにグループ分けされて示されており、ここでａは送信コンテキストに対応し、ｂはパケットが送信コンテキストに追加された元の順番に対応する。このラベル付けスキームの使用は、パケットデータが送信コンテキストにどのように書き込まれるかをより良く説明するための説明目的のためであり、データがＰＩＯ送信バッファ１２０に書き込まれる実際の位置が、先に論じられたように、アドレス変換スキームと組み合わせたＰＩＯ書込み命令に基づくようになることは、理解されるだろう。

【0046】

ｍｏｖ命令はパケットごとに処理されるように示されているものの、これらの命令の順序は、ｍｏｖ命令がコアの実行パイプラインに到着する順序に対応する。しかしながら、アウトオブオーダー実行をサポートするプロセッサは、命令が到着する順序とは異なる順序で命令を実行してもよい。いくつかの従来アプローチの下では、アウトオブオーダー実行は、パケット内のｍｏｖ命令には許可されるが、パケットをまたいでは許可されない。これは、ＳＦＥＮＣＥ命令後のいずれの格納命令の前でもＳＦＥＮＣＥ命令に先立つすべての格納（たとえば、この例ではｍｏｖ）命令がどこからも見える、ＳＦＥＮＣＥすなわちｓｆｅｎｃｅ（ストアフェンス、図中ＳＦｅｎｃｅとも表される）命令の使用を通じて促進される。その結果、従来のアプローチの下では、ＳＦＥＮＣＥに続くｍｏｖ命令で参照されるパケットデータは、処理パケットのデータのすべてがストアバッファに書き込まれてしまうまで、ストアバッファに書き込まれることは不可能である。この論理を補強するため、命令の実行が中断させられてもよく、その結果としてパケット転送性能が低下する。加えて、同じようにパケット内の書込み順を強化するためにＳＦＥＮＣＥ命令が使用されてもよい。ｓｆｅｎｃｅありおよびなしのＰＩＯ書込みを比較する図は、図９ａおよび図９ｂに示されており、以下に論じられる。

【0047】

本明細書に開示される実施形態の態様によれば、ＳＦＥＮＣＥ命令の従来の使用がなくなり、ストアバッファ内の第二のパケットの格納が（受信命令順で）前の第一パケットの格納の完了に先立って開始できるように、別のパケットからの格納命令を順序に関係なく実行可能とする。この一例が図７ａに示されており、ここでパケットＰ１−２の最初の「ｍｏｖ．ｑ」命令はアウトオブオーダーでパケットＰ１−１の最後の２つの「ｍｏｖ．ｑ」命令に先立って実行され、その結果ストアブロック７０６内の最初の８Ｂストアユニットのデータがストアバッファ６０８に書き込まれている。最初の時間枠の終わりに、パケットデータはｊ−１個の６４ＢのＰＣＩｅポステッドライトを用いて最初のｊ−１個の送信ブロック（パケットＰ１−１のストアブロック７００およびストアブロック７０２によって示される）の送信コンテキスト１にパケットデータが書き込まれている。上述のように、６４Ｂの各ＰＣＩｅポステッドライトと併せて、ドレインされているストアバッファ６０８内の対応するブロックがフリーになっている；このフリー状態は図７ｂに示されており、これは第二の時間枠Ｔ_２を示している。本明細書の図中、６４ＢのＰＣＩｅポステッドライトの順序は、丸で囲まれた番号で示されている。便宜上、６４ＢのＰＣＩｅポステッドライトのグループのデータ転送は、図７ａの番号「２」など、単一の丸付き番号で示されている。

【0048】

この第二の時間枠の間、（この例ではパディングを備える）ストアブロック７０４の残り２つのストアユニットに対応するデータがパケットＰ１−１に追加され、ストアブロック７０４からのデータは６４ＢのＰＣＩｅポステッドライトを介して送信コンテキスト１に書き込まれ、これによりＰＩＯ送信メモリへのフルパケットデータの書込みを完了する。これによりパケット完了状態となり、図１０および図１１に示され、後にさらに詳細に記載されるように、この時点でパケットは、パケット発信調停の準備が整っている。加えて、時間枠Ｔ_２の間、ストアブロック７０６、７０８、および７１０の各々にデータが書き込まれてストアブロック７０６および７０８を満たし、その一方で、ストアブロック７０８の最後のストアユニットを充填するためのｍｏｖ命令は、図示されるようにアウトオブオーダー実行を介して一時的にスキップされる。図示されるように、ＰＢＣヘッダのＰｂｃＬｅｎｇｔｈＤＷｓ値は、パケット充填サイズが３つの６４Ｂ送信ブロックとなることを示している。ストアブロック７０６および７１０の各々を充填すると、これらのストアブロックはドレインされて、対応するデータは６４ＢのＰＣＩｅポステッドライトを介してＰＩＯ送信メモリ１２０内の送信コンテキスト１に書き込まれ、その結果、パケットＰ１−２の最後の６４Ｂブロックが中間送信ブロックに先立って書き込まれる。

【0049】

混乱を低減するため、各ｍｏｖ命令またはｍｏｖ命令のセットの結果を示す矢印のうちいくつかは図７ｃから図７ｆに含まれていない；むしろ含まれている矢印は、新しいストアバッファブロックへの最初の書込み、および書き込まれている最後のブロックのみを示す。図７ｃに示されるように、第三の時間枠Ｔ_３の間、パケットＰ１−２の残りのデータがストアブロック７０８に書き込まれ、その結果このストアブロックデータはドレインされて、ＰＩＯ送信メモリ１２０内のパケットＰ１−２の中間送信ブロックに書き込まれる。これによりＰＩＯ送信メモリへのパケットＰ１−２の転送が完了し、こうしてパケットＰ１−２は発信調停の準備が整う。加えて、送信コンテキスト２に追加される最初のパケットに対応するデータ（２つの６４Ｂ送信ブロックの充填サイズおよび長さを有する、パケットＰ２−１）がストアブロック７１２および７１４に書き込まれ始め、その一方で送信コンテキスト１の第三のパケットＰ１−３のデータはアウトオブオーダー実行を用いてストアブロック７１６に書き込まれ始める。

【0050】

図７ｄは、時間枠Ｔ_４の間のデータ転送の状態を示す。この時間枠の間、パケットＰ２−１の最後の１６バイトがストアバッファ６０８に書き込まれ、６４ＢのＰＣＩｅポステッドライトを介してストアブロック７１４をドレインさせ、これによりＰＩＯ送信メモリ１２０内のパケットＰ２−１の第二の送信ブロックを充填し、パケットＰ２−１を発信調停に利用できるようにする。パケットＰ１−３データはストアブロック７１６および７１８の両方を充填するために追加され、２つの６４ＢのＰＣＩｅポステッドライトを介してＰＩＯ送信メモリ１２０内のパケットＰ１−３データに両方のストアブロックをドレインし、やはりパケットＰ１−３を発信調停に利用できるようにする。２つの追加パケットＰ２−２およびＰ１−４のｍｏｖ命令もまた時間枠Ｔ_４に追加されている。パケットＰ２−２は、送信コンテキスト２に追加される第二のパケットであり、ｋ個の６４Ｂブロックのサイズを有し、いかなるパディングも必要としない。パケットＰ１−４は、送信コンテキスト１に追加された第四のパケットであり、６４Ｂの最小サイズを有することになる。ストアブロック７２０および７２２によって示されるように、パケットＰ２−２の最初のｋ−１個のストアブロックは、ストアバッファ６０８に追加され、ｋ−１個の６４ＢのＰＣＩｅポステッドライトを介してＰＩＯ送信メモリ１２０に書き込まれている。パケットＰ２−２の最後の８バイトを除くすべてが、ストアブロック７２４に追加されている。これら最後の８バイトがストアブロック７２４の最後の８Ｂストアユニットに書き込まれる前に、パケットＰ１−４の最初の８バイトを書き込むためのアウトオブオーダーｍｏｖ命令が実行され、これによりストアブロック７２６を充填し始める。最後に、パケットＰ１−２がＶＬアービタによって放出のために選択され、そのデータはＦＩＦＯ順でその送信ブロックについて放出される。これは、同じ送信コンテキストの送信バッファの先のパケットのパケットデータ後にそのデータが追加されるパケットが、先のパケットに先立って放出のために選択され、こうしてパケットが送信コンテキスト内に充填されるアウトオブオーダーで放出される例を示す。

【0051】

図７ｅは、時間枠Ｔ_５の間の転送の状態を示す。パケットＰ２−２の最後の８バイトがストアブロック７２４に書き込まれ、このストアブロックは６４ＢのＰＣＩｅポステッドライトを介して、ＰＩＯ送信メモリ１２０内のパケットＰ２−２の最後の送信ブロックにドレインされ、こうしてパケットＰ２−２データの書込みを完了し、パケットＰ２−２を発信調停に利用できるようにする。パケットＰ１−４の残りの５６バイトはストアバッファ６０８のストアブロック７２６に書き込まれ、続いて６４ＢのＰＣＩｅポステッドライトを介してストアブロックデータがＰＩＯ送信メモリ１２０に書き込まれる。受信すると、ＰＣＢのＰｂｃＬｅｎｇｔｈＤＷｓフィールドが検査され、このパケットが６４Ｂ送信ブロック１個分の長さを有すると判断される；パケットＰ１−４のデータ全体がこのブロック内に包含されているので、パケットＰ１−４もまた充填されるよう標識されて発信調停の準備が整う。

【0052】

この例において追加される最後のパケットは、パケットＰ２−３であり、これは１９２Ｂ（３×６４Ｂ）の長さを有し、いかなるパディングも必要としない。この転送は、ストアバッファ６０８内の３つのストアブロック７２８、７３０、および７３２へのパケットデータの１９２Ｂの最初の書込みによって行われる。各ストアブロックへの８つのｍｏｖ命令が完了すると、ストアブロックは６４ＢのＰＣＩｅポステッドライトと併せて、ＰＩＯ送信メモリ１２０の送信コンテキスト２のパケットＰ２−３のために割り当てられたそれぞれの送信ブロック内へドレインされる。最後の６４ＢのＰＣＩｅポステッドライトを完了すると、パケット書込み完了機構は、パケットＰ２−３の全体がＰＩＯ送信メモリ１２０に書き込まれたことを検出し、こうしてパケットＰ２−３もまた完全に充填されて標識されて発信調停に利用できるようになる。また、パケットＰ１−１が放出のためにＶＬアービタによって選択されており、その送信ブロックがＦＩＦＯ順で放出される。

【0053】

図示される実施形態において、パケットＰ２−３の最後のｍｏｖ．ｑ命令に続いてＳＦＥＮＣＥ命令が追加される。これは、そのいずれかがフラッシュされる前にパケットＰ２−３のデータのすべてがストアブロック７２８、７３０、および７３２に書き込まれることを保証するためである。続くパケットのための書込み命令が命令スレッド内でただちに続く場合には、命令が各々該当するストアブロックを充填し、その結果としてストアブロックはフラッシュされる前にドレインされるので、ＳＦＥＮＣＥ命令の使用は必要とされない。

【0054】

上記に加えて、時間枠Ｔ_５の間、パケットＰ１−２およびパケットＰ２−１の各々は完全に放出されており、その対応する送信ブロックはクリアになっている（時間枠Ｔ_５の早い時期の間にパケットＰ２−１もまた放出のために選択されることに注意）。図１１および図１４を参照して後に記載されるように、送信ブロック状態がクリアになっているとき、クリア送信ブロックに対応する送信コンテキストのクレジットは、クリア状態に到達していない低ＦＩＦＯスロットを占有する送信ブロックがない場合に返信される。この例において、この条件は送信コンテキスト２には当てはまるが、パケットＰ１−１はまだ放出中であってクリア状態に到達していないので、送信コンテキスト１には当てはまらない。その結果、送信コンテキスト２には２つのクレジットが返信され、その一方で送信コンテキスト１にはこの時点でクレジットが返信されない。以下に詳述されるように、一実施形態において、１１ビットのランニングカウントを備える絶対クレジット値が返信される；図７ｅの例では、パケットＰ２−１がクリアになる前には送信コンテキスト２のランニングカウントは０であったと推測されるので、返信されたランニングカウント絶対クレジット値は２である。
図７ｆは、時間枠Ｔ_６の間の転送の状態を示す。この時間枠の間、パケットＰ１−３およびＰ２−２が放出し始め、その一方でパケットＰ１−１は放出を完了し、その送信ブロックはクリアにされる。この時点で、両方のパケットＰ１−１およびＰ１−２のクレジットが送信コンテキスト１について返信され、合計ｊ＋３クレジットとなり、ここでランニングカウンタ値は、送信コンテキスト１について返信された最後のクレジットに対してｊ＋３だけ増加していることになる。図示される例において、前のランニングカウントは２であり（送信コンテキスト１の最初の２つの空のＦＩＦＯスロットに対応する）、このため返信されたランニングカウント絶対クレジット値は２＋ｊ＋３である。加えて、時間枠Ｔ_５の間に送信されたパケットＰ２−１の送信ブロックの２つのクレジットが受信および処理されており、対応するＦＩＦＯスロットはフリーとして標識される。

【0055】

一実施形態によれば、単一のＰＩＯ書込み命令がストアブロックの完全な充填を招くように、ストアバッファ６０８に５１２ビット（６４Ｂ）を同時に書き込むためにＰＩＯ書込み命令が採用されてもよい。一実施形態において、これは５１２ｂ書込み命令の使用を通じて促進されるが、これはＩｎｔｅｌ（登録商標）ＣｏｒｐｏｒａｔｉｏｎのＡｄｖａｎｃｅｄ Ｖｅｃｔｏｒ Ｅｘｔｅｎｓｉｏｎ ５１２（Ｉｎｔｅｌ（登録商標）ＡＶＸ−５１２）によってサポートされている。Ｉｎｔｅｌ ＡＶＸ−５１２は、５１２ビット幅の３２個のベクトルレジスタを特徴としており、５１２ビットのデータがこれらのレジスタからストアブロック６０８内に移動できるようにする。なお、Ｉｎｔｅｌ ＡＶＸ−５１２の使用は単なる例示に過ぎず、５１２ビット書込みをサポートするその他の既存のおよび将来のプロセッサもまた使用可能であるので、これに限定するものではないことに注意する。

【0056】

図８ａから図８ｅは、どのようにしてパケットデータがＰＩＯ送信メモリ１２０に追加され、ストアブロックへの５１２ビット書込みを用いて引き続き放出されるかを示す、例示的な時間経過シーケンスを示す。この例において、各パケットの書込み命令のシーケンスは、５１２ビットのデータを示すｍｏｖ５１２．ｑ命令がＣＰＵ６００ａ内の５１２ｂレジスタから移動させられるものとして示されている。５１２ｂｍｏｖが実行される際に、命令の数は８Ｂｍｏｖを使用するよりもはるかに少ない。以前のように、ＳＦＥＮＣＥは、従来のアプローチではＳＦＥＮＣＥ命令が配置されるはずの場所を示すために、「Ｘ」で示されている。

【0057】

図８ａには、時間枠Ｔ_１の間に実行される動作が示されている。加えて、パケットＰ１−１、Ｐ１−２、Ｐ２−１、Ｐ１−３、Ｐ２−２、およびＰ１−４のシーケンスのｍｏｖ５１２．ｑ命令は、受信されたものとして示されている；しかしながら、これらの命令のうちのいくつかは時間枠Ｔ_１の間には受信されず、むしろデータがストアバッファ６０８に書き込まれているものとして示されるときに近い後の時間枠の間に受信されるので、これは命令のストリームを示すためのものではない。説明および比較目的のため、送信ブロックのいくつかが書き込まれる順序はこれら２つの例の間で異なるものの、図７ａから図７ｆと図８ａから図８ｅとで同じパケットシーケンスが示される。

【0058】

時間枠Ｔ_１の間、パケットＰ１−１のｊ個のｍｏｖ５１２．ｑ命令はＣＰＵ６００ａ上のプロセッサコアによって実行され、その結果、各命令はストレージブロックに書き込まれている６４Ｂのデータとなり、これはその後、図６ｂおよび図７ａから図７ｆに示されるものと類似のやり方で、６４ＢのＰＣＩｅポステッドライトを介してドレインされる。この結果、パケットＰ１−１のフルパケットデータはＰＩＯ送信メモリ１２０に書き込まれ、このパケットのヘッドパケット状態は発信調停のために標識される。加えて、パケットＰ１−２の最初の２つのｍｏｖ５１２．ｑ命令は受信されるが、アウトオブオーダーで実行される。その結果、パケットデータが書き込まれた中間送信ブロックは、６４ＢのＰＣＩｅポステッドライト「４」および「５」によって示されるように、最初の送信ブロックに先立ってＰＩＯ送信メモリに書き込まれることになる。中間送信ブロックのデータを受信すると、ヘッドパケット（およびひいてはＰＢＣヘッダ）はまだ受信されていないので、伝送エンジン論理によって採用された制御情報は、パケットＰ１−２のために充填される必要のあるブロックの数がわかるようになる。ヘッドパケットの受信は、ＰＢＣヘッダを検出するための送信ブロックの最初の部分の検査を介して、あるいは書込みがパケットの最初の送信ブロックを包含することを示す６４ＢのＰＣＩｅポステッドライト内のパケットの開始（ＳＯＰ）ビットを介して、の２つの方法のいずれかで検出可能である。パケットＰ１−２の最初の送信ブロックの受信時に、そのＰＢＣヘッダが検査され、このパケットの充填サイズは送信ブロック３つ分であると判断される。

【0059】

時間枠Ｔ_２の間、図８ｂに示されるように、パケットＰ１−２の最後のｍｏｖ５１２．ｑ命令が実行され、データをまずストアブロック７１０に移動させ、これはその後６４ＢのＰＣＩｅポステッドライト「６」を介してドレインされ、これによりパケットＰ１−２の送信ブロックの充填を完了する。その結果、ヘッドパケット状態が発信調停のために標識される。パケットＰ２−１およびＰ１−３の各々の命令は、６４ＢのＰＣＩｅポステッドライト「７」、「８」、および「９」の順で示されるように、アウトオブオーダーで実行され、その最後は進行中であるがまだ完了していないものとして示されている。パケットＰ２−１の最初の送信ブロックのｍｏｖ５１２．ｑ命令はまだ実行されていない。以前のように、最初の送信ブロック（およびひいては対応する６４ＢのＰＣＩｅポステッドライト内に設定されたＳＯＰビットを含み、ＰＢＣヘッダを包含する、送信ブロック）はまだ書き込まれていないので、制御論理はパケットＰ２−１のサイズを知らない。パケットＰ２−１の最初の送信ブロックによって占有されるＦＩＦＯスロットもまたフリーとして標識されたままである。もしも送信コンテキスト２ ＦＩＦＯの最後のブロックがフリー以外の何かとして標識されたとしたら、論理は（そうなるしかないので）このＦＩＦＯスロットがパケットＰ２−１の最初の送信ブロックに対応すると判断するように構成される可能性があるが、しかしこれは、最初に到着する送信ブロックを待つのに比べて本当に利益を提供するわけではない。

【0060】

図８ｃに示される時間枠Ｔ_３の間、最初の送信ブロックを書き込むためのｍｏｖ５１２．ｑ命令が実行され、その結果ストアブロック７１５は充填され、６４ＢのＰＣＩｅポステッドライト「１０」を介してドレインされる。制御論理は、これがパケットＰ２−１の開始に対応することを検出し、ＰＢＣヘッダのＰｂｃＬｅｎｇｔｈＤＷｓフィールドを検査し、パケット充填サイズが送信ブロック２つ分であると判断する。第二の送信ブロックが既に充填されているので、この第一の送信ブロックを充填した結果、パケット全体が充填され、こうしてヘッドパケット状態は発信調停のために標識される。加えて、パケットＰ２−２のｋ個のｍｏｖ５１２．ｑ命令が実行され、その結果、ストアブロック７１８、ｋ−２個のストアブロック７１９が充填およびドレインされて、ストアブロック７２０のためのプロセスでドレインを伴う充填が行われる。パケットＰ２−２のＰＢＣヘッダを検査すると、このパケットの充填サイズは送信ブロックｋ個分であると判断される。やはり時間枠Ｔ３の間に、パケットＰ１−１は放出のために選択されており、パケットＰ１−１の放出は処理中である。

【0061】

図８ｄに示される時間枠Ｔ_４の間、パケットＰ１−４に対応する単一のｍｏｖ５１２．ｑが実行され、このパケットのデータのすべてをまずストアブロック７１４に、その後ＰＩＯ送信メモリ１２０内の単一の送信ブロックに、６４ＢのＰＣＩｅポステッドライト「１４」を介して書き込む。パケットＰ２−３全体もまた、ストアブロック７２７、７２８、および７３０ならびに６４ＢのＰＣＩｅポステッドライト「１５」、「１６」、および「１７」を介してＰＩＯ送信メモリ１２０に書き込まれる。パケットＰ１−４およびＰ２−３のヘッドパケットの各々は、発信調停のために標識される。加えて、パケットＰ１−２およびＰ２−１の各々は放出のために選択されており、これらのパケットの対応する送信ブロック内のパケットデータは現在放出中である。

【0062】

先に論じられたように、時間枠Ｔ_３の間、パケットＰ１−１のパケットデータが放出され始める。時間枠Ｔ_４の間に放出は完了し、送信ブロックはクリアとして標識される。上記で論じられた実施形態によれば、２＋ｊクレジットの絶対クレジット返信カウントがこの時点で返信されるはずである（図示されない送信コンテキスト１の以前の全パケットのクレジットは先に返信されていると想定する）。しかしながら、クレジット返信機構の議論で下記に説明されるように、いくつかの実施形態において、クレジットは複数のパケットにわたって凝集され、最後のクレジット返信には到達していないので、クレジットの閾値までは返信されない。この例において、閾値にはまだ到達しておらず、その結果、この時点で返信されたクレジットはない。図８ｅに示される時間枠Ｔ_５の間、パケットＰ１−２およびＰ２−１の各々は放出を完了しており、クリアとして標識されているが、その一方でパケットＰ２−２は放出のために選択されており、放出を開始している。凝集されたクレジット返信は、一部の送信コンテキストのために採用されてもよいがその他のものには採用されないように、送信コンテキストごとに構成されてもよい。加えて、凝集クレジット閾値も送信コンテキストごとに構成されてもよい。したがって、この例において、送信コンテキスト１の凝集クレジット閾値に到達しており、このため２＋ｊ＋３のランニング返信クレジットカウント値がクレジット返信ブロック１２７を介して返信される。加えて、送信コンテキスト２は凝集クレジット閾値を採用しておらず、このため２クレジットのランニング返信クレジットカウント値が返信される。一実施形態において、複数の送信コンテキストのランニングクレジットカウント値は、単一のＤＭＡ書込みにおいてＰＣＩｅ上でメモリまで送信可能である。

【0063】

図９ａおよび図９ｂは、それぞれＳＦＥＮＣＥ命令ありおよびなしで６４ＢのＰＣＩｅポステッドライトを用いるパケットデータの転送に対応するデータフロータイムラインを示す。プロセッサコアの一部であるストアバッファ６０８からドレインされると、これはまず、図６ａおよび図６ｂに示されるように、ＩＩＯ６１０に転送される。本明細書において論じられるＰＣＩｅポステッドライト要求に加えてその他のＩＯ要求も扱う必要があるので、ＩＩＯにはいくつかの追加遅延がある。とりわけ、ＩＩＯは各ｓｆｅｎｃｅ命令のｓｆｅｎｃｅ確認（ａｃｋ；Ａｃｋｎｏｗｌｅｄｇｅｍｅｎｔ）を返信する。これにより、アウトオブオーダー命令がｓｆｅｎｃｅにわたって実行されるのを防止するが、その結果ｓｆｅｎｃｅに先立つパケットのすべての命令が実行されるまで遅延する可能性がある。ｓｆｅｎｃｅの使用を排除する本明細書の実施形態の下で、これら潜在的な遅延の発生は防止されており、ＰＩＯ送信ブロック書込み効率を最適化する。

【0064】

図１０は一実施形態による放出ブロック１２６のさらなる詳細を示す。（最大）１６０個の送信コンテキストの各々からのヘッドパケット状態はブロック１０００内で追跡され、その一方で１６個のＳＤＭＡ待ち行列の各々のヘッドパケット状態はブロック１００２内で追跡される。ブロック１０００および１００２は、複数のｐｅｒ−ＶＬ発信ＦＩＦＯ １００６への出力を提供するラウンドロビン発信アービタ１００４への入力を提供するが、その出力はＶＬアービタ１００８への入力として受信される。ＶＬアービタは、ＰＩＯ送信メモリ１２０およびＳＤＭＡメモリ１２４の各々に結合されたマルチプレクサ（Ｍｕｘ）１０１０への入力制御を提供する。放出ブロック１２６は、処理ブロック１０１２、１０１４、および１０１８、ならびに放出ＦＩＦＯ １０１６を、さらに含む。

【0065】

放出ブロック１２６は、１６０個の送信コンテキストおよび１６個のＳＤＭＡエンジンからのパケットの調停、ならびにその送信バッファメモリからｐｅｒ−ＶＬ発信ＦＩＦＯ １００６へ発信するための次の利用可能な完成パケットの選択を、担当する。ｐｅｒ−ＶＬ発信ＦＩＦＯは、ＶＬ間の遮断を最小限に抑えるために深くなっており、ＰＩＯ送信メモリ１２０およびＳＤＭＡメモリ１２４内のパケットに対するポインタを含むパケットの制御情報のみを包含する。実際のパケットデータパスはｐｅｒ−ＶＬ発信ＦＩＦＯ １００６内を流れるわけではなく、むしろこれらのＦＩＦＯはＶＬアービタ１００８へのｐｅｒ−ＶＬ入力を提供するために使用され、これは次に放出するパケットを選択するために発信ＦＩＦＯにわたってＶＬ調停を実行する。これにより放出ブロック１２６は、ｍｕｘ １０１０を介してＰＩＯ送信メモリ１２０またはＳＤＭＡメモリ１２４からそのパケットのデータをフェッチし始め、その後処理ブロック１０１２においてパケット整合性チェックが適用される。最後に、パケット放出パイプラインは、パケットに対していずれか必要な修正を実行し（たとえば、処理ブロック１０１４内のＨＣＲＣ／ＩＣＲＣ挿入、放出ＦＩＦＯ １０１６内のＦＩＦＯバッファリング、ならびに処理ブロック１０１８内の放出のためのＰＢＣ除去およびパケットフレーミング）、ファブリックポート１１２にパケットを提示する。

【0066】

一実施形態において、伝送エンジン１０８は、８つのデータＶＬおよび１つの管理ＶＬをサポートする。しかしながら、これは単なる例示に過ぎず、非限定的である。ＰＢＣヘッダ内のＶＬフィールドを用いてパケットが構築されたときに、パケットはソフトウェアによって仮想レーン（ＶＬ）に割り当てられる。

【0067】

一実施形態において、ＰＩＯ送信を用いて送信コンテキストに送信されたパケットは、送信コンテキストの送信バッファ内へのこれらパケットの配置によって定義される順序で発信される。これは「オリジナルプログラム順（ｏｒｉｇｉｎａｌ ｐｒｏｇｒａｍ ｏｒｄｅｒ）」と称される。本質的にこれは、プロセッサのライトコンバイニング機能によって提供される緩い順序付けセマンティックを用いるときでさえ、プログラムの元のパケット順を再構築するために送信バッファの充填において柔軟性があるとはいえ、送信バッファがＦＩＦＯとして振る舞うことを意味する。この順序付け議論の目的のため、要点は、ソフトウェアが送信コンテキスト上のパケット順を選択し、送信コンテキストはパケット発信を通じてこのパケット順を維持するということである。

【0068】

一旦完成パケットが送信バッファ内に充填されると、ＰＩＯ送信またはＳＤＭＡのいずれかにより、パケットは伝送エンジンによって発信可能となる。送信バッファからのパケットの発信は、パケットをｐｅｒ−ＶＬ ＦＩＦＯ上に配置する。同じＶＬを有するパケットの発信順は、そのＶＬを有するパケットがリンクに放出される順序を規定する。ｐｅｒ−ＶＬ ＦＩＦＯのヘッドにおけるパケットが選択される順序は、ＶＬ調停アルゴリズムによって決定される。

【0069】

なお、ソフトウェアは１つの送信コンテキスト上のＰＩＯ送信によって異なるＶＬを有するパケットを送信できることに、注意する。同様に、１つのＳＤＭＡ待ち行列上のＳＤＭＡによって異なるＶＬを有するパケットを送信することもできる。実施は、パケットが異なるＶＬ上にあったとしても、送信コンテキストまたはＳＤＭＡ待ち行列を通じて発信ポイントまでパケット順を維持することになる。しかしながら、発信を超えるとｐｅｒ−ＶＬ発信ＦＩＦＯのため保証される順序はなくなり、リンクへの実際の放出順はＶＬ調停の詳細に依存することになる。

【0070】

一実施形態の下で、同じＶＬを用いて伝送される同じ送信コンテキストのパケットは、オリジナルプログラム順で放出される。他方、異なるＶＬを用いて伝送されるパケットは、異なるＶＬ上で伝送される場合には後に書き込まれるパケットが先に書き込まれたパケットを続行させられるように、アウトオブオーダーで放出されてもよい。

【0071】

一実施形態において、ＨＦＩは、上記の定義された順序を超えた発信順に保証を提供しない。たとえば、いずれかのＳＤＭＡ待ち行列上のパケットの発信順は、その他いずれかのＳＤＭＡ待ち行列上のパケットに対して、またはＰＩＯ送信を用いて送信されるいずれかのパケットに対して、ＨＦＩによって順序付けされていない。加えて、いずれかの送信コンテキスト上のパケットの発信順は、その他いずれかの送信コンテキスト上のパケットに対して、またはＳＤＭＡを用いて送信されるいずれかのパケットに対して、ＨＦＩによって順序付けされていない。

【0072】

図１１は、ＨＦＩに結合されたファブリックリンク上のアウトバウンド放出のためにパケットデータを準備する際に実施される動作、段階、および状態を示すフローチャートである。パケット充填段階１１０２の間、送信メモリは、ＰＩＯ送信またはＳＤＭＡ機構のいずれかを介してパケットデータで充填されている。パケット完了状態１１０４は、パケットデータのすべてが送信メモリ内に格納されたときに発生する。この時点で、パケット充填は完了しており、パケットは発信可能である。パケット発信１１０６は、パケットが送信メモリからｐｅｒ−ＶＬ発信ＦＩＦＯ上に発信される時点である。この段階の間、パケットデータはまだ送信バッファ状態を占有しているが、しかし発信時にパケットはもう放出準備が整っており、この同じＶＬ上のその他のパケットに対するその順序は確立されている。

【0073】

パケットＶＬ調停１１０８の間、ｐｅｒ−ＶＬ発信ＦＩＦＯのヘッドにあるパケットはその間で調停され、１つがリンクに放出されるようにＶＬ調停アルゴリズムによって選択される。パケット放出１１１０の間、ＶＬ調停を介して選択されたパケットのパケットデータが送信メモリ（該当すれば、ＰＩＯ送信メモリ１２０またはＳＤＭＡメモリ１２４）から読み取られ、パケットデータが有効か否かを判断するためにパケット整合性チェックがブロック１０１２で実行される。整合性チェックに合格しなかったパケットは落とされ、その一方で良品パケットはリンクに放出されるが、これは必要であればＨＣＲＣおよびＩＣＲＣの挿入、および放出ＦＩＦＯ １０１６内のバッファリングを含んでもよい。

【0074】

次の状態は、パケットクリア１１１２である。この状態は、パケットが送信バッファをクリアにして送信バッファが再利用に入手可能となったときに、発生する。したがって、返信クレジットブロック１１１４において、送信バッファの１つ以上のクレジットがクレジット返信機構１２７を介して返信され、クリア送信ブロックは新しいパケットデータで充填されるために利用可能となる。しかしながら、パケット全体がリンクに放出されてしまう前にいくつかの送信ブロックが再利用され得るように、実施によってクレジット返信および送信バッファ再利用を送信ブロックレベルにまで最適化できることに、注意する。これは、送信バッファリソースが限られている重要な実施となり得る。加えて、上記で説明されたように、送信ブロックはクリアにされたものの、クリアになったＦＩＦＯ内でその下にその他の送信ブロックがある場合、そのブロックのクレジットは、これらのブロックもまたクリアにされるまで返信されない。

【0075】

クレジット返信機構
送信バッファをクリアにする先のパケットの前に送信バッファブロックがソフトウェアによって上書きされないことを保証するために、ＰＩＯ送信機構はクレジット返信機構を使用する。一実施形態において、送信クレジットは６４Ｂの粒度であり、１つの送信クレジットは１つの（６４Ｂ）送信ブロックに対応する。送信コンテキスト用の送信クレジットは順序通りに返信され、ソフトウェアは送信バッファメモリをラップアラウンドＦＩＦＯのやり方で使用する。ＨＦＩが送信クレジットの損失を伴わずにより最新の値でいつでもクレジット返信情報を上書きできるように、送信クレジット会計は絶対数を用いる。クレジット返信はまた状態情報も提供し、これは連続するクレジット返信書込みによって上書きされる。エラーに遭遇すると、クレジット返信はエラー表示で強制的に設定され、送信コンテキストはエラー状態に置かれて、さらなるクレジット返信書込みは送信コンテキストがホストシステムソフトウェアによってエラー状態から回復させられるまでスケジューリングされない。これにより、クレジット返信位置におけるエラー表示が観察されて、上書きの危険性を伴わずにホストソフトウェアによって適切に対処されることを、保証する。

【0076】

簡単に言うと、クレジット追跡は、消費されたクレジットの数のランニングカウントおよびフリーになったクレジットの数のランニングカウントを維持することによって達成される。すると、現在占有されているクレジットの数は、これらのカウントの間の差分となる。上述のように、これらはクレジットが消費またはフリーになったとき適切に単純増加する、絶対カウンタである。

【0077】

初期化の後、送信バッファは空になり、そのバッファ用のすべての送信クレジットはソフトウェアによって利用可能となる。一実施形態において、送信コンテキストに割り当て可能な送信クレジットの最大数は１０２４であり、送信バッファの６４ＫＢ最大サイズに対応する。一実施形態において、クレジット情報を追跡するために１１ビットカウンタが使用される。このアプローチは、カウンタがフルの１０２４値だけ異なる値となれるように、１つ余分なビットを使用する。これにより、０クレジットが利用可能であって１０２４クレジットが利用可能であるケースの曖昧さも解消される。カウンタ数学は、法２０４８で実行される。たとえば、１１ビットカウンタの前進および１１ビットカウンタ間の差は、法２０４８で実行される。

【0078】

より詳細には、ソフトウェアおよびハードウェアはいずれも、クレジット使用を追跡するために送信コンテキストごとに１１ビットカウンタを維持する。ソフトウェアカウンタは、フィルカウンタと称される。ハードウェアカウンタは、フリーカウンタと称される。ソフトウェアがクレジット返信の視認性を有するように、ハードウェアＤＭＡはそのカウンタ値を適切な間隔で、ホストメモリ内に保持されるシャドウフリーカウンタへ。最初に、両方のカウンタは０であり、使用中の送信クレジットはない。使用済みクレジットの数は、法２０４８で、フィルカウンタからフリーカウンタを減じたものとして計算される。すると利用可能なクレジットの数は、送信コンテキスト内のクレジットの総数から使用済みクレジットの数を減じたものとなる。両方のカウンタが同じ値を有するとき、コンテキストは空であり、その送信クレジットはすべてソフトウェアが充填するために利用可能である。ソフトウェアは、送信ブロックを送信コンテキストに書き込む前に、利用可能なクレジットをチェックする。ソフトウェアが送信ブロックを充填する際に、ソフトウェアが現在どの程度クレジットを使用したかを示すために、法２０４８でそのフィルカウンタを増分する。ソフトウェアが利用可能なクレジットを有していないとき、クレジットがフリーになるまで待機する。ソフトウェアは、クレジットがフリーになったときを判断するために、ホストメモリ内のシャドウフリーカウンタを監視することができる。

【0079】

クレジット追跡の抽象モデルに対応する擬似コードが、以下に示される。

【0080】

擬似コードリスト１
ｃｌａｓｓ ＳｅｎｄＢｕｆｆｅｒ：
ｄｅｆ＿ｉｎｉｔ＿（ｓｅｌｆ，ｎｕｍ＿ｃｒｅｄｉｔｓ）：
ａｓｓｅｒｔ（ｎｕｍ＿ｃｒｅｄｉｔｓ＞＝１ ａｎｄ ｎｕｍ＿ｃｒｅｄｉｔｓ＜＝１０２４）
ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ＝ｎｕｍ＿ｃｒｅｄｉｔｓ
ｓｅｌｆ．ｆｉｌｌ＿ｃｏｕｎｔｅｒ＝０
ｓｅｌｆ．ｆｒｅｅ＿ｃｏｕｎｔｅｒ＝０
ｓｅｌｆ．ｆｉｌｌ＿ｉｎｄｅｘ＝０
ｓｅｌｆ．ｅｇｒｅｓｓ＿ｉｎｄｅｘ＝０
ｓｅｌｆ．ｐａｃｋｅｔ＿ｃｒｅｄｉｔｓ＝［］
ｆｏｒ ｉ ｉｎ ｘｒａｎｇｅ（０，ｎｕｍ＿ｃｒｅｄｉｔｓ）：
ｓｅｌｆ．ｐａｃｋｅｔ＿ｃｒｅｄｉｔｓ．ａｐｐｅｎｄ（０）
ｄｅｆ ｇｅｔ＿ｎｕｍ＿ｃｒｅｄｉｔｓ（ｓｅｌｆ）：
ｒｅｔｕｒｎ ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ
ｄｅｆ ｇｅｔ＿ｕｓｅｄ＿ｃｒｅｄｉｔｓ（ｓｅｌｆ）：
ｒｅｔｕｒｎ（ｓｅｌｆ．ｆｉｌｌ＿ｃｏｕｎｔｅｒ−ｓｅｌｆ．ｆｒｅｅ＿ｃｏｕｎｔｅｒ）％２０４８
ｄｅｆ ｇｅｔ＿ｆｒｅｅ＿ｃｒｅｄｉｔｓ（ｓｅｌｆ）：
ｒｅｔｕｒｎ ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ−ｓｅｌｆ．ｇｅｔ＿ｕｓｅｄ＿ｃｒｅｄｉｔｓ（）
ｄｅｆ ｆｉｌｌ＿ｃｒｅｄｉｔｓ（ｓｅｌｆ，ｎｕｍ＿ｃｒｅｄｉｔｓ）：
＃Ｉｆ ｔｈｅｒｅ ｉｓ ｓｕｆｆｉｃｉｅｎｔ ｓｐａｃｅ，ｔｈｉｓ ｍｅｔｈｏｄ ｆｉｌｌｓ ｔｈｅ ｓｅｎｄ ｂｕｆｆｅｒ
＃ｗｉｔｈ ｎｕｍ＿ｃｒｅｄｉｔｓ ａｎｄ ｒｅｔｕｒｎｓ Ｔｒｕｅ．Ｏｔｈｅｒｗｉｓｅ，ｉｔ ｒｅｔｕｒｎｓ Ｆａｌｓｅ．（十分なスペースがあれば、この方法でｎｕｍ＿ｃｒｅｄｉｔｓを用いて送信バッファを充填し、Ｔｒｕｅを返す。またはＦａｌｓｅを返す。）
ａｓｓｅｒｔ（ｎｕｍ＿ｃｒｅｄｉｔｓ＞０）
ｆｒｅｅ＿ｃｒｅｄｉｔｓ＝ｓｅｌｆ．ｇｅｔ＿ｆｒｅｅ＿ｃｒｅｄｉｔｓ（）
ｉｆ ｎｕｍ＿ｃｒｅｄｉｔｓ＜＝ｆｒｅｅ＿ｃｒｅｄｉｔｓ：
ｓｅｌｆ．ｐａｃｋｅｔ＿ｃｒｅｄｉｔｓ［ｓｅｌｆ．ｆｉｌｌ＿ｉｎｄｅｘ］＝ｎｕｍ＿ｃｒｅｄｉｔｓ
ｓｅｌｆ．ｆｉｌｌ＿ｉｎｄｅｘ＝（ｓｅｌｆ．ｆｉｌｌ＿ｉｎｄｅｘ＋ｎｕｍ＿ｃｒｅｄｉｔｓ）％ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ
ｓｅｌｆ．ｆｉｌｌ＿ｃｏｕｎｔｅｒ＝（ｓｅｌｆ．ｆｉｌｌ＿ｃｏｕｎｔｅｒ＋ｎｕｍ＿ｃｒｅｄｉｔｓ）％２０４８
ｐｒｉｎｔ ‘Ｂｕｆｆｅｒ（％ｄ ｕｓｅｄ，％ｄ ｆｒｅｅ）：ｆｉｌｌｅｄ ％ｄ ｃｒｅｄｉｔｓ’％＼
（ｓｅｌｆ．ｇｅｔ＿ｕｓｅｄ＿ｃｒｅｄｉｔｓ（），ｓｅｌｆ．ｇｅｔ＿ｆｒｅｅ＿ｃｒｅｄｉｔｓ（），ｎｕｍ＿ｃｒｅｄｉｔｓ）
ｒｅｔｕｒｎ Ｔｒｕｅ
ｅｌｓｅ：
ｒｅｔｕｒｎ Ｆａｌｓｅ
ｄｅｆ ｆｒｅｅ＿ｃｒｅｄｉｔｓ（ｓｅｌｆ）：
＃Ｉｆ ｔｈｅｒｅ ｉｓ ａ ｐａｃｋｅｔ ｔｏ ｅｇｒｅｓｓ，ｔｈｉｓ ｍｅｔｈｏｄ ｅｇｒｅｓｓｅｓ ｔｈａｔ ｐａｃｋｅｔ，ｆｒｅｅｓ
＃ｉｔｓ ｃｒｅｄｉｔｓ ａｎｄ ｒｅｔｕｒｎｓ ａ ｖａｌｕｅ ｉｎｄｉｃａｔｉｎｇ ｔｈａｔ ｎｕｍｂｅｒ ｏｆ ｃｒｅｄｉｔｓ．（放出するパケットがあれば、この方法でそのパケットを放出し、そのクレジットをフリーにし、そのクレジット数を示す値を返す。）
＃Ｏｔｈｅｒｗｉｓｅ，ｉｔ ｒｅｔｕｒｎｓ Ｆａｌｓｅ．（またはＦａｌｓｅを返す）
ｎｕｍ＿ｃｒｅｄｉｔｓ＝ｓｅｌｆ．ｐａｃｋｅｔ＿ｃｒｅｄｉｔｓ［ｓｅｌｆ．ｅｇｒｅｓｓ＿ｉｎｄｅｘ］
ｉｆ ｎｕｍ＿ｃｒｅｄｉｔｓ：
ｓｅｌｆ．ｐａｃｋｅｔ＿ｃｒｅｄｉｔｓ［ｓｅｌｆ．ｅｇｒｅｓｓ＿ｉｎｄｅｘ］＝０
ｓｅｌｆ．ｅｇｒｅｓｓ＿ｉｎｄｅｘ＝（ｓｅｌｆ．ｅｇｒｅｓｓ＿ｉｎｄｅｘ＋ｎｕｍ＿ｃｒｅｄｉｔｓ）％ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ
ｓｅｌｆ．ｆｒｅｅ＿ｃｏｕｎｔｅｒ＝（ｓｅｌｆ．ｆｒｅｅ＿ｃｏｕｎｔｅｒ＋ｎｕｍ＿ｃｒｅｄｉｔｓ）％２０４８
ｐｒｉｎｔ ‘Ｂｕｆｆｅｒ（％ｄ ｕｓｅｄ，％ｄ ｆｒｅｅ）：ｒｅｔｕｒｎｅｄ ％ｄ ｃｒｅｄｉｔｓ’ ％＼
（ｓｅｌｆ．ｇｅｔ＿ｕｓｅｄ＿ｃｒｅｄｉｔｓ（），ｓｅｌｆ．ｇｅｔ＿ｆｒｅｅ＿ｃｒｅｄｉｔｓ（），ｎｕｍ＿ｃｒｅｄｉｔｓ）
ｒｅｔｕｒｎ ｎｕｍ＿ｃｒｅｄｉｔｓ
ｄｅｆ ｓｈｏｗ（ｓｅｌｆ）：
ｐｒｉｎｔ ‘Ｂｕｆｆｅｒ ％ｄ ｕｓｅｄ，％ｄ ｆｒｅｅ，％ｄ ｔｏｔａｌ’％＼
（ｓｅｌｆ．ｇｅｔ＿ｕｓｅｄ＿ｃｒｅｄｉｔｓ（），ｓｅｌｆ．ｇｅｔ＿ｆｒｅｅ＿ｃｒｅｄｉｔｓ（），ｓｅｌｆ．ｎｕｍ＿ｃｒｅｄｉｔｓ）
ｉｍｐｏｒｔ ｒａｎｄｏｍ
ｓｅｎｄ＿ｂｕｆｆｅｒ＝ＳｅｎｄＢｕｆｆｅｒ（１００）ｓｅｎｄ＿ｂｕｆｆｅｒ．ｓｈｏｗ（）
ｐａｃｋｅｔ＿ｆｉｆｏ＝［］
ｃｏｕｎｔ＝０
ｗｈｉｌｅ ｃｏｕｎｔ＜１００：
ｉｆ ｒａｎｄｏｍ．ｒａｎｄｏｍ（）＞＝０．２５：
ｆｉｌｌ＝ｉｎｔ（ｒａｎｄｏｍ．ｕｎｉｆｏｒｍ（ｌ，２０））
ｗｈｉｌｅ ｎｏｔ ｓｅｎｄ＿ｂｕｆｆｅｒ．ｆｉｌｌ＿ｃｒｅｄｉｔｓ（ｆｉｌｌ）：
ｃｒｅｄｉｔｓ＝ｓｅｎｄ＿ｂｕｆｆｅｒ．ｆｒｅｅ＿ｃｒｅｄｉｔｓ（）ａｓｓｅｒｔ（ｃｒｅｄｉｔｓ）
ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ＝ｐａｃｋｅｔ＿ｆｉｆｏ．ｐｏｐ（０）ａｓｓｅｒｔ（ｃｒｅｄｉｔｓ＝＝ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ）ｐａｃｋｅｔ＿ｆｉｆｏ．ａｐｐｅｎｄ（ｆｉｌｌ）ｃｏｕｎｔ＋＝１
ｅｌｓｅ：
ｃｒｅｄｉｔｓ＝ｓｅｎｄ＿ｂｕｆｆｅｒ．ｆｒｅｅ＿ｃｒｅｄｉｔｓ（）ｉｆ ｃｒｅｄｉｔｓ：
ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ＝ｐａｃｋｅｔ＿ｆｉｆｏ．ｐｏｐ（０）ａｓｓｅｒｔ（ｃｒｅｄｉｔｓ＝＝ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ）
ｐｒｉｎｔ ‘Ｔｏｔａｌ ｏｆ ％ｄ ｐａｃｋｅｔｓ ｆｉｌｌｅｄ ｗｉｔｈ％ｄ
（ｃｏｕｎｔ，ｌｅｎ（ｐａｃｋｅｔ＿ｆｉｆｏ））
ｐｒｉｎｔ ‘Ａｌｌ ％ｄ ｐａｃｋｅｔｓ ｐｏｓｔｅｄ，ｎｏｗ ｄｒａｉｎｉｎｇ ｗｈｉｌｅ Ｔｒｕｅ：
ｃｒｅｄｉｔｓ＝ｓｅｎｄ＿ｂｕｆｆｅｒ．ｆｒｅｅ＿ｃｒｅｄｉｔｓ（）ｉｆ ｃｒｅｄｉｔｓ：
ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ＝ｐａｃｋｅｔ＿ｆｉｆｏ．ｐｏｐ（０）
ａｓｓｅｒｔ（ｃｒｅｄｉｔｓ＝ｅｘｐｅｃｔｅｄ＿ｃｒｅｄｉｔｓ）ｅｌｓｅ：
ｂｒｅａｋ
ｐｒｉｎｔ ‘Ｔｏｔａｌ ｏｆ ％ｄ ｐａｃｋｅｔｓ ｆｉｌｌｅｄ ｗｉｔｈ％ｄ（ｃｏｕｎｔ，ｌｅｎ（ｐａｃｋｅｔ＿ｆｉｆｏ））
一実施形態において、消費されるＰＣＩｅおよびホストメモリ帯域幅を低減するために、送信クレジット返信が凝集される。各送信コンテキストは、ＳｅｎｄＣｔｘｔＣｒｅｄｉｔＣｔｒｌ．Ｔｈｒｅｓｈｏｌｄと称されるクレジット閾値を用いてプログラムされる。送信コンテキストは、まだファブリックに放出されていない最も古い送信ブロック（送信バッファ内のアドレス順で）を追跡するカウンタ値を保持する。先に論じられたように、単一の送信バッファ内で複数のＶＬが使用されるとき、送信ブロックの放出はアウトオブオーダーであってもよい。この状況を解決するために、順序通りのクレジット返信が提供可能となるように、アウトオブオーダー放出を追跡するためのハードウェア状態が採用される。この最も古い送信ブロックのカウンタからフリーカウンタのハードウェアコピーを減じた差分は、まだソフトウェアに返信されていない保留のフリークレジットの数である。この値が閾値と一致またはこれを超過するとき、この送信コンテキストのための送信クレジット返信が開始される。

【0081】

このクレジット返信アプローチは、ハードウェアの中にある閾値にクレジットを任せ、すべてのクレジットが返信され得ると保証する方法を提供するものではない。これは、いずれか特定の送信が送信バッファをクリアにしたことを識別するためには問題である。これを解決するために提供される方法は、いくつかある：
・多くの場合、ホストソフトウェアは、クレジット返信閾値機構を使用することができ、特定のＰＩＯ送信が送信バッファをクリアにしたか否かを問題にしない。
・ホストは、ＳｅｎｄＣｔｘｔＣｒｅｄｉｔＳｔａｔｕｓレジスタを用いてアダプタレジスタから送信コンテキスト用の現在のクレジット値を読み取ることができる。
・ホストは、クレジット返信を送信コンテキスト向けに強制的にスケジュールさせるために、ＳｅｎｄＣｔｘｔＣｒｅｄｉｔＦｏｒｃｅレジスタに書き込むことができる。
・ＰｂｃＣｒｅｄｉｔＲｅｔｕｒｎと称されるＰＢＣビットを介して特定のＰＩＯ送信用のクレジット返信をホストが要求できるようにする。

【0082】

加えて、ホストソフトウェアは、クレジットが特定の送信コンテキスト上で返信されたとき、中断を手配することができる。

【0083】

いくつかの実施形態において、パケットが放出するように確約されるとすぐに、しかしパケットが実際に送信バッファをクリアにしてしまう前に、クレジットをより積極的にホストに返信させる、早期クレジット返信機構が実現されてもよい。これにより、クレジット返信遅延を最適化して送信バッファリング要件を減少させるために、ホストは次のパケットに取りかかることができる。考え方としては、放出がその前の占有者用の送信バッファをドレインしている間に、ホストが次のパケットの充填を開始できることである。前のパケットが上書きされ得ないことを保証するためにハードウェアインターロックが採用され、また、前のパケットがファブリックワイヤ速度でドレインされるように、レートマッチング放出ＦＩＦＯも実施される。この機構は、実施問題の場合に、コンテキストごとに無効化されることが可能である。これは、コンテキストごとの送信クレジットが低いとき（たとえば、多数のコンテキストおよびさらに大きいＭＴＵサイズを使用するとき）、性能の向上にとって重要な最適化である。

【0084】

早期クレジット返信を有効化または無効化するために、送信コンテキストごとの構成ビット（ＳｅｎｄＣｔｘｔＣｒｅｄｉｔＣｔｒｌ．ＥａｒｌｙＲｅｔｕｒｎ）が提供される。有効化されると、個々の送信ブロックはハードウェアによって早期に（すなわち、その送信ブロックをクリアにするパケットの放出に先立って）フリーにされることが可能であり、これら早期にフリーになったクレジットは通常のクレジット返信アルゴリズムを用いて返信される。クレジット返信閾値機構はまだ適用されている。

【0085】

なお、ソフトウェアは、送信したいパケット用の送信コンテキストに割り当てられたクレジットが十分にあることを保証するためのものであることに、注意する。特定のパケット用の送信コンテキストに割り当てられたクレジットが十分にない場合には、パケットを発信するために利用できる十分なクレジットには決してならない。アプローチの１つは、送信コンテキストに割り当てられた送信ブロックの数に基づいてソフトウェアがパケットサイズを制限することである。この計算は、コンテキスト用のクレジット閾値までのクレジットがハードウェアの中にあり、将来の送信ブロックが放出されるまで自動的に返信されないということを、考慮すべきである。

【0086】

一実施形態において、送信クレジット返信は、６４Ｂキャッシュライン整列アドレスへのホストメモリへの６４Ｂ書込みとして実施される。この理由は、これらの動作はさらなる遅延を追加し、ホストメモリへのアクセスのパイプラインに影響を及ぼす可能性があるので、ＩＩＯからのメモリ上での読み出し・修正・書込み動作を回避するためである。しかしながらこれは、クレジット返信が付加的なＰＣＩｅ帯域幅を消費することを意味する。これは送信クレジット返信集合によって緩和されるものの、可能であればこれをさらに低減することが望ましい。一実施形態において、これは以下に記載されるように、送信コンテキストグループにわたる凝集クレジットの使用を介して促進される。

【0087】

一実施形態において、各１１ビットクレジット返信値は、コンテキスト状態と組み合わせられ、６４ビット値にするために確保されたビットが詰め込まれる。一実施形態において、６４ビット値は、グループクレジット返信のための６４Ｂ書込みに詰め込まれるクレジット返信を、最大８つまでサポートする。

【0088】

クレジット返信オーバーヘッドを削減する１つの技術は、送信コンテキストグループにわたってクレジット返信を凝集することである。考え方としては、送信コンテキストはグループにまとめられることが可能であり、その後ホストメモリへの単一の６４Ｂ書込みを用いてコンテキストのグループ用のクレジット返信が実行されるということである。一実施形態において、１６０個の送信コンテキストは、８つの連続する送信コンテキストのセットに凝集され、合計２０セットできる。しかしながら、送信コンテキストのその他の凝集が使用されてもよい。

【0089】

８つの送信コンテキストのセットサイズにより、セットごとに独立したグループ化を特定する能力を有する２０個の異なるセットが可能になる。セット数Ｓは、送信コンテキスト８Ｓから８Ｓ＋７までを包含する。一実施形態のセットマッピングが、表２に示される。２０セットを選択すると、４０、８０、および１６０個の送信コンテキストの典型的な構成における妥当な柔軟性が付与される。より少ない数の送信コンテキストでの構成においては、ソフトウェアは、必要とされるグループ化に応じてどの送信コンテキストを使用するか選択するときの、さらなる柔軟性を得る。各セットは、表３に示される構成となるように、独立して構成されることが可能である。

【0090】

【表2】

【0091】

【表3】

最小値０では、セットはグループごとに１個の送信コンテキストで８つのグループを有する（すなわち、実際のグループ化はない）。そのセット内のいずれの送信コンテキストも独立したクレジット返信を有することになるので、これにより完全な柔軟性を与える。最大値の３であれば、セットは８つすべての送信コンテキストを包含する１グループを有し、クレジット返信は８つすべての送信コンテキストのために凝集される。したがって、そのセットのクレジット返信のために使用されるホストメモリページは、これら８つの送信コンテキストによって共有される。なお、ソフトウェアはクレジット返信位置に書込みをしないので、そのページの読み取り専用マッピングのみが必要とされることに、注意する。最大グループサイズ８は、これら８つの送信コンテキストのクレジット返信アルゴリズムが互いにどのように相互作用するかに応じて、クレジット返信帯域幅を最大８倍まで減少させる。

【0092】

各送信コンテキストは、その送信コンテキスト用のクレジット返信に使用されるホスト物理アドレスおよびＴＰＨ情報を規定する、ＳｅｎｄＣｔｘｔＣｒｅｄｉｔＲｅｔｕｒｎＡｄｄｒレジスタを有する。送信コンテキストグループ化が用いられるとき、クレジット返信は、クレジット返信をトリガしたコンテキストに属するＳｅｎｄＣｔｘｔＣｒｅｄｉｔＲｅｔｕｒｎＡｄｄｒレジスタを使用する。一実施形態において、同じアドレスを有するグループ内のすべてのコンテキストのＳｅｎｄＣｔｘｔＣｒｅｄｉｔＲｅｔｕｒｎＡｄｄｒレジスタをプログラムするために、ソフトウェアが使用される。

【0093】

特定の送信コンテキスト（Ｎで表す）によってクレジット返信が開始されるとき、送信コンテキストは、送信コンテキスト番号を３つ右シフトすることによってセット数（Ｓ）にマッピングされる。セット数は、セットごと構成状態を調べるために使用され、表３の左端の列に示されるように値Ｂを付与する。Ｂは、同じグループ内の送信コンテキストを区別する送信コンテキスト番号の、最も重要ではないビットの番号である。そのグループ内の送信コンテキストの数はＧであって１＜＜Ｂに等しく、表３の右端の列の値を取る。このセットで最も小さい送信コンテキスト番号はＭと呼ばれて値（Ｎ＞＞Ｂ）＜＜Ｂを有し、これは最も重要ではないＢビットがクリアされたＮの値である。

【0094】

一実施形態において、クレジット返信は以下のように実現される。クレジット返信は、１つの６４Ｂ書込みを用いてＧ個の送信コンテキストのために凝集される。返信用のアドレスは、コンテキスト番号Ｍ（グループ内で最も小さい番号のコンテキスト）についてＳｅｎｄＣｔｘｔＣｒｅｄｉｔＲｅｔｕｒｎＡｄｄｒレジスタ内で規定され、その一方でこのクレジット返信用のＧ個の送信コンテキストにはＭからＭ＋Ｇ−１までの番号が付される。グループ内の各送信コンテキストのクレジット情報はＱＷであり、Ｇは６４Ｂクレジット返信書込みに詰め込まれるような値である。範囲［０，Ｇ−１］内のＩについては、返信されているクレジットは送信コンテキスト番号Ｍ＋Ｉのためであり、クレジットは指数（Ｍ＋１）＆０×７を有するＱＷの中に配置される。このため指数は送信コンテキスト番号の最も小さい３ビットによって簡単に指定され、Ｇの値にかかわらず、いずれか特定の送信コンテキストのクレジット返信値は６４Ｂクレジット返信値の中でいつも同じ位置にあり、実施におけるシフト動作をなくしている。クレジット返信値の中の未使用のＱＷは０×０の値で満たされる。

【0095】

クレジット返信値のすべての組み合わせは、表４にまとめられている。６４Ｂクレジット返信となる異なる指数値には８つの列がある。指数０はバイト０から７に対応し、指数１はバイト８から１５に対応する、などである。各行は、その特定のＧの値（グループごとの送信コンテキストの数である）のクレジット返信値の１つの組み合わせを表す。空白のセルは未使用のＱＷを示し、これらはゼロ値を有する。表記ＣＲｘ（ｘは０から７に含まれる）は、ｘに等しい少なくとも３つの有効ビットを有するコンテキスト用のクレジット返信値を示す。各ＣＲｘＱＷ値は、表２で定義されたフォーマットを有する。たとえば、Ｇは１であるとき、１つのクレジット返信値があり、送信コンテキスト番号に応じて８つの位置のうちの１つとなる。Ｇが８のときは、８つのクレジット返信値があり、８つすべての位置が使用される。

【0096】

【表4】

クレジットが送信コンテキストグループのために返信されると、グループ内の各送信コンテキスト用のフリーカウンタは、ホストメモリ内に保持されるシャドウコピーに転送されたＤＭＡであるクレジットカウンタ値に更新される。このアプローチは、ある送信コンテキストがその閾値に基づいてグループのクレジット返信をトリガしたときに、そのクレジット返信は最大可能な限りそのグループ内のその他すべての送信コンテキストに提供されることを、意味する。このアプローチは、送信ブロック放出がグループのメンバー全体に対して妥当にインターリーブされることを前提として、全体的にグループの送信クレジット更新の頻度を減少させる。なお、閾値は、この機構を有効にするためには最大パケット内の送信ブロックの数よりも大きくなければならないことに、注意する。

【0097】

図１２は、一実施形態による、絶対クレジットを用いてＰＩＯ書込み管理をサポートするために使用される、ＰＩＯ送信アドレスＦＩＦＯ １４００およびクレジット返信ＦＩＦＯ １４０２の例示的な構成を示す。ＰＩＯ送信アドレスＦＩＦＯ １４００は、ＰＩＯ送信メモリ書込みを生成したソフトウェアの管理の下で、メモリ１０６内の各送信コンテキストのために実施される。先に論じられたように、一実施形態において、（各送信コンテキスト内の利用可能な送信ブロックに対応する）利用可能なクレジットを追跡するために、１１ビットランニングカウンタがＦＩＦＯセマンティックスと組み合わせて使用される。命令に値する各送信ブロックが生成されてプロセッサコアによる実行のために転送される際に、ソフトウェアは、送信ブロックが書き込まれることになる送信コンテキストのランニングカウントを増加させる。他方、受信側では、クレジット返信機構１２７は、返信された絶対クレジットの１１ビットランニングカウントを保持する。クレジットが返信される際に、ランニングカウントが進む。ＦＩＦＯは、カウントが２０４７に到達すると０に戻される、円形ＦＩＦＯセマンティックスを使用する。ソフトウェアはまた、各送信コンテキストの絶対返信クレジットの追跡も続ける。送信絶対ランニングカウントと返信絶対ランニングカウントとの差が送信コンテキストのサイズ未満である限りにおいて、ソフトウェアは追加のＰＩＯ送信メモリ書込みを生成することができる。差が送信コンテキストのサイズに到達してしまうと、更新された絶対ランニングカウントがクレジット返信機構１２７を介して受信されるまで、送信コンテキストへのパケットデータの書込みは中断される。
例示的なＨＦＩ実施アーキテクチャ
図１３は、プロセッサ１３０６に結合されたファブリックポート１１２を含むホストファブリックインタフェース１０２を備える例示的な構成を有するシステムノード１３００を示し、これはまたメモリ１０６に結合されている。ファブリックポート１１２は、図１に示されるものと類似の高レベル構成を有する、伝送ポート１１０および受信ポート１１６を含む。伝送ポート１１０は、複数の伝送ＶＬバッファに分割された送信バッファ（Ｔｂｕｆ）を含むＴｘリンクファブリック副層回路および論理１３１０と、Ｔｘリンク転送副層回路および論理１３１２と、４つの送信器１３１６を含むＴｘ ＰＨＹ回路および論理１３１４と、Ｔｘリンク制御ブロック１３１７と、を含む。受信ポート１１６は、複数の受信ＶＬバッファに分割された受信バッファ（Ｒｂｕｆ）を含むＲｘリンクファブリック副層回路および論理１３１８と、Ｒｘリンク転送副層回路および論理１３２０と、４つの受信器１３２４を含むＲｘ ＰＨＹ回路および論理１３２２と、Ｒｘリンク制御ブロック１３２５と、を含む。

【0098】

Ｔｘ ＰＨＹ回路および論理１３１４は、４つの送信器１３１６およびＴｘリンク制御ブロック１３１７の一部を含む簡素化された形態で示されている。一般的に、送信器１３１６は、リンクのＰＨＹ層構成に応じて、電気または光学送信器を備えることができる。Ｔｘ ＰＨＹ回路および論理ブロックは、明確さのため図示されない伝送側ＰＨＹ層動作を実施するための追加回路および論理を含むことは、ネットワーク分野の当業者によって理解されるだろう。これは、エラーを低減して転送特性を強化するために、高速相互接続と併せて実施される様々な機能を促進するために使用される、ＰＨＹ層の中の様々な副層を含む。

【0099】

Ｒｘ ＰＨＹ回路および論理１３２２は、４つの受信器１３２４およびＲｘリンク制御ブロック１３２５の一部を含む簡素化された形態で示されている。一般的に、受信器１３２４は、リンクのＰＨＹ層構成に応じて、電気または光学送信器を備えることができ、送信器１３１６からのリンクを通じて送信された信号を受信するように構成される。Ｒｘ ＰＨＹ回路および論理ブロックは、明確さのため図示されない受信側ＰＨＹ層動作を実施するための追加回路および論理を含むことは、ネットワーク分野の当業者によって理解されるだろう。これは、エラーを低減して転送特性を強化するために、高速相互接続と併せて実施される様々な機能を促進するために使用される、ＰＨＹ層の中の様々な副層を含む。

【0100】

ＨＦＩ １３０２は、ＰＣＩｅインタフェース１１８に結合された伝送エンジン１０８および受信エンジン１１４を、さらに含む。伝送エンジン１０８および受信エンジン１１４の各々は、上述のような、図１の伝送エンジン１０８および受信エンジン１１４と類似のやり方で、構成されている。

【0101】

プロセッサ１３０６は、各々が統合されたレベル１およびレベル２（Ｌ１／Ｌ２）キャッシュを含み、コヒーレント相互接続１３３０に結合された、複数のプロセッサコア１３２８を含むＣＰＵ１３２６を含む。図示される実施形態において、ストアバッファ（Ｓｔ．Ｂｆ．）もまた各コア１３２８に結合されて示されている；選択的に、ストアバッファは、プロセッサ内のプロセッサコアのすべてまたは一部にわたって共有されてもよい。やはりコヒーレント相互接続１３３０に結合されているのは、メモリ１０６に結合されたメモリインタフェース１３３２と、統合入出力ブロック（ＩＩＯ）１３３４と、最終レベルキャッシュ（ＬＬＣ）１３３６である。ＩＩＯ １３３４は、プロセッサコア、メモリ、およびキャッシュによって採用されるコヒーレントドメインと、ＩＯコンポーネントおよびＩＯインタフェースのために採用される非コヒーレントドメインとの間に、１対のＰＣＩｅルートコンプレックス（ＲＣ）１３３８および１３４０を含む、インタフェースを提供する。当該技術分野において周知のように、ＰＣＩｅ ＲＣは、ＰＣＩｅインタフェース１３４２、１３４４、１３４６、および１３４８によって示されるように、複数のＰＣＩｅインタフェースおよびＰＣＩｅ装置が結合可能なＰＣＩｅ相互接続ヒエラルキーの頂点に座する。図示されるように、ＰＣＩｅ １３４４は、ＨＦＩ １０２のＰＣＩｅインタフェース１１８に結合されている。

【0102】

図１３に示されるものなど、いくつかの実施形態において、プロセッサ１３０６はＳｏＣアーキテクチャを採用する。別の実施形態では、ＰＣＩｅ関連コンポーネントが、プロセッサに結合されたＩＯチップセットなどに組み込まれている。さらに別の実施形態では、プロセッサ１３０６および１つ以上のＨＦＩ １０２が、たとえばＳｏＣ １３５０の囲み点線で示されるように、ＳｏＣ上に組み込まれている。また、図示されるように、第二のＨＦＩ １０２がＰＣＩｅインタフェース１３４６に結合されて示されており、囲み点線はこれが選択的な構成であることを示している。一実施形態において、図１４に示されるように、複数のＨＦＩはＡＳＩＣ（特定用途向け集積回路；Ａｐｐｌｉｃａｔｉｏｎ Ｓｐｅｃｉｆｉｃ Ｉｎｔｅｇｒａｔｅｄ Ｃｉｒｃｕｉｔ）１４００上に実装されてもよい。図１３にさらに示されるように、ソフトウェアアプリケーション１３５２は、プロセッサコア１３２８のうちの１つ以上で動作するソフトウェアコンポーネント、またはプロセッサ１３０６上で動作するオペレーティングシステムによってホストされる１つ以上の仮想マシンを備える。これらのソフトウェアコンポーネントに加えて、メモリ１０６（適用可能なキャッシュレベルを含む）と伝送エンジン１０８および受信エンジン１１４との間のデータ転送を容易にするために、メモリ１０６内に実装された追加ソフトウェアコンポーネントおよびバッファがある。

【0103】

本明細書に記載される対象内容のさらなる態様は、以下の箇条書きの節に明示される。

【0104】

１．メモリ内に格納されたそれぞれのパケット用のパケットデータをネットワークアダプタ上のＰＩＯ送信メモリに書き込むためのプログラム入力／出力（ＰＩＯ：Ｐｒｏｇｒａｍｍｅｄ Ｉｎｐｕｔ／Ｏｕｔｐｕｔ）書込み命令のシーケンスを受信するステップと、
ＰＩＯ書込み命令の前記シーケンスを、アウトオブオーダー実行をサポートするプロセッサ上の命令スレッドとして実行するステップであって、ＰＩＯ書込み命令の実行は、データをストアバッファ内のストアユニットに書き込ませ、ストアブロックにグループ分けされた前記ストアユニットは一列のストアユニットを備え；前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、結果的にデータは、前記ストアブロックが充填される前に異なるストアブロック内のストアユニットに書き込まれる、ステップと、
ストアブロックが充填されたときを検出するステップと、
ストアブロックが充填されたことの検出に応えて、前記ＰＩＯ送信メモリ内のバッファへのポステッドライトを介して前記ストアブロック内の前記データをドレインするステップと、
を備える方法。

【0105】

２．前記メモリは６４バイト（６４Ｂ）キャッシュラインを採用し、各ストアブロックは６４バイトのデータを備え、前記ポステッドライトは６４ＢのＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）ポステッドライトを備える、節１に記載の方法。

【0106】

３．前記プロセッサは６４ビットプロセッサを備え、各ストアユニットは、単一の命令を用いて前記プロセッサ内の６４ビットデータレジスタからストアユニットに書き込まれた６４ビットのデータを備える、節１または２に記載の方法。

【0107】

４．ＰＩＯ書込み命令の前記シーケンスは、それぞれのパケットごとに１つ以上の整列された６４Ｂ書込みの連続グループとして受信され、前記方法は、
パケットを生成するステップと、
前記パケットが６４バイトの倍数ではない長さを有すると判断するステップと、
６４バイトの倍数までその長さを伸長するために前記パケットにパディングを追加するステップと、
前記パケットデータを備えてパディングを含む１つ以上の整列された６４Ｂ書込みのシーケンスを備えるＰＩＯ書込み命令を生成するステップと、
を備える、節１から３のいずれかに記載の方法。

【0108】

５．前記プロセッサはライトコンバイニングを採用し、アウトオブオーダーＰＩＯ書込み命令の実行の結果、データは不連続順でストアブロック内のストアユニットに書き込まれる、節１から４のいずれかに記載の方法。

【0109】

６．前記ＰＩＯ送信メモリは複数の送信コンテキストに分割され、各送信コンテキストは送信ブロックのシーケンスとして構造化されており、前記方法は、
連続順で複数の連続する送信ブロックにパケットのデータを書き込むためのＰＩＯ書込み命令のシーケンスを受信するステップと、
不連続順で前記連続する送信ブロックに前記パケットの前記データを書き込むステップと、
を備える、節１から５のいずれかに記載の方法。

【0110】

７．前記複数の連続する送信ブロックのすべてが前記パケットデータで充填されたことを検出するステップと、
前記複数の送信ブロックのすべてが充填されてしまったら、前記複数の送信ブロック内のデータを放出できるようにするステップと、
をさらに備える、節６に記載の方法。

【0111】

８．プロセッサ上で実行されたときに、アウトオブオーダー実行をサポートする前記プロセッサを含むコンピュータに、節１から７のいずれかに記載の方法を実施させられるように構成された命令を格納する、非一時的機械読み取り可能媒体。

【0112】

９．メモリ内に格納されたそれぞれのパケット用のパケットデータをネットワークアダプタ上のＰＩＯ送信メモリに書き込むためのプログラム入力／出力（ＰＩＯ）書込み命令のシーケンスを受信するステップであって、各ＰＩＯ書込み命令は、前記データ、および前記データが書き込まれるＰＩＯ送信メモリ内の送信ブロックのメモリマップアドレスを包含するメモリ内のキャッシュラインの位置を定義する、ステップと、
ＰＩＯ書込み命令の前記シーケンスを、アウトオブオーダー実行をサポートするプロセッサ上の命令スレッドとして実行するステップであって、ＰＩＯ書込み命令の実行は、データをストアバッファ内のストアブロックに書き込ませ、前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、その結果、前記ＰＩＯ書込み命令が受信される順序とは異なる順序でデータがストアブロックに書き込まれる、ステップと、
ストアブロックが充填されたときを検出するステップと、
ストアブロックが充填されたことの検出に応えて、前記データを前記送信ブロックに書き込むために使用された前記ＰＩＯ書込み命令内に包含されるアドレスに位置する前記ＰＩＯ送信メモリ内の送信ブロックへのポステッドライトを介して前記ストアブロック内の前記データをドレインするステップと、
を備える方法。

【0113】

１０．前記ＰＩＯ書込み命令は５１２ビット書込み命令を備え、メモリキャッシュライン、ストアブロック、および送信ブロックの各々は６４バイトのサイズを有する、節９に記載の方法。

【0114】

１１．ポステッドライトは、６４バイト（６４Ｂ）ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）ポステッドライトを備える、節１０に記載の方法。

【0115】

１２．前記ＰＩＯ送信メモリを複数の送信コンテキストに分割するステップと、
任意のパケットのデータが１つ以上の連続する送信ブロックに格納される際の各送信コンテキスト用の先入先出（ＦＩＦＯ；Ｆｉｒｓｔ−ｉｎ，Ｆｉｒｓｔ−ｏｕｔ）格納スキームを採用するステップであって、同じ送信コンテキストに複数のパケットのパケットデータを書き込むためのＰＩＯ書込み命令は元のＦＩＦＯ順で連続的にグループ化され、前記複数のパケットの前記パケットデータは前記元のＦＩＦＯ順とは異なる順序で送信ブロックに書き込まれることが可能である、ステップと、
をさらに備える、節９から１１のいずれかに記載の方法。

【0116】

１３．前記１つ以上の連続する送信ブロックのすべてが任意のパケットについて前記パケットデータで充填されたことを検出するステップと、
一旦前記複数の送信ブロックが充填されたら、前記任意のパケットのデータが放出されることを可能にするステップと、
をさらに備える、節１２に記載の方法。

【0117】

１４．そのパケットに関連付けられたＶＬを識別するために使用される仮想レーン（ＶＬ）標識を用いて各パケット内のヘッダフィールドを符号化するステップと、
同じ送信コンテキスト内の異なるＶＬを有するパケットがＦＩＦＯ順とは関係なく放出されることを可能にするステップと、
同じ送信コンテキスト内の同じＶＬに関連付けられたパケットのデータの放出のためのＦＩＦＯ順を強制するステップと、
をさらに備える、節１３に記載の方法。

【0118】

１５．プロセッサ上で実行されたときに、アウトオブオーダー実行をサポートする前記プロセッサを含むコンピュータに、節８から１４のいずれかの方法を実施させられるように構成された命令を格納する、非一時的機械読み取り可能媒体。
１６．アウトオブオーダー実行をサポートし、メモリインタフェース、少なくとも１つのストアバッファ、および第一ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インタフェースを含む複数のプロセッサコアを有する、プロセッサと、
ＰＣＩｅ相互接続を介して前記プロセッサの前記第一ＰＣＩｅインタフェースに結合された、第二ＰＣＩｅインタフェースと、
前記第二ＰＣＩｅインタフェースに動作可能に結合され、プログラム入力／出力（ＰＩＯ）送信メモリを含む、伝送エンジンと、
を備える装置であって、前記プロセッサは、
前記メモリインタフェースに結合されたときにメモリ内に格納されたそれぞれのパケット用のパケットデータを前記ＰＩＯ送信メモリに書き込むためのプログラム入力／出力（ＰＩＯ）書込み命令のシーケンスを受信し、
ＰＩＯ書込み命令の前記シーケンスをプロセッサコア上の命令スレッドとして実行し、ＰＩＯ書込み命令の実行は、データをストアバッファ内のストアユニットに書き込ませ、ストアブロックにグループ分けされた前記ストアユニットは一列のストアユニットを備え；前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、結果的にデータは、前記ストアブロックが充填される前に異なるストアブロック内のストアユニットに書き込み、、
ストアブロックが充填されたときを検出し、
ストアブロックが充填されたことの検出に応えて、前記ＰＣＩｅ相互接続を通じて送信された前記ＰＩＯ送信メモリ内のバッファへのＰＣＩｅポステッドライトを介して前記ストアブロック内の前記データをドレインする、
回路および論理を含む、装置。

【0119】

１７．前記メモリは６４バイト（６４Ｂ）キャッシュラインを採用し、各ストアブロックは６４バイトのデータを備え、前記ポステッドライトは６４ＢのＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）ポステッドライトを備える、節１６に記載の装置。

【0120】

１８．前記プロセッサは６４ビットプロセッサを備え、各ストアユニットは、単一の命令を用いて前記プロセッサ内の６４ビットデータレジスタからストアユニットに書き込まれた６４ビットのデータを備える、節１６または１７に記載の装置。

【0121】

１９．前記プロセッサはライトコンバイニングを採用し、アウトオブオーダーＰＩＯ書込み命令の実行の結果、データは不連続順でストアブロック内のストアユニットに書き込まれる、節１６から１８のいずれかに記載の装置。

【0122】

２０．前記ＰＩＯ送信メモリは複数の送信コンテキストに分割され、各送信コンテキストは送信ブロックのシーケンスとして構造化されており、前記装置は、
連続順で複数の連続する送信ブロックにパケットのデータを書き込むためのＰＩＯ書込み命令のシーケンスを受信し、
不連続順で前記連続する送信ブロックに前記パケットの前記データを書き込む、
さらなる回路および論理を含む、節１６から１９のいずれかに記載の装置。

【0123】

２１．前記複数の連続する送信ブロックのすべてが前記パケットデータで充填されたことを検出し、
前記複数の送信ブロックのすべてが充填されてしまったら、前記複数の送信ブロック内のデータを放出できるようにする、
回路および論理をさらに備える、節２０に記載の装置。

【0124】

２２．前記パケットの長さを判断するために前記複数の連続する送信ブロックの１つ目の中のデータを検査し、
いくつの連続する送信ブロックが前記パケットのデータを格納するために採用されるべきかを判断する、
回路および論理をさらに備える、節２１に記載の装置。

【0125】

２３．アウトオブオーダー実行をサポートし、メモリインタフェース、少なくとも１つのストアバッファ、および第一ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インタフェースを含む、複数のプロセッサコアを有する、プロセッサと、
ＰＣＩｅ相互接続を介して前記プロセッサの前記第一ＰＣＩｅインタフェースに結合された、第二ＰＣＩｅインタフェースと、
前記第二ＰＣＩｅインタフェースに動作可能に結合され、プログラム入力／出力（ＰＩＯ）送信メモリを含む、伝送エンジンと、
を備える装置であって、前記プロセッサは、
メモリ内に格納されたそれぞれのパケット用のパケットデータを前記ＰＩＯ送信メモリに書き込むためのプログラム入力／出力（ＰＩＯ）書込み命令のシーケンスを受信するためであって、各ＰＩＯ書込み命令は、前記データが書き込まれる前記ＰＩＯ送信メモリ内の送信ブロックのデータおよびメモリマップアドレスを包含するメモリ内のキャッシュラインの位置を定義し、
ＰＩＯ書込み命令の前記シーケンスをプロセッサコア上の命令スレッドとして実行するためであって、ＰＩＯ書込みの実行は、データをストアバッファ内のストアブロックに書き込ませ、前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、結果的にデータは、前記ＰＩＯ書込み命令が受信される順とは異なる順序でストアブロックに書き込み、
ストアブロックが充填されたときを検出し、
ストアブロックが充填されたことの検出に応えて、前記データを送信ブロックに書き込むために使用された前記ＰＩＯ書込み命令に包含される前記アドレスに位置する前記ＰＩＯ送信メモリ内の前記送信ブロックへのＰＣＩｅポステッドライトを介して、前記ストアブロック内の前記データをドレインする、
回路および論理を含む、装置。

【0126】

２４．前記ＰＩＯ書込み命令は５１２ビット書込み命令を備え、メモリキャッシュライン、ストアブロック、および送信ブロックの各々は６４バイトのサイズを有し、前記ＰＣＩｅポステッドライトは６４バイトのＰＣＩｅポステッドライトを備える、節２３に記載の装置。

【0127】

２５．前記ＰＩＯ送信メモリを複数の送信コンテキストに分割し、
任意のパケットのデータが１つ以上の連続する送信ブロックに格納される際の各送信コンテキスト用の先入先出（ＦＩＦＯ；Ｆｉｒｓｔ−ｉｎ，Ｆｉｒｓｔ−ｏｕｔ）格納スキームを実施し、
前記１つ以上の連続する送信ブロックのすべてが任意のパケットのパケットデータで充填されたことを検出し、
一旦前記複数の送信ブロックが充填されたら、前記任意のパケットのデータが放出されることを可能にする、
回路および論理をさらに備え、
同じ送信コンテキストに複数のパケットのパケットデータを書き込むためのＰＩＯ書込み命令は元のＦＩＦＯ順で連続的にグループ化され、前記複数のパケットの前記パケットデータは前記ＰＩＯ書込み命令のアウトオブオーダー実行を介して前記元のＦＩＦＯ順とは異なる順序で送信ブロックに書き込まれることが可能である、
節２３または２４に記載の装置。

【0128】

２６．そのパケットに関連付けられたＶＬを識別するために使用される仮想レーン（ＶＬ）標識を用いて各パケット内のヘッダフィールドを符号化し、
同じ送信コンテキスト内の異なるＶＬを有するパケットがＦＩＦＯ順とは関係なく放出されることを可能にし、
同じ送信コンテキスト内の同じＶＬに関連付けられたパケットのデータの放出のためのＦＩＦＯ順を強制する、
回路および論理をさらに備える、節２５に記載の装置。

【0129】

２７．ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インタフェースと、
前記ＰＣＩｅインタフェースに動作可能に結合されたプログラム入力／出力（ＰＩＯ）送信メモリ、および
前記ＰＩＯ送信メモリに動作可能に結合された放出ブロック、
を含む伝送エンジンと、
前記放出ブロックに動作可能に結合された伝送ポートを含むネットワークポートと、
を備える装置であって、
前記伝送エンジンは、
前記ＰＩＯ送信メモリを、各々が複数の連続する送信ブロックを備える、複数の送信コンテキストに分割し、
ＰＣＩｅ相互接続を介して前記ＰＣＩｅインタフェースに結合されたプロセッサからインバウンドＰＣＩｅポステッドライトを受信し、各ＰＣＩｅポステッドライトは、前記プロセッサに結合されたメモリ内に格納されたパケットに対応するパケットデータを包含し、ＰＩＯ書込み命令を介して単一の送信ブロックに書き込まれ、任意のパケットのパケットデータは１つの送信ブロックまたは複数の連続する送信ブロックに書き込まれ、複数の連続する送信ブロックに書き込まれるパケットのパケットデータはアウトオブオーダーで受信されることが可能とし、
パケット用の複数の連続する送信ブロックが充填されたときを検出し、
パケット用の前記連続する送信ブロックのすべてが充填されたとして検出されたときに、前記複数の連続する送信ブロック内のパケットデータを、前記放出ブロックへの放出の対象であるとして標識する、
回路および論理をさらに備える、装置。

【0130】

２８．前記放出ブロックから前記伝送ポートに放出されるために充填された前記複数の送信コンテキスト内のパケットの中からパケットを選択するためのアービタを実現するための回路および論理をさらに備える、節２７に記載の装置。

【0131】

２９．前記伝送エンジンは、送信ダイレクトメモリアクセス（ＳＤＭＡ）メモリと、前記ＳＤＭＡメモリ内のバッファにデータを書き込むためにＤＭＡ転送を用いて前記プロセッサに結合されたメモリからデータを引き出すように構成された複数のＳＤＭＡエンジンと、をさらに備える、節２７または２８に記載の装置。

【0132】

３０．前記ＰＣＩｅインタフェースは第一ＰＣＩｅインタフェースを備え、前記装置は、
アウトオブオーダー実行をサポートし、メモリインタフェース、少なくとも１つのストアバッファ、およびＰＣＩｅ相互接続を介して前記第一ＰＣＩｅインタフェースに結合された第二ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インタフェースを含む、複数のプロセッサコアを有するプロセッサであって、
前記メモリインタフェースと結合されたときにメモリ内に格納されたそれぞれのパケット用のパケットデータを前記ＰＩＯ送信メモリに書き込むためのＰＩＯ書込み命令のシーケンスを受信し、
ＰＩＯ書込み命令の前記シーケンスをプロセッサコア上の命令スレッドとして実行し、ＰＩＯ書込み命令の実行は、データをストアバッファ内のストアユニットに書き込ませ、ストアブロックにグループ分けされた前記ストアユニットは一列のストアユニットを備え；前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、結果的にデータは、前記ストアブロックが充填される前に異なるストアブロック内のストアユニットに書き込み、
ストアブロックが充填されたときを検出し、
ストアブロックが充填されたことの検出に応えて、前記ＰＣＩｅ相互接続を通じて送信された前記ＰＩＯ送信メモリ内のバッファへのＰＣＩｅポステッドライトを介して前記ストアブロック内の前記データをドレインする、
回路および論理をさらに含むプロセッサをさらに備える、節２７から２９のいずれかに記載の装置。

【0133】

３１．前記装置は、
前記ＰＣＩｅインタフェースに結合された受信エンジンと、
前記受信エンジンに結合された受信ポートと、
をさらに備えるホストファブリックインタフェースを備える、節２７から３０のいずれかに記載の装置。

【0134】

３２．前記装置は、節３１の前記ホストファブリックインタフェースのために定義された構成を有する複数のホストファブリックインタフェースを備える、節３１に記載の装置。

【0135】

３３．アウトオブオーダー実行をサポートし、メモリインタフェース、少なくとも１つのストアバッファ、および第一ＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）インタフェースを含む複数のプロセッサコアを有する、プロセッサと、
ＰＣＩｅ相互接続を介して前記プロセッサの前記第一ＰＣＩｅインタフェースに結合された、第二ＰＣＩｅインタフェースと、
前記第二ＰＣＩｅインタフェースに動作可能に結合され、プログラム入力／出力（ＰＩＯ）送信メモリを含む、伝送エンジンと、
を備える装置であって、
前記プロセッサは、
前記メモリインタフェースに結合されたときにメモリ内に格納されたそれぞれのパケット用のパケットデータを前記ＰＩＯ送信メモリに書き込むためのプログラム入力／出力（ＰＩＯ）書込み命令のシーケンスを受信し、
ＰＩＯ書込み命令の前記シーケンスをプロセッサコア上の命令スレッドとして実行し、ＰＩＯ書込みの実行は、データをストアバッファ内のストアユニットに書き込ませ、ストアブロックにグループ分けされた前記ストアユニットは一列のストアユニットを備え；前記ＰＩＯ書込み命令の一部はアウトオブオーダーで実行され、結果的にデータは、前記ストアブロックが充填される前に異なるストアブロック内のストアユニットに書き込み、
ストアブロックが充填されたときを検出し、
ストアブロックが充填されたことの検出に応えて、前記ＰＣＩｅ相互接続を通じて送信された前記ＰＩＯ送信メモリ内のバッファへのＰＣＩｅポステッドライトを介して前記ストアブロック内の前記データをドレインする、
手段をさらに備える、装置。

【0136】

３４．前記メモリは６４バイト（６４Ｂ）キャッシュラインを採用し、各ストアブロックは６４バイトのデータを備え、前記ポステッドライトは６４ＢのＰＣＩｅ（Ｐｅｒｉｐｈｅｒａｌ Ｃｏｍｐｏｎｅｎｔ Ｉｎｔｅｒｃｏｎｎｅｃｔ Ｅｘｐｒｅｓｓ）ポステッドライトを備える、節３３に記載の装置。

【0137】

３５．前記プロセッサは６４ビットプロセッサを備え、各ストアユニットは、単一の命令を用いて前記プロセッサ内の６４ビットデータレジスタからストアユニットに書き込まれた６４ビットのデータを備える、節３３または３４に記載の装置。

【0138】

３６．前記プロセッサはライトコンバイニングを採用し、アウトオブオーダーＰＩＯ書込み命令の実行の結果、データは不連続順でストアブロック内のストアユニットに書き込まれる、節３３から３５のいずれかに記載の装置。

【0139】

３７．前記ＰＩＯ送信メモリは複数の送信コンテキストに分割され、各送信コンテキストは送信ブロックのシーケンスとして構造化され、前記装置は、
連続順で複数の連続する送信ブロックにパケットのデータを書き込むためのＰＩＯ書込み命令のシーケンスを受信し、
不連続順で前記連続する送信ブロックに前記パケットの前記データを書き込む、
手段をさらに備える、節３３から３６のいずれかに記載の装置。

【0140】

３８．前記複数の連続する送信ブロックのすべてが前記パケットデータで充填されたことを検出し、
前記複数の送信ブロックのすべてが充填されてしまったら、前記複数の送信ブロック内のデータを放出できるようにする、
手段をさらに備える、節３７に記載の装置。

【0141】

３９．前記パケットの長さを判断するために前記複数の連続する送信ブロックの１つ目の中のデータを検査し、
いくつの連続する送信ブロックが前記パケットのデータを格納するために採用されるべきかを判断する、
手段をさらに備える、節３８に記載の装置。

【0142】

一般的に、本明細書の図に示される回路、論理、および構成要素は、ディスクリートチップ、ＳｏＣ、マルチチップモジュール、および複数のネットワークインタフェースのサポートを含むネットワーキング／リンクインタフェースチップを含む、様々なタイプの集積回路（たとえば、半導体チップ）およびモジュールにおいて実施されることも可能である。また、本明細書において使用される際に、様々な動作を行うための回路および論理は、埋め込み論理、埋め込みプロセッサ、コントローラ、マイクロエンジン、あるいはハードウェア、ソフトウェア、および／またはファームウェアのいずれかの組み合わせの使用のうちの１つ以上を介して実施されてもよい。たとえば、様々な論理ブロックおよび／または回路によって示される動作は、ＡＳＩＣ、ＦＰＧＡ、ＩＰブロックライブラリを含むがこれらに限定されないプログラムされた論理ゲートなどを用いて、あるいはプロセッサ、プロセッサコア、コントローラ、マイクロコントローラ、マイクロエンジンなどを含む１つ以上の処理要素上で実行されるソフトウェアまたはファームウェア命令のうちの１つ以上を通じて、行われてもよい。

【0143】

加えて、本明細書の実施形態の態様は、半導体チップ、ＳｏＣ、マルチチップモジュールなどの中のみならず、非一時的機械読み取り可能媒体の中でも実施されることが可能である。たとえば、上記の設計は、半導体装置を設計するために使用される設計ツールに関連付けられた非一時的機械読み取り可能媒体に格納および／または埋め込まれてもよい。例としては、ＶＨＳＩＣハードウェア記述言語（ＶＨＤＬ；ＶＨＳＩＣ Ｈａｒｄｗａｒｅ Ｄｅｓｃｒｉｐｔｉｏｎ Ｌａｎｇｕａｇｅ）言語、Ｖｅｒｉｌｏｇ言語またはＳＰＩＣＥ言語、あるいはその他のハードウェア記述言語でフォーマットされたネットリストを含む。いくつかのネットリストの例は：挙動レベルネットリスト、レジスタ転送レベル（ＲＴＬ）ネットリスト、ゲートレベルネットリスト、およびトランジスタレベルネットリストを含む。機械読み取り可能媒体は、ＧＤＳ−ＩＩファイルなどのレイアウト情報を有する媒体も含む。

【0144】

さらに、半導体チップ設計のためのネットリストファイルまたはその他の機械読み取り可能媒体は、先に記載された教示の方法を実行するためのシミュレーション環境において使用されてもよい。

【0145】

特定の実施を参照していくつかの実施形態が記載されたものの、いくつかの実施形態によるその他の実施も可能である。加えて、図示された、および／または本明細書に記載された要素の配置および／または順序またはその他の特徴は、図示および記載された特定のやり方で配置される必要はない。いくつかの実施形態によるその他多くの配置が可能である。

【0146】

図示される各システムにおいて、いくつかのケースにおける要素は各々、提示される要素が異なってもおよび／または類似であってもよいことを示唆するために、同じ参照番号または異なる参照番号を有してもよい。しかしながら、１つの要素は、異なる実施を有するため、および本明細書に図示または記載されるシステムの一部またはすべてとともに動作するための、十分な柔軟性を有することができる。図示される様々な要素は、同じであっても異なってもよい。いずれのものが第一要素と称され、いずれのものが第二要素と称されるかは、任意である。

【0147】

上記詳細な説明および請求項における「Ｍ」、「Ｇ」、「Ｂ」、「ｎ」、「ｍ」、「ｋ」などのイタリック文字は整数を表すために使用され、特定の文字の使用は特定の実施形態に限定されるものではない。また、個別の整数を表すために個別の請求項において同じ文字が使用されてもよく、あるいは異なる文字が使用されてもよい。加えて、詳細な説明における特定の文字の使用は、詳細な説明の同じ内容に関する請求項で使用される文字と一致してもしなくてもよい。

【0148】

説明および請求項において、その派生語と併せて、用語「結合（ｃｏｕｐｌｅｄ）」および「接続（ｃｏｎｎｅｃｔｅｄ）」が使用されているかもしれない。これらの用語が互いの同義語として意図されるものではないことは、理解すべきである。むしろ、特定の実施形態において、「接続」は、２つ以上の要素が互いに直接物理的または電気的接触していることを示すために使用される。「結合」は、２つ以上の要素が直接物理的または電気的に接触していることを意味することができる。しかしながら、「結合」はまた、２つ以上の要素が互いに直接接触しておらず、それでもなお互いに協働または相互作用することも、意味することができる。

【0149】

実施形態は、本発明の実施または例である。明細書における「実施形態」、「一実施形態」、「いくつかの実施形態」、または「その他の実施形態」の言及は、その実施形態に関連して記載される特定の特徴、構造、または特性が本発明の少なくともいくつかの実施形態に含まれるが、しかし必ずしもすべての実施形態には含まれないことを、意味する。「実施形態」、「一実施形態」、または「いくつかの実施形態」の様々な記載は、必ずしもすべて同じ実施形態を指すとは限らない。

【0150】

本明細書に記載および図示されるすべての構成要素、特徴、構造、特性などが特定の１つまたは複数の実施形態に含まれる必要はない。ある構成要素、特徴、構造、または特性が含まれることが「あってもよい（ｍａｙ）」、「あるかもしれない（ｍｉｇｈｔ）」、「可能（ｃａｎ）」、または「あるかもしれない（ｃｏｕｌｄ）」と明細書が述べる場合、たとえば、その特定の構成要素、特徴、構造、または特性が含まれることが必要とされるわけではない。明細書または請求項が「ａ」または「ａｎ」（１つの）要素を指す場合、これはその要素が１つしかないことを意味するものではない。明細書または請求項が「もう１つの（ａｎ ａｄｄｉｔｉｏｎａｌ）」要素を指す場合、これは２つ以上の追加要素があることを除外するものではない。

【0151】

要約書に記載されるものを含め、本発明の図示される実施形態の上記説明は、包括的となるように、または本発明を開示された正確な形態に限定するように、意図されるものではない。本発明の特定の実施形態および例が説明目的のため本明細書に記載されているが、その一方で、当業者が認識するように、本発明の範囲内で様々な同等の修正が可能である。

【0152】

これらの修正は、上記の詳細な説明を鑑みて本発明に対してなされることが可能である。以下の請求項で使用される用語は、本明細書および図面で開示された具体的実施形態に本発明を限定するように解釈されるべきではない。むしろ、本発明の範囲は、請求項解釈の確立された原理にしたがって解釈される、以下の請求項によってのみ判断されるべきである。

【図1】

【図2】

【図3】

【図4】

【図5】

【図6a】

【図6b】

【図7a】

【図7b】

【図7c】

【図7d】

【図7e】

【図7f】

【図8a】

【図8b】

【図8c】

【図8d】

【図8e】

【図9a】

【図9b】

【図10】

【図11】

【図12】

【図13】

【図14】