DPDK 20.11 - IPv4 碎片 - 间接池耗尽
DPDK 20.11 - IPv4 Fragmentation - indirect pool gets exhausted
我正在尝试使用以下逻辑对 IPv4 数据包进行分段:
~after pkts ingress~
struct rte_port_ring_writer *p = port_out->h_port;
pool_direct = rte_mempool_lookup("MEMPOOL0");
pool_indirect = rte_mempool_lookup("MEMPOOL1");
printf("before frag mempool size d %d in %d\n",rte_mempool_avail_count(pool_direct),rte_mempool_avail_count(pool_indirect));
struct rte_mbuf *frag_pkts[MAX_FRAG_SIZE];
int out_pkts = rte_ipv4_fragment_packet (m, frag_pkts, n_frags, ip_mtu,pool_direct, pool_indirect);
printf("after frag mempool size d %d in %d\n",rte_mempool_avail_count(pool_direct),rte_mempool_avail_count(pool_indirect));
if(out_pkts > 0)
port_out->ops.f_tx_bulk(port_out->h_port,frag_pkts,RTE_LEN2MASK(out_pkts, uint64_t));
else
printf("frag failed\n");
rte_pktmbuf_free>(m); //free parent pkt
现在的问题是间接内存池耗尽。结果,在几次突发数据包之后,由于 -ENOMEM,分段失败。我完全不明白为什么 PMD 不释放并将 mempool obj 放回 MEMPOOL1。这极不可能是因为 NIC 端口被绑定到 MEMPOOL0 并且来自 MEMPOOL1 的片段 pkts 被导出。
请在下面找到上述片段的日志,它打印了直接 (d) 和间接 (in) 内存池中的可用插槽:
在 2095988 中的碎片内存池大小 d 2060457 之前
在 2095952 中的碎片内存池大小 d 2060344 之后
在 2095945
中 frag 内存池大小 d 2060361 之前
在 2095913 中的碎片内存池大小 d 2060215 之后
.
.
.
在 0
中 frag 内存池大小 d 2045013 之前
在 0
中的碎片内存池大小 d 2045013 之后
在 0
中 frag 内存池大小 d 2045013 之前
在 0
中的碎片内存池大小 d 2045013 之后
在 0
中的碎片内存池大小 d 2045013 之前
我可以看到直接内存池随着数据包的进入而减少和增加,并且 drop/egress 符合预期。我还可以确认我收到了等于 MEMPOOL1 大小的分段数据包的初始突发。非常感谢任何有助于理解问题原因的意见。
P.S: 我们在dpdk17.11中遇到了同样的问题。我们不得不折射 rte_ipv4_fragment_packet() 以不使用碎片的间接链接,而只是生成它们。
编辑:
DPDK 版本 - 20.11
环境 - linux - centos 7
PMD - i40e - 在模式 4 中使用绑定
包装尺寸 - 128
MTU - 70
内存池是用 rte_pktmbuf_pool_create() 创建的,
因此没有 SC/SP 标志(默认为 MC/MP)。也总是 n_frags < MAX_FRAG_SIZE.
感谢和问候,
维沙尔·莫汉
DPDK API rte_ipv4_fragment_packet在testpmd
和DPDK示例下都使用ip_fragementation
。这些也包含在 DPDK 测试套件中,每个版本也是 运行。
基于内部测试和 API 的正确使用,例如 Ip_fragementation
该问题无法重现。因此,API 泄漏内存池缓冲区的可能性很小,除非是一些特殊的极端情况(尚未发现)。
根据以下代码片段分析可能是内存池耗尽的原因
- 分片后无法释放直接缓冲区
- 当 tx_burst 失败时,无法从间接缓冲区释放一个或多个片段。
[EDIT-1] 根据邮件更新和评论,DPDK确实没有问题API rte_ipv4_fragment_packet 。问题来自应用程序逻辑,新行为为
- DPDK BOND PMD 导致当前代码片段的内存池耗尽
- DPDK BOND PMD 与 rte_ipv4_fragment_packet
的 DPDK 示例没有问题
- DPDK i40e PMD 当前代码片段有问题
- DPDK i40e PMD 与 dpdk 示例没有问题 rte_ipv4_fragment_packet
因此问题出在示例代码片段和用法上,而不是 DPDK API。
我正在尝试使用以下逻辑对 IPv4 数据包进行分段:
~after pkts ingress~
struct rte_port_ring_writer *p = port_out->h_port;
pool_direct = rte_mempool_lookup("MEMPOOL0");
pool_indirect = rte_mempool_lookup("MEMPOOL1");
printf("before frag mempool size d %d in %d\n",rte_mempool_avail_count(pool_direct),rte_mempool_avail_count(pool_indirect));
struct rte_mbuf *frag_pkts[MAX_FRAG_SIZE];
int out_pkts = rte_ipv4_fragment_packet (m, frag_pkts, n_frags, ip_mtu,pool_direct, pool_indirect);
printf("after frag mempool size d %d in %d\n",rte_mempool_avail_count(pool_direct),rte_mempool_avail_count(pool_indirect));
if(out_pkts > 0)
port_out->ops.f_tx_bulk(port_out->h_port,frag_pkts,RTE_LEN2MASK(out_pkts, uint64_t));
else
printf("frag failed\n");
rte_pktmbuf_free>(m); //free parent pkt
现在的问题是间接内存池耗尽。结果,在几次突发数据包之后,由于 -ENOMEM,分段失败。我完全不明白为什么 PMD 不释放并将 mempool obj 放回 MEMPOOL1。这极不可能是因为 NIC 端口被绑定到 MEMPOOL0 并且来自 MEMPOOL1 的片段 pkts 被导出。
请在下面找到上述片段的日志,它打印了直接 (d) 和间接 (in) 内存池中的可用插槽:
在 2095988 中的碎片内存池大小 d 2060457 之前
在 2095952 中的碎片内存池大小 d 2060344 之后
在 2095945
中 frag 内存池大小 d 2060361 之前
在 2095913 中的碎片内存池大小 d 2060215 之后
.
.
.
在 0
中 frag 内存池大小 d 2045013 之前
在 0
中的碎片内存池大小 d 2045013 之后
在 0
中 frag 内存池大小 d 2045013 之前
在 0
中的碎片内存池大小 d 2045013 之后
在 0
我可以看到直接内存池随着数据包的进入而减少和增加,并且 drop/egress 符合预期。我还可以确认我收到了等于 MEMPOOL1 大小的分段数据包的初始突发。非常感谢任何有助于理解问题原因的意见。
P.S: 我们在dpdk17.11中遇到了同样的问题。我们不得不折射 rte_ipv4_fragment_packet() 以不使用碎片的间接链接,而只是生成它们。
编辑:
DPDK 版本 - 20.11
环境 - linux - centos 7
PMD - i40e - 在模式 4 中使用绑定
包装尺寸 - 128
MTU - 70
内存池是用 rte_pktmbuf_pool_create() 创建的,
因此没有 SC/SP 标志(默认为 MC/MP)。也总是 n_frags < MAX_FRAG_SIZE.
感谢和问候,
维沙尔·莫汉
DPDK API rte_ipv4_fragment_packet在testpmd
和DPDK示例下都使用ip_fragementation
。这些也包含在 DPDK 测试套件中,每个版本也是 运行。
基于内部测试和 API 的正确使用,例如 Ip_fragementation
该问题无法重现。因此,API 泄漏内存池缓冲区的可能性很小,除非是一些特殊的极端情况(尚未发现)。
根据以下代码片段分析可能是内存池耗尽的原因
- 分片后无法释放直接缓冲区
- 当 tx_burst 失败时,无法从间接缓冲区释放一个或多个片段。
[EDIT-1] 根据邮件更新和评论,DPDK确实没有问题API rte_ipv4_fragment_packet 。问题来自应用程序逻辑,新行为为
- DPDK BOND PMD 导致当前代码片段的内存池耗尽
- DPDK BOND PMD 与 rte_ipv4_fragment_packet 的 DPDK 示例没有问题
- DPDK i40e PMD 当前代码片段有问题
- DPDK i40e PMD 与 dpdk 示例没有问题 rte_ipv4_fragment_packet
因此问题出在示例代码片段和用法上,而不是 DPDK API。