PISCES: A Programmable, Protocol-Independent Software Switch

摘要

PISCES，一个不局限于特定协议的软件交换机，能够轻松地添加新的功能，与OVS性能相近，改变源代码的效率比OVS高。

1 介绍

很少例外，每一个去往或来自VM的数据包都要经过一个软件交换机。服务器在这个环境里数量超过物理交换机。因此，一个有很多服务器的数据中心也会有很多软件交换机，并多于物理交换机，虚拟端口多余物理端口。

软件交换机可以支持新的封装，可以改善故障排除功能、可以调试以排除故障，可以提供类似中间盒的功能：负载均衡、地址虚拟化和加密等。

但是修改代码很难，需要专业知识。

更改软件交换机转发数据包的方式不应该需要了解交换机的实现方式。相反，应该可以在特定于域的语言（DSL）中指定自定义网络协议，例如P4 [10]，然后将其编译为管理程序交换机的自定义代码。

底层交换机应当是“协议无关”的，在接收有关数据包处理的指令之前，不知道协议是什么。

在DSL中编写的程序指定要解析的数据包包头和匹配操作表的结构。

需要在交换机中编译这些DSL代码，对于固定的协议是可手写的，协议的编译过程可能降低底层设施的效率，增加性能开销。硬件交换机编译过程提供的是有限的资源，在有限资源下提供空间、延迟、能量的优化，而软件交换机则不同。本文的目标是：（1）量化在DSL中表达自定义协议的额外成本，（2）设计与评估在特定领域的编译器的优化，以尽可能减少性能开销。最后，我们通过适当的编译器优化证明了独立于协议的软件交换机的性能——这是一种支持高级DSL的自定义协议规范的交换机，无需直接修改低级源码，可与本机管理程序切换。我们的结果证明了“可编译性成本”在管理程序交换机中可以忽略不计。我们期望我们的结果将激发新的独立于协议的软件交换机的开发。（ovs并非旨在支持协议独立性）。

我们有以下贡献：

PISCES的设计和部署，是第一个可以支持在高级DSL中进行自定义协议规范的软件交换机，无需直接修改交换机源代码。
一个公用的开源的PISCES的代码，在GitHub上，这个部署是一个独立于协议的，源于OVS的软件交换机，来自高级DSL。
特定于域的优化和后端优化器，降低使用P4自定义OVS的性能开销。
评估PISCES代码复杂性及其转发性能，复杂性比OVS减小40倍，仅多产生2%的性能开销。

2 对独立于协议的交换机的需求

PISCES是一个独立于协议的软件交换机，因为它在程序员指定它之前，不知道协议是什么，不知道如何代表协议处理数据包。例如，如果想用PISCES处理一个IPV4数据包，我们需要描述如何在P4程序中处理IPV4数据包。在一个P4程序中（例如，IPv4.p4），我们需要描述IPV4数据包包头的格式、字段、校验和、flags等等。我们还需要指定我们使用的用来存储IPV4前缀的查找表，该表用来搜索最长匹配前缀。我们还需要描述如何减少一个TTL，校验和如何更新等。P4程序捕获整个流经管道的数据包，该管道被OVS的源码编译，用于指定交换机的匹配、操作和解析功能。

一个独立于协议的交换机的好处：

添加新的标准或专用协议头。供应商在所有时间提供新的协议头，特别是对于数据中心。在近几年，VXLAN、NVGRE、Geneve已经被标准化了，STT和NSH也被作为潜在的标准被讨论。私有的、专用的协议也被添加，来提供竞争优势，通过创建程序之间更好的隔离或通过引入新的拥塞标记来提供竞争优势。在很多情况下，在一个新的协议被使用之前，所有的硬件和软件交换机必须被更新来重新识别包头并正确处理它们。对于硬件交换机，如果供应商同意添加该功能，数据中心所有者必须向其芯片供应商提供要求并等待三到四年才能到达新功能。对于软件交换机，它们只需要等待下一个主要的修订、测试和部署周期。即使修改开源的软件交换机也不是万能的，因为一旦数据中心所有者直接修改开源软件交换机以添加自己的自定义协议，这些修改仍需要维护并与主代码库同步。一个可以添加一个新的协议到一个P4程序中的数据中心拥有者，可以更快地编译和部署一个新的协议。

移除标准协议包头。数据中心网络通常比传统的园区网络和企业网络运行更少的协议，部分原因是大多数流量是机器到机器，并且不需要许多传统协议（例如，多播，RSVP，L2-learning）。例如，亚马逊网络服务（AWS）仅使用IPV4转发数据包。因此，有利于数据中心所有者完全删除未使用的协议，从而消除了与传统协议的默认部署的任何交互和影响。支持许多协议并不哈皮，更糟糕的是必须了解操作者不打算使用的协议的交互和影响。因此，数据中心所有者经常希望从其交换机、NICs和操作系统中删除未使用的协议。从传统的交换机中删除协议很难，对于硬件，这意味着要等待新的芯片，对于软件这意味着要对大型代码进行操作，来提取特定的协议。在PISCES中，删除未使用的协议就像删除协议规范的未使用部分并重新编译交换机源代码一样简单。（第5.2.2节显示了这甚至可以提高性能。）

