Compartir a través de

Esquema de procesamiento diferido de NDKPI

  • Artículo

Hay muchos casos en los que un consumidor de NDK publicará una cadena de solicitudes de iniciador en el par de colas (QP). Por ejemplo, un consumidor podría publicar una serie de solicitudes de registro rápido seguidas de una solicitud de envío. El rendimiento de estos patrones de solicitud puede mejorarse si la cadena de solicitudes se pone en cola en el QP y, a continuación, se indica al hardware para su procesamiento como un lote, en lugar de indicar cada solicitud de la cadena al hardware, una por una.

El valor de marca de NDK_OP_FLAG_DEFER se puede usar para este propósito con los siguientes tipos de solicitud:

La presencia de la marca es una sugerencia para el proveedor NDK que puede aplazar que indique la solicitud al hardware para su procesamiento, pero el proveedor puede procesar la nueva solicitud en cualquier momento.

La presencia de la marca NDK_OP_FLAG_DEFER en una solicitud de iniciador no cambia las responsabilidades existentes del proveedor NDK con respecto a la generación de finalizaciones. Una llamada a la solicitud del iniciador que devuelve un estado de error no debe dar lugar a que una finalización se pone en cola en el CQ para la solicitud con error. Por el contrario, una llamada que devuelve un estado correcto debe dar lugar a que una finalización se pone en cola en el CQ siempre que el consumidor siga los requisitos adicionales que se enumeran a continuación.

Además de todos los requisitos de NDK existentes, se deben observar dos requisitos adicionales (uno para el proveedor y otro para el consumidor) para evitar una situación en la que las solicitudes se publican correctamente en el QP con la marca NDK_OP_FLAG_DEFER , pero nunca se indican al hardware para su procesamiento:

  • Al devolver un estado de error de una llamada a una solicitud del iniciador, el proveedor debe garantizar que todas las solicitudes que se enviaron anteriormente con la marca NDK_OP_FLAG_DEFER se indican en el hardware para su procesamiento.
  • El consumidor garantiza que, en ausencia de un error insertado, todas las cadenas de solicitudes del iniciador finalizarán mediante una solicitud del iniciador que no establezca la marca de NDK_OP_FLAG_DEFER .

Por ejemplo, considere un caso en el que un consumidor tiene una cadena de dos solicitudes de registro rápidas y un envío que necesita publicar en el QP:

  1. El consumidor publica el primer registro rápido con la marca NDK_OP_FLAG_DEFER y NdkFastRegister devuelve STATUS_SUCCESS.
  2. De nuevo, el segundo registro rápido se publica con la marca NDK_OP_FLAG_DEFER establecida, pero ahora NdkFastRegister devuelve un estado de error. En este caso, el consumidor no publicará la solicitud de envío.
  3. Al devolver el error en línea de la segunda llamada a NdkFastRegister, el proveedor NDK se asegura de que todas las solicitudes no indicadas anteriormente (el primer registro rápido en este caso) se indican en el hardware para su procesamiento.
  4. Dado que la primera llamada a NdkFastRegister se realizó correctamente, se debe generar una finalización en el CQ.
  5. Dado que la segunda llamada a NdkFastRegister produjo un error en línea, no se debe generar una finalización en el CQ.

Interfaz del proveedor de kernel directo de red (NDKPI)