Summary:
Although programmable NIC can provide better scalability to handle the growing workload of the network, but for the hardware stateful network features programming provides a simple yet expressive abstraction remains a research challenge.
We use FlowBlaze solve this problem, FlowBlaze is an open abstraction for building stateful packet processing functions in hardware . The abstract based extended finite state machine (of EFSM), and the introduction flow state explicitly defined, so as to allow FlowBlaze using flow level parallelism. FlowBlaze expressive, support a variety of complex network functions and easy to use, the programmer hides the underlying hardware problem.
We implemented on NetFPGA SmartNIC FlowBlaze, deliver very low latency (about several microseconds), the power consumption is relatively small, the state may be maintained for each stream thousands of streams, and generates a 40 Gb / s speeds in order to achieve higher speeds on newer FPGA models.
Background / problem:
Network infrastructure requires a set of network capabilities evolving in order to operate reliably. Given modern network flexibility and sustained support new application requirements, operators have turned to pure software implementation of such functions, which has a number of benefits, including programmable and easy to manage. Although the network essential to its operation, but the network will bring the cost function, and because they are located on a network flow path, so they increase the network packets end to end delay, and increases the overall cost of operating the infrastructure needs additional computing resources , that is, the CPU core .
To solve this problem, in the past few years, it is the introduction of efficient programmable network devices that can reduce the burden on CPU processing network packets. For example, Microsoft deployed FPGA-based SmartNIC in its data center. These devices can save CPU usage and reducing traffic on the server PCIe bus, so that the function of the network packet processing delay increased by an order of magnitude. The downside is, Dui SmartNIC program to support new network features require hardware design experts , although the technology giant can set up and assign a dedicated team to complete the task, but most companies can not do.
Clear objectives nearest network programming abstractions (eg P4) is to simplify the FPGA-based network device programming. However, they describe the need to maintain per-flow state network function limitations aspect.
Solution:
Introducing FlowBlaze (such as P4 or an extended abstract language matching operation or the like of Microsoft GFT) to address these shortcomings, to simplify the description of the state of the L2-L4 large set of functions, while making them suitable for the FPGA-based SmartNIC implementation (in order to achieve wire speed).
FlowBlaze goal is to provide a system that allows experience almost no hardware design programmer may FPGA-based SmartNIC a rapid or fast updates implemented stateful and stateless packet processing capabilities .
FlowBlaze for the following four requirements (referred to as a four turn requires R4-Rl) :
-
High performance : support network functions that may be implemented throughput 40-100Gb s /, while the processing of each packet is delayed up to several μs.
-
Status Scalability : support running in fine-grained per-flow state, and capable of storing a large number of network flows (e.g., up to 100K) of the flow state, the number of streams should not affect the processing delay.
-
Ease of use : only allow programmers to focus on achieving the desired functionality, and not fall into the tricky and time-consuming hardware performance optimization. In addition, the impact of the hardware constraints on the application design is very small, and almost no programmer hardware design expertise to realize the function.
-
Expressive : programming abstraction system should allow a user to describe a variety of potential stateful functions, including complex functions (e.g., abnormality detection, tracking, etc. are connected).
Implementation details:
Given these requirements, we reviewed the prior art and found the target for FPGA, existing systems only partially meet these requirements (see table below).
In fact, we can previous methods fall into two categories:
General programming framework: common programming framework is entirely dependent on the FPGA reprogramming capabilities to implement solutions of new features, focusing on simplifying FPGA programming languages and frameworks. Here, we include a hardware description language (HDL) and high-level synthesis (HLS) system. HDL (such as Verilog) is a low-level FPGA programming method, like OpenCL based on the HLS system as possible to improve the ease of use (R3) through the use of high-level language, but requires hardware expertise , as must be properly designed to ensure a comprehensive and commented code provide high-performance implementation process was successful. In addition, the update feature of the FPGA design requires a new comprehensive and updated, and this process takes a few hours.
Match Action Abstract: matching operation is based on matching the abstract operation table (MAT) model. MAT is an effective and widely used tool, the network function can be described by the parser and variable number of action blocks match and the pipe. Parser and action logic are often quite stable, and therefore can be programmed at the time of configuration, the match table entry is inserted at run time, it may be used to implement the functions of the instant change. MAT is described network function L2-L4 good tool, but the currently available MAT abstraction supports only stateless function , so that programmers can not rely on the function of the previously received packet processing in a packet specified.
Once we meet all four requirements? MAT wide range of applications suggests that they may provide a good starting point for effective abstractions to describe network functions, and the like have been moving in the same Domino MAT extension to support the development direction of state functions. So our problem is reduced to support each flow state in the matching operation in the abstract.
Indeed, FAST OpenState follow this direction, and provided with the abstract state of packet processing, so that a well-defined flow state. In both cases, the packets are grouped in a programmer-defined network flow (e.g., the MAT), and the stream with the finite state machine (FSM) is associated , then the programmer defines the FSM transition table that is used FSM update corresponding data packet when processing state, according to this reasoning, it seems FSM is converted into a stateless good choice MAT stateful elements. Unfortunately, FSM is not extensible (R2), FSM T is described by the set of states S, the input I, output O, and conversion relationship: S × S × the I → O . Because of FSM requires a clear definition of all possible states si∈S, so the system in this case may be said to occur state explosion phenomenon.
The FlowBlaze Abstraction
In order to retain the most excellent characteristics in the FSM provides scalable abstraction at the same time, we turn to extended finite state machine (EFSM) .
EFSM by introducing the following extended FSM model:
-
To describe the state of the variable D
-
Such function F so that the trigger variable conversion (fi: D ← {0,1}, fi∈F)
-
Update function of the value of the variable (ui: D ← D, ui∈U)
EFSM transition relation is expressed as T: S × F. The I → S × × × the U-O
Although the use of EFSM may be a partial solution to the state explosion problem, but we still need to be adjusted to ensure efficient hardware implementation. We need to solve two problems:
-
Status Scalability : EFSM standard for each process in the system requires a separate transition table (i.e. EFSM description)
-
Flow Parallelism : EFSM definition does not include the concept of a state of the flow state, which we need to use the concept of parallelism flow level.
Machine Model
FlowBlaze machine model (see below) extended MATs tube model RMT described. Like the RMT, FlowBlaze header data (including metadata packets) processed by pipeline elements to define the forward operation, each element may be stateless or stateful. MAT element is stateless, RMT1 similar elements used in the definition of stateful elements implemented EFSM, conduit elements may be incorporated stateless and stateful elements.
There Architecture and MAT state of the element has two significant differences: (1) the context of this element has a flow table before the normal mating portion (2) into which the operation element (state), and updates the data packet operation.
In more detail, as shown above (labeled "stateful element" box), packet processing involves the following sequential steps:
-
Flow context table: When entering the header element, which is associated with a respective flow context.
-
Table EFSM: headers and metadata packets and a stream is passed to context extractor EFSM table. The table is an extension of traditional MAT, in addition to supporting matched packager header fields, can also be matched in the state of the label s and enable evaluation function.
-
Update Function: headers and metadata, tag status update instruction and new updated value will be passed to the function block.
-
Action: the same as in the MAT, the operation to the block header. And MAT difference is that the value of the global register values, and registers the stream context may also be used.
FlowBlaze Programming
FlowBlaze在NIC中直接部署，其编程类似于对P4设备进行编程。在配置时，程序员必须定义解析器，MAT和EFSM转换表的匹配字段以及操作，这些操作现在还包括状态更新功能，改变这些组件需要对FPGA设计进行新的综合。
幸运的是，这些是函数更改频率较低的部分。在运行时，程序员通过配置有状态元素的流定义，选择已解析的标头字段的子集并将所需的条目写入MAT和EFSM转换表中，来定义其网络功能的逻辑，这类似于P4和OpenFlow设备的运行时编程。实际上，我们扩展了OpenFlow协议，以便从基于python的RYU OpenFlow控制器中写入此类条目。
值得强调的一件事是，程序员可以快速地实验和更新其功能逻辑，因为对网络功能逻辑进行编程就像将表写入条目一样快，与其他的解决方案不一样，这需要更新一个的综合的FPGA设计。
讨论与思考：
FlowBlaze始终会具有一定的硬盘限制，例如DoS攻击可能会利用这些限制。为了解决这个问题，FlowBlaze提供了一些原语，程序员可以使用它们来明确处理“流上下文表”已满的情况。例如，实现功能之前可以实现带有SYN泛洪检测功能的元素，以便可以丢弃执行SYN攻击的主机的流量，从而避免在Flow中创建大量后续元素的上下文表条目。