(57)【要約】電気通信ネットワークにおいてモデムの上で使用するためのマルチ・コア・プロセッサにおけるバッファ管理メカニズムが、本明細書において説明される。バッファ管理メカニズムは、１つまたは複数のレイヤ２アプリケーションについてのバッファ管理サービスを提供するバッファ・モジュールを含んでおり、そこではバッファ・モジュールは、ユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間アプリケーション・インターフェースを少なくとも提供する。バッファ管理メカニズムはまた、複数の、トークンの別個のプールを管理するバッファ・マネージャも含んでおり、そこでは、それらのトークンは、外部メモリにおけるメモリ・エリアに対するポインタを含んでいる。さらに、バッファ管理メカニズムは、ユーザ・プレーン・データの配信のために使用されるバッファ・プールおよびフレーム待ち行列を含むデータ・パス加速アーキテクチャ（ＤＰＡＡ）リソースを管理するカスタム・ドライバを含んでいる。
2013546068.tif 000002
【特許請求の範囲】
【請求項１】
電気通信ネットワークにおいてモデムの上で使用するためのマルチ・コア・プロセッサにおいて、バッファ管理メカニズムであって、
１つまたは複数のレイヤ２アプリケーションについてのロックレスのゼロ・コピー・バッファ管理サービスを提供するバッファ・モジュールを備え、前記バッファ・モジュールはユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間アプリケーション・インターフェースを少なくとも提供し、さらに、
トークンの複数の別個のプールを管理するバッファ・マネージャを備え、前記トークンは、外部カーネル空間メモリにおけるメモリ・エリアに対するポインタを含み、さらに、
ユーザ・プレーン・データの配信のために使用されるバッファ・プールおよびフレーム待ち行列を含むデータ・パス加速アーキテクチャ（ＤＰＡＡ）リソースを管理するカスタム・ドライバを備え、前記カスタム・ドライバは、
前記外部カーネル空間メモリの隣接チャンクを獲得し、
さもなければ、カーネル・ツー・ユーザ−空間境界をデータが横切るときはいつでも生じるデータ・コピーを取り除くために、前記外部カーネル空間メモリに記憶されるデータへのユーザ・モード・アプリケーション・アクセスを可能にするように、カーネル空間メモリの前記隣接チャンクをユーザ空間にマッピングし、
プールの数と、プール当たりのトークンの数と、前記トークンが指し示す前記バッファのサイズとを初期化し、そして、
トークンを用いて前記プールをシーディングする、
ことにより、前記バッファ・モジュールについての事前に割り付けられたメモリをロックレスのゼロ・コピー・バッファ管理に提供するようにさらに動作する、バッファ管理メカニズム。
【請求項２】
前記バッファ・モジュールは、さらに、以下のサービス、すなわち、
バッファを獲得するサービスと、
与えられた数の、与えられたサイズのバッファを獲得し、次いで前記要求された数のバッファまでの使用可能なバッファのリストを戻すサービスと、
指定されたバッファを解放するサービスと、
バッファのリストを解放するサービスと、
バッファ・プール統計データについて問い合わせを行うサービスと
のうちの１つまたは複数をサポートするゼロ・コピーおよびロックレスのアプリケーション・プログラミング・インターフェースを実装し、また提供するように動作する、請求項１に記載のバッファ管理メカニズム。
【請求項３】
前記メモリ・チャンクの開始アドレスは、前記バッファ・プールについてのシード値を計算するときに、ベース・ポインタとして使用される、請求項１に記載のバッファ管理メカニズム。
【請求項４】
前記バッファ・マネージャは、さらに、ロックレス・ハードウェア（ＤＰＡＡ）調停を使用し、またパケットが到着した後に前記プールからトークンを待ち行列から取り出し、またバッファが解放されるときに、前記トークンを前記プール上へと戻して待ち行列に加えるように動作する、請求項１に記載のバッファ管理メカニズム。
【請求項５】
前記バッファ・マネージャは、さらに、複数のコアから同時にバッファまたはトークンについての要求を受信し、またソフトウェアでのソフトウェア・ロックまたはブロッキング・セマフォの必要なしに、ハードウェアでのロックレス調停を実行するように動作する、請求項１に記載のバッファ管理メカニズム。
【請求項６】
電気通信ネットワークにおいてマルチ・セル・サポートを提供する装置であって、
モデム・ボードと、
前記モデム・ボードに取り付けられた複数のプロセッサ・コアを含むマルチ・コア・プロセッサを備え、単一のパーティションが、その中に含まれる前記プロセッサ・コアのすべてを用いて規定され、また前記単一のパーティションを使用して、すべての制御プレーン機能、およびすべてのデータ・プレーン機能、ならびに前記単一のパーティションにおいて前記プロセッサ・コアの上で実行されるアプリケーション・ソフトウェアから任意のコア特有の詳細を隠すコア抽象化レイヤを実行し、
前記コア抽象化レイヤは、少なくとも以下のモジュール、すなわち、
１つまたは複数のレイヤ２アプリケーションについてのロックレスのゼロ・コピー・バッファ管理サービスを提供するバッファ・モジュールであって、ユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間アプリケーション・インターフェースを少なくとも提供するバッファ・モジュールと、
複数の、トークンの別個のプールを管理するバッファ・マネージャであって、前記トークンは、外部カーネル空間メモリにおけるメモリ・エリアに対するポインタを含む、バッファ・マネージャと、
ユーザ・プレーン・データの配信のために使用されるバッファ・プールおよびフレーム待ち行列を含むデータ・パス加速アーキテクチャ（ＤＰＡＡ）リソースを管理するカスタム・ドライバと
を備え、前記カスタム・ドライバは、さらに、
前記外部カーネル空間メモリの隣接チャンクを獲得し、
さもなければ、カーネル・ツー・ユーザ−空間境界をデータが横切るときはいつでも生じるデータ・コピーを取り除くために、前記外部カーネル空間メモリに記憶されるデータへのユーザ・モード・アプリケーション・アクセスを可能にするように、カーネル空間メモリの前記隣接チャンクをユーザ空間にマッピングし、
プールの数と、プール当たりのトークンの数と、前記トークンが指し示す前記バッファのサイズとを初期化し、そして、
トークンを用いて前記プールをシーディングする、
ことにより、前記バッファ・モジュールについての事前に割り付けられたメモリをロックレスのゼロ・コピー・バッファ管理に提供するように動作する、装置。
【請求項７】
前記バッファ・モジュールは、さらに、以下のサービス、すなわち、
バッファを獲得するサービスと、
与えられた数の、与えられたサイズのバッファを獲得し、次いで前記要求された数のバッファまでの使用可能なバッファのリストを戻すサービスと、
指定されたバッファを解放するサービスと、
バッファのリストを解放するサービスと、
バッファ・プール統計データについて問い合わせを行うサービスと
のうちの１つまたは複数をサポートするゼロ・コピーおよびロックレスのアプリケーション・プログラミング・インターフェースを実装し、また提供するように動作する、請求項５に記載の装置。
【請求項８】
前記メモリ・チャンクの開始アドレスは、前記バッファ・プールについてのシード値を計算するときに、ベース・ポインタとして使用される、請求項５に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示の実施形態は、マルチ・コア・プロセッサを使用した、単一のモデム・ボードの上のマルチ・セル・サポートのためのロックレス・バッファ管理スキームに関する。本発明は、特にワイヤレス電気通信の技術を対象としており、またそれゆえにそれに特に関連して説明されることになるが、本発明は、他の分野およびアプリケーションにおいても有用性を有し得ることが、理解されるであろう。
【背景技術】
【０００２】
背景として、ＬＴＥ（ロング・ターム・エボリューション（Ｌｏｎｇ  Ｔｅｒｍ  Ｅｖｏｌｕｔｉｏｎ））は、将来の通信ネットワーク需要に対処するようにＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーション・システム（Ｕｎｉｖｅｒｓａｌ  Ｍｏｂｉｌｅ  Ｔｅｌｅｃｏｍｍｕｎｉｃａｔｉｏｎｓ  Ｓｙｓｔｅｍ））モバイル電話規格を改善することを目指す急速に進化する３ＧＰＰプロジェクトである。ＬＴＥは、ワイヤレス・ネットワークの効率および帯域幅を改善し、コストを低減させ、またサービス経験を向上させる。具体的には、ＬＴＥは、新しいスペクトルの機会を使用し、また他のオープンな規格とのよりよい統合を提供する。ＬＴＥは、一般に、ＥＰＳ（進化型パケット・システム、進化型パケット・コアとも呼ばれる）と一緒にＬＴＥ  ＲＡＮ（無線アクセス・ネットワーク（Ｒａｄｉｏ  Ａｃｃｅｓｓ  Ｎｅｔｗｏｒｋ））（Ｅ−ＵＴＲＡＮとしても知られている）を含んでいる。
【０００３】
通信システムは、一般に、２つの主要な機能、すなわち、データ・プレーン機能と、制御プレーン機能とに分割される。以前のＬＴＥ製品においては、少なくとも２つのプロセッサ、すなわち制御プレーン機能（非リアル・タイム、例えば、オペレーション、統治、および管理（またはＯＡ＆Ｍ）に関連した機能、ならびにコール処理管理に関連した機能）をサポートする１つのプロセッサと、データ・プレーン機能（リアル・タイム、例えば、ＬＴＥレイヤ２処理）を終端し、サポートする別のプロセッサとが、モデム・ボードの上で使用された。制御プレーンと、データ・プレーンとの両方は、制御プレーンについてのＬｉｎｕｘやデータ・プレーン・コアについてのｖＸＷｏｒｋｓ（カリフォルニア州、アラメダ市のウィンド・リバー・システムズ（Ｗｉｎｄ  Ｒｉｖｅｒ  Ｓｙｓｔｅｍｓ）によって作られ、また販売される）などのリアル・タイムＯＳなど、異なるオペレーティング・システム（ＯＳ：ｏｐｅｒａｔｉｎｇ  ｓｙｓｔｅｍ）インスタンスを使用した。一般的に、１つのモデム・ボードは、１つのセクタまたはセルをサポートする。そのようにしてマルチ・セル（例えば、３−セルまたは６−セル）構成をサポートするためには、セルの数と同じ数のモデム・ボードを提供することが、必要となる。
【０００４】
マルチ・コア・プロセッサは、モデム・ボードの上のＬＴＥワイヤレス基地局において使用されることもある。ＰＲＥＥＭＰＴ＿ＲＴパッチが、すべての８つのコアを含む１つのＳＭＰパーティションの上で実行されるＳＭＰリナックス（ＳＭＰ  Ｌｉｎｕｘ）などのオペレーティング・システムがある。この構成においては、制御プレーン（非−リアル・タイム・スレッド／プロセス）と、データ・プレーン（リアル・タイム・スレッド／プロセス）とは、たとえそれらが、異なるコアの上で実行されなければならないとしても、同じオペレーティング・システム・インスタンスを共用する。
【０００５】
したがって、ロックレスであるバッファ管理スキームについての必要性があり、そうでなければ、無制限のレイテンシー・スパイク（ｌａｔｅｎｃｙ  ｓｐｉｋｅｓ）が、結果として起こることもある。そのような状況は、ＬＴＥレイヤ２のリアル・タイム処理の必要性をひどく危うくし、または破壊する可能性がある。ＳＭＰ環境においては、１つのコアの上で非リアル・タイムのプロセスまたはスレッドによってかけられる（ｔａｋｅｎ）ロックは、そのロックが異なるコアの上で解放されることを待つリアル・タイムのスレッドまたはプロセスについてのレイテンシー・スパイクを引き起こす可能性がある。
【発明の概要】
【発明が解決しようとする課題】
【０００６】
本明細書においては、ＳＭＰ環境におけるロックレス・バッファ管理スキームが、説明されている。例示の実施形態は、マルチ・コアからのバッファについての同時アクセスの調停をするバッファ・マネージャ（ＢＭａｎ：ｂｕｆｆｅｒ  ｍａｎａｇｅｒ）など、モデム・ボードの上のハードウェア・コンポーネントを利用している。ソフトウェア・ロックがかけられないので、ロックが解放されることを待つ一方で、プロセスまたはスレッドは、ブロックされないことになる。ＰＲＥＥＭＰＴ＿ＲＴを有するＳＭＰリナックスなどのオペレーティング・システム（ＯＳ）は、ｖｘＷｏｒｋｓなどのハード・コア・リアル・タイムＯＳではない。それゆえに、そのようなバッファリング・スキームを規定することが重要であり、そうでなければ、オペレーティング・システムは、ＬＴＥレイヤ２スケジューラのリアル・タイム処理の必要性を満たさないこともある。アプリケーション・ソフトウェアの観点から、ハードウェア調停は、まるで様々なコアからのバッファについてのすべての要求が、同時に、どのようなプロセスまたはスレッドもブロックされることなく、ほとんど並列に処理されているかのように見えるようにすることになる。その結果、無制限のレイテンシー・スパイクが、存在しないことになる。
【０００７】
本明細書においては、ＳＭＰリナックスについてのゼロ・コピー・バッファ管理スキームもまた説明されており、これによってデータは、ユーザ空間アプリケーションによって送信され、または受信される。ユーザ・ツー・カーネル−空間（ｕｓｅｒ−ｔｏ−ｋｅｒｎｅｌ−ｓｐａｃｅ）境界を通してゼロ・コピーを達成するために、バッファ・メモリは、カーネル・ツー・ユーザ−空間（ｋｅｒｎｅｌ−ｔｏ−ｕｓｅｒ−ｓｐａｃｅ）マッピングされる必要がある。メモリの隣接チャンクを割り付けることにより、それは、バッファ・プール（ｂｕｆｆｅｒ  ｐｏｏｌｓ）のカーネル・ツー・ユーザ−空間マッピングとシーディング（ｓｅｅｄｉｎｇ）とをより簡単にする。指定されたプールにおける特定のバッファについてのポインタ・アドレスを計算する数式を有することは、バッファ管理スキームをより決定論的に、また堅牢にし、またそれは、バッファ管理のブック・キーピング・アクティビティと、ガーベージ・コレクション・アクティビティとにおいて大きな助けを提供する。これはまた、メモリ破損についての効率的なチェックを実装する際にも助けとなるであろう。
【０００８】
処理環境において、ミドルウェア・レイヤは、一般的に、アプリケーション・レイヤからすべてのハードウェア特有の実装の詳細を隠す。コア抽象化レイヤ（ＣＡＬ：ｃｏｒｅ  ａｂｓｔｒａｃｔｉｏｎ  ｌａｙｅｒ）は、マルチ・コア・プロセッサと、そのデータ・パス加速アーキテクチャ（Ｄａｔａ  Ｐａｔｈ  Ａｃｃｅｌｅｒａｔｉｏｎ  Ａｒｃｈｉｔｅｃｔｕｒｅ）（またはＤＰＡＡ）についての抽象化を提供する。このモデム・ボードの展開では、ＣＡＬは、ＬＴＥ  Ｌ２アプリケーションについてのゼロ・コピー・ロックレス・バッファ管理スキームなど、様々なサービスと、マルチ・セル構成についての、無線リンク制御（ＲＬＣ：Ｒａｄｉｏ  Ｌｉｎｋ  Ｃｏｎｔｒｏｌ）サービス・データ・ユニット（ＳＤＵ：Ｓｅｒｖｉｃｅ  Ｄａｔａ  Ｕｎｉｔ）の制御装置ボードに対する送信と制御装置ボードからの受信とについてのバックプレーン・イーサネット・ドライバ（ＢＥＤ：Ｂａｃｋｐｌａｎｅ  Ｅｔｈｅｒｎｅｔ  ｄｒｉｖｅｒ）インターフェースについてのサポートとを提供する。
【課題を解決するための手段】
【０００９】
本発明の一態様においては、電気通信ネットワークにおいてモデムの上で使用するためのマルチ・コア・プロセッサにおけるバッファ管理メカニズムが、提供される。バッファ管理メカニズムは、１つまたは複数のレイヤ２アプリケーションについてのバッファ管理サービスを提供するバッファ・モジュールを含んでおり、そこではバッファ・モジュールは、ユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間アプリケーション・インターフェースを少なくとも提供する。バッファ管理メカニズムはまた、複数の、トークンの別個のプールを管理するバッファ・マネージャも含んでおり、そこでは、それらのトークンは、外部メモリにおけるメモリ・エリアに対するポインタを含んでいる。さらに、バッファ管理メカニズムは、ユーザ・プレーン・データの配信のために使用されるバッファ・プールおよびフレーム待ち行列を含むデータ・パス加速アーキテクチャ（ＤＰＡＡ）リソースを管理するカスタム・ドライバを含んでいる。
【００１０】
オプションとして、カスタム・ドライバは、さらに、一連の機能を実行するように動作することもできる。例えば、カスタム・ドライバは、外部メモリの隣接チャンクを獲得することができる。次に、カスタム・ドライバは、カーネル空間メモリをユーザ空間にマッピングして、データ・コピーを実行する必要なしに、外部メモリに記憶されるデータへのユーザ・モード・アプリケーション・アクセスを可能にすることができる。カスタム・ドライバはまた、プールの数と、プール当たりのトークンの数と、それらのトークンが指し示すバッファのサイズとを初期化することもできる。最終的に、カスタム・ドライバは、トークンでプールをシーディングする（ｓｅｅｄ）ことができる。
【００１１】
本発明の別の態様においては、電気通信ネットワークにおいてマルチ・セル・サポートを提供するための装置が、提供される。本装置は、一般に、モデム・ボードと、そのモデム・ボードに取り付けられる複数のプロセッサ・コアを備えるマルチ・コア・プロセッサとを含む。マルチ・コア・プロセッサに関連して、単一のパーティションが、その中に含まれるプロセッサ・コアのすべてを用いて規定され、またそこで単一のパーティションを使用して、すべての制御プレーン機能と、すべてのデータ・プレーン機能とを実行する。さらに、コア抽象化レイヤは、単一のパーティションにおけるプロセッサ・コアの上で実行されるアプリケーション・ソフトウェアから任意のコア特有の詳細を隠す。コア抽象化レイヤは、１つまたは複数のレイヤ２アプリケーションについてのバッファ管理サービスを提供するバッファ・モジュールを含んでおり、そこではバッファ・モジュールは、ユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間アプリケーション・インターフェースを少なくとも提供する。コア抽象化レイヤはまた、複数の、トークンの別個のプールを管理するバッファ・マネージャも含んでおり、そこではそれらのトークンは、外部メモリにおけるメモリ・エリアに対するポインタを含んでいる。さらに、コア抽象化レイヤは、ユーザ・プレーン・データの配信のために使用されるバッファ・プールおよびフレーム待ち行列を含むデータ・パス加速アーキテクチャ（ＤＰＡＡ）リソースを管理するカスタム・ドライバを含んでいる。
【００１２】
本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の精神および範囲の内部の様々な変更形態および修正形態が、当業者には明らかになるので、詳細な説明と特定の例とは、本発明の好ましい実施形態を示しながら、例証だけとして与えられていることを理解されたい。
【００１３】
本発明は、デバイスの構造、構成、および様々な部分の組合せと、方法のステップとの中に存在しており、これによって、企図される目的は、以降でより十分に説明され、特に特許請求の範囲の中で指摘され、また添付の図面において示されるように、達成される。
【図面の簡単な説明】
【００１４】
【図１】本発明の態様に従って、プラットフォーム・アーキテクチャの一実施形態を示す図である。
【図２】図１に示されるコア抽象化レイヤを実装するための例示のアーキテクチャを示す図である。
【図３】マルチ・コア・プロセッサを使用した単一のモデム・ボードの上のマルチ・セル・サポートのための例示のロックレス・バッファ管理スキームを示す図である。
【図４】メモリおよびバッファ・プールの獲得およびシーディングの高レベルの図である。
【発明を実施するための形態】
【００１５】
ここで図面を参照すると、それらの提示は例示の実施形態だけを示す目的のためであり、請求する主題を限定する目的のためではないが、図１では、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供している。ここで図１を参照すると、例示のプラットフォーム・アーキテクチャ１００が示されている。このアーキテクチャは、一般にモデム・ボードの上で使用されるが、それは、他のアプリケーションにおいても使用され得ることを理解されたい。この実施形態においては、１つのパーティションは、その中のすべての８つのコアを用いて規定される。しかしながら、マルチ・コア・プロセッサ１００は、任意の数のコアを有し得ることを理解されたい。この実施形態を用いて、すべてのコア（例えば、８つのコア）の上で実行される単一の対称マルチ処理（ＳＭＰ：ｓｙｍｍｅｔｒｉｃ  ｍｕｌｔｉｐｒｏｃｅｓｓｉｎｇ）オペレーティング・システム（ＯＳ）インスタンス１０２を使用することがそれゆえに可能である。制御プレーンおよびデータ・プレーンは、１つのＯＳインスタンスの下にあるので、データ・プレーンを伴う問題は、同様に制御プレーンを停止させることにならないことを保証する配慮が、一般に必要とされる。
【００１６】
この例においては、マルチ・コア・プロセッサ１００は、３つのセル（図において、１０４、１０６、および１０８として示される）にサービスを行う。各セルは、アップリンク（ＵＬ）スケジューラ（図において１１０、１１２、および１１４として示される）と、ダウンリンク（ＤＬ）スケジューラ（図１において１１６、１１８、および１２０として示される）とを必要とする。
【００１７】
無線リンク制御（ＲＬＣ）レイヤを使用して、ＬＴＥエア・インターフェースを通して送信され、また受信されるパケット・フレームの上でエラーをセグメント化し、連結させ、また訂正することが、知られている。無線リンク制御および媒体アクセス制御の（ＲＬＣ／ＭＡＣ）ソフトウェアは、ＧＰＲＳ（２．５Ｇ）ワイヤレス・スタックにおいて使用される。それは、移動局と基地局制御装置（ＢＳＣ：ｂａｓｅ  ｓｔａｔｉｏｎ  ｃｏｎｔｒｏｌｌｅｒ）との間の肯定応答されたデータ転送と、肯定応答されていないデータ転送とを提供する。このようにして、ＲＬＣ／ＭＡＣブロック１２２も含まれ、このＲＬＣ／ＭＡＣブロックは、モバイルとネットワークとの間で使用されるエア・インターフェースの上の基本トランスポート・ユニットである。ＲＬＣ／ＭＡＣブロックを使用して、データとＲＬＣ／ＭＡＣブロック信号とを搬送する。
【００１８】
マルチ・コア・プロセッサ１００はまた、オペレーション、統治、および管理（ＯＡ＆Ｍ）１２４と、ＣＡＬＬＬＰモジュール１２６とを提供する。
【００１９】
さらに、マルチ・コア・プロセッサ１００は、コア抽象化レイヤ（ＣＡＬ）１２８を含んでおり、このコア抽象化レイヤは、レイヤ２（Ｌ２）アプリケーション・ソフトウェアからコア特有の詳細を隠す。レイヤ２は、コンピュータ・ネットワーキングの７−レイヤＯＳＩモデルのうちのデータ・リンク・レイヤ（Ｄａｔａ  Ｌｉｎｋ  Ｌａｙｅｒ）である。データ・リンク・レイヤは、広域ネットワークにおける隣接するネットワーク・ノードの間で、または同じローカル・エリア・ネットワーク・セグメントの上のノードの間でデータを転送するプロトコル・レイヤである。データ・リンク・レイヤは、ネットワーク・エンティティの間でデータを転送する機能手段および手続き手段を提供し、また物理レイヤの中で起こり得るエラーを検出し、また場合によってはエラーを訂正する手段を提供する可能性がある。データ・リンク・プロトコルの例は、ローカル・エリア・ネットワーク（マルチ・ノード）についてのイーサネット、ポイント・ツー・ポイント・プロトコル（ＰＰＰ：Ｐｏｉｎｔ−ｔｏ−Ｐｏｉｎｔ  Ｐｒｏｔｏｃｏｌ）、ＨＤＬＣ、およびポイント・ツー・ポイント（デュアル・ノード）接続についてのＡＤＣＣＰである。この場合には、Ｌ２は、一般に、ＬＴＥエア・インターフェースについて必要とされるＬ２スケジューラ処理を意味しており、この処理は、非常に厳しいリアル・タイム要件を有する。
【００２０】
モバイル通信デバイスと、ネットワーク交換サブシステムとの間のトラフィックと信号とを処理する役割を担う基地局のリアル・タイム性能ニーズを満たすために、ＰＲＥＥＭＰＴ＿ＲＴパッチを有するＳＭＰリナックスなどのＯＳが、使用されることもある。もちろん、他のオペレーティング・システムも使用され得ることを理解されたい。そのようなＳＭＰ構成において決定論的な動作を達成するために、システムは、コア予約とコア親和性構造とを使用して、ＡＭＰのようなシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、ＰＲＥＥＭＰＴ＿ＲＴ  ＯＳを有するＳＭＰリナックスの中から最上の性能を得るためにも望ましい。バッファ管理などのロックレス・ゼロ・コピー・サービスと、メッセージング・サービスとの使用は、ＰＲＥＥＭＰＴ＿ＲＴ  ＯＳを有するＳＭＰリナックスの使用によって課されることもあるどのようなレイテンシー問題にも対処する助けをすることもできる。
【００２１】
図１に示されるようなコア抽象化レイヤ（１２８）の主要な機能のうちの１つは、マルチ・コア・プラットフォームの全能力を利用する様々なサービスをＬ２処理などの高レベル・アプリケーションに提供することである。コア抽象化レイヤは、このようにして、いくつかの目標を達成するように設計される。第１に、それは、より高レベルのアプリケーション・ソフトウェア（すなわち、Ｌ２ソフトウェア）からＤＰＡＡおよびマルチ・コア特有の実装形態を隠しながら、ＢＥＤ（バックプレーン・イーサネット・ドライバ）のＤＰＡＡベースのインターフェースをサポートすべきである。第２に、それは、Ｐ４０８０のＤＰＡＡハードウェア・コンポーネントを利用して、入口方向と出口方向との両方においてユーザ・プレーン・データについての加速されたデータ・パスを提供すべきである。第３に、それは、構成変化に（すなわち、コード変更を必要とせずに）簡単に適応するように、できるだけ多くの柔軟性を提供するべきである。ＣＡＬ構成の一例は、バッファ・プールと、入口フレーム待ち行列と、出口フレーム待ち行列とについてのＤＰＡＡリソース構成である。
【００２２】
次に図２を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ２００が、示されている。従来のコンピュータのオペレーティング・システムは、通常、カーネル空間と、ユーザ空間とに仮想メモリを分離することが知られている。カーネル空間は、カーネルと、カーネル拡張と、ほとんどのデバイス・ドライバとを実行するために厳しく予約される。対照的に、ユーザ空間は、すべてのユーザ・モード・アプリケーションが機能し、またこのメモリが必要なときに交換され得る場合のメモリ・エリアである。これに関して、コア抽象化レイヤ（ＣＡＬ）２０１は、それだけには限定されないが、フレーム・マネージャ（ＦＭａｎ）２３０および２３２に対してＬＴＥネットワーク構成と任意の静的ＰＣＤルールとをロードし、また１組の構成ファイルに基づいてＣＡＬフレームワークをセットアップするコア抽象化レイヤ初期化（ＣＡＬＩｎｉｔ）モジュール２０２と、コア抽象化レイヤ・バッファ（ＣＡＬＢｕｆ）モジュール２０４と、別のボード（すなわち、ｅＣＣＭ）に対してユーザ・プレーン・データを送信し、または別のボードからユーザ・プレーン・データを受信するメッセージング・サービスをＬ２ソフトウェアに対して提供するコア抽象化レイヤ・メッセージング（ＣＡＬＭｓｇ）モジュール２０６と、適切なコアに対して入口フレームをルーティングするために各ＦＭａｎ（２３０、２３２）によって使用される、構文解析、分類および配信（ＰＤＣ：Ｐａｒｓｉｎｇ，  Ｃｌａｓｓｉｆｉｃａｔｉｏｎ  ａｎｄ  Ｄｉｓｔｒｉｂｕｔｉｏｎ）のルールおよび構成を提供するコア抽象化レイヤの構文解析、分類および配信の（ＣＡＬＰｃｄＦｍｃ）モジュール２０８と、カーネル空間のモジュールである、コア抽象化レイヤＤＰＡＡドライバ（ＣＡＬＤｐａａＤｒｉｖｅｒ）２１２においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するコア抽象化レイヤＤＰＡＡトレース（ＣＡＬＤｐａａＴｒａｃｅ）モジュール２１０とを含む様々なモジュールをユーザ空間の中に含んでいる。
【００２３】
アーキテクチャ２００は、Ｐｒｅｅｍｐｔ  ＲＴパッチを有するＳＭＰリナックスなど、適切なオペレーティング・システム２１４をさらに含んでいる。オペレーティング・システム２１４は、順に、上述のＣＡＬＤｐａａドライバ２１２、少なくとも１つのフレーム・マネージャ（ＦＭａｎ）ドライバ２１６、少なくとも１つのバッファ・マネージャ（ＢＭａｎ）ドライバ２１８、少なくとも１つの待ち行列マネージャ（ＱＭａｎ）ドライバ２２０など、様々なドライバをサポートする。
【００２４】
図２に示されるように、アーキテクチャ２００は、スケーラブルなオン・チップ・ネットワークが、キャッシュ、スタンドアロン・キャッシュ、およびメモリ・サブシステムと複数のパワー・アーキテクチャ処理コアを接続するために適した相互接続アーキテクチャであるＰ４０８０ＣｏｒｅＮｅｔファブリック（Ｐ４０８０  ＣｏｒｅＮｅｔ  ｆａｂｒｉｃ）２２２を適切に含むことができる。
【００２５】
Ｐ４０８０プロセッサは、新しいデータ・パス加速アーキテクチャ（ＤＰＡＡ）の実装形態を含んでいる。したがって、アーキテクチャ２００は、Ｐ４０８０  ＤＰＡＡ  ２２４をさらに含むこともある。ＤＰＡＡ  ２２４は、ネットワーク・インターフェースとハードウェア・アクセラレータとを含めて、リソースの負荷拡散や共用化などのマルチ・コア・ネットワーク処理を最適化するように設計される。示されるように、ＤＰＡＡ  ２２４は、一般に、ＢＭａｎ  ２２６、ＱＭａｎ  ２２８、第１および第２のＦＭａｎ  それぞれ２３０および２３２など、様々なマネージャを含んでいる。
【００２６】
ワイヤレス多重アクセス通信システムにおいては、トランスミッタとレシーバとは、マルチ・レイヤの通信スタックを使用して通信することができることが、知られている。それらのレイヤは、例えば、物理レイヤ、媒体アクセス制御（ＭＡＣ）レイヤ、無線リンク制御（ＲＬＣ）レイヤ、プロトコル・レイヤ（例えば、パケット・データ・コンバージェンス・プロトコル（ＰＤＣＰ：ｐａｃｋｅｔ  ｄａｔａ  ｃｏｎｖｅｒｇｅｎｃｅ  ｐｒｏｔｏｃｏｌ）レイヤ）、アプリケーション・レイヤなどを含むことができる。ＲＬＣレイヤは、ＰＤＣＰレイヤからサービス・データ・ユニット（ＳＤＵ）を受信し、またＭＡＣレイヤに対して伝送するためにＳＤＵをＲＬＣプロトコル・データ・ユニット（ＰＤＵ：ｐｒｏｔｏｃｏｌ  ｄａｔａ  ｕｎｉｔｓ）に連結し、またはセグメント化する。
【００２７】
それに応じて、ＣＡＬＢｕｆモジュール２０４は、ＲＬＣ  ＳＤＵ処理において使用するために、Ｌ２アプリケーションについてのロックレス・バッファ管理サービスを容易にする。当技術分野において知られているように、非ブロッキング・アルゴリズムは、共用されたリソースについて競合するスレッドが、それらの実行が相互排除によって無期限に延長されないことを保証する。非ブロッキング・アルゴリズムは、システム規模の進化が保証される場合に、ロックレス（またはロックフリー）である。ＣＡＬＢｕｆモジュール２０４はまた、バッファ・プール統計データ（例えば、プール不足状態、不足カウント、プール使用可能状態、プール割付エラー・カウントなど）についての問い合わせもサポートする。ＣＡＬＢｕｆモジュール２０４は、ＣＡＬＤｐａａドライバ２１２とインターフェースして、それらのサービスを実装する。ＣＡＬＢｕｆモジュール２０４は、マルチ・コア環境において適切なシステム・オペレーションのために非常に重要であるロックレス・バッファ管理スキームを提供し、ここで、非リアル・タイム・プロセスによってかけられるロックは、そのロックの解放を待つリアル・タイム・プロセスについてレイテンシー問題を引き起こす可能性がある。
【００２８】
ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、ＣＡＬ  ２０１のカーネル空間コンポーネントであり、ＢｍａｎおよびＱｍａｎのＡＰＩを使用してバッファ管理サービスとメッセージング・サービスとを実装し、また提供する助けを行う。本明細書において使用されるように、用語ＡＰＩ（またはアプリケーション・プログラミング・インターフェース）は、ソフトウェア・プログラムによって実装されるインターフェースを意味しており、このインターフェースは、それが、他のソフトウェアと相互作用することを可能にする。それは、ユーザ・インターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェア・プログラムの間の相互作用を容易にする。ＡＰＩは、それらの語彙と呼び出し規則とを決定するようにアプリケーション、ライブラリ、およびオペレーティング・システムによって実装され、またそれらのサービスにアクセスするために使用される。ＡＰＩは、ルーチンと、データ構造と、オブジェクト・クラスと、ＡＰＩの消費者と実装者との間で通信するために使用されるプロトコルとについての仕様を含むことができる。
【００２９】
ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、ユーザ・プレーン・データ配信のために使用されるＤＰＡＡリソース（バッファ・プールおよびフレーム待ち行列）を管理する役割と、オープン、リリース、初期化のためのｉ−ｏ−制御（ｉｏｃｔｌ）、バッファ管理、メッセージング・サービスなど、様々なファイル・オペレーションを経由してユーザ空間インターフェースを他のＣＡＬモジュールに対して提供する役割と、カーネル・ツー・ユーザ−空間（Ｋ−Ｕ）バッファ・マッピングを実行する役割と、ＤＰＡＡのバッファ・プール、レシーバおよびトランスミッタの統計データを提供する役割と、リング・バッファを管理するためのサービスを実装する役割とを担う。リング・バッファは、ＣＡＬのＬ２ソフトウェア待ち行列を表し、またそれらは、一般に、特定のＬ２  ＤＬＴに向かうことになっているＦＤを記憶するために使用されることに注意されたい。ＣＡＬＭｓｇモジュール２０６は、Ｌ２が、リングからバッファ記述子を取り出すためのＡＰＩを提供する。
【００３０】
上記で説明されるＣＡＬコンポーネントのすべては、一般に、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２を例外として、プラットフォーム・ミドルウェア（ユーザ空間において実行される）である。ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、カーネル空間において実行されるカスタム・ドライバであり、またそれは、ＣＡＬユーザ空間ミドルウェアによって必要とされるサービスを−とりわけ、Ｐ４０８０  ＤＰＡＡハードウェア・コンポーネントに依存するこれらのサービスを−実装し、また提供するように設計される。
【００３１】
ＣＡＬＢｕｆモジュール２０４は、「高速パス」データ処理のために排他的に使用されるバッファ管理サービスを提供する。ＣＡＬＢｕｆモジュール２０４は、ユーザ空間ＡＰＩをＬ２アプリケーションに対して提供する。ＣＡＬＢｕｆモジュール２０４は、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２と協調して、ＣＡＬＤｐａａドライバ２１２が生成するが、Ｂｍａｎ  ２２６によって管理されるバッファについてのゼロ・コピーおよびロックレスのバッファ管理サービスを提供する。
【００３２】
ＣＡＬＢｕｆモジュール２０４は、とりわけ以下のサービス、すなわち
１．バッファ・サイズを仮定して、バッファを獲得するサービスと、
２．与えられた数の、与えられたサイズのバッファを獲得し、次いで、バッファの要求された数まで使用可能なバッファのリストを戻すサービスと、
３．指定されたバッファを解放するサービスと、
４．バッファのリストを解放するサービスと、
５．バッファ・プールの統計データについて問い合わせを行うサービスと
をサポートするＡＰＩを実装し、また提供する。
【００３３】
上で述べられるように、ロックレス・バッファ管理スキームは、マルチ・コア・プロセッサ・ベースのモデム・ボードの性能ニーズを満たすために重要であり、このマルチ・コア・プロセッサ・ベースのモデム・ボードは、すべての８つのコアから成る１つのパーティションを使用し、またＰＲＥＥＭＰＴ＿ＲＴを有するＳＭＰリナックスを実行する。そのようなスキームなしには、システムは、無制限のレイテンシー・スパイクの影響を受ける可能性があり、このレイテンシー・スパイクは、全体システムを破壊してしまう可能性がある。
【００３４】
図３を参照すると、ＢＭａｎ  ２２６や他の適切なコンポーネントなど、マルチ・コア・プロセッサの上のハードウェア・コンポーネント３０２を使用して、ロックレス・バッファ管理スキームを実装することができる。この例におけるハードウェア・コンポーネント３０２は、４８−ビットのトークンの６４個の別個のプール（または待ち行列）を管理する。これらのトークンは、バッファ・メモリに対するポインタとして機能する。プールと、各プールの内部のトークンとの数は、変化することができる。これに関して、異なるサイズの６４個のバッファ・プール（例えば、１つのプールは、２ＫＢバッファを指し示す１０個のトークンを有することもあり、第２のプールは、４ＫＢバッファを指し示す５０個のトークンを有することもあるなどである）が、ハードウェア・コンポーネント３０２の中で規定される。例として、ハードウェア・コンポーネント３０２は、各トークンが、サイズが１ＫＢ（１０２４バイト）のメモリの中のバッファを指し示す１０個のトークンを有する、参照番号３０４として示される第１のプール（すなわち、プール１）を含むことができる。しかしながら、最初のプール３０２は、より多くの４８−ビットのトークンを含むことができることを理解されたい。この例においてもやはり、参照番号３１０として示される最後のプール（すなわち、プール６４）は、各トークンが、サイズが８ＫＢのバッファを指し示す１０個のトークンを有する。この場合にも、最後のプール３１０は、より多くの４８ビットのトークンを含むことができることを理解されたい。図３には示されていないが、ハードウェア・コンポーネント３０２は、サイズが変化している可能性がある６２個の残りのプールを有することに、さらに注意されたい。しかしながら、例証の目的のために、６２個の残りのプール（すなわち、プール２〜６３）のおのおのは、おのおのが、サイズが１ＫＢのバッファを指し示す１０個のトークンを有することが仮定される。
【００３５】
本明細書において提供される例示の実施形態のオペレーション中に、バッファ管理スキームは、それが、ある種のサイズのバッファを必要とするたびごとに、トークン（すなわち、バッファ・メモリに対するポインタ）についてハードウェア・コンポーネント３０２に対して要求を送信する。これは、以下でより詳細に示される。
【００３６】
以上で述べられたように、ＣＡＬＢｕｆ  ＡＰＩＳは、バッファを獲得する。ＣＡＬＢｕｆ  ２１２は、ユーザ空間において実行されるアプリケーション・ソフトウェアに対してユーザ空間のＡＰＩを提供する。アプリケーションが、バッファを必要とするときに、それは、ある種のサイズのバッファを要求するＣＡＬＢｕｆ  ＡＰＩを呼び出す。次いで、ＣＡＬＢｕｆモジュール２０４は、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２などのカーネル空間モジュールからの助けを用いて、指定されたサイズのトークン／バッファをＢＭａｎ  ２２６に要求する。ＢＭａｎ  ２２６は、複数のコアからの同時アクセスの調停をするハードウェア・エンティティである。したがって、ＢＭａｎ  ２２６は、いくつかのＬ２エンティティが、並列に実行しているので、複数のコアから同時にトークン／バッファについての要求を受信する。次いで、ＢＭａｎ  ２２６は、ソフトウェア・ロックについての必要性なしにハードウェアの形で調停を実行し、また要求するＬ２エンティティのおのおのは、ブロックされることなくバッファを受信する。ハードウェア・コンポーネント３０２は、複数のコアからの同時アクセスの調停をするので、その結果は、以下でより十分に説明されるように、ソフトウェアでのロックまたはブロッキング・セマフォの必要をなくすソフトウェア・ロックレス・バッファ管理スキームである。
【００３７】
最初に、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、カーネル空間にメモリの隣接チャンク３１６（例えば、サイズが１ＧＢ）を割り付ける。このメモリは、プロセッサ１００が使用する外部ＤＤＲメモリであり、またそれは、一般的に、ボード上で、プロセッサと同一場所に配置される。次いで、ハードウェア支援されたプールは、バッファとして使用されることになるメモリ３１６のセクションを指し示すトークンを用いてシーディングされる。言い換えれば、メモリの隣接チャンク３１６は、各バッファ・プールが、特定のバッファ・サイズ特性を有する複数のバッファ・プールを含んでいる。６４個のバッファ・プール（プール３０４、３１０など）の内部のトークンを使用して、ある種のサイズの特定のバッファを開始するメモリ３１６の内部のアドレスを迅速に取得する。メモリの隣接チャンク３１６は、開始アドレスと終了アドレスとを有しており、これらのアドレスは、一緒に、メモリのチャンク３１６のサイズおよびロケーションを規定する。
【００３８】
メモリ・チャンク３１６の開始アドレスは、バッファ・プールについてのシード値を計算するときのベース・ポインタとして使用される。プールの内部の与えられた任意のトークンについてのシード・アドレスは、次の式、すなわち、
【００３９】
【数１】
2013546068.tif 000003
によって計算することができ、式中で、ｘは、プール番号であり、ｙは、プールｘの内部のバッファ（またはトークン）番号であり、プール＿サイズは、プールｋの内部のトークンの数であり、またプール＿バッファ＿サイズは、プールｋの内部のおのおのの個別のバッファのサイズ（２ＫＢなど）である。
【００４０】
例証の目的のために、メモリ・チャンク３１６の開始アドレスは、０ｘ００００であることが、仮定される。したがって、上記式を使用すると、１ＫＢのサイズのバッファを指し示す最初のプール（プール１）の最初のトークン（トークン０）についてのシード値は、０（例えば、０ｘ０００）である。プール１の次のトークン（トークン１）は、１０２４（例えば、０ｘ４００）などである。プール１〜６３は、おのおのサイズ１ＫＢのバッファを指し示す１０個のトークンを有すること、およびプール６４は、サイズ８ＫＢのバッファを指し示す１０個のトークンを有することを仮定すると、最後のプール（プール６４）は、６４，５１２（例えば、０ｘＦＣ００）の第１のトークン値（トークン０）を有することになり、次のトークン値（トークン１）は、７２７０４（例えば、０ｘ１１Ｃ００）の値を有することになるなどである。
【００４１】
ひとたびすべてのプールが、適切なバッファ・トークンを用いてシーディングされた後に、次いで、ハードウェア・コンポーネント３０２は、ソフトウェア・ロックレス・バッファ管理スキームを実装する際に、バッファ管理スキームを支援することができる。
【００４２】
メモリ３１６とバッファ・プールとの獲得およびシーディングの高レベルの図が、図４によって示される。ステップ４１０において、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、上記で説明されるように外部ＤＤＲメモリの隣接チャンク３１６を獲得する。
【００４３】
ステップ４２０において、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、カーネル空間のメモリ３１６をユーザ空間にマッピングして、データ・コピーを実行する必要なしに、メモリ・エリア３１６に記憶されるデータに対するユーザ・モード・アプリケーション・アクセスを可能にしている。リナックスのＧＰＬ問題に起因して、Ｌ２スケジューラは、ユーザ空間において実行される。それゆえに、ユーザ空間のアプリケーションは、カーネル空間のメモリにアクセスすることができないことになり、それでメモリは、カーネル空間からユーザ空間にマッピングされて、ユーザ空間のアプリケーションが、バッファ・メモリに直接にアクセスすることを可能にしている。これは、データ・コピーについての必要性をなくしている。
【００４４】
ステップ４３０において、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、プールの数と、プール当たりのトークンの数と、トークンが指し示すバッファのサイズとを初期化する。
【００４５】
ステップ４４０において、ＣＡＬＤｐａａＤｒｉｖｅｒ  ２１２は、図３に関して説明される式のように、トークン（メモリ・ポインタ）を用いてプールをシーディングする。
【００４６】
動作中に、パケットが到着するときなど、バッファ管理スキームが、バッファを必要とするときはいつでも、ＢＭａｎ２２６は、適切なハードウェア・プールからトークン（すなわち、バッファ・メモリに対するポインタ）を待ち行列から取り出す（すなわち、取り除く）。同様に、バッファが解放されるときに、バッファ管理スキームは、トークン（すなわち、バッファ・メモリ・ポインタ）をハードウェア・プールの上へと戻して待ち行列に加える（すなわち、元に戻す）。
【００４７】
適切には、各バッファは、一般に、バッファ管理スキームによる使用のために予約される数バイトのヘッダおよびトレーラを有することになる。これらのヘッダおよびトレーラは、誰がバッファを所有するかなど、重要なブック・キーピング情報を含んでいる。この情報は、特定のプロセスによって所有されるバッファをハードウェア・プールに解放して戻すためセル回復中に必要とされることを理解されたい。
【００４８】
当業者は、様々な上記で説明された方法のステップが、プログラムされたコンピュータによって実行され得ることを簡単に認識するであろう。本明細書においては、いくつかの実施形態はまた、プログラム・ストレージ・デバイスを、例えば、デジタル・データ・ストレージ媒体を対象として含むことを意図しており、このプログラム・ストレージ・デバイスは、マシン読み取り可能、またはコンピュータ読み取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、そこでは前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラム・ストレージ・デバイスは、例えば、デジタル・メモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、または光学的読取り可能デジタル・データ・ストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータを対象として含むようにも意図される。
【００４９】
上記説明は、単に本発明の特定の実施形態の開示を提供しているにすぎず、また本発明をそれだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけには限定されない。もっと正確に言えば、当業者は、本発明の範囲内に含まれる代替的な実施形態を考えることができることが、認識される。
【図１】
2013546068.tif 000004
【図２】
2013546068.tif 000005
【図３】
2013546068.tif 000006
【図４】
2013546068.tif 000007
【国際調査報告】
2013546068.tif 000008
2013546068.tif 000009
2013546068.tif 000010