Compartir a través de

Administración de elementos de anillo de red

Siga las instrucciones de este tema para administrar las estructuras de NET_RING y sus elementos durante la transferencia de datos de red. Las reglas de este tema describen qué miembros de los elementos del controlador cliente del anillo de red pueden modificar y cuándo, en función del escenario de la trayectoria de datos, así como la información general que los controladores cliente deben tener en cuenta para estas estructuras.

Importante

Los controladores de cliente deben cumplir estas instrucciones durante todas las fases de desarrollo. Si un controlador cliente no cumple estas instrucciones mientras se prueba con el comprobador de controladores, el comprobador de controladores notifica una infracción y desencadena una comprobación de errores en el dispositivo en prueba.

NET_RING

Cuando se inicia la cola de paquetes primarios del NET_RING, todos los índices del anillo se inicializan en 0.

En la tabla siguiente se describen los miembros de la red que los controladores de clientes pueden modificar.

Campo Se permite modificar el controlador de cliente
OSReserved1 No
ElementStride No
NúmeroDeElementos No
ElementIndexMask No
ÍndiceFinal No
OSReserved0 No
OSReserved2 No
BeginIndex Sí (obligatorio)
NextIndex Sí (opcional) Nota: El marco nunca lee NextIndex.
Scratch Sí (opcional) Nota: El marco nunca lee Scratch.
Memoria intermedia No

Los controladores de cliente no deben modificar ningún miembro de solo lectura de esta estructura, ni tampoco deben incrementar BeginIndex más allá de EndIndex durante una llamada a EvtPacketQueueAdvance.

Para obtener más información sobre la propiedad del índice en anillos netos, vea Introducción a los anillos netos.

NET_PACKET

Los campos de un NET_PACKET son sensibles a los distintos contextos en los que funciona la ruta de acceso de datos. Si se establece el campo Omitir del paquete, y si el controlador está recibiendo (Rx) o transmitiendo (Tx) el paquete, el conjunto de reglas que se aplica al paquete cambia.

En la tabla siguiente se proporcionan instrucciones para los controladores en cada escenario.

Rx o Tx El campo ignorar es configurado por... Notas
Rx Controlador de cliente
  • Durante Rx, los controladores de cliente establecen Omitir si es necesario y el entorno lo lee. Los controladores cliente no necesitan leer Ignore en ningún momento durante Rx.
  • Si un controlador cliente establece el campo Omitir durante Rx, haga lo siguiente:
    • Los controladores de clientes deben escribir en el campo Omitir al cancelar las operaciones de Rx de cualquier paquete que no se haya programado exitosamente en el hardware. Para obtener más información, consulte Cancelación de datos de red con anillos netos.
    • Los controladores de cliente no deben asociar recursos al paquete porque no se liberarán.
  • Si un controlador de cliente no establece el campo Omitir durante Rx, haga lo siguiente:
    • Los controladores del cliente deben rellenar FragmentIndex, FragmentCount y todos los campos en Layout.
    • FragmentIndex debe estar entre el BeginIndex, inclusivo, y el EndIndex, exclusivo, en el anillo de fragmentos.
    • FragmentCount no puede superar la cantidad de fragmentos entre BeginIndex incluido y EndIndex excluido en el anillo de fragmentos.
    • Los controladores de cliente deben mover el anillo de paquetes BeginIndex si mueven el anillo de fragmentos correspondiente BeginIndex.
    • Después de la llamada a EvtPacketQueueAdvance, si un controlador cliente incrementa el anillo de paquetes BeginIndex , el controlador también debe incrementar el anillo de fragmentos BeginIndex más allá de los fragmentos de ese paquete. En otras palabras, el anillo de fragmento BeginIndex debe moverse a EndIndex de los fragmentos del paquete anterior.
Tx NetAdapterCx
  • Los controladores de cliente no deben modificar ningún campo en ningún paquete excepto scratch.
  • Los controladores de cliente pueden leer el valor de Ignore pero nunca deben escribir en él.
  • Si se ignora un paquete Tx, el controlador no debe leer ningún campo excepto posiblemente Scratch, si es necesario.

Diseño de Paquete NET

Durante las operaciones rx, el campo Diseño del NET_PACKET está sujeto a las siguientes reglas:

  • El controlador cliente debe inicializar todos los campos excepto Reserved0 .
  • Si Layer2Type está establecido en NetPacketLayer2TypeEthernet, Layer2HeaderLength debe ser 14 o superior.
  • Si Layer2Type está establecido en NetPacketLayer2TypeNull, Layer2HeaderLength debe establecerse en 0.
  • Si Layer3Type es un tipo IPv4, Layer3HeaderLength debe ser 20 o superior.
  • Si Layer3Type es un tipo IPv6, Layer3HeaderLength debe ser 40 o superior.
  • Si Layer4Type está establecido en Tcp, Layer4HeaderLength debe ser 40 o superior.
  • Si Layer4Type está establecido en Udp, Layer4HeaderLength debe ser 8 o superior.
  • Los campos de tipo de capa deben estar dentro del intervalo de enumeración adecuado.

El diseño no se usa durante tx.

Fragmento de la Red

NET_FRAGMENT reglas de campo dependen de si el controlador está recibiendo o transmitiendo, y de si los búferes de fragmentos están conectados a los paquetes por el controlador o por el marco.

Rx o Tx Notas
Rx
  • Los controladores de cliente no pueden escribir en el campo OsReserved_Bounced .
  • Si el controlador no está conectado, la capacidad no debe modificarse, pero se debe modificar ValidLength y Offset .
  • Si el controlador está conectado, debe modificarse Capacity, ValidLength y Offset .
  • Compensar + ValidLength debe ser menor que Capacity.
Tx
  • Los controladores de cliente no pueden modificar ningún campo excepto para Scratch.
  • Last updated on