智能网卡系列三：P4语言的演进简述

作者简介：Anirudh Sivaraman是麻省理工学院计算机科学与人工智能实验室的研究生。他对计算机网络非常感兴趣，他最近的研究工作是可编程转发平面领域。

自从 P4 语言首次在 ACM CCR 文章中提出以来已经有一段时间了。在过去的时间里，该语言已经从提案演变为规范到现在广泛应用在智能网卡等领域。这篇博文捕捉了这种演变背后的一些想法：P4 中添加了哪些功能等。

这篇文章基于最近与Changhoon Kim，Ramkumar Krishnamurthy，Advait Dixit和Mihai Budiu共同撰写的一篇论文，该文章曾经发表在ACM SDN研究研讨会上。

最初提出的P4有几个核心概念，总结如下：

抽象的交换模型：从P4的角度来看，交换机应该是什么样的？抽象交换机模型指定交换机具有 P4 可编程解析器，后跟 P4 可编程入口管道，后跟固定流量管理器，后跟 P4 可编程出口管道。

首部信息：首部中的字段及其长度。例如：以太网报头具有 48b 源 MAC 地址字段、48b 目标 MAC 地址字段和 16b 以太网类型字段。

解析器：数据包中的标头如何排序，它们如何识别封装的内部标头？一个典型的示例是解析以太网标头，其 EtherType 将 IPv4 标识为下一个标头类型，其协议 ID 告诉我们下一个标头是 TCP。

表项和操作：交换机如何处理数据包？P4 基于 OpenFlow 的匹配操作表抽象构建，但允许对匹配和操作组件进行编程。match 键是标头字段的任意组合，包括（可能尚未定义的）用户定义的标头字段。这些操作是从一组对数据包字段（算术、读/写、比较、添加/删除字段）进行操作的操作基元构建的。

控制流图：哪些匹配操作表处理数据包，按什么顺序处理？例如，该图可以指定数据包在由 IP 路由表处理之前应由访问控制列表表处理。

P4交换机的抽象架构图

我们的开源 P4 开发环境由编译器和软件开关组成，用于编译和运行 P4 程序。在此开发环境中，我们使用 P4 来表示数据中心交换机的转发行为，其功能集（如下表所列）与当前的共享内存交换机相当：包括 VLAN、ACL、隧道和 ECMP。本练习的目的是使用数据包处理的常见示例（数据中心交换机的转发行为）实证评估 P4 的表现力。论文中使用的 P4 程序 DC.p4 可在 P4 github 存储库中找到，我们用它来说明 P4 的特定方面。

如图所示：描述P4语言的开发环境

这个练习给了我们几个教训。从积极的方面来说，从简单动作原语构建更大动作的前提是 DC.p4 中超过 90% 的动作是正确的。其次，我们观察到匹配操作表抽象对于大多数网络工程师来说是一种直观的抽象---主要是因为交换机实际上总是将数据包处理构建为一组表查找。

在业务处理流程中，我们还发现最初的 P4 提案无法表达某些类型的数据包处理。其中之一是等价多路径 （ECMP），这是一种在数据中心中使用的负载平衡机制，用于在一组候选传出链路之间分散流量。如果没有 ECMP，路由可以按如下方式工作：将匹配键视为目标地址，操作仅基于此键选择输出端口。但是，要实现 ECMP，没有从目标地址到输出端口的 1：1 映射。相反，ECMP 输出端口是根据给定流的 5 元组的哈希动态选择的。从 1：1 匹配操作映射转变为“一对一多”操作映射需要我们引入操作配置文件的概念。操作配置文件允许匹配键根据操作选择器从集中选择一个操作。在 ECMP 的情况下，此选择器是 5 元组的哈希。

我们还添加了一些新的动作原语;我们在这里总结其中最有趣的内容。数据包克隆允许我们复制数据包并将其发送到另一个端口（用于镜像等应用程序）或交换机 CPU。摘要生成从数据包中提取一组字段，将它们打包到摘要中，然后将它们发送给接收方。MAC 学习是众所周知的摘要生成用例。这些语言添加：动作配置文件、新的动作原语以及本文中更详细的几个内容现在是当前 P4 规范的一部分。

总的来说，我们发现 P4 达到了数据包处理的正确抽象级别。具体来说，操作标头字段不需要一点摆动。相反，标头中的字段通过定义的标头类型进行访问，编译器使用 P4 分析器规范自动生成数据包分析器。

但与此同时，仍有改进的余地。首先，P4对模块化的支持是有限的。目前，我们使用 include 指令将不同的 P4 代码片段分解为单独的 P4 文件。然后由 C 预处理器将它们拼接在一起，然后由 P4 解析。包含指令是一种相当弱的模块化形式：每个包含的 P4 文件都可以读/写任何其他包含的 P4 文件读/写的所有标头。其次，一些P4语义不精确。例如，当整数数据包字段溢出时会发生什么：它是环绕还是饱和？最后，尽管预计会添加新的操作原语，但它可能会因大量不透明的关键字而使语言膨胀，编译器无法推理---，因此无法优化。这也可能表明我们正在根据我们对一个特定目标架构的经验向 P4 添加基元;其中一些基元可能在其他目标上不可用，甚至无法实现。

为了应对这种添加新动作基元的趋势，我们首先注意到P4还可用于对交换机以外的网络设备的数据平面进行编程，例如网络接口卡，防火墙或接入点。这些网络设备（我们称之为数据包处理引擎 （PPE））在其底层数据包处理架构方面具有显著的多样性。反过来，这种多样性意味着，对于所有这些PPE来说，没有一个抽象的转换模型可能具有足够的表现力。

我们提出了一个简单的解决方案来解决这个问题：将抽象的交换机模型从语言中移出，并单独移动到单独的规范中，我们称之为PPE架构。PPE 架构指定可编程和固定功能块之间的互连（例如，可编程入口管道连接到固定调度程序，然后固定调度程序连接到可编程出口管道）。

为其设备提供 PPE 架构的供应商还可能包括一个供应商库，其中详细说明了该供应商专门提供的所有功能的输入-输出接口。必须添加到 P4 语言规范中的数据包克隆和摘要生成等操作原语现在可以成为供应商库的一部分，而供应商库又是特定供应商 PPE 的一部分。如果它们被证明是广泛使用的，它们最终可能会迁移到标准的 P4 库中。总的来说，将一些 P4 结构（如动作原语）移动到库组件中将简化语言核心。为了更详细地了解这个提案，我们向读者推荐Mihai Budiu在最近的P4研讨会上提出的关于该主题的胶片。

我们希望这篇文章能让您了解 P4 在过去一年中从提案到具体规范的演变。这篇论文的技术细节比我们希望在一篇文章中涵盖的要多得多。我们认为这种形式的P4程序实证分析在两个方面是有用的。一方面，它为语言设计提供了更严谨的基础。另一方面，它允许我们对最常用的动作基元进行编目，为开关设计人员设计可编程硬件提供有用的反馈。我们鼓励您编译、运行和扩展 DC.p4，并通过为其他数据包处理应用程序编写 P4 程序来参与正在进行的讨论。