作者介绍

Yochai Hagvi：英特尔网络平台组的产品支持工程师，DDP FW技术主管。

Andrey Chilikin：软件架构师，为电信和企业通信行业开发和提供新的网络技术和解决方案。

Brian Johnson：解决方案架构师，专注于定义数据中心网络、虚拟化和云技术中的网络解决方案和最佳实践。

Robin Giller: 英特尔网络平台组的软件产品经理。

简介

为了满足云和网络功能虚拟化不断变化的需求，全新设计的英特尔®以太网700系列支持更高的灵活性和灵敏性。该系列的一个设计目标是将部分英特尔®以太网500系列、82599、X540和X550中使用的固定管道转移到一个可编程的管道，可对英特尔以太网700系列进行定制以满足各种客户要求。因为这样的可编程性，相同的核心硅芯片上可实现60多种独特的配置。

虽然为市场提供了这么多种配置，随着它在电信市场中扮演着越来越重要的角色，英特尔®架构还需提供更多自定义的功能，其中呼声最高的是用户自定义的新数据包分类类(PCTYPE’s)，此功能目前暂不受支持，甚至还没有完整的定义。英特尔以太网700系列网络适配器已启用新功能——动态设备个性化（DDP），来解决这一问题。

本文介绍如何使用数据平面开发工具包（DPDK）来配置DDP profile。本文主要介绍的是GTPv1 profile。它可以用来提高性能，并优化虚拟化演进分组核心网（vEPC）和多接入边缘计算（MEC）的cpu利用。

DDP允许动态重新配置包处理管道，以满足特定用例。运行时向网络适配器添加新的包处理管道配置profile，无需重置或重启服务器。软件以一种非永久性、交互式模式应用这些自定义profile，因此在网络适配器重启或软件回退profile后，将恢复网络控制器的原始配置。DPDK提供了处理DDP包需要的所有API。

因为可以对新数据包类型进行分类，并将这些数据包分发到设备指定的队列，这提高了性能及CPU利用率：

·        不再要求主机CPU对指定的用例执行数据包类型的分类和负载均衡。

·        增加数据包吞吐量; 减少数据包延迟。

在服务器上存在多个网络控制器的情况下，每个控制器可以有自己的管道profile，而且应用时不会影响其他控制器和使用其他控制器的软件应用程序。

DDP用例

网络控制器运用DDP profile可以解决以下用例。

新的PCTYPE(flow type)用于网络控制器的包分类：

o   除TCP / UDP / SCTP之外的IP协议; 例如，IP ESP（Encapsulating Security Payload）、IP AH（authentication header）

o   UDP协议; 例如，MPLSoUDP（MPLS over UDP）或QUIC（Quick UDP Internet Connections)

o   TCP子类型，如TCP SYN-no-ACK（Synchronize without Acknowledgment set）

o   隧道协议，如PPPoE（Point-to-Point Protocol over Ethernet），GTP-C / GTP-U（GPRS Tunnelling Protocol-control plane/-user plane）

o   特定协议，如以太网无线电

识别数据包的新数据包类型：

o   IP6（因特网协议版本6）、GTP-U、IP4（因特网协议版本4）、UDP、PAY4

o   IP4，GTP-U，IP6，UDP，PAY4

o   IP4，GTP-U，PAY4

o   IP6，GTP-C，PAY4

o   MPLS（多协议标签交换），IP6，TCP，PAY4

DDP GTP示例

可以用交互模式更新原有的固件配置。加载新profile后，网络控制器会返回先前的配置，因此在运行时可以通过回退profile来恢复，如图2所示。

个性化profile处理步骤：

1.     原始固件配置; 没有应用profile

2.     在应用新profile时，固件会在profile的缓冲区中返回原始配置。

3.     将返回的配置写回硬件后，恢复原始状态。

固件和软件版本

DDP要求使用英特尔以太网700系列网络适配器最新的6.01版固件。

