libibverbs と librxe、および HCA の低レベル カーネル ドライバーの関係を理解するのに苦労しています。
具体的には、次の疑問があります。
InfiniBand 動詞の実装は、およそ 4 つのコンポーネントで構成されます。
ib_mthcaMellanox デバイス用)ib_uverbs)libmthca)libibverbs)InfiniBand は一般に、パケットベースの操作とリモート DMA という 2 つのセマンティクスをサポートしています。動作モードに関係なく、どちらもアプリケーション バッファから直接読み書きすることでゼロコピーを実装します。これは (すでに haggai_e で説明されているように) 物理メモリ内のバッファを固定すること (登録とも呼ばれます) によって行われ、仮想メモリ マネージャがバッファをディスクにスワップしたり、物理 RAM 内を移動したりするのを防ぎます。InfiniBand の非常に優れた機能は、各 HCA が独自の仮想アドレスから物理アドレスへの変換エンジンを備えていることです。これにより、ユーザー空間ポインターをハードウェアに直接渡すことができます。
ユーザーレベルのドライバーを使用する理由は、動詞が HCA のハードウェア レジスタをユーザー空間に直接公開し、各 HCA には異なるレジスタ セットがあるため、中間ユーザー空間レイヤーが必要になるためです。もちろん、完全にカーネルに実装して、ベンダーに依存しない単一のユーザー空間ライブラリを使用することもできますが、InfiniBand は可能な限り低いレイテンシーを提供するために非常に懸命に努力しており、毎回カーネルを経由する必要があるため、非常にコストがかかります。RDMA デバイスが独自に仮想アドレスを変換できるという事実は、ワーク キューにエントリを作成するときに、ユーザー空間ライブラリがカーネルを介してバッファの物理アドレスを取得する必要がないことを意味します (動詞によって使用されるメカニズムの一部)。データを送受信します)。
基本的に 2 つのベンダー ライブラリがあることに注意してください。1 つはカーネルに、もう 1 つはユーザー空間にあります。前者はファイル システム (Lustre など) やネットワーク プロトコル ドライバー (IP-over-InfiniBand など) などの他のカーネル モジュールに動詞機能を提供し、後者はユーザー空間でその機能を提供します。一部の操作は、完全にユーザー空間で実行することはできません。たとえば、メモリの登録やデバイス コンテキストの開閉などです。これらは によってカーネル モジュールに透過的に渡されますlibibverbs。
技術的には、RDMA over Converged Ethernet (RoCE、としてユーザー空間に実装librxe) はハードウェア レベルでは InfiniBand ではありませんが、OpenFabrics スタックは、RoCE や iWARP アダプターなど、InfiniBand HCA 以外の RDMA 対応ハードウェアをサポートするように設計されています。
詳細については、Linux での InfiniBand へのアクセスに関する Intel の概要を参照してください。
私はlibrxe特にドライバーに精通していませんが、一般的に、libibverbsそれを使用してアプリケーションまたはミドルウェア ライブラリからの要求を処理し、その呼び出しを などのプロバイダー ライブラリに転送しますlibrxe。また、プロバイダ ライブラリは内部 API を使用しlibibverbsて、(モジュールを介して) RDMA カーネル モジュールにコマンドを渡しますib_uverbs。
RDMA スタックは、ユーザー空間から直接ハードウェアにアクセスできるようにするために、このように定義されています。
編集:あなたのコメントに従って、ユーザー空間からカーネルへ、およびその逆にコピーをバイパスすることについて説明しようと思います。
を使用するアプリケーションlibibverbsは、関数を使用してメモリ領域を登録しibv_reg_mrます。この関数は、 に渡された仮想メモリ領域によって使用される物理メモリ ページを特定するために、カーネル コマンドを呼び出しますibv_reg_mr。その後、カーネル ドライバーは、情報をコピーせずにこれらのページに直接アクセスできます。