Partilhar via


OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Advertência

Algumas informações neste tópico referem-se ao produto pré-lançado, que pode ser substancialmente modificado antes de ser lançado comercialmente. A Microsoft não oferece garantias, expressas ou implícitas, em relação às informações fornecidas aqui.

RSSv2 é pré-visualização apenas no Windows 10, versão 1809.

O OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES OID é enviado para drivers de miniporta compatíveis com RSSv2para executar movimentos de entradas individuais da tabela de indireção. Este OID é um OID síncrono, o que significa que não pode retornar NDIS_STATUS_PENDING. É emitido apenas como um pedido de Método, no IRQL == DISPATCH_LEVEL.

Esta chamada usa o ponto de entrada XxxSynchronousOidRequest, onde Xxx é Miniport ou Filter dependendo do tipo de driver que recebe a solicitação. Esse ponto de entrada causa uma verificação de bug do sistema se ele vê um status de retorno NDIS_STATUS_PENDING.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES usa a estrutura NDIS_RSS_SET_INDIRECTION_ENTRIES para instruir um adaptador de miniporta a executar de forma síncrona um conjunto de ações, onde cada ação move uma única entrada da tabela de indireção RSS de um VPort especificado para uma CPU especificada de destino.

Comentários

Este OID deve ser executado e concluído no contexto do processador que o emitiu. Os drivers de miniporta devem executar totalmente esse OID ao retornar NDIS_STATUS_SUCCESS para a camada superior. Isso significa que o driver da miniporta deve estar preparado para receber solicitações OID back-to-back para mover vários ITEs em um novo processador imediatamente após a primeira movimentação terminar com NDIS_STATUS_SUCCESS.

Dica

Executar totalmente este OID significa que o driver de miniporta deve estar pronto para tentar com êxito outra ação para mover um ITE. Ele não prescreve onde o tráfego de recebimento em voo é indicado logo após a movimentação da fila, que pode estar na CPU de origem ou na CPU de destino.

Os protocolos de camada superior emitem OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES para definir ITEs e/ou os parâmetros primários e padrão do processador para apontar para processadores diferentes.

Este OID pode ser emitido para ativo ou inativo parâmetros de direção de tráfego. Para obter mais informações sobre parâmetros de direção, consulte Receive side scaling version 2 (RSSv2). Para parâmetros/ITEs no estado inativo, o driver de miniporta deve validar e armazenar em cache o processador de destino até a próxima alteração de estado RSS relevante (ativação ou desativação). Nesse ponto, os números do processador em cache tornam-se ativo e são usados para direcionar o tráfego. As atualizações de parâmetros de ativos (que também devem ser validados) devem ser tomadas imediatamente em vigor para direcionar o tráfego.

OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES deve ser emitido para um adaptador de miniporta com o sinalizador de NDIS_OID_REQUEST_FLAGS_VPORT_ID_VALID limpo. Isso ocorre devido à possibilidade de VPorts diferentes serem referenciados por diferentes elementos na matriz.

Este OID é invocado apenas no IRQL == DISPATCH_LEVEL.

Os drivers de miniporta devem estar preparados para lidar com pelo menos tantas ações de movimentação de entrada de tabela de indireção quanto anunciam na estrutura NDIS_NIC_SWITCH_CAPABILITIES. Isso é definido no NumberOfIndirectionTableEntriesPerNonDefaultPFVPort ou NumberOfIndirectionTableEntriesForDefaultVPort membro dessa estrutura ou 128 no modo RSS nativo.

Os drivers de miniporta devem tentar executar o maior número possível de entradas e atualizar o EntryStatus membro de cada NDIS_RSS_SET_INDIRECTION_ENTRY com o resultado da operação.

Manipulador OID para OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES

Espera-se que o manipulador OID para OID_GEN_RSS_SET_INDIRECTION_TABLE_ENTRIES se comporte da seguinte maneira:

  • Um retorno de NDIS_STATUS_PENDING não é permitido devido ao tipo de chamada síncrona do OID.
  • Finalize todas as movimentações ITE de entrada destinadas à CPU atual (iniciadas anteriormente em processadores remotos).
  • É altamente recomendável que os drivers de miniporta executem um passo de validação de parâmetro completo. Se não for possível, execute uma a uma validação e execução de entradas de matriz. Os drivers de miniporta devem verificar especificamente se todos os objetos referenciados são válidos:
    • Não é permitido retornar NDIS_STATUS_PENDING no campo EntryStatus do para um ITE.
    • O adaptador de miniporta existe e está em bom estado. Caso contrário, defina o campo EntryStatus da entrada como NDIS_STATUS_ADAPTER_NOT_FOUND, NDIS_STATUS_ADAPTER_NOT_READY, etc.
    • Cada VPort existe e está em bom estado. Caso contrário, defina o campo EntryStatus da entrada como NDIS_STATUS_INVALID_PORT, NDIS_STATUS_INVALID_PORT_STATE, etc.
    • Cada índice de entrada da tabela indirection está dentro do intervalo configurado. Esse intervalo é 0xFFFF ou está no intervalo [0...NumberOfIndirectionTableEntries - 1] definido pelo OID_GEN_RECEIVE_SCALE_PARAMETERS_V2 OID. Os índices de entrada 0xFFFF e 0xFFFE têm significados especiais: 0xFFFF define o processador padrão, enquanto 0xFFFE define o processador primário. Em caso de erro, o manipulador define o campo EntryStatus da entrada como NDIS_STATUS_INVALID_PARAMETER.
    • A camada superior e o driver de miniporta esperam que o ITE aponte para o processador atual (CPU do ator) antes da mudança. Por outras palavras, o ITE não pode ser redirecionado remotamente. Se isso não for verdade, defina o campo EntryStatus da entrada como NDIS_STATUS_NOT_ACCEPTED.
    • Todos os processadores de destino são válidos e fazem parte do conjunto RSS do adaptador de miniporta. Caso contrário, defina o campo EntryStatus da entrada como NDIS_STATUS_INVALID_DATA.
  • Subsequentemente ou como parte do passo de validação de parâmetros, valide a situação do recurso. Valide se o número de filas a serem usadas após uma movimentação de lote completo (evacuação) não exceda o NumberOfQueues definido na estrutura NDIS_RECEIVE_SCALE_PARAMETERS_V2 durante uma solicitação de OID_GEN_RECEIVE_SCALE_PARAMETERS_V2. Caso contrário, NDIS_STATUS_NO_QUEUES é retornado. NDIS_STATUS_NO_QUEUES deve ser usado para todas as condições que representam uma violação do número configurado de filas. NDIS_STATUS_RESOURCES só deve ser usado para designar condições transitórias de falta de memória.
  • Como parte das verificações de recursos, para cada entidade de dimensionamento (por exemplo, VPort), o driver de miniporta deve lidar com uma condição quando todos os ITEs que apontam para a CPU atual são movidos para longe dela.

