Compartir a través de


OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Advertencia

Parte de la información de esta tema hace referencia al producto de versión preliminar, el cual puede sufrir importantes modificaciones antes de que se publique la versión comercial. Microsoft no proporciona ninguna garantía, expresa o implícita, con respecto a la información proporcionada aquí.

RSSv2 es una versión preliminar solo en Windows 10, versión 1809.

El OID OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES se envía a los controladores de minipuerto compatibles con RSSv2 para realizar movimientos de entradas individuales de tabla de direccionamiento indirecto. Este OID es un OID sincrónico, lo que significa que no puede devolver NDIS_STATUS_PENDING. Solo se emite como solicitud de método, en IRQL == DISPATCH_LEVEL.

Esta llamada usa el punto de entrada XxxSynchronousOidRequest, donde Xxx es Minipuerto o Filtro, en función del tipo de controlador que recibe la solicitud. Este punto de entrada provoca una comprobación de errores del sistema si ve un estado de devolución de NDIS_STATUS_PENDING.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES usa la estructura NDIS_RSS_SET_INDIRECTION_ENTRIES para indicar a un adaptador de minipuerto que realice de forma sincrónica un conjunto de acciones, donde cada acción mueve una sola entrada de la tabla de direccionamiento indirecto RSS de un VPort especificado a una CPU especificada.

Comentarios

Este OID debe ejecutarse y completarse en el contexto del procesador que lo emitió. Los controladores de minipuerto deben ejecutar completamente este OID al devolver NDIS_STATUS_SUCCESS a la capa superior. Esto significa que el controlador de minipuerto debe estar preparado para recibir solicitudes de OID de retroceso para mover varias ITE en un nuevo procesador inmediatamente después de que el primer movimiento finalice con NDIS_STATUS_SUCCESS.

Sugerencia

La ejecución completa de este OID significa que el controlador de minipuerto debe estar listo para intentar correctamente otra acción para mover un ITE. No prescribe dónde se indica el tráfico de recepción en curso justo después del movimiento de la cola, que puede estar en la CPU de origen o en la CPU de destino.

Los protocolos de capa superior emiten OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES para establecer ITE o los parámetros del procesador principal y predeterminado para que apunten a diferentes procesadores.

Este OID se puede emitir para parámetros de dirección de tráfico activos o inactivos. Para obtener más información sobre los parámetros de dirección, consulte Receive side scaling versión 2 (RSSv2). En el caso de los parámetros o ITE en estado inactivo, el controlador de minipuerto debe validar y almacenar en caché el procesador de destino hasta el siguiente cambio de estado RSS pertinente (habilitación o deshabilitación). En ese momento, los números de procesador almacenados en caché se activan y se usan para dirigir el tráfico. Las actualizaciones de los parámetros activos (que también se deben validar) deben aplicarse de inmediato para dirigir el tráfico.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES debe emitirse a un adaptador de minipuerto con la marca NDIS_OID_REQUEST_FLAGS_VPORT_ID_VALID desactivada. Esto se debe a la posibilidad de que se haga referencia a diferentes VPorts por distintos elementos de la matriz.

Este OID solo se invoca en IRQL == DISPATCH_LEVEL.

Los controladores de minipuerto deben estar preparados para controlar al menos tantas acciones de movimiento de entrada de tabla de direccionamiento indirecto como anuncian en la estructura NDIS_NIC_SWITCH_CAPABILITIES. Esto se define en el miembro NumberOfIndirectionTableEntriesPerNonDefaultPFVPort o NumberOfIndirectionTableEntriesForDefaultVPort de esa estructura o 128 en modo RSS nativo.

Los controladores de minipuerto deben intentar ejecutar tantas entradas como puedan y actualizar el miembro EntryStatus de cada NDIS_RSS_SET_INDIRECTION_ENTRY con el resultado de la operación.

