Dégradation Des Performances Avec Les Trames Jumbo; Plusieurs Interfaces Sur Le Même Réseau De Diffusion Ethernet; Problèmes Msi-X Avec Des Noyaux De Versions 2.6.19 À 2.6.21 (Compris) - Intel Gigabit Ethernet Guide D'utilisation

Dégradation des performances avec les trames Jumbo
Une dégradation du débit peut être observée avec certaines trames Jumbo. Dans ce cas, il peut s'avérer utile
d'augmenter la taille de socket de l'application et/ou les valeurs d'entrée de /proc/sys/net/ipv4/tcp_*mem. Pour d'autres
détails, consultez la documentation spécifique de l'application dans le fichier texte ip-sysctl.txt de la documentation du
noyau.
Plusieurs interfaces sur le même réseau de diffusion Ethernet
En raison du comportement ARP par défaut sur Linux, il n'est pas possible qu'un système sur deux réseaux IP dans le
même domaine de diffusion Ethernet (commutateur non partitionné) se comporte normalement. Toutes les interfaces
Ethernet répondront au trafic IP pour toute adresse IP affectée au système. Il en résultera un trafic de réception non
équilibré.
Si un serveur dispose de plusieurs interfaces, activez le filtrage ARP en entrant :
echo 1 > /proc/sys/net/ipv4/conf/all/arp_filter
(ceci ne fonctionne que si la version du noyau est postérieure à 2.4.5), ou installez les interfaces dans des domaines
de diffusion différents.
Problème de perte de paquet lors du test de montée en charge UDP
Pendant le test de montée en charge UDP avec des petits paquets et le pilote 10GbE, le système Linux peut perdre
des paquets UDP parce que les descripteurs de socket sont pleins. Il est possible de régler les variables de contrôle
de flux du pilote à la valeur minimale pour le contrôle de la réception des paquets.
Une autre option consiste à accroître la taille par défaut des tampons pour udp en modifiant les valeurs dans
/proc/sys/net/core/rmem_default and rmem_max.
Débranchement du câble réseau alors qu'ethtool -p est en cours d'exécution
Sur les noyaux de versions 2.5.50 et supérieures (y compris la version 2.6), le système ne répond plus (sauf à la
commande Ctrl+Alt+Supp.) si le câble réseau est débranché alors que ethtool -p est en cours d'exécution. Le
redémarrage du système semble être le seul recours.
Le commutateur Cisco Catalyst 4948-10GE exécutant ethtool -g peut entraîner la
fermeture des ports par le commutateur
Le matériel basé sur le contrôleur 82598 peut rétablir rapidement la liaison et, lorsqu'il est connecté à certains
commutateurs, les réinitialisations rapides dans le pilote peuvent entraîner l'isolation du port du commutateur en
raison d'un "link flap". Cette condition est habituellement indiquée par un témoin de liaison de couleur jaune plutôt que
verte. Plusieurs opérations peuvent causer ce problème, telles que l'exécution répétée de commandes ethtool
entraînant une réinitialisation.
Un contournement potentiel consiste à utiliser la commande Cisco IOS "no errdisable detect cause all" depuis l'invite
de configuration globale, qui permet au commutateur de garder les interfaces en fonctionnement, sans tenir compte
des erreurs.
Problèmes MSI-X avec des noyaux de versions 2.6.19 à 2.6.21 (compris)
Des paniques et instabilités du noyau peuvent être observées sur tout matériel MSI-X si vous utilisez irqbalance avec
des noyaux de versions 2.6.19 et 2.6.21. Si ces types de problèmes surviennent, vous pouvez désactiver le démon
irqbalance ou mettre votre noyau à niveau.
Erreurs d'allocation de la page de réception
Erreurs d'allocation d'ordre d'échec : 0 erreur peut se produire en cas de stress avec les noyaux 2.6.25 et de versions
supérieures. Cela est dû à la façon dont le noyau Linux signale cette condition de stress.