Блог

Я пытаюсь фрагментировать пакет 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 %dn",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 %dn",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 failedn");

rte_pktmbuf_free>(m);                       //free parent pkt
 

Теперь проблема здесь в том, что косвенный mempool исчерпывается. В результате после нескольких пакетов фрагментация завершается сбоем из-за-ENOMEM. Я совершенно не могу понять, почему PMD не освобождает и не возвращает объект mempool обратно в MEMPOOL1. Маловероятно, что это связано с тем, что порты NIC ограничены MEMPOOL0, а фрагменты pkt из MEMPOOL1 удаляются.

Пожалуйста, найдите в журнале ниже приведенный выше фрагмент, в котором печатаются доступные слоты в прямых (d) и косвенных (in) пулах памяти:

перед фраг mempool размер D 2060457 в 2095988
после фраг mempool размер D 2060344 в 2095952
до фраг mempool размер D 2060361 в 2095945
после фраг mempool размер D 2060215 в 2095913
.
.
.
перед фраг mempool размер D 2045013 в 0
после фраг mempool размер D 2045013 в 0
перед фраг mempool размер D 2045013 в 0
после фраг mempool размер D 2045013 в 0
перед фраг mempool размер D 2045013 в 0

Я вижу, как прямой mempool уменьшается и увеличивается по мере поступления и удаления/выхода пакетов, как и ожидалось. Я также могу подтвердить, что получил начальный пакет фрагментированных пакетов, равный размеру MEMPOOL1. Мы высоко ценим любой вклад в понимание причины проблемы.

P. S: У нас была та же проблема в dpdk17.11. Нам пришлось преломить rte_ipv4_fragment_packet (), чтобы не использовать косвенную цепочку фрагментов вместо того, чтобы просто генерировать их.

Изменить:
Версия DPDK — 20.11
Env — linux — centos 7
PMD — i40e — использование связи в режиме 4
Размер Пкт — 128
МТУ — 70

Пулы памяти создаются с помощью rte_pktmbuf_pool_create(), таким образом, без флага SC/SP (по умолчанию MC/MP). Также всегда n_frags

Спасибо и с уважением,
Вишал Мохан

DPDK API rte_ipv4_fragment_packet используется как testpmd в примере, так и в примере DPDK ip_fragementation . Они также включены в набор тестов DPDK, который также запускается для каждого выпуска.

На основе внутреннего тестирования и надлежащего использования API, например Ip_fragementation , проблема не может быть воспроизведена. Следовательно, утечка буферов пула памяти API весьма маловероятна, если не считать какого-то специального углового случая (который еще предстоит найти).

Основываясь на анализе фрагмента кода, причиной исчерпания mempool может быть следующее

1. не удается освободить прямой буфер после фрагментации
2. не удается освободить один или несколько фрагментов из косвенного буфера при сбое tx_burst.

[РЕДАКТИРОВАТЬ-1] основываясь на обновлении электронной почты и комментариях, действительно нет проблем с API DPDK rte_ipv4_fragment_packet. Проблема связана с логикой приложения, с новым поведением, как

1. DPDK СВЯЗЬ PMD приводит к исчерпанию mempool с текущим фрагментом кода
2. DPDK BOND PMD не имеет проблем с DPDK пример с rte_ipv4_fragment_packet
3. DPDK i40e PMD имеет проблему с текущим фрагментом кода
4. DPDK i40e PMD не имеет проблем с примером dpdk rte_ipv4_fragment_packet

Следовательно, проблема связана с примером фрагмента кода и его использованием, а не с API DPDK.