DPDK 17.05可支持将DDP profile应用于英特尔以太网700系列网络适配器。DPDK 17.08和17.11引入了更高级的DDP API，比如不需将profile加载到英特尔以太网700系列网络适配器上就可以报告profile的信息。在不需要完全支持DPDK rte_flow API协议的情况下，这些API也可适用于新的profile。

从2.7.26版本开始，PCIe * 40千兆以太网网络连接的英特尔®网络适配器的Linux驱动支持通过ethtool加载和回退DDP profile。

GTPv1 DDP文件可在英特尔®下载中心下载。请联系当地的英特尔技术支持询问其他DDP profile的相关信息。

DPDK API

下面3个函数实现于DPDK 17.08：

rte_pmd_i40e_process_ddp_package（）：该函数的功能是下载并注册一个DDP profile，或者回退并注销一个profile。

int rte_pmd_i40e_process_ddp_package(

uint8_t port,

uint8_t *buff,

uint32_t size,

rte_pmd_i40e_package_op op  add, remove, write profile *

);

rte_pmd_i40e_get_ddp_info():该函数的功能是在无需下载profile到网络适配器上就能获取该profile的相关信息。

int rte_pmd_i40e_get_ddp_info(

uint8_t *pkg_buff,  /* buffer with the package in the memory */

uint32_t pkg_size,  /* size of the package buffer */

uint8_t *info_buff, /* buffer to store information to */

uint32_t info_size, /* size of the information buffer */

enum rte_pmd_i40e_package_info type /* type of required information */

);

rte_pmd_i40e_get_ddp_list()：使用该函数获取已注册profile的列表。

int rte_pmd_i40e_get_ddp_list (

uint8_t port,  /* DPDK port index to get list from */

uint8_t *buff, /* buffer to store list of registered profiles */

uint32_t size  /* size of the buffer */

);

DPDK 17.11额外增加了一些与DDP相关的功能：

rte_pmd_i40e_get_ddp_info(): 更新该函数后可以获取更多profile的相关信息。

添加了新的API，用来处理DDP profile创建的flow type：

rte_pmd_i40e_flow_type_mapping_update(): 将硬件的PCTYPE映射到DPDK  flow type上。

int rte_pmd_i40e_flow_type_mapping_update(

uint8_t port, /* DPDK port index to update map on */

/* array of the mapping items */

struct rte_pmd_i40e_flow_type_mapping *mapping_items,

uint16_t count, /* number of PCTYPEs to map */

uint8_t exclusive /* 0 to overwrite only referred PCTYPEs */

);

rte_pmd_i40e_flow_type_mapping_get():获取当前PCTYPE和DPDK flow type的映射关系。

int rte_pmd_i40e_flow_type_mapping_get(

uint8_t port, /* DPDK port index to get mapping from */

/* pointer to the array of RTE_PMD_I40E_FLOW_TYPE_MAX mapping items*/

struct rte_pmd_i40e_flow_type_mapping *mapping_items

);

rte_pmd_i40e_flow_type_mapping_reset(): 重置flow type映射表。

int rte_pmd_i40e_flow_type_mapping_reset(

uint8_t port /* DPDK port index to reset mapping on */

);

ethtool命令

需使用RHEL * 7.5及以上，或Linux *内核4.0.1及以上的版本。

应用profile时，请先将其复制到相对于固件根目录（通常是/lib/firmware）的intel/i40e/ddp目录上。例如：

然后用ethtool -f | --flash加上region参数100：ethtool -f 100。

例如：

可以用‘-’替代配置文件名的方式回退到之前加载的版本：

以后进先出的顺序(LIFO)删除profile来实现回退需求。详情请参阅驱动程序的readme.txt。

注意：ethtool DDP profile只能加载到第一物理口（PF0）上，但配置可以适用于适配器的所有端口。

通过testpmd使用DDP profile

我们将通过testpmd加载GTPv1 profile，并以此来演示英特尔以太网700系列网络适配器的DDP功能。该profile可通过英特尔®下载中心获取。请联系当地的英特尔技术支持获取其他DDP profile的相关信息。

