Résumé

  • Les auteurs de Presto expliquent que memcached, nginx et d’autres applications peuvent emprunter une couche d’interposition POSIX sans être recompilés, avec des échanges TCP vers Linux et TAS.
  • Le dépôt du prototype précise pourtant que le chemin Tofino 2 ne produit pas l’iCRC RDMA, que la validation doit être modifiée sur les cartes ConnectX et que la pile TCP de chaque pair doit réserver un remplissage Ethernet suffisant. L’ABI reste stable, l’environnement de bout en bout non.

Le terme « compatible » change de sens selon l’endroit où l’on place la frontière. Vu par le développeur, le test consiste à lancer le même programme et à retrouver les mêmes appels de sockets. Vu par l’exploitant, il faut encore savoir quel micrologiciel, quel registre de carte, quelle construction de trame et quel pair se trouvent derrière cette apparente continuité.

Le billet publié sur le blog de l’APNIC insiste sur la première moitié du tableau. Rajath Shashidhara y décrit une couche POSIX qui accueille sans modification des applications courantes et une interopérabilité avec les terminaisons Linux et TAS. La page est toutefois un billet invité et son avertissement attribue les opinions aux auteurs. Il ne faut donc pas transformer cette publication en validation institutionnelle de l’APNIC.

Le code fixe plus précisément la promesse. Au commit a6c1ceec447c27a7b77035cc7d4a1868a4f7fcc1, libpresto_interpose.so émule les sockets POSIX et s’insère avec LD_PRELOAD. C’est le chemin qui permet de garder un binaire intact. Une autre bibliothèque, plus proche du transfert sans copie, demande au contraire une adaptation de l’application. La compatibilité applicative est donc un choix d’interface documenté, pas une propriété uniforme de tout le projet.

En dessous, le guide du dépôt énumère une plate-forme très déterminée : commutateur de classe Tofino 2, cartes ConnectX, version de SDK, commit de support de carte et version minimale de MLNX OFED. Ces coordonnées rendent l’expérience reproductible. Elles interdisent aussi de conclure qu’un succès sur cette plate-forme couvre automatiquement une autre carte ou une autre pile distante.

La condition décisive porte sur la trame. Le chemin de données ne renseigne pas l’iCRC RDMA. Le README demande de désactiver sa validation sur ConnectX ; pour les générations 6 et 7, il renvoie vers des instructions propres au matériel. Surtout, toute pile TCP qui dialogue avec Presto doit ajouter en fin de segment assez de remplissage Ethernet pour laisser la place à cet iCRC. Le dépôt fournit une variante de TAS qui le fait.

L’article scientifique présenté à SIGCOMM 2026 ne cache pas cette limite. Il la range dans la section consacrée aux contraintes du banc d’essai Tofino 2. Le moteur de sommes de contrôle du prototype ne sait pas assurer les opérations attendues ; les auteurs indiquent qu’une version de production intégrerait des unités matérielles adaptées. Le périmètre est donc borné dans le temps et dans le matériel. Il demeure obligatoire pour reproduire le résultat publié.

Ce mécanisme n’est pas une exigence générale de TCP. La RFC 9293 définit le flux d’octets fiable et ordonné, le traitement des segments et la somme de contrôle TCP. L’espace réservé à l’iCRC RDMA et le réglage de validation de la carte appartiennent au montage qui relie l’hôte au pipeline Presto. Une pile peut respecter TCP tout en ne produisant pas spontanément la trame spéciale attendue ici.

La différence est opérationnelle. Tester nginx sans le recompiler prouve la continuité de l’interface de l’application. Cela ne prouve pas que le pair Linux n’a reçu aucune adaptation, que les registres de la carte ont la bonne valeur, que le MTU est cohérent ni que la trame contient le remplissage requis. Il faut une preuve distincte pour chaque surface.

Le script disable-icrc.sh donne la forme minimale de cette preuve. Il avertit qu’il suppose une ConnectX-5, lit quatre champs de registre, écrit des zéros puis relit l’état. Pour une autre carte, il demande de rétablir les valeurs et d’adapter le script. Un procès-verbal sérieux doit conserver les lectures avant et après, le modèle exact, le micrologiciel et la procédure de retour ; la seule mention « script exécuté » est insuffisante.

Un reçu d’acceptation relierait alors le hash du binaire applicatif au commit Presto, au programme P4, au contrôle du commutateur, au SDK, au pilote, au micrologiciel de la carte, au MTU et aux valeurs de registre. Une capture montrerait la fin de trame. Des essais séparés couvriraient un pair TAS préparé, un pair Linux ordinaire et, si elle existe, une variante Linux préparée. Le résultat préciserait quelle combinaison a réellement fonctionné.

Le retour arrière doit figurer dans le même reçu. switchconf_reset peut vider les tables de flux, les hôtes connectés, les contextes applicatifs et l’état d’exécution du commutateur sans perdre la configuration des ports. Cette commande ne restaure pas nécessairement les registres de la carte ni le comportement d’un pair modifié. La fin du test est donc un nouvel échange TCP normal après restauration, pas la seule disparition des entrées du commutateur.

Le résultat de recherche reste important : conserver le programme tout en déplaçant le transport vers un pipeline programmable réduit une barrière réelle. Mais l’adoption ne doit pas confondre l’absence de recompilation avec l’absence de changement. Presto déplace la modification hors de l’application ; il ne la fait pas disparaître.

Sources