Je vais probablement enfoncer des portes ouvertes mais c'est pas grave. Récemment j'ai écouté le trafic d'une machine qui streamait du son via le protocole DAAP (le truc de iTunes) sous un linux (donc une approximation de DAAP en fait, car les specs ne sont pas releasées). Bref, le linux envoie de la musique sur un LAN via le soft rhythmbox. Ça passe par un LAN, et arrive au client. En faisant un coup de tcpdump sur le serveur, je m'aperçois que les datagrammes IP font régulièrement plus de 1500 bytes. Souvent 5 ou 7 KB. Curieux... Je me demande d'où ça vient. Qui plus est, le checksum TCP est incorrect. Vraiment chelou, ça.

$ ip link ls eth0
3: eth0: <BROADCAST,MULTICAST,PROMISC,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 1000
    link/ether 00:12:3f:71:57:a1 brd ff:ff:ff:ff:ff:ff

La MTU est bien à 1500. Si j'écoute sur le client, je vois bien des paquets fragmentés. Bizarre bizarre. Le switch ferait ça ? Je mirror les ports et j'écoute : paquets fragmentés. Boooon, après avoir cherché à droite à gauche, je tombe sur ces liens :

L'explication est que la fragmentation est réalisée par la carte réseau, hypothèse que j'avais exclue d'emblée, parce que ça me semblait overkill. Et pourtant ! Un patch avec des benches envoyés sur la ml netdev du noyau linux montre que ça améliore significativement les performances (dans le cas où le firmware permet de le faire, bien sûr), et ça semble intégré depuis le 2.6.18.

C'est tout. Je voulais juste poster ça pour éviter aux ignares comme moi de chercher pendant des plombes le pourquoi du comment. Enfin... encore faut-il qu'ils connaissent ce site. :-)

PS : pour le checksum erroné, c'est visiblement parce que la stack TCP/IP sait que le device va regragmenter, et donc invalider le checksum calculé (et en mettre un autre à la place). Donc pas la peine de se fatiguer à le calculer. C'est mon hypothèse, il faudrait que je regarde les sources.