コンピュータ実装方法であって、複数の処理コアごとに、カーネル空間からユーザ空間にK-Uマッピングされたバッファおよび対応するバッファ記述子を取得するステップと、データパケットを前記バッファに挿入するステップと、前記バッファ記述子を循環バッファに挿入するステップとを含む、方法。前記K-Uマッピングされたバッファのポインタを含むフレーム記述子を作成するステップと、前記フレーム記述子を、IPアドレスをフレームキューにマッピングする動的なPCDルールによって指定されたフレームキューに挿入するステップと、前記フレーム記述子からバッファ記述子を作成するステップとをさらに含む、請求項1に記載の方法。前記データパケットがTCPまたはUDPパケットである、請求項1に記載の方法。前記循環バッファは、ユーザ空間内で実行している処理が、前記カーネル内で実行している処理によって作成または処理されたバッファへのロックレスな、ゼロコピーのアクセスをすることを可能にする、K-Uマッピングされたバッファ記述子のリングであり、前記循環バッファは、ユーザ空間内で実行している前記処理が、プロトコルスタックを使用せずに前記データパケットを処理することを可能にする、請求項3に記載の方法。K-Uマッピングされたバッファの前記取得、前記データパケットの前記バッファへの挿入、および前記バッファ記述子の前記循環バッファへの前記挿入が、ハードウェアコンポーネントとともに1つまたは複数のカーネルスレッドによって実行され、前記方法が、定期的な間隔でウェークアップするユーザ空間スレッドを実行するステップをさらに含み、前記ユーザ空間スレッドは、ウェークアップすると、前記循環バッファ内に何らかの未処理のバッファ記述子があるかどうかを決定するために前記循環バッファに問い合わせ、前記循環バッファ内に未処理のバッファ記述子があることを決定すると、同じまたは異なるユーザ空間スレッドを使用して前記バッファ内の前記データパケットを処理する、請求項1に記載の方法。ユーザ空間処理とカーネル空間処理との間のバッファへのロックレスな、ゼロコピーのアクセスを提供するための装置であって、モデムボードと、前記モデムボードに取り付けられた複数のプロセッサコアを含むマルチコアプロセッサであって、前記モデムボードがカーネル空間とユーザ空間とを含む、マルチコアプロセッサと、カーネル空間からユーザ空間にK-Uマッピングされたバッファ記述子を格納するように適合されたプロセッサコアごとの循環バッファとを備える、装置。前記カーネル空間が、前記カーネル、カーネル拡張、およびデバイスドライバを実行するために確保され、前記ユーザ空間が、ユーザモードアプリケーションが実行されるメモリ領域である、請求項6に記載の装置。データパケットを受信するためのイーサネットインターフェースと、カーネル空間からユーザ空間にK-Uマッピングされたバッファ、および対応するバッファ記述子を取得するためのバッファマネージャと、受信したデータパケットを前記K-Uマッピングされたバッファに挿入して、前記対応するバッファ記述子を前記循環バッファの待ち行列に入れるように適合されたフレームマネージャとをさらに備える、請求項6に記載の装置。前記データパケットがTCPまたはUDPパケットである、請求項8に記載の装置。定期的な間隔でウェークアップするように適合されたユーザ空間スレッドをさらに備え、ウェークアップすると、前記ユーザスレッドが、前記循環バッファ内に何らかの未処理のバッファ記述子があるかどうかを決定するために前記循環バッファに問い合わせ、前記循環バッファ内に未処理のバッファ記述子があることを決定すると、同じまたは異なるユーザ空間スレッドを使用して前記バッファ内の前記データパケットを処理するように適合される、請求項8に記載の装置。SMP環境では、あるコアコントロールプレーンにおいて見つけられるものなど上の非リアルタイム処理またはスレッドによって行われるロックは、別のコアデータプレーンにおいて見つけられるものなどにおいてそのロックの解除を待っているリアルタイムスレッドまたは処理にレイテンシスパイクを生じさせる場合がある。したがって、1つのパーティションを使用するマルチコアプロセッサベースのモデムボードの性能ニーズを満たすために、データプレーンコア上の高速データパスにLinuxプロトコルスタックを使用しない、ロックレス、ゼロコピー、ノンブロッキングのメッセージングスキームが必要である。このようなスキームがないと、システムは、特にLTEL2スケジューラの処理に関して、システム全体を停止させることがある無限のレイテンシスパイクを受ける場合がある。例示的実施形態の一態様では、マルチコアプロセッサにおける、ロックレスな、ゼロデータコピーのメッセージングのためのコンピュータ実装方法が提供される。本方法は、複数の処理コアごとに、カーネル空間からユーザ空間にK-Uマッピングされたバッファおよび対応するバッファ記述子を取得するステップと、データパケットをバッファに挿入するステップと、バッファ記述子を循環バッファに挿入するステップとを含む。他の態様では、ユーザ空間処理とカーネル空間処理との間のバッファへのロックレスな、ゼロコピーのアクセスを提供するための装置が提供される。本装置は、モデムボード、およびモデムボードに取り付けられた複数のプロセッサコアを含むマルチコアプロセッサを備える。モデムボードは、カーネル空間、ユーザ空間、およびカーネル空間からユーザ空間にK-Uマッピングされたバッファ記述子を格納するように適合されたプロセッサコアごとの循環バッファを含む。さらに他の態様では、複数の処理コアごとに、バッファ記述子を格納するための循環バッファをコンピュータに取得させる命令を格納する、非一時的コンピュータ使用可能データキャリアが提供される。循環バッファに格納されたバッファ記述子は、カーネル空間からユーザ空間にK-Uマッピングされたバッファについての情報を含む。また、命令は、1つまたは複数のハードウェアコンポーネントとともに1つまたは複数のカーネル空間スレッドを使用して、コンピュータに、イーサネットインターフェースでデータパケットを受信させて、K-Uマッピングされたバッファおよび対応するポインタを取得させて、受信したデータパケットをK-Uマッピングされたバッファに挿入させて、データパケットを含むK-Uマッピングされたバッファポインタで構成されるフレーム記述子をフレームキューの待ち行列に入れさせて、データパケットがフレームキューの先頭に到着した後、フレーム記述子からバッファ記述子を作成する処理を起動する割込み信号を生成させる。次いで、データパケットに関連付けられるバッファ記述子が、循環バッファマッピングへのフレームキューの通りに指定の循環バッファに挿入される。本例示的実施形態の適用性のさらなる範囲は、以下に提供する発明を実施するための形態から明らかになるであろう。しかしながら、本発明の趣旨および範囲内の様々な変更形態および修正形態は当業者には明らかになるので、発明を実施するための形態および特定の例は、本発明の好ましい実施形態を示しているが、例示のために与えられるに過ぎないことが理解されるべきである。本発明は、本デバイスの様々な部品の構成、配置、および組合せ、ならびに方法のステップにおいて存在し、その検討される目的は、以下により完全に規定され、特許請求の範囲で具体的に指摘され、添付の図面に示される通りに達成される。次に、特許請求の範囲に記載された主題を限定するためではなく、例示的実施形態を示すためだけに図示している図面を参照すると、図1は、本明細書で説明する実施形態を組み込むことができるシステムの図を提供している。次に図1を参照すると、例示的プラットフォームアーキテクチャ100が示されている。このアーキテクチャは、概してモデムボードにおいて使用されるが、他の応用で使用されうることが理解されるべきである。この実施形態では、1つのパーティションが8つの全てのコアを有するように定義される。しかし、マルチコアプロセッサ100は任意の数のコアを有してよいことが理解されるべきである。したがって、この実施形態では、全てのコアたとえば、8つのコアを実行する、単一の対称マルチプロセッシングSMPオペレーティングシステムOSインスタンス102を使用することが可能である。コントロールプレーンおよびデータプレーンは1つのOSインスタンス下にあるので、データプレーンの問題がコントロールプレーンもダウンさせないことを保証するために、概して注意が必要である。この例では、マルチコアプロセッサ100は3つのセル図面では104、106、および108として示されるを供給する。それぞれのセルは、アップリンクULスケジューラ図面では110、112、および114として示される、およびダウンリンクDLスケジューラ図1では116、118、および120として示されるを必要とする。無線リンク制御RLC層は、LTE電波インターフェースを介して送受信されるパケットフレーム上のエラーをセグメント化、連結、および訂正するために使用されることが知られている。無線リンク制御およびメディアアクセス制御RLC/MACソフトウェアは、GPRS2.5Gワイヤレススタックで使用される。RLC/MACソフトウェアは、移動局と基地局コントローラBSCとの間の承認データ転送および未承認データ転送を提供する。したがって、モバイルとネットワークとの間で使用される電波インターフェース上の基本的転送ユニットであるRLC/MACブロック122も含まれる。RLC/MACブロック122はデータおよびRLC/MACシグナリングを搬送するために使用される。マルチコアプロセッサ100は、運用、管理、および保守OAM124、ならびに非リアルタイム呼管理関連サービスを提供するCALLPモジュール126も提供する。さらに、マルチコアプロセッサ100は、層2L2アプリケーションソフトウェアからコアの具体的詳細を隠す、コア抽象化層CAL128を含む。層2は、コンピュータネットワーキングの7層OSIモデルのデータリンク層である。データリンク層は、ワイドエリアネットワーク内の隣接ネットワークノード間で、または同じローカルエリアネットワークセグメントのノード間で、データを転送するプロトコル層である。データリンク層は、ネットワークエンティティ間でデータを転送するための機能および手続的手段を提供し、物理層で発生しうるエラーを検出して、可能であれば訂正する手段を提供する可能性がある。データリンクプロトコルの例は、ローカルエリアネットワークマルチノード用のイーサネット、ポイントツーポイントプロトコルPPP、HDLC、およびポイントツーポイントデュアルノード接続用のADCCPである。この場合、L2は、概して、非常に厳しいリアルタイム要件を有する、LTE電波インターフェースに必要なL2スケジューラ処理を指す。モバイル通信デバイスとネットワークスイッチングサブシステムとの間のトラフィックおよびシグナリングの処理を担当する、基地局のリアルタイム性能ニーズを満たすために、PREEMPT_RTパッチを備えたSMPLinuxなどのOSが使用されうる。他のオペレーティングシステムが使用されうることが当然理解されるべきである。vxWorksを利用するためには非常に高いライセンシング料がかかるので、vxWorksなどのハードコアリアルタイムOSよりも、Preempt_RTを備えたSMPLinuxなどのオープンソースOSが選択される。このようなSMP構成における決定的動作を実現するために、システムは、コア予約およびコア親和性構造を使用する方法で実装されて、AMPのようなシステム動作を実現することが好ましい。これは、たとえばPREEMPT_RTOSを備えたSMPLinuxから最高の性能を得るためにも望ましい。バッファ管理などのロックレスなゼロコピーのサービス、およびメッセージングのサービスの使用は、PREEMPT_RTOSを備えたSMPLinuxの使用によってもたらされる可能性のある任意のレイテンシ問題に対処するのにも役立つ場合がある。図1に示されるコア抽象化層128の主な機能の1つは、マルチコアプラットフォームの全機能を利用する様々なサービスを有する、L2処理などの高水準のアプリケーションを提供することである。したがって、コア抽象化層はいくつかの目的を達成するように設計される。第1に、コア抽象化層は、DPAAおよびマルチコアの特定の実装形態をより高い水準のアプリケーションソフトウェアすなわち、L2ソフトウェアから隠しながら、BEDバックプレーンイーサネットドライバDPAAベースのインターフェースをサポートしなければならない。第2に、ユーザプレーンデータに、イングレス方向およびエグレス方向の両方の高速データパスを提供するために、P4080のDPAAハードウェアコンポーネントを利用しなければならない。第3に、構成変更に容易に適合できるようにすなわち、コード変更せずに、できる限りの柔軟性を提供しなければならない。CAL構成の例は、バッファプール、イングレスフレームキュー、およびエグレスフレームキューのDPAAリソース構成である。要約すると、本発明の実装形態は、1つのパーティションに全てのプロセッサコアを使用する。これは、OSインスタンスを1つだけ使用する必要があり、ハイパーバイザを使用する必要はない。単純なLinuxが全てのハードリアルタイム処理ニーズを満たすのは困難な場合があるので、PREEMPT_RTパッチを備えたSMPLinuxなどのOSが好ましい。コスト削減のために、オープンソースOSも使用される。システムは、6つのセル構成、または9つのセル構成も可能にする、SMP構成内のAMPのようなシステム動作を定義するために、SMPLinuxのコア親和性およびCPU予約機能をさらに組み込む。OSインスタンスが非リアルタイムコアコントロールプレーンなどとリアルタイムコアデータプレーンなどとの間で共有されるので、非リアルタイムスレッド/処理によってロックが行われると問題が生じ、リアルタイムスレッド/処理はデータプレーンコアのロックの解除を待たなければならないので、リアルタイムスレッド/処理に遅延が生じる。標準的なLinuxプロトコルスタックはロックレスな実装形態を保証しないので、本発明は、プロトコルスタックの使用を回避しながらTCP/UDPIPパケットを送信/受信するために、データプレーンコアにおいて実行しているリアルタイム処理LTEL2スケジューラのためのロックレスなメッセージングスキームを定義する。コントロールプレーンコアにおいて実行しているOAMなどの非リアルタイム処理は、通常の動作にLinuxプロトコルスタックの使用を継続する。LinuxGPL問題のため、我々が開発したLTEL2スケジューラはユーザ空間で操作される。したがって、LTEL2スケジューラからTCP/UDPIPデータを送受信するために、データは概してデータコピーが必要なユーザ空間とカーネル空間との境界を横切らなければならない。したがって、あるメモリ位置から別のメモリ位置にデータをコピーするためにプロセッサの電力を消費することによって、貴重なリソースを浪費してしまう。したがって、コントロールプレーンが通常の方法でたとえば、従来のLinuxプロトコルスタックを使用することによって動作できるようにしながら、データプレーンコアにおいて実行しているリアルタイムスレッド/処理のために、効率的なロックレス、ゼロコピー、およびノンブロッキングメッセージングサービスを可能にする方法およびシステムを提供することが望ましい。次に図2を参照すると、これらおよび他の目的を達成する例示的アーキテクチャ200が示されている。通常、従来のコンピュータオペレーティングシステムは、仮想メモリをカーネル空間とユーザ空間とに分離することが知られている。カーネル空間は、カーネル、カーネル拡張、およびほとんどのデバイスドライバを実行するために厳密に確保されている。一方、ユーザ空間は、全てのユーザモードアプリケーションが作業するメモリ領域であり、このメモリは必要に応じてスワップアウトされうる。この点で、コア抽象化層CAL201は、これに限定されないが、LTEネットワーク構成および任意の静的PCDルールをフレームマネージャFMAN230および232にロードして、構成ファイルのセットに基づいてCALフレームワークをセットアップする、コア抽象化層初期化CALInitモジュール202と、コア抽象化層バッファCALBufモジュール204と、L2ソフトウェアにメッセージングサービスを提供して、Linuxプロトコルスタックを使用せずに他のボードすなわち、eCCMへ、またはそこからユーザプレーンデータを送受信する、コア抽象化層メッセージングCALMsgモジュール206と、イングレスフレームを適切なコアに経路指定するために、各FMAN230、232によって使用されるべき構文解析、分類、および分散PCDルールおよび構成を提供する、コア抽象化層構文解析、分類、および分散CALPcdFmcモジュール208と、カーネル空間モジュールである、コア抽象化層DPAAドライバCALDPAADriver212内のトレースを可能および不可能にするためのトレーシング機能を提供する、コア抽象化層DPAAトレースCALDpaaTraceモジュール210とを含む、様々なモジュールをユーザ空間内に含む。アーキテクチャ200は、PreemptRTパッチを備えたSMPLinuxなどの適切なオペレーティングシステム214をさらに含む。次に、オペレーティングシステム214は、前述のCALDPAAドライバ212、少なくとも1つのフレームマネージャFMANドライバ216、少なくとも1つのバッファマネージャBMANドライバ218、および少なくとも1つのキューマネージャQMANドライバ220などの、様々なドライバをサポートする。図2に示されるように、アーキテクチャ200は、スケーラブルオンチップネットワークが、複数の電力アーキテクチャ処理コアとキャッシュ、スタンドアロンキャッシュ、およびメモリサブシステムとを接続するために適した相互接続アーキテクチャである、P4080のCoreNetファブリック222を適切に含みうる。P4080プロセッサは、新規のデータパス加速アーキテクチャDPAAの実装形態を含む。したがって、アーキテクチャ200はP4080のDPAA224をさらに含みうる。DPAA224は、ネットワークインターフェースおよびハードウェアアクセラレータを含む、負荷の分散およびリソースの共有などのマルチコアネットワーク処理を最適化するように設計されている。図示されるように、DPAA224は、概してBMAN226、QMAN228、ならびに第1のFMAN230および第2のFMAN232などの様々なマネージャをそれぞれ含む。CALInitモジュール202は、概してLTEネットワーク構成および任意の静的PCDルールをフレームマネージャ230および232にロードして、構成ファイルのセットに基づいてCALフレームワークをセットアップする。CALInitモジュール202は、FMCFMan構成ツール図示せずまたは任意の数のFManAPI図示せずとインターフェースしてFManPCDを構成し、CALDPAAドライバ212とインターフェースしてCAL構成たとえば、ユーザプレーンDPAリソースをロードおよびセットアップする。CALPcdFmcモジュール208は、イングレスフレームを適切なコアに経路指定するために、各FMan230、232によって使用されるべき構文解析、分類、および分散PCDルールおよび構成を提供する。CALInitモジュール202は様々な機能の提供を担当する。CALInitモジュール202は、マスターコアの起動時にCALフレームワークをセットアップして高速パス処理をサポートする。このステップは、CALDPAAドライバ212を初期化するステップを含むことができ、次にCALDPAAドライバ212は、aユーザプレーンデータたとえば、バッファプール、FQすなわちフレームキューを処理するために必要な様々なDPAAリソースを作成し、bDPAAたとえば、バッファプール構成、FQ、およびイングレスFQとDLスケジューラIPアドレスとの間の関連を維持する内部テーブル等を介してバッファ管理およびメッセージングサービスをサポートするために必要なCALインフラストラクチャを作成する。CALInitモジュール202は、LTEFMCの静的PCDルールおよびネットワーク構成もロードする。ワイヤレスマルチプルアクセス通信システムでは、送信機および受信機は多層通信スタックを使用して通信できることが知られている。この層は、たとえば、物理層、メディアアクセス制御MAC層、無線リンク制御RLC層、プロトコル層たとえば、パケットデータ収束プロトコルPDCP層、アプリケーション層等を含みうる。RLC層は、PDCP層からサービスデータユニットSDUを受信して、MAC層に送信するためにSDUをRLCプロトコルデータユニットPDUに連結または分離する。したがって、CALBufモジュール204は、L2アプリケーションをRLCSDU処理において使用するために、ロックレスバッファ管理サービスを容易にする。当技術分野では知られているように、ノンブロッキングアルゴリズムは、共有リソースを競合するスレッドが、相互排除によってそれらの実行を無期限に延期しないことを保証する。ノンブロッキングアルゴリズムは、システム全体の向上が保証される場合、ロックレスであるすなわちロックがない。CALBufモジュール204は、バッファプール統計データたとえば、プール空乏状態、空乏カウント、プール可用性状態、プール割当て誤り件数等の問合せもサポートする。CALBufモジュール204は、サービスを実装するためにCALDPAAドライバ212とインターフェースする。CALBufモジュール204は、マルチコア環境における適切なシステムオペレーションにとって非常に重要な、ロックレスなバッファ管理スキームを提供し、非リアルタイム処理によって行われるロックは、そのロックの解除を待っているリアルタイム処理にレイテンシ問題を生じさせる場合がある。CALDPAAドライバ212はCAL201のカーネル空間コンポーネントであり、BMANおよびQMANAPIを使用して、バッファ管理サービスおよびメッセージングサービスの実装および提供を助ける。本明細書で使用されるように、APIすなわち、アプリケーションプログラミングインターフェースという用語は、ソフトウェアプログラムによって実装されたインターフェースを指し、他のソフトウェアとの対話を可能にする。APIは、ユーザインターフェースがユーザとコンピュータとの間の対話を容易にするのと同様の方法で、別のソフトウェアプログラム間の対話を容易にする。APIは、ボキャブラリおよび呼出規約を決定するためにアプリケーション、ライブラリ、およびオペレーティングシステムによって実装されて、それらのサービスにアクセスするために使用される。APIは、消費者とAPIの実装者との間で通信するために使用されるルーチン、データ構造、オブジェクトクラス、およびプロトコルについての仕様を含みうる。CALDPAAドライバ212は、ユーザプレーンデータ分散のために使用されるべきDPAAリソースバッファプールおよびフレームキューの管理、初期化、バッファ管理、およびメッセージングサービスのためのオープン、解除、io制御ioctlなどの様々なファイル操作を介する他のCALモジュールへのユーザ空間インターフェースの提供、カーネル空間からユーザ空間へのK-Uバッファマッピングの実行、DPAAバッファプールおよび受信機と送信機の統計データの提供、ならびにリングバッファを管理するためのサービスの実装を担当する。リングバッファは、CALのL2ソフトウェアキューを表し、概して特定のL2のDLT宛てのFDを格納するために使用される点に留意されたい。CALMsgモジュール206は、リングからバッファ記述子を取り出すために、L2にAPIを提供する。上述の全てのCALコンポーネントは、CALDPAAドライバ212以外は、概してプラットフォームミドルウェアユーザ空間で実行しているである。CALDPAAドライバ212は、カーネル空間内で実行するカスタムドライバであり、CALユーザ空間ミドルウェアによって必要とされるサービス、特に、P4080のDPAAハードウェアコンポーネントに依存するサービスを実装および提供するように設計されている。CALBufモジュール204は、高速パスデータ処理のためだけに使用されるべきバッファ管理サービスを提供する。CALBufモジュール204は、ユーザ空間APIをL2アプリケーションに提供する。CALBufモジュール204は、CALDpaaドライバ212と協働して、CALDpaaドライバ212が作成するがBMAN226によって管理されるバッファに、ゼロコピーでロックレスなバッファ管理サービスを提供する。CALMsgモジュール206は、イングレスRLCSDUを受信して、DPAAを介してエグレスRLCSDUを送信するためのサービスを提供する。CALMsgモジュール206は、Tx/Rxイーサネットインターフェース統計データたとえば、受信または送信されるFDの数、ドロップしたFDの数、様々なタイプの不良FD等についての問合せもサポートする。CALMsgモジュール206は、サービスを実装するためにCALDPAAドライバ212とインターフェースする。CALMsgモジュール206は、プロトコルスタックを使用せずにTCP/UDPIPパケットを送受信するために、ゼロコピーでロックレスなメッセージングサービスをLTEL2アプリケーションに提供する。これにより、アプリケーションソフトウェアが、非常に厳密なリアルタイム処理要件を有するLTEシステムの適切なシステム動作を停止させる可能性がある無限のレイテンシスパイクに直面しないことが保証される。CALMsgモジュール206は、他のボードすなわち、eCCMに、またはそこからユーザプレーンデータを送受信するためにメッセージングサービスをL2ソフトウェアに提供する。CALMsgモジュール206は、DPAAを介してロックレスなゼロコピーのメッセージングサービスを提供するために、概してCALDPAAドライバ212とインターフェースする。この特徴により、L2アプリケーションソフトウェアは、無限のレイテンシ遅延を回避するためにプロトコルスタックを使用せずにTCP/UDPIPパケットを送受信できるようになる。CALMsgモジュール206は、以下のパラグラフで説明するサービスなどの、様々なサービスをサポートするAPIを実装および提供する。ある可能なサービスは、CALMsgサービスを備えたL2アプリケーションエンティティの登録であり、それによってエンティティは高速パスを介して着信パケットを受信できるようになる。この登録処理の間、エンティティ宛ての受信したバッファ記述子を維持するために、CALのL2ソフトウェアキューすなわち、バッファ記述子のリング、すなわち言い換えれば、バッファ記述子の循環バッファが作成される。また、この登録の間、CALMsgモジュール206は、他の処理たとえば、フレームがFQに到着したときに、バッファ記述子のどの輪がバッファ記述子をプッシュするべきかを決定する、において後で参照するためのIPアドレスへのイングレスFQとバッファ記述子IDのリングとの間の関連を作成する。また、CALMsgモジュール206は、カーネル空間からユーザ空間への、バッファ記述子の関連するリングのマッピングも実行し、アプリケーションエンティティについてのPCDルールを構成する静的ルールを介してまだ行われていない場合。さらに、登録処理の最初に、CAL201は、スレッドがクラッシュすると、アプリケーションによって取得された全てのバッファが適切に解除されることを保証するための防衛戦略を実装する。CALMsgモジュール206によって提供される第2のサービスは、アプリケーションエンティティ宛てのフレームを取り出すことである。返されたバッファアドレスは、イーサネットヘッダで始まるペイロードの先頭を指す。CALMsgモジュール206によって提供される第3のサービスは、ユーザプレーンデータたとえば、eth0を処理するために構成されたイーサネットインターフェース上のDPAAを介して外部エンティティにメッセージを送信することである。L2は、必要な全てのヘッダイーサネット、IP、UDPをポピュレートすることが予期され、ハードウェアはIPチェックサムおよびUDPチェックサムを生成してポピュレートするように適切に構成される。第4のサービスは、受信機および送信機ポートに統計データを問い合わせることである。第5のサービスは、CALMsgモジュール206からアプリケーションエンティティを登録解除することである。一旦アプリケーションエンティティが登録解除されると、高速パスを介してパケットを受信できなくなる。登録解除処理の一部として、CALは、アプリケーションソフトウェアによって取得された全てのバッファを解除する。高速パスを介してフレームを受信するためにCALMsgモジュール206が使用される場合、バッファ記述子の関連するリングおよびPCDルールも除去されることになる。図3を参照すると、データパケットのイングレスデータフローを提供するように適合される、例示的なバックプレーンイーサネットドライバBEDDPAベースのシステム300の高水準の概要が示されている。図3の左側は、従来のプロトコルスタックを使用してコントロールプレーンコアXに向かうことになっているパケットによって取られるパスを示している。図の右手側は、LTEL2スケジューラが実行しているデータプレーンコアYのパケットトラバーサルを示している。例示のために、LTEL2スケジューラは2つのリアルタイムスレッドで構成されている。2つのスレッドは、イングレスパケットフローのために作動し始める、図3にDLSCHEDULER324として示されるDLスケジューラと、エグレスパケットフローのために作動し始める、ULSCHEDULERとして示されるアップリンクスケジューラとを含むハードウェアの観点から、それぞれのコアはソフトウェアポータル316を有する。それぞれのポータルは指定された数のチャネルを有する。それぞれのチャネルは、複数のフレームキューFQで構成される、8つのプライオリティベースのワークキューWQを有する。FMAN302が高水準でデータパケット304を受信すると、適切なサイズのカーネル空間からユーザ空間にマッピングされたバッファをBMAN226から取得して、受信したパケットをバッファにコピーし、FMAN302は、どのイングレスFQ306をパケットの待ち行列に入れるかを決定してPCDルールの通りに、データパケット304を適切なFQ306上の待ち行列に入れるためにQMANAPI308を使用する。データパケット304がハードウェアレジスタDQRR328に進むと、指定されたコアコアY312などにポータル割込みが生成される。言い換えると、QMANが様々なチャネルの全てのFQを処理する。WQはサービス品質QoSを実装するためにある。それぞれの到着パケットが、FQ上の待ち行列に入れられると、QMAN内の内部ハードウェア待ち行列を通過する。キューの先頭に辿り着き、処理の準備ができているFQは、QMANによってDQRRレジスタに入れられる。DQRRレジスタは15エントリの深度を有する。それぞれのエントリパケットバッファへのポインタ、関連するコールバック機能などの、FQについての情報を含むフレームキュー記述子は、割込みサービスルーチンISRにおいて登録されたコールバック機能330によって供給され、QMAN308は次のFQ記述子を自動的にDQRR上の待ち行列に入れる。次いで、FQ306のCALDPAドライバ314の一部である、登録されたコールバック機能Uプレーンディスパッチャ330が、カーネル空間で実行して、適切なパケット処理を実行する。DLスケジューラのインスタンスごとに、バッファ記述子320のリングはリングIDを有する。バッファ記述子320のリングもカーネル空間からユーザ空間にK-Uマッピングされて、ユーザ空間CALMSG326などおよびCAL128のカーネル空間CALDPAドライバ314などコンポーネントが、アドレス指定問題なしに、およびデータコピーをする必要もなしに、アクセスできるようにする。セル初期化の間、CALMSG326は、CALMSG326に登録するために、ユーザアプリケーションDLスケジューラ324にサービスを提供する。その時点で、イングレスFQ306とリングID320との間のマッピング関係も作成された。コールバック機能330は、どのリングID320にこの特定のフレームキュー記述子が属するかを決定して、特定のデータプレーンコアY312上の関連するユーザ空間DLスケジューラスレッド324によって後に処理するために、カーネル空間からユーザ空間にマッピングされたバッファポインタを任意のブックキーピング情報とともにコピーして、適切なバッファ記述子をバッファ記述子320のカーネル空間からユーザ空間にマッピングされたリング上の待ち行列に入れることによって、バッファ記述子を作成する。DLスケジューラ処理324は、ユーザ空間内でエンドレスなRuntoCompletionモードで実行する。リアルタイムスレッドは、バッファ記述子320のリングにおいて消費するために待ち行列に入れられたパケットがある場合、全てのDeltaT時間をウェークアップし、問い合わせるためにCALMSG326APIを呼び出す。バッファ記述子320のリングにおいて消費するために待ち行列に入れられたパケットがある場合、DLスケジューラ324はリング320上のパケットを処理するまたは消費する。受信したパケットは標準的なプロトコルスタックを通過していないので、パケットヘッダTCP/UDP/IP/イーサネット全体を含んでいる。DLスケジューラ324は、パケットヘッダを無視して、パケットペイロードにおいて動作する。動作が行われると、CALBUF204APIを使用してバッファを解除する。一旦DLスケジューラ324が処理するべきパケットがなくなると、DLスケジューラスレッド324はスリープに戻る。バッファ記述子320のリングごとに、1つの生産者CALDPADriver314と1つの消費者特定のDLスケジューラスレッド324しかないので、このスキームは、どのようなソフトウェアロックも必要としない原子動作で実装されうる。さらなる利点は、バッファ記述子320のリングなどのバッファ記述子のリングとともに、カーネル空間からユーザ空間にマッピングされたバッファを使用することによって達成される。カーネル空間からユーザ空間にマッピングされたバッファの使用により、パケットはカーネル空間デバイスドライバからユーザ空間内の最終的な宛先へとトラバースするようになるので、データコピーが不要になる。例示的実施形態では、コントロールプレーントラフィックおよびデータプレーントラフィックは互いから分離されており、別々のイーサネットインターフェースに向けられている。FMAN302は複数のイーサネットインターフェースをサポートしうる。Linuxプロトコルスタックは、コントロールプレーンコアX332において実行することになっている。CALPCDモジュールは、FMAN302が、コントロールプレーンイーサネットインターフェースに到着する全てのパケット304を、カーネル空間で実行するFSLDPAドライバ336によって処理されるフレームキューFQ334の待ち行列に入れられるようにする静的PCDルールをセットアップする。このドライバ336は、パケットをLinuxプロトコルスタック338に引き渡す。パケットがカーネル空間とユーザ空間との境界を横切る際に、データコピーも含まれる。これは、図3の左側に示されている。データプレーンコアの着信データパケットに関する処理フローの高水準な図が図4に示されている。図4の方法は、図3に示した装置によって実装されうる。ステップ410で、DLスケジューラ320は自身をCALMSG326に登録する。また、システムは、カーネル空間からユーザ空間にK-Uマッピングされたバッファ記述子320のリングを作成して、カーネル空間エンティティCALDPAAドライバ314などと、ユーザ空間エンティティCALMSG326などとの両方がリングにアクセスできるようにする。このステップは、モデムボード上の構成されたセルごとに、CALDPAAドライバモジュール314とともにCALMSG326によって実行されうる。したがって、3つのセルがモデムボードにおいてサポートされている場合、バッファ記述子320の3つの異なるリングがありそれぞれのセルに1つ、CALDPAAドライバ314はイングレスFQ306とバッファ記述子320の特定のリングとの間にマッピングを有する。例示的実施形態では、DLSCHEDULERインスタンス324ごとにバッファ記述子320の1つのリングがある。バッファ記述子のリングは、読出しポインタと書込みポインタとを有する。1つの生産者たとえば、カーネル空間内のCALDPAAドライバ314のuプレーンディスパッチャ330などと1つの消費者ユーザ空間内の特定のDLスケジューラ324などしかないので、バッファ記述子320のリングは、原子動作を使用してロックレスな方法で実装される。ステップ420で、専用データプレーンイーサネットインターフェースがデータパケット304を受信する。ステップ430で、FMAN302がカーネル空間からユーザ空間にマッピングされたバッファ/トークンをBMAN図2、226から取得する。ステップ440で、FMAN302が、受信したデータパケット304を取得したバッファに挿入する。ステップ450で、セル初期化IPアドレスとイングレスFQ306との間にマッピングを提供するの間にCALモジュールCALMSG206によってセットアップされた動的なPCDルールごとに、FMAN302は、QMAN308の助けを借りて、パケットを適切なFQ306において待ち行列に入れる。ステップ460で、パケットがハードウェアDQRRレジスタ328に進むと、システムは、P4080マルチコアプロセッサを介して、コアY312データプレーンコア用のソフトウェアポータル316への割込みを生成する。特定のFQについて登録されたコールバック機能この場合は、uプレーンディスパッチャ330は、カーネル空間内でISRルーチンとして実行してパケットを処理する。基本的に、コールバック機能は、処理されているDQRRエントリのフレームキュー記述子FD内に含まれる情報からバッファ記述子を作成する。FDからのバッファポインタが、いくつかのさらなるブックキーピング情報とともにバッファ記述子にコピーされる。ステップ470で、CALDPAAドライバ314は、ステップ460から生成されたバッファ記述子を、コアY312に関連付けられるバッファ記述子320のリングの待ち行列に入れる。ステップ410~470は、CALDPAAドライバ314たとえば、uプレーンディスパッチャ330のカーネルスレッドとともに、ハードウェアFMANおよびQMANによって実行される。例示的実施形態では、ステップ480~495は、ステップ410~470で実行された処理またはスレッドとは無関係の処理またはスレッドにおいて実行される。このように、ステップ480~495は、データプレーンコアY312上のDLスケジューラ324などのユーザ空間スレッドによって実行される。ステップ410~470と同時に、DLスケジューラ324は完了モードへエンドレスランで実行し、TTITimeTolnterrupt間隔でウェークアップする。ステップ480で、一旦アウェイクすると、DLスケジューラ324は、消費のためのバッファ記述子320のリング上に何らかの未処理のパケットがあるかどうかを問い合わせるために、CALMSGAPI326を呼び出す。バッファ記述子320のリング上に未処理のデータパケットがない場合、DLSCHEDULER324は、CALMSGモジュール326から、未処理のパケットがないことを示すノンブロッキング応答を受信する。次いで、DLスケジューラスレッド324は次のTTIまでスリープに入る。ステップ485で、未処理のデータパケットがあるとDLスケジューラ324が決定する場合、方法はステップ490に進み、そうではない場合、方法は495に進む。ステップ490で、DLスケジューラ324は、バッファ記述子320のリング上の次のデータパケットを処理する。次のパケットは、リングの読出しポインタによって示される。データパケットが処理された後、DLスケジューラ324は、CALBUF204のAPIを使用してK-Uマッピングされたバッファを解除する。例示的実施形態では、処理されるべきデータパケットは、1つまたは複数のヘッダとペイロードとの両方を含む。DLスケジューラ324はヘッダを無視して、ペイロードにおいて動作する。ヘッダはパケットを宛先に経路指定するために使用され、例示的実施形態ではプロトコルスタックを使用せずに達成される。一旦DLSCHEDULER324が全てのパケットを処理すると、方法はステップ495に進んで、DLSCHEDULERはスリープ状態に入る。例示的実施形態は、3つのセルをサポートする最大6つのセルまで拡張できる。それぞれのセルは、自身の専用データプレーンコアにおいて実行することになっている、自身のDLスケジューラDLSCHEDULERスレッド324を有する。したがって、例示的実施形態では、3つの異なるデータプレーンコアにおいて実行している、最小限の3つのDLSCHEDULER図1、116、118、および120スレッドがある。同様に、それぞれのセルはULL2スケジューラULSCHEDULERを必要とする。したがって、3つの異なるデータプレーンコアにおいて実行している、3つのULSCHEDULERスレッド図1、110、112、および114がある。セルのセットアップの間、動的なPDCルールすなわち、IPアドレスのイングレスFQへのマッピングがCALMSGモジュール326によってセットアップされる。CALMSGモジュール326は、イングレスFQをバッファ記述子IDのリングにマッピングすることなどのブックキーピング機能も実行できる。PCDルールによって、FMANはそれぞれのパケットのIPアドレスを検査して、パケットをどのFQの待ち行列に入れるべきかを決定できるようになる。さらなるブックキーピング情報バッファ記述子320のリングへのイングレスFQ306のIDマッピングなどによって、uプレーンディスパッチャカーネルスレッド330は、着信データパケットに関連付けられる所与のバッファ記述子をどのバッファ記述子320のリングに入れるべきかを決定できるようになる。したがって、イングレスパケットが、従来のプロトコルスタックを使用せずにデータプレーンコアY312において実行しているDLスケジューラスレッド324に到達できる、ロックレスな、ゼロコピーのメッセージングスキームが達成される。図5を参照すると、データパケットのエグレスデータフローを提供するように適合される、例示的なバックプレーンイーサネットドライバBEDDPAベースのシステム500の高水準の概要が示されている。例示的実施形態500は、エグレスデータプレーントラフィックを送信するためにLinuxプロトコルスタックを使用しないソリューションを提供する。図5の左側は、従来のプロトコルスタック538を使用してコントロールプレーンコアX532から送信されたパケットによって取られるパスを示している。コントロールプレーンコアx532において実行しているOAM124などの非リアルタイムユーザ空間アプリケーションが、プロトコルスタック538を使用してTCP/UDPIPパケットを送信する。プロトコルスタック538は、パケットをカーネル空間内のFSLDPAドライバ536に転送する。パケットをユーザ空間内のコアx532からカーネル空間内のFSLDPAドライバ536に転送する処理は、データコピーを必要とする。FSLDPAドライバ536は、QMAN508の助けを借りてFMAN506によって最終的に供給されるFQ534上の待ち行列にパケットを入れて、パケットはイーサネットインターフェースにおいて送信される。図面の右手側は、プロトコルスタック538を使用せずにLTEL2ULスケジューラ502が実行しているデータプレーンコアY512から出ているパケットについてのパケットトラバーサルを示している。したがって、エグレスデータフローも、無限のレイテンシスパイクを招かないロックレスなゼロコピーのメッセージングスキームを使用する。発信データパケットすなわち、データプレーンコアのエグレスデータフローに関する処理フローの高水準な図が図6に示されている。図6の方法は、図5に示した装置によって実装されうる。ステップ610で、ULスケジューラ502が、カーネル空間からユーザ空間にマッピングされたバッファをCALBUF522から取得する。ステップ620で、ULスケジューラ502がTCP/UDPIPパケットを送信する準備ができると、ULスケジューラ502はパケット全体ヘッダおよびペイロードを備えるを用意して、CALMSGAPI522を呼び出す。ステップ630で、CALMSG522が、CALDPAAドライバ524の助けを借りて、用意したパケットを、データプレーンイーサネットインターフェースに関連付けられるチャネルCHBの適切なエグレスFQ504の待ち行列に入れる。この待ち行列化は、プロトコルスタックを使用しないで実行され、無限のレイテンシスパイクを回避するために、代わりにロックレスなゼロメッセージングスキームに依存する。任意のステップ640で、QMAN508は、待ち行列動作が成功したかどうかの状況を決定し、この応答は、ユーザアプリケーションULスケジューラ502がその状況の受信を所望する場合、ユーザアプリケーションULスケジューラ502にまで遡って返信される。ステップ650で、FMAN506は、QMAN508の助けを借りて、様々なFQ504からの全てのパケットを処理する。たとえ、パケットがユーザ空間とカーネル空間との境界をトラバースするたびに関連するコンテキスト切替えがあっても、関連するデータコピーはない。したがって、FMAN506によるパケットの処理はハードウェアで効率的な方法で実行されるので、それぞれの個々のコアにパフォーマンス上のペナルティは無視できるか、または全くない。それぞれのULスケジューラ302は、パケットをイーサネットインターフェースにおいて送信するための専用FQ504を目標チャネルCHB526上に有する。1つの生産者ユーザ空間内の特定のULSCHEDULERスレッド502インスタンス、およびハードウェア内のFMAN506によって消費される1つの専用エグレスFQ504もある。ステップ660で、一旦パケットが送信されると、FMAN506はバッファを解除してBMAN図2、226に戻す。当業者は、上述の様々な方法のステップが、プログラムされたコンピュータで実行されうることを容易に理解できるであろう。本明細書では、いくつかの実施形態は、たとえば、デジタルデータストレージ媒体などのプログラムストレージデバイスをカバーすることも企図され、それらは機械またはコンピュータ可読であり、および命令の機械実行可能またはコンピュータ実行可能プログラムを符号化し、前記命令は前記上述の方法のステップのうちのいくつかまたは全てを実行する。プログラムストレージデバイスは、たとえば、デジタルメモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハードドライブ、または光学的に読取り可能なデジタルデータストレージ媒体でもよい。本実施形態は、上述の方法の前記ステップを実行するようにプログラムされたコンピュータをカバーすることも企図される。上記の記述は、本発明の特定の実施形態の開示を単に提供するに過ぎず、本発明をそれに限定することを意図するものではない。したがって、本発明は上述の実施形態だけに限定されない。むしろ、当業者は本発明の範囲内の代替実施形態を想起することが理解される。