次の方法で共有

NDKPI 遅延処理スキーム

  • [アーティクル]

多くの場合、NDK コンシューマーがイニシエーター要求のチェーンをキューペア (QP) に送信します。 たとえば、コンシューマーは、多数の高速レジスター要求の後に送信要求を送信できます。 このような要求パターンに対するパフォーマンスは、チェーン内の各要求をハードウェアに 1 つずつ指示するのではなく、要求のチェーンが QP にキューに入れられ、バッチとして処理するようにハードウェアに示された場合に改善される可能性があります。

NDK_OP_FLAG_DEFER フラグの値は、この目的のために以下の要求タイプで使うことができます。

このフラグの存在は、NDK プロバイダーが要求をハードウェアに表示して処理するのを延期してもよいが、プロバイダーはいつでも新しい要求を処理してもよいというヒントになります。

イニシエーター要求に NDK_OP_FLAG_DEFER フラグが存在しても、完了の生成に関する NDK プロバイダーの既存の責任は変わりません。 失敗ステータスを返すイニシエーター要求を呼び出しても、失敗した要求に対して CQ に完了がキューに入れられてはなりません。 逆に、成功ステータスを返す呼び出しは、コンシューマーが以下に示す追加の要件に従っている限り、最終的に完了が CQ にキューに入れられる必要があります。

既存のすべての NDK 要件に加え、NDK_OP_FLAG_DEFER フラグを持つ QP への要求が正常に送信されたにもかかわらず、処理のためにハードウェアに指示さ れないという状況を防ぐために、2 つの追加要件（プロバイダー用とコンシューマー用）を遵守する必要があります。

  • イニシエーター要求に対する呼び出しから失敗ステータスを返す場合、NDK_OP_FLAG_DEFER フラグで以前に送信されたすべての要求が、処理のためにハードウェアに表示されることをプロバイダーは保証する必要があります。
  • コンシューマーは、インライン障害がない場合、NDK_OP_FLAG_DEFER フラグを設定しないイニシエーター要求によってすべてのイニシエーター要求チェーンが終了することを保証します。

例えば、あるコンシューマが、2 つの高速レジスター要求と、QP にポストする必要のある送信というチェーンを持っている場合を考えてみましょう。

  1. コンシューマーは、NDK_OP_FLAG_DEFER フラグを持つ最初の高速レジスターをポストし、NdkFastRegister は STATUS_SUCCESS を返します。
  2. ここでも、2 番目の高速レジスタは NDK_OP_FLAG_DEFER フラグが設定された状態でポストされますが、今度は NdkFastRegister が失敗ステータスを返します。 この場合、コンシューマーは送信要求をポストしません。
  3. NdkFastRegister への 2 番目の呼び出しに対してインラインエラーが返されると、NDK プロバイダーは、以前に送信されていないすべての要求 (この場合は最初の高速レジスター) が処理のためにハードウェアに表示されるようにします。
  4. NdkFastRegister の最初の呼び出しが成功したため、CQ に対して完了を生成する必要があります。
  5. NdkFastRegister の 2 番目の呼び出しがインラインで失敗したため、CQ に対して完了を生成してはなりません。

Network Direct Kernel Provider Interface (NDKPI)