Iperf: Réduisez la taille du package UDP par défaut à physiquement MTU - utilisez les E/S enregistrées WSA sur Windows pour recevoir les packages UDP

Créé le 25 janv. 2021  ·  4Commentaires  ·  Source: esnet/iperf

J'ai découvert, quelle est la raison, que les files d'attente RSS UDP ne fonctionnent pas : l'adaptateur réseau convergent Ethernet Intel(R) X550-T2 n'envoie pas de packages Jumbo même s'il est configuré (d'autres NIC le font), donc tous les packages UDP plus grands que les 1500MTU par défaut sont divisés en packages IP. Les packages IP n'ont pas de ports et l'algorithme UDP-RSS-Hashing ne peut pas fonctionner. Même s'il saurait que le package IP fait partie d'un package UDP.

Le seul moyen est de réduire la taille du MTU du côté envoi d'iperf au MTU physique.
De plus, Windows ne reçoit pas plus d'un package UDP du noyau, lors de l'utilisation de l'API WINSOCK par défaut. Ce qui entraînera une charge CPU très élevée. Pour résoudre ce problème, iperf doit utiliser l'API d'E/S enregistrée WSA.

_Publié à l'origine par @Febbe sur https://github.com/esnet/iperf/issues/1049#issuecomment -766829448_

Commentaire le plus utile

Le PR n°1119 a été soumis pour ajouter une option permettant de définir l'indicateur de ne pas fragmenter.

Tous les 4 commentaires

Je serais heureux que vous ayez pu découvrir ce qui cause ce problème! Malheureusement, ESnet ne prend pas en charge iperf3 sur Windows, donc s'il y a une solution, elle devra venir de la communauté (ainsi que de ne pas casser iperf3 pour les plates-formes prises en charge).

Est-ce que « ESnet ne prend pas en charge iperf3 sur Windows » signifie que vous, en tant qu'ESnet, ne réglerez pas cela, mais que vous accepterez les relations publiques de la communauté ?

Comme je le sais, les files d'attente RSS sont également utilisées sur les plates-formes Linux, donc même là, il serait logique, au moins, d'ajouter un indicateur pour interdire la fragmentation des packages pour udp, au lieu d'utiliser l'indicateur par défaut -l 8K.

Est-ce que « ESnet ne prend pas en charge iperf3 sur Windows » signifie que vous, en tant qu'ESnet, ne réglerez pas cela, mais que vous accepterez les relations publiques de la communauté ?

Nous prendrons les PR de la communauté s'ils ne cassent pas les fonctionnalités (utilisez la compilation conditionnelle si possible, il y a plusieurs exemples dans l'arborescence) ou ne provoquent pas de changements majeurs dans la conception de la conception iperf3. Nous n'avons pas la possibilité de tester réellement les PR spécifiques à Windows dans notre environnement, donc la meilleure chance d'obtenir un PR accepté est qu'il soit petit et facile à comprendre par les développeurs non Windows.

Le PR n°1119 a été soumis pour ajouter une option permettant de définir l'indicateur de ne pas fragmenter.

Cette page vous a été utile?
0 / 5 - 0 notes