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
