LWN：P4TC 撞墙了！

关注了就能看到更多这么棒的文章哦～

P4TC hits a brick wall

By Jonathan Corbet
June 10, 2024
Gemini-1.5-flash translation
https://lwn.net/Articles/977310/

P4，简称“Programming Protocol-independent Packet Processors”（独立于协议的包处理器编程），是一种针对网络设备的编程语言；它在防火墙和复杂的路由架构配置方面很有用。由于许多高级网络功能都是通过 Linux 系统实现的，因此支持 P4 具有很大价值。实际上，P4 的实现 在 2023 年初由 Jamal Hadi Salim 首次发布到内核的流量控制子系统中。然而，在近 18 个月后，该功能仍未合并，合并的可能性似乎越来越小。

P4TC 简介

内核的网络子系统中支持多种流量控制机制； tc-flower（流量分类器）可能是其中最常用的机制之一。Salim 提出的 P4TC 子系统符合该子系统，它增加了使用 P4 语言描述网络策略的能力。该子系统完全在软件中实现，并在内核中运行。

该软件实现是这项工作最初引起关注的首要方面之一。虽然可以在内核中进行复杂的网络处理和路由，但任何旨在跟上当前网络速度的实现都需要相当多的硬件支持。现在已经有厂商销售支持 P4 编程的网络硬件，P4TC 旨在支持这些硬件，但这种能力在补丁集中（或任何后续版本中）都不存在。Jiri Pirko 在对初始发布的回复中 询问了这个遗漏；Salim 回答 说，流量控制子系统需要一个软件实现来处理任何可以卸载到硬件的功能（从而确保该功能普遍可用），并且硬件卸载接口仍在考虑中。Daniel Borkmann 抱怨 说，没有人会使用软件实现，Salim 不同意 这种说法。

第一个帖子中另一个重要的评论来自 Stanislav Fomichev，他 建议，与其在内核中添加另一个包解析器，不如将 P4 程序编译成 BPF，然后可以在 BPF 验证器的保护下运行。Salim 接受了这个建议；P4TC 补丁的第二个版本 于 2023 年 6 月发布，其中包括对该 BPF 支持的早期实现。

越来越多的反对

P4TC 补丁集之后发布了多个版本，总体上很少受到审阅者的关注。版本 7 于 2023 年 10 月发布，移除了“RFC”标签，表明 Salim 认为它已准备好合并到主线（mainline，指主分支）中。版本 8 于 11 月发布，吸引了更多评论。John Fastabend 是第一个 提出 反对意见的人，而这种反对意见后来演变成持续的反对：补丁集添加的新 kfunc 实现的功能被认为与 BPF 映射提供的功能类似。一些 BPF 社区的成员认为这些 kfunc 至少也是不必要的重复代码，甚至可能算是对 kfunc 机制的滥用。

Fastabend 后来 提出了 一些其他的反对意见。他说，将 P4 集成到流量控制子系统中，可能会在多个方面影响性能。他认为，P4 可以直接编译成 BPF，而无需流量控制部分。他说，使用 netlink 来控制 P4TC 比将策略信息存储在 BPF 映射中更慢、更复杂。他还抱怨说，P4 的真正优势在于硬件卸载，但补丁集仍然没有支持与硬件的接口。在这些讨论中，Salim 试图解决针对这项工作的批评，有时表现出沮丧，经常坚持自己的意见。例如，使用 netlink 被 描述 为“不可协商”。

版本 10 在介绍信中添加了更多上下文，试图解释为什么做出某些决定，但 Fastabend 重申并扩展了 他对 版本 12（2 月发布）的反对意见。同样是对该版本的回复，网络维护者 Paolo Abeni 指出，虽然一些开发人员对这些补丁表示反对，但没有声音（除了 Salim）表达支持；他想知道硬件支持的缺乏是否可能是原因之一。Anjali Singhai 回答 说，英特尔和 AMD 都需要硬件卸载支持，但他们也需要一个标准的内核 API 来管理 P4 程序，以及一个内核管道来混合硬件和软件实现。“这个补丁集有助于创建一个软件管道和标准 API”。Chris Sommers 也 表达了支持，并列举了一长串理由，说明这对他的公司很有用。

版本 13（3 月下旬）获得了 Toke Høiland-Jørgensen 的 ACK（表示同意），但没有其他回复。版本 14（4 月初）反而获得了 BPF 维护者 Alexei Starovoitov 对 BPF 集成（尤其是使用 kfunc）的反对意见，从而导致他 明确的 NACK（表示不同意）。Borkmann 也添加了他的 NACK，之后 Fastabend 也 做出了类似的决定。

寻找前进的道路

Salim 坚持不懈，于 4 月中旬发布了 版本 16。Abeni 建议 删除 BPF 组件（并对系列进行重大重构）作为将这项工作移入内核的一种可能方式，这引起了 Salim 的 恼怒的回应，他认为自己不应该被要求删除 BPF 支持，因为自己是在响应现在反对者的评论后才添加的。他后来 表示：“我的观点是，这组 patch 哪怕有 NACK 也应该被合入，因为它完全位于 networking/TC 中（与 ebpf 无关）”。然而，Abeni 拒绝这么做。

5 月 21 日，Salim 回来了，他介绍了这项工作的历史，并要求“第三方调解人”介入调查情况并提出建议。他创建了 一个网页，描述了这项工作、提出的反对意见以及他对这些反对意见的回应。然而，调解人尚未确定，这种情况似乎不太可能改变。相反，像 Tom Herbert 这样的人开始 质疑 P4 的价值，网络维护者 Jakub Kicinski 表示：“该提交无论是技术上都不够强大，也不够实用，无法考虑做出推翻维护者的可疑先例”。

正如内核补丁争议性越来越大的情况一样，这里的一个基本问题是，子系统维护者的权限到底有多大。P4TC 补丁包含在流量控制子系统中，该子系统由 Jamal Hadi Salim（和其他一些人）维护。正如他多次指出的那样，这项工作/使用/了 BPF，但没有更改 BPF 子系统；他说，BPF 开发人员因此无权阻止它。

尽管有这种观点，这项工作似乎已被有效阻止，目前尚不清楚如何找到一个双方都能接受的解决方案。像 Sommers 这样的潜在用户已经 表达了他们对这种情况的失望，但这似乎并没有动摇那些反对 P4TC 的人。在这一点上，立场已经根深蒂固，很难看出如何协调它们。

全文完
LWN 文章遵循 CC BY-SA 4.0 许可协议。

欢迎分享、转载及基于现有协议再创作～

长按下面二维码关注，关注 LWN 深度文章以及开源社区的各种新近言论～