在 dpdk legacy memory 模型浅析 这篇文章中，我描述了 linux 平台 dpdk 早期版本的内存模型并分析了此模型下对 hugepage 的管理代码，在此模型中，dpdk primary 进程负责 layout hugepage 到 VA 中。为了支持多进程共享大页内存，dpdk primary 进程将大页内存初始化过程中得到的每个 memseg 与 hugepage file 信息通过 mmap 记录到特定文件中，secondary 进程通过 mmap 相同文件来访问这些信息并映射大页到相同的 VA 地址以共享 primary 进程映射的大页。

当 dpdk 进程完成了内存初始化后，在一个进程中使用 dpdk 内存分配接口分配的内存可以直接在其它 dpdk 进程中使用，可其它 dpdk 进程如何知道某个进程分配的某块区域的地址呢？显然需要引入新的描述信息来保存这一信息，且这些信息也需要在多进程之间共享。

dpdk 中抽象了 rte_config 结构来保存共享内存区域的描述信息。dpdk 多进程共享内存示意图如下： 中间的的区域为 dpdk 多进程需要共享的内容，大页内存共享 + 内存分配描述信息共享共同实现了 dpdk 多进程共享内存机制，在本文中，我将基于 dpdk-17.11 源码分析下 dpdk 中内存共享描述信息的原理。

rte_config 结构定义如下：

它可以划分为两部分：

共享内存描述数据为 rte_mem_config 结构，此结构定义如下：

核心字段为 memseg、memzone、tailq_head、malloc_heaps，这些字段保存了整个共享的描述信息，实际运行中 dpdk 多进程之间内存的分配、查找、释放就是通过控制这些结构实现的，下面分别对这些结构的功能进行描述。

此结构描述了单块物理内存连续区域的信息，其定义如下：

它由 primary 进程初始化，保存大页的映射信息。secondary 进程通过访问此结构得到大页内存的 layout 信息，然后按照此信息 mmap 大页到 primary 进程中相同的地址以实现整个大页内存区域的共享。

此结构描述一块在 memseg 上分配的带标识符的内存区域，标识符为字符串，其定义如下：

name 唯一区分每块内存区域，在其它进程中可以以字符串为参数遍历 rte_mem_config 结构的 memzone 数组，匹配每个 memzone 结构的 name 来获取到某块内存区域的 rte_memzone 结构进而得到内存其实地址实现共享，这就是 rte_memzone_lookup 的实现原理。

rte_tailq_head 是 dpdk 中双向链表的表头，dpdk 中为多个功能不同的内存结构注册不同的 tailq 链表用于多进程间共享。此结构定义如下：

rte_mem_config 中保存所有的 rte_tailq_head 信息，每一个 rte_tailq_head 的 name 唯一标识一个 tailq。 dpdk 通过共享 rte_tailq_head 头并在大页上分配 rte_tailq_head 链表中链入的每一个 rte_tailq_entry 来实现多进程间基于 tailq 获取共享内存信息功能。

此结构维护大页内存分配信息，每个 numa 节点上有一个独立的结构以支持在特定 numa 节点上分配内存。其定义如下：

核心数据为 free_head，free_head 按照不同的内存大小范围分为不同的 free_list，free_list 链表的成员单位为 malloc_elem。free_head 内容分配方式如下：

在内存释放时会根据大小放入对应的 free_head 中，在内存申请时也会根据大小计算需要查找的 free_head 来分配。malloc_elem 也在大页内存上分配，是 dpdk 内存分配的核心数据结构。

涉及共享数据一般都离不开锁的使用，rte_mem_config 中有如下读写锁定义：

malloc_heap 中有如下自旋锁定义：

这些锁用于多线程互斥保护，而它们又在多进程之间共享，也用于多进程之间的共享数据保护。dpdk memzone、tailq、mempool 一般用于分配固定格式的数据，一次分配、多次访问，符合读写锁的使用场景，而 malloc_heap 结构会频繁的分配、释放，故而使用自旋锁。

这些锁都基于 dpdk 原生实现，工作在用户态，有很好的性能，然而却不支持异常回收。在一个进程中使用没有问题，在多进程中使用时，如果某个进程在临界区内异常退出，就会产生死锁。在 程序启动顺序引发的血案之 dpdk 进程死锁 这篇文章中，我描述了这个问题，并提供了相应的解决方案。

dpdk 多进程模型以共享大页内存为基础，实际实现中仅仅共享大页内存还不够，还需要共享内存分配的一些描述文件，这就是 rte_config 等结构的由来。使用这些结构，dpdk 能够灵活的在某个进程中找到在另外一个进程中分配的内存来使用，表面看上去好像不符合每个进程虚拟地址独立的特点，其实不过是因为这些虚拟地址指向的物理地址完全一致而已。

在实际使用场景中，常常需要在多线程与多进程模型之间进行选择，使用多线程机制不用创建许多进程，然而一个线程异常很大概率会影响整个进程的执行，而采用多进程模型，某个进程异常，其它进程仍旧能够正常工作。

基于可靠性考虑多进程模型是更好的选择。 dpdk 内存架构原生支持多进程模型，支持一个 primary 进程与多个 secondary，甚至于可以使用 --file-prefix 来创建多个 primary 进程，在开发时不用做额外修改即可使用。