question con, juste parceque j'ai déjà rencontré le problème.
tu n'aurai pas 12 miliars de rules iptables ?
Le 12/02/2014 21:37, Francois Romieu a écrit :
Bonsoir,
Xavier Beaudouin kiwi@oav.net :
Le 12 févr. 2014 à 12:28, Raphael Mazelier raph@futomaki.net a écrit :
[...]
Non c'est faux. Il faut arrêter avec ce mythe de l'autonégociation et cisco. C’était peut être vrai il y a 10ans mais plus maintenant. La best practice est de tout laisser en auto au contraire.
+1
Oui.
Il faut arrêter les conneries, les spécifications du giga sur cuivre IMPLIQUENT que l'autoneg DOIT être activé.
C'est pas plus compliqué que ça.
Histoire de préciser sans que les participants ne se sentent obligés d'avaler toute la spec 802.3 (au demeurant moyennement digeste, ici en version 2002): [...] 37.1.4.4 User Configuration with Auto-Negotiation Rather than disabling Auto-Negotiation, the following behavior is suggested in order to improve interoperability with other Auto-Negotiation devices. When a device is configured for one specific mode of operation (e.g. 1000BASE-X Full Duplex), it is recommended to continue using Auto-Negotiation but only advertise the specifically selected ability or abilities. This can be done by the Management agent only setting the bits in the advertisement registers that correspond to the selected abilities.
-> on a quand même le droit d'activer ou non les paramètres négociables.
Après tu peux aussi ajouter flow-control receive on / flow-control send on sur le cisco, ca peux aider.
CEPENDANT, il faut noter que c'est pas le switch qui vas ralentir mais l'OS.
S'il n'est pas capable de balouder ses packets car il est plus occupé le flow control vas dire au cisco : 'hey tu peux bufferiser la ?'.
Je ne comprends pas. S'agit-il d'une description des trames PAUSE ou de complètement autre chose ?
[...]
- voir si par hasard dans ton bios tu as désactivé SRV-IO si oui = point blague, actives le
- voir si par hasard tu n'as pas 200000 modules qui partagent la même irq
Ca supposerait que le module igb emploie des interruptions PCI historiques et non des interruptions MSI [*]. Je ne critique pas le côté plaisanterie de la chose mais je serais curieux de savoir si quelqu'un a déjà croisé un truc pareil.
Le partage d'IRQ avec d'autres modules devrait donc être d'emblée exclus.
[*] La prise en charge des interruptions MSI est d'ailleurs requise par le pilote igb pour le fonctionnement avec SR-IOV, rejoignant ainsi la spec. [blabla SR IOV specification] PFs may implement INTx per the PCI Express Base Specification. VFs must not implement INTx. PFs and VFs shall implement MSI or MSI-X or both if interrupt resources are requested. Each PF and VF must implement its own unique interrupt capabilities
Bonne soirée.