Bottleneck Analysis

实验方法：扩展了RMT resource mapper

发现了四个bottleneck

Hash calls：在硬件交换机上，代码中出现的所有hash调用都需要预先分配，因为必须保证在所有可能的执行路径上以线速度执行。这增加了资源需求，即使哈希调用不需要执行。
Memory：与哈希资源类似，SALU（memory access hardware）需要在编译时预先分配，即使它们可能一直未使用。
Resources for tracking heavy flowkeys：许多sketch需要跟踪heavy flowkey，以实现下游的分析任务。通常情况下，这些sketch在一个单独的数据结构（例如，堆或优先级队列）中存储heavy flowkey[17, 41]。
Pipeline stages：我们隐含地假设交换机上有一个单一的资源池（即SRAM/TCAM、SALU和哈希调用），可以分配给sketch操作。在现实中，这些资源在流水线的各个阶段被分割开来。这在两个方面影响资源的使用。首先，在一个操作可以被分配到一个阶段之前，所有需要的资源都需要在该阶段可用。如果不是这样，它需要被转移到下一个阶段。第二，如果两个操作之间存在依赖关系，例如代码中的O1 → O2，那么O2必须被放在比O1更晚的阶段，即使在流水线的早期阶段有未使用的资源可用。

Optimizations

Optimizing Hash Calls

Optimization 1. Consolidate many short hash calls

我们观察到，许多哈希调用只需要短长度（例如，1比特）的哈希结果。我们可以通过合并许多短的哈希调用来减少哈希调用的数量，只要哈希调用的输入是相同的。

实际上就是把一个长的hash分割成几个不同的短的hash。

Optimization 2. Reuse the hash calls across levels for multi-level sketches

如果对哈希调用没有独立性要求，我们可以重用它们；也就是说，它们可以使用同一个种子。尽管在一个单级sketch中的不同计数器阵列之间通常需要哈希的独立性，但在不同级别之间则不需要[16]。因此，我们可以在多级草图中使用相同的哈希种子跨越不同级别。

Optimizing Pipeline Stages

Optimization 3. Avoiding the sequential if clauses using a longest prefix match

最长前缀匹配（LPM），可以在硬件中有效计算。也就是说，我们可以使用单一的L位散列计算L个散列位，并使用LPM来识别哪些层需要更新。如图9所示，这种LPM操作是通过TCAM实现的。

Optimizing Memory Accesses

Optimization 4: Refactor multi-level sketches to update one level per packet

我们重构了multi-level sketching algorithms及其代码，以保证only one level is updated per flowkey。

详细可以看图10

Optimization 5: Remove unnecessary SALU operations

对于每个级别的每个计数器，编译器静态地分配一个SALU用于内存访问。这导致了SALU的高使用率，即使每个数据包只需要更新一个级别；也就是说，使用率与更新所有级别相同。

当每个数据包只需要一个更新时，我们可以删除不必要的SALU。编译器之所以没有为所有可能的内存访问预先分配SALU，是因为在运行时很难自动找出只需要一个更新。我们的优化重组了P4代码，使编译器明确知道每一级只需要一个计数草图更新。我们没有使用位于不同开关内存区域的单独的计数器阵列，而是将所有级别的计数器阵列合并到位于一个内存区域的单一阵列中。这是可能的，因为SALU可以支持随机访问，因此根据选定的级别，我们可以计算出相应的索引值来访问合并后的寄存器。图11说明了这种SALU优化。这种优化将多级草图的SALU要求降低了L（级别的数量，例如，R-HHH[12]的25）倍。

Optimizing Heavy Flowkey Reporting

Optimization 6: Use a hash table and an exact-match ta- ble for checking duplicate flowkeys

正如第3.2节B3所讨论的，先前的努力[33，39]使用Bloom filter作为重复检查器，但过滤器的假阳性会导致heavy flowkeys的错过，除非使用一个非常大的Bloom filter。为了改善失误率和数据平面资源之间的权衡，我们使用一个哈希表和一个精确匹配表来检查重复。

API Implementation

没什么好看的