<html xmlns:v="urn:schemas-microsoft-com:vml" xmlns:o="urn:schemas-microsoft-com:office:office" xmlns:w="urn:schemas-microsoft-com:office:word" xmlns:m="http://schemas.microsoft.com/office/2004/12/omml" xmlns="http://www.w3.org/TR/REC-html40"> <head> <meta http-equiv="Content-Type" content="text/html; charset=iso-8859-9"> <meta name="Generator" content="Microsoft Word 15 (filtered medium)"> <style></style> </head> <body lang="TR" link="#0563C1" vlink="#954F72" style="word-wrap:break-word"> <div class="WordSection1"> Hello all,<o:p></o:p> <o:p> </o:p> I got issue, may be there is a missing solution in rte_kni.c or other parts.<o:p></o:p> <o:p> </o:p> There is not any function to free kni allocated bufs and rte_pktmbuf_free is not enough to handle it. (kni_free_mbufs is not reachable.)<o:p></o:p> <o:p> </o:p> In default-testing kni application works as below<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo4">Call rte_kni_rx_burst function to get messages<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:0cm;mso-list:l1 level1 lfo4">Then push to other KNI interface via rte_kni_tx_burst. There is no memory-leak because kni_free_mbufs is called and freed unused allocations.<o:p></o:p></li></ol> <o:p> </o:p> On the other hand, in my scenario<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l2 level1 lfo5">Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l2 level1 lfo5">Then try to free all messages via rte_pktmbuf_free<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l2 level1 lfo5">Freed 1 unit and 31 unit is not freed. memory leak<o:p></o:p></li></ol> <o:p> </o:p> Other scenario,<o:p></o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l4 level1 lfo6">Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 packet is received from Kernel<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l4 level1 lfo6">Push to ethernet_device via rte_eth_tx_burst <o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l4 level1 lfo6">There is not any free operation by rte_eth_tx_burst<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l4 level1 lfo6">Try to free via rte_pktmbuf_free<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-8.0pt;mso-list:l4 level1 lfo6">1 unit is freed 31 unit is left in memory. Still memory leak<o:p></o:p></li></ol> <o:p> </o:p> <o:p> </o:p> What i am missing ? I think same issue happens in version 17.11 .<o:p></o:p> <o:p> </o:p> unsigned<o:p></o:p> rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)<o:p></o:p> {<o:p></o:p> num = RTE_MIN(kni_fifo_free_count(kni->rx_q), num);<o:p></o:p> void *phy_mbufs[num];<o:p></o:p> unsigned int ret;<o:p></o:p> unsigned int i;<o:p></o:p> <o:p> </o:p> for (i = 0; i < num; i++)<o:p></o:p> phy_mbufs[i] = va2pa_all(mbufs[i]);<o:p></o:p> <o:p> </o:p> ret = kni_fifo_put(kni->rx_q, phy_mbufs, num);<o:p></o:p> <o:p> </o:p> /* Get mbufs from free_q and then free them */<o:p></o:p> kni_free_mbufs(kni); �------ Here is freeing unused allocations. <o:p></o:p> <o:p> </o:p> return ret;<o:p></o:p> }<o:p></o:p> unsigned<o:p></o:p> rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num)<o:p></o:p> {<o:p></o:p> unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);<o:p></o:p> <o:p> </o:p> /* If buffers removed, allocate mbufs and then put them into alloc_q */<o:p></o:p> if (ret)<o:p></o:p> kni_allocate_mbufs(kni);<o:p></o:p> <o:p> </o:p> return ret;<o:p></o:p> }<o:p></o:p> <o:p> </o:p> static void<o:p></o:p> kni_free_mbufs(struct rte_kni *kni)<o:p></o:p> {<o:p></o:p> int i, ret;<o:p></o:p> struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];<o:p></o:p> <o:p> </o:p> ret = kni_fifo_get(kni->free_q, (void **)pkts, MAX_MBUF_BURST_NUM); <<�- to free all allocated memory needs to use this function. (kni->free_q)<o:p></o:p> if (likely(ret > 0)) {<o:p></o:p> for (i = 0; i < ret; i++)<o:p></o:p> rte_pktmbuf_free(pkts[i]);<o:p></o:p> }<o:p></o:p> }<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Best Regards.<o:p></o:p> <o:p> </o:p> <div> ___<o:p></o:p> Yasin CANER<o:p></o:p> Lider M�hendis<o:p></o:p> Ulak Haberle�me A.�. Ankara<o:p></o:p> </div> <o:p> </o:p> <div> <div style="border:none;border-top:solid #E1E1E1 1.0pt;padding:3.0pt 0cm 0cm 0cm"> From: Yasin CANER Sent: Thursday, May 4, 2023 10:32 AM To: users@dpdk.org Subject: DPDK 22.11 - How to fix memory leak for KNI - How to debug<o:p></o:p> </div> </div> <o:p> </o:p> Hello all,<o:p></o:p> <o:p> </o:p> I think there is a memory leak for KNI. <o:p></o:p> <o:p> </o:p> Firstly, try to active trace mod�le to follow memory management but could not. �t doesn’t create file and dont have any clue.<o:p></o:p> <o:p> </o:p> Run Command : -c dpdk_core_mask -d librte_net_virtio.so -d librte_mbuf.so -d librte_mempool.so -d librte_mempool_ring.so -d librte_mempool_stack.so -d librte_mempool_bucket.so -d librte_kni.so --log-level lib.kni:debug --log-level lib.eal:debug --log-level lib.ethdev:debug --trace=kni --trace-dir=/tmp/<o:p></o:p> <o:p> </o:p> <o:p> </o:p> Secondly, I used followed functions.<o:p></o:p> <o:p> </o:p> ``code<o:p></o:p> used_mpool = rte_mempool_in_use_count(rdpdk_cfg->mbuf_pool);<o:p></o:p> count_mpool = rte_mempool_avail_count(rdpdk_cfg->mbuf_pool);<o:p></o:p> ``<o:p></o:p> <o:p> </o:p> After calling function rte_kni_rx_burst, 32 unit is allocated. Then i force to free message_buf (mbuf). It frees 1 unit. 31 units left in memory!<o:p></o:p> <o:p> </o:p> <o:p> </o:p> How to fix or understand this issue.<o:p></o:p> Follow logs,<o:p></o:p> <o:p> </o:p> <o:p> </o:p> <o:p> </o:p> <ol style="margin-top:0cm" start="1" type="1"> <li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 lrtc():3212> [KNI]Picked up 1 packets from port 0 [KNI:F000] � 1 packet is received from Kernel that is allocate 32 unit<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:468][avail_mpool:9931]<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2536> [KNI] i:0/1<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2616> [KNI][EGR] P:[IPv6] P:[0] [fe80::f816:3eff:fe93:f5fd]->[ff02::2] � Packet is a broadcast packet IPv6<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2620> [KNI][EGR][pkt-len:70]<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:467][avail_mpool:9932] � mbuf is freed to understand mem-leak. �t is same happens after calling rte_eth_tx_burst<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 lrtc():3212> [KNI]Picked up 1 packets from port 1 [KNI:F000] � 1 packet is received from Kernel that is allocate 32 unit 9932 to 9900 then same process happens and 31 units is not freed.<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:499][avail_mpool:9900]<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2536> [KNI] i:0/1<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2616> [KNI][EGR] P:[IPv6] P:[1] [fe80::f816:3eff:fed2:9101]->[ff02::2]<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 pkni():2620> [KNI][EGR][pkt-len:70]<o:p></o:p></li><li class="MsoListParagraph" style="margin-left:-15.5pt;mso-list:l0 level1 lfo3"> (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:498][avail_mpool:9901]<o:p></o:p></li></ol> <o:p> </o:p> <o:p> </o:p> Kernel : 5.4.0-146-generic #163-Ubuntu SMP Fri Mar 17 18:26:02 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux<o:p></o:p> Ubuntu 20.04<o:p></o:p> DPDK dpdk-stable-22.11.1<o:p></o:p> �gb_uio is used.<o:p></o:p> <o:p> </o:p> Best regards.<o:p></o:p> ___<o:p></o:p> Yasin CANER<o:p></o:p> Lider M�hendis<o:p></o:p> Ulak Haberle�me A.�. Ankara<o:p></o:p> <o:p> </o:p> </div> <!DOCTYPE html> Bu elektronik posta ve onunla iletilen b�t�n dosyalar sadece g�ndericisi taraf�ndan almas� ama�lanan yetkili, ger�ek ya da t�zel ki�inin kullan�m� i�indir. E�er s�z konusu yetkili al�c� de�ilseniz, bu elektronik postan�n i�eri�ini a��klaman�z, kopyalaman�z, y�nlendirmeniz ve kullanman�z kesinlikle yasakt�r ve bu elektronik postay� derhal silmeniz gerekmektedir. �irketimiz bu mesaj�n i�erdi�i bilgilerin do�rulu�u veya eksiksiz oldu�u konusunda herhangi bir garanti vermemektedir. Bu nedenle, bu bilgilerin ne �ekilde olursa olsun i�eri�inden, iletilmesinden, al�nmas�ndan ve saklanmas�ndan sorumlu de�ildir. Bu mesajdaki g�r��ler yaln�zca g�nderen ki�iye aittir ve �irketimizin g�r��lerini yans�tmayabilir. Taraf�n�z ile payla��lan ki�isel verilerin, 6698 say�l� Ki�isel Verilerin Korunmas� Kanununa uygun olarak i�lenmesi gere�ini bilginize sunar�z. <hr style:?border-top:="" 1px="" solid="" black?=""> This e-mail and all files sent with it are intended for authorized natural or legal persons, who should be the only persons to open and read them. If you are not an authorized recipient, you are strictly prohibited from disclosing, copying, forwarding, and using the contents of this e-mail, and you must immediately delete it. Our company does not guarantee the accuracy or thoroughness of the information contained in this message. It is therefore in no way responsible for the content, sending, retrieval and storage of this information. The opinions contained in this message are the views of the sender only and do not necessarily reflect the views of the company. We would like to inform you that any personal data shared with you should be processed in accordance with the Law on Protection of Personal Data numbered 6698. </body> </html>