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

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

Author：OnceDay Date：2024年7月2日

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

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

参考文档：

• DPDK download
• Getting Started Guide for Linux — documentation (dpdk.org)
• Sample Applications User Guides — documentation (dpdk.org)
• 14. Mbuf Library — Data Plane Development Kit 24.07.0-rc1 documentation (dpdk.org)
• dpdk/lib/mbuf at main · DPDK/dpdk · GitHub
• TCP/IP Illustrated, Volume 2: The Implementation (kohala.com)
• DPDK源码分析之(1)libmbuf模块-CSDN博客

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() 函数同步。

4. 动态字段(dynamic fields)

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

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

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

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

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

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

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

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

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

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

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

4.1 数据结构定义

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

/**
 * 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操作

当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操作

6. 报文类型

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

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

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

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

<'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.

<'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 类型值枚举

以及几个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。