JP6788691B2 - ＯｐｅｎＦａｂｒｉｃｓにおけるスループットの改善 - Google Patents

Description

本開示はスループットに関する。特に、本開示は、ＯｐｅｎＦａｂｒｉｃｓコンピューティング環境におけるスループットの改善に関する。

ＯｐｅｎＦａｂｒｉｃｓ Ｅｎｔｅｒｐｒｉｓｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＯＦＥＤ（商標））は、リモートダイレクトメモリアクセス（ＲＤＭＡ）及びカーネルバイパスアプリケーションのためのオープンソースコンピューティング技術である。ＯＦＥＤは、高効率なネットワーク、ストレージ接続性、及び並列コンピューティングを必要とするコンピューティング環境で使用され得る。ＯＦＥＤは、カーネルレベルのドライバ、ＲＤＭＡ送受信操作、並列メッセージパッシング（ＭＰＩ）のためのサービス、オペレーティングシステム（ＯＳ）のカーネルバイパス、並びにカーネル及びユーザーレベルのアプリケーションプログラミングインターフェース（ＡＰＩ）を提供する。したがって、ＯＦＥＤは、高効率のコンピューティング、ワイヤスピードのメッセージング、マイクロ秒のレイテンシ、並びにストレージ及びファイルシステムに対する高速入力／出力（Ｉ／Ｏ）を必要とするアプリケーションに使用され得る。

ＲＤＭＡは、いずれかのコンピューティングシステムのＯＳも介さずに、あるコンピューティングシステムのメモリから別のコンピューティングシステムのメモリへのダイレクトメモリアクセス（ＤＭＡ）を含む。他の特徴に加えて、ＲＤＭＡは、リモートダイレクトメモリアクセス、非同期の作業キュー、及びカーネルバイパスを提供する。ＲＤＭＡは、増大したスループット及び低いレイテンシを可能にする。

ＯＦＥＤ ＡＰＩは、入力パラメータを（例えば、ヘッダ及び１つ以上のデータパケットの形式で）受け入れ得る。ヘッダは典型的にサイズが小さいため（例えば、データと比較して）、データ及びヘッダを合体させて、ＲＤＭＡ書き込みの数を最小限にすることが効率的である。しかしながら、データ及びヘッダを合体させると同時に、データがページ境界に位置合わせされた状態を維持することにより、電信上の無駄（on-wire wastage）が生じ得る（例えば、ネットワーク上で送信又は転送されるデータの量）。

本明細書では、ＯｐｅｎＦａｂｒｉｃｓコンピューティング環境におけるスループットを改善するための方法、システム、及びプロセスを開示する。このような方法の１つは、データ及びヘッダを受信することと、データ及びヘッダが書き込まれるバッファを識別することと、を含む。データ及びヘッダに関する配置情報は、それぞれのバッファのサイズ、データのページ境界位置合わせ、及びヘッダのヘッダ位置合わせに、少なくとも部分的に基づいて決定される。データ及びヘッダは次いで、配置情報を使用してバッファ（複数可）に書き込まれる。この例では、データは、ページ境界に書き込まれ、ヘッダはヘッダ境界に書き込まれる。

特定の実施形態では、配置情報を使用することにより、結果的に最小数のバッファを利用することになり、データは最小数のバッファに書き込まれるときにページ境界に位置合わせされ、加えて電信上の無駄が最小限（又はゼロ）になる。配置情報は、データ及びヘッダを最後から２番目のバッファに書き込むための命令を含む。

いくつかの実施形態では、ヘッダ及びデータは、配置情報に基づいて、複数のソースバッファに含まれるヘッダ及びデータを１つ（又はそれ以上）の宛先バッファにマッピングすることにより、リモートダイレクトメモリアクセス（ＲＤＭＡ）書き込みに合体（結合）される。メタデータを含む３２ビットデータ空間を含み、またそれが付随するＲＤＭＡ書き込みは、配置情報と共に宛先に送信又は転送される。

他の実施形態では、データを最小数のバッファでページ境界に位置合わせできない場合、１つ以上の追加バッファが選択され得る。この例では、バッファは、複数の宛先バッファを含み、最小数のバッファは、１つ以上の宛先バッファを含む。

前述の内容は概要であり、したがって必然的に、簡略化、一般化、及び詳細の省略を含み、その結果として、当業者であれば、その概要が例示的であるにすぎず、なんら限定的ではないことを理解するであろう。特許請求の範囲によってのみ定義されるような本開示の他の態様、機能、及び利点は、以下に記載される非限定的で詳細な説明において明らかになるであろう。

本開示は、添付図面を参照することによってよりよく理解され得、かつそれの多数の対象及び特徴が当業者に明らかにされる。

本開示の一実施形態による、ＯＦＥＤコンピューティングシステムのブロック図である。

本開示の一実施形態による、ＯＦＥＤ ＡＰＩを実装するソースコンピューティングシステムのブロック図である。

本開示の一実施形態による、合体されていないデータ単位及びヘッダのブロック図である。

本開示の一実施形態による、バッファの始まりに書き込まれるヘッダのブロック図である。

本開示の一実施形態による、データの直後に書き込まれるヘッダのブロック図である。

本開示の一実施形態による、ＯＦＥＤ ＡＰＩによって提供される３２ビットデータ空間のブロック図である。

本開示の一実施形態による、位置合わせの終わりに書き込まれるヘッダのブロック図である。

本開示の一実施形態による、最後から２番目のバッファで位置合わせの終わりに書き込まれるヘッダのブロック図である。

本開示の一実施形態による、追加のバッファなしに、位置合わせの終わりに書き込まれるヘッダのブロック図である。

本開示の一実施形態による、最後から２番目のバッファに書き込まれるヘッダのブロック図である。

本開示の一実施形態による、バッファにデータ及びヘッダを充填するためのプロセスを示すフローチャートである。

本開示の一実施形態による、ヘッダ及びデータを結合するためのプロセスを示すフローチャートである。

本開示の一実施形態による、ヘッダ及びデータの配置／マッピング情報を決定するためのプロセスを示すフローチャートである。

本開示の一実施形態による、ＲＤＭＡを使用してデータ及びヘッダを生成して送信するためのプロセスを示すフローチャートである。

本開示の一実施形態による、特定のモジュール（複数可）がソフトウェア内に実装され得る態様を示す、コンピューティングシステムのブロック図である。

本開示の一実施形態による、多様なデバイスがネットワークを介して通信し得る態様を示す、ネットワーク化されたシステムのブロック図である。

本開示は、様々な修正形態に影響を受けるが、本開示の特定の実施形態は、図面及び詳細な説明において例として提供される。図面及び詳細な説明は、開示内容を開示された特定の形式に限定することを意図しない。その代わりに、添付の請求項によって規定されるような本開示の趣旨及び範囲内にある全ての修正形態、等価物、及び代替形態を包含することが意図される。

序論
あるコンピューティング環境において、２つ（又はそれ以上）のコンピューティングシステム間のデータ転送は、データ及び付随するヘッダ（並びに他のメタデータ）をあるコンピューティングシステムのメモリから（例えば、複数のソースバッファから）別のコンピューティングシステムのメモリに（例えば、１つ以上の宛先バッファに）直接送信することを含み得る。ヘッダは典型的にサイズが小さいため（例えば１ｋ）、あるコンピューティングシステムのメモリから別のコンピューティングシステムのメモリにヘッダを転送する書き込み操作のみを行うことは、リソースの集中は言うまでもなく、非効率である。

したがって、データ及びヘッダを合体（又は結合）させて、実行される書き込み操作の数を減らし、アプリケーションのスループットを改善することが有利であり得る。合体の一部として、複数のソースバッファに含まれるデータ及びヘッダは、単一の宛先バッファ（又は複数の宛先バッファ）にマッピングされ得る。この配置（又はマッピング）情報は次いで、単一の書き込み操作の一部として、データ及びヘッダと共に、ソースバッファから１つ以上の宛先バッファに送信され得る。

上記のアプローチが有利に使用され得るシステムの一例は、ＯｐｅｎＦａｂｒｉｃｓ Ｅｎｔｅｒｐｒｉｓｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＯＦＥＤ（商標））（又はＯｐｅｎＦａｂｒｉｃｓ Ｓｏｆｔｗａｒｅ（ＯＦＳ））を実装するシステムである。ＯＦＥＤは、リモートダイレクトメモリアクセス（ＲＤＭＡ）及びカーネルバイパスアプリケーションのためのオープンソースソフトウェアである。ＯＦＥＤは、高効率なネットワーク、ストレージ接続性、及び並列コンピューティングを必要とするコンピューティング環境に実装され得る。他の特徴の中でも、ＯＦＥＤは、カーネルレベルドライバ、チャネル指向ＲＤＭＡ及び送受信操作、オペレーティングシステム（ＯＳ）のカーネルバイパス、並びにカーネル及びユーザーレベルアプリケーションプログラミングインターフェース（ＡＰＩ）（例えば、ＲＤＭＡ転送のためのＯＦＥＤ ＡＰＩ）を提供する。ＯＦＥＤはまた、並列メッセージパッシング（ＭＰＩ）、ソケットデータ交換（例えば、セッション記述プロトコル（ＳＤＰ））、ネットワーク接続型ストレージ（ＮＡＳ）及びストレージエリアネットワーク（ＳＡＮ）ストレージ、並びにファイルシステムのためのサービスを提供する。

