Interruptions NAPI vs adaptatives


12

Quelqu'un pourrait-il expliquer comment les deux technologies suivantes sont utilisées pour atténuer la surcharge d'interruption sous une charge réseau élevée?

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

J'apprécierais une réponse qui explique la différence plus près du niveau source du noyau linux? Je voudrais également savoir comment forcer la carte d'interface réseau à interroger / interrompre le mode de fusion à une charge qui est ~ 400 Mbps.

Plus d'informations:

Le problème semble être que les pilotes bnx2 et e1000 ignorent la commande "ethtool -C adaptive-rx on". Cela est probablement dû au fait que ces pilotes ne prennent pas en charge les interruptions adaptatives. Bien que le manuel de référence du programmeur Broadcom indique que cette fonctionnalité devrait être prise en charge par le matériel NIC BCM5709.

J'ai donc décidé d'essayer NAPI et de réduire le poids de 64 à 16 dans l'appel de fonction netif_napi_add () pour forcer le NIC en mode interrogation sous une charge beaucoup plus faible, mais malheureusement cela n'a pas fonctionné. Je suppose que NAPI n'a pas besoin de support matériel spécial dans NIC, est-ce correct?

Le matériel que j'utilise est la carte réseau BCM5709 (il utilise le pilote bnx2). Et OS est Ubuntu 10.04. Le CPU est XEON 5620.

Réponses:


18

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


1
Vous avez dit que "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 ". Mais dans wiki a déclaré que NAPI n'utilise pas d'interruptions matérielles, jamais, mais interroge chaque période de temps : fr.wikipedia.org/wiki/New_API Citation exacte: "Le noyau peut vérifier périodiquement l'arrivée des paquets réseau entrants sans être interrompu , ce qui élimine la surcharge de traitement des interruptions. " Où est la vérité?
Alex

1
Les interruptions matérielles @Alex doivent être utilisées pour informer le noyau qu'il y a du trafic à recevoir. Un gestionnaire d'interruption "à l'ancienne" planifie la réception des paquets, puis réactive les interruptions. Un gestionnaire d'interruptions NAPI désactive les interruptions, planifie un interrogateur et réactive les interruptions. Le poller effectue la réception de paquets pour une certaine quantité de paquets, et tant qu'il y a du trafic à entretenir, le poller continue de fonctionner, le but étant d'éviter les interruptions matérielles en tirant toujours le trafic de la carte réseau. Lorsque le trafic s'arrête, le scrutateur sort et le système se remet en attente d'une interruption.
suprjami
En utilisant notre site, vous reconnaissez avoir lu et compris notre politique liée aux cookies et notre politique de confidentialité.
Licensed under cc by-sa 3.0 with attribution required.