【翻译】dRMT: Disaggregated Programmable Switching

Sharad Chole, Andy Fingerhut, Sha Ma, Anirudh Sivaraman, Shay Vargaftik, Alon Berger, Gal Mendelson, Mohammad Alizadeh, Shang-Tse Chuang, Isaac Keslassy, Ariel Orda, Tom Edsall.

Cisco/MIT/Technion/VMware, Inc.

摘要

我们介绍了dRMT（解耦合可重配置匹配动作表），一个新的可编程交换机架构。dRMT克服了RMT的2个重要的限制（RMT是当前主流的基于流水线架构的可编程交换机）：（1）表内存是流水线阶段独有的，意味着一个阶段不使用的内存不能被别的阶段所使用。（2）RMT被硬件连线决定，在包穿过流水线各个阶段的时候，必须串行执行匹配和动作。我们会说明这些限制使得要在RMT上有效的执行程序会很困难。

dRMT通过解耦合可编程交换机的内存和计算资源来解决这两个问题。具体的，dRMT会把表内存从流水线各个阶段当中移出来放到一个可以通过crossbar访问的中心化的池子里。另外，dRMT用一组处理器来代替RMT流水线各个阶段。

我们会介绍怎样在dRMT上编译时调度一个P4程序来保证确定性的吞吐和时延。我们还给出了一个dRMT的硬件设计并分析了它的可行性和芯片面积。我们的结果表明dRMT可以在线速上运行程序，并使用比RMT更少的处理器，而且避免当没有足够的处理器资源来在线速下运行程序的时候出现性能悬崖。dRMT的硬件设计相对RMT会有芯片面积的轻微增加，主要是由于crossbar导致。

关键词

可编程交换；包处理；RMT；去耦合

1. 引言

历史上，告诉包交换芯片都被架构成匹配动作阶段的流水线。对于每个进到交换机的包，每个阶段（1）提取特定的包头比特生成一个匹配key，然后（2）从匹配动作表当中查询这个key，最后（3）根据匹配结果执行一个动作。比如，一个阶段可以提取一个包的IP目的地址，在一个转发表当中查询这个IP地址，用这个结果来确定出去的端口。最近几年，可编程交换机出现了，允许一个交换机的流水线匹配动作阶段可以通过像P4这样的语言进行编程。

RMT. 可编程交换机主流的架构是RMT架构。如图1a所展示的那样，RMT使用匹配动作阶段流水线，和传统的固定功能交换机类似。但是，RMT使得匹配动作阶段可编程；程序员可以指定用于匹配的头，匹配的类型（绝对匹配，三态匹配等），并且基于基本动作组合自己的动作。

RMT的流水线阶段包含3种硬件资源：(1)匹配单元从匹配的key当中提取头比特，（2）本地内存集合中的表内存（3）动作单元可编程的修改包字段。比如一个阶段可能有一个匹配单元从一个包头当中提取880比特的keys，11Mbit的SRAM和1.25Mbit TCAM表，以及一个可以并行处理最多32个包字段的动作单元。

通过把这些资源连接成一个串行的流水线。RMT大大的简化布线。但是RMT因为流水线架构有两个关键的缺点。首先，因为每个流水线阶段只能访问本地的存储，RMT必须为执行匹配和行动的当前阶段所用到的表格分配存储。这样做把存储和匹配动作处理合并起来了，使得表的分布变得很有挑战，而且会导致非常差的资源使用率。比如当一个大表，没办法放到一个阶段，那么必须要分配到多个阶段里面去。但是，这个过程当中，这些阶段当中的匹配动作单元就被浪费了，除非上面还有其他表可以被并行的执行。

第二，RMT的硬件连接的流水线只能以一个固定的顺序执行一系列操作：阶段1的匹配动作执行，阶段2的匹配动作执行，等等。这种严格性对于匹配和动作不平衡的程序来说会导致硬件资源的浪费。比如一个程序的默认动作是减少包的TTL，那么这个流水线阶段执行默认动作就会浪费匹配单元和表存储。而且，因为包只能串行的通过流水线，一个程序不适应可用的硬件阶段必须重新循环这个流水线，这会把吞吐率降到一半，即使这个程序只需要一个额外的处理阶段。

dRMT。我们提出了dRMT(解耦RMT)，一个新的可编程交换机架构，来解决RMT遇到的2个问题。dRMT的关键是解耦可编程交换机的硬件资源。如图1b，dRMT解耦了：

(1) 存储：dRMT把各个处理阶段中给表格的存储提取出来放到一起，然后通过一个crossbar去访问。这个crossbar根据在匹配动作单元和内存中间交换搜索keys和结果。

(2)计算：dRMT通过一组匹配动作处理器代替了RMT的串行连线的流水线阶段。匹配动作处理器由匹配动作单元组成，和RMT的流水线阶段相似。但是和流水线阶段 不同的是包不需要在dRMT处理器之间移动。根据round-robin调度的方式，每个包被发送到一个dRMT处理器。这个包在这个处理器里面运行整个程序，直到程序结束。

存储和计算解耦合给dRMT提供了大量的灵活性。首先，从匹配动作处理硬件当中解耦存储来放表格。第二，计算解耦使得使得在一个处理器里面对于一个包或者跨包交错的执行匹配和动作变得可能。最后，计算解耦允许包间并行，一个处理器可以同时在多个包上执行匹配动作操作。这种灵活性使得dRMT相对RMT提高了硬件使用率，减少了线速运行一个程序的硬件数量（阶段或者处理器的数量）。等价的，它增加了一个固定数量的硬件线速执行程序的数量。

dRMT的run2complet包处理模型之前在一些网络处理器上已经使用过了(Cisco QuantumFlow Processor, Mellanox Indig NPS-400 400Gbps NPU，Netronome Agilio CX SmartNICs)。但是这些网络处理器并不保证确定性的包吞吐和时延。在网络处理器当中出现不确定性，有各种各样的原因，包括缓存不命中。处理器存储互联竞争。在dRMT当中，我们展示如何在编译时调度整个系统（处理器和存储）使得没有竞争。给定一个P4程序，我们的调度算法在编译时计算一个静态的调度，这样就确保了确定性的吞吐和时延。

我们用4个基准P4程序来评估dRMT，其中3个从开源的switch.p4衍生出来，另外一个是从一个大的交换ASIC制造商那边拿过来的私有的程序。通过这些程序，我们发现dRMT相对RMT只需要4.5%，16%，41%和50%的处理器数量来完成线速吞吐率（每个clock一个包）。我们也发现对于随机生成的类似switch.p4特性的程序，达到线速吞吐，dRMT平均只需要10%（最多30%）的处理器数量。而且dRMT的吞吞吐率随着处理器数量的减少下降非常的丝滑；而RMT如果程序需要更过的流水线阶段的话，性能下非常的迅速。

