contribution

个人总结的话就是用一些形式化的程序代替了函数的执行，给函数的输入，然后输出性能。至于怎么提取好像也不是全自动的，同时还依赖符号执行。

我们建议将性能接口作为描述系统性能的一种方式，类似于语义接口描述其功能的方式。我们在网络功能（NF）领域具体化了这一想法，并提出了一个工具（PIX），它可以从NF的实现中自动提取性能界面。

performance interface

design goals

我们设想，"性能界面 "必须描述系统外部可见的性能行为，就像语义界面描述系统外部可见的功能一样[48]。总结性能的主要挑战是，系统通常比语义界面暴露出更多的性能行为。因此，一个能够完美预测每一种可能的性能行为的性能接口很可能会非常复杂，以至于不值得被称为接口。我们寻找一种折中的方法，即一种能够在以下特性之间取得良好平衡的性能总结方式：

准确性，即完全（对每一个可能的输入）和精确（误差小）总结性能的能力。
简洁性，即比代码小，并尽可能地抽象--用适合于系统语义界面的基元来总结性能，只有在必要时才显示出实现细节。
可移植性。一个系统的性能可能在很大程度上取决于其环境（例如，工作负载，硬件）。例如，造成L3缓存缺失的对抗性流量可以使NF延迟降低3倍[64]。该接口应该能够方便地量化特定环境对性能的影响，使接口能够跨部署地移植。

definition

几个定义

program: \(P\)
procedure: \(p_1, p_2, ...\)
performance interface of \(P\): \(S_p = {p_1',p_2', ...}\)
\(p_i'\) 是一个程序，takes the same inputs as the corresponding \(p_i \in P\)，return

有两种情况：general-case performance interface和deployment-specific performance interface

general-case performance interface

在一般情况下的性能接口中，程序 \(p_i'\) 的计算性能是Performance- Critical Variables的一个函数[41]。PCVs保证了接口可以完全通用地描述每个 \(p_i'\) 的性能，也就是说，对于任意的工作负载和硬件配置。

deployment-specific performance interface

一个针对部署的性能接口比一般情况下的接口更简单，而且不包含PCVs。相反，程序 \(p_i'\) 将性能作为一个统计量（如中位数、最大值、第99百分位数）返回，该统计量是针对描述 \(P\) 的特定部署环境的PCV的给定联合概率分布计算的。在这项工作中，一个NF的部署环境是由它在启动时读取的配置、一个有代表性的工作负载和它运行的具体硬件来定义。

extracting performance interfaces

图3展示了PIX的概况。

PIX Backend

NF开发者向PIX后端提供NF源代码，并辅以几个single-line annotation。

PIX将此与NF使用的数据结构的预先分析相结合，并为所有有意义的解析范围提取general-case interface。PIX后端使用详尽的符号执行（ESE）[45]来自动分析NF代码。

PIX Frontend

NF运营商向PIX前端提供NF binary和general-case interface（由NF开发者提供和上一步生成），以及代表其部署中预期工作负载的（一组）数据包trace。

从这些数据中，PIX为所有有意义的分辨率范围提取特定于部署的interface。NF开发人员/操作人员也可以用特定的分辨率查询PIX，以获得该分辨率的接口。

extracting general-case interfaces

整个步骤分成四步

预处理。生成each execution path of the NF的hardware-independent PCV。论文中是指令个数和内存访问个数。我们主要是重复使用Bolt[41]的方法和工具。In Step 0, PIX also automatically instruments the NF code such that it can log the values of the hardware-independent PCVs for each input packet encountered.
NF-domain hardware model。这一步通过引入与硬件相关的PCVs（即捕捉NF和硬件之间相互作用的PCVs），以与硬件相关的指标（CPU cycles）来描述NF的每个执行路径的性能。我们利用NF领域的知识来消除CPI组件，并只挑选必要的硬件依赖性PCVs集。PIX只引入了两个与硬件相关的PCV--Base_CPI和LLC_miss_latency，并将路径的CPU周期数表示为 instructions * Base_CPI + LLC_misses * LLC_miss_latency。注意，虽然PIX对所有NF使用相同的两个PCV，但这些PCV的值随每个<NF，HW>对而变化（§3.2）。为了跟踪可能的LLC失误，PIX利用taint analysis[70]来识别特定于当前输入的依赖性堆访问；然后在每个这样的访问上进行分支，一个结果是LLC失误，另一个是LLC命中。
Python程序。前面的步骤将NF执行路径指定为对输入包和调用数据结构产生的符号的一组符号约束；这一步将这些约束翻译成人类可读的Python代码，并输出一个分辨率为1的NF的一般情况下的性能接口。 PIX利用流行的网络工作协议（如IPv4、TCP、QUIC）的头格式知识，对输入数据包进行符号约束的翻译。例如，非隧道式IPv4数据包上的约束pkt[23 : 24] == 6被翻译成pkt.isTCP 。PIX使用调用上下文和开发者提供的注释（每个实例化的数据结构有一个注释）来翻译调用数据结构产生的符号。
基于解析的合并。这一步使用分辨率的概念来简化性能间的关系。首先，它计算每个约束条件的最大性能影响，即两个执行路径之间的最大性能差异，这两个执行路径只在这个约束条件上有差异。不同的 "最大性能影响 "的集合形成了最小的决议阈值。其次，它消除了所有影响小于目标分辨率的约束。

extracting deployment-specific interfaces

PIX通过数据包trace作为输入，运行NF binary，推断出特定deployment下的PCV分布。主要有以下的PCV分布

与硬件无关的PCVs。PIX利用步骤0中介绍的测量方法来测量所提供的跟踪中每个数据包所遇到的这些PCV的值。然后，它计算这些PCVs的联合概率分布，因为它们往往是高度相关的（例如，在表1中，n_stale和n_evictions都是occ的函数）。
基础CPI。PIX使用当今所有主要处理器上的硬件性能计数器[75]来测量。由于数据包跟踪可能没有行使所有的执行路径，PIX假设所有路径的基础CPI分布相同，如果检测到明显的差异（例如，一些路径使用昂贵的X86指令，如整数除法，而其他路径不使用），它会提供警告。我们认为这是一个合理的假设，因为基本CPI只是指令组合的一个函数（它不包括任何失误事件）。在第4.1节中，我们通过实验来验证这一点。
LLC miss latency。测量LLC miss latency的分布，理想情况下需要复杂的NF特定测试[64]，以说明NF的特定指令和内存级的并行性。PIX避免了这一点，因为它的目标是将其所有状态保存在相对较小的一组预先分析的数据结构中的NF。PIX通过在部署的硬件上运行相应的micro-benchmark，估计出了特定部署中每个数据结构调用的LLC-miss-latency分布。在第4.1节中，我们通过实验表明，我们的近似方法在实践中表现良好（平均误差<10%）。

Performance Interfaces for Network Functions