ＲＤＭＡは、ソース又は宛先コンピューティングシステムのＯＳのいずれかを介することなく、あるコンピューティングシステム（例えば、ソースコンピューティングシステム）のメモリから別のコンピューティングシステム（例えば、宛先コンピューティングシステム）のメモリへのダイレクトメモリアクセス（ＤＭＡ）を含む。例えば、ソースコンピューティングシステムのネットワークアダプタは、宛先コンピューティングシステムのネットワークアダプタが宛先コンピューティングシステムのメモリへの（又はそこからの）データに直接アクセスすることを可能にするメッセージを宛先コンピューティングシステムのネットワークアダプタに送信し得る。

ＲＤＭＡ内のメッセージは、少なくとも２つのタイプのメッセージを含み得る。第１のタイプは、ＲＤＭＡ書き込みである。ＲＤＭＡ書き込みは、そのアドレスに置く（又は書き込む）アドレス及びデータを含む。ＲＤＭＡ書き込みは、ＲＤＭＡ書き込みを受信するネットワークアダプタが、提供されたデータを指定のアドレスに書き込む（又は置く）ことを可能にする。第２のタイプは、ＲＤＭＡ読み取りである。ＲＤＭＡ読み取りは、アドレス及び長さを含む。ＲＤＭＡ読み取りは、ＲＤＭＡ読み取りを受信するネットワークアダプタが、要求されたアドレスにデータを返信する応答を生成することを可能にする。ＲＤＭＡでは、これらのタイプのメッセージは両方とも「片側」であり、メッセージは、メッセージを受信するコンピューティングシステムの中央演算処理装置（ＣＰＵ）を介さずに、メッセージを受信するネットワークアダプタによって処理される。

特定のコンピューティングシステムでは、ネットワークアダプタは、非同期インターフェース（「ｖｅｒｂｓ」インターフェースとも呼ばれる）を介してアクセスされ得る。ネットワークアダプタを使用するため（例えば、ＲＤＭＡ操作を実行するため）、キューペア（又はＱＰ）と呼ばれるオブジェクトが作製され得る。ＱＰは、作業キューのペア、すなわち送信キュー及び受信キューのほか、完了キュー（ＣＱ）を含む。ＲＤＭＡ操作は、作業キューに（例えば、要求として）ｐｏｓｔ送信され得る。ＲＤＭＡ操作は次いで、同期的に実行され、完了すると、ネットワークアダプタが作業完了情報をＣＱの最後に追加する。完了情報は次いで、ＣＱから受信され、どの要求が完了したかが決定され得る。このように非同期に操作することで、ＲＤＭＡコンピューティング環境において計算及び通信をオーバーラップさせることがより容易になる。

ＲＤＭＡ対応ネットワークアダプタはまた、片側のＲＤＭＡ操作に加えて、「両側」の送受信操作をサポートすることに留意されたい。加えて、ＲＤＭＡコンピューティング環境におけるネットワークアダプタはまた、カーネルを介さずにハードウェアで直接、高速経路操作（例えば、作業要求のｐｏｓｔ送信及び作業完了の検索）を実行する（ゆえに、システムコールオーバーヘッドに関連付けられた時間を節約する）ためのユーザー空間プロセスを可能にし得ることが理解されよう。したがって、ＲＤＭＡは、高スループット及び低レイテンシのネットワーキングを可能にする（例えば、並列計算クラスタで特に有用である）。

前述のとおり、ＯＦＥＤは、ＲＤＭＡデータ転送用のＡＰＩを提供する。ＯＦＥＤ ＡＰＩがＲＤＭＡデータ転送に使用される場合、クライアントのメッセージは、ヘッダ及び１つ以上のデータパケットを含む。ヘッダのサイズは、データのサイズと比べて典型的に小さいため、データとヘッダとを個別に（例えば、２つの別個のＲＤＭＡ書き込みとして）書き込むことは効率的ではない。データ及びヘッダを合体（又は結合）させて（例えば、ＲＤＭＡ書き込みの一部として）、ＲＤＭＡ書き込みの合計数を減らすことができる。

ＯＦＥＤ ＡＰＩはまた、それぞれのＲＤＭＡ書き込みの一部として私的利用のための３２ビットデータ空間（３２ビット即値データ又は私的データとも呼ばれる）を提供する。この３２ビットデータ空間を使用して、ヘッダ自体に関連付けられた情報（例えば、ヘッダ境界におけるヘッダの位置を示すヘッダオフセット）に加え、バッファ位置情報並びにＲＤＭＡ書き込みに関連付けられた他のメタデータを記憶することができる。

残念ながら、ＲＤＭＡデータ転送用のデータ及びヘッダを合体（結合）させることは（例えば、ソースバッファを宛先バッファにマッピングすることにより）、いくつかの問題を引き起こす。第１に、アプリケーション（例えば、宛先コンピューティングシステム１４５上で実行する１つ以上のアプリケーション）は、データがページ境界に位置合わせされることを必要とする。例えば、コンピューティングシステムは、メモリアドレスに対するワードサイズのチャンク（例えば、３２ビットシステムで４バイトチャンク）以上のデータの読み取り又は書き込みを行う。

ページ境界位置合わせ（又はデータ構造位置合わせ）は、コンピューティングシステムのパフォーマンスを向上させるように（例えば、特定のメモリ管理システムがメモリを管理する方法による）、ワードサイズのいくらかの倍数に等しいデータをメモリアドレスに書き込むことを含む。データをページ境界に位置合わせするため、最後のデータ構造の終わりと次のデータ構造の始まりとの間に無意味なもの（「ドントケア」）（無駄とも呼ばれる）としていくつかのバイトを挿入（又は処理）する必要がある場合がある（例えば、パディング）。したがって、データがページ境界に位置合わせされたままであるという必要条件により、不必要かつ冗長に電信上で送信される（例えば、ＲＤＭＡデータ転送の一部としてネットワーク上で送信される）無駄が生じ得る。

第２に、データ及びヘッダを合体させることにより、追加の冗長なＲＤＭＡ書き込みが生じ得る（例えば、１つ以上の追加の宛先バッファは、ヘッダ境界の始まりにヘッダを書き込むこと、ページ境界位置合わせを維持すること、などが必要とされ得る）。したがって、データ及びヘッダを書き込むために使用される宛先バッファ（又は実行されるＲＤＭＡ書き込み）の数を最小限にすることも、重要な考慮事項である。

第３に、述べたように、ＯＦＥＤを実装するようなシステムは、例えば、バッファ位置情報、ＲＤＭＡ書き込みメタデータ、ヘッダ位置情報などを維持するため、ＲＤＭＡ書き込みの一部として３２ビット情報記憶領域を提供する、ＯＦＥＤ ＡＰＩを採用する（又は、採用するように変更され得る）。３２ビットのデータ空間のうちの数ビットのみをヘッダ位置情報（例えば、ヘッダオフセット）の維持に利用できるため、かかるシステムでデータ及びヘッダを合体させるときは、ヘッダの配置も別の重要な考慮事項（及び制限事項）となる。

本明細書では、提供された３２ビットデータ空間を効率的に利用し、ＲＤＭＡ書き込みの数を最小限にし（例えば、データ及びヘッダの書き込みに使用する宛先バッファの数を減らす）、データのページ境界位置合わせを維持し、電信上の無駄を最小限にしながら、ＯＦＥＤ ＲＤＭＡコンピューティングシステムなどのシステムにおいて、データ及びヘッダを合体させ、スループットを改善するための方法、システム、及びプロセスを開示する。
コンピューティングシステムにおける例示的な実装

図１は、一実施形態による、ＲＤＭＡ技術を実装し、使用するコンピューティングシステムのブロック図である。図１のコンピューティングシステムは、ネットワーク１８０を介して通信可能に連結されたソースコンピューティングシステム１０５及び宛先コンピューティングシステム１４５を含む。ネットワーク１８０としては、任意のタイプのネットワーク又は相互接続（例えば、インターネット、広域ネットワーク（ＷＡＮ）、ＳＡＮなど）が挙げられ得る。

