RSS versão 2 (RSSv2)
O Receive Side Scaling aprimora 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 ao oferecer uma distribuição dinâmica de filas por 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 alto tráfego. Para fazer isso, o RSSv2 executa suas ações em IRQL = DISPATCH_LEVEL, no contexto do processador de tratamento 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 em vários processadores de forma muito mais responsiva do que o RSSv1.
No RSSv2, foram introduzidos dois OIDs, OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 e OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES, para que os drivers de miniporta definam as capacidades de RSS adequadas e controlem a tabela de indireção de forma respectiva. OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é uma OID regular, enquanto OID_GEN_RSS_SET_INDIRECTION_ENTRIES é uma OID síncrona 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:
| Prazo | Definição |
|---|---|
| RSSv1 | O mecanismo de recebimento de escala lateral de primeira geração. Utiliza OID_GEN_RECEIVE_SCALE_PARAMETERS. |
| RSSv2 | O mecanismo de recebimento de escala lateral de segunda geração compatível com Windows 10, versão 1803 e posteriores, descrito neste artigo. |
| Entidade de dimensionamento | O adaptador de miniporta em si 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 do NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou o 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 por VPort que controla como seus ITEs são tratados em tempo de execução. Isso pode ser estático (sem movimentações de ITE devido a alterações de carga) ou dinâmico (expansão e agrupamento dependendo da carga de tráfego atual). |
| Fila | Um objeto de hardware subjacente (fila) que apoia um ITE. Dependendo do hardware e da tabela de indireção, a fila de configuração pode suportar 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 ProcessorAffinity membro da estrutura de NDIS_NIC_SWITCH_VPORT_PARAMETERS durante a criação do VPort. Esse processador pode ser atualizado em runtime e especifica para onde o tráfego de VMQ é direcionado. |
| CPU de origem | O processador ao qual o ITE está atualmente mapeado. |
| CPU de Destino | O processador para o qual o ITE está sendo mapeado novamente (usando RSSv2). |
| CPU do Ator | O processador no qual as solicitações RSSv2 estão sendo feitas. |
Anunciando a funcionalidade RSSv2 em um driver de miniporta
Os drivers de miniporta anunciam o suporte para o RSSv2 definindo o membro CapabilitiesFlags da estrutura NDIS_RECEIVE_SCALE_CAPABILITIES com o sinalizador NDIS_RSS_CAPS_SUPPORTS_INDEPENDENT_ENTRY_MOVE. Esta funcionalidade é necessária para habilitar o recurso de balanceamento de carga da CPU do RSSv2, juntamente com o sinalizador NDIS_RECEIVE_FILTER_DYNAMIC_PROCESSOR_AFFINITY_CHANGE_SUPPORTED, que possibilita o balanceamento dinâmico do RSSv1 para VPorts não padrão (VMQs).
Nota
Os protocolos de camada superior pressupõem que o processador primário do VPort padrão pode ser movido para drivers de miniporto RSSv2.
Se um adaptador de miniporto não anunciar a funcionalidade RSSv2, todos os VPorts habilitados para VMQ permanecerão no modo de distribuição estático mesmo se esses VPorts forem solicitados a executar a disseminação dinâmica. O OID RSSv1 para a configuração dos parâmetros RSS, OID_GEN_RECEIVE_SCALE_PARAMETERS, é utilizado para esses VPorts que ainda estão no modo de distribuição estática.
Os drivers de miniporto só precisam implementar um mecanismo de controle RSS - RSSv1 ou RSSv2. Se o driver anunciar o suporte ao RSSv2, o NDIS converterá OIDs RSSv1 em OIDs RSSv2, se necessário, para configurar a disseminação por VPort. O driver de miniporta deve dar suporte para os dois novos OIDs e modificar o comportamento do OID OID_GEN_RECEIVE_SCALE_PARAMETERS do RSSv1 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 OID de consulta e de definição utilizado para configurar os parâmetros da entidade de dimensionamento, como o número de filas, o número de ITEs, a habilitação/ do RSS e as atualizações de chave de hash.
- OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES é um OID de método utilizado para realizar modificações nas entradas da tabela de indireção.
Tratamento de OIDs do RSSv2
OID_GEN_RECEIVE_SCALE_PARAMETERS é utilizado apenas para consultar os parâmetros de RSS atuais de uma determinada entidade de dimensionamento. No RSSv1, essa OID é usada para definir parâmetros. No caso de drivers de miniporta compatíveis com RSSv2, o NDIS executa essa conversão de função para o driver de forma automática e emite os dois OIDs a seguir para definir parâmetros em vez disso.
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 é um OID Regular e é tratado da mesma forma que o OID_GEN_RECEIVE_SCALE_PARAMETERS OID foi tratado no RSSv1. Esse OID não é visível para drivers de filtro leve (LWFs) do NDIS em versões 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. Essa OID deve ser executada e concluída no contexto do processador que originou o OID. Assim como OID_GEN_RECEIVE_SCALE_PARAMETERS_V2, ele também não é visível para os LWFs de NDIS antes do NDIS 6.80. LWFs no NDIS 6.80 e posteriores não estão autorizados a atrasar esse OID nem mover para outro processador. Sua payload contém uma matriz de ações simples de "mover ITE", cada uma das quais inclui um comando para mover um único ITE de uma entidade de escalonamento para uma CPU alvo diferente. Elementos da matriz podem fazer referência a diferentes entidades de escalonamento (VPorts).
Cada tipo de driver, miniporto, filtro e protocolo do NDIS tem pontos de entrada para dar suporte à interface de solicitação OID síncrona:
| Tipo de controlador NDIS | Manipuladores OID síncronos | Função para originar OIDs síncronos |
|---|---|---|
| Miniport | MiniportSynchronousOidRequest | N/A |
| Filtro | NdisFSynchronousOidRequest | |
| Protocolo | N/A | NdisSynchronousOidRequest |
Transições de estado do RSS, atualizações do ITE e processadores primários/padrão
Parâmetros de direção
No RSSv2, parâmetros diferentes 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 desabilitado | RSS habilitado |
|---|---|---|
| Processador primário | Ativo | Inativo |
| Processador padrão | Inativo | Ativo |
| ITE[0..N] | Inativo | Ativo |
Quando um parâmetro de direcionamento 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 miniport devem acompanhar as alterações no parâmetro até que a transição inversa o ative novamente. Isto significa que, enquanto o RSS estiver desabilitado para essa entidade de dimensionamento um driver de miniporta precisa monitorar todas as atualizações nas entradas da tabela de indireção e no processador padrão. Quando o RSS está habilitado, o estado monitorado atual para o processador padrão e a tabela de indireção deve entrar em vigor.
Por exemplo, considere o cenário em que o software vRSS já está habilitado. Nesse caso, a tabela de indireção já existe no protocolo de camada superior e é usada ativamente pelo código de difusão de software da camada superior. Se, durante a habilitaçã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 monitorado as informações padrão do processador e do ITE, ele pode direcionar o tráfego para onde é esperado pela camada superior.
Embora os drivers de miniporta precisem monitorar todas as atualizações para parâmetros de direcionamento inativos, eles deveriam adiar a validação desses parâmetros até que a alteração de estado do RSS tente tornar esses parâmetros ativos. Por exemplo, no caso da propagação de software enquanto o RSS de hardware está desabilitado, os protocolos de camada superior podem usar qualquer processador para propagação (inclusive fora do conjunto RSS do adaptador). As camadas superiores garantem que, no momento da transição de estado do RSS, todos os parâmetros inativos de sejam válidos para o novo estado RSS. No entanto, o driver de miniporta ainda deveria validar os parâmetros e não aceitar a transição de estado do RSS, se descobrir que qualquer parâmetro de direcionamento inativo é inválido.
Estado inicial e atualizações para 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 (utilizando OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES) são invocadas do processador para o qual a entrada correspondente aponta atualmente. Para um determinado VPort, a camada superior garante que, nestas circunstâncias, nenhum OID OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES para mover ITEs ou definir os processadores primários/padrão, será emitido :
- Enquanto OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 está em andamento.
- Depois que a sequência de exclusão do VPort for iniciada. Por exemplo, a camada superior emite o OID de definir filtro somente após que o último OID para mover ITEs tiver concluído.
Desabilitação do RSS
Durante a desabilitaçã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 as-is e desabilitar o RSS. Em ambos os casos, o tráfego de recebimento deve ser direcionado ao 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 que nenhum tráfego de recebimento flua por meio do VPort e, em seguida, prossiga com a exclusão do VPort sem desabilitar o RSS. A camada superior garante que nenhum OID OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES 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 deveria se encarregar de todas as tarefas internas pendentes que possam estar presentes devido a movimentações de fila anteriores.
Invariantes RSSv2
O protocolo de camada superior garante que invariáveis importantes não sejam violados antes de executar funções de gerenciamento ou movimentações de ITE. Por exemplo:
- Antes de reduzir o número de filas, a camada superior garante que a tabela de indireção 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 indireção que viole o número atualmente configurado de filas para um VPort. O driver de miniporta deve impor essa regra e retornar uma falha.
- Antes de alterar o número de entradas na tabela de indireção para adaptadores de VMMQ-RESTRICTED, a camada superior garante que o conteúdo da tabela de indireção seja normalizado para uma potência de 2.
Links relacionados
OID_GEN_RECEIVE_SCALE_PARAMETERS_V2