虽然DPDK 17.11在rte_flow API层面上添加了带Ipv4负载的GTPv1 ，但我们使用较低级别的API，来演示在DDP支持但rte_flow不支持的新协议的情况下，如何直接使用英特尔以太网700系列网络适配器。

作为演示，我们需要具有以下配置的GTPv1-U数据包：

Source IP                1.1.1.1

Destination IP           2.2.2.2

IP Protocol              17 (UDP)

GTP Source Port          45050

GTP Destination Port     2152

GTP Message type         0xFF

GTP Tunnel id            0x11111111-0xFFFFFFFF random

GTP Sequence number      0x000001

-- Inner IPv4 Configuration --------------

Source IP                3.3.3.1-255 random

Destination IP           4.4.4.1-255 random

IP Protocol              17 (UDP)

UDP Source Port          53244

UDP Destination Port     57069

图3. GTPv1 GTP-U数据包配置。

如图3所示，由于外层IP地址和UDP端口是固定的，所以外层IPv4头的hash值不会改变。但是GTPv1报头隧道端点标识符（TEID）的数值在0x11111111到0xFFFFFFFF的范围里随机选取，而内层IPv4数据包的IP地址在1到255的范围里随机生成。

这里可以下载上述配置的GTPv1-U流的pcap文件——可在文中查看pcap文件。

我们会使用DPDK 17.11版本中最新版本的testpmd。 首先，启动testpmd，开启4个队列，切换到rxonly模式，并启用verbose模式和RSS：

testpmd -w 02:00.0 -- -i --rxq=4 --txq=4 --forward-mode=rxonly

testpmd> port config all rss all

testpmd> set verbose 1

testpmd> start

图4. Testpmd的启动配置。

使用支持GTP-U的流量生成器，发送四个GTP-U数据包。也可以使用提供的GTPv1-U流的pcap文件。

由于所有数据包都具有相同的外层IP报头，它们由队列1接收，并报告为IPv4 UDP数据包：

testpmd> port 0/queue 1: received 4 packets

src=3C:FD:FE:A6:21:24 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0xd9a562 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

src=3C:FD:FE:A6:21:24 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0xd9a562 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

src=3C:FD:FE:A6:21:24 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0xd9a562 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

src=3C:FD:FE:A6:21:24 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0xd9a562 - RSS queue=0x1 - hw ptype: L2_ETHER L3_IPV4_EXT_UNKNOWN L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - Receive queue=0x1

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

图5.没有GTPv1 profile的GTP-U数据包的分布。

我们可以看到，四个数据包的哈希值都相同，为 0xD9A562。这是因为外层IP报头中的IP源/目的地址和UDP源/目的端口是固定的，也不会因为数据包不同而不同，见图3。

现在我们将GTP profile应用于网络适配器端口。作为演示，我们假设已将profile包文件下载并解压到/lib/firmware/intel/i40e/ddp文件夹中。从gtp.pkgo文件加载该profile，原始配置会存储到gtp.bak文件中：

testpmd> stop

testpmd> port stop 0

testpmd> ddp add 0 /lib/firmware/intel/i40e/ddp/gtp.pkgo,/home/pkg/gtp.bak

图6.将GTPv1profile应用于设备。

'ddp add 0 /home/pkg/gtp.pkgo,/home/pkg/gtp.bak'指令先将gtp.pkgo文件加载到内存缓存区，作为rte_pmd_i40e_process_ddp_package()的参数，另一个参数是RTE_PMD_I40E_PKG_OP_WR_ADD，然后将原始配置返回到同一个缓存区，保存为gtp.bak文件。

如果设备的物理口0（PF0）上加载了Linux驱动程序，而testpmd使用了设备其他的物理口，则可以使用ethtool命令加载profile：

ethtool -f eth0 gtp.pkgo 100

我们可以确认profile是否已经成功加载：