ソースコンピューティングシステム１０５は、ソースプロセッサ１１０及びソースネットワークアダプタ１１５を含む。ソースプロセッサ１１０及びソースネットワークアダプタ１１５は、ソースメモリ１２０に通信可能に連結される。ソースメモリ１２０は、ソースドライバ１２５、ソースＯＳ １３０、及びソースバッファ１４０（１）〜（Ｎ）を実装するアプリケーション１３５を含む。同様に、宛先コンピューティングシステム１４５は、宛先メモリ１５０に通信可能に連結された宛先プロセッサ１７５及び宛先ネットワークアダプタ１７０を含む。宛先メモリ１５０は、宛先バッファ１５５（１）〜（Ｎ）、宛先ドライバ１６０、及び宛先ＯＳ １６５を含む。

図１のコンピューティングシステムは、ソースＯＳ １３０又は宛先ＯＳ １６５を介さない、ソースコンピューティングシステム１０５のソースメモリ１２０から宛先コンピューティングシステム１４５のメモリへのリモートダイレクトメモリアクセスを可能にする（逆もまた同様）。例えば、ソースコンピューティングシステム１０５のソースネットワークアダプタ１１５は、宛先コンピューティングシステム１４５の宛先ネットワークアダプタ１７０が宛先メモリ１５０への（又はそこからの）データに直接アクセスすること（逆もまた同様）を可能にするメッセージ（例えば、クライアントメッセージ）を宛先コンピューティングシステム１４５の宛先ネットワークアダプタ１７０に送信し得る。

いくつかの実施形態では、ソースネットワークアダプタ１１５及び宛先ネットワークアダプタ１７０は、ユーザー空間プロセス（それぞれ、ソースコンピューティングシステム１０５上及び宛先コンピューティングシステム１４５上）が、それぞれのカーネルをバイパスし、システムコールを回避することによって（例えば、図１に示すように、ソースＯＳ １３０及び宛先ＯＳ １６５をバイパスすることによって）、ＲＤＭＡ操作（又は、本明細書に記載するような方法に修正可能な、他のバッファベースの操作）を実行することを可能にする。ＲＤＭＡ操作は、ＯＦＥＤ ＡＰＩを使用して管理され、促進され得る。

図２は、一実施形態による、ＯＦＥＤ ＡＰＩを実装するソースコンピューティングシステムのブロック図である。図２に示すように、ソースコンピューティングシステム１０５は、ＯｐｅｎＦａｂｒｉｃｓ Ｅｎｔｅｒｐｒｉｓｅ Ｄｉｓｔｒｉｂｕｔｉｏｎ（ＯＦＥＤ（商標））ＡＰＩなどのアプリケーションプログラミングインターフェース（ＡＰＩ）２０５を含む。ソースコンピューティングシステム１０５はまた、ＲＤＭＡモジュール２１０、バッファセレクタ２１５、データ及びヘッダコアレッサ２２０、並びにページ境界位置合わせ計算機２２５を含む。ＲＤＭＡモジュール２１０（又は他の同等のサポートモジュール）、バッファセレクタ２１５、データ及びヘッダコアレッサ２２０、並びにページ境界位置合わせ計算機２２５は、ハードウェア又はソフトウェアとして、及びソースコンピューティングシステム１０５の一部として、又は別個に（例えば、ＲＤＭＡサーバ、ソフトウェアアプライアンス、仮想マシン、又は何らかの他のタイプのコンピューティングデバイスの一部として）実装され得ることに留意されたい。

ソースコンピューティングシステム１０５はまた、ソースメモリ１２０を含む。ソースメモリ１２０は、ソースバッファ１４０（１）〜（Ｎ）を含む。それぞれのソースバッファは、データ、又はデータ及びヘッダの組み合わせを含む。例えば、図２に示すように、ＲＤＭＡモジュール２１０によって宛先バッファにマッピングされるとき、ソースバッファ１４０（１）はデータ２３０（１）（例えば、１つ以上のデータ単位を伴う）を含み、ソースバッファ１４０（Ｎ−２）はデータ２３０（２）を含み、ソースバッファ１４０（Ｎ−１）（例えば、最後から２番目のバッファ）はデータ２３０（Ｎ−１）及びヘッダ２４０を含み、ソースバッファ１４０（Ｎ）はデータ２３０（Ｎ）を含む。

ＲＤＭＡモジュール２１０は、１つ以上のＲＤＭＡ操作を管理、促進、調整、及び実行する。例えば、ＲＤＭＡモジュール２１０は、ＲＤＭＡ書き込み操作又はＲＤＭＡ読み取り操作を実行し得る。バッファセレクタ２１５は、データ、又はデータ及びヘッダを充填する（又は書き込む）１つ以上のバッファ（例えば、宛先バッファ１５５（１）〜（Ｎ））を選択する。データ及びヘッダコアレッサ２２０は、データ及びヘッダを（例えば、単一のＲＤＭＡ書き込み／パケットの一部として単一のバッファ（例えば、宛先バッファ１４０（Ｎ−１））に）合体（又は結合）させることによって、ソースバッファを宛先バッファにマッピングする。最後に、ページ境界位置合わせ計算機２２５は、データがページ境界に位置合わせされるように、宛先バッファ１５５（１）〜（Ｎ）内でのデータの配置を決定する。

併せて、ＲＤＭＡモジュール２１０、バッファセレクタ２１５、データ及びヘッダをコアレッサ２２０、並びにページ境界位置合わせ計算機２２５は、ＯＦＥＤベースのＲＤＭＡコンピューティング環境におけるスループットを改善するため、１つ以上の（利用可能な）バッファ（例えば、宛先バッファ１５５（１）−（Ｎ））の中でデータ及びヘッダの配置を決定する。
データ及びヘッダの書き込みの例

一実施形態では、ソースコンピューティングシステム１０５は、（例えば、１つ以上のソースバッファに含まれる、及び／又は１つ以上のホスト、サーバなどによって実行されるアプリケーションからの）ヘッダ及びデータを受信する。バッファセレクタ２１５は、データ及びヘッダが書き込まれる宛先バッファ（例えば、宛先バッファ１５５（１）〜（Ｎ））を識別する。データ及びヘッダコアレッサ２２０は次いで、データ及びヘッダの（適切な）マッピング並びに配置を決定する。

いくつかの実施形態では、データ及びヘッダのマッピング並びに配置の決定は、少なくとも３つの要素に基づく。第１に、データ及びヘッダの配置の決定は、（例えば、ＲＤＭＡ書き込みの数を減らすため）最小数の宛先バッファを利用することに基づく。第２に、データ及びヘッダの配置の決定は、（最小数の宛先バッファにおいて）ページ境界に位置合わせされるデータに基づく。第３に、データ及びヘッダの配置の決定は、電信上の無駄を最小限にする（例えば、ネットワーク上で送信される無駄（又はパディング）の量を減らす）配置に基づく。少なくともこれら３つの要素に基づいて、ＲＤＭＡモジュール２１０は、データ及びヘッダを宛先バッファに書き込む（例えば、データをページ境界に書き込み、ヘッダをヘッダ境界に書き込む）。

他の実施形態では、ＲＤＭＡモジュール２１０は、ＲＤＭＡ書き込みを生成する。ＲＤＭＡ書き込みは、単一のＲＤＭＡパケットに合体された（例えば、データ及びヘッダコアレッサ２２０を使用）ヘッダ及びデータを含む。特定の実施形態では、ＲＤＭＡ書き込みは、３２ビットデータ空間（例えば、３２ビットデータ空間は、クライアントデータ空間の一部ではない）が付随し、ＲＤＭＡを使用して宛先コンピューティングシステム１４５に送信される。この例では、３２ビットデータ空間は、ヘッダのオフセットを含むために（例えば、宛先バッファへのデータ及びヘッダの書き込みの一部として）使用される。

他の実施形態では、バッファセレクタ２１５は、それぞれのバッファのサイズに基づいて、データ及びヘッダに必要とされるバッファの最小数を決定する。バッファセレクタ２１５は、最小数のバッファでデータをページ境界に位置合わせできない場合に、１つ以上の追加のバッファを選択する。特定の実施形態では、それぞれのバッファは宛先バッファであり、ＯＦＥＤ ＡＰＩは、単一の宛先バッファに対する複数のソースバッファのマッピングを可能にする。
データ及びヘッダの合体の例

図３Ａは、一実施形態による、合体されていないデータ単位及びヘッダのブロック図である。説明のため、図３Ａ〜図３Ｅ及び図４Ａ〜図４Ｃのソースバッファ１４０（１）〜（Ｎ）のサイズ（並びに、受信／宛先バッファ１５５（１）〜（Ｎ）のサイズ）は８ｋであり、データは４ｋで位置合わせされる。しかしながら、代替の実装及び実施形態では、ソースバッファ１４０（１）〜（Ｎ）及び宛先バッファ１５５（１）〜（Ｎ）は、任意のサイズ（例えば、１６ｋ、３２ｋなど）であってよく、データのページ境界位置合わせも異なってよい（例えば、データは２ｋ、３ｋ、又は６ｋで位置合わせされ得る）。