增加更好的可见性。理解网络行为和操作条件变得很重要。失败可能导致巨大的收入损视，随着网络越来越大，越来越复杂，调试时间越来越长，人们越来越关注如何更容易地看到网络在做什么。提高网络的可见性可能需要支持新的统计数据，生成新的探测数据包，或者添加新的协议和操作来收集交换机状态。用户希望了解队列的演变情况，延迟是否有所不同，隧道是否正确中止以及链路是否仍在运行。通常，在紧急情况下，用户希望快速地添加可视功能，让它们准备好部署或者能够快速修改转发和监视逻辑，从而减少诊断时间和修复网络中断时间。

添加新的功能。如果用户和网络拥有者可以修改转发行为，甚至可以添加全新的行为。例如，随着时间的推移，我们可以期望交换机来实现更复杂的路由，例如路径利用感知路由，新的拥塞控制机制，源控制路由，新的负载平衡算法，减轻DDos算法，以及新的虚拟到物理的网管功能。如果一个网络拥有者可以更新架构来获得更高的利用率和更多的控制，那么他们将知道如何实现更复杂的路由。鉴于在像P4这样的DSL中升级程序的方法是向交换机中添加新功能，我们可以期望网络所有者更快地改进他们的网络。

3 背景

PISCES是一种软件交换机，其转发行为是使用特定于域的语言指定的。 PISCES基于Open vSwitch（OVS）的软件交换机，使用P4的特定语言进行配置。

特定域语言P4：P4是一个特定于域的语言，表示网络转发元素的管道应该如何使用图1所示的抽象转发模型处理数据包。在这个模型中，每个数据包首先通过一个可编程解析器来提取头部信息。P4程序指定每个可能的包头的结构以及表示顺序和依赖关系的解析图。然后，数据包通过一系列匹配动作表（MAT）。P4程序指定每个MAT可以匹配的字段以及它们之间的控制流，以及每个表允许操作的范围。在交换机转发分组时，控制器可以使用符合P4程序规范的特定匹配动作规则来添加、移除和修改表条目。最后，一个逆解析（deparser）将头字段写回数据包，再将其发送出适当的端口。

我们选择P4，是因为它的交换机抽象模型类似于OpenFlow（OVS中的内置语言），允许我们在有和没有P4前端的情况下制定简单的对等的OVS。我们考虑了其他的替代品，例如在Berkeley Extensible Software Switch（BESS）中使用的Click，它允许比匹配动作处理更丰富的计算。但是，就我们的目的而言，P4足已完成。有一个共同的方法来表达网络中所有“管道”交换机的转发，并且可从一个移植到另一个。因此，使用相同的语言对这些实验有意义。

软件交换机OVS：OVS是一个在数据中心中广泛使用的在虚拟机管理程序内运行的软件交换机。在这样的环境中，OVS将虚拟接口之间的数据包切换到虚拟机和物理端口。OVS实现了通用的协议，例如以太网、GRE和IPV4，以及数据中心的新协议，如VXLAN Group Based Policy（GBP）扩展，Geneve，NVGRE和用于虚拟网络覆盖的STT。

OVS虚拟交换机有两个重要部分，被称为慢路径和快路径（即，数据路径），就像图2所示。慢路径是用户空间程序，提供了OVS的大部分智能。快路径充当缓冲层，仅包含实现最高性能所需要的代码。值得注意的是，快速路径必须将导致高速缓存未命中的任何分组传递到慢速路径以获得用于进一步处理的指令。OVS包括一个单独的轻便的慢路径和多重的快路径：一个基于Linux内核模块，另一个基于Windows内核模块，另一个基于英特尔DPDK用户转发。DPDK快速路径产生最高性能，因此将DPDK运用到我们的工作中。

作为SDN交换机，OVS依赖于来自控制器的指令来确定其行为，特别是使用OpenFlow协议。OpenFlow根据匹配操作表的集合指定行为，每个匹配操作表包含许多称为流的条目。相反，一个流包括匹配、包头和元数据，指示交换机在匹配评估为真时要做什么动作，以及数据优先级。当数据包到达特定的匹配操作表时，交换机会找到匹配的流并执行其操作;如果多个流与数据包匹配，则优先级最高的流优先。

完全按照上述方式实现行为的软件交换机无法实现高性能，因为OpenFlow数据包经常通过几个匹配操作表，每个表都需要通用的数据包分类。因此，OVS依靠缓存来实现良好的转发性能。主要的OVS缓存是它的megaflow缓存，结构很像OpenFlow表。Megaflow缓存背后的想法是，理论上可以通过计算其交叉产品来组合数据包访问的所有匹配操作表，同时遍历OpenFlow管道到单个表中。然而，这是不可行的，因为k表与n1,…,nk规则的交叉成绩可能具有n1*…*nk个规则，megaflow缓存功能有点像缓慢计算的交叉产品：当数据包到达时，与任何现有的megaflow缓存条目不匹配时，慢速路径会计算一个新条目，该条目与理论交叉产品中的一行相对应，并将其插入缓存中。OVS使用许多技术来提高缓存性能和命中率。

当数据包在megaflow缓存中命中时，交换机可以比从快速路径到缓存未命中所需的慢速路径的往返行程快得多地处理它。然而，作为通用分组分类步骤，兆高速缓存查找仍然具有显著成本。因此，OVS快速路径的实现还包括微流缓存——一个从数据包五元组映射到兆字节缓存条目的哈希表。微流缓存查找的结果只能是一个提示，因为megaflow通常匹配更多的字段而不仅仅是五元组，因此微流缓存条目最多可以指向最可能的匹配。因此，快速路径必须验证megaflow缓存条目确实与数据包匹配。如果匹配，则查找成本仅是单个hash查找的成本，这种成本比一般数据包分类便宜得多，因此，对于具有相对长且稳定的数据包流的流量模式来说，它是一个重要的优化。如果不匹配，则数据包继续通过一般的megaflow缓存查找过程，跳过以检查过的部分。

