Esquema de procesamiento diferido de NDKPI

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

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

La presencia del indicador es una indicación para el proveedor NDK de que puede posponer la indicación de la solicitud al hardware para su procesamiento; sin embargo, el proveedor puede procesar la nueva solicitud en cualquier momento.

La presencia de la bandera NDK_OP_FLAG_DEFER en una solicitud de iniciador no altera las responsabilidades existentes del proveedor NDK con respecto a la generación de completaciones. Una llamada a la solicitud del iniciador que devuelve un estado de error no debe dar lugar a que se pone en cola una finalización en el CQ para la solicitud con error. Por el contrario, una llamada que devuelve un estado de éxito debe dar lugar a que una finalización sea puesta en cola en el CQ siempre que el consumidor siga los requisitos adicionales que se detallan 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 de iniciador, el proveedor debe garantizar que todas las solicitudes que se enviaron anteriormente con el indicador NDK_OP_FLAG_DEFER se indiquen al hardware para su procesamiento.
  • El consumidor garantiza que, en ausencia de un fallo en línea, todas las cadenas de solicitudes del iniciador finalizarán mediante una solicitud de iniciador que no establezca el indicador 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 bandera 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 fallo en línea para 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 al hardware para su gestión.
  4. Dado que la primera llamada a NdkFastRegister se realizó correctamente, se debe generar un completamiento 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 de Proveedor de Kernel Directo para Redes (NDKPI)

  • Last updated on