我们给出了dRMT的硬件设计，并且分析了它的可行性和芯片面积成本。dRMT相对RMT的灵活性来自一些额外的芯片面积成本。（1）实现了一个crossbar，这个在RMT架构下是不存在的。（2）实现了一个匹配动作处理器来实现存储和执行整个P4程序，不像RMT阶段那样只需要存储和执行P4程序当中的一段。我们给出了架构的优化，这个优化通过适度的限制来平衡成本。尽管我们没有做出一个dRMT芯片，我们的分析表明实现一个dRMT，这个dRMT和RMT有相同数量的处理器/阶段，然后拥有类似的芯片面积是可行的。比如一颗有32个处理器的dRMT芯片大概比一颗有32个阶段的RMT芯片多5平方毫米的芯片面积。一个典型的交换芯片的总面积大于200平方毫米。dRMT的可扩展性受到crossbar连线复杂度的制约。超过32个处理器，对于crossbar设计来说已经需要小心的人工布局和路由，可能比较有难度。幸运的是，交换芯片不大可能需要超过32个处理器（比如当前最好的可编程交换机有12个阶段）。

dRMT项目主页包含了复现我们实验结果的代码。还包含了一篇包含证明本文用到的理论的文章。(尴尬的是这个主页已经找不到了。。。)

2. 解耦合

2.1 存储解耦合

RMT架构下，每个流水线阶段可以只访问它本地的存储集合。这导致了一个表存储必须和提取搜索key和执行动作放在同一个阶段。这导致了2个问题的耦合:(1) 为每个阶段选择哪个匹配和动作操作。（2）把程序的表放到内存里。第一个问题涉及在多个阶段之间调度匹配和动作操作，这样来保证程序的依赖不被破坏。第二个问题关于把表放到存储当中去。dRMT通过通过crossbar使得所有的处理器可以访问所有的存储集合来解耦这两个问题。这有几个优势。

提高硬件使用率。存储解耦合最大的好处是大大的增加了有效的把操作和表格映射到硬件资源的灵活性。

例子2.1（并行搜索）。考虑一个有4个表格的程序，这个程序搜索可以并行的执行。如果4个表的keys可以从一个RMT阶段当中提取出来，但是他们所有的表的容量超过了一个存储集合的容量，那么有些表就必须移到后面的阶段。相似的，如果表可以放到存储集合当中，但是key的宽度超过了一个阶段的key提取能力，有些表必须被移动到后面的阶段。这两个case当中，有些资源（key提取硬件或者表）在第一个阶段当中都没有使用。但是dRMT，key提取和表布局是解耦合的，一个处理器可以提取4个搜索key然后通过crossbar发送到存储这些表的相应内存。

例子2.2（大表）。一个大表可能不能整个大放到一个存储集合当中去，可能需要分到多个阶段当中去。RMT每个阶段都要搜索它那部分表格，多次提取相同的key，然后匹配结果必须组合到一起。表格的动作只能在所有这些阶段之后再执行，可能导致所有前面阶段的执行单元的浪费。dRMT，crossbar可以将搜索key组播到多个存储集合，部分的搜索可以同时执行。在存储集合到处理器返回路径中，只有小量的结果组合逻辑，处理器只要接收最高优先级的结果。

独立的调度处理器和存储资源。内存解耦合使得基于执行程序的类型来选择处理器和存储集合的数量变得很直接。比如，一个设计者可以轻松的加一点TCAM存储集合来增加TCAM容量。通过组播搜索key，新的TCAM可以被分配给任何需要TCAM的表。作为对比，增加一个RMT阶段的存储，但是不增加它的匹配动作容量，可能会导致存储的浪费。

简单的编译。一个RMT编译器为了满足程序操作依赖必须把表分布到流水线的各个阶段。一个dRMT编译器需要解决2个更简单的问题：(1)把表放到存储集合当中去，这个可以通过简单的背包问题解决。（2）处理器上的调度操作。dRMT的一个重要的特性是这两个问题是解耦的；表可以被放到存储集合上和操作是怎么调度的是不相关的。这使得编译程序到dRMT上概念上比RMT要简单。我们在第三章讨论dRMT调度问题的细节。

存储解耦合的好处也不是dRMT专有的，我们也可以给RMT架构加一个crossbar来把所有的pipeline阶段连接到存储集合，并且提供相同的好处。但是，我们接下来要讨论的是dRMT把解耦合进一步推广，把流水线结构彻底的改造，把计算资源也解耦合了。我们的结果表明要获得解耦合的所有好处，计算解耦合是有必要的。

2.2 计算解耦合

RMT架构需要在流水线当中有严格的匹配动作序列操作。在dRMT当中我们允许匹配动作在一个处理器上可以交错的执行，只要依赖和资源约束条件被满足，这有几个好处。

提高硬件使用率。计算解耦合进一步的增加了调度操作来最大化硬件使用率的灵活性。我们使用一个toy程序来展示这个优势。这个toy程序的依赖可以看图2的有向无环图。我们假设每条边要求边之间的操作之间最少有一个周期的时延。节点上的数字表示他们的资源（匹配或者动作）需求。我们调度这个DAG来运行在RMT和dRMT上，假设每个阶段或者处理器每个周期可以处理最多1个match或者2个actions。

在RMT流水线当中，这个DAG需要至少3个阶段，因为没有足够的匹配资源来并行的跑M1和M2，而且M1和M2必须在A0之后。这个调度的问题是第一阶段的匹配单元被浪费了。dRMT可以调度相同的程序，只用2个处理器。每一行表示一个包在一个处理器上的的的操作序列。注意到包是以round-robin的顺序发送到这些处理器的：在第k个始终周期到达的包被放到处理器k mod 2上面。也注意到，每个处理器上的操作不会超过处理器每个时钟周期处理1个匹配和2个动作的容量限制。

消除性能滑坡。包交换ASIC，往往有一个回流路径，包的处理如果在单个通过中没有处理完可以发回到开头（和新的包混合在一起）。在一个流水线架构当中，如果一个特定的程序不能调度到适配当前的匹配动作阶段，可能就需要把程序分到多个passes。K-pass调度的包速率是1/K的系统最大速率。

作为对比，dRMT的吞吐率随着程序复杂度的提高降级比较丝滑。比如，如果一个dRMT系统可以支持每个时钟周期每个包M个表查询的dRMT系统，可以支持以每个时钟周期没M/M'个包，M' > M个表的搜索。这只需要增加包在处理器当中的时间，减少包发送到处理器的比例。

3. 确定性性能调度