4 PISCES原型

我们PISCES的原型是OVS的修改版本，其解析、匹配、操作代码都由我们P4编译器的C代码替换。工作流程如下：首先，程序员创建一个P4程序，使用PISCES版本的P4编译器为OVS生成新的解析。其次，OVS使用一般的C解析器被解析，创建一个依赖于协议的交换机，该交换机按照P4程序中的描述处理数据包，为了修改协议，用户可以修改P4程序，该程序编译为一个新的二进制虚拟管理交换机。

我们使用OVS作为PISCES的基础，是因为它被广泛地使用，并包含一些可编程交换机的基本材料，因此我们只关注需要定制的交换机部分（即，解析、匹配、操作）。代码结构良好，可以修改，并且测试环境已经存在。它同样支持一些基础比较：可以将原有OVS代码行数与PISCES的P4程序进行比较，也可以比较它们的性能。

4.1 PISCES中P4-to-OVS编译器

P4编译器有两个方面：一个前端（将P4代码转化成一个与目标无关的中间IR表示），一个后端（将IR映射到目标）。在我们的例子中，后端通过操作IR来优化CPU时间、延迟或者其他目标，然后生成替换OVS中的解析、匹配和操作代码的C代码，如图3所示。P4-to-OVS编译器输出C源代码，实现编译相应交换机可执行文件所需要的一切。编译过程还生成一个独立的类型检查程序，可执行程序使用该程序来确保来自控制器的任何运行时配置指令（例如，插入流规则），符合P4程序中指定的协议。

解析（Parse）：替换原始OVS解析器的C代码是通过替换struct flow产生的，struct flow是OVS用来跟踪协议头信息的C结构，包含P4程序指定的每个字段的成员，可以生成代码以从数据包中提取头字段写入struct flow。

匹配（Match）：OVS使用一个通用的分配器数据结构，基于元组空间搜索，来实施匹配。为了实现自定义的匹配，我们不需要修改数据结构或者代码来管理它们。相反，控制平面可以简单地在运行时使用新的数据包头领域填充到分类器中，从而自动使这些域在数据包匹配时可用。

行动（Action）：我们解析器的后端支持自定义的操作，通过自动地生成我们编译为OVS二进制文件的代码。自定义操作可以在OVS慢速路径或快速路径中被实施。编译器确定特定的一个操作在何处运行，以确保交换机有效地执行操作。某些动作（例如，设置字段）可以在任一组件中执行。程序员可以向编译器提供关于动作的慢路径或者快路径实现是否是最合适的。

控制流（control flow）：在一个交换机中，一个数据包的控制流是数据包遍历的匹配操作表序列。对于P4，控制流必须在运行时指定，OVS控制流通过流条目在运行时指定，这使它更加灵活。

优化IR：编译器后端包含一个用于检查和修改IR的优化器，以便生成高性能的C代码。例如，P4程序可能包含完整的IP校验和，但是优化器可以将此操作转化为增量IP校验和，以使其更快。编译器还对IR执行数据流分析，允许它合并并专门化C代码。优化器还决定数据包处理管道中何时何地编辑数据包头。一些硬件交换机推迟编辑直到管道结束，而软件交换机通常在管道的每个阶段编辑标题。如果有必要，优化器会转换IR以进行内联编辑。

与其他P4编译器一样，P4-to-OVS编译器也为匹配操作表生成API，并扩展OVS命令行工具以使用新字段。

4.2 对OVS的修改

我们需要对OVS做三个修改来使它实现任何P4程序中描述的转发行为。

任意封装和解封装。OVS不支持P4程序可能需要的任意封装和解封装。每个OVS快速路径为各种固定形式的封装提供定制支持。例如，Linux内核快速路径和DPDK快速路径，每个分别实现GRE、VXLAN、STT和其他的一些封装。封装和解封装一个数据包所需要的元数据是被静态配置的。交换机使用一个数据包的输入端口来将它映射到一个合适的隧道中，在出口处，数据包基于此静态隧道配置，被封装子在相应的IP报头中。因此，我们向OVS添加了两个新的原语，添加add_header()和remove_header()，分别执行封装和解封装，并在快速路径中执行这些操作。

基于对数据包头的比较的条件。OpenFlow仅支持对头字段按位相等的性测试，用于将K位字段与常量进行比较的关系测试（例如，<和>）,可以表示为使用按位相等匹配的最多k个规则。两个k比特字段之间的关系测试，例如x<y，需要k(k+1)/2这样的规则。为了同时测试分别采用n1和n2规则的两个这样的条件，需要n1*n2个规则。P4直接支持这样的测试，但是在OpenFlow中以这种方式实现太贵了，所以我们在OVS中添加了对它们的直接支持作为条件操作，这是OpenFlow操作中的一种“if”语句。例如，我们的扩展允许P4编译器发出“If x < y, go to table2, otherwise go to table 3.”的形式的操作。

通用校验和验证/更新。IP路由器应该在入口处验证校验和，并在出口处重新计算，大多数硬件交换机都是这么做的。软件交换机通常会在入口处跳过校验和验证来减少CPU周期，它只在更改任何字段（如，TTL）时逐步更新校验和。目前，OVS仅支持增量校验和，但是我们希望以程序员预期的方式支持校验和的其他用途。因此，我们添加了增量校验和的优化（4.3节）。该优化是否有效取决于P4交换机是作为转发元素还是作为给定数据包的终端主机——如果是终端主机，则必须验证校验和，因此它需要P4程序员进行注释。

