Le principe principal de la modération des interruptions est de générer moins d'une interruption par trame reçue (ou une interruption par achèvement de la trame de transmission), réduisant ainsi la surcharge du système d'exploitation rencontrée lors de la maintenance des interruptions. Le contrôleur BCM5709 prend en charge deux méthodes dans le matériel pour fusionner les interruptions, notamment:
- Générer une interruption après avoir reçu des trames X (trames rx dans ethtool)
- Génère une interruption lorsqu'aucune trame n'est reçue après X usecs (rx-usecs dans ethtool)
Le problème avec l'utilisation de ces méthodes matérielles est que vous devez les sélectionner pour optimiser le débit ou la latence, vous ne pouvez pas avoir les deux. La génération d'une interruption pour chaque trame reçue (trames rx = 1) minimise la latence, mais elle le fait à un coût élevé en termes de surcharge de service d'interruption. La définition d'une valeur plus élevée (disons rx-frames = 10) réduit le nombre de cycles CPU consommés en générant une seule interruption pour chaque dix frames reçues, mais vous rencontrerez également une latence plus élevée pour les premières frames de ce groupe de dix.
L'implémentation NAPI tente de tirer parti du fait que le trafic arrive par lots, de sorte que vous générez une interruption immédiatement sur la première trame reçue, puis vous passez immédiatement en mode d'interrogation (c.-à-d. Désactivez les interruptions) car plus de trafic sera proche. Après avoir interrogé un certain nombre d'images (16 ou 64 dans votre question) ou un certain intervalle de temps, le pilote réactivera les interruptions et recommencera.
Si vous avez une charge de travail prévisible, des valeurs fixes peuvent être sélectionnées pour l'un des éléments ci-dessus (NAPI, rx-frames, rx-usecs) qui vous offrent le bon compromis, mais la plupart des charges de travail varient et vous finissez par faire des sacrifices. C'est là que l'adaptive-rx / adaptive-tx entre en jeu. L'idée est que le pilote surveille en permanence la charge de travail (trames reçues par seconde, taille de trame, etc.) et ajuste le schéma de fusion des interruptions matérielles pour optimiser la latence dans les situations à faible trafic ou optimiser le débit dans les situations à fort trafic. C'est une théorie cool mais peut être difficile à mettre en œuvre dans la pratique. Seuls quelques pilotes l'implémentent (voir http://fxr.watson.org/fxr/search?v=linux-2.6&string=use_adaptive_rx_coalesce ) et les pilotes bnx2 / e1000 ne figurent pas sur cette liste.
Pour une bonne description du fonctionnement de chaque champ de coalescence ethtool, consultez les définitions de la structure ethtool_coalesce à l'adresse suivante:
http://fxr.watson.org/fxr/source/include/linux/ethtool.h?v=linux-2.6#L111
Pour votre situation particulière (débit ~ 400 Mo / s), je vous suggère de régler les valeurs rx-frames et rx-usecs pour les meilleurs paramètres pour votre charge de travail. Regardez à la fois les frais généraux de l'ISR ainsi que la sensibilité de votre application (httpd? Etc.) à la latence.
Dave