図３Ａに示すように、いくつかの実施形態では、データ（例えば、データ単位３０５（１）〜（１３））及びヘッダ（例えば、ヘッダ２３５）は、合体されない（例えば、単一の宛先バッファ又は単一のＲＤＭＡ書き込みに結合されない）。この例では、データは１３Ｋであり（例えば、データ単位３０５（１）〜（１３））、ヘッダは１ｋである（例えば、ヘッダ２３５）。データ（例えば、４ｋでページ境界に位置合わせされる１３ｋのデータ）は、２つのバッファ（例えば、図３Ａに示すように、宛先バッファ１５５（１）及び１５５（２））を必要とする（及び使用する）。データとヘッダが合体していない場合、ヘッダ２３５は、別個の追加バッファ（例えば、宛先バッファ１５５（３））を必要とする。したがって、電信上の無駄は存在しないが、ＲＤＭＡ書き込み操作は、３つの宛先バッファを消費することになる。この結果、３つのＲＤＭＡ書き込みが、データ及びヘッダのＲＤＭＡ転送の一部として必要とされることになる。

図３Ｂは、一実施形態による、バッファの始まりに書き込まれるヘッダのブロック図である。いくつかの実施形態では、ヘッダ（例えば、ヘッダ２３５）は、バッファ（例えば、宛先バッファ１４０（１））の始まりに書き込まれる。ただし、前述のように、ＲＤＭＡコンピューティング環境におけるアプリケーションは、典型的に、データがページ境界に（例えば、データが４ｋでページ境界に位置合わせされる場合、８ｋバッファ内の０ｋ又は４ｋに）書き込まれることを必要とする。

この結果、図３Ｂに示すように、データはページに位置合わせされた境界で始まる必要があり（例えば、データ単位３０５（１）は、４ｋのページ境界で始まる必要がある）、必要なバッファ数も減らされていない（例えば、３つのバッファ）ため、ヘッダをバッファの始まりに書き込むことにより、ヘッダの終りとデータの始まりとの間に電信上の無駄が生じ得る。

図３Ｃは、一実施形態による、データの直後に書き込まれるヘッダのブロック図である。この例では、１３ｋのデータ（例えば、データ単位３０５（１）〜（１３））を書き込むことは、２つのバッファ（例えば、宛先バッファ１５５（１）及び１５５（２））を必要とする。いくつかの実施形態では、ヘッダ２３５は、データの直後（例えば、データ単位３０５（１３）の後）に書き込まれる。前述のように、ＯＦＥＤ ＡＰＩは、プログラマに、私的使用のために全てのＲＤＭＡ書き込みを伴う３２ビット空間を提供する。宛先コンピューティングシステム１４５は、この３２ビット値を使用して、更なる処理のために、適切なバッファ（複数可）及びバッファ（複数可）に関する使用情報（例えば、ＲＤＭＡ書き込み）を特定することができる。

しかしながら、一例として、ＯＦＥＤベースのＲＤＭＡコンピューティング環境を使用すると、この３２ビットデータ空間の一部はまた、特定のバッファ内の正確なヘッダオフセットを指示するために必要とされる。図３Ｃの例では、ヘッダ２３５がデータ（８ｋバッファに対する８バイトの位置合わせ）の直後に書き込まれる場合、ヘッダオフセットを表すことは、即値データの３２ビットデータ空間から利用可能であるよりも多くの空間（例えば、１０ビット）を必要とする。残念ながら、前述のような多くのシナリオでは、既に密集している３２ビットデータ空間において１０（空き）ビットを発見することは可能であり得ない。したがって、図３Ｃの例にあるヘッダ及びデータの配置によって、結果的に、電信上の無駄はゼロとなり、最小数のバッファが使用されるが、ヘッダオフセットを表すことは（例えば、特に、ヘッダがヘッダ境界に書き込まれていない場合）３２ビットデータ空間からあまりにも多くのビットを必要とするため、このようなソリューションは実現可能であり得ない。

図３Ｄは、一実施形態による、ＯＦＥＤ ＡＰＩによって提供される３２ビットデータ空間のブロック図である。図３Ｄに示すように、３２ビット即値データ３１０は、バッファ識別子３１５、フラグ（複数可）３２０、メタデータ３２５、ソース識別子３３０、クライアント識別子３３５、及び空きビット３４０（１）〜（Ｎ）（例えば、ヘッダオフセットの表現に利用可能）などの情報を含む。他の情報に加え、バッファ識別子、フラグ（複数可）、メタデータ、ソース識別子、及びクライアント識別子に関する情報は、３２ビット即値データ３１０の空間（例えば、ビット）の大部分を使用する。したがって、空きビット３４０（１）−（Ｎ）は、ヘッダオフセットの表現に利用可能な少数のビットを表す。この結果、利用可能な空間（例えば、空きビット）でヘッダオフセット情報を正確に表すため、いくつかの実施形態では、（例えば、空きビット３４０（１）〜（Ｎ）を使用して、ヘッダオフセット情報を完全かつ正確に表すことができるように）ヘッダはヘッダ境界に書き込まれる。

図３Ｅは、一実施形態による、位置合わせの終わりに書き込まれるヘッダのブロック図である。図３Ｅに示すように、特定の実施形態では、ヘッダ２３５は、特定の位置合わせの終わりに（例えば、２ｋの位置合わせの終わりに）及びヘッダ境界に（例えば、８ｋバッファ内の６ｋに）書き込まれる。この例では、データが（例えば、宛先バッファ１５５（１）及び１５５（２）のような１つ以上のバッファに）書き込まれる場合、ヘッダ２３５の位置合わせは、潜在的に（例えば、ヘッダ配置に）利用可能なビット数に基づいて決定される。利用可能な空きビットが多いほど、無駄が少なくなる。

例えば、図３Ｅにおいて位置合わせに２ビットのみが利用可能である場合、ヘッダ（例えば、２ｋで位置合わせされる）は、４つの可能なオフセット（例えば、８ｋバッファ内の０ｋ、２ｋ、４ｋ、及び６ｋ）に配置され得る（又はそこに書き込まれ得る）。この例において、発生し得る最大の電信上の無駄は２ｋである。しかしながら、図３Ｅにおいて位置合わせに３ビットを利用できる場合、ヘッダ（例えば、１ｋで位置合わせされる）は、８つの可能なオフセットに配置され得る（又は書き込まれ得る）ため、発生し得る最大の電信上の無駄は１ｋに軽減される。したがって、図３Ｅに示すように、位置合わせの終わりにヘッダを書き込むことはまた、いくらかの無駄を生むが、最小限になる（例えば、図３Ａに示すようにバッファの始まりにヘッダを書き込むことと比較した場合）。
ヘッダ及びデータ配置の例

図４Ａは、一実施形態による、最後から２番目のバッファで位置合わせの終わりに書き込まれるヘッダのブロック図である。図４Ａに示すように、いくつかの実施形態では、ヘッダ２３５は、最後から２番目のバッファ（例えば、宛先バッファ１４０（Ｎ−１））で、ヘッダサイズ（例えば、図４Ａに示すように１ｋ）及び位置合わせ（例えば、ヘッダ境界に基づく）に基づいて（例えば、宛先バッファ１５５（Ｎ−１）の）最後の（利用可能な）ヘッダ位置合わせされたオフセット（例えば、６ｋ）に書き込まれる。特定の実施形態では、バッファセレクタ２１５は、宛先バッファ１５５（Ｎ−１）を最後から２番目のバッファとして識別し、宛先バッファ１５５（Ｎ−１）をヘッダの配置用に選択する。ページ境界位置合わせ計算機２２５は次いで、宛先バッファ１５５（Ｎ−１）に書き込まれ得るデータのページ境界位置合わせ（例えば、データ単位３０５（１）〜３０５（６））を計算し、データ及びヘッダコアレッサ２２０は、ヘッダの配置（例えば、１ｋ）、ヘッダの表現（例えば、３２ビット即値データ３１０による）、及びヘッダ位置合わせ（例えば、６ｋで）のために十分な空間が利用可能であることを保証する。

したがって、図４Ａに示すように、いくつかの実施形態では、最後から２番目のバッファにおいて位置合わせの終わりにヘッダを書き込むことにより、結果的に電信上の無駄がゼロになり、追加のバッファも不要になる。図４Ｂは、他の実施形態による、追加のバッファ（の必要）なしに、位置合わせの終わりに書き込まれるヘッダのブロック図である。例えば、バッファ内の利用可能空間（例えば、ビット）が（例えば、データが書き込まれた後）で２ｋのヘッダ位置合わせが可能である場合（例えば、可能な最小量のビットでヘッダオフセットをキャプチャできるようにするため）、位置合わせの終わりに（例えば、宛先バッファ１５５（Ｎ）で）ヘッダ２３５を書き込むことにより、それ以外の場合に可能であるよりも書き込まれるデータが多くなる（例えば、データ単位３０５（１４））。データが最大限まで充填されていない場合（例えば、データ単位３０５（１４）まで）、１ｋのギャップ（例えば、電信上の無駄）が導入される。しかしながら、この例では、ヘッダ２３５は、データの後（例えば、１４データ単位の後）に書き込まれ得る。この例のヘッダ及びデータの配置では、電信上に無駄が生じず、また追加（宛先）バッファが必要とされないことが理解されよう。