4.3 编译器的后端优化

软件交换机的两个方面最终会影响转发性能：（1）快速路径处理每个数据包的成本（增加100个周期会使交换机的吞吐量降低约500Mbps）（2）发送到慢路径的数据包数量，周期是处理数据包的快速路径的50倍。表1列出了我们已经实现的优化，以及优化是否减少了到慢速路径、快速路径的CPU周期或者行程。

内联编辑VS后期管道编辑。OVS快速路径执行内联编辑，立即应用数据包修改（慢速路径做一些简单的优化来防止冗余或不必要的修改）。如果修改、删除或者插入了许多字段，动态迁移和调整分组数据大小会变得昂贵。相反，在处理包头之前延迟编辑可能更有效（如硬件交换机通常使用的那样）。优化器分析IR以确定可能需要在管道中修改数据包的次数。如果该值低于某个阈值，则优化程序执行内联编辑，否则执行后期管道编辑。我们允许程序员使用pragma命令覆盖此启发式算法。

增量校验和。通过根据诸如P4的高级程序描述表达校验和操作，程序员可以向编译器提供必要的上下文信息，以更有效地实现校验和。例如，程序员可以通过注释通知编译器每个数据包的校验和可以递增计算。然后，优化程序可以执行数据流分析来确定哪个数据包头改变，从而使校验和的重新计算更有效。

解析器专业化。独立于协议的软件交换机可以优化数据包解析器的实现，因为定制的数据包处理管道（如P4等高级语言中所指定的）提供了有关数据包中那些字段被修改或者使用的特定信息。例如，不基于其他层的信息做出转发决定的第二层交换机可以避免在这些层处解析分组包头字段，以高级语言指定转发行为为编译器提供了可用于优化解析器的信息。

行动专业化。OVS快速路径中的内联编辑操作将相关字段联系在一起，这些字段通常同时设置。例如，OVS实现单个快速路径操作，该操作设置IPV4源，目的地、服务种类和TTL数值。当同时有多个字段要被更新世，这是有效的，如果只更新一个字段，则边际成本很低。IPV4有许多其他字段，但快速路径不能设置其中任何一个。

OVS这方面的设计需要领域的专业只是，设计者需要知道那些领域对于能够改变的快速路径是重要的。P4编译器不具备将哪些字段组合在一起的专业知识，从而产生将太少或太多字段分组到单个操作中的可能成本。幸运的是，匹配操作控制流的高级P4程序允许优化器识别和消除在快速路径集动作中的冗余检查，使用死代码消除等优化。这样，优化器仅检查将在匹配操作控制流中实际设置地集合操作中的那些字段。

行动合并。通过分析P4程序中的控制流和匹配动作处理，编译器可以发现哪个域被修改，可以生成一个有效的单个动作来直接更新这些字段。因此，如果规则修改了两个字段，优化程序仅在OVS中安装一个操作。

缓存字段修改。网络协议数据平面很少需要对头字段进行算术运算，TTL递减操作是最明显的反例，上面已经讨论过的校验和是另一个。因此，OVS快速路径没有包括通用算术运算。事实上，它们也不包括特殊用途的TTL减量操作。相反，为了实现特殊用途的OpenFlow动作来递减TTL，慢速路径依赖于来自给定源大多数分组具有相同TTL的事实，因此，会发出一个缓存条目，该条目匹配它证字啊转发的数据包中观察到的TTL值，并用比观察值小1的值覆盖该值，我们称之为“匹配和设置”。对于TTL减量，这解决方案是可以接受的，因为OVS设计人员知道以这种方式缓存会在实践中产生很高的命中率。

匹配和设置并不总是合适的。考虑到某些其他IP域的IPV4和IPV6校验和的变化，使用匹配和设置方法，缓存条目必须匹配每个有助于校验和的字段，即每个IP字段，这将使缓存条目的命中率几乎降低到0。对于P4支持的更简单的算术运算也是如此。例如，递增或递减字段值，并且最终PISCES无法知道匹配和设置在给定情况下是否适合。

PISCES采用的解决方案，是为了在它可以的时候阻止匹配和设置，通过自动地生成快速路径操作来实现P4程序需要的算术运算。例如，如果程序递增特定的字段，则PISCES生成快速路径操作以递增该字段。当P4程序“盲目地”执行算术运算时，这是有效的，而不会在修改的字段上进行匹配。如果程序匹配它，那么，遵循通常的缓存规则，缓存条目必须匹配字段，因此需要匹配和设置方法。

舞台作业。 OVS实现分阶段查找以减少到慢速路径的次数。分阶段查找将字段划分为一个有序的组列表，称为阶段。这些阶段是累积的，因此第一阶段之后的每个阶段都包含前一阶段的所有字段以及其他字段。最后阶段包含每个领域。 OVS在其元组空间搜索分类器中将每个阶段实现为单独的哈希表。分类器查找按顺序搜索这些阶段中的每一个。如果任何搜索不匹配，则整个搜索终止，并且只有最后一个阶段中包含的字段必须在缓存条目中匹配。

OVS使用有四个阶段：（1）元数据字段（例如数据包入口端口）（2）元数据和第二层字段（3）第三层字段（4）包括所有字段（元数据，第二、三、四层字段）。该顺序基于以下的原则：当他们的顺序对应于在网络中观察到的字段值的上的增序时，阶段是最有效率的。例如，在常见情况下，仅与元数据匹配的缓存条目可能具有比仅与第四层字段匹配的缓存条目更高的命中率，因此元数据首先出现在较早的阶段（第一阶段）而不是第四层的领域（最后阶段）。

