DPDK源码分析之(1)libmbuf模块补充

Once_day2024-07-11 5:02

DPDK源码分析之(1)libmbuf模块补充

Author：OnceDay Date：2024年7月2日

漫漫长路，有人对你笑过嘛...

全系列文档可参考专栏：源码分析_Once-Day的博客-CSDN博客

参考文档：

文章目录

      • DPDK源码分析之(1)libmbuf模块补充
        • [3. offload信息](#3. offload信息)
          • [3.1 Rx卸载信息](#3.1 Rx卸载信息)
        • [4. 动态字段(dynamic fields)](#4. 动态字段(dynamic fields))
          • [4.1 数据结构定义](#4.1 数据结构定义)
          • [4.2 动态字段API操作](#4.2 动态字段API操作)
          • [4.3 动态字段处理](#4.3 动态字段处理)
        • [5. 自定义内存池操作](#5. 自定义内存池操作)
          • [5.1 API操作](#5.1 API操作)
        • [6. 报文类型](#6. 报文类型)
          • [6.1 类型值枚举](#6.1 类型值枚举)
3. offload信息
3.1 Rx卸载信息

这些标志位也携带了数据包类型信息，由于接收(RX)和发送(TX)共享这些标志位，对其修改需要谨慎，主要规则如下:

  • 接收(RX)标志位从第0位开始，新定义的标志位添加在之前标志位的左边。
  • 最高的3个比特位是为通用的mbuf(内存缓冲区)标志保留的。
  • 发送(TX)标志位从第60位(即63-3)开始，新定义的标志位添加在之前标志位的右边，即应该从高位往低位定义，而不是从低位往高位。
  • 保持这些标志位与 rte_get_rx_ol_flag_name() 和 rte_get_tx_ol_flag_name() 函数同步。
标识 值 描述
RTE_MBUF_F_RX_VLAN (1ULL << 0) 802.1q VLAN报文，TCI ID记录在mbuf->vlan_tci里面。 如果没有RTE_MBUF_F_RX_VLAN_STRIPPED标记，则VLAN数据未被剥离。
RTE_MBUF_F_RX_RSS_HASH (1ULL << 1) 表示数据包有RSS(Receive Side Scaling)哈希值。
RTE_MBUF_F_RX_FDIR (1ULL << 2) 表示数据包匹配了特定的流向。
RTE_MBUF_F_RX_OUTER_IP_CKSUM_BAD (1ULL << 5) 表示数据包最外层的IP校验和已被硬件检查并且是错误的。
RTE_MBUF_F_RX_VLAN_STRIPPED (1ULL << 6) 表示数据包的VLAN标签以及被剥离保存在mbuf->vlan_tci里。
RTE_MBUF_F_RX_IP_CKSUM_MASK ((1ULL << 4)|(1ULL << 7))
RTE_MBUF_F_RX_IP_CKSUM_UNKNOWN 0 未知的IP检验和检查结果
RTE_MBUF_F_RX_IP_CKSUM_BAD (1ULL << 4) the IP checksum in the packet is wrong
RTE_MBUF_F_RX_IP_CKSUM_GOOD (1ULL << 7) the IP checksum in the packet is valid
RTE_MBUF_F_RX_IP_CKSUM_NONE ((1ULL << 4)|(1ULL << 7)) 表示数据包的IP校验和在数据包中不正确， 但IP数据的完整性已经通过其他方式验证。
RTE_MBUF_F_RX_L4_CKSUM_MASK ((1ULL << 3)|(1ULL << 8))
RTE_MBUF_F_RX_L4_CKSUM_UNKNOWN 0 no information about the RX L4 checksum
RTE_MBUF_F_RX_L4_CKSUM_BAD (1ULL << 3) the L4 checksum in the packet is wrong
RTE_MBUF_F_RX_L4_CKSUM_GOOD (1ULL << 8) the L4 checksum in the packet is valid
RTE_MBUF_F_RX_L4_CKSUM_NONE ((1ULL << 3)|(1ULL << 8)) 表示数据包的L4校验和在数据包中不正确， 但L4数据的完整性已经通过其他方式验证。
RTE_MBUF_F_RX_IEEE1588_PTP (1ULL << 9) 符合IEEE 1588精确时间协议(Precision Time Protocol, PTP)标准 的二层以太网精确时间报文。
RTE_MBUF_F_RX_IEEE1588_TMST (1ULL << 10) 包含IEEE 1588精确时间协议(Precision Time Protocol, PTP)时间戳 的二层(L2)或四层(L4)网络数据包。
RTE_MBUF_F_RX_FDIR_ID (1ULL << 13) 当数据包匹配流向识别(Flow Director, FDIR)规则时， 报告相应的流向ID(Flow Director ID, FD ID)。
RTE_MBUF_F_RX_FDIR_FLX (1ULL << 14) 当数据包匹配流向识别(Flow Director, FDIR)规则时， 报告规则中配置的灵活字节(flexible bytes)。
RTE_MBUF_F_RX_QINQ_STRIPPED (1ULL << 15) 表示数据包的QINQ标签以及被剥离保存在mbuf->vlan_tci_outer里。 RTE_MBUF_F_RX_VLAN和RTE_MBUF_F_RX_QINQ需要被设置。
RTE_MBUF_F_RX_LRO (1ULL << 16) 数据包被硬件或虚拟驱动程序合并时，驱动程序会设置该标识。 这个标志表示mbuf中的m->tso_segsz字段是有效的， 并且其值被设置为原始数据包的段大小(segment size)。
RTE_MBUF_F_RX_SEC_OFFLOAD (1ULL << 18) 表示数据包经过了安全卸载处理，即某些安全操作已经由硬件完成。
RTE_MBUF_F_RX_SEC_OFFLOAD_FAILED (1ULL << 19) 表示数据包的安全卸载处理失败。 这可能是由于硬件错误、配置问题、不支持的算法等。
RTE_MBUF_F_RX_QINQ (1ULL << 20) 表示数据包是一个双VLAN(QinQ)数据包,即包含两层VLAN标签。
RTE_MBUF_F_RX_OUTER_L4_CKSUM_MASK ((1ULL << 21)|(1ULL << 22)) 表示外层(outer)四层(L4)校验和状态的标志掩码
RTE_MBUF_F_RX_OUTER_L4_CKSUM_UNKNOWN 0 表示没有关于外层四层校验和的信息。
RTE_MBUF_F_RX_OUTER_L4_CKSUM_BAD (1ULL << 21) 表示数据包中的外层四层校验和是错误的。
RTE_MBUF_F_RX_OUTER_L4_CKSUM_GOOD (1ULL << 22) 表示数据包中的外层四层校验和是正确的。
RTE_MBUF_F_RX_OUTER_L4_CKSUM_INVALID ((1ULL << 21)|(1ULL << 22)) 表示外层四层校验和状态无效。
RTE_MBUF_F_FIRST_FREE (1ULL << 23) 需要一开始就重置的最大标识位(Rx从0位往上)
RTE_MBUF_F_LAST_FREE (1ULL << 40) 需要最后重置的最小标识位(TX从60位往下)
RTE_MBUF_F_TX_OUTER_UDP_CKSUM (1ULL << 41) 使能外部UDP校验和卸载功能。
RTE_MBUF_F_TX_UDP_SEG (1ULL << 42) UDP分段卸载功能，需要将MSS存放于mbuf->tso_segsz
RTE_MBUF_F_TX_SEC_OFFLOAD (1ULL << 43) 安全处理卸载。
RTE_MBUF_F_TX_MACSEC (1ULL << 44) MACsec卸载功能，对数据包进行加密、完整性保护和重放保护。
RTE_MBUF_F_TX_TUNNEL_VXLAN (0x1ULL << 45) Bits 45:48 used for the tunnel type.
RTE_MBUF_F_TX_TUNNEL_GRE (0x2ULL << 45)
RTE_MBUF_F_TX_TUNNEL_IPIP (0x3ULL << 45)
RTE_MBUF_F_TX_TUNNEL_GENEVE (0x4ULL << 45)
RTE_MBUF_F_TX_TUNNEL_MPLSINUDP (0x5ULL << 45)
RTE_MBUF_F_TX_TUNNEL_VXLAN_GPE (0x6ULL << 45)
RTE_MBUF_F_TX_TUNNEL_GTP (0x7ULL << 45)
RTE_MBUF_F_TX_TUNNEL_ESP (0x8ULL << 45)
RTE_MBUF_F_TX_TUNNEL_IP (0xDULL << 45) Generic IP encapsulated tunnel type used for TSO and checksum offload.
RTE_MBUF_F_TX_TUNNEL_UDP (0xEULL << 45) Generic UDP encapsulated tunnel type used for TSO and checksum offload.
RTE_MBUF_F_TX_QINQ (1ULL << 49) Double VLAN insertion (QinQ) request to driver
RTE_MBUF_F_TX_TCP_SEG (1ULL << 50) TCP segmentation offload
RTE_MBUF_F_TX_IEEE1588_TMST (1ULL << 51) TX IEEE1588 packet to timestamp
RTE_MBUF_F_TX_L4_NO_CKSUM (0ULL << 52) Disable L4 cksum of TX pkt
RTE_MBUF_F_TX_TCP_CKSUM (1ULL << 52) TCP cksum of TX pkt
RTE_MBUF_F_TX_SCTP_CKSUM (2ULL << 52) SCTP cksum of TX pkt
RTE_MBUF_F_TX_UDP_CKSUM (3ULL << 52) UDP cksum of TX pkt
RTE_MBUF_F_TX_L4_MASK (3ULL << 52) Mask for L4 cksum offload request
RTE_MBUF_F_TX_IP_CKSUM (1ULL << 54) Offload the IP checksum in the hardware.
RTE_MBUF_F_TX_IPV4 (1ULL << 55) Packet is IPv4.
RTE_MBUF_F_TX_IPV6 (1ULL << 56) Packet is IPv6
RTE_MBUF_F_TX_VLAN (1ULL << 57) VLAN tag insertion request to driver
RTE_MBUF_F_TX_OUTER_IP_CKSUM (1ULL << 58) Offload the IP checksum of an external header in the hardware
RTE_MBUF_F_TX_OUTER_IPV4 (1ULL << 59) Packet outer header is IPv4
RTE_MBUF_F_TX_OUTER_IPV6 (1ULL << 60) Packet outer header is IPv6
RTE_MBUF_F_TX_OFFLOAD_MASK 所有Tx offload的集合
RTE_MBUF_F_EXTERNAL (1ULL << 61) Mbuf having an external buffer attached. shinfo in mbuf must be filled.
RTE_MBUF_F_INDIRECT (1ULL << 62) Indirect attached mbuf
4. 动态字段(dynamic fields)

DPDK中的rte_mbuf是一种用于存储网络数据包的内存结构。为了支持各种不同的功能，我们常常需要在mbuf中存储一些额外的信息。然而，mbuf结构体本身的空间是有限的，不可能为每个功能都预留一个固定的字段，否则可能会导致兼容性问题。

为了解决这个问题，DPDK引入了mbuf动态字段和标志的机制。通过这个机制，我们可以在运行时按需在mbuf中注册一些自定义的字段或标志位:

动态字段是mbuf中一段连续的内存区域，有特定的大小和对齐要求，可以用来存储一些与报文相关的元数据。

动态标志位是mbuf->ol_flags中的一个位，用来标记某种特性是否启用。

动态字段和标志位的分配可以是自动的，由DPDK的内存管理模块选择合适的位置，也可以由应用程序和驱动显式指定偏移量。

使用动态字段和标志位时，应用程序和驱动需要协同工作:

  • 首先定义动态字段的参数，如名称、大小、对齐要求等，并用API函数注册。

  • 驱动程序在适当的时候(如网卡初始化时)注册它需要使用的动态字段，并记录下分配的偏移量，供后续读写操作使用。

  • 应用程序如果需要读写某个动态字段，也同样需要先注册，获得相同的偏移量，然后才能通过特定的宏来访问字段。

为了避免命名冲突，注册动态字段时应当遵循一定的命名规范，比如以"rte_"为前缀等。

总之，rte_mbuf动态字段和标志为我们提供了一种灵活的机制，可以在运行时按需添加自定义字段，且不影响原有mbuf结构的兼容性。

4.1 数据结构定义

相关的数据结构和宏定义如下：

yacas 复制代码 
/**
 * Maximum length of the dynamic field or flag string.
 */
#define RTE_MBUF_DYN_NAMESIZE 64

/**
 * Structure describing the parameters of a mbuf dynamic field.
 */
struct rte_mbuf_dynfield {
	char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the field. */
	size_t size;        /**< The number of bytes to reserve. */
	size_t align;       /**< The alignment constraint (power of 2). */
	unsigned int flags; /**< Reserved for future use, must be 0. */
};

/**
 * Structure describing the parameters of a mbuf dynamic flag.
 */
struct rte_mbuf_dynflag {
	char name[RTE_MBUF_DYN_NAMESIZE]; /**< Name of the dynamic flag. */
	unsigned int flags; /**< Reserved for future use, must be 0. */
};
4.2 动态字段API操作
API名字 描述
rte_mbuf_dynfield_register 注册一个动态字段，或者返回已存在动态字段的偏移量
rte_mbuf_dynfield_register_offset 在指定偏移处注册一个动态字段，或者返回已存在动态字段的偏移量
rte_mbuf_dynfield_lookup 寻址一个已经注册的动态mbuf字段
rte_mbuf_dynflag_register 注册一个动态标志，或者返回已存在动态标志的偏移值
rte_mbuf_dynflag_register_bitnum 在指定偏移处注册一个动态标志，或者返回已存在动态标志的偏移值
rte_mbuf_dynflag_lookup 寻址一个已经注册的动态mbuf标志
RTE_MBUF_DYNFIELD 返回对应偏移位置的动态字段
rte_mbuf_dyn_dump dump动态字段的名字和标识
RTE_MBUF_DYNFIELD_METADATA_NAME rte_flow_dynfield_metadata
RTE_MBUF_DYNFLAG_METADATA_NAME rte_flow_dynflag_metadata
RTE_MBUF_DYNFIELD_TIMESTAMP_NAME rte_dynfield_timestamp
RTE_MBUF_DYNFLAG_RX_TIMESTAMP_NAME rte_dynflag_rx_timestamp，驱动填充timestamp
rte_mbuf_dyn_rx_timestamp_register 注册rx timestamp字段
RTE_MBUF_DYNFLAG_TX_TIMESTAMP_NAME rte_dynflag_tx_timestamp
rte_mbuf_dyn_tx_timestamp_register 注册tx timestamp字段
RTE_MBUF_DYNFIELD_IP_REASSEMBLY_NAME 卸载IP重组到驱动上。
RTE_MBUF_DYNFLAG_IP_REASSEMBLY_INCOMPLETE_NAME IP重组未完成的信息。

当PMD(Poll Mode Driver，轮询模式驱动)在发送数据包时看到数据包上设置了RTE_MBUF_DYNFLAG_TX_TIMESTAMP_NAME标志，它会尝试将数据包出现在网络上的时间与指定的数据包时间戳同步。如果指定的时间戳是在过去，那么它应该被忽略；如果是在遥远的未来，那么它应该被限制在某个合理的值内(在秒的范围内)。

这里没有根据时间戳对数据包进行任何重新排序，无论是对于突发中的数据包，还是对于整个突发，这完全是应用程序的责任，以所需的顺序生成数据包及其时间戳。时间戳可能只放在突发中的第一个数据包中，提供整个突发的调度。

这个功能的主要作用是:

  • 允许应用程序控制数据包的发送时间，实现更精确的发送调度。

  • PMD驱动会尝试将数据包实际发送的时间与应用程序指定的时间戳对齐，提高发送时间的精确性。

  • 如果应用程序指定的时间戳不合理(过去或太远的未来)，PMD会进行适当的处理，如忽略或限制在合理范围内。

  • 应用程序需要自行维护发送数据包的顺序和时间戳，DPDK不会对此进行额外的处理。

  • 对于批量发送的数据包(burst)，可以只在第一个包上设置时间戳，用于控制整个burst的发送时间。

4.3 动态字段处理

(1) init_shared_mem(void)函数用于初始化mbuf动态字段的信息，首先会初始化一个和mbuf一样大小的结构体内存mbuf_shm，里面用于模拟mbuf的动态字段排布情况。

(2) mbuf_shm里面固定字段初始化为0值，动态字段初始化为1值，调用process_score()函数，对动态字段按照对齐属性划分，比如对齐到8字节的空间每个字节都填充为8 。

(3) rte_mbuf_set_platform_mempool_ops，

5. 自定义内存池操作

DPDK (Data Plane Development Kit) 是一个用于快速数据包处理的开源库和框架。DPDK提供了许多功能和API，用于优化和加速网络数据平面的处理。其中一个功能是RTE Mbuf Pool Ops，它与内存池(mempool)的操作有关。

在DPDK中，mbuf(memory buffer)是一种用于存储网络数据包的内存结构。为了高效地管理和分配mbuf，DPDK使用了内存池的概念。内存池是一组预先分配的固定大小的内存块，可以快速地从池中分配和释放mbuf。

RTE Mbuf Pool Ops提供了一组API，用于配置mbuf池的操作(ops)名称，这些操作主要由rte_pktmbuf_pool_create()函数使用。通过设置合适的mbuf池操作，可以优化内存池的性能和效率。

RTE Mbuf Pool Ops的主要作用包括：

  • 设置mbuf池的操作名称 ：可以使用相关的API函数，如rte_mbuf_best_mempool_ops()，来设置当前可用的最佳内存池操作名称。这样，在创建mbuf池时，就可以使用优化后的操作函数。

  • 查询可用的mbuf池操作 ：通过调用rte_mbuf_pool_ops_get()函数，可以获取当前可用的mbuf池操作名称。这对于了解系统支持的内存池操作以及选择合适的操作非常有帮助。

  • 自定义mbuf池操作：DPDK允许用户根据特定需求自定义mbuf池的操作函数。通过实现自定义的alloc、free、enqueue、dequeue等函数，并将其注册到DPDK中，可以对内存池的行为进行定制化控制。

通过使用RTE Mbuf Pool Ops，可以灵活地配置和优化mbuf池的操作，从而提高数据包处理的性能。这对于高性能网络应用程序的开发非常重要，因为高效的内存管理和数据包处理可以显著提升系统的吞吐量和响应时间。

5.1 API操作
API名字 描述
rte_mbuf_set_platform_mempool_ops 注册平台硬件mempool内存池操作API，任意时刻都只能注册一个值。
rte_mbuf_platform_mempool_ops 获取平台硬件mempool内存池操作API。
rte_mbuf_set_user_mempool_ops 设置用户偏好的内存池操作API集合。
rte_mbuf_user_mempool_ops 获取用户偏好的内存池操作API集合。
rte_mbuf_best_mempool_ops 获取最佳的内存池操作集合：用户定义，平台硬件支持，编译时指定。
6. 报文类型

用32位字段的结构来表示数据包类型，被分成了几个子字段，每个子字段表示了数据包在对应协议层的类型信息，字段的划分如下:

  • 0-3 位表示二层(L2)类型。
  • 4-7 位表示三层(L3)或者外层三层(用于隧道封装)类型 。
  • 8-11 位表示四层(L4)或者外层四层(用于隧道封装)类型。
  • 12-15 位表示隧道类型。
  • 16-19 位表示内层二层类型。
  • 20-23 位表示内层三层类型。
  • 24-27 位表示内层四层类型。
  • 28-31 位是保留位。

每个字段的值都是索引式的，即从一个预定义的类型值集合中取出。为了兼容 Vector PMD，一些特定的三层和四层类型值要按照特定的方式编排在连续的7个比特位中。

同时，不同的硬件可能对同一个数据包识别出不同的数据包类型组合，因为不同硬件的报文识别能力可能不同。

yacas 复制代码 
<'ether type'=0x0800
   | 'version'=4, 'protocol'=0x29
   | 'version'=6, 'next header'=0x3A
   | 'ICMPv6 header'>
will be recognized on i40e hardware as packet type combination of,
RTE_PTYPE_L2_ETHER |
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN |
RTE_PTYPE_TUNNEL_IP |
RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
RTE_PTYPE_INNER_L4_ICMP.
yacas 复制代码 
<'ether type'=0x86DD
   | 'version'=6, 'next header'=0x2F
   | 'GRE header'
   | 'version'=6, 'next header'=0x11
   | 'UDP header'>
will be recognized on i40e hardware as packet type combination of,
    RTE_PTYPE_L2_ETHER |
    RTE_PTYPE_L3_IPV6_EXT_UNKNOWN |
    RTE_PTYPE_TUNNEL_GRENAT |
    RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN |
    RTE_PTYPE_INNER_L4_UDP.
6.1 类型值枚举
类型名 值 描述
RTE_PTYPE_UNKNOWN 0x00000000 无任何报文类型信息
RTE_PTYPE_L2_ETHER 0x00000001 常见的外层以太报文(`[0x0800
RTE_PTYPE_L2_ETHER_TIMESYNC 0x00000002 二层时间同步报文(0x88F7)
RTE_PTYPE_L2_ETHER_ARP 0x00000003 二层ARP报文(0x0806)
RTE_PTYPE_L2_ETHER_LLDP 0x00000004 LLDP (Link Layer Discovery Protocol)(0x88CC)
RTE_PTYPE_L2_ETHER_NSH 0x00000005 NSH (Network Service Header)(0x894F)
RTE_PTYPE_L2_ETHER_VLAN 0x00000006 VLAN packet type(0x8100)
RTE_PTYPE_L2_ETHER_QINQ 0x00000007 QinQ packet type(0x88a8)
RTE_PTYPE_L2_ETHER_PPPOE 0x00000008 PPPOE packet type(`[0x8863
RTE_PTYPE_L2_ETHER_FCOE 0x00000009 FCoE packet type(0x8906)
RTE_PTYPE_L2_ETHER_MPLS 0x0000000a MPLS packet type(`[0x8847
RTE_PTYPE_L2_MASK 0x0000000f Mask of layer 2 packet types.
下面标识用于tunnel报文L3外层
RTE_PTYPE_L3_IPV4 0x00000010 IPv4(`0x0800
RTE_PTYPE_L3_IPV4_EXT 0x00000030 IPv4 With Options(`0x0800
RTE_PTYPE_L3_IPV6 0x00000040 IPv6(`0x86dd
RTE_PTYPE_L3_IPV4_EXT_UNKNOWN 0x00000090 IPv4，可能携带Options，也可能不携带Options
RTE_PTYPE_L3_IPV6_EXT 0x000000c0 IPv6(`0x86dd
RTE_PTYPE_L3_IPV6_EXT_UNKNOWN 0x000000e0 IPv6(`0x86dd
RTE_PTYPE_L3_MASK 0x000000f0 Mask of layer 3 packet types.
下面标识用于tunnel报文L4外层
RTE_PTYPE_L4_TCP 0x00000100 TCP，协议6，无分帧。
RTE_PTYPE_L4_UDP 0x00000200 UDP，协议17，无分帧。
RTE_PTYPE_L4_FRAG 0x00000300 IPv4分帧报文，只能被识别为三层报文，因为四层的信息可能不完整。
RTE_PTYPE_L4_SCTP 0x00000400 SCTP (Stream Control Transmission Protocol) 协议132。
RTE_PTYPE_L4_ICMP 0x00000500 ICMP，IPv4协议为1，IPv6协议为0x3a。
RTE_PTYPE_L4_NONFRAG 0x00000600 非上述识别出来的其他L40协议报文(非TCP/UDP/FRAG/SCTP/ICMP)。
RTE_PTYPE_L4_IGMP 0x00000700 IPv4 IGMP报文，协议2
RTE_PTYPE_L4_MASK 0x00000f00 Mask of layer 4 packet types.
下面标识用于隧道协议
RTE_PTYPE_TUNNEL_IP 0x00001000 IPIP协议，协议4/41
RTE_PTYPE_TUNNEL_GRE 0x00002000 GRE协议，协议47
RTE_PTYPE_TUNNEL_VXLAN 0x00003000 VXLAN协议，协议17+目的端口4789
RTE_PTYPE_TUNNEL_NVGRE 0x00004000 NVGRE协议，协议47+协议类型0x6558
RTE_PTYPE_TUNNEL_GENEVE 0x00005000 GENEVE协议，协议17+目的端口6081
RTE_PTYPE_TUNNEL_GRENAT 0x00006000 Teredo, VXLAN, GRE混合，
RTE_PTYPE_TUNNEL_GTPC 0x00007000 GTP-C控制报文，协议号17，端口2123
RTE_PTYPE_TUNNEL_GTPU 0x00008000 GTP-U用户数据报文，协议号17，端口2152
RTE_PTYPE_TUNNEL_ESP 0x00009000 ESP(IP层安全封装负载)，协议50
RTE_PTYPE_TUNNEL_L2TP 0x0000a000 L2TP报文，V2(UDP+目的端口1701)，V3(IP协议115)
RTE_PTYPE_TUNNEL_VXLAN_GPE 0x0000b000 VXLAN-GPE，UDP协议+目的端口4790
RTE_PTYPE_TUNNEL_MPLS_IN_GRE 0x0000c000 MPLS-in-GRE，GRE+0x8848协议
RTE_PTYPE_TUNNEL_MPLS_IN_UDP 0x0000d000 MPLS-in-UDP，UDP+目的端口6635
RTE_PTYPE_TUNNEL_MASK 0x0000f000 Mask of tunneling packet types.
下面标识用于隧道内层L2报文
RTE_PTYPE_INNER_L2_ETHER 0x00010000 IPv4或者IPv6
RTE_PTYPE_INNER_L2_ETHER_VLAN 0x00020000 VLAN报文，ID范围1-4095
RTE_PTYPE_INNER_L2_ETHER_QINQ 0x00030000 QINQ报文
RTE_PTYPE_INNER_L2_MASK 0x000f0000 Mask of inner layer 2 packet types.
下面标识用于隧道内层L3报文
RTE_PTYPE_INNER_L3_IPV4 0x00100000 IPv4协议，不携带Options。
RTE_PTYPE_INNER_L3_IPV4_EXT 0x00200000 IPv4协议，携带Options。
RTE_PTYPE_INNER_L3_IPV6 0x00300000 IPv6协议，不包括选项扩展头部。
RTE_PTYPE_INNER_L3_IPV4_EXT_UNKNOWN 0x00400000 IPv4协议，不区分是否携带Options。
RTE_PTYPE_INNER_L3_IPV6_EXT 0x00500000 IPv6协议，携带选项扩展头部。
RTE_PTYPE_INNER_L3_IPV6_EXT_UNKNOWN 0x00600000 IPv6协议，不区分是否携带选项扩展头部。
RTE_PTYPE_INNER_L3_MASK 0x00f00000 Mask of inner layer 3 packet types.
下面标识用于隧道内层L4报文
RTE_PTYPE_INNER_L4_TCP 0x01000000 TCP且IP不分片报文
RTE_PTYPE_INNER_L4_UDP 0x02000000 UDP且IP不分片报文
RTE_PTYPE_INNER_L4_FRAG 0x03000000 L4且IP分片报文
RTE_PTYPE_INNER_L4_SCTP 0x04000000 SCTP且IP不分片报文
RTE_PTYPE_INNER_L4_ICMP 0x05000000 ICMP且IP不分片报文
RTE_PTYPE_INNER_L4_NONFRAG 0x06000000 L4报文且IP不分片，但不属于以上类型
RTE_PTYPE_INNER_L4_MASK 0x0f000000 Mask of inner layer 4 packet types.
RTE_PTYPE_ALL_MASK 0x0fffffff All valid layer masks.

以及几个API函数: rte_get_ptype_l2_name，rte_get_ptype_l3_name，rte_get_ptype_l4_name，rte_get_ptype_tunnel_name，rte_get_ptype_inner_l2_name，rte_get_ptype_inner_l3_name，rte_get_ptype_inner_l4_name，rte_get_ptype_name。

相关推荐
flysnow01011 天前
WSL(Ubuntu20.04)编译和安装DPDK
dpdk·1024程序员节
彭泽布衣1 个月前
解读: 火山引擎自研vSwitch技术
dpdk·火山引擎·ovs·云网络·vswitch
别NULL2 个月前
DPDK 简易应用开发之路 2：UDP数据包发送及实现
linux·网络·网络协议·udp·dpdk
别NULL2 个月前
DPDK基础入门（十）：虚拟化
linux·网络·tcp/ip·dpdk
墨染 锦年4 个月前
DPDK概述
笔记·学习·dpdk·uio·igb-uio
小勇者5 个月前
【DPDK学习路径】八、轮询
dpdk
大1234草5 个月前
dpdk flow 的简单使用
dpdk
写一封情书5 个月前
tldk之tle简单记录
dpdk·tldk·tle
范桂飓5 个月前
Intel HDSLB 高性能四层负载均衡器 — 基本原理和部署配置
运维·负载均衡·dpdk
热门推荐
01【HarmonyOS】HUAWEI DevEco Studio 下载地址汇总02(欧拉)openEuler系统添加网卡文件配置流程、(欧拉)openEuler系统手动配置ipv6地址流程、(欧拉)openEuler系统网络管理说明03组基轨迹建模 GBTM的介绍与实现（Stata 或 R）04【AIGC】重塑未来的科技巨轮05全面解析：构建基于深度学习的安全帽检测系统（UI界面+YOLO代码+数据集）06【经验分享】Ubuntu22.04安装微信(linux官方版)07基于YOLOv10深度学习的CT扫描图像肾结石智能检测系统【python源码+Pyqt5界面+数据集+训练代码】深度学习实战、目标检测08Ubuntu 20.04使用Livox mid 360 测试 FAST_LIO09RAG 实践- Ollama+RagFlow 部署本地知识库10【TC3xx芯片】TC3xx芯片电源管理系统PMS详解