我们现在描述dRMT调度问题，开发一个调度技术来在dRMT硬件上有效的执行P4程序，并且提供确定性的吞吐和时延。具体的，给定一个P4程序，我们寻找一个确定性的调度（编译时预计算）来满足2个约束：（1）P4程序特定依赖，（2）dRMT架构资源约束，比如每个处理器匹配和动作容量。我们的形式化的重要方面是相同的调度在处理器之间以round-robin的形式重复。这大大的简化了问题，因为这大大的减少了我们搜索的调度空间。这还会产生一组独特的周期性约束，我们的调度必须满足这种约束。

我们首先表述dRMT调度问题，然后引入我们主要的理论结果。具体的我们展示了确定性性能调度是NP难问题，然后形式化这个问题为一个整数线性规划问题。

3.1 调度问题

首先我们给出P4程序依赖约束和dRMT架构约束。然后我们引出给定这两类约束的调度优化问题，然后在定义之后给出一个阐述的例子。

程序依赖。每个进入dRMT的包，遵循由一个P4程序描述的控制流。这个控制流规定了包头是怎么被处理的。为了表达程序的依赖性，我们定义了一个操作依赖图（ODG），比如，一个有向无环图，这个图上节点表示一个包在穿过交换机的时候好执行的匹配动作操作，边描述了这些操作之间的依赖。

两个节点之间的一个边表示任何有效的调度必须一个一个执行。一个边也表明两个操作之间最小的时间间隔。对一个节点A和B之间的边，时延是节点A上操作执行结束所需要的时间。我们假设一个表的匹配需要M个时钟周期，一个动作需要A个时钟周期，意味着一个操作依赖于一个匹配或者一个动作必须要等待M或者A个时钟周期。

对于条件执行的操作（比如基于一个预测或者是否有一个表的命中或者不命中），我们保守的假设条件的两个分支都被执行并且都被调度，即使只有一个在运行时被执行。这等价于在一个条件分支下，等价的执行所有的动作节点，然后类似于RMT采用的推测执行模型，根据条件测试结果产生副作用。这个最差情况假设简化了调度问题。实际上，这还是允许我们有效的调度程序。

例子3.1（P4程序）。图4a描绘了一个支持单播和组播路由的简单P4程序的控制流（是22当中L2L3程序当中的一段）。图4b描绘了对应的ODG。M0，M1，M2，M3可以并行执行。动作A1必须在A2之前执行，因为他们都要写入相同的字段，A2的结果必须是最后的结果。

ODG和表依赖图TDG有点像。但是ODG更加简单。TDG基于依赖的类型（比如匹配，动作，反向匹配）描述边。通过把TDG中的每个表分到2个不同的匹配动作节点（中间有一个边）。ODG通过合适的边时延让我们用一个统一的方式表示这些依赖。

架构约束。一个调度必须满足几个dRMT的架构约束。在提供一个解释性的例子之前，我们先详细介绍这些约束。

处理器。dRMT架构包含N个处理器。在每个时钟周期，每个处理器可以对任意包开启如下的操作：发起一个表匹配，发起一个动作，或者不做任何操作（no-op）。每个表匹配需要M个时钟周期，每个动作需要A个时钟周期，这意味着如果一个操作依赖于一个匹配或者一个动作需要等待M或者A个时钟周期。在每个时钟浊气，当决定发起哪一个操作的时候，处理器受到以下限制：

(1) 它可以发起最多M个最多b个比特的并行表搜索。比如，它可以通过发送3个b比特的并行向量，用一个2.5b的key长度来查询一个匹配动作表。只要3小于等于M。

(2)可以并行修改最多A个动作字段。

(3)最后，它只能发起IPC个不同的包的匹配，也只能发起最多IPC个不同的包的动作。发起匹配的包和发起动作的包不需要相同。

存储访问约束。每个时钟周期，一个P4表（和存储集合有关）只能被一个处理器当中的一个包访问。

Crossbar。在每个时钟周期，上面的约束意味着每个处理器可以通过一个crossbar生成做多M个b比特宽key的表查询。crossbar也支持组播。

固定调度。给定一个P4程序和一个dRMT架构，我们限制固定调度（也就是在编译时预先定义各种类型的包）。具体的，我们假设到达的包按照严格的round-robin方式被分配到N个处理器当中的一个，而且每个处理器每隔P个始终周期接收到一个新的包。因此交换机的吞吐率是N/P（比如N=P，意味着每个时钟周期有一个新的包进入交换机）。因此，我们需要找到一个固定的调度，比如一个在编译时预先确定的单个cycle-by-cycle调度，可以应用到所有的包。比如，在线速情况下（P=N），相同的操作在时钟周期t，可以在处理器0上执行，也可以在t+1在处理器1上执行，在t+2在处理器t+2上执行等等，直到处理器0在t+P时刻执行相同的操作。这个调度是有效的，只要它满足P4约束和dRMT架构约束。

例子3.2 （有效调度）。我们想要给例子3.1/图4b当中的单播组播P4例子找到一个固定调度，N=2，P=2。为了简单起见，假设每个匹配需要M=2个时钟周期，每个动作需要A=1个时钟周期。在动作字段上的限制A是很大的，可以忽略，并行表搜索限制是2（如果key的大小是小于b的话），包并行是IPC=1，也就是在给定时钟周期一个处理器执行的匹配都是在相同的包上面的。

图4c给出了一个违反架构约束的调度。最上面的行表示时钟周期，后面的行表示不同的包。最左边的列表示处理器，0或者1。为了构建这第一种调度，我们根据图4b的ODG，从左到右，从上到下，因此产生了一下的可能操作序列：

M0&M1->M2&M3->A1&A2->A3。

注意到ODG允许所有的匹配并行的执行，但是因为M=2，只有其中2个可以并行的执行。因此，在时间0，一个包进入处理器0，M0和M1并行执行。在时间2，这个包的M0和M1结束了，M2和M3并行执行。所有的包在所有的处理器当中，遵循相同的调度，因此整个序列每一行只是简单的向右移动一列。不幸的是，这个调度序列是无效的，因为它违反了两个架构约束。首先，在时钟周期2，处理器0执行的匹配对应到2个不同的包，因此超过了IPC=1的约束。第二在时钟周期2，处理器0执行了4个匹配，但是M=2.

图4d展示了另一个没有冲突的调度。操作的序列如下：

M0&M1->no-op->M2&M3->A1&A2->A3。

在调度当中插入一个no-op，只是小幅度的增加了时延，但是解决了所有的约束。

调度目标。给定一个有N个处理器的dRMT架构和一个P4程序，我们的主要目标 是最大化dRMT的吞吐率。为了实现这一点，在编译时，我们运行一个优化子程序来表明，在P4程序依赖约束和dRMT架构约束下，一个给定的吞吐率是可行的。然后，我们用这个子程序结合二分查找来找到最大吞吐率。

