2011-09-11 9 views
5

¿Alguien puede explicar cuáles son las funciones de hardware TSO/LRO en TCP y si estas funciones también son responsables ante el mecanismo de acuse de recibo?¿Alguien puede explicar cuáles son las funciones de hardware TSO/LRO en TCP?

+0

Nunca he oído hablar de esas funciones HW. ¿Puedes explicar por favor? – valdo

+0

También en Wikipedia: [TSO] (http://en.wikipedia.org/wiki/Large_segment_offload) y [LRO] (http://en.wikipedia.org/wiki/Large_receive_offload). –

Respuesta

5

Un host con hardware habilitado para TSO envía datos TCP a la NIC sin segmentar los datos en el software. El NIC llevará a cabo la segmentación de TCP (léase: dividirá el fragmento de datos grandes en segmentos). Las NIC que admiten LRO reciben paquetes y los vuelven a ensamblar antes de pasar los datos al software local.

LRO/TSO no son responsables del mecanismo de respuesta directamente (aunque sí depende de GBN). Tenga en cuenta que LRO/TSO son seguros de usar en enrutadores y puentes siempre que todas las interfaces involucradas sean compatibles con la técnica.

+0

1. Si el LRO/TSO no es responsable ante el mecanismo de respuesta, ¿cómo pueden segmentar/volver a armar los paquetes? 2. ¿Por qué es necesario que todas las interfaces involucradas respalden la técnica LRO/TSO? –

+0

1. grandes trabajos de descarga de recepción agregando múltiples paquetes entrantes de una única secuencia en un búfer más grande antes de que pasen más arriba en la pila de red. Simplemente los agrega sin ninguna forma de verificar que los datos se enviaron correctamente. Hay algoritmos que resuelven este problema en otra capa. 2. Si voy a decirle 1509GB de datos, lo menos que debe hacer es tenerlo en cuenta y preparar un buffer de 1509GB. Esa es la simple regla de LRO/TSO. –

12

Sé que este es un hilo viejo, pero creo que la respuesta no está completa.

Lo primero que debes entender es que TSO es la punta de un iceberg bastante grande cuando se trata de técnicas para aumentar el rendimiento de la red.

Consideremos la interfaz de red básica. Su sistema operativo envía un paquete completo a la NIC (tarjeta de interfaz de red) utilizando PIO (entrada/salida programada, es decir, una palabra (normalmente 32 bits) a la vez) como debería aparecer en el cable excluyendo la secuencia de verificación de cuadros.

Estos son los aumentos de velocidad para la transmisión de datos.

El primer aumento de velocidad es usar DMA (Direct Memory Access), esto permite que el procesador haga otras cosas mientras el hardware copia el paquete. Pero el sistema operativo aún tiene que copiar los datos del paquete en la memoria y generar los encabezados y las sumas de comprobación.

El segundo impulso es hacer que el hardware genere la suma de comprobación para la porción de datos del paquete, el sistema operativo aún copiará los datos en su espacio de memoria y colocará el encabezado antes. Como el sistema operativo está generando los encabezados, siempre puede generar las sumas de comprobación para los encabezados. Esto parece complicado, pero el mecanismo es bastante simple. Se le dice al hardware que comience la suma de verificación cuando alcance la posición XX y que coloque la suma de verificación en la posición yy en el búfer de paquetes.

El tercer impulso es utilizar Scatter/Gather. Esto básicamente significa que el sistema operativo no copia los datos en su memoria, pasa el encabezado y la ubicación de la porción de datos al controlador y permite que el controlador recolecte los datos para enviarlos. Esto requiere verificación de hardware, si el sistema operativo necesita verificar el paquete, primero debe copiarlo en la memoria.

El cuarto (y el nivel más alto de refuerzo soportado de forma nativa en Linux) es TSO. Con TSO, el SO le da al hardware una plantilla de encabezado y luego una gran cantidad de datos (no más de 64K) para que se dividan y comprueben, los medios que el sistema operativo necesita para generar menos encabezados y cualquier sobrecarga en la configuración del DMA también se diezma . Cuando los paquetes pasan por el cable, cumplen con las reglas normales de los paquetes y serán compatibles con CUALQUIER interruptor o enrutador por el que pasen.

La recepción es una historia diferente. La suma de comprobación de hardware es más una conjetura que una certeza aquí, por lo que DEBE suceder es que el hardware pasa el paquete y la suma de verificación al sistema operativo por separado y permite que el sistema operativo decida si el paquete está OK o no.

Scatter/Gather es bastante redundante para recibir. LRO (descarga de recepción grande), bueno, no hay una manera fácil para que el hardware sepa lo que significan estos paquetes, entonces LRO es actualmente un constructo de software único, los paquetes se pasan al sistema operativo, el sistema operativo decide si no concatenar los datos y pasar una gran parte a la aplicación o pasar muchos trozos más pequeños.

Algunas notas en la pila de la red.

El software debe SIEMPRE producir los paquetes de ACK. La única razón por la que no lo haría es si tiene un TOE (motor de descarga TCP) en su NIC. No conozco ningún SO que lo soporte de forma nativa, lo que significa que necesitarás hackearlo para hacerlo compatible.

Así que hay una respuesta completa y laberíntica, espero que ayude a alguien.

+4

¡Si mejora el formateo, podría ayudar mucho a la legibilidad de esta respuesta! –

Cuestiones relacionadas