<div dir="ltr">Hello Ferruh,<div><br>Thanks for your kind response. Also thanks to Stephen.</div><div><br></div><div>Even if 1 packet is consumed from the kernel , each time rx_kni allocates another 32 units. After a while all mempool is used in alloc_q from kni. there is not any room for it.</div><div><br></div><div>Do you think my mistake is using one and common mempool usage both kni and eth?</div><div><br></div><div>If it needs a separate mempool , i'd like to note in docs.</div><div><br></div><div>Best regards.</div></div><br><div class="gmail_quote"><div dir="ltr" class="gmail_attr">Ferruh Yigit <<a href="mailto:ferruh.yigit@amd.com">ferruh.yigit@amd.com</a>>, 17 May 2023 Çar, 20:53 tarihinde şunu yazdı:<br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left:1px solid rgb(204,204,204);padding-left:1ex">On 5/9/2023 12:13 PM, Yasin CANER wrote:<br>
> Hello,<br>
> <br>
> I draw a flow via asciiflow to explain myself better. Problem is after<br>
> transmitting packets(mbufs) , it never puts in the kni->free_q to back<br>
> to the original pool. Each cycle, it allocates another 32 units that<br>
> cause leaks. Or I am missing something.<br>
> <br>
> I already tried the rte_eth_tx_done_cleanup() function but it didn't fix<br>
> anything.<br>
> <br>
> I am working on a patch to fix this issue but I am not sure if there<br>
> is another way.<br>
> <br>
> Best regards.<br>
> <br>
> <a href="https://pastebin.ubuntu.com/p/s4h5psqtgZ/" rel="noreferrer" target="_blank">https://pastebin.ubuntu.com/p/s4h5psqtgZ/</a><br>
> <<a href="https://pastebin.ubuntu.com/p/s4h5psqtgZ/" rel="noreferrer" target="_blank">https://pastebin.ubuntu.com/p/s4h5psqtgZ/</a>><br>
> <br>
> <br>
> unsigned<br>
> rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned<br>
> int num)<br>
> {<br>
> unsigned int ret = kni_fifo_get(kni->tx_q, (void **)mbufs, num);<br>
> <br>
> /* If buffers removed, allocate mbufs and then put them into alloc_q */<br>
> /* Question, how to test buffers is removed or not?*/<br>
> if (ret)<br>
> kni_allocate_mbufs(kni);<br>
> <br>
> return ret;<br>
> }<br>
> <br>
<br>
Selam Yasin,<br>
<br>
<br>
You can expect 'kni->alloc_q' fifo to be full, this is not a memory leak.<br>
<br>
As you pointed out, number of mbufs consumed by kernel from 'alloc_q'<br>
and number of mbufs added to 'alloc_q' is not equal and this is expected.<br>
<br>
Target here is to prevent buffer underflow from kernel perspective, so<br>
it will always have available mbufs for new packets.<br>
That is why new mbufs are added to 'alloc_q' at worst same or sometimes<br>
higher rate than it is consumed.<br>
<br>
You should calculate your mbuf requirement with the assumption that<br>
'kni->alloc_q' will be full of mbufs.<br>
<br>
<br>
'kni->alloc_q' is freed when kni is removed.<br>
Since 'alloc_q' holds physical address of the mbufs, it is a little<br>
challenging to free them in the userspace, that is why first kernel<br>
tries to move mbufs to 'kni->free_q' fifo, please check<br>
'kni_net_release_fifo_phy()' for it.<br>
<br>
If all moved to 'free_q' fifo, nothing left to in 'alloc_q', but if not,<br>
userspace frees 'alloc_q' in 'rte_kni_release()', with following call:<br>
`kni_free_fifo_phy(kni->pktmbuf_pool, kni->alloc_q);`<br>
<br>
<br>
I can see you have submitted fixes for this issue, although as I<br>
explained above I don't think a defect exist, I will review them<br>
today/tomorrow.<br>
<br>
Regards,<br>
Ferruh<br>
<br>
<br>
> Stephen Hemminger <<a href="mailto:stephen@networkplumber.org" target="_blank">stephen@networkplumber.org</a><br>
> <mailto:<a href="mailto:stephen@networkplumber.org" target="_blank">stephen@networkplumber.org</a>>>, 8 May 2023 Pzt, 19:18 tarihinde<br>
> şunu yazdı:<br>
> <br>
> On Mon, 8 May 2023 09:01:41 +0300<br>
> Yasin CANER <<a href="mailto:yasinncaner@gmail.com" target="_blank">yasinncaner@gmail.com</a> <mailto:<a href="mailto:yasinncaner@gmail.com" target="_blank">yasinncaner@gmail.com</a>>><br>
> wrote:<br>
> <br>
> > Hello Stephen,<br>
> ><br>
> > Thank you for response, it helps me a lot. I understand problem<br>
> better.<br>
> ><br>
> > After reading mbuf library (<br>
> > <a href="https://doc.dpdk.org/guides/prog_guide/mempool_lib.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/prog_guide/mempool_lib.html</a><br>
> <<a href="https://doc.dpdk.org/guides/prog_guide/mempool_lib.html" rel="noreferrer" target="_blank">https://doc.dpdk.org/guides/prog_guide/mempool_lib.html</a>>) i<br>
> realized that<br>
> > 31 units allocation memory slot doesn't return to pool!<br>
> <br>
> If receive burst returns 1 mbuf, the other 31 pointers in the array<br>
> are not valid. They do not point to mbufs.<br>
> <br>
> > 1 unit mbuf can be freed via rte_pktmbuf_free so it can back to pool.<br>
> ><br>
> > Main problem is that allocation doesn't return to original pool,<br>
> act as<br>
> > used. So, after following rte_pktmbuf_free<br>
> ><br>
> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6902" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6902</a> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6902" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6902</a>>><br>
> > function,<br>
> > i realized that there is 2 function to helps to mbufs back to pool.<br>
> ><br>
> > These are rte_mbuf_raw_free<br>
> ><br>
> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d7432" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d7432</a> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d7432" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d7432</a>>><br>
> > and rte_pktmbuf_free_seg<br>
> ><br>
> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f37" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f37</a> <<a href="http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f37" rel="noreferrer" target="_blank">http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f37</a>>>.<br>
> > I will focus on them.<br>
> ><br>
> > If there is another suggestion, I will be very pleased.<br>
> ><br>
> > Best regards.<br>
> ><br>
> > Yasin CANER<br>
> > Ulak<br>
> <br>
<br>
</blockquote></div>