分阶段查找可以推广到任意P4程序。这个顺序无法从P4程序中被推断出，所以PISCES需要帮助才能选择合适的阶段。我们扩充了P4语言，使用户能够使用阶段号来注释每个包头，阶段数与包头数相同。

5 评估

我们将PISCES虚拟软件交换机的复杂性和性能与等效的OVS本机数据包处理进行了比较，我们将得到的程序在两个维度进行比较：（1）复杂性，包括开发和部署、维护的复杂性（2）性能，通过比较PISCES的数据包转发性能和相同的本机OVS性能。

5.1 复杂性

复杂性表示可以轻松修改程序以修复缺陷，来满足新要求，简化未来维护或应对软件环境的变化。我们评估两类复杂性：（1）为一个软件交换机开发基线特征的复杂性（2）改变维护现有软件交换机的复杂性。

5.1.1 开发复杂性

我们使用三种不同的元素评估开发复杂性：代码行数、方法数、平均方法大小。我们只需要通过计算换行符号和方法数来计算代码行数，通过计算每个程序中子程序的数量，使用ctags [33]进行测量。最后，我们按照方法的数量划分代码行，以平均方法大小。较高的平均值可能表明（某些）方法过于冗长或复杂。

编写编译器是一次性成本。虽然开发人员经常更新他们的P4程序，但编译器的更改频率更低 - 通常是在P4语言规范发生变化时。对于PISCES，我们编写了大约1,000行代码来将P4编译到C代码，以及额外的1,700行代码来扩展本机OVS以合并生成的C代码。

ovs.p4 [1]包含OVS当前支持的头，解析器和操作的表示。 OVS中的大部分代码都超出了P4的范围，因此我们的度量标准仅包括负责协议定义和头解析的文件。表2总结了本机OVS头字段和解析器实现的每个度量标准，P4.3中的等效逻辑PISCES将代码行减少了大约40倍，平均方法大小减少了大约20倍

5.1.2更改复杂性

为了评估在PISCES中维护协议独立软件交换机的复杂性，我们比较了在OVS和P4中已经支持的协议中添加对新头字段的支持所需的工作量。表3显示了我们对添加对三个字段的支持的更改的分析：（1）连接标签，连接跟踪接口的128位自定义元数据; （2）隧道OAM标志，许多网络工具使用它来区分测试数据包和实际流量; （3）TCP标志，一种修改，增加了对解析所有TCP标志的支持。表3显示了基于公共Open vSwitch提交对OVS的更改。这些数字是保守的，因为它们只包含对三个OVS快速路径实现之一的更改。

结果表明，在单个P4文件中仅修改几行代码足以支持新字段，而在OVS中，相应的更改通常需要对数十个文件进行数百行更改。除了其他更改之外，还必须将字段添加到struct flow，在全局表中描述字段的属性，在慢速路径中为字段实现解析器，以及在一个或多个快速路径中单独实现解析器。

5.2转发性能

在本节中，我们比较OVS和PISCES数据包转发性能。

5.2.1实验设置和评估指标

图4显示了用于评估PISCES转发性能的设置拓扑。我们使用三台PowerEdge R730xd服务器和两台8核16线程Intel Xeon E5-2640 v3 2.6GHz CPU运行Proxmox虚拟环境[59]，这是一个使用虚拟交换机连接虚拟机的开源服务器虚拟化平台，使用Proxmox内核版本4.2.6-1-pve。我们的每台机器都配备一个双端口和一个四端口Intel X710 10 Gbps NIC。我们使用MoonGen [20]配置两台这样的机器，在10 Gbps接口中的三个[64]上以1488万包/秒（Mpps）全线速率发送最小尺寸的64字节帧，而其他接口未被使用。我们将这六个接口连接到第三台机器，即被测设备，为PISCES发送总共60 Gbps的流量以进行转发。

我们考虑吞吐量和每秒数据包来比较PISCES和OVS的转发性能，使用MoonGen数据包生成器为我们的实验生成测试流量。我们使用六个轮询模式驱动程序（PMD）线程配置PISCES和OVS-每个10 Gbps接口一个 - 在运行到完成（RTC）模型[35]。每个线程在一个独立的CPU核心上运行，该CPU核心连接到机器上的一个非统一内存访问（NUMA）[45]节点。为了进一步了解性能瓶颈，我们使用机器的时间戳计数器（TSC）来测量各种数据包处理操作（即解析器，兆高速缓存查找和操作）使用的CPU周期数。报告CPU周期时，我们报告在实验运行中转发的所有数据包的每个数据包的平均CPU周期;每次运行持续30秒，进入率为89.28 Mpps。

校准OVS以实现性能比较。为了更准确地测量后续实验中OVS和PISCES的解析成本，我们首先建立OVS性能的基线，并使用最小的解析功能。为了最大限度地降低解析成本，我们禁用解析器，解析器通常解析一组全面的固定头，以便它只报告输入端口。在此更改之后，我们通过交换机发送测试流量使用一个简单的流表来匹配端口1上进入的每个数据包并将其发送到端口2.

我们测量了这个经过修改的OVS的性能。图5a和5b显示了我们的设置通过OVS实现的最大吞吐量，有和没有微流缓存，用于60-Gbps流量。对于64字节数据包，禁用微流缓存可将性能降低约35％，因为OVS megaflow缓存中的查找消耗的频率是微流缓存的五倍（表4）。对于小数据包，OVS交换机在查找时受CPU限制;因此，在这种操作方案中，微流缓存的好处是显而易见的。

