DPDK内存管理（1）

1 前言

 

DPDK将利用hugepage预留的物理内存统一的组织管理起来，然后以库的方式对外提供使用的接口。下图展示了DPDK中内存有关的模块的相互关系。

rte_eal            是统一的组织管理者（当然rte_eal不只是做内存的工作）

rte_malloc       对外提供分配释放内存的API，分配的内存都是rte_eal中管理的内存

rte_ring          提供无锁队列，他之间使用了rte_eal管理的内存

rte_mempool  利用rte_eal中的内存和rte_ring提供内存池的功能

ret_mbuf       

 

下面我们一个一个分析各个模块是怎样处理及使用内存的（重点诉说流程，不会详细的介绍代码），DPDK管理的内存有个很有用的特点--同一块物理内存在不同的进程地址空间中，虚拟地址是一样的。下面会详细的说明DPDK是怎样实现这个功能的。

首先hugepage这里就不描述了，要理解DPDK的内存管理必须知道hugepage，不了解的自行补齐吧，linux内核中有个文档介绍的很详细。可以点击这里查看。

2 rte_eal 对内存的组织与管理

这块是在rte_eal中实现的。有关的函数有：

rte_eal_init -> eal_hugepage_info_init

rte_eal_init -> rte_eal_memory_init

rte_eal_init -> rte_eal_memzone_init

rte_eal_init -> eal_check_mem_on_local_socket

 

2.1 eal_hugepage_info_init

首先DPDK管理的内存都是通过hugepage预留的，这个函数主要获取预留的内存的信息，获取方法是读取 /sys/kernel/mm/hugepages 下的文件，具体还是参考hugepage的文档吧，这里不详细描述。

预留的内存按页大小分类（ i386 architecture supports 4K and 4M (2M in PAE mode) page sizes, ia64 architecture supports multiple page sizes 4K, 8K, 64K, 256K, 1M, 4M, 16M, 256M and ppc64 supports 4K and 16M. ），可能会有多类，DPDK会把这些信息全部读取，使用struct hugepage_info进行保存，每一类对应一个struct hugepage_info类型的对象，所有的这些对象保存在struct internal_config的数组中。DPDK有个internal_config的全局变量，记录这些信息。

 

struct hugepage_info {
    size_t hugepage_sz;   /**< size of a huge page */
    const char *hugedir;    /**< dir where hugetlbfs is mounted */
    uint32_t num_pages[RTE_MAX_NUMA_NODES];
                /**< number of hugepages of that size on each socket */
    int lock_descriptor;    /**< file descriptor for hugepage dir */
};

 

struct internal_config {
　　 ...
    unsigned num_hugepage_sizes;      /**< how many sizes on this system */
    struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES];
};

 

 

struct internal_config internal_config;

 

总结 eal_hugepage_info_init，就是获取了系统中预留的内存信息，有几类（相同页大小的是一类），将每一类的信息（页大小、页数、挂载点）存储在internal_config.hugepage_info数组中。hugepage_info数组也进行了排序，大页的信息放前面，小页的信息放后面。

每一类所有内存页，也分处在哪个 socket上（不明白的查看NUMA相关知识补齐）的，hugepage_info中统计内存页数会按属于处在哪个socket上进行统计，但在这一步(eal_hugepage_info_init)中，还区分不了每个页处在哪个socket上，因此这里还没有按socket统计页数，将内存页数直接记录到num_pages[0]里面了。

 

2.2 rte_eal_memory_init

int
rte_eal_memory_init(void)
{
    RTE_LOG(INFO, EAL, "Setting up memory...\n");
    const int retval = rte_eal_process_type() == RTE_PROC_PRIMARY ?
            rte_eal_hugepage_init() :
            rte_eal_hugepage_attach();
    if (retval < 0)
        return -1;

    if (internal_config.no_shconf == 0 && rte_eal_memdevice_init() < 0)
        return -1;

    return 0;
}

 

DPDK多进程状态下，分为RTE_PROC_PRIMARY进程及RTE_PROC_SECONDARY进程，RTE_PROC_PRIMARY负责初始化内存，RTE_PROC_SECONDARY获取 RTE_PROC_PRIMARY 内存映射的信息，创建与RTE_PROC_PRIMARY一样的内存映射。这是DPDK多进程共享内存的方式。此处先不展开描述。随着流程的展开，自然会明白。

2.2.1 rte_eal_mem_init -> rte_eal_hugepage_init 

DPDK有个全局变量

static struct rte_config rte_config

该变量的成员 struct rte_mem_config *mem_config;  保存了DPDK管理的内存的所有信息。DPDK将内存统一的管理，就是将所有内存保存到mem_config:memseg[]中。

struct rte_mem_config {
    volatile uint32_t magic;   /**< Magic number - Sanity check. */

    /* memory topology */
    uint32_t nchannel;    /**< Number of channels (0 if unknown). */
    uint32_t nrank;       /**< Number of ranks (0 if unknown). */

    /**
     * current lock nest order
     *  - qlock->mlock (ring/hash/lpm)
     *  - mplock->qlock->mlock (mempool)
     * Notice:
     *  *ALWAYS* obtain qlock first if having to obtain both qlock and mlock
     */
    rte_rwlock_t mlock;   /**< only used by memzone LIB for thread-safe. */
    rte_rwlock_t qlock;   /**< used for tailq operation for thread safe. */
    rte_rwlock_t mplock;  /**< only used by mempool LIB for thread-safe. */

