Receber dimensionamento lateral versão 2 (RSSv2)
Receive Side Scaling melhora o desempenho do sistema relacionado ao manuseio de dados de rede em sistemas multiprocessadores. As versões 6.80 e posteriores do NDIS suportam a RSS Versão 2 (RSSv2), que amplia o RSS ao oferecer uma distribuição dinâmica e por fila em cada VPort.
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, evitando lentidão durante situações de tráfego intenso. Para atingir este objetivo, o RSSv2 realiza as suas ações em IRQL = DISPATCH_LEVEL, no contexto do processador que está a tratar da solicitação, e opera apenas sobre um subconjunto de entradas da tabela de indireção que apontam para o processador atual. Isso significa que o RSSv2 pode distribuir 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 controladores de miniporta definirem capabilidades RSS adequadas e controlarem 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 artigo usa os seguintes termos:
| Vigência | Definição |
|---|---|
| RSSv1 | A primeira geração recebe mecanismo de dimensionamento lateral. Usa OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | O mecanismo de dimensionamento do lado de recepção de segunda geração suportado no Windows 10, versão 1803 e posteriores, é descrito neste artigo. |
| Entidade de Escalonamento | O próprio miniadaptador em modo RSS nativo ou um VPort em modo RSSv2. |
| ITE | Uma entrada de tabela de indireção (ITE) de uma determinada entidade de escalonamento. O número total de ITEs por VPort não pode exceder NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou NumberOfIndirectionTableEntriesForDefaultVPort no modo VMQ, ou 128 no caso de RSS nativo. NumberOfIndirectionTableEntriesPerNonDefaultPFVPort e NumberOfIndirectionTableEntriesForDefaultVPort são membros da estrutura NDIS_NIC_SWITCH_CAPABILITIES. |
| Modo de dimensionamento | A política vmswitch per-VPort que controla como seus ITEs são manipulados em tempo de execução. Isso pode ser estático (sem movimentos de 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 suporta um ITE. Dependendo do hardware e da tabela de indireção, a fila de configuração pode apoiar vários ITEs. O número total de filas, incluindo uma que é 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 membro ProcessorAffinity da estrutura NDIS_NIC_SWITCH_VPORT_PARAMETERS durante a criação do VPort. Este 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á atualmente mapeado. |
| Processador 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 CapabilitiesFlags membro da estrutura NDIS_RECEIVE_SCALE_CAPABILITIES com o sinalizador NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE. Esta capacidade é necessária para ativar a funcionalidade de balanceamento de carga da CPU do RSSv2, juntamente com o sinalizador NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED, que permite o balanceamento dinâmico do RSSv1 para VPorts (VMQs) que não são padrão.
Observação
Os protocolos de camada superior assumem 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, todos os VPorts habilitados para VMQ permanecerão no modo de dispersão estática, mesmo que esses VPorts sejam solicitados a executar a propagação dinâmica. O OID RSSv1 para configuração de parâmetros RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, é utilizado para estes VPorts que ainda estão no modo de distribuição estática.
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 para OIDs RSSv2, se necessário, para configurar a distribuiçã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 no RSSv2 e não para definir parâmetros RSS.
- OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é um Query e Set OID usados para configurar os parâmetros da entidade de dimensionamento, como o número de filas, o número de ITEs, ativação/desativação de RSS e atualizações de chave de hash.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES é um método OID usado para executar a modificação das entradas da tabela de indirection.
Manipulação de OIDs RSSv2
OID_GEN_RECEIVE_SCALE_PARAMETERS é usado apenas para consultar os parâmetros RSS atuais de uma determinada entidade de escala. No RSSv1, este 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 é tratado da mesma forma que o OID_GEN_RECEIVE_SCALE_PARAMETERS OID foi manipulado no RSSv1. Este OID não é visível para os drivers de filtro de leve peso (LWFs) do NDIS antes da versão 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 está visível para os NDIS LWFs antes do NDIS 6.80. LWFs no NDIS 6.80 e posteriores não têm permissão para atrasar este OID ou mover para outro processador. A carga útil contém uma matriz de ações simples "mover ITE", cada uma das quais inclui um comando para mover um único ITE associado a uma entidade de escalonamento para uma CPU diferente de destino. Os elementos da matriz podem fazer referência a diferentes entidades de dimensionamento (VPorts).
Cada tipo de driver NDIS, miniporta, filtro e protocolo, tem pontos de entrada para suportar a interface de solicitação OID síncrona:
| Tipo de controlador NDIS | Manipulador(es) OID síncrono(s) | Função para originar OIDs síncronos |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/A |
| Filtrar |
|
NdisFSynchronousOidRequest |
| Protocolo | N/A | NdisSynchronousOidRequest |
Transições de estado RSS, atualizações ITE e processadores primários/padrão
Parâmetros da direção
No RSSv2, diferentes parâmetros são usados para direcionar o tráfego para a CPU correta, dependendo do estado RSS (ativado ou desativado). Quando o RSS está desativado, apenas o processador primário é usado para direcionar o tráfego. Quando o RSS está ativado, tanto o processador padrão quanto todos os ITEs são usados para direcionar o tráfego. Estes 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 | Ativo | Inativo |
| Processador padrão | Inativo | Ativo |
| ITE[0..N] | Inativo | Ativo |
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 no processador padrão e nas entradas da tabela de indireção, enquanto o RSS está desativado para essa entidade de dimensionamento. Quando o RSS está habilitado, o estado rastreado atual do processador padrão e da tabela indirection deve entrar em vigor.
Por exemplo, considere o cenário em que o software vRSS já está ativado. Neste caso, a tabela de indirecção já existe no protocolo da camada superior e é usada ativamente pelo código de dispersã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 movam e as entradas da tabela de indireção sejam emitidas e executadas pelo hardware, o processador primário poderá sofrer um curto congestionamento. Se o driver da miniporta tiver rastreado as informações padrão do processador e do ITE, ele poderá direcionar o tráfego para onde ele já é esperado pela camada superior.
Embora os drivers de miniporta devam rastrear todas as atualizações de 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 software se espalhando enquanto o RSS de hardware está desativado, os protocolos de camada superior podem usar qualquer processador para espalhar (inclusive fora do conjunto 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 de rastreados inativos 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 indireção |
|
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 não serão emitidos OIDs do tipo OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES para mover as ITEs ou definir os processadores primários/padrão nessas circunstâncias:
- Enquanto OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 está em andamento.
- Após o início da sequência de exclusão do VPort. Por exemplo, a camada superior emite o OID do filtro definido somente depois que o último OID para mover ITEs é concluído.
Desativação do 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 desativar o RSS, ou pode optar por deixar a tabela de indireção as-is e desativar 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 desativar 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, em seguida, prossiga com a exclusão do VPort sem desativar 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 da 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 violados 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 indirection 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 da tabela de indireção que viole o número de filas atualmente configuradas para um VPort. O driver de miniporta deve aplicar essa regra e retornar uma falha.
- Antes de alterar o número de entradas da tabela de indireção para adaptadores VMMQ-RESTRICTED, a camada superior garante que o conteúdo da tabela de indireção seja normalizado para uma potência de 2.
Ligações úteis
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2