考虑到这种校准，对于本章的其余部分，我们使用OVS的转发性能，禁用微流缓存作为我们与PISCES性能比较的基础。我们禁用微流高速缓存是因为它依赖于匹配数据包的五元组的散列，大多数NIC（网络接口）可以直接在硬件中进行计算。尽管OVS的微流缓存显着提高了其转发性能，但此功能依赖于协议相关的功能（具体而言，该数据包首先具有五元组）。因为我们的目标是评估协议独立交换机的转发速率，所以我们禁用了OVS的微流缓存，以便我们可以将PISCES（一种独立于协议的交换机）与没有协议相关优化的OVS版本进行比较。将PISCES性能与OVS的性能进行比较并禁用微流缓存因此提供了更多的性能比较，尽管它使得难以解释性能与“真实的Open vSwitch”。我们期望在PISCES中实现微流缓存，通过为要散列的字段添加P4注释，然后在软件中对它们进行散列，可以恢复大部分性能。

5.2.2端到端性能

我们接下来测量OVS和PISCES的实际网络应用的转发性能。这种评估清晰地说明了可编程性的端到端性能成本。我们选择一个现实且相对复杂的应用程序，其中两个交换机实现都提供所有数据包处理功能，以便在实际网络设置中提供公平的PISCES性能比较。

图7显示了这个应用程序，我们称之为“L2L3-ACL”。它执行以下操作：

•解析以太网，VLAN，IP，TCP和UDP协议。

•执行VLAN封装和解封装。

•执行控制流和匹配操作，如图7所示，实现访问控制列表（ACL）。

•设置以太网源，目标，类型和VLAN字段。

•减少IP的TTL值。

•更新IP校验和。

表5显示了此应用程序的转发性能结果。在我们应用所有编译器优化之后，最重要的行是最后两行，它们显示了OVS和PISCES之间的“底线”比较。这些结果表明，每个数据包的平均CPU周期数和所有编译器优化的PISCES平均吞吐量都与禁用微流缓存的OVS相当：每个数据包平均需要400个CPU周期，并且都实现了吞吐量刚刚超过13 Gbps - 性能开销不到2％。图6表明，该结果也适用于更大的数据包大小。在所有情况下，在其编译器中启用编译器优化的PISCES实现了与OVS相当的性能。

接下来，我们将更详细地讨论每个编译器优化在此端到端应用程序中实现的性能优势。

单独的编译器优化。 P4支持后期管道编辑，因此我们首先使用后期管道编辑来编译L2L3-ACL。 PISCES需要平均737个循环来处理64字节的数据包。数据包解析和快速路径操作主要负责这些额外的CPU流程。正如我们的微基准测试所示（第5.2.3节），如果对数据包的调整次数少于8次，则使用内联编辑模式可提供更好的转发性能。基于这种洞察力，P4编译器的PISCES版本使用内联编辑，这将解析器所控制的周期数减少了约56％。但是，快速路径动作的周期略有增加（仍然比OVS多255个周期）。

接下来，我们介绍增量校验和更新，以减少快速路径操作所消耗的周期数。唯一被修改的IP字段是TTL，但P4抽象模型支持的完整校验和验证和更新设计在入口处运行一次整个标头的校验和。对于我们的P4程序，我们指定我们要使用增量校验和。使用这些知识，而不是在所有头字段上重新计算校验和，使用P4程序（MAT和控制流）上的数据流分析，P4编译器确定管道仅修改TTL并仅使用该字段调整校验和，这减少了周期数受快速通道行动的影响为59.7％，显着改善。但是，PISCES仍然比OVS多消耗23.24个周期。

为了进一步提高性能，我们应用了动作特殊化和合并以及解析器专业化（第4.3节）。这使得PISCES每个数据包消耗的周期数达到425.82。

解析器专业化。独立于协议的交换机只需要解析程序员定义的协议的数据包头字段。 PISCES中的编译器可以进一步优化解析器，以仅解析交换机处理数据包所需的头字段。为了评估此专业化的潜在好处，我们使用L2L3-ACL程序的两个子集重复我们的端到端性能评估：“L2L3”程序，它不执行ACL功能，以及“L2”程序，它操纵以太网和VLAN标头并执行VLAN封装，但不解析任何IP标头或减少TTL（因此不更新IP校验和）。根据图7中原始“L2L3-ACL”基准程序的控制流程，“L2L3”程序删除了深灰色ACL表，“L2”程序另外删除了浅灰色Routable和路由表。

表6比较了这两个程序的OVS和PISCES的转发性能。对于L2L3，PISCES每个数据包比OVS消耗多四个周期。但是，PISCES的解析速度更快：与L2L3-ACL相比，L2L3中的解析大约每个数据包的七个周期更便宜。 OVS使用固定的解析器，因此其成本保持不变。解析器专门化消除了解析器中未在控制流中使用的字段的冗余解析（即，TCP和UDP报头）。由于OVS不是先验地知道控制流和MAT结构，因此其解析器无法实现相同的特化。对于L2应用程序，解析器可以进一步专门化，因为它只需要解析以太网头。在这种情况下，PISCES实际上可以比协议相关的交换机更快地处理数据包。

5.2.3微观标记

我们现在评估PISCES各个组成部分的表现。我们专注于解析器和操作，这些解析器和操作应用于每个传入的数据包，并对性能产生最大的影响。我们现在测试解析器和操作中复杂性的增加如何影响PISCES的整体性能。