Controlador de OID para OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Se espera que el controlador de OID para OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES se comporte de la siguiente manera:

  • No se permite una devolución de NDIS_STATUS_PENDING debido al tipo de llamada sincrónica del OID.
  • Finalizar los movimientos de ITE entrantes destinados a la CPU actual (iniciados previamente en procesadores remotos).
  • Se recomienda encarecidamente que los controladores de minipuerto realicen un paso de validación de parámetros completo. Si no es posible, deben realizar la validación de uno en uno y la ejecución de entradas de matriz. Los controladores de minipuerto deben comprobar específicamente si todos los objetos a los que se hace referencia son válidos:
    • No se permite devolver NDIS_STATUS_PENDING en el campo EntryStatus de un ITE.
    • El adaptador de minipuerto existe y está en buen estado. En caso contrario, establezca el campo EntryStatus de la entrada en NDIS_STATUS_ADAPTER_NOT_FOUND, NDIS_STATUS_ADAPTER_NOT_READY, etc.
    • Cada VPort existe y está en buen estado. De lo contrario, establezca el campo EntryStatus de la entrada en NDIS_STATUS_INVALID_PORT, NDIS_STATUS_INVALID_PORT_STATE, etc.
    • Cada índice de entrada de tabla de direccionamiento indirecto está dentro del intervalo configurado. Este intervalo es 0xFFFF o está en el intervalo [0...NumberOfIndirectionTableEntries - 1] establecido por el OID OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Los índices de entrada 0xFFFF y 0xFFFE tienen significados especiales: 0xFFFF define el procesador predeterminado, mientras que 0xFFFE define el procesador principal. En caso de error, el controlador establece el campo EntryStatus de la entrada en NDIS_STATUS_INVALID_PARAMETER.
    • La capa superior y el controlador de minipuerto esperan que el ITE apunte al procesador actual (CPU del actor) antes del movimiento. Es decir, el ITE no se puede redirigir de forma remota. Si esto no es así, establezca el campo EntryStatus de la entrada en NDIS_STATUS_NOT_ACCEPTED.
    • Todos los procesadores de destino son válidos y forman parte del conjunto RSS del adaptador de minipuerto. De lo contrario, establezca el campo EntryStatus de la entrada en NDIS_STATUS_INVALID_DATA.
  • Posteriormente o como parte del paso de validación de parámetros, valide la situación del recurso. Valide que el número de colas que se van a usar después de un movimiento por lotes completo (evacuación) no supere el valor de NumberOfQueues establecido en la estructura NDIS_RECEIVE_SCALE_PARAMETERS_V2 durante una solicitud OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. De lo contrario, se devuelve NDIS_STATUS_NO_QUEUES. NDIS_STATUS_NO_QUEUES debe usarse para todas las condiciones que representan una infracción del número configurado de colas. NDIS_STATUS_RESOURCES solo se debe usar para designar condiciones transitorias de memoria insuficiente.
  • Como parte de las comprobaciones de recursos, para cada entidad de escalado (por ejemplo, VPort), el controlador de minipuerto debe controlar una condición cuando todas las TI que apunten a la CPU actual se alejan de ella.

Si se superan todas las comprobaciones anteriores, el controlador de minipuerto debe poder aplicar incondicionalmente la nueva configuración y debe establecer el campo EntryStatus de cada entrada en NDIS_STATUS_SUCCESS.

En general, el controlador para este OID debe ser muy ligero. No debe llamar a servicios NDIS o del sistema operativo, salvo para posibles operaciones de sincronización como bloqueos por subproceso y NdisMConfigMSIXTableEntry.

El controlador de minipuerto no debe llamar a NDIS para indicar el estado o los eventos PnP.

El controlador de minipuerto tampoco debe usar indicaciones completas de recepción/transmisión en el contexto de este controlador OID, ya que hacerlo conduce a la recursividad. La capa superior puede invocar este OID desde el contexto de indicaciones de recepción o transmisión.

Movimiento de todas las entradas de la tabla de direccionamiento indirecto

