论文阅读：FlowBlaze: Stateful Packet Processing in Hardware
摘要：
尽管可编程NIC可以提供更好的可扩展性以处理不断增长的网络工作量，但为硬件中的有状态网络功能编程提供表达能力却又简单的抽象仍然是一项研究挑战。
我们使用FlowBlaze解决了这个问题，FlowBlaze是一种开放式抽象，用于在硬件中构建有状态的数据包处理功能。该抽象基于扩展有限状态机（EFSM），并引入了流状态的显式定义，从而允许FlowBlaze利用流级并行性。 FlowBlaze具有表现力，支持各种复杂的网络功能且易于使用，对程序员隐藏了底层硬件实现问题。
我们在NetFPGA SmartNIC上实现FlowBlaze，实现了极低的延迟（大约几微秒），消耗的功率相对较小，可以保持成千上万个流的每个流状态，并产生40 Gb / s的速度，从而在更新的FPGA型号上实现更高的速度。
背景/问题：
网络基础设施需要一组不断发展的网络功能才能可靠地运行。鉴于现代网络的灵活性以及持续支持新应用程序的需求，运营商已转向此类功能的纯软件实现，这具有许多好处，包括可编程和易于管理。虽然网络操作必不可少，但网络功能会带来开销，而且由于它们位于网络流的路径上，因此它们增加了网络数据包的端到端延迟，并增加了运行基础架构的总体成本，需要额外的计算资源，即CPU内核。
为了解决这个问题，过去几年来，人们引入了高效的可编程网络设备，这些设备可以减轻CPU处理网络数据包的负担。例如，微软在其数据中心中部署了基于FPGA的SmartNIC。这些设备可以节省CPU使用率并减少服务器PCIe总线上的流量，从而将网络功能的数据包处理延迟提高了一个数量级以上。不利的一面是，对SmartNIC进行编程以支持新的网络功能需要硬件设计专家，尽管技术巨头可以组建并分配一个专门的团队来完成任务，但大多数公司无法做到。
最近的网络编程抽象（例如P4）的明确目标是简化基于FPGA的网络设备的编程。但是，它们在描述需要保持每流状态的网络功能方面有局限性。
解决办法：
引入FlowBlaze（一种扩展了诸如P4或Microsoft的GFT之类的匹配动作语言的抽象）来解决这些缺点，以简化对L2-L4大状态函数集的描述，同时使它们适合在基于FPGA的SmartNIC上的实现（以线速实现）。
FlowBlaze的目标是提供一种系统，使几乎没有硬件设计专业经验的程序员可以在基于FPGA的SmartNIC上快速实现或快速更新无状态和有状态的数据包处理功能。
FlowBlaze针对以下四个要求（四个要求依次记为R1-R4）：
-
高性能：支持网络功能，这些功能可实现40-100Gb / s的吞吐量，同时每个数据包的处理延迟最多为几µs。
-
状态可伸缩性：支持在细粒度的每流状态下运行的功能，并能够存储大量网络流（例如，最多100K）的流状态，流的数量不应影响处理延迟。
-
易于使用：允许程序员仅专注于实现所需的功能，而不会陷入棘手、耗时的硬件性能优化。此外，硬件约束对应用程序设计的影响很小，并且程序员几乎不需要硬件设计专业知识来实现功能。
-
富有表现力：系统的编程抽象应允许用户描述各种潜在的有状态功能，包括复杂的功能（例如，异常检测，连接跟踪等）。
实现细节：
考虑到这些要求，我们回顾了现有技术，发现对于FPGA目标，现有系统仅部分满足这些要求（参见下表）。
实际上，我们可以将先前的方法分为两类：
通用编程框架：通用编程框架是完全依赖于FPGA重新编程功能来实现新功能的解决方案，着眼于简化FPGA编程的语言和框架。在这里，我们包括硬件描述语言（HDL）和高级综合（HLS）系统。 HDL（例如Verilog）是FPGA的低级编程方法，像基于OpenCL的HLS系统一样，可以通过采用高级语言来提高易用性（R3），但是需要硬件专业知识，因为必须正确设计和注释代码以确保综合过程成功提供高性能实现。此外，更新功能需要对FPGA设计进行新的综合和更新，而这一过程需要数小时的时间。
匹配动作抽象：匹配动作抽象是基于匹配动作表（MAT）模型。 MAT是一种有效且广泛应用的工具，可将网络功能描述为由解析器和可变数量的match和action块组成的管道。解析器和动作逻辑通常相当稳定，因此可以在配置时进行编程，而匹配表的条目则在运行时插入，可用于即时更改功能的实现。 MAT是描述L2-L4网络功能的好工具，但是当前可用的MAT抽象仅支持无状态功能，因此程序员无法依赖于先前接收到的包的功能指定下一个包的处理。
我们一次满足所有四个要求吗？ MAT的广泛应用表明，它们可能是提供有效抽象来描述网络功能的良好起点，并且像Domino一样已经朝着扩展MAT以支持有状态功能的方向发展。 因此，我们的问题归结为在匹配动作抽象中支持每个流状态。
诚然，FAST 和OpenState 遵循此方向来提供有状态的数据包处理抽象，从而明确定义流状态。在这两种情况下，数据包都被分组在程序员定义的网络流中（如MAT中），并且流与有限状态机（FSM）关联，然后程序员定义FSM的过渡表，该表用于在处理数据包时更新相应FSM的状态，按照这种推理，FSM似乎是将无状态MAT转换为有状态元素的不错选择。不幸的是，FSM是不可扩展的（R2），FSM由状态集S，输入I，输出O以及转换关系T描述：S×I→S×O。由于FSM需要明确定义所有可能的状态si∈S，因此系统在这种情况下可能会发生称为状态爆炸的现象。
The FlowBlaze Abstraction
为了在提供可扩展的抽象的同时保留FSM的大多数优良特性，我们求助于扩展有限状态机（EFSM）。
EFSM通过引入以下内容扩展了FSM模型：
-
变量D以描述状态
-
使此类变量上的函数F触发转换（fi：D←{0,1}，fi∈F）
-
更新变量值的函数（ui：D←D，ui∈U）
EFSM的过渡关系表示为T：S×F×I→S×U×O
尽管采用EFSM可以部分解决状态爆炸问题，但我们仍然需要对其进行调整以确保高效的硬件实现。 我们需要解决两个问题：
-
状态可伸缩性：标准EFSM对于系统中的每个流程都需要一个单独的过渡表（即EFSM的说明）
-
流并行性：EFSM状态定义不包括流状态的概念，这是我们需要利用流级并行性的概念。
Machine Model
FlowBlaze的机器模型（参见下图）扩展了RMT 描述的MATs管道模型。与RMT一样，FlowBlaze数据包头（包括数据包元数据）通过管道的元素进行处理以定义转发动作，每个元素可以是无状态的或有状态的。无状态元素是MAT，类似于RMT1中使用的元素，有状态元素实现EFSM定义，管道可以结合无状态元素和有状态元素。
有状态元素的体系结构与MAT有两个显着区别：（1）这种元素在通常的匹配部分之前具有流上下文表（2）该元素将动作分为（状态）更新功能和数据包动作。
更详细地，如上图所示（标记为“有状态元素”的框），数据包处理涉及以下顺序步骤：
-
流上下文表：当数据包头进入元素时，它与相应的流上下文相关联。
-
EFSM表：数据包的标头和元数据以及提取的流上下文将传递到EFSM表。该表是传统MAT的扩展，除了支持在打包程序标头字段上进行匹配外，还可以在状态标签s上进行匹配并评估启用功能。
-
更新功能：标头和元数据，更新指令以及状态标签的新值将传递到更新功能块。
-
行动：像在MAT中一样，此块将操作应用于数据包头。与MAT不同的是，流上下文寄存器的值以及全局寄存器的值也可以被使用。
FlowBlaze Programming
FlowBlaze在NIC中直接部署，其编程类似于对P4设备进行编程。在配置时，程序员必须定义解析器，MAT和EFSM转换表的匹配字段以及操作，这些操作现在还包括状态更新功能，改变这些组件需要对FPGA设计进行新的综合。
幸运的是，这些是函数更改频率较低的部分。在运行时，程序员通过配置有状态元素的流定义，选择已解析的标头字段的子集并将所需的条目写入MAT和EFSM转换表中，来定义其网络功能的逻辑，这类似于P4和OpenFlow设备的运行时编程。实际上，我们扩展了OpenFlow协议，以便从基于python的RYU OpenFlow控制器中写入此类条目。
值得强调的一件事是，程序员可以快速地实验和更新其功能逻辑，因为对网络功能逻辑进行编程就像将表写入条目一样快，与其他的解决方案不一样，这需要更新一个的综合的FPGA设计。
讨论与思考：
FlowBlaze始终会具有一定的硬盘限制，例如DoS攻击可能会利用这些限制。为了解决这个问题，FlowBlaze提供了一些原语，程序员可以使用它们来明确处理“流上下文表”已满的情况。例如，实现功能之前可以实现带有SYN泛洪检测功能的元素，以便可以丢弃执行SYN攻击的主机的流量，从而避免在Flow中创建大量后续元素的上下文表条目。
