Outils réseauActualité

MetaRoCE : paquets perdus et récupération des données

Sur cette page
  1. Réordonnancement et perte ne sont pas le même événement
  2. Un essai ne décrit pas tous les déploiements
  3. Ce qu’il faut établir pour évaluer une implémentation

Meta a décrit MetaRoCE le 24 août comme un transport RDMA pour Ethernet avec pertes. Le réseau peut perdre ou réordonner des paquets pendant que le transport répare la livraison. L’application n’est pas censée accepter des données manquantes.

Exemple conceptuel : A et C occupent leurs positions pendant que B circule encore ou attend récupération. L’ordre global d’arrivée ne prouve pas une perte ; les données requises doivent être livrées. Aucune trace réseau MetaRoCE.
Exemple conceptuel : A et C occupent leurs positions pendant que B circule encore ou attend récupération. L’ordre global d’arrivée ne prouve pas une perte ; les données requises doivent être livrées. Aucune trace réseau MetaRoCE. Graphique : PeopleAreGeek. Source des données.
Agrandir l’image

Réordonnancement et perte ne sont pas le même événement

La présentation technique de Meta place choix des chemins et récupération aux extrémités, sans imposer les trames de pause PFC. Les paquets portent les informations permettant de placer les arrivées dans leurs positions mémoire.

Prenons un message fictif composé de A, B et C. Si A et C arrivent avant B par des chemins différents, ils peuvent rejoindre leurs positions pendant que B circule encore. Cet ordre d’arrivée ne prouve pas une perte. Si B est perdu, la récupération doit le fournir avant que l’application considère le message requis comme complet.

La distinction compte parce que le protocole décrit ordre et acquittements par chemin. Sa détection n’est pas simplement « un numéro absent dans le message global signifie un paquet perdu ». Réordonnancement entre chemins et trou dans la séquence d’un chemin n’ont pas le même sens.

Un essai ne décrit pas tous les déploiements

Meta rapporte une validation sur matériel AMD Pensando dans un cluster de 64 nœuds GPU, avec environ 86 % du débit conservé à 1 % de pertes. Ce sont des conditions expérimentales rapportées. Elles ne démontrent pas le même résultat pour toute topologie, charge ou implémentation de carte réseau.

La fin de l’article prévoit octobre pour publier spécification, référence logicielle et cadre de conformité au sommet OCP. La présentation de l’ouverture ne prouve donc pas que tous ces éléments étaient téléchargeables publiquement en août.

Ce qu’il faut établir pour évaluer une implémentation

Pour une carte et un pilote donnés, commencez par établir le support du protocole aux deux extrémités. La compatibilité des commutateurs Ethernet ne transforme pas une carte RoCE existante en implémentation MetaRoCE. Une référence logicielle sur UDP constitue aussi une cible différente d’une implémentation matérielle déchargée sur la carte.

Définissez ensuite le périmètre du test : octets utiles livrés, latence des requêtes les plus lentes, charge offerte, profil des pertes et délai de reprise. Comparez un travail égal. Compter les octets émis peut récompenser la retransmission répétée des mêmes données plutôt que l’achèvement de l’application.

PeopleAreGeek n’a pas exécuté MetaRoCE. L’idée consiste à faire gérer explicitement un réseau imparfait par le transport. Son adoption dépend encore des implémentations et de leur interopérabilité, pas du simple retrait de PFC sur un réseau existant.

Revue du 8 septembre : sources primaires, portée des annonces et exemples vérifiés ; illustration remplacée.