Receive Side Scaling 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 al ofrecer una distribución dinámica de colas por VPort.
Visió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, lo que 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 al gestionar la solicitud y solo opera en un subconjunto de entradas de la 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 minipuerto puedan establecer las capacidades de RSS adecuadas y controlar 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, consulte Interfaz de solicitud de OID sincrónico en NDIS 6.80.
Terminología de RSSv2
En este artículo se usan los siguientes términos:
| Término | Definición |
|---|---|
| RSSv1 | El mecanismo de escalado en el lado de recepción de primera generación. Usa OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | El mecanismo de escalado del lado receptor de segunda generación, admitido en Windows 10, versión 1803 y posteriores, se describe en este artículo. |
| Entidad de escalado | El propio adaptador de minipuerto en modo RSS nativo o un VPort en modo RSSv2. |
| ITE | Una 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 de RSS nativo. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort y NumberOfIndirectionTableEntriesForDefaultVPort son miembros de la estructura NDIS_NIC_SWITCH_CAPABILITIES. |
| Modo de escalado | La política vmswitch de per-VPort que controla cómo se gestionan 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 | Un objeto de hardware subyacente (cola) que respalda una ITE. Dependiendo del hardware y la tabla de direccionamiento indirecto, la cola de configuración puede soportar varias ITE. 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 | Un procesador que se especifica como el miembro ProcessorAffinity de la estructura NDIS_NIC_SWITCH_VPORT_PARAMETERS durante la creación de un 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á asignada actualmente la ITE. |
| Dirección 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 minipuerto anuncian compatibilidad con RSSv2 estableciendo el miembro CapabilitiesFlags de la estructura 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 (VMQ) 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 solicita que estas VPorts realicen la propagación dinámica. El OID de RSSv1 para la configuración de los parámetros de RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, se utiliza para estos VPorts que todavía están en modo de distribució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 de configuración que se utiliza para configurar los parámetros de la entidad de escalado, como el número de colas, el número de ITE, la activación/desactivación de RSS y las actualizaciones de la clave hash.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES es un OID de método que se utiliza para modificar las entradas de la 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 maneja igual que el OID OID_GEN_RECEIVE_SCALE_PARAMETERS se manejaba en RSSv1. Este OID no es visible para los controladores de filtros ligeros NDIS (LWF) anteriores a 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 LWF 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 una única 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 generar OID sincrónicas |
|---|---|---|
| Minipuerto | MiniportSynchronousOidRequest | N/A |
| Filtro | NdisFSynchronousOidRequest | |
| Protocolo | N/A | 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 | Activo | Inactivo |
| Procesador predeterminado | Inactivo | Activo |
| ITE[0..N] | Inactivo | Activo |
Cuando un parámetro de dirección está en el estado activo, dirige el tráfico. Desde el momento de una transición de estado RSS que hace que un parámetro sea inactivo, los controladores de miniport deben realizar un seguimiento de los cambios en el parámetro hasta que la transición inversa lo active de nuevo. Esto significa que un controlador de minipuerto debe realizar un seguimiento de todas las actualizaciones de las entradas predeterminadas del procesador y de la tabla de direccionamiento indirecto 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, tenga en cuenta el caso en que el software vRSS 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 de RSS de hardware, todas las entradas comienzan a apuntar al procesador principal antes de que las actualizaciones de mover las entradas de la tabla de direccionamiento indirecto se emitan y ejecuten por el hardware, el procesador principal podría experimentar una breve congestión. Si el controlador de minipuerto ha realizado un seguimiento del procesador predeterminado y de la información de ITE, puede dirigir el tráfico hacia donde ya se espera en la capa superior.
Aunque los controladores de minipuerto deben realizar un seguimiento de todas las actualizaciones de los parámetros de direccionamiento inactivos, deben aplazar la validación de esos parámetros hasta que el cambio de estado de RSS intente establecer esos parámetros como activos. 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 de inactivos sean válidos para el nuevo estado RSS. Sin embargo, el controlador de minipuerto debe seguir validando los parámetros y producir un error en la transición de estado de RSS si detecta que cualquier parámetro de direccionamiento inactivo no es válido.
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 direccionamientos indireectos |
|
Las actualizaciones de las ITE y de los procesadores primarios y predeterminados (mediante OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) se invocan desde el procesador al que actualmente apunta 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 se haya iniciado 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 capa 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 as-is 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 de RSS y la eliminación del VPort, el controlador de minipuerto debe gestionar cualquier operación interna pendiente que pueda existir debido a movimientos previos de la cola.
Invariables de RSSv2
El protocolo de nivel superior garantiza que las invariables importantes no se infringen 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 la tabla de indirection que infrinja el número de colas configurado actualmente para un VPort. El controlador de minipuerto debe aplicar esta regla y devolver un error.
- Antes de cambiar el número de entradas de tabla de direccionamiento indirecto para adaptadores de VMMQ-RESTRICTED, la capa superior garantiza que el contenido de la tabla de direccionamiento indirecto se normalice a la potencia de 2.
Vínculos relacionados
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2