Los controladores de minipuerto deben reconocer y controlar una solicitud especial que mueva todas las entradas de la tabla de direccionamiento indirecto fuera de la CPU actual. Dado que RSSv2 funciona con movimientos ITE individuales, los controladores de minipuerto deben garantizar la atomicidad de la operación general. Si se produce un error en el medio de un lote mientras se procesa la matriz correspondiente de comandos de movimiento, el controlador de minipuerto debe revertir todos los comandos que ya se realizaron y marcar todos los comandos como "erróneos" en el campo EntryStatus por comando. El protocolo de nivel superior siempre espera que el lote "mover todos los ITE" contenga todos los comandos marcados como "correctos" o todos los comandos marcados como "erróneos", y se supone que el tráfico obedece al estado resultante (ya sea antes o después del movimiento). Si la capa superior solo ve algunas entradas marcadas como "erróneas", comprobará el sistema y señalará al controlador de minipuerto como causa.

Para ayudar al control del controlador de minipuerto del comando "mover todos los ITE" y para evitar interbloqueos, los protocolos de nivel superior agrupan comandos de movimiento en el lote en pares de campos SwitchId + VPortId, de modo que:

  • Los comandos que la capa superior desea que se ejecuten juntos, como parte del comando "mover todo", para el mismo VPort se colocan consecutivamente en el lote global.
  • El controlador del minipuerto no debe intentar ejecutar el lote de comandos global, que puede tener como objetivo diferentes VPorts, de forma "mover todo". Solo el grupo de comandos que tienen como destino el mismo VPort (etiquetado con el mismo par SwitchId + VPortId) deben ejecutarse conforme a la semántica de "mover todo".
  • Cuando la capa superior no se preocupa por la semántica de "mover todo", puede intercalar comandos al mismo VPort con comandos a diferentes VPort(s). En este caso, si el segundo grupo de comandos al mismo VPort no se puede ejecutar debido a una infracción de "número de colas", el controlador de minipuerto marca ese grupo con el código de estado correspondiente (NDIS_STATUS_NO_QUEUES) y la capa superior asume la responsabilidad de recuperarse.

Por ejemplo, si el protocolo de capa superior intercala una serie de comandos como estos:

  • VPort=1 ITE[0,1]
  • VPort=2 ITE[0]
  • VPort=1 ITE[2]

El controlador de minipuerto no necesita intentar ejecutar atómicamente los cuatro comandos de movimiento o los tres comandos de movimiento para VPort=1 (ITE[0,1,2]). Solo necesita ejecutar el grupo VPort=1 ITE[0,1] de forma "mover todo", después el grupo VPort=2 ITE[0] y, a continuación VPort=1 ITE[2]. Los tres grupos de comandos pueden tener un resultado diferente. Por ejemplo, los grupos de VPort=1 ITE[0,1] y VPort=2 ITE[0] podrían realizarse correctamente y el grupo VPort=1 ITE[2] podría fallar. El resultado debe reflejarse en el miembro EntryStatus correspondiente de cada estructura de comandos. De esta forma, el controlador del minipuerto no necesita tomar precauciones para la ejecución segura de todo el lote (por ejemplo, bloquear todo el adaptador). Solo los comandos que tienen como destino un VPort específico deben serializarse, se pueden usar bloqueos por VPort más específicos y se evitan determinados interbloqueos.

Nota:

El grupo completo de las entradas de comando debe marcarse con el mismo estado de entrada.

Condiciones y códigos de estado de error

Este OID devuelve los siguientes códigos de estado cuando se produce un error:

status code Condición de error
NDIS_STATUS_INVALID_LENGTH El OID tiene un formato incorrecto.
NDIS_STATUS_INVALID_PARAMETER Otros campos, ya sea en el encabezado o en el propio OID (pero no en entradas de comandos individuales) contienen valores no válidos.

Requisitos

Versión: Windows 10, versión 1709 Encabezado: Ntddndis.h (include Ndis.h)

Consulte también