Rien ne l'oblige mais l'implantation générique est souvent base sur le fait que le hash + décision de forwarding est calculé une fois, pour le premier paquet, puis collé dans une table. Ensuite pour chaque autre paquet de la même FEC on calcule le hash, on look up la table, on applique la décision de forwarding sans réfléchir.
Et là, zallez me dire "mais pourquoi donc ?". Et comme d'habitude la réponse est rigolote. Le mec qui a codé ça à l'époque devait avoir comme inspiration son Cisco au bout de la table. Hors sur un Cisco, on a une CPU de cafetière, d'une latence fleurtant avec celle d'un lien transatlantique Cogent, mais épaulé par un ASIC et de la TCAM. Dans ce cas précis, prendre une décision de forwarding (cpu) est beaaaaaaaucoup plus lent que calculer un hash (via l'ASIC) faire un lookup dans une table (tcam : rapide). Alors que sur un Linusque, point de TCAM, point d'ASIC, tout passe en CPU et RAM... (oui si vous vous demandiez pkoi M$ a attendu Win2012 pour implémenter du LACP en soft, la réponse est là aussi : en s'appuyant sur les drivers, ils balançaient le pb sur le fournisseur de NIC, et hop jamais un pb côté OS). Du coup, intérêt de coder un truc pour emuler une TCAM ? Évidemment tout ceci est vrai tant que la NIC ne fait pas d'offloading (ce qui est maintenant généralement le cas, car ça pose pas mal de limitations sinon) Bref en 2017, il serait rigolo de faire un petit bench entre du per packet et per flow pour du LACP géré 100% en soft ... m'est avis que le résultat pourrait être surprenant :) Le lun. 26 juin 2017 à 22:27, Raphael Mazelier <r...@futomaki.net> a écrit : > > > On 26/06/2017 19:49, Youssef Ghorbal wrote: > > - Est ce que la spec (802.3ax ?) impose le fait que tt les packets > > d'une meme session TCP partent sur le meme lien physique ? Je ne > > trouve rien de clairement explicite. Je vois quelque chose concernant > > l'algo de hash qui doit respecter l'order des packets mais rien de > > plus. > > Le 802.3ad opére théoriquement au niveau 2. On lourait donc dire que peu > importe le lien physique qu'emprunte une session tcp, tant que les > paquets arrivent dans l'ordre. Ceci étant vu les algos de hash courants > (couple src/dst @mac, ou @ip) de fait une sessions tcp emprunte toujours > le même lien (sauf algo de hash type rr, ou adaptative). > > > > - Dans l'autre sens, est ce que les stacks reseaux (kernel, drivers, > > etc) s'attendent a voir atterir les packets TCP d'une meme session sur > > le meme port physique ?! Comment c'est sens se comporter si ce n'est > > pas le cas ? > > > > Si l'on prend l'exemple linux tout arrive sur une interface "bond" > niveau l2. Le kernel devrait pouvoir s'en sortir dans tous les cas. > > -- > Raphael Mazelier > > > --------------------------- > Liste de diffusion du FRnOG > http://www.frnog.org/ > -- Cordialement, Guillaume BARROT --------------------------- Liste de diffusion du FRnOG http://www.frnog.org/