解析器性能。图8a显示了对于后编辑和内联编辑模式，P4程序解析附加协议时每个数据包周期计数的增加情况。为了仅解析以太网报头，解析器在其他模式下消耗大约20个周期。当我们引入新协议时，循环计数会增加，对于后期管道编辑会更快，交换机会为快速路径操作创建协议标头的额外副本。对于图8a中最大的协议组合，解析器需要大约133个周期（几乎是简单处理以太网帧的周期的六倍）以用于管道后编辑，并且需要54个周期用于内联编辑。图8b示出了在解析器中添加每个新协议后吞吐量如何降低。对于60 Gbps的输入流量，流水线编辑时切换吞吐量从51.1 Gbps降至33.2 Gbps约35％，对于内联编辑约为24％，从52.4 Gbps降至40.0 Gbps。

快速路径动作性能。在性能方面，虚拟交换机中的主要动作是set-field（或modify-field）动作，换句话说，是写动作。图9显示了每个数据包的成本，以周期为单位，因为我们增加了后期和内联编辑模式的快速路径中的设置字段操作数。在后编辑模式下，我们将更改应用于标头字段的副本（从数据包中提取），并在管道的末尾执行“deparse”操作，将更改写回数据包。 “deparse”栏显示即使没有模拟字段，deparsing也会消耗大约99个周期，而在这种情况下，内联编辑没有成本。随着写入次数的增加，两种模式之间的性能差异变窄。对于16次写入，这种差异比单次写入少20个周期。但是，在这两种情况下，循环次数都会增加。对于后编辑案例，16次写入消耗354个周期，约为单次写入的3.6倍;对于内联编辑，16次写入消耗319个周期，或者比单次写入多大约5.6倍。

我们还测量了每个数据包的周期数，用于添加或删除标头。图10和图11分别显示了在后管道和内联编辑模式下越来越多的add-header和remove-header动作的每个数据包周期。

对于add-header动作，对于内联编辑模式，每个新动作的循环次数加倍。这是因为这些操作直接应用于数据包，每次调整数据包大小。相比之下，管道后编辑在“deparse”操作中仅调整一次数据包大小，因此剩余的周期数仍然存在几乎不变。对于单个add-header操作，后编辑成本较高，但对于四个或更多操作，内联编辑模式的成本更高。对于16个add-header操作，内联编辑每个数据包比后续管道编辑多消耗577个周期。

我们观察到remove-header动作的类似趋势。还有一个问题：随着删除标头操作的数量增加，管道后编辑的成本实际上略有下降，因为随着数据包收缩，需要在数据包中调整更少的字节。随着我们将删除标头操作的数量从1增加到16，每个数据包的周期数减少了约21％。这导致我们遵循以下经验法则：对于少于8个数据包大小的调整（即添加和删除标题操作），编译器使用内联编辑;否则，它应用管道后编辑，因为解析器生成解析的包头的副本所需的增加的周期数被内联编辑模式中的添加/删除头操作所需的周期数所抵消。

慢速路径转发性能。当OVS必须将所有数据包发送到慢速路径时，处理单个数据包平均需要大约3,500个循环（大约是微流缓存命中所产生的循环的50倍）。在这种情况下，无论数据包大小如何，最大数据包转发速率约为0.66 Mpps。慢速路径处理的每个数据包周期计数用于将每个数据包发送到同一输出端口的最简单程序。大多数真正的数据包处理程序需要更多的周期。例如，对于L2L3-ACL程序，慢速路径处理需要每个数据包30,000到60,000个CPU周期。这些性能数字表明了我们在4.3节中描述的megaflow缓存优化的重要性，以减少到慢速路径的数量。显然，到慢速路径的次数取决于实际的流量组合（因为这会影响megaflow缓存中的缓存命中率），因此很难说明这些优化的好处的一般结果，但计算减速由于缓存未命中很简单。

控制流。 OVS中的控制流以及因此在PISCES中的控制流在慢速路径中实现。它具有较小的一次性成本，在每个新流程的设置中，通常不可能与慢速路径性能分离。

6相关工作

PISCES协议和数据包处理功能可以使用高级域特定语言进行数据包处理。尽管PISCES使用P4作为其高级语言而OVS作为其软件交换机，但以前的工作已经开发了用于数据包处理和虚拟软件交换的特定于域的语言，其中我们的方法实现了协议独立性和从DSL到软件交换机也可以应用。

用于数据包处理的特定于域的语言。 P4语言为协议独立提供了主要框架[10]; PISCES在真实的软件交换机中实现了协议独立性。 P4本身借用了先前工作中的概念[7,23,48];因此，有可能将我们在PISCES中实现的类似概念应用于其他高级语言。虽然PISCES将P4编译为OVS源代码，但我们开发的概念和优化可以应用于其他高级语言和目标交换机;诸如NetASM [65]之类的中间表示最终可以为编译器提供一种机制，以便为各种语言和目标应用优化。 Pyretic [62]和Frenetic [24]等语言是特定于域的语言，用于指定固定功能OpenFlow交换机应如何处理数据包。它们需要进行大量调整才能利用可编程交换机的能力。此外，将数据包程序编译为可重新配置的硬件交换机[36]和FPGA [12,63]与编译软件交换机不同。对于硬件交换机，重点是受约束的优化问题，其中，给定相对较小的芯片或内存占用，目标是在满足依赖性的同时最佳地使用该空间。对于没有相同类型约束的软件交换机，这种方法不太可能有效。

