Receber dimensionamento lateral versão 2 (RSSv2)
O Receive Side Scaling melhora o desempenho do sistema relacionado ao tratamento de dados de rede em sistemas multiprocessadores. O NDIS 6.80 e versões posteriores oferecem suporte ao RSS Versão 2 (RSSv2), que estende o RSS oferecendo uma distribuição dinâmica por VPort de filas.
Visão geral
Em comparação com o RSSv1, o RSSv2 reduz o tempo entre a medição da carga da CPU e a atualização da tabela de indireção. Isso evita a lentidão durante situações de alto tráfego. Para fazer isso, o RSSv2 executa suas ações em IRQL = DISPATCH_LEVEL, no contexto do processador de manipulação da solicitação, e opera apenas em um subconjunto de entradas de tabela de indireção que apontam para o processador atual. Isso significa que o RSSv2 pode espalhar dinamicamente filas de recebimento por vários processadores de forma muito mais responsiva do que o RSSv1.
Dois OIDs, OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 e OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, foram introduzidos no RSSv2 para drivers de miniporta para definir recursos RSS adequados e controlar a tabela de indireção, respectivamente. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é um OID regular, enquanto OID_GEN_RSS_SET_INDIRECTION_ENTRIES é um OID síncrono que não pode retornar NDIS_STATUS_PENDING. Para obter mais informações sobre esses OIDs, consulte suas páginas de referência individuais. Para obter mais informações sobre OIDs síncronos, consulte Interface de solicitação OID síncrona no NDIS 6.80.
Terminologia RSSv2
Este tópico usa os seguintes termos:
| Termo | Definição |
|---|---|
| RSSv1 | A primeira geração recebe mecanismo de dimensionamento lateral. Usa OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | O mecanismo de dimensionamento lateral de recebimento de segunda geração com suporte no Windows 10, versão 1803 e posterior, descrito neste tópico. |
| Entidade de dimensionamento | O próprio adaptador de miniporta no modo RSS nativo ou um VPort no modo RSSv2. |
| ITE | Uma entrada de tabela de indireção (ITE) de uma determinada entidade de dimensionamento. O número total de ITEs por VPort não pode exceder NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou NumberOfIndirectionTableEntriesForDefaultVPort no modo VMQ ou 128 no caso RSS nativo. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort e NumberOfIndirectionTableEntriesForDefaultVPort são membros da estrutura NDIS_NIC_SWITCH_CAPABILITIES. |
| Modo de dimensionamento | A política de vmswitch por VPort que controla como seus ITEs são manipulados em tempo de execução. Isso pode ser estático (sem movimentos ITE devido a mudanças de carga) ou dinâmico (expansão e coalescência dependendo da carga de tráfego atual). |
| Fila | Um objeto de hardware subjacente (fila) que faz backup de um ITE. Dependendo do hardware e da tabela de indireção, a fila de configuração pode fazer backup de vários ITEs. O número total de filas, incluindo uma usada pela fila padrão, não pode exceder o limite pré-configurado normalmente definido por um administrador. |
| Processador padrão | Um processador que recebe pacotes para os quais o hash não pode ser calculado. Cada VPort tem um processador padrão. |
| Processador primário | Um processador especificado como o membro ProcessorAffinity da estrutura NDIS_NIC_SWITCH_VPORT_PARAMETERS durante a criação do VPort. Esse processador pode ser atualizado em tempo de execução e especifica para onde o tráfego VMQ é direcionado. |
| CPU de origem | O processador para o qual o ITE está mapeado no momento. |
| CPU de Destino | O processador para o qual o ITE está sendo remapeado (usando RSSv2). |
| CPU do ator | O processador no qual as solicitações RSSv2 estão sendo feitas. |
Anunciando a capacidade RSSv2 em um driver de miniporta
Os drivers de miniporta anunciam o suporte a RSSv2 definindo o membro CapabilitiesFlags da estrutura NDIS_RECEIVE_SCALE_CAPABILITIES com o sinalizador NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE . Esse recurso é necessário para habilitar o recurso de balanceamento de carga de CPU do RSSv2, juntamente com o sinalizador de NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED que habilita o balanceamento dinâmico RSSv1 para VPorts (VMQs) não padrão.
Observação
Os protocolos de camada superior pressupõem que o processador primário do VPort padrão pode ser movido para drivers de miniporta RSSv2.
Se um adaptador de miniporta não anunciar o recurso RSSv2, todas as VPorts habilitadas para VMQ permanecerão no modo de propagação estática, mesmo que essas VPorts sejam solicitadas a executar a propagação dinâmica. O RSSv1 OID para configuração de parâmetros RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, é usado para esses VPorts que ainda estão no modo de propagação estático.
Os drivers de miniporta só precisam implementar um mecanismo de controle RSS - RSSv1 ou RSSv2. Se o driver anunciar suporte a RSSv2, o NDIS converterá OIDs RSSv1 em OIDs RSSv2, se necessário, para configurar a propagação por VPort. O driver de miniporta deve suportar os dois novos OIDs e modificar o comportamento do RSSv1 OID_GEN_RECEIVE_SCALE_PARAMETERS OID da seguinte maneira:
- OID_GEN_RECEIVE_SCALE_PARAMETERS é usado apenas para solicitações de consulta em RSSv2 e não para definir parâmetros RSS.
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é uma Consulta e um OID de Conjunto usados para configurar os parâmetros da entidade de dimensionamento, como o número de filas, o número de ITEs, a ativação/desativação de RSS e as atualizações de chave de hash.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES é um método OID usado para executar a modificação de entradas de tabela de indirecional.
Manipulando OIDs RSSv2
OID_GEN_RECEIVE_SCALE_PARAMETERS é usado apenas para consultar os parâmetros RSS atuais de uma determinada entidade de dimensionamento. No RSSv1, esse OID é usado para definir parâmetros. Para drivers de miniporta compatíveis com RSSv2, o NDIS executa automaticamente essa conversão de função para o driver e emite os dois OIDs a seguir para definir parâmetros.
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é um OID regular e é manipulado da mesma forma que o OID_GEN_RECEIVE_SCALE_PARAMETERS OID foi manipulado no RSSv1. Esse OID não é visível para drivers de filtro de peso leve (LWFs) do NDIS anteriores ao NDIS 6.80.
OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, no entanto, é um OID síncrono que não pode retornar NDIS_STATUS_PENDING. Este OID deve ser executado e concluído no contexto do processador que originou o OID. Como OID_GEN_RECEIVE_SCALE_PARAMETERS_V2, também não é visível para LWFs NDIS antes do NDIS 6.80. LWFs no NDIS 6.80 e posterior não têm permissão para atrasar esse OID ou mover para outro processador. Sua carga útil contém uma matriz de ações simples de "mover ITE", cada uma das quais contém um comando para mover um único ITE para uma entidade de dimensionamento para uma CPU de destino diferente. Os elementos da matriz podem fazer referência a diferentes entidades de dimensionamento (VPorts).
Cada tipo de driver NDIS, miniporta, filtro e protocolo, têm pontos de entrada para suportar a interface de solicitação OID síncrona:
| Tipo de driver NDIS | Manipulador(es) OID síncrono | Função para originar OIDs síncronos |
|---|---|---|
| Miniporta | MiniportSynchronousOidRequest | N/D |
| Filter | NdisFSynchronousOidRequest | |
| Protocolo | N/D | NdisSynchronousOidRequest |
Transições de estado RSS, atualizações ITE e processadores primários/padrão
Parâmetros de direção
No RSSv2, diferentes parâmetros são usados para direcionar o tráfego para a CPU correta, dependendo do estado RSS (habilitado ou desabilitado). Quando o RSS está desabilitado, somente o processador primário é usado para direcionar o tráfego. Quando o RSS está habilitado, o processador padrão e todos os ITEs são usados para direcionar o tráfego. Esses parâmetros de direção são rotulados como "ativos" ou "inativos", resumidos na tabela a seguir:
| Parâmetro de direção | RSS desativado | RSS ativado |
|---|---|---|
| Processador primário | Ativa | Inativos |
| Processador padrão | Inativos | Ativa |
| ITE[0..N] | Inativos | Ativa |
Quando um parâmetro de direção está no estado ativo , ele direciona o tráfego. A partir do momento de uma transição de estado RSS que torna um parâmetro inativo, os drivers de miniporta devem rastrear as alterações no parâmetro até que a transição inversa o ative novamente. Isso significa que um driver de miniporta precisa rastrear todas as atualizações para o processador padrão e entradas de tabela de indireção enquanto o RSS está desabilitado para essa entidade de dimensionamento. Quando o RSS está habilitado, o estado rastreado atual para o processador padrão e a tabela de indirecionamento devem entrar em vigor.
Por exemplo, considere o cenário quando o vRSS de software já estiver habilitado. Nesse caso, a tabela de indireção já existe no protocolo da camada superior e é usada ativamente pelo código de propagação de software da camada superior. Se, durante a ativação do RSS de hardware, todas as entradas começarem a apontar para o processador primário antes que as atualizações para mover as entradas da tabela de indireção sejam emitidas e executadas pelo hardware, o processador primário poderá enfrentar um pequeno congestionamento. Se o driver de miniporta tiver rastreado as informações padrão do processador e do ITE, ele poderá direcionar o tráfego para onde já é esperado pela camada superior.
Observe que, embora os drivers de miniporta devam rastrear todas as atualizações dos parâmetros de direção inativos, eles devem adiar a validação desses parâmetros até que a alteração de estado RSS tente tornar esses parâmetros ativos. Por exemplo, no caso de propagação de software enquanto o RSS de hardware está desativado, os protocolos de camada superior podem usar qualquer processador para se espalhar (inclusive fora do conjunto de RSS do adaptador). As camadas superiores garantem que, no momento da transição de estado RSS, todos os parâmetros inativos sejam válidos para o novo estado RSS. No entanto, o driver de miniporta ainda deve validar os parâmetros e falhar na transição de estado RSS se descobrir que quaisquer parâmetros de direção inativos rastreados são inválidos.
Estado inicial e atualizações dos parâmetros de direção
A tabela a seguir descreve o estado inicial da entidade de dimensionamento após a criação (por exemplo, após a criação do VPort), bem como como os parâmetros podem ser atualizados:
| Parâmetro | Descrição |
|---|---|
| Processador primário |
|
| Processador padrão | |
| Tabela de indirecionamento |
|
As atualizações para ITEs e os processadores primários/padrão (usando OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) são invocadas a partir do processador para o qual a entrada correspondente aponta atualmente. Para um determinado VPort, a camada superior garante que nenhum OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs para mover ITEs ou definir os processadores primários/padrão será emitido nestas circunstâncias:
- Enquanto OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 está em andamento.
- Após a sequência de exclusão VPort é iniciada. Por exemplo, a camada superior emite o OID do filtro set somente depois que o último OID para mover ITEs é concluído.
Desativação RSS
Durante a desativação do RSS, o protocolo de camada superior pode optar por apontar todos os ITEs para o processador primário e, em seguida, emitir o OID para desabilitar o RSS ou pode optar por deixar a tabela de indireção como está e desabilitar o RSS. Em ambos os casos, o tráfego de recebimento deve ter como alvo o processador primário.
O RSSv2 mantém um requisito do RSSv1 que permite que o protocolo de camada superior exclua um VPort sem primeiro desabilitar o RSS. A camada superior pode definir o filtro de recebimento no VPort como zero, garantindo assim que nenhum tráfego de recebimento flua através do VPort e, em seguida, prossiga com a exclusão do VPort sem desabilitar o RSS. A camada superior garante que nenhum OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OIDs será emitido durante ou após a exclusão do VPort.
Durante a desativação do RSS e a exclusão do VPort, o driver de miniporta deve cuidar de quaisquer operações internas pendentes que possam existir devido a movimentações de fila anteriores.
Invariantes RSSv2
O protocolo de camada superior garante que invariantes importantes não sejam violadas antes de executar funções de gerenciamento ou movimentos ITE. Por exemplo:
- Antes de reduzir o número de filas, a camada superior garante que a tabela de indirecionamento não faça referência a mais processadores do que o novo número de filas para um VPort.
- A camada superior não deve solicitar uma atualização de tabela de indirecionamento que viole o número atualmente configurado de filas para um VPort. O driver de miniporta deve impor isso e retornar uma falha.
- Antes de alterar o número de entradas de tabela de indireção para adaptadores VMMQ-RESTRICTED , a camada superior garante que o conteúdo da tabela de indireção seja normalizado para a potência de 2.
Links relacionados
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2
Comentários
Em breve: Ao longo de 2024, eliminaremos os problemas do GitHub como o mecanismo de comentários para conteúdo e o substituiremos por um novo sistema de comentários. Para obter mais informações, consulte https://aka.ms/ContentUserFeedback.
Enviar e exibir comentários de