図４Ａと同様に、図４Ｃは、一実施形態による、最後から２番目のバッファに書き込まれるヘッダのブロック図である。図４Ｃに示すように、ヘッダ２３５は、最後から２番目のバッファである宛先バッファ１５５（Ｎ−１）に書き込まれる。３２ビット即値データ３１０にヘッダオフセットを組み込む必要性によって必要とされるように、ヘッダ２３５は、ヘッダ境界で（例えば、６Ｋで）ヘッダ位置合わせされる。最後のバッファ内の利用可能空間には、データ（例えば、データ単位３０５（７）〜（１４））が完全に充填される。データ単位３０５（１）〜（６）は、宛先バッファ１５５（Ｎ−１）に書き込まれる。両方の宛先バッファ１５５（Ｎ−１）及び１５５（Ｎ）内のデータは、ページ境界で位置合わせされ、ヘッダ２３５もヘッダ境界で位置合わせされる。したがって、この例では、データ及びヘッダを書き込むために必要なバッファの最小数が使用され、かつ、電信上の無駄がない。

本明細書に記載されるような（例えば、図１に示すような）コンピューティングシステムが複数の受信バッファ（例えば、宛先バッファ１５５（１）〜（Ｎ））を有する場合、かつ、受信／宛先バッファの合計サイズが、位置合わせされたヘッダとページ境界で位置合わせされたデータとの合計よりも大きい場合、最後から２番目のバッファで位置合わせの終わりにヘッダを書き込むことにより、結果的にバッファの利用が最小限になり、電信上の無駄が軽減（又は排除）されることが理解されよう。このようにヘッダ及びデータを合体させることにより、結果的に、Ｉ／Ｏパフォーマンス及びアプリケーションスループットが向上することも理解されよう。
ヘッダ及びデータを合体させるための例示的なプロセス

図５Ａは、一実施形態による、バッファにデータ及びヘッダを充填するためのプロセスを示すフローチャートである。プロセスは、例えば、ホスト、仮想マシン、若しくはソースコンピューティングシステム１０５に通信可能に連結された他のタイプのコンピューティングシステムからの、又はソースコンピューティングシステム１０５上で実行される１つ以上のアプリケーションからの入力パラメータとして、ヘッダ（例えば、ヘッダ２３５）及びデータ（例えば、データ単位３０５（１）〜（１４））を受信することにより、５０５から始まる。５１０で、プロセスは、ヘッダ及びデータに必要なバッファ数を（例えば、バッファセレクタ２１５を使用することにより、かつ、データの一部として受信したデータ単位のサイズに基づいて）決定する。５１５で、プロセスは、データをページ（境界）に位置合わせして（例えば、ページ境界位置合わせ計算機２２５を使用する）、このマッピングを記録する。

５２０で、プロセスは、充填にする（例えば、データ（単位）を書き込む）データ専用バッファが存在するか否かを決定する。充填するデータ専用バッファが存在する場合、５２５で、プロセスは、バッファ（複数可）にデータを充填する（例えば、宛先バッファ１５５（１）〜（Ｎ−２））。充填するデータ専用バッファが存在しない場合、５３０で、プロセスは、最後から２番目のバッファ（例えば、宛先バッファ１５５（Ｎ−１））におけるヘッダの位置を決定する。５３５で、プロセスは、データを宛先バッファ１５５（Ｎ−２）まで充填する。５４０で、プロセスは、宛先バッファ１５５（Ｎ−１）内にデータ及びヘッダを充填する（例えば、図４Ａ及び図４Ｃに示すとおり）。５４５で、プロセスは、最後のバッファ（例えば、宛先バッファ１５５（Ｎ））に残りのデータを充填する。プロセスは、処理する別のメッセージが存在するかどうかを決定することにより、５５０で終了する。

図５Ｂは、一実施形態による、ヘッダ及びデータを結合するためのプロセスを示すフローチャートである。プロセスは、ソースバッファに含まれるデータ及びヘッダを受信することによって、５５５から始まる。５６０で、プロセスは、ヘッダ及びデータ配置解析を（例えば、ＲＤＭＡモジュール２１０を使用して）開始する。５６５で、プロセスは、利用可能なバッファのサイズ（例えば、８ｋ、１６ｋ、３２ｋなど）を計算する。５７０で、プロセスは、データ及びヘッダに必要なバッファの数（例えば、最小数）を（例えば、受信したデータ単位のサイズに基づいて）決定する。５７５で、プロセスは、識別されたバッファ内のデータに対して（例えば、ページ境界位置合わせ計算機２２５を使用して）ページ境界位置合わせを決定する。ページ境界位置合わせ計算機２２５はまた、ヘッダのヘッダ境界を決定できることに留意されたい。

５８０で、プロセスは、最後から２番目のバッファ内の（例えば、宛先バッファ１５５（Ｎ−１）内の）ヘッダの位置を決定する。例えば、宛先バッファ１５５（Ｎ−１）における、ページ境界に位置合わせされたデータの終わりの（例えば、図４Ａ及び図４Ｃに示すようにデータ単位３０５（６）の後の）、及びヘッダ境界（例えば、同じく図４Ａ及び図４Ｃに示すように、１ｋヘッダの２ｋ位置合わせの場合に６ｋで始まる）のヘッダ２３５の位置を決定し得る。５８５で、プロセスは、最小数の宛先バッファが利用され、データがページ境界に位置合わせされるように、宛先バッファにデータ及びヘッダを充填する。５９０で、プロセスは、結合されたヘッダ及びデータを、単一のＲＤＭＡ書き込み（例えば、ＲＤＭＡを介して送信されるメッセージ）内の配置／マッピング情報と共に、宛先（例えば、宛先計算機システム１４５）に送信する。プロセスは、処理する別のヘッダ及び（更なる）データが存在するかどうかを決定することにより、５９５で終了する。

図６は、一実施形態による、ヘッダ及びデータの配置／マッピング情報を決定するためのプロセスを示すフローチャートである。プロセスは、データ及びヘッダを受信することによって、６０５から始まる。６１０で、プロセスは、データ及びヘッダを書き込むのに必要なバッファの最小数を決定する。６１５で、プロセスは、選択されたバッファ内のデータ及びヘッダの配置を決定する。６２０で、プロセスは、データがページ境界に位置合わせされているか否か、及びデータが電信上の無駄を生じさせ得る最小数のギャップを有しているか否かを決定する。データがページ境界に位置合わせされていない場合、又はデータが電信上の無駄を生じさせ得る最小数のギャップ（又はゼロギャップ）を有していない場合、６２５で、プロセスは、データがページ境界に位置合わせされ、かつ最小限の（又はゼロ）ギャップを有する状態に維持されるよう、選択されたバッファ内のデータ及びヘッダの位置を再決定する。しかしながら、データが、ページ境界に位置合わせされ、電信上の無駄を生じさせ得る最小数のギャップ（又は更にはゼロキャップ）を有している場合、６３０で、プロセスは、選択されたバッファにデータ及びヘッダを充填する（例えば、図４Ａ及び図４Ｃに示すとおり）。プロセスは、処理する別のヘッダ及び（より多くの）データが存在するかどうかを決定することにより、６３５で終了する。

図７は、一実施形態による、ＲＤＭＡを使用してデータ及びヘッダを生成及び送信するためのプロセスを示すフローチャートである。プロセスは、データ及びヘッダを（例えば、ソースバッファから）受信する又はアクセスすることによって、７０５から始まる。７１０で、プロセスは、最小数のバッファが使用され、データがページ境界に位置合わせされ、ヘッダが位置合わせされ、電信上の無駄が最小限になる（又はなくなる）ように、データ及びヘッダをバッファに書き込む。

７１５で、プロセスは、ヘッダオフセット情報（例えば、ヘッダが特定の宛先バッファに書き込まれる場合、そのときのヘッダの位置）を３２ビット即値データ３１０（例えば、ＡＰＩ ２０５の一部として提供される３２ビットデータ空間）に組み込む。７２０で、プロセスは、ＲＤＭＡ書き込みを（例えば、ＲＤＭＡモジュール２１０を使用して）生成する。７２５で、プロセスは、ＲＤＭＡ書き込みを３２ビットの即値データ３１０と共に宛先に（例えば、宛先コンピューティングシステム１４５に）送信する。プロセスは、処理する別のヘッダ及び（更なる）データが存在するかどうかを決定することにより、７３０で終了する。