另外，给定任意dRMT吞吐，我们想要最小化系统的资源来支持这个吞吐率，尤其是每个包需要处理的包的数量。假设T是调度器固定包时延。然后我们找到每个处理器最大的并行包数量T/P。因此，给定N和P，如果我们最小化时延，我们也最小化每个处理器需要处理的包的最大数量。综上，给定假设的吞吐，最后我们形式化定义我们的调度目标是：

3.2 简化dRMT调度

现在我们建立了调度目标方程1。我们通过依次考虑一个处理器，然后一个处理器一个包，展示简化dRMT调度问题的可能性。

单处理器调度。我们从调度一个处理器开始，而不是调度多个处理器。具体的，我们考虑一个处理器的固定调度，它满足程序相关的依赖以及M/A/IPC等架构约束。然后是一个有效的dRMT调度，符合所有的约束要求。尤其是，它不会和其它处理器在访问存储集合的时候产生冲突。形式化如下：

观察1（无竞争匹配）。考虑一个单处理器调度应用到所有的处理器。然后没有存储竞争，也就是说每个时钟周期所有从不同处理器发起的匹配请求被路由到不同的存储。

这个观察是来自以下事实：所有的包在不同的时钟周期到达交换机，因为调度是固定的，从包到达到存储访问的时间是固定的。另外因为ODG是无环的，每个包访问每个内存最多一次。因此，在任何给定的存储集合，对于不同的包，访问存储的时间是不一样的。

dRMT相对RMT有更高的吞吐率。观察1的一个重要的推论是dRMT架构至少有RMT架构的吞吐率。我们可以想象在RMT流水线上一个包的操作序列。这样的话，我们可以对每个dRMT处理器用相同的顺序使用相同的调度。很明显，如果dRMT处理器和RMT阶段有相同的M和A能力，这样一个调度可以满足程序相关的依赖约束以及M/A和IPC架构约束，因此我们得到一个dRMT有效调度。形式化的：

理论3.3。 一个程序的吞吐率在dRMT上至少是和RMT一样的。

在这篇文章中的所有结果的完整的证明都在在线拓展版本当中。

单包调度。就像之前提到的，一个固定调度在所有进来的包上以相同的顺序应用相同的操作。这些包每隔P个单位周期性的到达一个给定的处理器。考虑一个在时间t到达的包，这时，这个处理器同时在这个包上执行操作集合0，在t-P时刻到达的包上执行操作集合P，在t-2P时刻到达的包上执行操作集合2P等等。这些同时执行的操作集合也就是第一个包在各个时钟周期执行的操作，等价于t按P取模。因为第一个包也会在时间t+P执行集合P的操作，在t+2P执行集合2P的操作等等。因此不需要分析不同的包怎么在处理器上共享资源，只需要分析一个包的所有操作就足够了。

例子3.4 （单包调度）。再看看图4的单播组播的例子。图5展示了只考虑单个包和单个处理器的一个简化的分析。每个长方形表示一个等价类，也就是所有在时钟周期模P同时执行的操作。时间槽出现之后就执行相应的操作。对于一个满足程序依赖约束的有效调度，我们只需要确认所有给等价类的操作满足M/A和IPC约束。图5a展示了图4c中的有冲突的调度。在长方形时钟周期模P=0里面，再一次的我们看到它违反了架构的两个约束：有4个匹配操作但是M=2；对于匹配操作有2个不同的执行时间，但是IPC等于1。图5b展示了图4b有no-op的没有冲突的调度。通过把操作放到不同的长方形当中去，可以简单的验证调度的有效性。

就像图5展示的那样，为了建立一个符合M/A和IPC架构约束的单包调度。我们可以把这些约束转换成循环约束，也就是单个包的调度序列模P的约束。具体的，我们定义P个等价类，对应调度周期长度，依赖于以下的观察：

观察2（循环处理器调度）为单个处理器构建一个有效调度对应把ODG当中每一个匹配和动作操作分配给一个等价类，并确保分配给等价类的操作不违反架构约束，也就是M/A和IPC。

如果考虑等价类当中的所有操作，很容易验证M和A约束。但是要确保IPC约束得到满足，我们需要一个额外的观察：

观察3（包分类），在时钟周期t，一个处理器发起匹配/动作对应的不同的包的数量等于等价类t模p当中不同的匹配/动作执行的次数。

通过这些观察，我们形式化的获取了以下结果：

理论3.5。单包调度是有效的，当且仅当完整的dRMT调度是有效的。

3.3 整数线性规划

在给出我们的ILP调度解决方案之前，我们建立以下调度难的结果：

理论3.6 dRMT调度问题是NP难的。

我们的证明是基于箱子装载问题的归纳。用箱子来表示模P的时钟周期。不同大小的匹配动作操作是对象。因为问题的复杂性，我们观察到所有的dRMT架构约束是整数值的，因此只要目标函数是线性的，我们可以把调度问题表达为整数线性规划问题。而ILP问题可以用像Gurobi这样的ILP求解器去最优求解。

ILP公式。像理论3.5那样，我们可以限制到一个循环调度取模约束。我们看一个包pi，考虑这个包的操作v对应的一个ODG节点。我们用t(v)来表示这个操作v开始的时间。我们的目标是为pi找到一个循环调度，满足所有的约束，并且最小化所需的最大时间t(v)，也就是最后一个操作开始的时间。那么第一组约束就是对于任意的t(v) <= T。T是我们想要最小化的目标函数。

我们下一步是概述ILP是怎么处理以下3类约束的：P4程序依赖约束，资源约束，包间并行约束。

依赖约束。当解决调度问题的时候，我们必须满足ODG当中边的依赖，以及他们的对应时延。我们可以把这些约束表达为：

t是u/v之间必须满足的时钟周期。注意我们不需要相等。这种灵活性的代价是我们可能需要一个临时存储区来存储中间结果以供后面的节点使用。

资源约束。就像观察2表明的那样，我们寻求把ODG中所有节点划分到P个等价类当中，并保证并不违反任何资源约束。为此，我们引入了指示变量来跟踪每个类的资源使用。我们定义一个节点的等价类为这个节点的执行时间除以周期长度P的余数。因此我们引入二元变量rq(v,q,r)，rq(v,q,r)=1当且仅当t(v) = q*P + r。可以看到指示变量必须满足两个等式：

假设ODG当中匹配节点的结合为Vm，k(v)是key的size。同样的，Va可以看作动作节点的集合，a(v)是动作v修改字段的数量。现在我们可以形式化匹配和动作资源约束如下：

IPC约束。我们想要把IPC当作处理器在同一时间槽上可以生成匹配关键字的不同包的数量的最大值。为了这么做，我们依赖观察3。具体的，让(q,r)对应执行时间t=q*P + r 。然后我们限制不同q值的数量。为此我们为匹配操作引入了指示变量pm(q,r)，如果至少有一个匹配操作在时间t=q*P+r，那么pm(q,r)=1。可以表达为如下公式：

