Zusammenfassung

  • Über Prestos POSIX-Interpositionsschicht können nach Angaben der Autoren Programme wie memcached und nginx unverändert laufen; der Prototyp tauscht TCP mit Linux- und TAS-Endpunkten aus.
  • Derselbe Quellstand verlangt jedoch veränderte iCRC-Prüfung auf ConnectX-Karten und zusätzliches Ethernet-Padding von jedem beteiligten Peer. Die Anwendung bleibt gleich, der technische Geltungsbereich nicht.

Kompatibilität ist bei Presto keine einzelne Linie auf einer Checkliste. Sie beginnt beim Anwendungsbinärprogramm, führt durch die Socket-Semantik und endet erst nach Peer, Netzwerkkarte, Switch-Programm und physischem Frame.

Der Gastbeitrag im APNIC Blog beschreibt vor allem den oberen Teil dieser Kette. Rajath Shashidhara erklärt, verbreitete Anwendungen könnten ohne Änderung über die POSIX-Schicht laufen und der Prototyp arbeite mit Linux und dem TCP Acceleration Service (TAS) zusammen. Der Blog kennzeichnet die Ansichten zugleich als jene der Autoren. Daraus folgt keine institutionelle Bestätigung oder unabhängige Abnahme durch APNIC.

Im Commit a6c1ceec447c27a7b77035cc7d4a1868a4f7fcc1 lässt sich der Pfad ohne Anwendungsänderung genau benennen. libpresto_interpose.so emuliert POSIX-Sockets und wird per LD_PRELOAD in einen bestehenden Prozess geladen. Daneben gibt es eine niedrigere Zero-Copy-Schnittstelle, für die Anwendungen angepasst werden müssen. „Unverändert“ ist damit eine Eigenschaft des vorgesehenen Interpositionspfads, nicht aller Presto-APIs.

Unterhalb dieser Grenze nennt die README-Datei einen engen Versuchsaufbau: einen Tofino-2-Switch, ConnectX-5 oder neuer, eine bestimmte SDK-Generation, einen festgelegten Board-Support-Commit und eine Mindestversion von MLNX OFED. Das sind gute Reproduktionsdaten. Sie sind zugleich ein Warnsignal gegen Aussagen über ungeprüfte Kombinationen.

Die entscheidende Bedingung betrifft RDMA iCRC. Der Datenpfad setzt sie nicht. Für ConnectX-Karten soll die Validierung abgeschaltet werden; bei ConnectX-6 und ConnectX-7 verweist die Anleitung auf gerätespezifische Hinweise des NVIDIA-Supports. Außerdem muss jeder TCP-Peer, der mit Presto spricht, am Ende jedes Segments genügend Ethernet-Padding für die iCRC ergänzen. Eine entsprechend geänderte TAS-Variante liegt bei.

Das SIGCOMM-2026-Papier ordnet die Einschränkung ausdrücklich den Testbed Constraints des Tofino-2-Prototyps zu. Dessen Checksum-Engine unterstützt die betreffenden Payload-Prüfsummen und die RDMA iCRC nicht; für eine Produktionsfassung stellen die Autoren Hardware-Checksum-Einheiten in Aussicht. Der heutige Aufbau ist also bedingt, ohne dass diese Bedingung zwangsläufig für jede spätere Implementierung gilt.

Eine allgemeine TCP-Vorgabe ist sie ebenfalls nicht. RFC 9293 beschreibt den zuverlässigen, geordneten Byte-Strom, die Segmentverarbeitung und die TCP-Prüfsumme. Der Platz für eine RDMA iCRC im Ethernet-Frame und der Prüfzustand der NIC gehören zum Implementierungspfad zwischen Host und Presto. Ein standardkonformer TCP-Peer muss dieses zusätzliche Format nicht von sich aus erzeugen.

Darum reicht ein erfolgreicher Anwendungslauf nicht als End-to-End-Beleg. Er prüft Binärprogramm, ABI und Socket-Verhalten. Für Peer- und Gerätekompatibilität braucht es außerdem Paketmitschnitt, NIC-Modell, Firmware, Treiber, Registerwerte, MTU sowie die exakten P4- und Control-Plane-Builds.

Das Skript disable-icrc.sh macht die Konfigurationsänderung messbar. Es warnt vor der Annahme einer ConnectX-5, liest vier Registerfelder, schreibt Nullwerte und liest erneut. Für andere Karten soll der Betreiber Werte wiederherstellen und das Skript anpassen. Ein belastbarer Testbericht bewahrt daher Vorher- und Nachherwerte und einen verifizierten Rückweg, nicht nur den Exitcode.

Ein Abnahmebeleg sollte den Hash der Anwendung mit Presto-Commit, P4-Build, Control Plane, SDK, BSP, Treiber, Firmware und MTU verbinden. Ein Mitschnitt zeigt den Frame-Abschluss. Separat geprüft werden ein vorbereiteter TAS-Peer, ein unveränderter Linux-Peer und gegebenenfalls ein eigens vorbereiteter Linux-Pfad. Nur getestete Kombinationen gehören in die Kompatibilitätsmatrix.

Auch das Zurücksetzen ist mehrstufig. switchconf_reset entfernt Flow-Tabellen, verbundene Hosts, Anwendungskontexte und Laufzeitzustand, behält jedoch die Portkonfiguration. Das setzt den Switch-Anteil zurück, aber nicht automatisch NIC-Register oder das Padding-Verhalten des Peers. Vollständig ist der Rollback erst, wenn gewöhnlicher TCP-Verkehr nach der Wiederherstellung erneut über den Ausgangspfad läuft.

Prestos Forschungsbeitrag bleibt davon unberührt. Eine bestehende Anwendung auf einer programmierbaren Transportpipeline weiterlaufen zu lassen, ist gerade der interessante Teil. Für den Betrieb muss dieser Erfolg jedoch als Verschiebung der Änderung verstanden werden: weg von der Anwendung, hin zu einem genau zu verwaltenden Netzrand.

Quellen