決定された配置／マッピング情報に基づいて、ソースバッファを１つ以上の宛先バッファにマッピングし、ヘッダ及びデータを特定の選択された宛先バッファ（複数可）に書き込むことにより、ヘッダ及びデータを合体させることで、結果的に、ＯＦＥＤベース及びＲＤＭＡ対応のコンピューティング環境において宛先バッファが効率的に利用され、電信上の無駄が軽減（又は更には排除）されることが理解されよう。本明細書に記載のシステム、方法、及びプロセスはまた、このようなコンピューティング環境において増大したＩ／Ｏパフォーマンス及びアプリケーションスループットを提供することができることも理解されよう。
例示的なコンピューティング環境

図８は、一実施形態による、配置及びマッピング情報モジュール８６５がソフトウェアに実装され得る態様を示すコンピューティングシステムのブロック図である。コンピューティングシステム８００は、コンピュータ可読命令を実行することができる任意のシングル又はマルチプロセッサコンピューティングデバイスあるいはシステムを広く表す。コンピューティングシステム８００の例としては、ワークステーション、パーソナルコンピュータ、ラップトップ、クライアント側端末、サーバ、分散型コンピューティングシステム、携帯用デバイス（例えば、パーソナル携帯情報機器、及び携帯電話）、ネットワークアプライアンス、ストレージコントローラ（例えば、アレイ、テープドライブ、又はハードディスクコントローラ）などを含む任意の１つ以上の様々なデバイスが挙げられるが、これらに限定されない。コンピューティングシステム８００は、少なくとも１つのプロセッサ８５５（例えば、ソースプロセッサ１１０又は宛先プロセッサ１７５）と、メモリ８６０（例えば、ソースメモリ１２０又は宛先メモリ１５０）と、を含んでもよい。ソースコンピューティングシステム１０５又は宛先コンピューティングシステム１４５を実装するソフトウェアを実行することにより、コンピューティングシステム８００は、ＯｐｅｎＦａｂｒｉｃｓ環境におけるスループットを改善するように構成された、特殊用途のコンピューティングデバイスとなる。

プロセッサ８５５は、データの処理、又は命令の解釈及び実行ができる任意のタイプ又は形式の処理装置を概して表す。特定の実施形態では、プロセッサ８５５は、ソフトウェアアプリケーション又はモジュールから命令を受信してもよい。これらの命令は、プロセッサ８５５に、本明細書に記載及び／又は例示する実施形態のうちの１つ以上の機能を実施させてもよい。例えば、プロセッサ８５５は、本明細書に記載する動作の全部若しくは一部を実行してもよく、及び／又は実行するための手段であってもよい。プロセッサ８５５は、また、本明細書に記載又は例示する任意の他の動作、方法、若しくはプロセスを実行してもよく、及び／又は実行するための手段であってもよい。

メモリ８６０は、データ及び／又は他のコンピュータ可読命令を記憶することが可能な任意のタイプ若しくは形式の揮発性若しくは不揮発性ストレージデバイス又は媒体を概して表す。例としては、ランダムアクセスメモリ（random access memory、ＲＡＭ）、読み取り専用メモリ（read only memory、ＲＯＭ）、フラッシュメモリ、又は任意の他の好適なメモリデバイスが挙げられるが、これらに限定されない。必須でないが、特定の実施例では、コンピューティングシステム８００は、揮発性メモリユニット及び不揮発性ストレージデバイスの両方を含んでもよい。一例において、配置及びマッピング情報モジュール８６５を実行するプログラム命令は、メモリ８６０（例えば、ソースメモリ１２０）にロードされてもよい。

特定の実施形態では、コンピューティングシステム８００はまた、プロセッサ８５５及び／又はメモリ８６０に加えて、１つ以上の構成要素又は要素を含んでもよい。例えば、図８に示すように、コンピューティングシステム８００は、メモリコントローラ８２０、入力／出力（Ｉ／Ｏ）コントローラ８３５、及び通信インターフェース８４５を含んでもよく、これらの各々は、通信インフラストラクチャ８０５を介して相互接続されてもよい。通信インフラストラクチャ８０５は、コンピューティングデバイスの１つ以上の構成要素間の通信を容易にすることが可能な任意のタイプ又は形式のインフラストラクチャを概して表す。通信インフラストラクチャ８０５の例としては、通信バス（業界標準アーキテクチャ（Industry Standard Architecture、ＩＳＡ）、周辺構成要素相互接続（Peripheral Component Interconnect、ＰＣＩ）、ＰＣＩエクスプレス（PCI express、ＰＣＩｅ）、又は類似のバスなど）、及びネットワークが挙げられるが、これらに限定されない。

メモリコントローラ８２０は、メモリ若しくはデータを取り扱うことが可能な、又はコンピューティングシステム８００の１つ以上の構成要素間の通信を制御することが可能な任意のタイプ又は形式のデバイスを概して表す。特定の実施形態では、メモリコントローラ８２０は、通信インフラストラクチャ８０５を介して、プロセッサ８５５、メモリ８６０、及びＩ／Ｏコントローラ８３５間の通信を制御してもよい。特定の実施形態では、メモリコントローラ８２０は、本明細書に記載又は例示する１つ以上の動作又は機能を単独又は他の要素との組み合わせのいずれかで実施してもよく、及び／又は実施するための手段であってもよい。

Ｉ／Ｏコントローラ８３５は、仮想マシン、アプライアンス、ゲートウェイ、及び／若しくはコンピューティングシステムの入出力機能を調整並びに／又は制御することが可能な任意のタイプ又は形式のモジュールを概して表す。例えば、特定の実施形態では、Ｉ／Ｏコントローラ８３５は、プロセッサ８５５（例えば、ソースプロセッサ１１０又は宛先プロセッサ１７５）、メモリ８６０（例えば、ソースメモリ１２０又は宛先メモリ１５０）、通信インターフェース８４５、表示アダプタ８１５、入力インターフェース８２５、及びストレージインターフェース８４０などの、ソースコンピューティングシステム１０５又は宛先コンピューティングシステム１４５の１つ以上の要素間のデータの転送を制御又は促進し得る。

通信インターフェース８４５は、コンピューティングシステム８００と、１つ以上の他のデバイスとの間の通信を容易にすることが可能な任意のタイプ又は形式の通信デバイス又はアダプタを広く表す。通信インターフェース８４５は、コンピューティングシステム８００と追加のコンピューティングシステムを含むプライベート又はパブリックネットワークとの間の通信を容易にし得る。通信インターフェース８４５の例としては、有線ネットワークインターフェース（ネットワークインターフェースカードなど）、無線ネットワークインターフェース（無線ネットワークインターフェースカードなど）、モデム、及び任意の他の好適なインターフェースを含むが、これらに限定されない。通信インターフェース８４５は、インターネットなどネットワークへの直接リンクを介してリモートサーバへの直接接続を提供してよく、また、例えば、ローカルエリアネットワーク（例えば、イーサネット（登録商標）ネットワーク）、パーソナルエリアネットワーク、電話若しくはケーブルネットワーク、携帯電話接続、衛星データ接続、又は任意の他の好適な接続を通じて、かかる接続を間接的に提供してよい。

通信インターフェース８４５はまた、外部バス又は通信チャネルを介して、コンピューティングシステム８００と、１つ以上の追加のネットワーク又はストレージデバイスとの間の通信を容易にするように構成されたホストアダプタを表してよい。ホストアダプタの例としては、スモールコンピュータシステムインターフェース（Small Computer System Interface、ＳＣＳＩ）ホストアダプタ、ユニバーサルシリアルバス（Universal Serial Bus、ＵＳＢ）ホストアダプタ、米国電気電子技術者協会（Electrical and Electronics Engineers、ＩＥＥＥ）１３９４ホストアダプタ、シリアルアドバンストテクノロジーアタッチメント（Serial Advanced Technology Attachment、ＳＡＴＡ）、シリアルアタッチトＳＣＳＩ（Serial Attached SCSI、ＳＡＳ）、及びエクスターナルＳＡＴＡ（external SATA、ｅＳＡＴＡ）ホストアダプタ、アドバンスドテクノロジーアタッチメント（Advanced Technology Attachment、ＡＴＡ）、及びパラレルＡＴＡ（Parallel ATA、ＰＡＴＡ）ホストアダプタ、ファイバチャネルインターフェースアダプタ、イーサネット（登録商標）アダプターなどが挙げられるが、これらに限定されない。通信インターフェース８４５はまた、コンピューティングシステム８００が、（例えば、実行するためにリモートデバイスに対して命令を送受信することにより）分散又はリモートコンピューティングに関与できるようにしてよい。

