NAPI vs interrupciones adaptativas

12

¿Alguien podría explicar cómo se utilizan las dos tecnologías siguientes para mitigar la sobrecarga de interrupción bajo una alta carga de red?

  1. Adaptive-rx / Adaptive-tx, y
  2. NAPI;

Agradecería una respuesta que explica la diferencia más cerca del nivel de fuente del kernel de Linux? También me gustaría escuchar cómo forzar a la NIC a sondear / interrumpir el modo de fusión en la carga que es ~ 400Mbps.

Más antecedentes:

El problema parece ser que los controladores bnx2 y e1000 ignoran el comando "ethtool -C adaptive-rx on". Esto probablemente se deba a que esos controladores no admiten interrupciones adaptativas. Aunque el manual de referencia del programador Broadcom dice que esta característica debe ser compatible con el hardware NIC BCM5709.

Así que decidí probar NAPI y reducir el peso de 64 a 16 en la llamada a la función netif_napi_add () para forzar la NIC en modo de sondeo con una carga mucho menor, pero desafortunadamente eso no funcionó. Supongo que NAPI no necesita ningún soporte de hardware especial en NIC, ¿es correcto?

El hardware que estoy usando es BCM5709 NIC (usa el controlador bnx2). Y el sistema operativo es Ubuntu 10.04. La CPU es XEON 5620.

usuario389238
fuente

Respuestas:

18

El principio principal detrás de la moderación de interrupción es generar menos de una interrupción por trama recibida (o una interrupción por finalización de trama de transmisión), reduciendo la sobrecarga del sistema operativo que se encuentra al dar servicio a las interrupciones. El controlador BCM5709 admite un par de métodos en hardware para las interrupciones de fusión, que incluyen:

  • Genere una interrupción después de recibir X cuadros (fotogramas rx en ethtool)
  • Genere una interrupción cuando no se reciben más tramas después de X usecs (rx-usecs en ethtool)

El problema con el uso de estos métodos de hardware es que debe seleccionarlos para optimizar el rendimiento o la latencia, no puede tener ambos. La generación de una interrupción para cada trama recibida (fotogramas rx = 1) minimiza la latencia, pero lo hace a un alto costo en términos de sobrecarga del servicio de interrupción. Establecer un valor mayor (digamos fotogramas rx = 10) reduce el número de ciclos de CPU consumidos al generar solo una interrupción por cada diez fotogramas recibidos, pero también encontrará una latencia mayor para los primeros fotogramas en ese grupo de diez.

La implementación de NAPI intenta aprovechar el hecho de que el tráfico viene en grupos, de modo que genere una interrupción inmediatamente en el primer cuadro recibido, luego cambie inmediatamente al modo de sondeo (es decir, deshabilite las interrupciones) porque habrá más tráfico cerca. Después de haber consultado un número determinado de fotogramas (16 o 64 en su pregunta) o algún intervalo de tiempo, el controlador volverá a habilitar las interrupciones y comenzará de nuevo.

Si tiene una carga de trabajo predecible, se pueden seleccionar valores fijos para cualquiera de los anteriores (NAPI, fotogramas rx, rx-usecs) que le brindan la compensación correcta, pero la mayoría de las cargas de trabajo varían y termina haciendo algunos sacrificios. Aquí es donde entran en juego adaptive-rx / adaptive-tx. La idea es que el controlador monitorea constantemente la carga de trabajo (fotogramas recibidos por segundo, tamaño de fotograma, etc.) y ajusta el esquema de fusión de interrupción de hardware para optimizar la latencia en situaciones de bajo tráfico u optimizar el rendimiento en situaciones de alto tráfico. Es una teoría genial, pero puede ser difícil de implementar en la práctica. Solo unos pocos controladores lo implementan (consulte http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) y los controladores bnx2 / e1000 no están en esa lista.

Para una buena descripción de cómo se supone que funciona cada campo de fusión de ethtool, eche un vistazo a las definiciones de la estructura ethtool_coalesce en la siguiente dirección:

http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111

Para su situación particular (~ 400Mb / s de rendimiento), le sugiero que ajuste los fotogramas rx y los valores de uso de rx para la mejor configuración para su carga de trabajo. Observe tanto la sobrecarga del ISR como la sensibilidad de su aplicación (httpd, etc.) a la latencia.

Dave

Dave
fuente
1
Dijiste que "la implementación de NAPI intenta aprovechar el hecho de que el tráfico viene en grupos, de modo que generas una interrupción inmediatamente en el primer marco recibido , luego cambias inmediatamente al modo de sondeo ". Pero en wiki dice que NAPI no usa interrupciones de hardware, nunca, sino que realiza encuestas cada cierto período de tiempo : en.wikipedia.org/wiki/New_API Cita exacta: "El núcleo puede verificar periódicamente la llegada de los paquetes de red entrantes sin ser interrumpido , que elimina la sobrecarga del procesamiento de interrupciones ". Donde esta la verdad
Alex
1
Las interrupciones de @Alex Hardware deben usarse para notificar al núcleo que hay tráfico que recibir. Un controlador de interrupciones de "estilo antiguo" programa la recepción de paquetes y luego vuelve a habilitar las interrupciones. Un controlador de interrupciones NAPI deshabilita las interrupciones, programa un sondeo y vuelve a habilitar las interrupciones. El encuestador realiza la recepción de paquetes para una cierta cantidad de paquetes, y siempre que haya tráfico para dar servicio, el encuestador sigue funcionando, con el objetivo de evitar interrupciones duras siempre sacando el tráfico de la NIC. Cuando el tráfico se detiene, el sondeo sale y el sistema vuelve a esperar una interrupción.
suprjami