"電気通信ネットワークにおいてモデムの上で使用するためのマルチコアプロセッサにおいて、バッファ管理メカニズムであって、1つまたは複数のレイヤ2アプリケーションについてのロックレスのゼロコピーバッファ管理サービスを提供するバッファモジュールを備え、前記バッファモジュールはユーザ空間において実行されるアプリケーションソフトウェアに対してユーザ空間アプリケーションインターフェースを少なくとも提供し、さらに、トークンの複数の別個のプールを管理するバッファマネージャを備え、前記トークンは、外部カーネル空間メモリにおけるメモリエリアに対するポインタを含み、さらに、ユーザプレーンデータの配信のために使用されるバッファプールおよびフレーム待ち行列を含むデータパス加速アーキテクチャDPAAリソースを管理するカスタムドライバを備え、前記カスタムドライバは、前記外部カーネル空間メモリの隣接チャンクを獲得し、さもなければ、カーネルツーユーザ-空間境界をデータが横切るときはいつでも生じるデータコピーを取り除くために、前記外部カーネル空間メモリに記憶されるデータへのユーザモードアプリケーションアクセスを可能にするように、カーネル空間メモリの前記隣接チャンクをユーザ空間にマッピングし、プールの数と、プール当たりのトークンの数と、前記トークンが指し示す前記バッファのサイズとを初期化し、そして、トークンを用いて前記プールをシーディングする、ことにより、前記バッファモジュールについての事前に割り付けられたメモリをロックレスのゼロコピーバッファ管理に提供するようにさらに動作する、バッファ管理メカニズム。前記バッファモジュールは、さらに、以下のサービス、すなわち、バッファを獲得するサービスと、与えられた数の、与えられたサイズのバッファを獲得し、次いで前記要求された数のバッファまでの使用可能なバッファのリストを戻すサービスと、指定されたバッファを解放するサービスと、バッファのリストを解放するサービスと、バッファプール統計データについて問い合わせを行うサービスとのうちの1つまたは複数をサポートするゼロコピーおよびロックレスのアプリケーションプログラミングインターフェースを実装し、また提供するように動作する、請求項1に記載のバッファ管理メカニズム。前記メモリチャンクの開始アドレスは、前記バッファプールについてのシード値を計算するときに、ベースポインタとして使用される、請求項1に記載のバッファ管理メカニズム。前記バッファマネージャは、さらに、ロックレスハードウェアDPAA調停を使用し、またパケットが到着した後に前記プールからトークンを待ち行列から取り出し、またバッファが解放されるときに、前記トークンを前記プール上へと戻して待ち行列に加えるように動作する、請求項1に記載のバッファ管理メカニズム。前記バッファマネージャは、さらに、複数のコアから同時にバッファまたはトークンについての要求を受信し、またソフトウェアでのソフトウェアロックまたはブロッキングセマフォの必要なしに、ハードウェアでのロックレス調停を実行するように動作する、請求項1に記載のバッファ管理メカニズム。電気通信ネットワークにおいてマルチセルサポートを提供する装置であって、モデムボードと、前記モデムボードに取り付けられた複数のプロセッサコアを含むマルチコアプロセッサを備え、単一のパーティションが、その中に含まれる前記プロセッサコアのすべてを用いて規定され、また前記単一のパーティションを使用して、すべての制御プレーン機能、およびすべてのデータプレーン機能、ならびに前記単一のパーティションにおいて前記プロセッサコアの上で実行されるアプリケーションソフトウェアから任意のコア特有の詳細を隠すコア抽象化レイヤを実行し、前記コア抽象化レイヤは、少なくとも以下のモジュール、すなわち、1つまたは複数のレイヤ2アプリケーションについてのロックレスのゼロコピーバッファ管理サービスを提供するバッファモジュールであって、ユーザ空間において実行されるアプリケーションソフトウェアに対してユーザ空間アプリケーションインターフェースを少なくとも提供するバッファモジュールと、複数の、トークンの別個のプールを管理するバッファマネージャであって、前記トークンは、外部カーネル空間メモリにおけるメモリエリアに対するポインタを含む、バッファマネージャと、ユーザプレーンデータの配信のために使用されるバッファプールおよびフレーム待ち行列を含むデータパス加速アーキテクチャDPAAリソースを管理するカスタムドライバとを備え、前記カスタムドライバは、さらに、前記外部カーネル空間メモリの隣接チャンクを獲得し、さもなければ、カーネルツーユーザ-空間境界をデータが横切るときはいつでも生じるデータコピーを取り除くために、前記外部カーネル空間メモリに記憶されるデータへのユーザモードアプリケーションアクセスを可能にするように、カーネル空間メモリの前記隣接チャンクをユーザ空間にマッピングし、プールの数と、プール当たりのトークンの数と、前記トークンが指し示す前記バッファのサイズとを初期化し、そして、トークンを用いて前記プールをシーディングする、ことにより、前記バッファモジュールについての事前に割り付けられたメモリをロックレスのゼロコピーバッファ管理に提供するように動作する、装置。前記バッファモジュールは、さらに、以下のサービス、すなわち、バッファを獲得するサービスと、与えられた数の、与えられたサイズのバッファを獲得し、次いで前記要求された数のバッファまでの使用可能なバッファのリストを戻すサービスと、指定されたバッファを解放するサービスと、バッファのリストを解放するサービスと、バッファプール統計データについて問い合わせを行うサービスとのうちの1つまたは複数をサポートするゼロコピーおよびロックレスのアプリケーションプログラミングインターフェースを実装し、また提供するように動作する、請求項5に記載の装置。前記メモリチャンクの開始アドレスは、前記バッファプールについてのシード値を計算するときに、ベースポインタとして使用される、請求項5に記載の装置。本明細書においては、SMP環境におけるロックレスバッファ管理スキームが、説明されている。例示の実施形態は、マルチコアからのバッファについての同時アクセスの調停をするバッファマネージャBMan:buffermanagerなど、モデムボードの上のハードウェアコンポーネントを利用している。ソフトウェアロックがかけられないので、ロックが解放されることを待つ一方で、プロセスまたはスレッドは、ブロックされないことになる。PREEMPT_RTを有するSMPリナックスなどのオペレーティングシステムOSは、vxWorksなどのハードコアリアルタイムOSではない。それゆえに、そのようなバッファリングスキームを規定することが重要であり、そうでなければ、オペレーティングシステムは、LTEレイヤ2スケジューラのリアルタイム処理の必要性を満たさないこともある。アプリケーションソフトウェアの観点から、ハードウェア調停は、まるで様々なコアからのバッファについてのすべての要求が、同時に、どのようなプロセスまたはスレッドもブロックされることなく、ほとんど並列に処理されているかのように見えるようにすることになる。その結果、無制限のレイテンシースパイクが、存在しないことになる。本明細書においては、SMPリナックスについてのゼロコピーバッファ管理スキームもまた説明されており、これによってデータは、ユーザ空間アプリケーションによって送信され、または受信される。ユーザツーカーネル-空間user-to-kernel-space境界を通してゼロコピーを達成するために、バッファメモリは、カーネルツーユーザ-空間kernel-to-user-spaceマッピングされる必要がある。メモリの隣接チャンクを割り付けることにより、それは、バッファプールbufferpoolsのカーネルツーユーザ-空間マッピングとシーディングseedingとをより簡単にする。指定されたプールにおける特定のバッファについてのポインタアドレスを計算する数式を有することは、バッファ管理スキームをより決定論的に、また堅牢にし、またそれは、バッファ管理のブックキーピングアクティビティと、ガーベージコレクションアクティビティとにおいて大きな助けを提供する。これはまた、メモリ破損についての効率的なチェックを実装する際にも助けとなるであろう。処理環境において、ミドルウェアレイヤは、一般的に、アプリケーションレイヤからすべてのハードウェア特有の実装の詳細を隠す。コア抽象化レイヤCAL:coreabstractionlayerは、マルチコアプロセッサと、そのデータパス加速アーキテクチャDataPathAccelerationArchitectureまたはDPAAについての抽象化を提供する。このモデムボードの展開では、CALは、LTEL2アプリケーションについてのゼロコピーロックレスバッファ管理スキームなど、様々なサービスと、マルチセル構成についての、無線リンク制御RLC:RadioLinkControlサービスデータユニットSDU:ServiceDataUnitの制御装置ボードに対する送信と制御装置ボードからの受信とについてのバックプレーンイーサネットドライバBED:BackplaneEthernetdriverインターフェースについてのサポートとを提供する。本発明の一態様においては、電気通信ネットワークにおいてモデムの上で使用するためのマルチコアプロセッサにおけるバッファ管理メカニズムが、提供される。バッファ管理メカニズムは、1つまたは複数のレイヤ2アプリケーションについてのバッファ管理サービスを提供するバッファモジュールを含んでおり、そこではバッファモジュールは、ユーザ空間において実行されるアプリケーションソフトウェアに対してユーザ空間アプリケーションインターフェースを少なくとも提供する。バッファ管理メカニズムはまた、複数の、トークンの別個のプールを管理するバッファマネージャも含んでおり、そこでは、それらのトークンは、外部メモリにおけるメモリエリアに対するポインタを含んでいる。さらに、バッファ管理メカニズムは、ユーザプレーンデータの配信のために使用されるバッファプールおよびフレーム待ち行列を含むデータパス加速アーキテクチャDPAAリソースを管理するカスタムドライバを含んでいる。オプションとして、カスタムドライバは、さらに、一連の機能を実行するように動作することもできる。例えば、カスタムドライバは、外部メモリの隣接チャンクを獲得することができる。次に、カスタムドライバは、カーネル空間メモリをユーザ空間にマッピングして、データコピーを実行する必要なしに、外部メモリに記憶されるデータへのユーザモードアプリケーションアクセスを可能にすることができる。カスタムドライバはまた、プールの数と、プール当たりのトークンの数と、それらのトークンが指し示すバッファのサイズとを初期化することもできる。最終的に、カスタムドライバは、トークンでプールをシーディングするseedことができる。本発明の別の態様においては、電気通信ネットワークにおいてマルチセルサポートを提供するための装置が、提供される。本装置は、一般に、モデムボードと、そのモデムボードに取り付けられる複数のプロセッサコアを備えるマルチコアプロセッサとを含む。マルチコアプロセッサに関連して、単一のパーティションが、その中に含まれるプロセッサコアのすべてを用いて規定され、またそこで単一のパーティションを使用して、すべての制御プレーン機能と、すべてのデータプレーン機能とを実行する。さらに、コア抽象化レイヤは、単一のパーティションにおけるプロセッサコアの上で実行されるアプリケーションソフトウェアから任意のコア特有の詳細を隠す。コア抽象化レイヤは、1つまたは複数のレイヤ2アプリケーションについてのバッファ管理サービスを提供するバッファモジュールを含んでおり、そこではバッファモジュールは、ユーザ空間において実行されるアプリケーションソフトウェアに対してユーザ空間アプリケーションインターフェースを少なくとも提供する。コア抽象化レイヤはまた、複数の、トークンの別個のプールを管理するバッファマネージャも含んでおり、そこではそれらのトークンは、外部メモリにおけるメモリエリアに対するポインタを含んでいる。さらに、コア抽象化レイヤは、ユーザプレーンデータの配信のために使用されるバッファプールおよびフレーム待ち行列を含むデータパス加速アーキテクチャDPAAリソースを管理するカスタムドライバを含んでいる。本発明の適用可能性のさらなる範囲は、以下で提供される詳細な説明から明らかになるであろう。しかしながら、本発明の精神および範囲の内部の様々な変更形態および修正形態が、当業者には明らかになるので、詳細な説明と特定の例とは、本発明の好ましい実施形態を示しながら、例証だけとして与えられていることを理解されたい。本発明は、デバイスの構造、構成、および様々な部分の組合せと、方法のステップとの中に存在しており、これによって、企図される目的は、以降でより十分に説明され、特に特許請求の範囲の中で指摘され、また添付の図面において示されるように、達成される。ここで図面を参照すると、それらの提示は例示の実施形態だけを示す目的のためであり、請求する主題を限定する目的のためではないが、図1では、現在説明しようとしている実施形態を組み込むことができるシステムの図を提供している。ここで図1を参照すると、例示のプラットフォームアーキテクチャ100が示されている。このアーキテクチャは、一般にモデムボードの上で使用されるが、それは、他のアプリケーションにおいても使用され得ることを理解されたい。この実施形態においては、1つのパーティションは、その中のすべての8つのコアを用いて規定される。しかしながら、マルチコアプロセッサ100は、任意の数のコアを有し得ることを理解されたい。この実施形態を用いて、すべてのコア例えば、8つのコアの上で実行される単一の対称マルチ処理SMP:symmetricmultiprocessingオペレーティングシステムOSインスタンス102を使用することがそれゆえに可能である。制御プレーンおよびデータプレーンは、1つのOSインスタンスの下にあるので、データプレーンを伴う問題は、同様に制御プレーンを停止させることにならないことを保証する配慮が、一般に必要とされる。この例においては、マルチコアプロセッサ100は、3つのセル図において、104、106、および108として示されるにサービスを行う。各セルは、アップリンクULスケジューラ図において110、112、および114として示されると、ダウンリンクDLスケジューラ図1において116、118、および120として示されるとを必要とする。無線リンク制御RLCレイヤを使用して、LTEエアインターフェースを通して送信され、また受信されるパケットフレームの上でエラーをセグメント化し、連結させ、また訂正することが、知られている。無線リンク制御および媒体アクセス制御のRLC/MACソフトウェアは、GPRS2.5Gワイヤレススタックにおいて使用される。それは、移動局と基地局制御装置BSC:basestationcontrollerとの間の肯定応答されたデータ転送と、肯定応答されていないデータ転送とを提供する。このようにして、RLC/MACブロック122も含まれ、このRLC/MACブロックは、モバイルとネットワークとの間で使用されるエアインターフェースの上の基本トランスポートユニットである。RLC/MACブロックを使用して、データとRLC/MACブロック信号とを搬送する。マルチコアプロセッサ100はまた、オペレーション、統治、および管理OAM124と、CALLLPモジュール126とを提供する。さらに、マルチコアプロセッサ100は、コア抽象化レイヤCAL128を含んでおり、このコア抽象化レイヤは、レイヤ2L2アプリケーションソフトウェアからコア特有の詳細を隠す。レイヤ2は、コンピュータネットワーキングの7-レイヤOSIモデルのうちのデータリンクレイヤDataLinkLayerである。データリンクレイヤは、広域ネットワークにおける隣接するネットワークノードの間で、または同じローカルエリアネットワークセグメントの上のノードの間でデータを転送するプロトコルレイヤである。データリンクレイヤは、ネットワークエンティティの間でデータを転送する機能手段および手続き手段を提供し、また物理レイヤの中で起こり得るエラーを検出し、また場合によってはエラーを訂正する手段を提供する可能性がある。データリンクプロトコルの例は、ローカルエリアネットワークマルチノードについてのイーサネット、ポイントツーポイントプロトコルPPP:Point-to-PointProtocol、HDLC、およびポイントツーポイントデュアルノード接続についてのADCCPである。この場合には、L2は、一般に、LTEエアインターフェースについて必要とされるL2スケジューラ処理を意味しており、この処理は、非常に厳しいリアルタイム要件を有する。モバイル通信デバイスと、ネットワーク交換サブシステムとの間のトラフィックと信号とを処理する役割を担う基地局のリアルタイム性能ニーズを満たすために、PREEMPT_RTパッチを有するSMPリナックスなどのOSが、使用されることもある。もちろん、他のオペレーティングシステムも使用され得ることを理解されたい。そのようなSMP構成において決定論的な動作を達成するために、システムは、コア予約とコア親和性構造とを使用して、AMPのようなシステム動作を達成するようにして実装されることが好ましい。これはまた、例えば、PREEMPT_RTOSを有するSMPリナックスの中から最上の性能を得るためにも望ましい。バッファ管理などのロックレスゼロコピーサービスと、メッセージングサービスとの使用は、PREEMPT_RTOSを有するSMPリナックスの使用によって課されることもあるどのようなレイテンシー問題にも対処する助けをすることもできる。図1に示されるようなコア抽象化レイヤ128の主要な機能のうちの1つは、マルチコアプラットフォームの全能力を利用する様々なサービスをL2処理などの高レベルアプリケーションに提供することである。コア抽象化レイヤは、このようにして、いくつかの目標を達成するように設計される。第1に、それは、より高レベルのアプリケーションソフトウェアすなわち、L2ソフトウェアからDPAAおよびマルチコア特有の実装形態を隠しながら、BEDバックプレーンイーサネットドライバのDPAAベースのインターフェースをサポートすべきである。第2に、それは、P4080のDPAAハードウェアコンポーネントを利用して、入口方向と出口方向との両方においてユーザプレーンデータについての加速されたデータパスを提供すべきである。第3に、それは、構成変化にすなわち、コード変更を必要とせずに簡単に適応するように、できるだけ多くの柔軟性を提供するべきである。CAL構成の一例は、バッファプールと、入口フレーム待ち行列と、出口フレーム待ち行列とについてのDPAAリソース構成である。次に図2を参照すると、これらの目標および他の目標を達成する例示のアーキテクチャ200が、示されている。従来のコンピュータのオペレーティングシステムは、通常、カーネル空間と、ユーザ空間とに仮想メモリを分離することが知られている。カーネル空間は、カーネルと、カーネル拡張と、ほとんどのデバイスドライバとを実行するために厳しく予約される。対照的に、ユーザ空間は、すべてのユーザモードアプリケーションが機能し、またこのメモリが必要なときに交換され得る場合のメモリエリアである。これに関して、コア抽象化レイヤCAL201は、それだけには限定されないが、フレームマネージャFMan230および232に対してLTEネットワーク構成と任意の静的PCDルールとをロードし、また1組の構成ファイルに基づいてCALフレームワークをセットアップするコア抽象化レイヤ初期化CALInitモジュール202と、コア抽象化レイヤバッファCALBufモジュール204と、別のボードすなわち、eCCMに対してユーザプレーンデータを送信し、または別のボードからユーザプレーンデータを受信するメッセージングサービスをL2ソフトウェアに対して提供するコア抽象化レイヤメッセージングCALMsgモジュール206と、適切なコアに対して入口フレームをルーティングするために各FMan230、232によって使用される、構文解析、分類および配信PDC:Parsing,ClassificationandDistributionのルールおよび構成を提供するコア抽象化レイヤの構文解析、分類および配信のCALPcdFmcモジュール208と、カーネル空間のモジュールである、コア抽象化レイヤDPAAドライバCALDpaaDriver212においてトレースをイネーブルにし、またディスエーブルにするためのトレース能力を提供するコア抽象化レイヤDPAAトレースCALDpaaTraceモジュール210とを含む様々なモジュールをユーザ空間の中に含んでいる。アーキテクチャ200は、PreemptRTパッチを有するSMPリナックスなど、適切なオペレーティングシステム214をさらに含んでいる。オペレーティングシステム214は、順に、上述のCALDpaaドライバ212、少なくとも1つのフレームマネージャFManドライバ216、少なくとも1つのバッファマネージャBManドライバ218、少なくとも1つの待ち行列マネージャQManドライバ220など、様々なドライバをサポートする。図2に示されるように、アーキテクチャ200は、スケーラブルなオンチップネットワークが、キャッシュ、スタンドアロンキャッシュ、およびメモリサブシステムと複数のパワーアーキテクチャ処理コアを接続するために適した相互接続アーキテクチャであるP4080CoreNetファブリックP4080CoreNetfabric222を適切に含むことができる。P4080プロセッサは、新しいデータパス加速アーキテクチャDPAAの実装形態を含んでいる。したがって、アーキテクチャ200は、P4080DPAA224をさらに含むこともある。DPAA224は、ネットワークインターフェースとハードウェアアクセラレータとを含めて、リソースの負荷拡散や共用化などのマルチコアネットワーク処理を最適化するように設計される。示されるように、DPAA224は、一般に、BMan226、QMan228、第1および第2のFManそれぞれ230および232など、様々なマネージャを含んでいる。ワイヤレス多重アクセス通信システムにおいては、トランスミッタとレシーバとは、マルチレイヤの通信スタックを使用して通信することができることが、知られている。それらのレイヤは、例えば、物理レイヤ、媒体アクセス制御MACレイヤ、無線リンク制御RLCレイヤ、プロトコルレイヤ例えば、パケットデータコンバージェンスプロトコルPDCP:packetdataconvergenceprotocolレイヤ、アプリケーションレイヤなどを含むことができる。RLCレイヤは、PDCPレイヤからサービスデータユニットSDUを受信し、またMACレイヤに対して伝送するためにSDUをRLCプロトコルデータユニットPDU:protocoldataunitsに連結し、またはセグメント化する。それに応じて、CALBufモジュール204は、RLCSDU処理において使用するために、L2アプリケーションについてのロックレスバッファ管理サービスを容易にする。当技術分野において知られているように、非ブロッキングアルゴリズムは、共用されたリソースについて競合するスレッドが、それらの実行が相互排除によって無期限に延長されないことを保証する。非ブロッキングアルゴリズムは、システム規模の進化が保証される場合に、ロックレスまたはロックフリーである。CALBufモジュール204はまた、バッファプール統計データ例えば、プール不足状態、不足カウント、プール使用可能状態、プール割付エラーカウントなどについての問い合わせもサポートする。CALBufモジュール204は、CALDpaaドライバ212とインターフェースして、それらのサービスを実装する。CALBufモジュール204は、マルチコア環境において適切なシステムオペレーションのために非常に重要であるロックレスバッファ管理スキームを提供し、ここで、非リアルタイムプロセスによってかけられるロックは、そのロックの解放を待つリアルタイムプロセスについてレイテンシー問題を引き起こす可能性がある。CALDpaaDriver212は、CAL201のカーネル空間コンポーネントであり、BmanおよびQmanのAPIを使用してバッファ管理サービスとメッセージングサービスとを実装し、また提供する助けを行う。本明細書において使用されるように、用語APIまたはアプリケーションプログラミングインターフェースは、ソフトウェアプログラムによって実装されるインターフェースを意味しており、このインターフェースは、それが、他のソフトウェアと相互作用することを可能にする。それは、ユーザインターフェースが、ユーザとコンピュータとの間の相互作用を容易にするやり方と同様に、異なるソフトウェアプログラムの間の相互作用を容易にする。APIは、それらの語彙と呼び出し規則とを決定するようにアプリケーション、ライブラリ、およびオペレーティングシステムによって実装され、またそれらのサービスにアクセスするために使用される。APIは、ルーチンと、データ構造と、オブジェクトクラスと、APIの消費者と実装者との間で通信するために使用されるプロトコルとについての仕様を含むことができる。CALDpaaDriver212は、ユーザプレーンデータ配信のために使用されるDPAAリソースバッファプールおよびフレーム待ち行列を管理する役割と、オープン、リリース、初期化のためのi-o-制御ioctl、バッファ管理、メッセージングサービスなど、様々なファイルオペレーションを経由してユーザ空間インターフェースを他のCALモジュールに対して提供する役割と、カーネルツーユーザ-空間K-Uバッファマッピングを実行する役割と、DPAAのバッファプール、レシーバおよびトランスミッタの統計データを提供する役割と、リングバッファを管理するためのサービスを実装する役割とを担う。リングバッファは、CALのL2ソフトウェア待ち行列を表し、またそれらは、一般に、特定のL2DLTに向かうことになっているFDを記憶するために使用されることに注意されたい。CALMsgモジュール206は、L2が、リングからバッファ記述子を取り出すためのAPIを提供する。上記で説明されるCALコンポーネントのすべては、一般に、CALDpaaDriver212を例外として、プラットフォームミドルウェアユーザ空間において実行されるである。CALDpaaDriver212は、カーネル空間において実行されるカスタムドライバであり、またそれは、CALユーザ空間ミドルウェアによって必要とされるサービスを-とりわけ、P4080DPAAハードウェアコンポーネントに依存するこれらのサービスを-実装し、また提供するように設計される。CALBufモジュール204は、高速パスデータ処理のために排他的に使用されるバッファ管理サービスを提供する。CALBufモジュール204は、ユーザ空間APIをL2アプリケーションに対して提供する。CALBufモジュール204は、CALDpaaDriver212と協調して、CALDpaaドライバ212が生成するが、Bman226によって管理されるバッファについてのゼロコピーおよびロックレスのバッファ管理サービスを提供する。CALBufモジュール204は、とりわけ以下のサービス、すなわち1.バッファサイズを仮定して、バッファを獲得するサービスと、2.与えられた数の、与えられたサイズのバッファを獲得し、次いで、バッファの要求された数まで使用可能なバッファのリストを戻すサービスと、3.指定されたバッファを解放するサービスと、4.バッファのリストを解放するサービスと、5.バッファプールの統計データについて問い合わせを行うサービスとをサポートするAPIを実装し、また提供する。上で述べられるように、ロックレスバッファ管理スキームは、マルチコアプロセッサベースのモデムボードの性能ニーズを満たすために重要であり、このマルチコアプロセッサベースのモデムボードは、すべての8つのコアから成る1つのパーティションを使用し、またPREEMPT_RTを有するSMPリナックスを実行する。そのようなスキームなしには、システムは、無制限のレイテンシースパイクの影響を受ける可能性があり、このレイテンシースパイクは、全体システムを破壊してしまう可能性がある。図3を参照すると、BMan226や他の適切なコンポーネントなど、マルチコアプロセッサの上のハードウェアコンポーネント302を使用して、ロックレスバッファ管理スキームを実装することができる。この例におけるハードウェアコンポーネント302は、48-ビットのトークンの64個の別個のプールまたは待ち行列を管理する。これらのトークンは、バッファメモリに対するポインタとして機能する。プールと、各プールの内部のトークンとの数は、変化することができる。これに関して、異なるサイズの64個のバッファプール例えば、1つのプールは、2KBバッファを指し示す10個のトークンを有することもあり、第2のプールは、4KBバッファを指し示す50個のトークンを有することもあるなどであるが、ハードウェアコンポーネント302の中で規定される。例として、ハードウェアコンポーネント302は、各トークンが、サイズが1KB1024バイトのメモリの中のバッファを指し示す10個のトークンを有する、参照番号304として示される第1のプールすなわち、プール1を含むことができる。しかしながら、最初のプール302は、より多くの48-ビットのトークンを含むことができることを理解されたい。この例においてもやはり、参照番号310として示される最後のプールすなわち、プール64は、各トークンが、サイズが8KBのバッファを指し示す10個のトークンを有する。この場合にも、最後のプール310は、より多くの48ビットのトークンを含むことができることを理解されたい。図3には示されていないが、ハードウェアコンポーネント302は、サイズが変化している可能性がある62個の残りのプールを有することに、さらに注意されたい。しかしながら、例証の目的のために、62個の残りのプールすなわち、プール2~63のおのおのは、おのおのが、サイズが1KBのバッファを指し示す10個のトークンを有することが仮定される。本明細書において提供される例示の実施形態のオペレーション中に、バッファ管理スキームは、それが、ある種のサイズのバッファを必要とするたびごとに、トークンすなわち、バッファメモリに対するポインタについてハードウェアコンポーネント302に対して要求を送信する。これは、以下でより詳細に示される。以上で述べられたように、CALBufAPISは、バッファを獲得する。CALBuf212は、ユーザ空間において実行されるアプリケーションソフトウェアに対してユーザ空間のAPIを提供する。アプリケーションが、バッファを必要とするときに、それは、ある種のサイズのバッファを要求するCALBufAPIを呼び出す。次いで、CALBufモジュール204は、CALDpaaDriver212などのカーネル空間モジュールからの助けを用いて、指定されたサイズのトークン/バッファをBMan226に要求する。BMan226は、複数のコアからの同時アクセスの調停をするハードウェアエンティティである。したがって、BMan226は、いくつかのL2エンティティが、並列に実行しているので、複数のコアから同時にトークン/バッファについての要求を受信する。次いで、BMan226は、ソフトウェアロックについての必要性なしにハードウェアの形で調停を実行し、また要求するL2エンティティのおのおのは、ブロックされることなくバッファを受信する。ハードウェアコンポーネント302は、複数のコアからの同時アクセスの調停をするので、その結果は、以下でより十分に説明されるように、ソフトウェアでのロックまたはブロッキングセマフォの必要をなくすソフトウェアロックレスバッファ管理スキームである。最初に、CALDpaaDriver212は、カーネル空間にメモリの隣接チャンク316例えば、サイズが1GBを割り付ける。このメモリは、プロセッサ100が使用する外部DDRメモリであり、またそれは、一般的に、ボード上で、プロセッサと同一場所に配置される。次いで、ハードウェア支援されたプールは、バッファとして使用されることになるメモリ316のセクションを指し示すトークンを用いてシーディングされる。言い換えれば、メモリの隣接チャンク316は、各バッファプールが、特定のバッファサイズ特性を有する複数のバッファプールを含んでいる。64個のバッファプールプール304、310などの内部のトークンを使用して、ある種のサイズの特定のバッファを開始するメモリ316の内部のアドレスを迅速に取得する。メモリの隣接チャンク316は、開始アドレスと終了アドレスとを有しており、これらのアドレスは、一緒に、メモリのチャンク316のサイズおよびロケーションを規定する。メモリチャンク316の開始アドレスは、バッファプールについてのシード値を計算するときのベースポインタとして使用される。プールの内部の与えられた任意のトークンについてのシードアドレスは、次の式、すなわち、によって計算することができ、式中で、xは、プール番号であり、yは、プールxの内部のバッファまたはトークン番号であり、プール_サイズは、プールkの内部のトークンの数であり、またプール_バッファ_サイズは、プールkの内部のおのおのの個別のバッファのサイズ2KBなどである。例証の目的のために、メモリチャンク316の開始アドレスは、0x0000であることが、仮定される。したがって、上記式を使用すると、1KBのサイズのバッファを指し示す最初のプールプール1の最初のトークントークン0についてのシード値は、0例えば、0x000である。プール1の次のトークントークン1は、1024例えば、0x400などである。プール1~63は、おのおのサイズ1KBのバッファを指し示す10個のトークンを有すること、およびプール64は、サイズ8KBのバッファを指し示す10個のトークンを有することを仮定すると、最後のプールプール64は、64,512例えば、0xFC00の第1のトークン値トークン0を有することになり、次のトークン値トークン1は、72704例えば、0x11C00の値を有することになるなどである。ひとたびすべてのプールが、適切なバッファトークンを用いてシーディングされた後に、次いで、ハードウェアコンポーネント302は、ソフトウェアロックレスバッファ管理スキームを実装する際に、バッファ管理スキームを支援することができる。メモリ316とバッファプールとの獲得およびシーディングの高レベルの図が、図4によって示される。ステップ410において、CALDpaaDriver212は、上記で説明されるように外部DDRメモリの隣接チャンク316を獲得する。ステップ420において、CALDpaaDriver212は、カーネル空間のメモリ316をユーザ空間にマッピングして、データコピーを実行する必要なしに、メモリエリア316に記憶されるデータに対するユーザモードアプリケーションアクセスを可能にしている。リナックスのGPL問題に起因して、L2スケジューラは、ユーザ空間において実行される。それゆえに、ユーザ空間のアプリケーションは、カーネル空間のメモリにアクセスすることができないことになり、それでメモリは、カーネル空間からユーザ空間にマッピングされて、ユーザ空間のアプリケーションが、バッファメモリに直接にアクセスすることを可能にしている。これは、データコピーについての必要性をなくしている。ステップ430において、CALDpaaDriver212は、プールの数と、プール当たりのトークンの数と、トークンが指し示すバッファのサイズとを初期化する。ステップ440において、CALDpaaDriver212は、図3に関して説明される式のように、トークンメモリポインタを用いてプールをシーディングする。動作中に、パケットが到着するときなど、バッファ管理スキームが、バッファを必要とするときはいつでも、BMan226は、適切なハードウェアプールからトークンすなわち、バッファメモリに対するポインタを待ち行列から取り出すすなわち、取り除く。同様に、バッファが解放されるときに、バッファ管理スキームは、トークンすなわち、バッファメモリポインタをハードウェアプールの上へと戻して待ち行列に加えるすなわち、元に戻す。適切には、各バッファは、一般に、バッファ管理スキームによる使用のために予約される数バイトのヘッダおよびトレーラを有することになる。これらのヘッダおよびトレーラは、誰がバッファを所有するかなど、重要なブックキーピング情報を含んでいる。この情報は、特定のプロセスによって所有されるバッファをハードウェアプールに解放して戻すためセル回復中に必要とされることを理解されたい。当業者は、様々な上記で説明された方法のステップが、プログラムされたコンピュータによって実行され得ることを簡単に認識するであろう。本明細書においては、いくつかの実施形態はまた、プログラムストレージデバイスを、例えば、デジタルデータストレージ媒体を対象として含むことを意図しており、このプログラムストレージデバイスは、マシン読み取り可能、またはコンピュータ読み取り可能であり、また命令のマシン実行可能プログラム、またはコンピュータ実行可能プログラムを符号化し、そこでは前記命令は、前記上記で説明された方法のステップのうちの一部または全部を実行する。プログラムストレージデバイスは、例えば、デジタルメモリ、磁気ディスクや磁気テープなどの磁気ストレージ媒体、ハードドライブ、または光学的読取り可能デジタルデータストレージ媒体とすることができる。実施形態はまた、上記で説明された方法の前記ステップを実行するようにプログラムされるコンピュータを対象として含むようにも意図される。上記説明は、単に本発明の特定の実施形態の開示を提供しているにすぎず、また本発明をそれだけに限定する目的のために意図されてはいない。したがって、本発明は、上記で説明された実施形態だけには限定されない。もっと正確に言えば、当業者は、本発明の範囲内に含まれる代替的な実施形態を考えることができることが、認識される。"