From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 00F8842ABC for ; Tue, 9 May 2023 13:15:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6D7B1410FC; Tue, 9 May 2023 13:15:11 +0200 (CEST) Received: from mail-wm1-f48.google.com (mail-wm1-f48.google.com [209.85.128.48]) by mails.dpdk.org (Postfix) with ESMTP id 03AEB410FA for ; Tue, 9 May 2023 13:15:10 +0200 (CEST) Received: by mail-wm1-f48.google.com with SMTP id 5b1f17b1804b1-3f315735514so203226955e9.1 for ; Tue, 09 May 2023 04:15:10 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683630910; x=1686222910; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=i0+Zpi9CUTwcuJ6Xk+fwK8V3dvUgjIWu4UTeKHGqdOo=; b=Gxgk7JFB67l07nWTZXSyUUU+VTFPPZUPIVpsQ2du1jmTAvMKDo89CkSQ0Adt1+vgDO 6jYDjOaR+hTeF+YS+TBZrxs8H6rnuSmC9uGt8NlnN1MViYGgMcRysNBjdBaheLD/F+lM kmTJmr9f78ZmcRUDRmnH9MNzdbF2JbCdGVNoHqp1nWTj1BVDbDxAVyS8EGWVkHMUXbNl Z65SZlkTIysWQ52j+qvmf0vEtfwIIRqiLou4D7ZX6PmgMeMsnq0om1XEaT9vuEt9oGKT SrH2EUHG/XrSI+fQKzGh6Ie4y3V/piSmmvpVVo2vpPpc4W9G9Y3iomXu0+/aLl8SJA+s GXUQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683630910; x=1686222910; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :x-gm-message-state:from:to:cc:subject:date:message-id:reply-to; bh=i0+Zpi9CUTwcuJ6Xk+fwK8V3dvUgjIWu4UTeKHGqdOo=; b=h/YaGkREodK4dMXjN6Tt/nMATjvAG5FjkNirEuDQw5uoZZioJIuEG3KSD2J02IrRkh 4/pkGcYYPkDOTeJbtLXokvyciCwV7+qsEXDER1XfPPWuErVJNYBwqOhMpbS6sTCfpy1F YyqZSMOZproHJQv4+6hdOTvWTzeiLtUsXi2nR0y5TtzXL1PvoQkjNVl/Nzrgxcz7njjD 9dP6fwosg1ukgbDS36+Zjg45eNR7BrG8N/LcJfOljUNHsmiyeSNrMvMluLyXoRP/Dh+Y aeP56LAThHXFCK0QEN+CzNZBXnmrmiiwRMQAAknwsDxR7S3tLrP4c51WQo7GKDTTI3Ug e5AQ== X-Gm-Message-State: AC+VfDxPZW7I1WQaHeHcN0taiN6Qk+ATvjmciRoV0x3RMGdQnZzCPC25 e5iugidUwxyC8XrX86/ZEvkcArjcqX2k051Qgp8JznIE X-Google-Smtp-Source: ACHHUZ5p96ibuM0dBJoq/jUYh4+WlzFaBuyE2fBntdnx2x+NMzKdwaTvMLaBh7NkRW5lec2su60DFFc1ZQwTUC1RKZE= X-Received: by 2002:adf:fdd1:0:b0:306:2ff1:5227 with SMTP id i17-20020adffdd1000000b003062ff15227mr8257433wrs.23.1683630910287; Tue, 09 May 2023 04:15:10 -0700 (PDT) MIME-Version: 1.0 References: <20230508091845.646caf17@hermes.local> In-Reply-To: <20230508091845.646caf17@hermes.local> From: Yasin CANER Date: Tue, 9 May 2023 14:13:17 +0300 Message-ID: Subject: Re: DPDK 22.11 - How to fix memory leak for KNI - How to debug To: Stephen Hemminger , users@dpdk.org Content-Type: multipart/alternative; boundary="0000000000005734fa05fb40de8c" X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: users-bounces@dpdk.org --0000000000005734fa05fb40de8c Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello, I draw a flow via asciiflow to explain myself better. Problem is after transmitting packets(mbufs) , it never puts in the kni->free_q to back to the original pool. Each cycle, it allocates another 32 units that cause leaks. Or I am missing something. I already tried the rte_eth_tx_done_cleanup() function but it didn't fix anything. I am working on a patch to fix this issue but I am not sure if there is another way. Best regards. https://pastebin.ubuntu.com/p/s4h5psqtgZ/ unsigned rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int num) { unsigned int ret =3D kni_fifo_get(kni->tx_q, (void **)mbufs, num); /* If buffers removed, allocate mbufs and then put them into alloc_q */ /* Question, how to test buffers is removed or not?*/ if (ret) kni_allocate_mbufs(kni); return ret; } Stephen Hemminger , 8 May 2023 Pzt, 19:18 tarihinde =C5=9Funu yazd=C4=B1: > On Mon, 8 May 2023 09:01:41 +0300 > Yasin CANER wrote: > > > Hello Stephen, > > > > Thank you for response, it helps me a lot. I understand problem better. > > > > After reading mbuf library ( > > https://doc.dpdk.org/guides/prog_guide/mempool_lib.html) i realized > that > > 31 units allocation memory slot doesn't return to pool! > > If receive burst returns 1 mbuf, the other 31 pointers in the array > are not valid. They do not point to mbufs. > > > 1 unit mbuf can be freed via rte_pktmbuf_free so it can back to pool. > > > > Main problem is that allocation doesn't return to original pool, act as > > used. So, after following rte_pktmbuf_free > > < > http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a69= 02 > > > > function, > > i realized that there is 2 function to helps to mbufs back to pool. > > > > These are rte_mbuf_raw_free > > < > http://doc.dpdk.org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d74= 32 > > > > and rte_pktmbuf_free_seg > > < > http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f= 37 > >. > > I will focus on them. > > > > If there is another suggestion, I will be very pleased. > > > > Best regards. > > > > Yasin CANER > > Ulak > > --0000000000005734fa05fb40de8c Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello,