虚拟软件交换机。现有的方法和框架用于构建软件交换机，如Linux Kernel [46]，DPDK [34]，Netmap [64]，Click [44]和BPF [14,15,49]，需要对底层实现有深入了解。因此，使网络程序员难以快速适应并向这些虚拟交换机添加新功能。另一方面，PISCES允许程序员指定独立于底层实现细节的数据包处理行为。 Open vSwitch（OVS）[57]提供了用于填充其匹配操作表的接口，但没有提供自定义协议和操作的机制。

其他可编程交换机。软件路由器，如RouteBricks[18]，PacketShader [31]和GSwitch [72]依靠通用处理器或GPU来处理数据包;这些设计通常侧重于优化服务器，网络接口和处理器调度，以提高软件交换机的性能。这些交换机不能通过P4等高级域特定语言实现可编程性，并且它们也不能用作管理程序交换机。 CuckooSwitch [74]可以用作管理程序交换机。但是，它侧重于通过使用基于Cuckoo散列的高度并发哈希表来提供快速转发查找[54]，并且还没有提供用于配置交换机的高级域特定语言。 Switch？Blade [6]支持一定数量的协议定制，并以硬件速度转发数据包，但也可作为独立交换机，并需要FPGA作为目标。

测量性能。以前的工作既包括[9,21]，也在改进[14,15,34,49,56,57,64]软件虚拟交换机的性能。关于度量的工作已经集中在一组性能指标上，以便比较各种交换机架构和实现;我们的评估使用这些指标来比较PISCES与其他虚拟交换机的性能。

衡量复杂性。在软件工程师[13,32,37,38,52]中开发了许多衡量用域特定语言编写的程序的复杂性和可维护性的指标。 PISCES的目标之一是让程序员更容易开发和维护代码。对于我们的评估，我们从软件工程中采用这些指标来评估在P4中编写程序的复杂性与直接修改OVS源代码在

7 结论

数据中心越来越多地使用软件管理程序交换机，因此需要快速修改这些软件交换机的数据包转发行为。今天，模拟这些交换机既需要熟悉交换机代码库，又需要广泛的网络协议设计专业知识，这使得定制这些软件交换机的标准非常高。作为这种操作模式的替代方案，我们开发了PISCES，一种可编程的，独立于协议的软件开关，允许协议设计人员以高级域特定语言指定软件交换机的自定义数据包处理行为（在我们的例子中，P4 ）;然后，编译器为底层目标软件开关（在我们的例子中为OVS）生成源代码。 PISCES程序比软件交换机的本机代码中的等效程序简洁大约40倍。我们证明，通过适当的编译器优化，与本机软件交换机实现相比，这种复杂性的急剧降低只会带来很小的性能开销。

我们的原型演示了使用P4作为编程语言并将OVS作为目标交换机的协议独立软件切换的可行性。此外，我们的软件交换协议独立性技术和将特定于域的数据包处理语言编译为高效的低级实现应该推广到其他语言和目标。实现语言和目标独立性的一种方法是首先将域特定语言编译为独立于协议的高级中间表示（HLIR），例如协议不经意转发[68]或NetASM [65]，然后将PISCES的技术和优化应用到HLIR。

PISCES的另一个未来增强功能是将自定义解析，匹配和动作代码动态加载到运行的协议无关的交换机中。 PISCES目前需要在每次程序员更改P4规范时重新编译交换机源代码。在某些情况下，例如为运行生产交换机添加新功能和协议或暂时改变协议行为以增加可见性或防御攻击，在正在运行的交换机中动态加载代码将是有价值的。我们期望未来可编程协议无关的软件交换机支持动态加载新的或修改的数据包处理代码。最后，PISCES没有实现维持数据包状态（即计数器，计量表或寄存器）的P4功能，这需要扩展和推广Open vSwitch缓存模型以实现可接受的性能。

现在看到PISCES对协议开发的影响还为时过早，但由此产生的代码简单性可以使部署，实现和维护自定义软件交换机变得更加容易。特别是，协议设计人员可以根据像P4这样的高级域特定语言来维护他们的自定义软件交换机实现，而无需跟踪（更大和更复杂）底层软件交换机代码库的演变。无需修改（和跟踪）软件开关（如OVS）的源代码即可开发专有自定义的能力是协议设计者的卖点。我们打算在发布PISCES时与这些效果进行研究和表征，并与使用它的协议设计者进行交互.

https://github.com/P4-vSwitch/vagrant

OpenFlow的缺陷：没有做到协议不相关：OpenFlow只能依据现有的协议来定义流表项。我们的目标是能够自定义协议字段类型、实现自定义动作类型，即所说的数据面编程。数据面编程：我们自己定义匹配字段，自己定义动作类型，从而自己定义流表，进而形成流水线（pipline）。基于这种初衷，P4应运而生。OpenFlow 并不是真正控制switch 的行为，而是给了我们一个建立一套已知表格的方法。

P4：是一种数据面的编程语言，下图提供了P4提供的最简单最易理解的编程结构，V1Model，由5个模块组成，从左到右分别是Parser（解析器：解析并提取数据包头的各个字段）、Ingress（定义Ingress流水线）、TM（Traffic Manager，有一些队列，用于流量控制，一些队列相关的metedata在此更新）、Egress（定义Egress流水线）、Deparser（重组数据包，因为数据包在处理过程中经历了分解和处理，所以在最后转发时需要重组一下）。

（https://www.sdnlab.com/22466.html）

【论】PISCES: A Programmable, Protocol-Independent Software Switch