図８に示すように、コンピューティングシステム８００はまた、表示アダプタ８１５を介して、通信インフラストラクチャ８０５に接続されている、少なくとも１つの表示デバイス８１０を含んでもよい。表示デバイス８１０は、表示アダプタ８１５によって転送された情報を視覚的に表示することが可能な任意のタイプ又は形式のデバイスを概して表す。同様に、表示アダプタ８１５は、表示デバイス８１０上に表示するために、通信インフラストラクチャ８０５から（又は当該技術分野において既知のように、フレームバッファから）、グラフィックス、テキスト、及び他のデータを転送するように構成された任意のタイプ又は形式のデバイスを概して表す。コンピューティングシステム８００はまた、入力インターフェース８２５を介して通信インフラストラクチャ８０５に接続されている、少なくとも１つの入力デバイス８３０を含んでよい。入力デバイス８３０は、コンピュータ又はヒトのいずれかによって生成された入力を、コンピューティングシステム８００に提供することが可能な任意のタイプ又は形式の入力デバイスを概して表す。入力デバイス８３０の例としては、キーボード、ポインティングデバイス、音声認識デバイス、又は任意の他の入力デバイスが挙げられる。

コンピューティングシステム８００はまた、ストレージインターフェース８４０を介して通信インフラストラクチャ８０５に接続されているストレージデバイス８５０を含んでよい。ストレージデバイス８５０は、データ及び／又は他のコンピュータ可読命令を記憶することが可能な任意のタイプ又は形式のストレージデバイス又は媒体を概して表す。例えば、ストレージデバイス８５０としては、磁気ディスクドライブ（例えば、いわゆるハードドライブ）、フロッピーディスクドライブ、磁気テープドライブ、光ディスクドライブ、フラッシュドライブなどが挙げられ得る。ストレージインターフェース８４０は、コンピューティングシステム８００のストレージデバイス８５０と他の構成要素との間でデータを転送及び／又は送信するための任意のタイプ又は形式のインターフェース又はデバイスを概して表す。

ストレージデバイス８５０は、コンピュータソフトウェア、データ、又は他のコンピュータ可読情報を記憶するように構成されている、取り外し可能なストレージユニットから読み取るように、及び／又はそれに書き込むように構成されてよい。好適な取り外し可能なストレージユニットの例としては、フロッピーディスク、磁気テープ、光ディスク、フラッシュメモリデバイスなどが挙げられるが、これらに限定されない。ストレージデバイス８５０は、また、コンピュータソフトウェア、データ、又は他のコンピュータ可読命令が、コンピューティングシステム８００にロードされることを可能にするための他の類似の構造又はデバイスを含んでもよい。例えば、ストレージデバイス８５０は、ソフトウェア、データ、又は他のコンピュータ可読情報を読み取り、及び書き込むように構成されてもよい。ストレージデバイス８５０は、また、コンピューティングシステム８００の一部であってもよく、又は他のインターフェースシステムによってアクセスされる別個のデバイスであってもよい。

多くの他のデバイス又はサブシステムは、コンピューティングシステム８００に接続されてもよい。逆に、図８に示す構成要素及びデバイスの全てが、本明細書において説明及び／又は例示される実施形態を実践するために存在する必要があるわけではない。上で述べたデバイス及びサブシステムはまた、図８に示すものとは異なる様式で相互接続されてもよい。

コンピューティングシステム８００はまた、任意の数のソフトウェア、ファームウェア、及び／又はハードウェア構成を採用してもよい。例えば、本明細書において開示される実施形態のうちの１つ又は２つ以上は、コンピュータ可読ストレージ媒体上にコンピュータプログラム（コンピュータソフトウェア、ソフトウェアアプリケーション、コンピュータ可読命令、又はコンピュータ制御論理とも称される）としてコード化され得る。コンピュータ可読ストレージ媒体の例としては、磁気ストレージ媒体（例えば、ハードディスクドライブ、及びフロッピーディスク）、光ストレージメディア（例えば、ＣＤ−、又はＤＶＤ−ＲＯＭ）、電子ストレージ媒体（例えば、ソリッドステートドライブ、及びフラッシュメディア）などが挙げられる。そのようなコンピュータプログラムはまた、インターネットなどのネットワークを介してメモリに又はキャリア媒体に記憶するためにコンピューティングシステム８００に転送されてもよい。

コンピュータプログラムを含むコンピュータ可読媒体は、コンピューティングシステム８００にロードされてもよい。コンピュータ可読媒体上に記憶されたコンピュータプログラムの全部又は一部は、次に、メモリ８６０及び／又はストレージデバイス８５０の種々の部分に記憶されてもよい。プロセッサ８５５によって実行されるとき、コンピューティングシステム８００にロードされたコンピュータプログラムは、本明細書において説明及び／又は例示する実施形態のうちの１つ以上の機能をプロセッサ８５５に実施させてもよく、及び／又はそれらを実施するための手段であってもよい。付加的に又は代替的に、本明細書に説明及び／又は例示される例示的な実施形態のうちの１つ又は２つ以上は、ファームウェア及び／又はハードウェアに実装され得る。例えば、コンピューティングシステム８００は、本明細書において開示される実施形態のうちの１つ又は２つ以上を実行するように適合された特定用途向け集積回路（application specific integrated circuit、ＡＳＩＣ）として構成されてもよい。
例示的なネットワーキング環境

図９は、本開示の一実施形態による、様々なデバイスがネットワークを介して通信し得る態様を例示する、ネットワーク化されたシステムのブロック図である。特定の実施形態では、ネットワーク接続型ストレージ（ＮＡＳ）デバイスは、ネットワークファイルシステム（ＮＦＳ）、サーバメッセージブロック（ＳＭＢ）、又はコモンインターネットファイルシステム（ＣＩＦＳ）などの様々なプロトコルを使用して、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５と通信するように構成されてもよい。ネットワーク１８０は、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５間の通信を促進することができる任意のタイプ若しくは形式のコンピュータネットワーク又はアーキテクチャを概して表す。

特定の実施形態では、図８の通信インターフェース８４５などの通信インターフェースは、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５と、ネットワーク１８０との間の接続性を提供するために使用され得る。本明細書に記載及び／又は例示する実施形態は、インターネット又は任意の特定のネットワークベース環境に限定されないことに留意されたい。例えば、ネットワーク１８０は、ストレージエリアネットワーク（ＳＡＮ）であってもよい。

一実施形態では、開示する実施形態のうちの１つ以上の全体又は一部は、コンピュータプログラムとしてコード化されてよく、また、ソースコンピューティングシステム１０５及び／若しくは宛先コンピューティングシステム１４５、又はそれらの任意の組み合わせにロードされて実行されてもよい。本明細書で開示する実施形態のうちの１つ以上の全体又は一部はまた、コンピュータプログラムとしてコード化され、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５に記憶され、ネットワーク１８０を介して分散されてもよい。いくつかの例では、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５の全体又は一部は、クラウドコンピューティング又はネットワークベース環境の部分を表してもよい。クラウドコンピューティング環境は、インターネットを介して、種々のサービス及びアプリケーションを提供し得る。これらのクラウドベースのサービス（例えば、サービスとしてのソフトウェア、サービスとしてプラットフォーム、サービスとしてのインフラストラクチャなど）は、ウェブブラウザ又は他の遠隔インターフェースを通じて、アクセス可能であり得る。本明細書において説明される種々の機能は、遠隔デスクトップ環境又は任意の他のクラウドベースのコンピューティング環境を通じて提供され得る。

加えて、本明細書に記載の構成要素のうちの１つ又は２つ以上は、データ、物理的デバイス、及び／又は物理的デバイスの表現を、ある形態から他の形態に変換し得る。例えば、配置及びマッピング情報モジュール８６５は、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５にＯｐｅｎＦａｂｒｉｃｓ及びＲＤＭＡコンピューティング環境におけるスループットを改善させるため、ソースコンピューティングシステム１０５及び／又は宛先コンピューティングシステム１４５の挙動を変換し得る。

本開示がいくつかの実施形態と関連して説明してきたが、本開示は、本明細書で述べた特定の形式に限定されるように意図されていない。逆に、添付の請求項によって規定されるような本開示の範囲内に合理的に含まれ得るような代替形態、修正形態、及び等価物を包含するように意図されている。

Claims (18)

1. コンピューティングシステムに実装されたコンピュータ実装方法であって、
   前記コンピューティングシステムで、データと、前記データについての情報を含むヘッダを受信することと、
   前記コンピューティングシステムのプロセッサを使用し、前記データ及び前記ヘッダをまとめて記憶するように構成されたバッファの最小数を決定することであって、前記最小数は二以上の整数である、ことと、
   前記プロセッサを使用し、前記データ及び前記ヘッダの前記バッファ内の配置情報を決定することであって、
   前記配置情報は、
   各前記バッファのサイズ、
   前記データのページ境界位置合わせ、及び
   前記ヘッダのヘッダ位置合わせに少なくとも部分的に基づいて決定され、
   前記配置情報は、最後から２番目のバッファを識別する、ことと、
   前記データ及び前記ヘッダを前記バッファに書き込むことであって、
   前記バッファは、前記コンピューティングシステムのメモリに含まれ、
   前記データは、前記配置情報を使用して書き込まれ、
   前記データは、前記メモリのページ境界に書き込まれ、
   前記ヘッダは、前記最後から２番目のバッファのヘッダ境界に書き込まれる、ことと、を含む、方法。
