(57)【特許請求の範囲】
【請求項１】
コンピュータ実装方法であって、カーネル空間およびユーザ空間を含むマルチコア・プロセッサの少なくとも１つの処理コアのために、
カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファおよび対応するＫ−Ｕマッピングされたバッファのポインタを取得するステップと、
データ・パケットを前記バッファに挿入するステップと、
前記Ｋ−Ｕマッピングされたバッファのポインタを含むフレーム記述子を作成するステップと、
前記フレーム記述子を、ＩＰアドレスをフレーム・キューにマッピングする動的な構文解析、分類、および分散（ＰＣＤ）ルールによって指定されたフレーム・キューに挿入するステップと、
前記フレーム記述子からＫ−Ｕマッピングされたバッファ記述子を作成するステップと、
前記Ｋ−Ｕマッピングされたバッファ記述子を循環バッファに挿入するステップと
を含む、方法。
【請求項２】
前記データ・パケットがトランスミッション・コントロール・プロトコル（ＴＣＰ）またはユーザ・データグラム・プロトコル（ＵＤＰ）パケットである、請求項１に記載の方法。
【請求項３】
前記循環バッファは、ユーザ空間内で実行している処理が、前記カーネル内で実行している処理によって作成または処理されたバッファへのロックレスな、ゼロ・コピーのアクセスをすることを可能にする、Ｋ−Ｕマッピングされたバッファ記述子のリングであり、
前記循環バッファは、ユーザ空間内で実行している前記処理が、プロトコル・スタックを使用せずに前記データ・パケットを処理することを可能にする、
請求項２に記載の方法。
【請求項４】
Ｋ−Ｕマッピングされたバッファの前記取得、前記データ・パケットの前記バッファへの挿入、および前記バッファ記述子の前記循環バッファへの前記挿入が、ハードウェア・コンポーネントとともに１つまたは複数のカーネル・スレッドによって実行され、前記方法が、
定期的な間隔でウェークアップするユーザ空間スレッドを実行するステップをさらに含み、
前記ユーザ空間スレッドは、ウェークアップすると、前記循環バッファ内に何らかの未処理のバッファ記述子があるかどうかを決定するために前記循環バッファに問い合わせ、
前記循環バッファ内に未処理のバッファ記述子があることを決定すると、同じまたは異なるユーザ空間スレッドを使用して前記バッファ内の前記データ・パケットを処理する、
請求項１に記載の方法。
【請求項５】
ユーザ空間処理とカーネル空間処理との間のバッファへのロックレスな、ゼロ・コピーのアクセスを提供するための装置であって、
モデム・ボードと、
前記モデム・ボードに取り付けられた複数のプロセッサ・コアを含むマルチコア・プロセッサであって、前記モデム・ボードがカーネル空間とユーザ空間とを含む、マルチコア・プロセッサと、
カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファ記述子を格納するように適合されたプロセッサ・コアのための循環バッファと、
定期的な間隔でウェークアップするように構成されたユーザ空間スレッドとを備え、
ウェークアップすると、前記ユーザ空間スレッドが、
前記循環バッファ内に１つまたは複数の未処理のバッファ記述子があるかどうかを決定するために前記循環バッファに問い合わせ、
前記循環バッファ内に未処理のバッファ記述子があることを決定すると、同じまたは異なるユーザ空間スレッドを使用して前記バッファ内の前記データ・パケットを処理するようにさらに構成される、装置。
【請求項６】
前記カーネル空間が、前記カーネル、カーネル拡張、およびデバイス・ドライバを実行するために確保され、
前記ユーザ空間が、ユーザ・モード・アプリケーションが実行されるメモリ領域である、請求項５に記載の装置。
【請求項７】
データ・パケットを受信するように構成されたイーサネット・インターフェースと、
カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファ、および対応するバッファ記述子を取得するように構成されたバッファ・マネージャと、
受信したデータ・パケットを前記Ｋ−Ｕマッピングされたバッファに挿入して、
前記対応するバッファ記述子を前記循環バッファの待ち行列に入れる
ように構成されたフレーム・マネージャと
をさらに備える、請求項５に記載の装置。
【請求項８】
前記データ・パケットがトランスミッション・コントロール・プロトコル（ＴＣＰ）またはユーザ・データグラム・プロトコル（ＵＤＰ）パケットである、請求項７に記載の装置。
【発明の詳細な説明】
【技術分野】
【０００１】
本発明の例示的実施形態は、マルチコア・プロセッサを使用する、単一のモデム・ボードにおけるマルチセル・サポートのための、ゼロ・コピー、ロックレス、およびノンブロッキングのメッセージング・スキームに関する。本発明は、ワイヤレス遠隔通信の分野を特に対象とし、したがってワイヤレス遠隔通信の分野を特に参照して説明するが、本発明は他の分野および用途で有用性を有しうることが理解されよう。
【背景技術】
【０００２】
背景として、ＬＴＥ（ロング・ターム・エボリューション）は、ＵＭＴＳ（ユニバーサル・モバイル・テレコミュニケーション・システム）モバイル電話規格を、将来の通信ネットワーク需要に対処するように改善することを目的とする、急速に進化している３ＧＰＰプロジェクトである。ＬＴＥは、ワイヤレスネットワーク効率および帯域幅を向上し、コストを削減し、サービス経験を向上させる。特に、ＬＴＥは新規のスペクトル機会を利用し、他のオープン・スタンダードとの統合の改良を提供する。ＬＴＥは、通常、ＬＴＥ  ＲＡＮ（無線アクセス・ネットワーク）（Ｅ−ＵＴＲＡＮとしても知られる）、およびＥＰＳ（進化型パケットシステム、進化型パケット・コアとも呼ばれる）を含む。
【０００３】
通信システムは、一般にデータ・プレーン機能とコントロール・プレーン機能との２つの主な機能に分けられる。従来のＬＴＥ製品では、モデム・ボードにおいて少なくとも２つのプロセッサが使用されていた。１つはコントロール・プレーン機能（非リアルタイム、たとえば、運用、管理、および保守（すなわちＯＡ＆Ｍ）、ならびに呼処理管理関連機能）をサポートするためのものであり、もう１つは、データ・プレーン機能（リアルタイム、たとえばＬＴＥ層２処理）を終了およびサポートするためのものである。コントロール・プレーンおよびデータ・プレーンの両方は、異なるオペレーティング・システム（ＯＳ）インスタンスを使用する。たとえばコントロール・プレーンはＬｉｎｕｘを使用し、データ・プレーン・コアはｖＸＷｏｒｋｓ（カリフォルニア州のＷｉｎｄ  Ｒｉｖｅｒ  Ｓｙｓｔｅｍｓ  ｏｆ  Ａｌａｍｅｄａによって作成および販売される）などのリアルタイムＯＳを使用する。一般的に、１つのモデム・ボードは１つのセクタまたはセルをサポートする。したがって、マルチセル（たとえば、３つのセルまたは６つのセル）構成をサポートするためには、セルと同数のモデム・ボードを提供することが必要になる。
【０００４】
マルチコア・プロセッサは、モデム・ボード上のＬＴＥワイヤレス基地局で使用されうる。ＰＲＥＥＭＰＴ＿ＲＴパッチを備えたＳＭＰ  Ｌｉｎｕｘなどのオペレーティング・システムは、８つの全てのコアを含んだ１つのＳＭＰパーティションにおいて実行できる。この構成では、コントロール・プレーン（非リアルタイム・スレッド／処理）およびデータ・プレーン（リアルタイム・スレッド／処理）が、たとえ別々のコアにおいて実行しなければならなくても、同じオペレーティング・システム・インスタンスを共有する。データ・プレーン・コアにおいて実行しているＬＴＥ  Ｌ２スケジューラなどの、リアルタイム処理／スレッドからＴＣＰ／ＵＤＰパケットを送信／受信するためにＬｉｎｕｘプロトコル・スタックを使用すると、ＬＴＥ  Ｌ２スケジューラの処理を停止させる可能性がある無限のレイテンシ・スパイクをもたらす場合がある。これは、Ｌｉｎｕｘプロトコル・スタックがロックレスになるように設計されていないという事実のためであり、またＬｉｎｕｘプロトコル・スタックがＯＡ＆Ｍ、およびコントロール・プレーン・コアにおいて実行しているＣＡＬＬＰなどの非リアルタイム処理／スレッドによっても使用されるためである。
【発明の概要】
【発明が解決しようとする課題】
【０００５】
ＳＭＰ環境では、あるコア（コントロール・プレーンにおいて見つけられるものなど）上の非リアルタイム処理またはスレッドによって行われるロックは、別のコア（データ・プレーンにおいて見つけられるものなど）においてそのロックの解除を待っているリアルタイム・スレッドまたは処理にレイテンシ・スパイクを生じさせる場合がある。したがって、１つのパーティションを使用するマルチコア・プロセッサベースのモデム・ボードの性能ニーズを満たすために、データ・プレーン・コア上の高速データ・パスにＬｉｎｕｘプロトコル・スタックを使用しない、ロックレス、ゼロ・コピー、ノンブロッキングのメッセージング・スキームが必要である。このようなスキームがないと、システムは、特にＬＴＥ  Ｌ２スケジューラの処理に関して、システム全体を停止させることがある無限のレイテンシ・スパイクを受ける場合がある。
【課題を解決するための手段】
【０００６】
例示的実施形態の一態様では、マルチコア・プロセッサにおける、ロックレスな、ゼロ・データ・コピーのメッセージングのためのコンピュータ実装方法が提供される。本方法は、複数の処理コアごとに、カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファおよび対応するバッファ記述子を取得するステップと、データ・パケットをバッファに挿入するステップと、バッファ記述子を循環バッファに挿入するステップとを含む。
【０００７】
他の態様では、ユーザ空間処理とカーネル空間処理との間のバッファへのロックレスな、ゼロ・コピーのアクセスを提供するための装置が提供される。本装置は、モデム・ボード、およびモデム・ボードに取り付けられた複数のプロセッサ・コアを含むマルチコア・プロセッサを備える。モデム・ボードは、カーネル空間、ユーザ空間、およびカーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファ記述子を格納するように適合されたプロセッサ・コアごとの循環バッファを含む。
【０００８】
さらに他の態様では、複数の処理コアごとに、バッファ記述子を格納するための循環バッファをコンピュータに取得させる命令を格納する、非一時的コンピュータ使用可能データ・キャリアが提供される。循環バッファに格納されたバッファ記述子は、カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファについての情報を含む。また、命令は、１つまたは複数のハードウェア・コンポーネントとともに１つまたは複数のカーネル空間スレッドを使用して、コンピュータに、イーサネット・インターフェースでデータ・パケットを受信させて、Ｋ−Ｕマッピングされたバッファおよび対応するポインタを取得させて、受信したデータ・パケットをＫ−Ｕマッピングされたバッファに挿入させて、データ・パケットを含むＫ−Ｕマッピングされたバッファ・ポインタで構成されるフレーム記述子をフレーム・キューの待ち行列に入れさせて、データ・パケットがフレーム・キューの先頭に到着した後、フレーム記述子からバッファ記述子を作成する処理を起動する割込み信号を生成させる。次いで、データ・パケットに関連付けられるバッファ記述子が、循環バッファ・マッピングへのフレーム・キューの通りに指定の循環バッファに挿入される。
【０００９】
本例示的実施形態の適用性のさらなる範囲は、以下に提供する発明を実施するための形態から明らかになるであろう。しかしながら、本発明の趣旨および範囲内の様々な変更形態および修正形態は当業者には明らかになるので、発明を実施するための形態および特定の例は、本発明の好ましい実施形態を示しているが、例示のために与えられるに過ぎないことが理解されるべきである。
【００１０】
本発明は、本デバイスの様々な部品の構成、配置、および組合せ、ならびに方法のステップにおいて存在し、その検討される目的は、以下により完全に規定され、特許請求の範囲で具体的に指摘され、添付の図面に示される通りに達成される。
【図面の簡単な説明】
【００１１】
【図１】本発明の態様による、プラットフォーム・アーキテクチャの一実施形態を示す図である。
【図２】図１に示されるコア抽象化層を実装するための例示的アーキテクチャを示す図である。
【図３】データ・パケットのイングレス（ｉｎｇｒｅｓｓ）・データ・フローを提供するための例示的ＢＥＤ  ＤＰＡＡベースのシステムを示す図である。
【図４】着信データ・パケットに関する処理フローの高水準記述を示す図である。
【図５】データ・パケットのエグレス（ｅｇｒｅｓｓ）・データ・フローを提供するための例示的ＢＥＤ  ＤＰＡＡベースのシステムを示す図である。
【図６】発信（エグレス）データ・パケットに関する処理フローの高水準記述を示す図である。
【発明を実施するための形態】
【００１２】
次に、特許請求の範囲に記載された主題を限定するためではなく、例示的実施形態を示すためだけに図示している図面を参照すると、図１は、本明細書で説明する実施形態を組み込むことができるシステムの図を提供している。
【００１３】
次に図１を参照すると、例示的プラットフォーム・アーキテクチャ１００が示されている。このアーキテクチャは、概してモデム・ボードにおいて使用されるが、他の応用で使用されうることが理解されるべきである。この実施形態では、１つのパーティションが８つの全てのコアを有するように定義される。しかし、マルチコア・プロセッサ１００は任意の数のコアを有してよいことが理解されるべきである。したがって、この実施形態では、全てのコア（たとえば、８つのコア）を実行する、単一の対称マルチプロセッシング（ＳＭＰ）オペレーティング・システム（ＯＳ）インスタンス１０２を使用することが可能である。コントロール・プレーンおよびデータ・プレーンは１つのＯＳインスタンス下にあるので、データ・プレーンの問題がコントロール・プレーンもダウンさせないことを保証するために、概して注意が必要である。
【００１４】
この例では、マルチコア・プロセッサ１００は３つのセル（図面では１０４、１０６、および１０８として示される）を供給する。それぞれのセルは、アップリンク（ＵＬ）スケジューラ（図面では１１０、１１２、および１１４として示される）、およびダウンリンク（ＤＬ）スケジューラ（図１では１１６、１１８、および１２０として示される）を必要とする。
【００１５】
無線リンク制御（ＲＬＣ）層は、ＬＴＥ電波インターフェースを介して送受信されるパケット・フレーム上のエラーをセグメント化、連結、および訂正するために使用されることが知られている。無線リンク制御およびメディア・アクセス制御（ＲＬＣ／ＭＡＣ）ソフトウェアは、ＧＰＲＳ（２．５Ｇ）ワイヤレス・スタックで使用される。ＲＬＣ／ＭＡＣソフトウェアは、移動局と基地局コントローラ（ＢＳＣ）との間の承認データ転送および未承認データ転送を提供する。したがって、モバイルとネットワークとの間で使用される電波インターフェース上の基本的転送ユニットであるＲＬＣ／ＭＡＣブロック１２２も含まれる。ＲＬＣ／ＭＡＣブロック１２２はデータおよびＲＬＣ／ＭＡＣシグナリングを搬送するために使用される。
【００１６】
マルチコア・プロセッサ１００は、運用、管理、および保守（ＯＡ＆Ｍ）１２４、ならびに非リアルタイム呼管理関連サービスを提供するＣＡＬＬＰモジュール１２６も提供する。
【００１７】
さらに、マルチコア・プロセッサ１００は、層２（Ｌ２）アプリケーション・ソフトウェアからコアの具体的詳細を隠す、コア抽象化層（ＣＡＬ）１２８を含む。層２は、コンピュータ・ネットワーキングの７層ＯＳＩモデルのデータ・リンク層である。データ・リンク層は、ワイド・エリア・ネットワーク内の隣接ネットワーク・ノード間で、または同じローカル・エリア・ネットワーク・セグメントのノード間で、データを転送するプロトコル層である。データ・リンク層は、ネットワーク・エンティティ間でデータを転送するための機能および手続的手段を提供し、物理層で発生しうるエラーを検出して、可能であれば訂正する手段を提供する可能性がある。データ・リンク・プロトコルの例は、ローカル・エリア・ネットワーク（マルチノード）用のイーサネット、ポイント・ツー・ポイント・プロトコル（ＰＰＰ）、ＨＤＬＣ、およびポイント・ツー・ポイント（デュアルノード）接続用のＡＤＣＣＰである。この場合、Ｌ２は、概して、非常に厳しいリアルタイム要件を有する、ＬＴＥ電波インターフェースに必要なＬ２スケジューラ処理を指す。
【００１８】
モバイル通信デバイスとネットワーク・スイッチング・サブシステムとの間のトラフィックおよびシグナリングの処理を担当する、基地局のリアルタイム性能ニーズを満たすために、ＰＲＥＥＭＰＴ＿ＲＴパッチを備えたＳＭＰ  ＬｉｎｕｘなどのＯＳが使用されうる。他のオペレーティング・システムが使用されうることが当然理解されるべきである。ｖｘＷｏｒｋｓを利用するためには非常に高いライセンシング料がかかるので、ｖｘＷｏｒｋｓなどのハード・コア・リアルタイムＯＳよりも、Ｐｒｅｅｍｐｔ＿ＲＴを備えたＳＭＰ  Ｌｉｎｕｘなどのオープン・ソースＯＳが選択される。このようなＳＭＰ構成における決定的動作を実現するために、システムは、コア予約およびコア親和性構造を使用する方法で実装されて、ＡＭＰのようなシステム動作を実現することが好ましい。これは、たとえばＰＲＥＥＭＰＴ＿ＲＴ  ＯＳを備えたＳＭＰ  Ｌｉｎｕｘから最高の性能を得るためにも望ましい。バッファ管理などのロックレスなゼロ・コピーのサービス、およびメッセージングのサービスの使用は、ＰＲＥＥＭＰＴ＿ＲＴ  ＯＳを備えたＳＭＰ  Ｌｉｎｕｘの使用によってもたらされる可能性のある任意のレイテンシ問題に対処するのにも役立つ場合がある。
【００１９】
図１に示されるコア抽象化層（１２８）の主な機能の１つは、マルチコア・プラットフォームの全機能を利用する様々なサービスを有する、Ｌ２処理などの高水準のアプリケーションを提供することである。したがって、コア抽象化層はいくつかの目的を達成するように設計される。第１に、コア抽象化層は、ＤＰＡＡおよびマルチコアの特定の実装形態をより高い水準のアプリケーション・ソフトウェア（すなわち、Ｌ２ソフトウェア）から隠しながら、ＢＥＤ（バックプレーン・イーサネット・ドライバ）ＤＰＡＡベースのインターフェースをサポートしなければならない。第２に、ユーザ・プレーン・データに、イングレス方向およびエグレス方向の両方の高速データ・パスを提供するために、Ｐ４０８０のＤＰＡＡハードウェア・コンポーネントを利用しなければならない。第３に、構成変更に容易に適合できるように（すなわち、コード変更せずに）、できる限りの柔軟性を提供しなければならない。ＣＡＬ構成の例は、バッファ・プール、イングレス・フレーム・キュー、およびエグレス・フレーム・キューのＤＰＡＡリソース構成である。
【００２０】
要約すると、本発明の実装形態は、１つのパーティションに全てのプロセッサ・コアを使用する。これは、ＯＳインスタンスを１つだけ使用する必要があり、ハイパーバイザを使用する必要はない。単純なＬｉｎｕｘが全てのハード・リアルタイム処理ニーズを満たすのは困難な場合があるので、ＰＲＥＥＭＰＴ＿ＲＴパッチを備えたＳＭＰ  ＬｉｎｕｘなどのＯＳが好ましい。コスト削減のために、オープン・ソースＯＳも使用される。システムは、６つのセル構成、または９つのセル構成も可能にする、ＳＭＰ構成内のＡＭＰのようなシステム動作を定義するために、ＳＭＰ  Ｌｉｎｕｘのコア親和性およびＣＰＵ予約機能をさらに組み込む。ＯＳインスタンスが非リアルタイム・コア（コントロール・プレーンなど）とリアルタイム・コア（データ・プレーンなど）との間で共有されるので、非リアルタイム・スレッド／処理によってロックが行われると問題が生じ、リアルタイム・スレッド／処理はデータ・プレーン・コアのロックの解除を待たなければならないので、リアルタイム・スレッド／処理に遅延が生じる。標準的なＬｉｎｕｘプロトコル・スタックはロックレスな実装形態を保証しないので、本発明は、プロトコル・スタックの使用を回避しながらＴＣＰ／ＵＤＰ  ＩＰパケットを送信／受信するために、データ・プレーン・コアにおいて実行しているリアルタイム処理（ＬＴＥ  Ｌ２スケジューラ）のためのロックレスなメッセージング・スキームを定義する。コントロール・プレーン・コアにおいて実行しているＯＡ＆Ｍなどの非リアルタイム処理は、通常の動作にＬｉｎｕｘプロトコル・スタックの使用を継続する。Ｌｉｎｕｘ  ＧＰＬ問題のため、我々が開発したＬＴＥ  Ｌ２スケジューラはユーザ空間で操作される。したがって、ＬＴＥ  Ｌ２スケジューラからＴＣＰ／ＵＤＰ  ＩＰデータを送受信するために、データは概してデータ・コピーが必要なユーザ空間とカーネル空間との境界を横切らなければならない。したがって、あるメモリ位置から別のメモリ位置にデータをコピーするためにプロセッサの電力を消費することによって、貴重なリソースを浪費してしまう。したがって、コントロール・プレーンが通常の方法で（たとえば、従来のＬｉｎｕｘプロトコル・スタックを使用することによって）動作できるようにしながら、データ・プレーン・コアにおいて実行しているリアルタイム・スレッド／処理のために、効率的なロックレス、ゼロ・コピー、およびノンブロッキング・メッセージング・サービスを可能にする方法およびシステムを提供することが望ましい。
【００２１】
次に図２を参照すると、これらおよび他の目的を達成する例示的アーキテクチャ２００が示されている。通常、従来のコンピュータ・オペレーティング・システムは、仮想メモリをカーネル空間とユーザ空間とに分離することが知られている。カーネル空間は、カーネル、カーネル拡張、およびほとんどのデバイス・ドライバを実行するために厳密に確保されている。一方、ユーザ空間は、全てのユーザ・モード・アプリケーションが作業するメモリ領域であり、このメモリは必要に応じてスワップ・アウトされうる。この点で、コア抽象化層（ＣＡＬ）２０１は、これに限定されないが、ＬＴＥネットワーク構成および任意の静的ＰＣＤルールをフレーム・マネージャ（ＦＭＡＮ）２３０および２３２にロードして、構成ファイルのセットに基づいてＣＡＬフレームワークをセットアップする、コア抽象化層初期化（ＣＡＬＩｎｉｔ）モジュール２０２と、コア抽象化層バッファ（ＣＡＬＢｕｆ）・モジュール２０４と、Ｌ２ソフトウェアにメッセージング・サービスを提供して、Ｌｉｎｕｘプロトコル・スタックを使用せずに他のボード（すなわち、ｅＣＣＭ）へ、またはそこからユーザ・プレーン・データを送受信する、コア抽象化層メッセージング（ＣＡＬＭｓｇ）・モジュール２０６と、イングレス・フレームを適切なコアに経路指定するために、各ＦＭＡＮ（２３０、２３２）によって使用されるべき構文解析、分類、および分散（ＰＣＤ）ルールおよび構成を提供する、コア抽象化層構文解析、分類、および分散（ＣＡＬＰｃｄＦｍｃ）モジュール２０８と、カーネル空間モジュールである、コア抽象化層ＤＰＡＡドライバ（ＣＡＬＤＰＡＡＤｒｉｖｅｒ）２１２内のトレースを可能および不可能にするためのトレーシング機能を提供する、コア抽象化層ＤＰＡＡトレース（ＣＡＬＤｐａａＴｒａｃｅ）・モジュール２１０とを含む、様々なモジュールをユーザ空間内に含む。
【００２２】
アーキテクチャ２００は、Ｐｒｅｅｍｐｔ  ＲＴパッチを備えたＳＭＰ  Ｌｉｎｕｘなどの適切なオペレーティング・システム２１４をさらに含む。次に、オペレーティング・システム２１４は、前述のＣＡＬＤＰＡＡドライバ２１２、少なくとも１つのフレーム・マネージャ（ＦＭＡＮ）・ドライバ２１６、少なくとも１つのバッファ・マネージャ（ＢＭＡＮ）・ドライバ２１８、および少なくとも１つのキュー・マネージャ（ＱＭＡＮ）・ドライバ２２０などの、様々なドライバをサポートする。
【００２３】
図２に示されるように、アーキテクチャ２００は、スケーラブル・オンチップ・ネットワークが、複数の電力アーキテクチャ処理コアとキャッシュ、スタンドアロン・キャッシュ、およびメモリ・サブシステムとを接続するために適した相互接続アーキテクチャである、Ｐ４０８０のＣｏｒｅＮｅｔファブリック２２２を適切に含みうる。
【００２４】
Ｐ４０８０プロセッサは、新規のデータ・パス加速アーキテクチャ（ＤＰＡＡ）の実装形態を含む。したがって、アーキテクチャ２００はＰ４０８０のＤＰＡＡ２２４をさらに含みうる。ＤＰＡＡ２２４は、ネットワーク・インターフェースおよびハードウェア・アクセラレータを含む、負荷の分散およびリソースの共有などのマルチコア・ネットワーク処理を最適化するように設計されている。図示されるように、ＤＰＡＡ２２４は、概してＢＭＡＮ２２６、ＱＭＡＮ２２８、ならびに第１のＦＭＡＮ２３０および第２のＦＭＡＮ２３２などの様々なマネージャをそれぞれ含む。
【００２５】
ＣＡＬＩｎｉｔモジュール２０２は、概してＬＴＥネットワーク構成および任意の静的ＰＣＤルールをフレーム・マネージャ２３０および２３２にロードして、構成ファイルのセットに基づいてＣＡＬフレームワークをセットアップする。ＣＡＬＩｎｉｔモジュール２０２は、ＦＭＣ（ＦＭａｎ構成ツール）（図示せず）または任意の数のＦＭａｎ  ＡＰＩ（図示せず）とインターフェースしてＦＭａｎ  ＰＣＤを構成し、ＣＡＬＤＰＡＡドライバ２１２とインターフェースしてＣＡＬ構成（たとえば、ユーザ・プレーンＤＰＡリソース）をロードおよびセットアップする。
【００２６】
ＣＡＬＰｃｄＦｍｃモジュール２０８は、イングレス・フレームを適切なコアに経路指定するために、各ＦＭａｎ（２３０、２３２）によって使用されるべき構文解析、分類、および分散（ＰＣＤ）ルールおよび構成を提供する。
【００２７】
ＣＡＬＩｎｉｔモジュール２０２は様々な機能の提供を担当する。ＣＡＬＩｎｉｔモジュール２０２は、マスター・コアの起動時にＣＡＬフレームワークをセットアップして「高速パス」処理をサポートする。このステップは、ＣＡＬＤＰＡＡドライバ２１２を初期化するステップを含むことができ、次にＣＡＬＤＰＡＡドライバ２１２は、（ａ）ユーザ・プレーン・データ（たとえば、バッファ・プール、ＦＱ（すなわちフレーム・キュー））を処理するために必要な様々なＤＰＡＡリソースを作成し、（ｂ）ＤＰＡＡ（たとえば、バッファ・プール構成、ＦＱ、およびイングレスＦＱとＤＬスケジューラＩＰアドレスとの間の関連を維持する内部テーブル等）を介してバッファ管理およびメッセージング・サービスをサポートするために必要なＣＡＬインフラストラクチャを作成する。ＣＡＬＩｎｉｔモジュール２０２は、ＬＴＥ  ＦＭＣの（静的）ＰＣＤルールおよびネットワーク構成もロードする。
【００２８】
ワイヤレス・マルチプル・アクセス通信システムでは、送信機および受信機は多層通信スタックを使用して通信できることが知られている。この層は、たとえば、物理層、メディア・アクセス制御（ＭＡＣ）層、無線リンク制御（ＲＬＣ）層、プロトコル層（たとえば、パケット・データ収束プロトコル（ＰＤＣＰ）層）、アプリケーション層等を含みうる。ＲＬＣ層は、ＰＤＣＰ層からサービス・データ・ユニット（ＳＤＵ）を受信して、ＭＡＣ層に送信するためにＳＤＵをＲＬＣプロトコル・データ・ユニット（ＰＤＵ）に連結または分離する。
【００２９】
したがって、ＣＡＬＢｕｆモジュール２０４は、Ｌ２アプリケーションをＲＬＣ  ＳＤＵ処理において使用するために、ロックレス・バッファ管理サービスを容易にする。当技術分野では知られているように、ノンブロッキング・アルゴリズムは、共有リソースを競合するスレッドが、相互排除によってそれらの実行を無期限に延期しないことを保証する。ノンブロッキング・アルゴリズムは、システム全体の向上が保証される場合、ロックレスである（すなわちロックがない）。ＣＡＬＢｕｆモジュール２０４は、バッファ・プール統計データ（たとえば、プール空乏状態、空乏カウント、プール可用性状態、プール割当て誤り件数等）の問合せもサポートする。ＣＡＬＢｕｆモジュール２０４は、サービスを実装するためにＣＡＬＤＰＡＡドライバ２１２とインターフェースする。ＣＡＬＢｕｆモジュール２０４は、マルチコア環境における適切なシステム・オペレーションにとって非常に重要な、ロックレスなバッファ管理スキームを提供し、非リアルタイム処理によって行われるロックは、そのロックの解除を待っているリアルタイム処理にレイテンシ問題を生じさせる場合がある。
【００３０】
ＣＡＬＤＰＡＡドライバ２１２はＣＡＬ２０１のカーネル空間コンポーネントであり、ＢＭＡＮおよびＱＭＡＮ  ＡＰＩを使用して、バッファ管理サービスおよびメッセージング・サービスの実装および提供を助ける。本明細書で使用されるように、ＡＰＩ（すなわち、アプリケーション・プログラミング・インターフェース）という用語は、ソフトウェア・プログラムによって実装されたインターフェースを指し、他のソフトウェアとの対話を可能にする。ＡＰＩは、ユーザ・インターフェースがユーザとコンピュータとの間の対話を容易にするのと同様の方法で、別のソフトウェア・プログラム間の対話を容易にする。ＡＰＩは、ボキャブラリおよび呼出規約を決定するためにアプリケーション、ライブラリ、およびオペレーティング・システムによって実装されて、それらのサービスにアクセスするために使用される。ＡＰＩは、消費者とＡＰＩの実装者との間で通信するために使用されるルーチン、データ構造、オブジェクト・クラス、およびプロトコルについての仕様を含みうる。
【００３１】
ＣＡＬＤＰＡＡドライバ２１２は、ユーザ・プレーン・データ分散のために使用されるべきＤＰＡＡリソース（バッファ・プールおよびフレーム・キュー）の管理、初期化、バッファ管理、およびメッセージング・サービスのためのオープン、解除、ｉｏ制御（ｉｏｃｔｌ）などの様々なファイル操作を介する他のＣＡＬモジュールへのユーザ空間インターフェースの提供、カーネル空間からユーザ空間への（Ｋ−Ｕ）バッファ・マッピングの実行、ＤＰＡＡバッファ・プールおよび受信機と送信機の統計データの提供、ならびにリング・バッファを管理するためのサービスの実装を担当する。リング・バッファは、ＣＡＬのＬ２ソフトウェア・キューを表し、概して特定のＬ２のＤＬＴ宛てのＦＤを格納するために使用される点に留意されたい。ＣＡＬＭｓｇモジュール２０６は、リングからバッファ記述子を取り出すために、Ｌ２にＡＰＩを提供する。
【００３２】
上述の全てのＣＡＬコンポーネントは、ＣＡＬＤＰＡＡドライバ２１２以外は、概してプラットフォーム・ミドルウェア（ユーザ空間で実行している）である。ＣＡＬＤＰＡＡドライバ２１２は、カーネル空間内で実行するカスタム・ドライバであり、ＣＡＬユーザ空間ミドルウェアによって必要とされるサービス、特に、Ｐ４０８０のＤＰＡＡハードウェア・コンポーネントに依存するサービスを実装および提供するように設計されている。
【００３３】
ＣＡＬＢｕｆモジュール２０４は、「高速パス」データ処理のためだけに使用されるべきバッファ管理サービスを提供する。ＣＡＬＢｕｆモジュール２０４は、ユーザ空間ＡＰＩをＬ２アプリケーションに提供する。ＣＡＬＢｕｆモジュール２０４は、ＣＡＬＤｐａａドライバ２１２と協働して、ＣＡＬＤｐａａドライバ２１２が作成するがＢＭＡＮ２２６によって管理されるバッファに、ゼロ・コピーでロックレスなバッファ管理サービスを提供する。
【００３４】
ＣＡＬＭｓｇモジュール２０６は、（イングレス）ＲＬＣ  ＳＤＵを受信して、ＤＰＡＡを介して（エグレス）ＲＬＣ  ＳＤＵを送信するためのサービスを提供する。ＣＡＬＭｓｇモジュール２０６は、Ｔｘ／Ｒｘイーサネット・インターフェース統計データ（たとえば、受信または送信されるＦＤの数、ドロップしたＦＤの数、様々なタイプの不良ＦＤ等）についての問合せもサポートする。ＣＡＬＭｓｇモジュール２０６は、サービスを実装するためにＣＡＬＤＰＡＡドライバ２１２とインターフェースする。ＣＡＬＭｓｇモジュール２０６は、プロトコル・スタックを使用せずにＴＣＰ／ＵＤＰ  ＩＰパケットを送受信するために、ゼロ・コピーでロックレスなメッセージング・サービスをＬＴＥ  Ｌ２アプリケーションに提供する。これにより、アプリケーション・ソフトウェアが、非常に厳密なリアルタイム処理要件を有するＬＴＥシステムの適切なシステム動作を停止させる可能性がある無限のレイテンシ・スパイクに直面しないことが保証される。
【００３５】
ＣＡＬＭｓｇモジュール２０６は、他のボード（すなわち、ｅＣＣＭ）に、またはそこからユーザ・プレーン・データを送受信するためにメッセージング・サービスをＬ２ソフトウェアに提供する。ＣＡＬＭｓｇモジュール２０６は、ＤＰＡＡを介してロックレスなゼロ・コピーのメッセージング・サービスを提供するために、概してＣＡＬＤＰＡＡドライバ２１２とインターフェースする。この特徴により、Ｌ２アプリケーション・ソフトウェアは、無限のレイテンシ遅延を回避するためにプロトコル・スタックを使用せずにＴＣＰ／ＵＤＰ  ＩＰパケットを送受信できるようになる。
【００３６】
ＣＡＬＭｓｇモジュール２０６は、以下のパラグラフで説明するサービスなどの、様々なサービスをサポートするＡＰＩを実装および提供する。
【００３７】
ある可能なサービスは、ＣＡＬＭｓｇサービスを備えた（Ｌ２）アプリケーション・エンティティの登録であり、それによってエンティティは「高速パス」を介して着信パケットを受信できるようになる。この登録処理の間、エンティティ宛ての受信したバッファ記述子を維持するために、ＣＡＬのＬ２ソフトウェア・キュー（すなわち、バッファ記述子のリング、すなわち言い換えれば、バッファ記述子の循環バッファ）が作成される。また、この登録の間、ＣＡＬＭｓｇモジュール２０６は、他の処理（たとえば、フレームがＦＱに到着したときに、バッファ記述子のどの輪がバッファ記述子をプッシュするべきかを決定する）、において後で参照するためのＩＰアドレスへのイングレスＦＱとバッファ記述子ＩＤのリングとの間の関連を作成する。また、ＣＡＬＭｓｇモジュール２０６は、カーネル空間からユーザ空間への、バッファ記述子の関連するリングのマッピングも実行し、アプリケーション・エンティティについてのＰＣＤルールを構成する（静的ルールを介してまだ行われていない場合）。さらに、登録処理の最初に、ＣＡＬ２０１は、スレッドがクラッシュすると、アプリケーションによって取得された全てのバッファが適切に解除されることを保証するための防衛戦略を実装する。
【００３８】
ＣＡＬＭｓｇモジュール２０６によって提供される第２のサービスは、アプリケーション・エンティティ宛てのフレームを取り出すことである。返されたバッファ・アドレスは、イーサネット・ヘッダで始まるペイロードの先頭を指す。
【００３９】
ＣＡＬＭｓｇモジュール２０６によって提供される第３のサービスは、ユーザ・プレーン・データ（たとえば、ｅｔｈ０）を処理するために構成されたイーサネット・インターフェース上のＤＰＡＡを介して外部エンティティにメッセージを送信することである。Ｌ２は、必要な全てのヘッダ（イーサネット、ＩＰ、ＵＤＰ）をポピュレートすることが予期され、ハードウェアはＩＰチェックサムおよびＵＤＰチェックサムを生成してポピュレートするように適切に構成される。
【００４０】
第４のサービスは、受信機および送信機ポートに統計データを問い合わせることである。
【００４１】
第５のサービスは、ＣＡＬＭｓｇモジュール２０６からアプリケーション・エンティティを登録解除することである。一旦アプリケーション・エンティティが登録解除されると、「高速パス」を介してパケットを受信できなくなる。登録解除処理の一部として、ＣＡＬは、アプリケーション・ソフトウェアによって取得された全てのバッファを解除する。高速パスを介してフレームを受信するためにＣＡＬＭｓｇモジュール２０６が使用される場合、バッファ記述子の関連するリングおよびＰＣＤルールも除去されることになる。
【００４２】
図３を参照すると、データ・パケットのイングレス・データ・フローを提供するように適合される、例示的なバックプレーン・イーサネット・ドライバ（ＢＥＤ）ＤＰＡベースのシステム３００の高水準の概要が示されている。図３の左側は、従来のプロトコル・スタックを使用してコントロール・プレーン・コアＸに向かうことになっているパケットによって取られるパスを示している。図の右手側は、ＬＴＥ  Ｌ２スケジューラが実行しているデータ・プレーン・コアＹのパケット・トラバーサルを示している。
【００４３】
例示のために、ＬＴＥ  Ｌ２スケジューラは２つのリアルタイム・スレッドで構成されている。２つのスレッドは、イングレス・パケット・フローのために作動し始める、図３にＤＬ  ＳＣＨＥＤＵＬＥＲ３２４として示されるＤＬスケジューラと、エグレス・パケット・フローのために作動し始める、ＵＬ  ＳＣＨＥＤＵＬＥＲとして示されるアップリンク・スケジューラとを含む
【００４４】
ハードウェアの観点から、それぞれのコアはソフトウェア・ポータル３１６を有する。それぞれのポータルは指定された数のチャネルを有する。それぞれのチャネルは、複数のフレーム・キュー（ＦＱ）で構成される、８つのプライオリティ・ベースのワーク・キュー（ＷＱ）を有する。
【００４５】
ＦＭＡＮ３０２が高水準でデータ・パケット３０４を受信すると、適切なサイズのカーネル空間からユーザ空間にマッピングされたバッファをＢＭＡＮ２２６から取得して、受信したパケットをバッファにコピーし、ＦＭＡＮ３０２は、どのイングレスＦＱ３０６をパケットの待ち行列に入れるかを決定して（ＰＣＤルールの通りに）、データ・パケット３０４を適切なＦＱ３０６上の待ち行列に入れるためにＱＭＡＮ  ＡＰＩ３０８を使用する。データ・パケット３０４がハードウェア・レジスタＤＱＲＲ３２８に進むと、指定されたコア（コアＹ３１２など）にポータル割込みが生成される。言い換えると、ＱＭＡＮが様々なチャネルの全てのＦＱを処理する。ＷＱはサービス品質（ＱｏＳ）を実装するためにある。それぞれの到着パケットが、ＦＱ上の待ち行列に入れられると、ＱＭＡＮ内の内部ハードウェア待ち行列を通過する。キューの先頭に辿り着き、処理の準備ができているＦＱは、ＱＭＡＮによってＤＱＲＲレジスタに入れられる。ＤＱＲＲレジスタは１５エントリの深度を有する。それぞれのエントリ（パケット・バッファへのポインタ、関連するコールバック機能などの、ＦＱについての情報を含むフレーム・キュー記述子）は、割込みサービスルーチン（ＩＳＲ）において登録されたコールバック機能３３０によって供給され、ＱＭＡＮ３０８は次のＦＱ記述子を自動的にＤＱＲＲ上の待ち行列に入れる。
【００４６】
次いで、ＦＱ３０６のＣＡＬ  ＤＰＡドライバ３１４の一部である、登録されたコールバック機能「Ｕプレーン・ディスパッチャ」３３０が、カーネル空間で実行して、適切なパケット処理を実行する。ＤＬスケジューラのインスタンスごとに、バッファ記述子３２０のリングはリングＩＤを有する。バッファ記述子３２０のリングもカーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされて、ユーザ空間（ＣＡＬＭＳＧ３２６など）およびＣＡＬ１２８のカーネル空間（ＣＡＬ  ＤＰＡドライバ３１４など）コンポーネントが、アドレス指定問題なしに、およびデータ・コピーをする必要もなしに、アクセスできるようにする。セル初期化の間、ＣＡＬＭＳＧ３２６は、ＣＡＬＭＳＧ３２６に登録するために、ユーザ・アプリケーションＤＬスケジューラ３２４にサービスを提供する。その時点で、イングレスＦＱ３０６とリングＩＤ３２０との間のマッピング関係も作成された。コールバック機能３３０は、どのリングＩＤ３２０にこの特定のフレーム・キュー記述子が属するかを決定して、特定のデータ・プレーン・コアＹ３１２上の関連するユーザ空間ＤＬスケジューラ・スレッド３２４によって後に処理するために、カーネル空間からユーザ空間にマッピングされたバッファ・ポインタを（任意のブックキーピング情報とともに）コピーして、適切なバッファ記述子をバッファ記述子３２０のカーネル空間からユーザ空間にマッピングされたリング上の待ち行列に入れることによって、バッファ記述子を作成する。
【００４７】
ＤＬスケジューラ処理３２４は、ユーザ空間内でエンドレスな「Ｒｕｎ  ｔｏ  Ｃｏｍｐｌｅｔｉｏｎ」モードで実行する。リアルタイム・スレッドは、バッファ記述子３２０のリングにおいて消費するために待ち行列に入れられたパケットがある場合、全てのＤｅｌｔａ  Ｔ時間をウェークアップし、問い合わせるためにＣＡＬＭＳＧ３２６  ＡＰＩを呼び出す。バッファ記述子３２０のリングにおいて消費するために待ち行列に入れられたパケットがある場合、ＤＬスケジューラ３２４はリング３２０上のパケットを処理する（または消費する）。受信したパケットは標準的なプロトコル・スタックを通過していないので、パケット・ヘッダ（ＴＣＰ／ＵＤＰ／ＩＰ／イーサネット）全体を含んでいる。ＤＬスケジューラ３２４は、パケット・ヘッダを無視して、パケット・ペイロードにおいて動作する。動作が行われると、ＣＡＬＢＵＦ２０４  ＡＰＩを使用してバッファを解除する。一旦ＤＬスケジューラ３２４が処理するべきパケットがなくなると、ＤＬスケジューラ・スレッド３２４はスリープに戻る。バッファ記述子３２０のリングごとに、１つの生産者（ＣＡＬ  ＤＰＡＤｒｉｖｅｒ３１４）と１つの消費者（特定のＤＬスケジューラ・スレッド３２４）しかないので、このスキームは、どのようなソフトウェア・ロックも必要としない原子動作で実装されうる。さらなる利点は、バッファ記述子３２０のリングなどのバッファ記述子のリングとともに、カーネル空間からユーザ空間にマッピングされたバッファを使用することによって達成される。カーネル空間からユーザ空間にマッピングされたバッファの使用により、パケットはカーネル空間デバイス・ドライバからユーザ空間内の最終的な宛先へとトラバースするようになるので、データ・コピーが不要になる。
【００４８】
例示的実施形態では、コントロール・プレーン・トラフィックおよびデータ・プレーン・トラフィックは互いから分離されており、別々のイーサネット・インターフェースに向けられている。ＦＭＡＮ３０２は複数のイーサネット・インターフェースをサポートしうる。Ｌｉｎｕｘプロトコル・スタックは、コントロール・プレーン・コアＸ３３２において実行することになっている。ＣＡＬ  ＰＣＤモジュールは、ＦＭＡＮ３０２が、コントロール・プレーン・イーサネット・インターフェースに到着する全てのパケット３０４を、カーネル空間で実行するＦＳＬ  ＤＰＡドライバ３３６によって処理されるフレーム・キュー（ＦＱ）３３４の待ち行列に入れられるようにする静的ＰＣＤルールをセットアップする。このドライバ３３６は、パケットをＬｉｎｕｘプロトコル・スタック３３８に引き渡す。パケットがカーネル空間とユーザ空間との境界を横切る際に、データ・コピーも含まれる。これは、図３の左側に示されている。
【００４９】
データ・プレーン・コアの着信データ・パケットに関する処理フローの高水準な図が図４に示されている。図４の方法は、図３に示した装置によって実装されうる。
【００５０】
ステップ４１０で、ＤＬスケジューラ３２０は自身をＣＡＬＭＳＧ３２６に登録する。また、システムは、カーネル空間からユーザ空間に（Ｋ−Ｕ）マッピングされたバッファ記述子３２０のリングを作成して、カーネル空間エンティティ（ＣＡＬＤＰＡＡドライバ３１４など）と、ユーザ空間エンティティ（ＣＡＬＭＳＧ３２６など）との両方がリングにアクセスできるようにする。このステップは、モデム・ボード上の構成されたセルごとに、ＣＡＬＤＰＡＡドライバ・モジュール３１４とともにＣＡＬＭＳＧ３２６によって実行されうる。したがって、３つのセルがモデム・ボードにおいてサポートされている場合、バッファ記述子３２０の３つの異なるリングがあり（それぞれのセルに１つ）、ＣＡＬＤＰＡＡドライバ３１４はイングレスＦＱ３０６とバッファ記述子３２０の特定のリングとの間にマッピングを有する。例示的実施形態では、ＤＬ  ＳＣＨＥＤＵＬＥＲインスタンス３２４ごとにバッファ記述子３２０の１つのリングがある。バッファ記述子のリングは、読出しポインタと書込みポインタとを有する。１つの生産者（たとえば、カーネル空間内のＣＡＬＤＰＡＡドライバ３１４のｕプレーン・ディスパッチャ３３０など）と１つの消費者（ユーザ空間内の特定のＤＬスケジューラ３２４など）しかないので、バッファ記述子３２０のリングは、原子動作を使用してロックレスな方法で実装される。
【００５１】
ステップ４２０で、専用データ・プレーン・イーサネット・インターフェースがデータ・パケット３０４を受信する。
【００５２】
ステップ４３０で、ＦＭＡＮ３０２がカーネル空間からユーザ空間にマッピングされたバッファ／トークンをＢＭＡＮ（図２、２２６）から取得する。
【００５３】
ステップ４４０で、ＦＭＡＮ３０２が、受信したデータ・パケット３０４を取得したバッファに挿入する。
【００５４】
ステップ４５０で、セル初期化（ＩＰアドレスとイングレスＦＱ３０６との間にマッピングを提供する）の間にＣＡＬモジュール（ＣＡＬＭＳＧ２０６）によってセットアップされた動的なＰＣＤルールごとに、ＦＭＡＮ３０２は、ＱＭＡＮ３０８の助けを借りて、パケットを適切なＦＱ３０６において待ち行列に入れる。
【００５５】
ステップ４６０で、パケットがハードウェアＤＱＲＲレジスタ３２８に進むと、システムは、Ｐ４０８０マルチコア・プロセッサを介して、コアＹ３１２（データ・プレーン・コア）用のソフトウェア・ポータル３１６への割込みを生成する。特定のＦＱについて登録されたコールバック機能（この場合は、ｕプレーン・ディスパッチャ３３０）は、カーネル空間内でＩＳＲルーチンとして実行してパケットを処理する。基本的に、コールバック機能は、処理されているＤＱＲＲエントリのフレーム・キュー記述子（ＦＤ）内に含まれる情報からバッファ記述子を作成する。ＦＤからのバッファ・ポインタが、いくつかのさらなるブックキーピング情報とともにバッファ記述子にコピーされる。
【００５６】
ステップ４７０で、ＣＡＬＤＰＡＡドライバ３１４は、ステップ４６０から生成されたバッファ記述子を、コアＹ３１２に関連付けられるバッファ記述子３２０のリングの待ち行列に入れる。
【００５７】
ステップ４１０〜４７０は、ＣＡＬＤＰＡＡドライバ３１４（たとえば、ｕプレーン・ディスパッチャ３３０）のカーネル・スレッドとともに、ハードウェア（ＦＭＡＮおよびＱＭＡＮ）によって実行される。例示的実施形態では、ステップ４８０〜４９５は、ステップ４１０〜４７０で実行された処理またはスレッドとは無関係の処理またはスレッドにおいて実行される。このように、ステップ４８０〜４９５は、データ・プレーン・コアＹ３１２上のＤＬスケジューラ３２４などのユーザ空間スレッドによって実行される。
【００５８】
ステップ４１０〜４７０と同時に、ＤＬスケジューラ３２４は完了モードへエンドレス・ランで実行し、ＴＴＩ（Ｔｉｍｅ-Ｔｏ-ｌｎｔｅｒｒｕｐｔ）間隔でウェークアップする。ステップ４８０で、一旦アウェイクすると、ＤＬスケジューラ３２４は、消費のためのバッファ記述子３２０のリング上に何らかの未処理のパケットがあるかどうかを問い合わせるために、ＣＡＬＭＳＧ  ＡＰＩ３２６を呼び出す。バッファ記述子３２０のリング上に未処理のデータ・パケットがない場合、ＤＬ  ＳＣＨＥＤＵＬＥＲ３２４は、ＣＡＬＭＳＧモジュール３２６から、未処理のパケットがないことを示すノンブロッキング応答を受信する。次いで、ＤＬスケジューラ・スレッド３２４は次のＴＴＩまでスリープに入る。
【００５９】
ステップ４８５で、未処理のデータ・パケットがあるとＤＬスケジューラ３２４が決定する場合、方法はステップ４９０に進み、そうではない場合、方法は４９５に進む。
【００６０】
ステップ４９０で、ＤＬスケジューラ３２４は、バッファ記述子３２０のリング上の次のデータ・パケットを処理する。次のパケットは、リングの読出しポインタによって示される。データ・パケットが処理された後、ＤＬスケジューラ３２４は、ＣＡＬＢＵＦ２０４のＡＰＩを使用してＫ−Ｕマッピングされたバッファを解除する。例示的実施形態では、処理されるべきデータ・パケットは、１つまたは複数のヘッダとペイロードとの両方を含む。ＤＬスケジューラ３２４はヘッダを無視して、ペイロードにおいて動作する。ヘッダはパケットを宛先に経路指定するために使用され、例示的実施形態ではプロトコル・スタックを使用せずに達成される。一旦ＤＬ  ＳＣＨＥＤＵＬＥＲ３２４が全てのパケットを処理すると、方法はステップ４９５に進んで、ＤＬ  ＳＣＨＥＤＵＬＥＲはスリープ状態に入る。
【００６１】
例示的実施形態は、３つのセルをサポートする（最大６つのセルまで拡張できる）。それぞれのセルは、自身の専用データ・プレーン・コアにおいて実行することになっている、自身のＤＬスケジューラ（ＤＬ  ＳＣＨＥＤＵＬＥＲスレッド３２４）を有する。したがって、例示的実施形態では、３つの異なるデータ・プレーン・コアにおいて実行している、最小限の３つのＤＬ  ＳＣＨＥＤＵＬＥＲ（図１、１１６、１１８、および１２０）スレッドがある。同様に、それぞれのセルはＵＬ  Ｌ２スケジューラ（ＵＬ  ＳＣＨＥＤＵＬＥＲ）を必要とする。したがって、３つの異なるデータ・プレーン・コアにおいて実行している、３つのＵＬ  ＳＣＨＥＤＵＬＥＲスレッド（図１、１１０、１１２、および１１４）がある。
【００６２】
セルのセットアップの間、動的なＰＤＣルール（すなわち、ＩＰアドレスのイングレスＦＱへのマッピング）がＣＡＬＭＳＧモジュール３２６によってセットアップされる。ＣＡＬＭＳＧモジュール３２６は、イングレスＦＱをバッファ記述子ＩＤのリングにマッピングすることなどのブックキーピング機能も実行できる。ＰＣＤルールによって、ＦＭＡＮはそれぞれのパケットのＩＰアドレスを検査して、パケットをどのＦＱの待ち行列に入れるべきかを決定できるようになる。さらなるブックキーピング情報（バッファ記述子３２０のリングへのイングレスＦＱ３０６のＩＤマッピングなど）によって、ｕプレーン・ディスパッチャ・カーネル・スレッド３３０は、着信データ・パケットに関連付けられる所与のバッファ記述子をどのバッファ記述子３２０のリングに入れるべきかを決定できるようになる。したがって、イングレス・パケットが、従来のプロトコル・スタックを使用せずにデータ・プレーン・コアＹ３１２において実行しているＤＬスケジューラ・スレッド３２４に到達できる、ロックレスな、ゼロ・コピーのメッセージング・スキームが達成される。
【００６３】
図５を参照すると、データ・パケットのエグレス・データ・フローを提供するように適合される、例示的なバックプレーン・イーサネット・ドライバ（ＢＥＤ）ＤＰＡベースのシステム５００の高水準の概要が示されている。例示的実施形態５００は、エグレス・データ・プレーン・トラフィックを送信するためにＬｉｎｕｘプロトコル・スタックを使用しないソリューションを提供する。図５の左側は、従来のプロトコル・スタック５３８を使用してコントロール・プレーン・コアＸ５３２から送信されたパケットによって取られるパスを示している。コントロール・プレーン・コアｘ５３２において実行しているＯＡ＆Ｍ１２４などの非リアルタイムユーザ空間アプリケーションが、プロトコル・スタック５３８を使用してＴＣＰ／ＵＤＰ  ＩＰパケットを送信する。プロトコル・スタック５３８は、パケットをカーネル空間内のＦＳＬ  ＤＰＡドライバ５３６に転送する。パケットをユーザ空間内のコアｘ５３２からカーネル空間内のＦＳＬ  ＤＰＡドライバ５３６に転送する処理は、データ・コピーを必要とする。ＦＳＬ  ＤＰＡドライバ５３６は、ＱＭＡＮ５０８の助けを借りてＦＭＡＮ５０６によって最終的に供給されるＦＱ５３４上の待ち行列にパケットを入れて、パケットはイーサネット・インターフェースにおいて送信される。図面の右手側は、プロトコル・スタック５３８を使用せずにＬＴＥ  Ｌ２  ＵＬスケジューラ５０２が実行しているデータ・プレーン・コアＹ５１２から出ているパケットについてのパケット・トラバーサルを示している。したがって、エグレス・データ・フローも、無限のレイテンシ・スパイクを招かないロックレスなゼロ・コピーのメッセージング・スキームを使用する。
【００６４】
発信データ・パケット（すなわち、データ・プレーン・コアのエグレス・データ・フロー）に関する処理フローの高水準な図が図６に示されている。図６の方法は、図５に示した装置によって実装されうる。
【００６５】
ステップ６１０で、ＵＬスケジューラ５０２が、カーネル空間からユーザ空間にマッピングされたバッファをＣＡＬＢＵＦ５２２から取得する。
【００６６】
ステップ６２０で、ＵＬスケジューラ５０２がＴＣＰ／ＵＤＰ  ＩＰパケットを送信する準備ができると、ＵＬスケジューラ５０２はパケット全体（ヘッダおよびペイロードを備える）を用意して、ＣＡＬＭＳＧ  ＡＰＩ５２２を呼び出す。
【００６７】
ステップ６３０で、ＣＡＬＭＳＧ５２２が、ＣＡＬＤＰＡＡドライバ５２４の助けを借りて、用意したパケットを、データ・プレーン・イーサネット・インターフェースに関連付けられるチャネルＣＨＢの適切なエグレスＦＱ５０４の待ち行列に入れる。この待ち行列化は、プロトコル・スタックを使用しないで実行され、無限のレイテンシ・スパイクを回避するために、代わりにロックレスなゼロ・メッセージング・スキームに依存する。
【００６８】
任意のステップ６４０で、ＱＭＡＮ５０８は、待ち行列動作が成功したかどうかの状況を決定し、この応答は、ユーザ・アプリケーションＵＬスケジューラ５０２がその状況の受信を所望する場合、ユーザ・アプリケーションＵＬスケジューラ５０２にまで遡って返信される。
【００６９】
ステップ６５０で、ＦＭＡＮ５０６は、ＱＭＡＮ５０８の助けを借りて、様々なＦＱ５０４からの全てのパケットを処理する。たとえ、パケットがユーザ空間とカーネル空間との境界をトラバースするたびに関連するコンテキスト切替えがあっても、関連するデータ・コピーはない。したがって、ＦＭＡＮ５０６によるパケットの処理はハードウェアで効率的な方法で実行されるので、それぞれの個々のコアにパフォーマンス上のペナルティは無視できるか、または全くない。それぞれのＵＬスケジューラ３０２は、パケットをイーサネット・インターフェースにおいて送信するための専用ＦＱ５０４を目標チャネル（ＣＨ  Ｂ５２６）上に有する。１つの生産者（ユーザ空間内の特定のＵＬ  ＳＣＨＥＤＵＬＥＲスレッド５０２インスタンス）、およびハードウェア内のＦＭＡＮ５０６によって消費される１つの専用エグレスＦＱ５０４もある。
【００７０】
ステップ６６０で、一旦パケットが送信されると、ＦＭＡＮ５０６はバッファを解除してＢＭＡＮ（図２、２２６）に戻す。
【００７１】
当業者は、上述の様々な方法のステップが、プログラムされたコンピュータで実行されうることを容易に理解できるであろう。本明細書では、いくつかの実施形態は、たとえば、デジタル・データ・ストレージ媒体などのプログラム・ストレージ・デバイスをカバーすることも企図され、それらは機械またはコンピュータ可読であり、および命令の機械実行可能またはコンピュータ実行可能プログラムを符号化し、前記命令は前記上述の方法のステップのうちのいくつかまたは全てを実行する。プログラム・ストレージ・デバイスは、たとえば、デジタル・メモリ、磁気ディスクおよび磁気テープなどの磁気ストレージ媒体、ハード・ドライブ、または光学的に読取り可能なデジタル・データ・ストレージ媒体でもよい。本実施形態は、上述の方法の前記ステップを実行するようにプログラムされたコンピュータをカバーすることも企図される。
【００７２】
上記の記述は、本発明の特定の実施形態の開示を単に提供するに過ぎず、本発明をそれに限定することを意図するものではない。したがって、本発明は上述の実施形態だけに限定されない。むしろ、当業者は本発明の範囲内の代替実施形態を想起することが理解される。
【図１】
0005726316.tif 000002
【図２】
0005726316.tif 000003
【図３】
0005726316.tif 000004
【図４】
0005726316.tif 000005
【図５】
0005726316.tif 000006
【図６】
0005726316.tif 000007