12 votos

NAPI vs Adaptativa Interrupciones

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

  1. Adaptación-rx/Adaptación-tx, y
  2. NAPI;

Le agradecería una respuesta que explica la diferencia más cerca de fuente del núcleo de linux? También me gustaría saber cómo la fuerza de la NIC de sondeo/interrumpir coalescentes en el modo de carga que es de ~ 400Mbps.

Más de fondo:

El problema parece ser que bnx2 y e1000 conductores ignoran "ethtool -C adaptativa-rx" de comandos. Esto es probablemente debido a que los conductores no soporte adaptativo interrupciones. Aunque la Broadcom manual de referencia del Programador dice que esta característica debe ser apoyado por BCM5709 de hardware NIC.

Así que me decidí a probar NAPI y reducir el peso de 64 a 16 en netif_napi_add() llamada a la función a la fuerza de la NIC en modo de sondeo bajo mucho menor carga, pero por desgracia eso no funcionó. Supongo que NAPI no necesita ningún hardware especial apoyo en NIC, ¿es correcto?

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

18voto

Dave Puntos 211

El principio fundamental detrás de la moderación de la interrupción es generar menos de una interrupción por cada trama recibida (o una interrupción por transmitir la finalización de los trabajos), la reducción de la OS sobrecarga encontrado cuando el servicio se interrumpe. El BCM5709 controlador soporta un par de métodos en el hardware para la creación de las interrupciones, incluyendo:

  • Generar una interrupción después de recibir X marcos (rx-marcos en ethtool)
  • Generar una interrupción cuando no hay más tramas recibidas después del X usecs (rx-usecs en ethtool)

El problema con el uso de estos métodos de hardware es que usted necesita para seleccionar a optimizar el rendimiento o la latencia, no se puede tener ambas. La generación de una interrupción para cada trama recibida (rx-fotogramas = 1) minimiza la latencia, pero lo hace a un alto costo en términos de interrupción de servicio de sobrecarga. Configuración de un valor mayor (digamos rx-marcos = 10) se reduce el número de ciclos de CPU consumido por la generación de sólo una interrupción para cada uno de los diez tramas recibidas, pero también te encontrarás con una mayor latencia para los primeros fotogramas en los que el grupo de los diez.

El NAPI implementación de los intentos de aprovechar el hecho de que el tráfico viene de los racimos, por lo que se genera una interrupción de inmediato en el primer fotograma recibida, entonces se cambia inmediatamente al modo de sondeo (es decir, deshabilitar las interrupciones) porque más tráfico será de cerca. Después de haber consultado a algún número de marcos (16 o 64 en tu pregunta) o algún intervalo de tiempo, a continuación, el controlador volver a habilitar las interrupciones y empezar de nuevo.

Si usted tiene una predicción de la carga de trabajo, a continuación, fija los valores pueden ser elegidos para ninguno de los anteriores (NAPI, rx-marcos, rx-usecs) que le dan el derecho de trade-off, pero la mayoría de las cargas de trabajo varían y se terminan haciendo algunos sacrificios. Aquí es donde adaptativa-rx/adaptación-tx entran en juego. La idea no es que el controlador monitorea constantemente la carga de trabajo (tramas recibidas por segundo, tamaño de fotograma, etc.) melodías y la interrupción de hardware coalescente esquema para optimizar la latencia en bajo situaciones de tráfico o para optimizar el rendimiento en situaciones de alto tráfico. Es una teoría, pero puede ser difícil de implementar en la práctica. Sólo un par de controladores de implementación (ver http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce) y el bnx2/e1000 los conductores no están en esa lista.

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

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

Para que la situación particular (~400 mb/s de rendimiento) sugeriría que la optimización de la rx-marcos y el rx-usecs valores para la mejor configuración para su carga de trabajo. Mira, tanto la sobrecarga de la ISR, así como la sensibilidad de su aplicación (httpd? etc.) a la latencia.

Dave

EnMiMaquinaFunciona.com

EnMiMaquinaFunciona es una comunidad de administradores de sistemas en la que puedes resolver tus problemas y dudas.
Puedes consultar las preguntas de otros sysadmin, hacer tus propias preguntas o resolver las de los demás.

Powered by: