更灵活，拓展性更高：回炉重造的DPDK Packet Framework

作者简介：张帆

背景

2015年，DPDK Packet Framework面世。截至DPDK 18.02，Packet Framework以Open Flow的设计理念为导向，将常见的网络应用的实现拆分成不同的查表操作（ACL,LPM,HASH等）及行为（Action），然后将其聚合抽象成若干流水线功能模块（pipeline），如Pass Through，流分类，防火墙等。各功能模块之间用网络接口的抽象队列（queue）相连接，再加上入口和出口的网络接口抽象port，组成一个完整的网络应用。

Packet Framework同时还包含一个范例程序IP Pipeline，该范例支持预先网络应用搭建的脚本解析及应用生成，及运行期配置的CLI命令解析及应用等，并能实现网络流的Traffic Management，Metering等高级功能。IP pipeline程序可灵活配置相同或不同的CPU核心来运行不同的Pipeline模块，以达到最大性能。Packet Framework的系统结构如图1，其中浅棕色块代表一个CPU线程，深蓝色块为不同的Pipeline，浅蓝色块为不同的表，最后深棕色块为不同的Action。

这个系统最大的优点，就是快速的网络应用开发和配置。因为该系统抽象了几乎所有DPDK程序所必须的元素，如Mempool, port等，配置一个简单的L2Xfwd应用仅需如图二所示的8行脚本即可。图二中我们指定了两个CPU核心，其中Core 0用来运行控制面子程序，包括解析CLI命令，或者统计信息等。Core 1运行数据面子程序，即一个简单的Pass-through Pipeline工作。

然而，Packet Framework并非全是优点。将不同表及行为打包成一个Pipeline实例的方法固然方便，但不够灵活：既无法将表项和行为解耦，也无法灵活快速地二次开发一套新的行为。对于快速迭代的网络环境Packet Framework也无能为力：在程序启动后，我们无法在不关闭软件的前提下再为系统增加一个Pipeline，或者改变Pipeline的拓扑等。这些限制使得彼时的Packet Framework对复杂度较高的网络应用如VBNG的二次开发较为困难。倘若用户对其应用有更高的定制化要求如多重网络帧封装等，Packet Framework会显得无能为力。

要命的是，DPDK18.05之前的Packet Framework，特别是IP Pipeline应用已经固化，我们无法在不改变其基础结构又使之能适应我们对灵活性和可延展性的需求。因此，我们不得不对Packet Framework进行重新设计，回炉重造。

新Packet Framework和IP Pipeline

我们把新Packet Framework的设计理念基石定义如下：

• 新Packet Framework仍将基于Open Flow的设计理念。
• 在pipeline, table和port中我们需要再增加一类抽象，action，及行为。我们需要能对不同的行为进行定义，并提供高可用度的接口以便快速开发新的行为。
• Pipeline不再作为一个运行实例，而仅仅是Table的容器，它以port为网络帧的入口和出口，之间可任意链接不同数量的table和action。
• 引入新的Action profile概念，用来定义相同行为的一类Action。这样不同的Table可套用相同的Action Profile来定义其能实现的一种Action。
• 抛弃构建应用脚本，所有的系统搭建及表项配置等均用CLI命令完成以最大化灵活度。
• 除了自带的CLI命令解释器，新的Packet Framework也应能支持如OpenBras, OpenDaylight等第三方控制面软件的介入。

新的Packet Framework结构最终如图3所示。乍一看和图1没有什么区别，但结合以上的设计理念，我们可以看到：

• 再无固定功能Pipeline，仅固定功能的Action。
• 一个Pipeline内可有任意不同Match-Act Table。
• 一个Pipeline内各Action之间可耦合。

而与之对应的，IP Pipeline应用则有了非常大的改变。我们先看一下系统结构图，如图4：