I draw a flow v= ia asciiflow to explain myself better. Problem is after transmitting=C2=A0p= ackets(mbufs) , it never puts in the kni->free_q to back to the original= pool. Each cycle, it allocates another 32 units that cause leaks. Or I am = missing something.

I already tried the rte_eth_tx_= done_cleanup() function but it didn't fix anything.

I am working on a=C2=A0patch to fix this issue but I am not sure if t= here is=C2=A0another way.

Best regards.
=


unsigned
rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbuf = **mbufs, unsigned int num)
{
unsigned int ret =3D kni_fifo_get(kni-&= gt;tx_q, (void **)mbufs, num);

/* If buffers removed, allocate mbuf= s and then put them into alloc_q */
/* Question, how to test buff= ers is removed or not?*/
if (ret)
=C2=A0 =C2=A0 kni_allocate_mbufs(k= ni);

return ret;
}

Stephen Hemminger <stephen@networkplumber.org>, 8 May 2= 023 Pzt, 19:18 tarihinde =C5=9Funu yazd=C4=B1:
On Mon, 8 May 2023 09:01:41 +0300
Yasin CANER <= yasinncaner@gmail.com> wrote:

> Hello Stephen,
>
> Thank you for response, it helps me a lot. I understand problem better= .
>
> After reading mbuf library (
> https://doc.dpdk.org/guides/prog_guide/m= empool_lib.html)=C2=A0 i realized that
> 31 units allocation memory slot doesn't return to pool!

If receive burst returns 1 mbuf, the other 31 pointers in the array
are not valid. They do not point to mbufs.

> 1 unit mbuf can be freed via rte_pktmbuf_free so it can back to pool.<= br> >
> Main problem is that allocation doesn't return to original pool, a= ct as
> used. So, after following rte_pktmbuf_free
> <http://doc.dpdk.= org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6902>
> function,
> i realized that there is 2 function to helps to mbufs back to pool. >
> These are rte_mbuf_raw_free
> <http://doc.dpdk.= org/api/rte__mbuf_8h.html#a9f188d53834978aca01ea101576d7432>
>=C2=A0 and rte_pktmbuf_free_seg
> <http://doc.dpdk.= org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82f37>.
> I will focus on them.
>
> If there is another suggestion, I will be very pleased.
>
> Best regards.
>
> Yasin CANER
> Ulak

--0000000000005734fa05fb40de8c--