Summary

  • Presto’s authors report that applications such as memcached and nginx can run unchanged through a POSIX interposition layer, and that the prototype interoperates with Linux and TAS endpoints.
  • The same release record says the Tofino 2 data path does not set RDMA iCRC, tells ConnectX operators to change validation state, and requires every interacting peer stack to add enough Ethernet padding for that iCRC. Application compatibility is therefore not the same as an unchanged deployment perimeter.

“No application modification” is a valuable claim because it names the layer that can remain stable. It is not a promise that the network around that layer remains untouched.

That distinction is easy to miss in the APNIC guest post. Rajath Shashidhara writes that nothing above the socket changes: familiar server programs can run through Presto’s POSIX interface, and the prototype can exchange TCP traffic with Linux and the TCP Acceleration Service, or TAS. The page also carries APNIC’s standard guest-post disclaimer. These are the authors’ claims, not an APNIC policy position or an independent APNIC validation.

The interface mechanism is concrete. At repository commit a6c1ceec447c27a7b77035cc7d4a1868a4f7fcc1, libpresto_interpose.so emulates POSIX sockets and can be loaded into an unmodified program with LD_PRELOAD. The repository also exposes a lower-level zero-copy library that does require application adaptation. The broad phrase is therefore accurate for one deliberately provided application path, not for every possible Presto interface.

Below that boundary, the prerequisites become much more specific. The published setup names a Tofino 2-class switch, ConnectX-5 or later adapters, a particular switch SDK generation, a named board-support commit and a minimum MLNX OFED release. These are not criticisms; they are the reproducibility coordinates for the prototype. They also show why “the binary did not change” is only one line in an acceptance record.

The sharper condition appears in the repository’s deployment instructions. The data path does not set RDMA’s invariant CRC. For ConnectX devices, the instructions call for disabling iCRC validation; for ConnectX-6 and ConnectX-7, they direct the operator to obtain equivalent instructions from NVIDIA support. Any TCP peer that talks to the prototype must also append sufficient Ethernet padding to each segment to leave room for that iCRC. The repository supplies a TAS variant with that behaviour.

The SIGCOMM paper makes the scope explicit. Its checksum section is under “Testbed Constraints” and attributes the omission of TCP payload checksums and RDMA iCRC to the Tofino 2 checksum engine used by the prototype. It says production hardware would include checksum units. This is evidence of a bounded prototype condition, not evidence that every future implementation must share it.

It is also not a general TCP rule. RFC 9293 defines TCP’s reliable, ordered byte stream, segment processing and TCP checksum. The reserved frame space and NIC iCRC setting belong to the Presto test environment that carries traffic into and out of the switch data path. A peer can implement standard TCP semantics and still be unprepared for the extra wire-side convention described by this repository.

That is the compatibility perimeter: application ABI, socket semantics, peer packet construction, NIC register state, switch program and physical frame are different control surfaces. A test that proves only the first two cannot certify the remaining four.

The repository’s disable-icrc.sh makes the evidence requirement unusually visible. It warns that it assumes ConnectX-5, reads four register fields, writes zero values and reads them again. For another NIC, it tells the operator to restore register values and modify the script. That is a configuration operation with observable before-and-after state. A deployment record should preserve those observations rather than reduce the step to “script ran”.

A useful acceptance receipt would bind the application binary to the exact Presto commit, P4 and control-plane builds, switch SDK and board support, NIC model and firmware, driver package, MTU, register values before and after, and a packet capture showing the required tail space. It would run both a conditioned TAS peer and an ordinary Linux peer, recording which paths pass, which require adaptation and which are outside the tested claim.

The rollback test matters as much as the forward test. The README exposes switchconf_reset to clear Presto flow tables, connected hosts, application contexts and runtime state while retaining port configuration. That helps reset the switch side. It does not, by itself, prove that NIC register settings have been restored or that a peer modified for padding has returned to its ordinary behaviour. The receipt closes only when post-rollback TCP traffic is observed again on the original path.

None of this negates the application result. Preserving an application binary while moving transport work into a programmable pipeline is precisely what makes Presto interesting. It changes what “compatible” must mean in an operator’s decision: not a single yes-or-no property, but a chain of interfaces whose unchanged and changed parts are named separately.

Sources