最后我们可以限制同一个时钟周期进行匹配操作的不同包的数量：

也就是说，我们要求在用一个时钟周期，不同q值的匹配操作的数量，受到IPC的约束（译者：what？why different q value，different q value should refer to different time slot right？）。但是并不约束属于相同包（也就是相同r值）的并行匹配数量。IPC动作约束的定义也是相同的。

加速ILP运行时。我们开发了3种技术来加速ILP运行时，这些技术允许我们找到一个ILP的可行解。这个可行解可以作为ILP求解器的种子，或者被用来在二分搜索中快速的建立可行性。如果感兴趣可以看本文的长版本。

4. 评估

我们用两个指标来比较在包处理程序上的RMT和dRMT：(1)保持线速（也就是每个时钟周期一个包）的最小处理器数量。（2）保持一个时钟周期一个包的最小线程数量。在一个dRMT处理器中，对于每个包，存在一个单独的线程来维护一些状态（比如包头向量）。对于一个固定吞吐率来说，每个时钟周期一个包，所有处理器当中线程的总数等于程序的时间延迟（译者：why？）。

首先，我们在4个P4程序上比较两个架构，其中3个是从开源程序switch.p4当中引申出来的。以及一个私有的程序。第二因为真实的P4程序的缺乏，我们在100个随机生成的操作依赖图（ODG）上比较了两个架构。第三，我们展示了当我们降低处理器数量的时候，两个架构的吞吐率是如何降低的。表明dRMT不会像RMT那样出现性能滑坡。第四我们报告了dRMT ILP运行时。

4.1 实验环境

我们比较了4个架构：RMT架构，细粒度RMT架构，IPC=1的dRMT架构，IPC=2的dRMT架构。细粒度dRMT允许一个P4表格当中的匹配动作被划分和分布到不同的RMT阶段。它比RMT提供更多的灵活性，代价是暂时把动作的结果放到包头当中，这个代价对于RMT来说可以忽略。我们还比较了下界。下界表示支持线速所需要的最少处理器数量（假设瓶颈资源，匹配或者动作，完全被使用）。它还表示一个程序基于它的关键路径所需要的最小时延。

数值参数。对于两个架构来说，我们假设存储集合的数量等于处理器或者阶段的数量。我们在表1中列出了其它参数。我们基于RMT的文章和我们估计的匹配和动作时延来选择这些参数。dRMT的匹配时延是大于RMT的，因为存在crossbar。dRMT的动作容量是小于RMT的，这确保了芯片面积和RMT差不多（我们在5.1当中展开介绍）。我们不考虑RMT IPC=2的情况，因为这需要发送两个包头痛过流水线，这会使得所有阶段的位宽加倍。对于dRMT，支持IPC=2只需要额外的包缓冲区以及处理器当中的一些选择器，这只增加一点芯片面积。

评估RMT的性能。对于细粒度和默认的RMT架构，我们形式化一个ILP来表示上述匹配和动作容量约束，以及由操作依赖图表示的依赖约束。我们的RMT ILP和文章22类似，有效的仿真了带有完全解耦合存储的RMT流水线。这表明dRMT相对RMT（本地，每个阶段非共享存储）实际的提升比这里提到的会更多。我们使用RMT ILP来计算最少的流水线阶段数量S。

评估dRMT的性能。对于dRMT，我们运行第三章当中描述的ILP，使用一些启发式的方法来加速ILP运行时。我们用第三章中提到的二分搜索过程来计算最小的调度周期P使得单个处理器可以每P个时钟周期接收一个包。

指标。对于dRMT，如果最小的调度周期是P，那个单个处理器最多每P个时钟周期接收一个包。这意味着至少需要P个处理器来支持每个时钟周期一个包的吞吐率。对于RMT，假设每个时钟周期每个流水线阶段可以处理一个包，至少需要S个阶段来实现每个时钟周期处理一个包。对于RMT来说，最少的线程数量可以通过最小的阶段数量乘以RMT匹配和动作的时间延迟。对于dRMT，可以作为ILP的优化目标来输出。

备注。对于RMT和dRMT的ILP，假设一个条件的两个分支永远是预测执行。调度互斥的操作（对于任意的包不能同时执行）一起执行可能降低两个架构处理器或者阶段以及线程的数量。

4.2 实验结果

在真正的P4程序上比较dRMT和RMT。表2和3展示了要在4个程序上支持一个每个时钟周期一个包的吞吐率最少的处理器和线程数量。

其中三个是从一个开源的P4程序switch.p4衍生出来的，他们对应switch.p4 ingress流水线，egress流水线，组合ingress+egress代码运行在单个共享物理流水线来提高使用率。组合switch.p4程序通过统计多路复用有效的提高了使用率。它创建了一个机会，在同一个硬件阶段，在一个流水线当中有一个非常高使用率的阶段，在另外一个流水线当中有一个低使用率低阶段。

我们还从一个大的交换ASIC制造商那里拿来了一个私有的P4程序。这个程序的代码行数比switch.p4多50%，实现了所有的（出了少数）switch.p4的转发特性，还有一些switch.p4没有的功能。为了匿名性，对于私有程序，我们把关键路径的时延和处理器数量的下界形式化为1 。

结果表明从RMT到IPC=2点dRMT，最少的处理器数量和线程数量都下降了，因为更多的去耦合会使得更加灵活的调度成为可能。这个结果还表明在同一个处理器当中并行执行两个包（IPC=2）的优势明显。IPC=1的RMT和dRMT都没办法利用这种并行性。IPC=2还让这些程序到达了吞吐率的上限，这表明小程度的包间并行可以大大提高吞吐率。

dRMT最大的好处是对于那些导致匹配和动作操作不平衡流水线（浪费资源）的程序。dRMT把这些程序（比如switch.p4 egress）打包到少量的处理器上。当程序已经有比较平衡的RMT流水线的时候（比如组合ingress和egress的switch.p4），dRMT的好处不多。

在随机ODG上的比较。为了在更多的各种各样的可能P4程序上比较dRMT和RMT，我们基于switch.p4 ODG的特性生成了各种随机ODG。具体的，我们生成了100个不同的ODG，代表各种大小的不同P4程序。对于每个ODG，我们报告了需要支持线速的最少处理器和阶段的数量。我们用以下方式生成ODG：

（1）随机生成一个有100个节点的有向无环图。边（i，j）存在的概率是p，我们选择p是的平均边的数量是500。

（2）然后节点通过拓扑排序的方式进行访问。每个非叶子节点以概率0.15来选择默认的动作，或者作为一个条件节点，也就是作为一个单字段动作节点以概率0.25表示一个预测，或者以概率0.6分化成一个动作节点和匹配节点。同样的，每个叶子节点要么概率0.15的默认动作，或者以概率0.85分化成一个匹配节点和一个动作节点。

