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 controladores de cliente de elementos de anillo de red pueden modificar y cuándo, en función del escenario de ruta de acceso de datos, así como los controladores de cliente de información general deben tener en cuenta 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 sometido a prueba.

NET_RING

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

En la tabla siguiente se describen los miembros del anillo neto que los controladores de cliente pueden modificar.

Campo	Se permite modificar el controlador de cliente
OSReserved1	No
ElementStride	No
NumberOfElements	No
ElementIndexMask	No
Endindex	No
OSReserved0	No
OSReserved2	No
BeginIndex	Sí (obligatorio)
NextIndex	Sí (opcional) Nota: El marco nunca lee NextIndex.
Borrador	Sí (opcional) Nota: El marco nunca lee Scratch.
Buffer	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, consulte Introducción a los anillos netos.

NET_PACKET

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

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

Rx o Tx	Omitir campo está establecido por...	Notas
Rx	Controlador de cliente	Durante Rx, los controladores de cliente establecen Ignore si es necesario y el marco lo lee. Los controladores de cliente no necesitan leer Ignore en ningún momento durante Rx. Si un controlador de cliente establece el campo Omitir durante rx, haga lo siguiente: Los controladores de cliente deben escribir en el campo Omitir al cancelar las operaciones Rx de cualquier paquete que no se haya programado correctamente 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 de cliente deben rellenar FragmentIndex, FragmentCount y todos los campos de Layout. FragmentIndex debe estar entre BeginIndex inclusivo y EndIndex exclusivo en el anillo de fragmento. FragmentCount no puede superar el recuento de fragmentos entre BeginIndex inclusivo y EndIndex exclusivo 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 fragmentos BeginIndex debe moverse al EndIndex de los fragmentos del paquete anterior.
Tx	NetAdapterCx	Los controladores de cliente no deben modificar ningún campo de ningún paquete excepto scratch. Los controladores de cliente pueden leer el valor de Ignore pero nunca debe escribir en él. Si se omite un paquete Tx, el controlador no debe leer ningún campo excepto para Scratch, si es necesario.

NET_PACKET_LAYOUT

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

• El controlador de 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 se establece 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.

NET_FRAGMENT

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 se debe modificar, 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 scratch.