DPDK预分配了多少虚拟内存

Posted 2023-02-16

【中文标题】DPDK预分配了多少虚拟内存

【英文标题】：How much virtual memory is preallocated In DPDK

【发布时间】：2020-07-30 05:42:30

【问题描述】：

假设我正在运行具有以下配置的 DPDK 进程：

8 个 Numa 节点。每个 numa 节点有 4 个核心（即：32 个物理核心）

我只选择前 4 个 Numa 节点的核心，即前 32 个核心用于快速路径处理。

但我的 2 个网卡插入 Numa 节点 6

我有大小为 1G 的巨页，请求的巨页数量为 64G（64G/8 NUMA = 8G 每个 NUMA）并且总 RAM 约为 256G。

问题：

那么通过上面的配置并且在 DPDK 通用 _base 文件中将最大虚拟内存限制设置为 512G，DPDK 会出现吗？因为似乎每个 numa 节点需要分配 128 G 的虚拟内存，并且在达到第 5 个节点时，将达到 512 G 的虚拟内存限制。 即使所有运行内核都在前 4 个 Numa 节点中，但在最后一个 Numa 节点中的 NIC 会影响 DPDK？ 假设有 16 个 Numa 节点，那么我们是否也应该增加 common_base 中的虚拟内存限制？

【参考方案1】：

是的，对于每个 NUMA 节点，总虚拟内存设置为 128G。使用1G hugepage 大小，每个 NUMA 节点的内存段数将为 128，从而产生 128G 的最大应用程序数据内存。

但是，由于RTE_MAX_MEM_MB设置为512G，每个128G只有4个NUMA节点可以成功分配(4 x 128G == 512G)。因此，虚拟内存限制将导致应用程序失败。为了支持更多数量的 NUMA 节点，我们可以将总内存减少到 64G，除非应用程序不需要更高的内存要求。通过降低每个节点的内存，在连续 VA 内存的可用性方面可能会有优势。

其次，在启用 NUMA 的系统中，应从 NIC 接口与特定 NUMA 节点关联的同一内存域访问数据包缓冲区和描述符环，否则您将导致 QPI 带宽访问其他内存域并导致更高的延迟数据吞吐量低。

【讨论】：

但是由于所有 DPDK 快速路径核心都在前 4 个 Numa 节点上，为什么它需要为最后 4 个 Numa 节点预先分配虚拟才能运行？我同意 Numa 节点 6 中的 NIC 从 Numa 节点 1-4 访问内存时会出现性能问题，但操作应该没问题吧？

【参考方案2】：

将当前布局总结为

 - Assuming x86 for 32 physical cores
    No HT: 32 Threads
    with HT: 64 Threads
 - CPU cores from first 4 NUMA selected 
    No HT: 16 Threads 
    with HT: 32 Threads
 - NIC NUMA is 6
 - from total of 256GB, 1GB huge page selected as kernel CMD line for 64 pages results to
    numa 1: 8GB
    numa 2: 8GB 
    numa 3: 8GB
    numa 4: 8GB 
    numa 5: 8GB 
    numa 6: 8GB 
    numa 7: 8GB 
    numa 8: 8GB 

Q1. Max virtual memory limit set to 512G in DPDK common _base file, will DPDK come up? 
Answer> depending upon eal-args passed this can vary. Without passing any fields for `--socket-mem` or `--socket-limit` all 1GB  huge page are consumed. ie: 8GB per NUMA, which can lead to 64GB physical memory mapped to 64GB virtual address + extra space for Linux process

Q2. Because it seems 128 G of virtual memory needs to be allocated per numa node and by reaching 5th node 512 G of virtual memory limit would be hit. Even though all the operating cores are in first 4 Numa nodes , but NICs being in last Numa nodes affect the DPDK? 
Answer> creating the mempool/mbuf pool is specific to NUMA. You can do this by invoking `rte_eth_get_socketid (portNumber)` or simialr API to avoid wrong NUMA pitfall.

Q3. Say suppose there are 16 Numa nodes then should we also increase the virtual memory limit in common_base?
not clear> are you reffering 64bit virtual address space or hugepage per NUMA?

[更新]基于debug session，virtual-mem，mmu memory等信息。共享 mmap、legacy-mode、socket-mem、创建每个 NUMA 套接字的 API。

【讨论】：

我只是想知道每个节点分配了多少虚拟内存。假设我有 8 个 Numa 节点和 64G 物理大页面，那么每个 numa 节点可以获得 8G 物理大页面，对吗？预分配的虚拟内存呢？它是否为每个 numa 节点分配 128 GB，因此无法为最后 4 个节点分配虚拟内存，因为达到 common_base 文件中定义的 512G 虚拟内存限制？

您分享的问题并不反映相同。请使用评论中的相同问题更新问题。对于虚拟内存，它是映射大页面+进程映射区域的总和。例如64Gb mmap area + .so mapped + linux __start/stack/and others。尝试使用pmap 或/proc/pid/stats 收集真实信息。

默认情况下，DPDK 不会为每个节点分配 128G 虚拟巨页内存和 1G 巨页吗？由于 CONFIG_RTE_MAX_MEM_MB_PER_TYPE 为 131072 (128G) 。如果是，它不会无法将虚拟内存预分配给最后 4 个 numa 节点，因为在分配给前 4 个 NUMA 节点后，虚拟内存限制会达到由 CONFIG_RTE_MAX_MEM_MB 定义的限制。这与请求的物理大页面无关。如果所有执行快速路径的核心都在前 4 个 numa 节点中，但 NIC 在最后 4 个 Numa 节点中，dpdk 是否仍会尝试将虚拟内存预分配给最后 4 个 numa 节点？

根据您的要求，您已经声明您只有 64G 作为大页面，dpdk 18.11 或更高版本基于可用的总大页面创建 mmap，在此过程中映射到大页面。由于 64g mmap 适合 128G 以下，我猜它应该不会失败。我测试的节点最大只有 96GB。所以你能在你的节点上试一试并检查前面的评论吗

以上假设您已从CONFIG_RTE_MAX_MEM_MB_PER_LIST=32768 修改为CONFIG_RTE_MAX_MEM_MB_PER_LIST=65356 或CONFIG_RTE_MAX_MEM_MB_PER_LIST=262144