Compartilhar via

Gerenciamento de elementos de anel de rede

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 drivers clientes de elementos do anel de rede podem modificar e quando, dependendo do cenário de caminho de dados, assim como informações gerais que os drivers clientes 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á uma verificação de bugs 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 cliente podem modificar.

Campo O driver cliente tem permissão para modificar
OSReserved1 Não
ElementStride Não
NúmeroDeElementos Não
ElementIndexMask Não
ÍndiceFinal Não
OSReserved0 Não
OSReserved2 Não
BeginIndex Sim (obrigatório)
NextIndex Sim (opcional) Observação: a estrutura nunca lê NextIndex.
Scratch Sim (opcional) Observação: a estrutura nunca lê Scratch.
Buffer Não

Os drivers cliente não devem modificar nenhum membro de somente leitura dessa estrutura, nem devem incrementar BeginIndex além de EndIndex durante uma chamada para EvtPacketQueueAdvance.

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

pacote de rede

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 que é aplicado ao pacote.

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

Rx ou Tx O campo de ignorar é definido por... Anotações
Rx Driver do cliente
  • Durante o Rx, os drivers cliente definem Ignorar, se necessário, e o framework a lê. Os drivers de cliente não precisam ler Ignorar em qualquer 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 Cancelamento de dados de rede com anéis de rede.
    • Os drivers 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 cliente devem preencher FragmentIndex, FragmentCount e todos os campos no Layout.
    • FragmentIndex deve estar entre BeginIndex inclusivo e EndIndex exclusivo no anel de fragmentos.
    • FragmentCount não pode exceder a contagem de fragmentos entre BeginIndex inclusive e EndIndex exclusivo no anel de fragmentos.
    • Os drivers cliente devem 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 se mover 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 escrever 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 do Rx, o campo Layout do NET_PACKET está sujeito às seguintes regras:

  • Todos os campos, exceto Reservado0 , devem ser inicializados pelo driver cliente.
  • Se Layer2Type estiver definido como NetPacketLayer2TypeEthernet, Layer2HeaderLength deverá ter 14 ou mais.
  • Se Layer2Type estiver definido como NetPacketLayer2TypeNull, Layer2HeaderLength deverá ser definido como 0.
  • Se Layer3Type for um tipo IPv4, Layer3HeaderLength deverá ter 20 ou mais.
  • Se Layer3Type for um tipo IPv6, Layer3HeaderLength deverá ter 40 ou mais.
  • Se Layer4Type estiver definido como Tcp, Layer4HeaderLength deverá ter 40 ou mais.
  • Se Layer4Type estiver definido como Udp, Layer4HeaderLength deverá ter 8 ou mais.
  • 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

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

Rx ou Tx Anotações
Rx
  • Drivers de cliente não podem gravar no campo OsReserved_Bounced.
  • Se o driver não estiver conectando, a capacidade não deverá ser modificada, mas ValidLength e Offset deverão ser modificados.
  • Se o driver estiver anexando, a Capacidade, ValidLength e Deslocamento deverão ser modificados.
  • Offset + ValidLength deve ser menor que a Capacidade.
Tx
  • Os drivers cliente não podem modificar nenhum campo, exceto o Scratch.
  • Last updated on