（3）对于一个非条件动作节点，首先从平均值为4个字段的几何分布当中采样字段数量， 然后截断到区间[1,32]。

  (4) 对于一个匹配节点。键宽首先从一个均值为106比特的几何分布当中采样，然后截断到[80, 640]。

所有以上的参数，比如边的数量，节点类型的概率，截断几何分布的参数的选择都是基于对switch.p4分布观测。我们通过选择一个几何分布来捕获我们从switch.p4当中获取的经验观测，大的键宽和动作字段是不可能的。

图6展示了结果。和预期的一样，IPC=2的dRMT提供了更大的灵活性，从而导致需要的处理器变少。IPC=1的dRMT是第二名，展示了相对dRMT架构一致的优势。

dRMT消除了性能滑坡。我们一旦确定了让RMT和dRMT能够以每个时钟周期一个包的吞吐率工作的S和P，我们可以计算吞吐率th(N)作为处理器数量N的函数。

吞吐率是小于1的，因为要构建一个片上内存支持每个时钟周期2次或者多次的读写诗非常有难度的，也就是每个时钟周期多个包。

图7展示了降低处理器数量对于吞吐率的影响。使用switch.p4 egress流水线，它划出了每个架构的吞吐率。这个图表明两个RMT变体有性能滑坡，而dRMT只有线性降级。switch.p4的ingress和组合版本的结果没有展示，但是是类似的。比如对于ingress程序，当处理器数量从18降到17，RMT吞吐率下降50%。

dRMT ILP运行时评估。把每个时钟周期一个包作为固定吞吐率，把dRMT ILP的时间作为处理器数量N的一个函数，使用3个开源switch.p4程序。我们在一台有8个4核心 AMD处理器（2.2GHz，每个处理器有一个2MB L3 cache），544MHz的256GB DDR2 RAM的HP ProLiant DL785G5机器上运行评估。

图8展示了dRMT IPC=1的结果。在满足每个时钟周期处理一个包的最小数量的处理器之后，随着处理器数量的小幅度增加，ILP运行时的时间下降的非常快。因为当适当松弛之后，ILP会变得非常容易求解。我们并没有展示IPC=2的dRMT的结果，因为IPC=2的运行时不管处理器的数量有多少，永远不会超过几分钟。因为IPC=2提供的灵活性会让调度问题变得非常简单。

5. 硬件架构

dRMT架构由一组匹配动作处理器通过crossbar连接到一组存储集合组成。每个匹配动作处理器包含处理元素：（1）生成用于匹配的匹配keys。（2）更新包字段来做动作。尽管dRMT的整个架构和RMT事不一样的，但是对于匹配和动作处理元素来说事相似的。因此我们采用RMT当中这些处理元素的设计。

RMT和dRMT的关键不同是：如果一个包被分配给一个处理器，那么这个dRMT处理器会将包处理完毕，而不是在阶段与阶段之间来回移动。尽管run-to-completion为dRMT架构提供了更多的灵活性，但是它需要每个处理器存储整个程序。这和RMT截然不同，RMT的流水线阶段只存储只存储在这个阶段执行的那部分程序。因此，dRMT硬件设计需要更多的优化来避免数字逻辑当中额外的成本，从而减少芯片面积和功耗。5.1章专注介绍单个匹配动作处理器的优化。5.2章介绍存储集合。5.3章介绍连接处理器和集合的crossbar。

我们会在本章提到很多的约束。比如，包向量当中的比特数量，每个时钟周期一个处理器可以发起的搜索key的比特数量，等等。除非明确说明，否则我们就使用RMT架构当中提到的设计参数。这让我们更加直接的比较两个工作。

5.1 匹配动作处理器

每个匹配动作处理器每隔P个时钟周期接收一个数据包，P是调度周期。如果最大的程序时延是T个周期，每个处理器必须并行接收和处理最多m=T/P的上届个包。因此处理器使用一个m线程的设计来存储包和等待服务，每个线程对应于不同的包。这个和通用CPU核心和GPU来说是类似的，有相同的目的：当面对高时延操作的时候（比如L1 cache不命中或者dRMT表匹配），为了获得更高的处理器使用率。图9展示了处理器架构，我们列出其中的部件：

(1) 包头向量：用来存储包头和元数据。元数据就是从包当中或者查表内容衍生出来的数据，但是并不是包的一部分。

(2) 匹配表key生成逻辑：用来为表查询生成匹配key。

(3) 动作算数逻辑单元（ALUs）：在每个时钟周期允许多个包字段并行处理。

(4) 一个非常大的指令集字（VLIM）：规定每个动作ALU在每个时钟周期的配置（操作数和操作码）的指令存储。

(5) 一个动作输入crossbar来选择ALU的输入。

(6) 一个动作输出crossbar把ALU修改后的结果路由到包头向量。

(7) 一个scrach pad用来暂时存储一个表匹配的结果相关联的数据（我们给它一个术语叫动作数据段），这些数据会在下一个时钟周期被使用。

(8) 一个线程配置表来帮助在每个时钟周期选择一个用于陪陪动作操作的线程。同时选择多个线程使得我们之前讨论的包间并行成为可能。

匹配key生成。基于RMT，我们使用一个4-kbit的包头向量，分割成64个8比特字段，96个16比特字段，64个32比特字段，总共224个字段。从这个向量当中，我们提取最多640比特长的字段作为匹配搜索key发送给crossbar。这被结构化为8个80比特的key段，比如它可以由分到4个段的320比特key和2个分别分到2个段的160比特key。我们发现没有必要为哈希表和TCAM构建不同的640比特key，处理器生成的给哈希表和TCAM的key都可以是640bit形式。

在RMT当中，匹配key是由一个4-kbit到640比特的crossbar生成的，这个crossbar把包头向量作为输入，并输出最多8个搜索key。每个匹配动作阶段对于crossbar来说只需要一个配置设置，这个设置存储在这个阶段的触发器当中。不同的阶段由不同的配置，这样不同的阶段可以基于查询的内容生成不同的搜索keys。

不同的是dRMT是一个run-to-complete架构，所以每个处理器必须要能够在P个时钟周期当中的每个时钟周期生成不同的搜索keys。为了减少芯片面积，把P个搜索key的crossbar配置设定存储到一个中心的位置，而不是存储到每个处理器。然后当需要key生成的时候，通过2级分发树，为每个处理器分发配置。

注意dRMT架构可以在相同的时钟周期从多个线程当中调度匹配动作操作（IPC>1）。唯一的约束是所有的线程组合的搜索keys必须适配到640比特的搜索key当中。

