Compartilhar via

Gerenciamento de elementos de anel de rede

  • Artigo

Siga as diretrizes neste tópico para gerenciar suas estruturas de NET_RING e seus elementos durante a transferência de dados de rede. As regras neste tópico descrevem quais membros dos elementos de anel líquido os drivers de cliente podem modificar e quando, dependendo do cenário de caminho de dados, bem como os drivers de cliente de informações gerais devem ter em mente para essas estruturas.

Importante

Os drivers de cliente devem seguir essas direções durante todas as fases de desenvolvimento. Se um driver cliente não aderir a essas direções durante o teste com o Verificador de Driver, o Verificador de Driver relatará uma violação e disparará um bug marcar no dispositivo em teste.

NET_RING

Quando a fila de pacotes pai do NET_RING é iniciada, todos os índices no anel são inicializados como 0.

A tabela a seguir descreve quais membros do anel de rede que os drivers de cliente podem modificar.

Campo O driver do cliente tem permissão para modificar
OSReserved1 No
ElementStride No
Numberofelements No
ElementIndexMask Não
Endindex No
OSReserved0 No
OSReserved2 Não
BeginIndex Sim (Obrigatório)
NextIndex Sim (opcional) Observação: a estrutura nunca lê NextIndex.
Rascunho Sim (opcional) Observação: a estrutura nunca lê Scratch.
Buffer No

Os drivers cliente não devem modificar nenhum membro somente leitura dessa estrutura, nem devem incrementar BeginIndex após EndIndex durante uma chamada para EvtPacketQueueAdvance.

Para obter mais informações sobre a propriedade do índice em anéis líquidos, consulte Introdução aos anéis de rede.

NET_PACKET

Os campos em uma NET_PACKET são sensíveis aos diferentes contextos nos quais o caminho de dados opera. Se o campo Ignorar do pacote está definido e se o driver está recebendo (Rx) ou transmitindo (Tx), o pacote altera o conjunto de regras aplicado ao pacote.

A tabela a seguir fornece instruções para drivers em cada cenário.

Rx ou Tx Ignorar campo é definido por... Observações
Rx Driver do cliente
  • Durante o Rx, os drivers de cliente definem Ignorar , se necessário, e a estrutura a lê. Os drivers cliente não precisam ler Ignorar em nenhum momento durante o Rx.
  • Se um driver cliente definir o campo Ignorar durante rx, então:
    • Os drivers cliente devem gravar no campo Ignorar ao cancelar operações Rx para qualquer pacote que não tenha sido programado com êxito para hardware. Para obter mais informações, consulte Cancelando dados de rede com anéis de rede.
    • Os drivers de cliente não devem associar recursos ao pacote porque eles não serão liberados.
  • Se um driver cliente não definir o campo Ignorar durante rx, então:
    • Os drivers de cliente devem preencher FragmentIndex, FragmentCount e todos os campos em Layout.
    • FragmentIndex deve estar entre BeginIndex inclusive e EndIndex exclusivo no anel de fragmento.
    • FragmentCount não pode exceder a contagem de fragmentos entre BeginIndex inclusive e EndIndex exclusivo no anel de fragmento.
    • Os drivers cliente deverão mover o anel de pacote BeginIndex se moverem o anel de fragmento correspondente BeginIndex.
    • Após a chamada para EvtPacketQueueAdvance, se um driver cliente incrementar o anel de pacote BeginIndex , o driver também deverá incrementar o anel de fragmento BeginIndex após os fragmentos desse pacote. Em outras palavras, o anel de fragmento BeginIndex deve ser movido para o EndIndex dos fragmentos do pacote anterior.
Tx NetAdapterCx
  • Os drivers cliente não devem modificar nenhum campo em nenhum pacote, exceto para Scratch.
  • Os drivers de cliente podem ler o valor de Ignorar , mas nunca devem gravar nele.
  • Se um pacote Tx for ignorado, o driver não deverá ler nenhum campo, exceto possivelmente para Scratch, se necessário.

NET_PACKET_LAYOUT

Durante as operações Rx, o campo Layout do NET_PACKET está sujeito às seguintes regras:

  • Todos os campos, exceto Reserved0 , devem ser inicializados pelo driver cliente.
  • Se Layer2Type estiver definido como NetPacketLayer2TypeEthernet, Layer2HeaderLength deverá ser 14 ou maior.
  • Se Layer2Type estiver definido como NetPacketLayer2TypeNull, Layer2HeaderLength deverá ser definido como 0.
  • Se Layer3Type for um tipo IPv4, Layer3HeaderLength deverá ser 20 ou maior.
  • Se Layer3Type for um tipo IPv6, Layer3HeaderLength deverá ser 40 ou maior.
  • Se Layer4Type estiver definido como Tcp, Layer4HeaderLength deverá ser 40 ou maior.
  • Se Layer4Type estiver definido como Udp, Layer4HeaderLength deverá ser 8 ou maior.
  • Os campos de tipo de camada devem estar dentro do intervalo de enumeração apropriado.

O layout não é usado durante o Tx.

NET_FRAGMENT

NET_FRAGMENT regras de campo dependem se o driver está recebendo ou transmitindo e se os buffers de fragmento são anexados aos pacotes pelo driver ou pela estrutura.

Rx ou Tx Observações
Rx
  • Os drivers de cliente não podem gravar no campo OsReserved_Bounced .
  • Se o driver não estiver sendo anexado, a Capacidade não deverá ser modificada, mas ValidLength e Offset deverão ser modificados.
  • Se o driver estiver sendo anexado, a Capacidade, o ValidLength e o Deslocamento deverão ser modificados.
  • Deslocamento + ValidLength deve ser menor que Capacidade.
Tx
  • Os drivers de cliente não podem modificar nenhum campo, exceto para Scratch.