    uint32_t memzone_idx; /**< Index of memzone */

    /* memory segments and zones */
    struct rte_memseg memseg[RTE_MAX_MEMSEG];    /**< Physmem descriptors. */
    struct rte_memzone memzone[RTE_MAX_MEMZONE]; /**< Memzone descriptors. */

    /* Runtime Physmem descriptors. */
    struct rte_memseg free_memseg[RTE_MAX_MEMSEG];

    struct rte_tailq_head tailq_head[RTE_MAX_TAILQ]; /**< Tailqs for objects */

    /* Heaps of Malloc per socket */
    struct malloc_heap malloc_heaps[RTE_MAX_NUMA_NODES];
} __attribute__((__packed__));

详细流程：

函数先根据 struct hugepage_info hugepage_info[MAX_HUGEPAGE_SIZES]; （eal_hugepage_info_init中获取的信息）得到了内存页的总数。然后为struct hugepage_file *tmp_hp申请了内存，有多少个内存页，就分配了多少个hugepage_file。

 

struct hugepage_file {
    void *orig_va;      /**< virtual addr of first mmap() */
    void *final_va;     /**< virtual addr of 2nd mmap() */
    uint64_t physaddr;  /**< physical addr */
    size_t size;        /**< the page size */
    int socket_id;      /**< NUMA socket ID */
    int file_id;        /**< the '%d' in HUGEFILE_FMT */
    int memseg_id;      /**< the memory segment to which page belongs */
#ifdef RTE_EAL_SINGLE_FILE_SEGMENTS
    int repeated;        /**< number of times the page size is repeated */
#endif
    char filepath[MAX_HUGEPAGE_PATH]; /**< path to backing file on filesystem */
};

接着针对每一类内存（相同页大小的内存算一类）进行处理，

for(每一类） ｛

　　for（这一类的每一页） ｛         

　　　　每个页对应一个hugepage_file，file_id，size，filepath初始化。其中file_id是页的序号，这个序号是给filepath用的，是为了给每个页对应的文件起一个独立的文件名（与其他页不会重复）。

　　　　建立文件<filepath>，这个文件是因为使用hugepage的内存必须按这样的方式（先建立文件，再mmap，得到内存虚拟地址使用）使用。

　　　　执行mmap获得页的虚拟地址，赋给hugepage_file:orig_va。

　　｝ （map_all_hugepages()）

 

　　所有hugepage预留的物理内存都映射完成，可以根据hugepage_file:orig_va进行访问了。

　　for（这一类的每一页） ｛

　　　　获取物理地址，赋给hugepage_file:physaddr。

　　　　获取物理地址的方式，是linux内核提供的功能，不了解的可以点击这里补齐。

　　｝（find_physaddrs()）

　　

　　for（这一类的每一页） ｛

　　　　 获取每个页所在的socket，赋给hugepage_file:socket_id。　

　　　　 获取的方法也是linux内核提供的功能，具体不详述。

　　}（find_numasocket()）

 

　　对这一类的页的hugepage_file[]按页物理地址进行排序。

 

　　for（这一类的每一页） ｛

　　　　重新执行mmap，并将获取的虚拟地址赋给hugepage_file:final_va。　　　　

　　｝（map_all_hugepages()）

　　本次重新mmap，与第一次的不同是，会主动先申请一块足够映射本类所有内存页的虚拟地址空间，然后将本类的所有页连续的映射的该虚拟地址空间中。

　　如果找不到这么大的虚拟地址空间，还是会一页一页的映射，让内核去决定虚拟地址空间。

　　第二次映射用代码的注释解释 The second mapping tries to  map continguous physical blocks in contiguous virtual blocks.

 

　　将第一次的映射unmap掉

｝

 

继续

更新 internal_config.hugepage_info[].num_pages[]，我们知道bugepage_info在eal_hugepage_info_init中初始化时，不知道每个页是属于哪个socket的，因此直接使用num_pages[0]记录了所有的页数，但在上一步中，已经知道了每个页属于哪个socket，因此这里更新了num_pages，准确的记录了哪个socket上有多少个页。

 

这块我还没具体看 unmap pages that we won't need (looks at used_hp)，接下来再研究。

接下来，建立了共享内存，将hugepage_file拷贝到共享内存中，这样RTE_PROC_SECONDARY启动后可以在共享内存中读取这些信息，然后创建与RTE_PROC_PRIMARY一致的映射。

 

最后，使用mem_config->memseg[]将所有内存管理起来。

一个struct rte_memsg对象，保存一块相同socket的、相同页大小的、物理地址连续的、虚拟地址连续的内存。因此整个内存由多个memseg组成。

 

总结rte_eal_hugepage_init，它获取hugepge的方式预留的所有物理内存，统一的映射到虚拟地址空间中，保存到memseg中。至此，理论上可以通过memseg获取虚拟地址使用这些内存了。但DPDK提供了统一的方式来使用，不是谁用就可以来拿的。

 

 2.2.2 rte_eal_mem_init -> rte_eal_hugepage_attach

 /*
 * This creates the memory mappings in the secondary process to match that of
 * the server process. It goes through each memory segment in the DPDK runtime
 * configuration and finds the hugepages which form that segment, mapping them
 * in order to form a contiguous block in the virtual memory space
 */

 

3 rte_malloc

 

4 rte_ring

 

5 rte_mempool

 

原文链接 http://www.cnblogs.com/jintianfree/p/4018043.html