ALUs。每个算术逻辑单元的目标是在1到2个包头字段上每个时钟周期执行一个操作，比如2个32位数的算术，左移或者右移，比较或者逻辑操作。RMT和dRMT，ALU的实现本身相对便宜，但是为了输入操作数和输出结果需要昂贵的逻辑。比如对于，RMT和dRMT，crossbar逻辑需要从4k包头向量当中提取ALU输入和768比特动作数据段（也就是最多8个表格的匹配结果，每个96比特）。

另外，RMT中每个阶段只需要部分程序的指令存储。但是dRMT当中每个处理器需要存储整个程序。这需要我们在dRMT设计当中减少ALU的数量，因为ALU数量的增加会增加VLIW指令的宽度。RMT在它的VLIW指令当中使用224个ALUs，每个对应4k比特包头向量当中的224个字段当中的一个。基于我们对switch.p4的分析，我们发现32个并行的ALU就够了。图10 展示了关于switch.p4的分析。我们注意到超过90%的表格需要8个或者更少的原始动作来组合成所需的最大的混合动作，超过90%的原始动作可以在单个ALU中执行。对于私有的P4程序的分析给出了相似的结果。

RMT设计师是这样解释他们为每个字段选择一个ALU的：允许每个逻辑阶段重写每个字段可能看起来有点过头，但是当移动包头的时候很有用。一个逻辑MPLS阶段可能掉丢一个MPLS头，把后面的MPLS头向前移动。对于这个具体的情况，6个MPLS头组成的P4程序只需要6个32位ALU来实现push/pop操作。更大的头数组在网络协议当中是不常见的。如果这种情况在某个P4程序当中遇到了，对于32个ALU，我们没办法在一个VLIW指令当中处理，dRMT可以执行多次。

dRMT的ALU使用32位的输入和输出，这和RMT芯片当中的ALU功能上是一致的。有32个这样的ALU，我们可以在一个时钟周期里面，修改包头向量当中最多1k比特。因为我们只有32个ALU，我们实现了一个32x224的crossbar来把ALU的输出写回到包头向量当中224个位置当中的32个。这个输出crossbar在RMT当中并不存在，因为在RMT都中224个字段当中的每一个都有一个直连的线。

每个时钟周期可能执行最多8个匹配。所以我们可以在每个时钟周期最多有8个动作。加在一起，这8个动作可以用完所有32个ALUs。编译器确保8个动作用不同的ALU来实现，从而避免资源冲突。因此每个时钟周期，每个ALU都属于8个动作当中的一个，这个动作给这个ALU配置了操作数和操作码。

VLIW指令存储。VLIM指令存储是通过每个时钟周期提供操作数和操作码来配置dRMT当中的32个ALU的。如图11，我们讲指令存储实现为32个per-ALU SRAM slices。每个slice可以放1千条记录，每条记录对应配置ALU执行1000种不同的操作。我们选择一千来对应RMT，RMT通过32个阶段*32个用户可定义的动作，提供1024个动作。slice当中的每条记录存储ALU的操作码和操作数的地址。操作数可以是224个包字段当中的1个，8个作为表查询结果返回的个96bit动作数据段（比如设置下一跳的动作产生的下一跳的值）当中的一个，一个常数，或者scrach pad当中的数据。

一个slice当中在某个时钟周期某个ALU是通过哪个1K记录来配置的？每次表查询，除了返回数据段，还返回一个10比特的指令指针来表示其中的1K不同的动作。在某个时钟周期，从表查询返回的指令指针寻址了ALU对应的slice。为了确定32个per-ALU slice当中哪一个指令指针在某个时钟周期应该被寻址，我们使用了一个32*96b的配置表。这个表由5bit（因此有32条记录）的程序计数器来索引。每个记录里面有32个3比特的选择字段，每个ALU一个字段。这个记录表明该时钟周期被赋予指定ALU的8个动作（8个10bit指令指针）的一个。

VLIM指令存储不能被像匹配配置那样的中心化分布式树代替。这是因为VLIM ALU操作码需要在运行时确定，它依赖于每个包的匹配动作表查询返回的指令指针，每个包可能是不同的。另一方面匹配crossbar配置可以在编译时确认，只需要在处理器需要的时候发给它就行了。

Scratch pad。如果程序只包含固定模式的匹配动作元素，动作数据段当他们返回的时候就被用掉了。但是，在dRMT当中有额外的挑战：

• 程序调度器可能通过no-ops延迟一个动作，从而把时钟周期让给另外一个包。
• 匹配和动作可能交替执行，比如M1M2。。。A1A2。
• 多个匹配操作之后，调度器可能为了降低时延，融合多个动作。比如M1M2。。。A1+2。A1+2对应并行运行A1和A2的融合动作。

虽然这些灵活性提高了调度的结果，它需要暂态存储来保存匹配操作从存储集合当中返回到处理器的结果。为此我们实现了一个sratch pad。scratch pad的宽度是96比特（动作数据段的宽度），它最多可以存储64条记录。这个大小对于我们评估的程序来说已经足够了。这个sratch pad有8个写端口和8个读端口。这允许处理器并行的写8个动作结果，以及并行的读8个动作数据。

一个更深的scratch pad可以为调度器推迟动作带来更多的灵活性，但是会增加硬件成本。如果一个编译器拿到的程序是这么多scratch pad记录支持不过来的，调度器可以重新安排匹配和动作来减少暂态存储的需求。比如可以通过限制交替执行匹配动作操作的数量（比如对于某些依赖约束，把方程2的不等式改成等式，因此会少一些松弛），这可能导致更高的时延，甚至更低的吞吐率（如果满足这些新约束的可行调度没办法找到的话）。我们把ILP形式化工作的改善留给未来的工作。

5.2 存储集合

一个dRMT存储集合组织的像单个RMT阶段里面的存储。每个内存集合有一组内存块可以组合之后构建更宽更深的逻辑表。存储块的参数和RMT是相同的。一般来说处理器数量和存储集合的数量是一样的，但是架构允许这两个数不一样。

5.3 crossbar

crossbar连接处理器和存储。每个时钟周期，一个处理器可以产生最多M=8个b=80比特的key段，然后期望从存储集合当中产生8个10比特指令指针加上8个96比特动作数据段。crossbar的配置是基于调度算法的结果在编译的时候静态的编程的。

crossbar类型。当设计dRMT架构的时候，我们考虑了各种crossbar的类型和他们的优缺点。如图12:

（1）单位crossbar：在处理器和存储集合之间是1对1连接。

（2）段crossbar：在一个处理器的第k个索引是key（动作数据）段，对应存储集合上的第k个段。这个等价于k并行单位crossbar，每个段一个。

（3）全crossbar：一个处理器上的任何段对应存储集合上的任何段。从存储集合上的表项分配角度看，这给了我们完整的灵活性。