• 程序启动时会建立一个TCP服务器用来接收并处理外部客户端发送的命令，用户可通过TELNET/NETCAT的应用，或通过第三方控制面软件的外部代理插件（暂时未适配）将配置操作翻译成其可识别的命令，发送至该服务器来完成配置。
• Pipeline, Table, Action和Port在运行期间用命令生成/删除，再无启动脚本。
• 每个工作线程有独立的Message Queue来接收并处理线程相关命令配置更新
• 每个Pipeline有独立的Message Queue来接收并处理对其Table, Action，及port的配置更新。

这样，新的Packet Framework在延续其性能优点的同时最大化了其灵活性和可延展性的优点。

如何使用新的IP Pipeline程序来生成网络应用

首先，你需要编译DPDK及IP Pipeline范例程序，这里不作赘述，IP Pipeline子程序位于dpdk/examples/ip_pipeline文件夹内。

然后IP Pipeline程序就可以运行了，运行命令为

ip_pipeline [EAL_ARGS] — [-s SCRIPT_FILE] [-h HOST] [-p PORT]
其中EAL_ARGS为标准DPDK的EAL参数。

-s：用于指定初始化运行的脚本路径，该脚本可包含用于构建初始化Pipeline功能组件时的命令。这些命令也可在程序初始化完成后输入，因此该参数不是必须的。
-h：本体TCP服务器的IP地址，缺省为0.0.0.0
-p：本体TCP服务器的TCP端口号，缺省为8086

程序启动完成后，用户可通过TELNET/NETCAP应用通过既定IP地址和端口号来发送命令。以下是一个简单的命令集范例：

01: mempool MEMPOOL0 buffer 2304 pool 32K cache 256 cpu 0
02: link LINK0 dev 0000:02:00.0 rxq 1 128 MEMPOOL0 txq 1 512
03: …
04: table action profile AP0 ipv4 offset 270 fwd
05: pipeline PIPELINE0 period 10 cpu 0
06: pipeline PIPELINE0 table match lpm … action AP0

以上的命令片段分别创建了一个mempool对象MEMPOOL0，一个link对象LINK0，一个使用简单转发行为的Action profile对象AP0，一个Pipeline对象PIPELINE0，以及PIPELINE0中的一个套用AP0行为的LPM表（该表并无名字，系统既定其ID为PIPELINE0中的表0）。

07: pipeline PIPELINE0 port in bsz 32 link LINK0 rxq 0
08: pipeline PIPELINE0 port out bsz 32 link LINK0 txq 0
09: pipeline PIPELINE0 port in 0 table 0

以上07-09行命令将刚创建的对象连接了起来，其中07行将PIPELINE0的输入端定义为LINK0的队列0（rxq 0），在第8行对输出端也做了相同的定义。在第9行，我们把PIPELINE0中表0绑定的到其输入端接口上。

10: thread 1 pipeline PIPELINE0 enable

以上命令使PIPELINE0开始在第二个CPU CORE中运行起来(thread 1)。该CPU CORE由启动程序时的EAL参数指定。

11: pipeline PIPELINE0 table 0 rule add match lpm … action fwd port 0
12: pipeline PIPELINE0 table 0 rule add match default action fwd port 1

以上命令为PIPELINE0中的表0加入两个转发规则，第11行我们加入一个具体的LPM表项（表项内容省略），符合该规则的网络帧将被转发到port 0。第12行将所有接收到的网络帧缺省转发到port 1。请注意第7和第8行命令中，我们只定义了port 0，因此该行命令实际意义是丢弃所有不符合第11行定义规则的网络帧。至此一个简单的网络应用配置就完成了。当然Pipeline不只能干这些，更为详细的说明请参看http://doc.dpdk.org/guides/sample_app_ug/ip_pipeline.html

结语

DPDK Packet Framework目前能做的更多了。转发和路由等不在话下，VSWITCH和VBNG类的应用也没有问题。在DPDK 18.08，我们计划加入SOFTNIC，即在一个DPDK的网卡PMD中运行PACKET FRAMEWORK，在无缝连接已有的DPDK程序的同时还加入能灵活配置的强大网络帧处理功能。在未来我们更会加入对CRYPTO和VIRTIO的支持。