Se todas as verificações acima passarem, o driver de miniporta deve ser capaz de aplicar incondicionalmente a nova configuração e deve definir o campo EntryStatus de cada entrada como NDIS_STATUS_SUCCESS.

Em geral, o manipulador para este OID deve ser muito leve. Ele não deve chamar NDIS ou serviços do sistema operacional a não ser para possíveis operações de sincronização, como spinlocks e NdisMConfigMSIXTableEntry.

O driver de miniporta não deve chamar NDIS para indicar status ou eventos PnP.

O driver de miniporta também não deve usar receber / transmitir indicações completas no contexto deste manipulador OID, pois isso leva à recursão. A camada superior pode invocar este OID a partir do contexto de receber ou transmitir indicações.

Movendo todas as entradas da tabela indirection

Os drivers de miniporta devem reconhecer e lidar com uma solicitação especial que mova todas as entradas da tabela de indireção para longe da CPU atual. Como o RSSv2 opera com movimentos ITE individuais, os drivers de miniporta devem garantir a atomicidade da operação geral. Se encontrar um erro no meio de um lote durante o processamento da matriz correspondente de comandos move, o driver de miniporta deve reverter todos os comandos que já foram executados e marcar todos os comandos como "falhou" no campo EntryStatus por comando. O protocolo de camada superior sempre espera que o lote "mover todos os ITEs" contenha todos os comandos marcados como "bem-sucedidos" ou todos os comandos marcados como "falha", e assumirá que o tráfego obedece ao estado resultante (antes ou depois da movimentação). Se a camada superior vir apenas algumas entradas marcadas como "falhou", verificará o sistema com bugs e apontará para o driver de miniporta como a causa.

Para ajudar o driver de miniporta a lidar com o comando "move all ITEs" e evitar deadlocks, os protocolos de camada superior agrupam comandos move no lote em pares de campos SwitchId + VPortId, de modo que:

  • Os comandos que a camada superior deseja que sejam executados juntos, como parte do comando "mover tudo", para o mesmo VPort são colocados consecutivamente no lote geral.
  • O driver de miniporta não deve tentar executar o lote de comando geral, que pode ter como alvo VPorts diferentes, de forma "mover tudo". Apenas o grupo de comandos que visam o mesmo VPort (marcado com o mesmo par SwitchId + VPortId) precisa ser executado de acordo com a semântica "mover tudo".
  • Quando a camada superior não se preocupa com a semântica "mover tudo", ela pode intercalar comandos para o mesmo VPort com comandos para VPort(s) diferentes. Nesse caso, se o segundo grupo de comandos para o mesmo VPort não puder ser executado devido a uma violação de "número de filas", o driver de miniporta marcará esse grupo com o código de status correspondente (NDIS_STATUS_NO_QUEUES) e a camada superior assumirá a responsabilidade pela recuperação.

Por exemplo, se o protocolo de camada superior intercala uma série de comandos como este:

  • VPort=1 ITE[0,1]
  • VPort=2 ITE[0]
  • VPort=1 ITE[2]

O driver de miniporta não precisa tentar executar atomicamente todos os quatro comandos move ou todos os três comandos move para VPort=1 (ITE[0,1,2]). Ele só precisa executar o grupo VPort=1 ITE[0,1] de forma "mover tudo", depois o grupo VPort=2 ITE[0] e, em seguida, VPort=1 ITE[2]. Todos os três grupos de comando podem ter um resultado diferente. Por exemplo, os grupos para VPort=1 ITE[0,1] e VPort=2 ITE[0] podem ser bem-sucedidos e o grupo VPort=1 ITE[2] pode falhar. O resultado deve ser refletido no correspondente EntryStatus membro de cada estrutura de comando. Desta forma, o driver da miniporta não precisa tomar precauções para a execução segura do lote geral (por exemplo, bloquear todo o adaptador). Somente os comandos que visam um VPort específico precisam ser serializados, o bloqueio por VPort de grão mais fino pode ser usado e certos deadlocks são evitados.

Observação

Todo o grupo de entradas de comando deve ser marcado com o mesmo status de entrada.

Condições de erro e códigos de status

Este OID retorna os seguintes códigos de status quando ocorre um erro:

Código de status Condição de erro
NDIS_STATUS_INVALID_LENGTH O OID estava malformado.
NDIS_STATUS_INVALID_PARAMETER Outros campos, no cabeçalho ou no próprio OID (mas não em entradas de comando individuais) contêm valores inválidos.

Requerimentos

Versão: Windows 10, versão 1709 de cabeçalho : Ntddndis.h (incluir Ndis.h)

Ver também