另外，对于上述任意一个提到的存储类型，我们考虑1对多组播crossbar。一个1对多crossbar使得处理器可以一次访问多个存储集合，而不需要额外的时延。这是的大表可以被分布到多个存储集合，但是还是可以通过一次匹配操作去访问。

尽管段crossbar看起来比全crossbar更不灵活，我们可以证明以下的结果：

理论5.1:段crossbar和full crossbar是等价的如果满足：(1) 没有匹配表跨过存储集合。（2）每个处理器发送，对应每个存储集合接收最多M个key段。

尽管我们可以找到例子来说明两种crossbar是不一样的，比如有一个表需要跨过存储集合。这个理论还是表明在实际当中大多数的例子两种crossbar没什么不同。我们选择组播段crossbar，因为它和全crossbar的表达能力是类似的，但是段crossbar所使用的芯片面积和功耗要少的多。表4详细的描述了不算入连线所需要的逻辑门的面积（表6是包含连线的段corssbar的面积，包含连线之后，不同crossbar面积比例和没包含之前是类似的）。

6 硬件成本

现在我们评估一下dRMT硬件实现的成本，并且和RMT设计进行比较。当前，对于这种高性能芯片的最主流的制程技术是16纳米。就像我们之前提到的，我们并没有实现dRMT。为了获取芯片面积的估计，我们以1.2G时钟周期作为目标，编码了样本逻辑并通过Synopsys Design Complier综合了。我们揭示了dRMT和RMT芯片面积的差异是很小的。我们的计算只考了了RMT和dRMT的处理器部分，我们没有考虑相同的设计元素，比如存储集合，SerDes，以太网MAC逻辑和包buffer存储。芯片面积和成本的关系的讨论可以看文章24的第一章。图5总结了处理器内部主要组件的面积。

我们综合了dRMT ALU的一个设计，芯片面积大小和表中的类似。因为我们不知道RMT架构ALU完整的操作集合，关于RMT的数据是基于RMT的估计，也就是ALU占用整个芯片7%的面积，这个芯片有32个流水线阶段和每个阶段有224个ALU。

我们基于Gibb的文章，估计整个RMT芯片的面积是200平方毫米，然后从28nm切换到16nm制程（我们必须在这里做一些假设来比较芯片面积，因为RMT没有提到ALU具体的面积）。我们预估使用RMT 42%的ALU芯片面积。这超过了所有涉及的ALU数量32/224，因为dRMT的32比特ALU相对RMT的8比特和16比特ALU要大一些。

RMT当中的包头向量是每个阶段20个包向量的一个简单的移位寄存器，对应18个时钟周期的匹配时延和2个周期的动作时延。对于dRMT来说，匹配时延是22个时钟周期，因为加上了额外的4个时钟周期用来穿过crossbar。另外，在我们的P4程序调度实验中，我们看到有些例子每个处理器最多需要29个包（也就是线程），为了满足调度约束，因为引入了no-ops。这比RMT要多，因为使用了更多的处理器资源。因此我们假设dRMT架构每个处理器最多32个线程，对应每个处理器最多32个包向量。

dRMT包头向量每bit存储需要更多的面积，主要因为额外的读写端口需求。比如IPC=2的时候，每个时钟周期我们需要读2个不同的向量来构建匹配key，加上2个动作，并为另外两个包做写回。这样有4个读和两个写。

表6给出了多个处理器全部的芯片面积。它还给出了组播crossbar的面积，这个crossbar连接处理器和存储集合，对应相应的处理器数量和32个存储集合。

我们当前存在商业的设计，包含16个处理器和16个存储集合，有相似的33%的使用率。我们详细的分析了在存储集合当中通过SRAM手工路由crossbar可以让变成一个更大的32*32的crossbar。详细内容请看长文版本。

表7估计了crossbar的功耗。这是通过Synopsis PrimeTime基于相同的16nm技术得到的。1.2G时钟频率，0.9V，50%交换系数，这是最极端的情况，也就是每个时钟周期所有的数据比特都改变值。算上面积和功耗，商用交换ASIC会占用300-700平方毫米，消耗150-350W。

7 相关的工作

dRMT的设计有点像网络处理单元（NPU）和多核软件路由器，都是共享内存加一组处理器核心。就像CPU和NPU核心一样，每个dRMT核心有本地指令存储和一个存储数据的scratch pad。但是，NPU缺乏确定性的性能保证，并且历史上一直比线速交换机慢。一个NPU的不确定性来自于多个方面：缓存不命中，处理器存储互联竞争，每个核心对流水线的冲洗等等。dRMT定制的crossbar是在编译时被调度的，这消除了竞争，因此是确定性的。另外，通过基于dRMT的VLIW指令集（来自RMT）dRMT相对NPU来说更加有效的利用了包处理当中的并行性，NPU就会有性能问题，因为他们的指令集有点类似传统的CPU。

Cavium的XPliant和Barefoot的Tofino是两个能够支持多Tbit/s速度的商用产品。基于公开的文档，他们都是用类似于RMT的流水线。从这些文档中看，他们在流水线和表存储之间有没有使用crossbar不清楚。如果是的话，就像我们分析dRMT那样，crossbar会带来相似的额外的面积和功耗成本。提供解耦的存储，在处理大表的时候，会有更好的流水线处理资源的使用率。但是Xpliant和Tofino架构在一次流水线操作不够的情况还是会有性能滑坡问题。

之前的工作22已经用ILP公式研究了编译P4程序到RMT架构。这个ILP公式需要在满足表依赖的情况下为逻辑P4表处理存储分配问题。dRMT通过crossbar解耦了存储分配问题和计算调度问题。本质上，把编译问题变成2个独立的ILP，一个是存储分配，一个是计算调度。

在运筹学领域已经对循环调度问题进行了广泛的研究。在一个循环调度问题当中，一组任务需要在有限数量的时间内被执行，但是同时要满足任务依赖和资源约束。循环调度的目标是最大化稳态吞吐率，也就是一个相同的任务实例可以多么频繁的被执行。我们的问题也是类似的，任务对应匹配动作操作。我们的公式和标准的循环调度问题不一样，它引入了包处理特有的约束：我们用IPC参数限制了可以并行被处理的包的数量。

8 总结

这个文章给出了RMT，一个新的高速可编程交换机的架构。dRMT的核心是2种解耦合：存储解耦合，我们把处理器当中的存储取出来放到一个共享的存储池；计算解耦合，我们允许每个处理器以任意顺序执行匹配动作操作，只要满足程序依赖。我们在dRMT上下文上讨论了解耦合，但是它可以更加广泛的使用。比如，保留RMT流水线，但是添加一个共享的存储池来提高RMT的存储使用率。相似的，解耦合单个RMT表格当中的匹配动作，然后放到不同的阶段当中（也就是细粒度RMT架构）减少了RMT阶段的数量。