2. 前記データ及び前記ヘッダは、前記コンピューティングシステムのネットワークアダプタで受信され、
   前記ネットワークアダプタは、前記コンピューティングシステムをネットワークに通信可能に連結され、
   前記バッファ及び前記ヘッダを前記書き込むことにおいて前記配置情報を使用することが、結果的に、
   最小数のバッファを利用し、
   前記データが前記最小数のバッファに書き込まれるときに、ページ境界に位置合わせされ、
   前記データ及び前記ヘッダを送信するときに前記ネットワーク上で送信されるデータ量を削減する、ことになる、請求項１に記載の方法。
3. リモートダイレクトメモリアクセス書き込みメッセージに前記データ及び前記ヘッダを結合することであって、
   前記結合することは、
   複数のソースバッファ内に含まれる前記ヘッダ及び前記データを前記配置情報に基づいて前記バッファにマッピングすることを含む、こと、を更に含む、請求項１に記載の方法。
4. 前記最小数のバッファにおいて前記データをページ境界に位置合わせできない場合に、１つ以上の追加バッファを選択することであって、
   前記１つ以上の追加バッファは、前記メモリに含まれる、こと、を更に含む、請求項１に記載の方法。
5. 前記最小数のバッファが１つ以上の宛先バッファを含み、
   前記１つ以上の宛先バッファは、前記メモリに含まれる、請求項１に記載の方法。
6. 前記リモートダイレクトメモリアクセス書き込みメッセージは、３２ビット情報記憶領域を含む、請求項３に記載の方法。
7. ヘッダオフセットを前記３２ビット情報記憶領域に組み込むことであって、
   前記ヘッダオフセットは、前記リモートダイレクトメモリアクセス書き込みメッセージにおける前記ヘッダのオフセットである、こと、を更に含む、請求項６に記載の方法。
8. コンピュータに方法を実行させるためのプログラム命令を記憶するコンピュータ可読ストレージ媒体（ＣＲＳＭ）であって、前記方法は、
   前記コンピュータで、データと、前記データについての情報を含むヘッダを受信することと、
   前記コンピュータのプロセッサを使用し、前記データ及び前記ヘッダをまとめて記憶するように構成されたバッファの最小数を決定することであって、前記最小数は二以上の整数である、ことと、
   前記コンピュータのプロセッサを使用し、前記データ及び前記ヘッダの前記バッファ内の配置情報を決定することであって、
   前記配置情報は、
   各前記バッファのサイズ、
   前記データのページ境界位置合わせ、及び、
   前記ヘッダのヘッダ位置合わせに少なくとも部分的に基づいて決定され、
   前記配置情報は、最後から２番目のバッファを識別する、ことと、
   前記データ及び前記ヘッダを前記バッファに書き込むことであって、
   前記バッファは、前記コンピュータのメモリに含まれ、
   前記データは、前記配置情報を使用して書き込まれ、
   前記データは、前記メモリのページ境界に書き込まれ、
   前記ヘッダは、前記最後から２番目のバッファのヘッダ境界に書き込まれる、ことと、を含む、ＣＲＳＭ。
9. 前記データ及び前記ヘッダは、前記コンピュータのネットワークアダプタで受信され、
   前記ネットワークアダプタは、前記コンピュータをネットワークに通信可能に連結され、
   前記バッファ及び前記ヘッダを前記書き込むことにおいて前記配置情報を使用することが、結果的に、
   最小数のバッファを利用し、
   前記データが前記最小数のバッファに書き込まれるときに、ページ境界に位置合わせされ、
   前記データ及び前記ヘッダを送信するときに前記ネットワーク上で送信されるデータ量を削減する、ことになる、請求項８に記載のＣＲＳＭ。
10. 前記方法は、
    リモートダイレクトメモリアクセス書き込みメッセージに前記データ及び前記ヘッダを結合することであって、
    前記結合することは、
    複数のソースバッファ内に含まれる前記ヘッダ及び前記データを前記配置情報に基づいて前記バッファにマッピングすることを含み、
    前記リモートダイレクトメモリアクセス書き込みメッセージは、３２ビット情報記憶領域を含む、ことと、
    ヘッダオフセットを前記３２ビット情報記憶領域に組み込むことであって、
    前記ヘッダオフセットは、前記リモートダイレクトメモリアクセス書き込みメッセージの前記ヘッダにおけるオフセットである、ことと、を更に含む、請求項８に記載のＣＲＳＭ。
11. 前記方法は、
    前記最小数のバッファにおいて前記データをページ境界に位置合わせできない場合に、１つ以上の追加バッファを選択することであって、
    前記１つ以上の追加バッファは、前記メモリに含まれる、こと、を更に含む、請求項８に記載のＣＲＳＭ。
12. 前記最小数のバッファが１つ以上の宛先バッファを含み、
    前記１つ以上の宛先バッファは、前記メモリに含まれる、請求項８に記載のＣＲＳＭ。
13. コンピューティングシステムであって、
    １つ以上のプロセッサと、
    前記１つ以上のプロセッサに結合されたメモリと、
    前記１つ以上のプロセッサに結合されたコンピュータ可読ストレージ媒体と、を備え、
    前記コンピュータ可読ストレージ媒体は、方法を実行するために前記１つ以上のプロセッサによって実行可能なプログラム命令を記憶し、前記方法は、
    前記コンピューティングシステムで、データと、前記データについての情報を含むヘッダを受信することと、
    前記１つ以上のプロセッサを使用し、前記データ及び前記ヘッダをまとめて記憶するように構成されたバッファの最小数を決定することであって、前記最小数は二以上の整数である、ことと、
    前記１つ以上のプロセッサを使用し、前記データ及び前記ヘッダの前記バッファ内の配置情報を決定することであって、
    前記配置情報は、
    各前記バッファのサイズ、
    前記データのページ境界位置合わせ、及び
    前記ヘッダのヘッダ位置合わせに少なくとも部分的に基づいて決定され、
    前記配置情報は、最後から２番目のバッファを識別する、ことと、
    前記データ及び前記ヘッダを前記バッファに書き込むことであって、
    前記バッファは、前記コンピューティングシステムのメモリに含まれ、
    前記配置情報は、前記１つ以上のプロセッサにより実行可能な前記プログラム命令によって、前記データ及び前記ヘッダを前記バッファに書き込み、前記データを前記バッファに書き込むために使用され、
    前記データは、前記メモリのページ境界に書き込まれ、
    前記ヘッダは、前記最後から２番目のバッファのヘッダ境界に書き込まれる、ことと、を含む、システム。
14. 前記データ及び前記ヘッダは、前記コンピューティングシステムのネットワークアダプタで受信され、
    前記ネットワークアダプタは、前記コンピューティングシステムをネットワークに通信可能に連結され、
    前記バッファ及び前記ヘッダを前記書き込むことにおいて前記配置情報を使用することが、結果的に、
    最小数のバッファを利用し、
    前記データが前記最小数のバッファに書き込まれるときに、ページ境界に位置合わせされ、
    前記データ及び前記ヘッダを送信するときに前記ネットワーク上で送信されるデータ量を削減する、ことになる、請求項１３に記載のシステム。
15. 前記ヘッダ及び前記データは、リモートダイレクトメモリアクセス書き込みメッセージに含まれ、前記リモートダイレクトメモリアクセス書き込みメッセージは、３２ビット情報記憶領域を更に含み、前記方法は、
    ヘッダオフセットを３２ビット情報記憶領域に組み込むことであって、
    前記ヘッダオフセットは、前記リモートダイレクトメモリアクセス書き込みメッセージにおける前記ヘッダのオフセットである、こと、を更に含む、請求項１３に記載のシステム。
16. 前記方法は、
    リモートダイレクトメモリアクセス書き込みメッセージに前記データ及び前記ヘッダを結合することであって、
    前記結合することは、
    複数のソースバッファ内に含まれる前記ヘッダ及び前記データを前記配置情報に基づいて前記バッファにマッピングすることを含み、
    前記リモートダイレクトメモリアクセス書き込みメッセージは、３２ビット情報記憶領域を含む、ことと、
    ヘッダオフセットを前記３２ビット情報記憶領域に組み込むことであって、
    前記ヘッダオフセットは、前記リモートダイレクトメモリアクセス書き込みメッセージにおける前記ヘッダのオフセットである、ことと、を更に含む、請求項１３に記載のシステム。
17. 前記方法は、
    前記最小数のバッファにおいて前記データをページ境界に位置合わせできない場合に、前記１つ以上の追加バッファを選択することであって、
    前記１つ以上のバッファは、前記メモリに含まれる、こと、を更に含む、請求項１３に記載のシステム。
18. 前記最小数のバッファが１つ以上の宛先バッファを含み、
    前記１つ以上の宛先バッファは、前記メモリに含まれる、請求項１３に記載のシステム。

Images