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 <k...@oav.net> :
Le 12 févr. 2014 à 12:28, Raphael Mazelier <r...@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.
_______________________________________________
Liste de diffusion du FRsAG
http://www.frsag.org/
