Le Sat, 14 Aug 2010 10:30:50 +0200, Arnaud Launay asl@launay.org a écrit :
ainsi que sur le tcpoffload, ça m'intéresserait beaucoup,
J'ai oublié çà ...
En fait il arrive que sur les NICs qui font du TCP offloading on ait soit des bugs (corruption des paquets TCP), soit des pbs de performances. Il est par conséquence primordial de pouvoir flasher leur firmware.
Pour les pbs de perfs, des outils comme uperf ou netperf permettent de rapidement les identifier : on fait des benchmarks avec et sans le TCP offloading, si sans çà marche plus vite, houston, on a un pb :p
Pour les corruption de paquets TCP, soit lors du benchmarking tu fais des captures de paquets et tu regardes les trames, soit tu prends un outil qui te permet de garantir l'intégrité des trames TCP par un autre moyen que le checksum standard de TCP. Dans le cadre d'une intégration de DRBD avec des NICs qui font du TCP offload, tu as cette possibilité en natif, tu l'actives sur DRBD le temps de la phase de test (parce que c'est pas fait pour être mis en prod, sauf si tu as plus besoin d'intégrité que de throughput) et çà te permet de vérifier que le TCP offloading n'est pas source de corruption.
a +.