Escalado lateral de recepción versión 2 (RSSv2)
El escalado lateral de recepción mejora el rendimiento del sistema relacionado con el control de datos de red en sistemas multiprocesador. NDIS 6.80 y versiones posteriores admiten RSS versión 2 (RSSv2), que amplía RSS ofreciendo distribución dinámica por VPort de colas.
Información general
En comparación con RSSv1, RSSv2 acorta el tiempo entre la medición de la carga de CPU y la actualización de la tabla de direccionamiento indirecto. Esto evita la ralentización durante situaciones de tráfico elevado. Para ello, RSSv2 realiza sus acciones en IRQL = DISPATCH_LEVEL, en el contexto del procesador de controlar la solicitud y solo funciona en un subconjunto de entradas de tabla de direccionamiento indirecto que apuntan al procesador actual. Esto significa que RSSv2 puede distribuir dinámicamente las colas de recepción en varios procesadores de forma mucho más dinámica que RSSv1.
Se han introducido dos OID, OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 y OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, en RSSv2 para que los controladores de miniporte establezcan las funcionalidades RSS adecuadas y controle la tabla de direccionamiento indirecto respectivamente. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 es un OID normal, mientras que OID_GEN_RSS_SET_INDIRECTION_ENTRIES es un OID sincrónico que no puede devolver NDIS_STATUS_PENDING. Para obtener más información sobre estos OID, consulta sus páginas de referencia individuales. Para obtener más información sobre los OID sincrónicos, consulta Interfaz de solicitud OID sincrónica en NDIS 6.80.
Terminología de RSSv2
En este tema se usan los siguientes términos:
| Término | Definición |
|---|---|
| RSSv1 | El mecanismo de escalado lateral de la primera generación. Usa OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | El mecanismo de escalado lateral de segunda generación admitido en Windows 10, versión 1803 y posteriores, descrito en este tema. |
| Entidad de escalado | El propio adaptador de miniporte en modo RSS nativo o un VPort en modo RSSv2. |
| ITE | Entrada de tabla de direccionamiento indirecto (ITE) de una entidad de escalado determinada. El número total de ITE por VPort no puede superar NumberOfIndirectionTableEntriesPerNonDefaultPFVPort o NumberOfIndirectionTableEntriesForDefaultVPort en modo VMQ o 128 en el caso RSS nativo. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort y NumberOfIndirectionTableEntriesForDefaultVPort son miembros de la estructura de NDIS_NIC_SWITCH_CAPABILITIES . |
| Modo de escalado | La directiva vmswitch por VPort que controla cómo se controlan sus ITE en tiempo de ejecución. Esto puede ser estático (no se mueve ITE debido a cambios de carga) o dinámico (expansión y fusión en función de la carga de tráfico actual). |
| Cola | Objeto de hardware subyacente (cola) que respalda un ITE. En función del hardware y la tabla de direccionamiento indirecto, la cola de configuración puede hacer una copia de seguridad de varias TI. El número total de colas, incluida la que usa la cola predeterminada, no puede superar el límite preconfigurado establecido normalmente por un administrador. |
| Procesador predeterminado | Procesador que recibe paquetes para los que no se puede calcular el hash. Cada VPort tiene un procesador predeterminado. |
| Procesador principal | Procesador especificado como miembro ProcessorAffinity de la estructura NDIS_NIC_SWITCH_VPORT_PARAMETERS durante la creación de VPort. Este procesador se puede actualizar en tiempo de ejecución y especifica dónde se dirige el tráfico de VMQ. |
| CPU de origen | Procesador al que está asignado actualmente el ITE. |
| CPU de destino | Procesador al que se va a reasignar el ITE (mediante RSSv2). |
| Actor CPU | Procesador en el que se realizan solicitudes de RSSv2. |
Publicidad de la funcionalidad RSSv2 en un controlador de miniport
Los controladores de miniport anuncian la compatibilidad con RSSv2 estableciendo el miembro CapabilitiesFlags de la estructura de NDIS_RECEIVE_SCALE_CAPABILITIES con la marca NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE . Esta funcionalidad es necesaria para habilitar la característica de equilibrio de carga de CPU de RSSv2, junto con la marca NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED que habilita el equilibrio dinámico de RSSv1 para VPorts (VMQs) no predeterminados.
Nota:
Los protocolos de nivel superior suponen que el procesador principal del VPort predeterminado se puede mover para los controladores de miniport de RSSv2.
Si un adaptador de miniporte no anuncia la funcionalidad RSSv2, todas las VPorts habilitadas para VMQ permanecen en modo de propagación estática incluso si se solicitan estas VPorts para realizar la propagación dinámica. El OID de RSSv1 para la configuración de parámetros RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, se usa para estos VPorts que todavía están en modo de propagación estática.
Los controladores de miniport solo necesitan implementar un mecanismo de control RSS: RSSv1 o RSSv2. Si el controlador anuncia la compatibilidad con RSSv2, NDIS convertirá los OID de RSSv1 en OID de RSSv2 si es necesario para configurar la propagación por VPort. El controlador de miniport debe admitir los dos nuevos OID y modificar el comportamiento del OID_GEN_RECEIVE_SCALE_PARAMETERS OID de RSSv1 de la siguiente manera:
- OID_GEN_RECEIVE_SCALE_PARAMETERS solo se usa para las solicitudes de consulta en RSSv2 y no para establecer parámetros RSS.
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 es una consulta y un OID establecido que se usa para configurar los parámetros de la entidad de escalado, como el número de colas, el número de ITE, la habilitación y deshabilitación de RSS y las actualizaciones de clave hash.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES es un OID de método que se usa para realizar la modificación de entradas de tabla de direccionamiento indirecto.
Control de los OID de RSSv2
OID_GEN_RECEIVE_SCALE_PARAMETERS solo se usa para consultar los parámetros RSS actuales de una entidad de escalado determinada. En RSSv1, este OID se usa para establecer parámetros. En el caso de los controladores de miniport compatibles con RSSv2, NDIS realiza automáticamente esta conversión de roles para el controlador y emite los dos OID siguientes para establecer parámetros en su lugar.
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 es un OID normal y se controla igual que el OID_GEN_RECEIVE_SCALE_PARAMETERS OID se controló en RSSv1. Este OID no es visible para los controladores de filtro ligero (LWFs) NDIS antes de NDIS 6.80.
OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, sin embargo, es un OID sincrónico que no puede devolver NDIS_STATUS_PENDING. Este OID debe ejecutarse y completarse en el contexto del procesador que originó el OID. Al igual que OID_GEN_RECEIVE_SCALE_PARAMETERS_V2, tampoco es visible para los LWFs NDIS anteriores a NDIS 6.80. Los LWFs en NDIS 6.80 y versiones posteriores no pueden retrasar este OID ni moverse a otro procesador. Su carga contiene una matriz de acciones simples de "mover ITE", cada una de las cuales contiene un comando para mover un único ITE para una entidad de escalado a una CPU de destino diferente. Los elementos de la matriz pueden hacer referencia a diferentes entidades de escalado (VPorts).
Cada tipo de controlador NDIS, miniporte, filtro y protocolo, tiene puntos de entrada para admitir la interfaz de solicitud OID sincrónica:
| Tipo de controlador NDIS | Controladores de OID sincrónicos | Función para originar OID sincrónicas |
|---|---|---|
| Minipuerto | MiniportSynchronousOidRequest | N/D |
| Filtro | NdisFSynchronousOidRequest | |
| Protocolo | N/D | NdisSynchronousOidRequest |
Transiciones de estado RSS, actualizaciones de ITE y procesadores primarios/predeterminados
Parámetros de dirección
En RSSv2, se usan distintos parámetros para dirigir el tráfico a la CPU correcta en función del estado RSS (habilitado o deshabilitado). Cuando RSS está deshabilitado, solo se usa el procesador principal para dirigir el tráfico. Cuando RSS está habilitado, tanto el procesador predeterminado como todos los ITE se usan para dirigir el tráfico. Estos parámetros de dirección se etiquetan como "activos" o "inactivos ", resumidos en la tabla siguiente:
| Parámetro de dirección | RSS deshabilitado | RSS habilitado |
|---|---|---|
| Procesador principal | Activas | Inactivo |
| Procesador predeterminado | Inactivo | Activas |
| ITE[0..N] | Inactivo | Activas |
Cuando un parámetro de dirección está en estado activo , dirige el tráfico. Desde el momento de una transición de estado RSS que hace que un parámetro esté inactivo, los controladores de miniport deben realizar un seguimiento de los cambios en el parámetro hasta que la transición inversa la active de nuevo. Esto significa que un controlador de minipuerto debe realizar un seguimiento de todas las actualizaciones de las entradas de tabla de procesador e indirecto predeterminadas mientras RSS está deshabilitado para esa entidad de escalado. Cuando RSS está habilitado, el estado de seguimiento actual para el procesador predeterminado y la tabla de direccionamiento indirecto deben surtir efecto.
Por ejemplo, considere el escenario en el que vRSS de software ya está habilitado. En este caso, la tabla de direccionamiento indirecto ya existe en el protocolo de capa superior y la usa activamente el código de propagación de software de la capa superior. Si, durante la habilitación rss de hardware, todas las entradas comienzan a apuntar al procesador principal antes de que las actualizaciones muevan las entradas de la tabla de direccionamiento indirecto se emiten y ejecutan con el hardware, el procesador principal podría experimentar un breve atasco. Si el controlador de miniporte ha realizado un seguimiento del procesador predeterminado y la información de ITE, puede dirigir el tráfico a donde ya se espera en la capa superior.
Tenga en cuenta que, aunque los controladores de miniporte deben realizar un seguimiento de todas las actualizaciones de los parámetros de dirección inactivos, deben aplazar la validación de esos parámetros hasta que el cambio de estado RSS intente activar estos parámetros. Por ejemplo, en el caso de la propagación de software mientras se deshabilita RSS de hardware, los protocolos de capa superior pueden usar cualquier procesador para la propagación (incluido fuera del conjunto RSS del adaptador). Las capas superiores garantizan que, en el momento de la transición de estado RSS, todos los parámetros inactivos sean válidos para el nuevo estado RSS. Sin embargo, el controlador de minipuerto todavía debe validar los parámetros y producir un error en la transición de estado RSS si detecta que los parámetros de dirección inactivos de seguimiento no son válidos.
Estado inicial y actualizaciones de los parámetros de dirección
En la tabla siguiente se describe el estado inicial de la entidad de escalado después de la creación (por ejemplo, después de la creación de VPort), así como cómo se pueden actualizar los parámetros:
| Parámetro | Descripción |
|---|---|
| Procesador principal |
|
| Procesador predeterminado |
|
| Tabla de direccionamiento indirecto |
|
Novedades a ITE y a los procesadores primarios y predeterminados (mediante OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) se invoca desde el procesador al que apunta actualmente la entrada correspondiente. Para un VPort determinado, la capa superior garantiza que no se emita ningún OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID para mover ITE o establecer los procesadores principales o predeterminados en estas circunstancias:
- Mientras OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 está en curso.
- Una vez iniciada la secuencia de eliminación de VPort. Por ejemplo, la capa superior emite el OID de filtro establecido solo después de que se complete el último OID para mover ITE.
Deshabilitación de RSS
Durante la deshabilitación de RSS, el protocolo de nivel superior puede elegir apuntar todas las ITE al procesador principal y, a continuación, emitir el OID para deshabilitar RSS, o bien puede optar por dejar la tabla de direccionamiento indirecto tal como está y deshabilitar RSS. En cualquier caso, el tráfico de recepción debe tener como destino el procesador principal.
RSSv2 mantiene un requisito de RSSv1 que permite que el protocolo de capa superior elimine un VPort sin deshabilitar primero RSS. La capa superior puede establecer el filtro de recepción en VPort en cero, lo que garantiza que no haya flujos de tráfico de recepción a través de VPort y, a continuación, continúe con la eliminación de VPort sin deshabilitar RSS. La capa superior garantiza que no se emitirá ningún OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID durante o después de la eliminación de VPort.
Durante la deshabilitación RSS y la eliminación de VPort, el controlador de miniport debe ocuparse de las operaciones internas pendientes que puedan existir debido a los movimientos de cola anteriores.
Invariables de RSSv2
El protocolo de nivel superior garantiza que no se infringen las invariables importantes antes de realizar funciones de administración o movimientos de ITE. Por ejemplo:
- Antes de reducir el número de colas, la capa superior garantiza que la tabla de direccionamiento indirecto no haga referencia a más procesadores que el nuevo número de colas de un VPort.
- La capa superior no debe solicitar una actualización de tabla de direccionamiento indirecto que infrinja el número de colas configurado actualmente para un VPort. El controlador de miniporte debe aplicar esto y devolver un error.
- Antes de cambiar el número de entradas de tabla de direccionamiento indirecto para adaptadores VMMQ-RESTRICTED, la capa superior garantiza que el contenido de la tabla de direccionamiento indirecto se normalice con la potencia de 2.
Vínculos relacionados
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2
Comentarios
Próximamente: A lo largo de 2024 iremos eliminando gradualmente GitHub Issues como mecanismo de comentarios sobre el contenido y lo sustituiremos por un nuevo sistema de comentarios. Para más información, vea: https://aka.ms/ContentUserFeedback.
Enviar y ver comentarios de