Estoy interesado en respuestas particulares:
- ¿La NIC con GRO edita / crea TCP ACK o cualquier otro paquete (o esta característica es transparente para las pilas TCP del receptor / emisor)?
- ¿Debería haber un tiempo de espera / evento cuando NIC debe pasar los "segmentos pegados" a la pila TCP? ¿Qué son?
- En la configuración de reenvío de paquetes, ¿la función GRO también intenta leer los ACK del receptor (vea a continuación por qué pregunto esto)?
- Cualquier fuente que explique GRO y también otras características de descarga de NIC (TSO, LSO ...) mejor que las páginas de manual de wikipedia y Linux sería realmente apreciada.
Más detalles:
Estoy solucionando un problema de rendimiento con una implementación de IPSec. El problema es que el ancho de banda disponible no se distribuye uniformemente en los 4 túneles VPN (distribuidos aproximadamente como 200MBps / 200MBps / 1MBps / 1MBps; cada túnel VPN encapsula una única conexión TCP). En PCAP de vez en cuando veo que el servidor web está inactivo durante unos 2 segundos (esperando ACK). La descarga se reanuda cuando el servidor web retransmite segmentos no reconocidos.
Mi opinión interna de PCAP es que la función NIC GRO pega paquetes juntos, pero a veces no los pasa a la pila TCP de manera oportuna y eso está causando los problemas.
Como este servidor VPN no tiene interfaces que terminen las conexiones TCP sino que solo reenvían paquetes. Luego intenté desactivar GRO y luego observé que el tráfico se distribuía de manera uniforme en todos los túneles. Además, cuando el escalado de la ventana TCP está deshabilitado en el servidor web, el ancho de banda también se distribuye incluso con GRO habilitado (es por eso que tuve la pregunta # 3).
Estoy usando 2.6.32-27 Linux en el servidor Ubuntu 10.04 (64 bits). NIC es Intel 82571EB. Todas las interfaces (cliente HTTP, cliente VPN, servidor VPN, servidor web) están conectadas directamente en cadena con cables Ethernet de 1 Gbit.