摘要

  • Presto 通过 POSIX 插入层让 memcached、nginx 等程序无需重新编译即可运行，作者还报告它能与 Linux 和 TAS 的 TCP 端点互通。
  • 同一份发布记录也写明：Tofino 2 数据路径不会设置 RDMA iCRC，ConnectX 需要改变验证状态，所有交互对端还要在每个分段末尾留出足够的以太网填充。应用不变，并不等于部署环境不变。

判断一项网络技术是否“兼容”，首先要问兼容的是哪一层。程序员看到同一个可执行文件、同一组套接字调用，答案可能已经是肯定的。运维人员还要继续向下追问：哪一代网卡、什么寄存器值、哪一种对端实现，以及线上帧尾部究竟长什么样。

APNIC 博客的客座文章突出的是上层连续性。Rajath Shashidhara 介绍，Presto 的 POSIX 接口可以承载未修改的常见应用，并与 Linux、TCP Acceleration Service（TAS）端点交换 TCP 流量。不过页面同时明确，观点属于作者本人，不一定代表 APNIC。这里可以把 APNIC 视为发布平台，不能把客座文章改写成 APNIC 的机构背书或独立验收结论。

代码仓库把“无需改应用”的含义限定得更清楚。在提交 a6c1ceec447c27a7b77035cc7d4a1868a4f7fcc1 中，libpresto_interpose.so 通过 LD_PRELOAD 模拟 POSIX 套接字，让原有程序走进 Presto。另一个更底层的零拷贝接口则需要应用适配。因此，保持不变的是特意提供的插入式接口路径，而不是 Presto 的所有接入方式。

沿栈向下，条件迅速具体化。仓库 README列出 Tofino 2 级交换机、ConnectX-5 或更新网卡、交换机 SDK、特定板级支持提交和最低 MLNX OFED 版本。这些坐标让原型可复现，也同时说明，某一组合上的成功不能自动覆盖另一块网卡或另一套软件版本。

真正划出兼容性边界的是校验条件。README 说，数据路径不会生成 RDMA 的 invariant CRC。对 ConnectX，部署步骤要求关闭 iCRC 验证；对 ConnectX-6 和 ConnectX-7，则要求向 NVIDIA 获取对应说明。更关键的是，任何与 Presto 交互的 TCP 对端都必须在每个分段末尾添加足够的以太网填充，为 iCRC 留出位置。仓库提供的是已经具备这种行为的 TAS 变体。

SIGCOMM 2026 论文把这一点放在“测试平台限制”之下。作者把 payload 校验和与 RDMA iCRC 的缺失归因于原型所用 Tofino 2 校验引擎的能力，并说明生产实现会配置硬件校验单元。这一表述十分重要：当前限制不能被省略，但也不应被外推为所有未来 Presto 实现的永久属性。

它也不是 TCP 标准本身的要求。RFC 9293规定可靠、有序的字节流、TCP 分段处理和 TCP 自身的校验和。为 RDMA iCRC 预留帧空间、改变网卡对它的验证状态，属于主机与 Presto 数据路径之间的实现条件。一套对端即使遵守 TCP，也未必会天然生成该原型所期待的帧尾。

所以，“原应用运行成功”只能证明应用 ABI 与套接字语义这一段。它不能替代四类证据：对端是否按要求构造帧，网卡寄存器是否处在预期状态，交换机程序是否对应同一版本，以及撤销实验后普通 TCP 是否恢复。

仓库中的 disable-icrc.sh把这种证据要求写得很直观。脚本警告它假定使用 ConnectX-5；它先读取四个寄存器字段，再写入零值，随后重新读取。若使用其他网卡，说明要求恢复寄存器值并修改脚本。一次可审计测试应保存网卡型号、固件、变更前后读数和回退办法，而不是只写一句“脚本已执行”。

完整的验收回执还应绑定应用二进制摘要、Presto 提交、P4 与控制面构建、SDK、板级支持、驱动、MTU 和网卡状态。数据包捕获要显示帧尾预留空间。测试结果应分别注明：经过调适的 TAS 对端、普通 Linux 对端，以及任何专门调适的 Linux 路径，各自是否成功。这样，“互通”才有版本、对象与前提。

回退不能只清理交换机。README 中的 switchconf_reset 可以清空流表、已连接主机、应用上下文和运行时状态，同时保留端口配置。它有助于复位 Presto 一侧，却不能证明网卡寄存器已经还原，也不能证明对端取消了特殊填充。最后一项验收应是：所有变更恢复之后，原路径上的普通 TCP 流量再次通过。

这并没有削弱 Presto 的研究价值。让应用接口保持稳定、把传输处理迁入可编程流水线，本来就是它最值得关注的分层成果。运营决策需要做的，是把“没有改应用”准确解释为“变化移到了别处”，并把那个别处写进控制记录。

来源