testpmd> ddp get list 0

Profile number is: 1

Profile 0:

Track id:     0x80000008

Version:      1.0.0.0

Profile name: GTPv1-C/U IPv4/IPv6 payload

图7.检查设备是否加载了profile。

'ddp get list 0'命令调用rte_pmd_i40e_get_ddp_list()并打印返回的信息。

Track ID是profile特有的识别码，可区分各profile。

以下展示了如何获取由profile创建的新PCTYPE和数据包类型的相关信息：

testpmd> ddp get info /lib/firmware/intel/i40e/ddp/gtp.pkgo

Global Track id:       0x80000008

Global Version:        1.0.0.0

Global Package name:   GTPv1-C/U IPv4/IPv6 payload

i40e Profile Track id: 0x80000008

i40e Profile Version:  1.0.0.0

i40e Profile name:     GTPv1-C/U IPv4/IPv6 payload

Package Notes:

This profile enables GTPv1-C/GTPv1-U classification

with IPv4/IPV6 payload

Hash input set for GTPC is TEID

Hash input set for GTPU is TEID and inner IP addresses (no ports)

Flow director input set is TEID

List of supported devices:

8086:1572 FFFF:FFFF

8086:1574 FFFF:FFFF

8086:1580 FFFF:FFFF

8086:1581 FFFF:FFFF

8086:1583 FFFF:FFFF

8086:1584 FFFF:FFFF

8086:1585 FFFF:FFFF

8086:1586 FFFF:FFFF

8086:1587 FFFF:FFFF

8086:1588 FFFF:FFFF

8086:1589 FFFF:FFFF

8086:158A FFFF:FFFF

8086:158B FFFF:FFFF

List of used protocols:

12: IPV4

13: IPV6

17: TCP

18: UDP

19: SCTP

20: ICMP

21: GTPU

22: GTPC

23: ICMPV6

34: PAY3

35: PAY4

44: IPV4FRAG

48: IPV6FRAG

List of defined packet classification types:

22: GTPU IPV4

23: GTPU IPV6

24: GTPU

25: GTPC

List of defined packet types:

167: IPV4 GTPC PAY4

168: IPV6 GTPC PAY4

169: IPV4 GTPU IPV4 PAY3

170: IPV4 GTPU IPV4FRAG PAY3

171: IPV4 GTPU IPV4 UDP PAY4

172: IPV4 GTPU IPV4 TCP PAY4

173: IPV4 GTPU IPV4 SCTP PAY4

174: IPV4 GTPU IPV4 ICMP PAY4

175: IPV6 GTPU IPV4 PAY3

176: IPV6 GTPU IPV4FRAG PAY3

177: IPV6 GTPU IPV4 UDP PAY4

178: IPV6 GTPU IPV4 TCP PAY4

179: IPV6 GTPU IPV4 SCTP PAY4

180: IPV6 GTPU IPV4 ICMP PAY4

181: IPV4 GTPU PAY4

182: IPV6 GTPU PAY4

183: IPV4 GTPU IPV6FRAG PAY3

184: IPV4 GTPU IPV6 PAY3

185: IPV4 GTPU IPV6 UDP PAY4

186: IPV4 GTPU IPV6 TCP PAY4

187: IPV4 GTPU IPV6 SCTP PAY4

188: IPV4 GTPU IPV6 ICMPV6 PAY4

189: IPV6 GTPU IPV6 PAY3

190: IPV6 GTPU IPV6FRAG PAY3

191: IPV6 GTPU IPV6 UDP PAY4

113: IPV6 GTPU IPV6 TCP PAY4

120: IPV6 GTPU IPV6 SCTP PAY4

128: IPV6 GTPU IPV6 ICMPV6 PAY4

图8.获取DDP profile的相关信息。

'ddp get info gtp.pkgo'命令多次调用rte_pmd_i40e_get_ddp_info()，以获取与该profile相关的不同信息，并将其打印出来。

会有很多信息，但我们想要的是其中新数据包分类器类型：

List of defined packet classification types:

22: GTPU IPV4

23: GTPU IPV6

24: GTPU

25: GTPC

图9. GTPv1  profile 定义的新PCTYPE。

除了可用的所有默认PCTYPE之外，还创建了四种新PCTYPE（请查看最新手册中Table 7-5. Packet classifier types and its inputsets）。

为带有IPv4负载的GTPv1-U启用RSS，需要将PCTYPE 22映射到DPDK flow type。flow type在rte_eth_ctrl.h中定义; 前21个在DPDK 17.11中使用，因此可以映射到22及以上。映射到flow type上后，我们再重新启动端口并为flow type 22启用RSS：

testpmd> port config 0 pctype mapping update 22 22

testpmd> port start 0

testpmd> start

testpmd> port config all rss 22

图10.将新的PCTYPE映射到DPDK flow type上。

'port config 0 pctype mapping update 22 22'命令调用rte_pmd_i40e_flow_type_mapping_update()，将新的数据包分类器类型22映射到DPDK flow type22上，'port config all rss 22'命令因此可以为该flow type启用RSS。

如果我们再次发送GTP流量，我们可以看到数据包被识别为GTP并分配到多个队列中：

port 0/queue 1: received 1 packets

src=00:01:02:03:04:05 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0x342ff376 - RSS queue=0x1 - hw ptype: L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN packet: packet type =32912, Destination UDP port =2152, VNI = 3272871 - Receive queue=0x1

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

port 0/queue 2: received 1 packets

src=00:01:02:03:04:05 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0xe3402ba5 - RSS queue=0x2 - hw ptype: L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN packet: packet type =32912, Destination UDP port =2152, VNI = 9072104 - Receive queue=0x2

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

port 0/queue 0: received 1 packets

src=00:01:02:03:04:05 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0x6a97ed3 - RSS queue=0x0 - hw ptype: L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN packet: packet type =32912, Destination UDP port =2152, VNI = 5877304 - Receive queue=0x0

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

port 0/queue 3: received 1 packets

src=00:01:02:03:04:05 - dst=00:10:20:30:40:50 - type=0x0800 - length=178 - nb_segs=1 - RSS hash=0x7d729284 - RSS queue=0x3 - hw ptype: L3_IPV4_EXT_UNKNOWN TUNNEL_GTPU INNER_L3_IPV4_EXT_UNKNOWN INNER_L4_UDP  - sw ptype: L2_ETHER L3_IPV4 L4_UDP  - l2_len=14 - l3_len=20 - l4_len=8 - VXLAN packet: packet type =32912, Destination UDP port =2152, VNI = 1459946 - Receive queue=0x3

ol_flags: PKT_RX_RSS_HASH PKT_RX_L4_CKSUM_GOOD PKT_RX_IP_CKSUM_GOOD

图11. 设备应用GTPv1 profile后的GTP-U数据包分布。

目前，英特尔以太网700系列解析器已经会把具有UDP目的端口2152的数据包解析为GTP-U隧道，而且也会从GTP和内部IP报头中提取额外的字段。

如果不再需要该profile，可以将其从网络适配器中删除并恢复原始配置：

testpmd> port stop 0

testpmd> ddp del 0 /home/pkg/gtp.bak

testpmd> ddp get list 0

Profile number is: 0

testpmd>

图12. 移除设备上的GTPv1 profile

'ddp del 0 gtp.bak'命令首先将gtp.bak文件加载到内存缓冲区，作为rte_pmd_i40e_process_ddp_package()的参数，另一个参数是RTE_PMD_I40E_PKG_OP_WR_DEL，同时恢复原始配置。

总结

本新功能提供了在各种不同网络环境下的加速处理网络包的方法，通过应用DDP Profile来满足网络控制器的功能需求。在同样的基础设施上（配合安装的网络适配器）优化不同网络环境下的流量处理，而无需重置网络适配器或者重启服务器。