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 151CB42AD6 for ; Thu, 11 May 2023 16:16:00 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7649040DF6; Thu, 11 May 2023 16:15:59 +0200 (CEST) Received: from mail-wm1-f46.google.com (mail-wm1-f46.google.com [209.85.128.46]) by mails.dpdk.org (Postfix) with ESMTP id D5394406B6 for ; Thu, 11 May 2023 16:15:57 +0200 (CEST) Received: by mail-wm1-f46.google.com with SMTP id 5b1f17b1804b1-3f49bf0223cso19827735e9.1 for ; Thu, 11 May 2023 07:15:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20221208; t=1683814557; x=1686406557; h=to:subject:message-id:date:from:in-reply-to:references:mime-version :from:to:cc:subject:date:message-id:reply-to; bh=gDTtAgbhsYXBMz0632PBqRJXlC7laBSDL/re6CfI1N0=; b=QPbliCzo/eWXwIrBldavxyStAFCwxheAvdEb6FZ7K0g43n9Bq+1bC0dSqmW+goKaEC aAJK9F79U64Bgu+2dSN8tuCG26sAgorDt1swBmPdQ/4uEG19BBgnfRp0b8U9GlIb6ZCt UrpBCAmQNKGxyDI3V+4fpWVNlQQSJYwYOQAwsR2oTDrZL3sHQnKQ4oWHiPk6aI3va9PC zj0INTMhfJ6VcXRBoLmJzwmjxpxV3CVzvgrXWg3dMZyFfTVv5bh5SKjdclbzvrEFh6wN XCxBGpaRVS4pvqbNvJmrxLhv99XwEtqrA0/bIwQ16bfL3/OC/00MqlQiluK8KS6aEpjc xeCQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1683814557; x=1686406557; 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=gDTtAgbhsYXBMz0632PBqRJXlC7laBSDL/re6CfI1N0=; b=ZM3CDRGSoNFUOLpw4dTnFeQdcjkoUMFEiScaSXVJ3tr9XrPn1rCGrFwndswO5xM1Vc uy8v9koGzd1zb9rbyCXJIR3mCt/w94PLwTD5ZkbvsUXc1MbAJJjh7xeW71XgwSc8Ypms B/QZ5g4Q/5exQ+2x/CYiyUshdiAHh2wBw6DqaZJL/BV1Y+Holhn2OveMy/qCnnuZTp3E xIs9Pv0csWHryz0uKZQlOjJixuZUruWxslobD8Fbm9zjOBWIQqwEk1zCjy//eIBUitvJ TWsJx48NNbG46iOPCrabkxko/qBuRFxRYSLzCxShc1/G8PQPVCbpTMrNwOCy9nk2/1kW J8Uw== X-Gm-Message-State: AC+VfDxhx2T/P/MnCZxjM0Y6wfl4VwKJvw3Z31dHepdq+VGw3fQkA5xD 5qGDg4KiuzhYawLh1DHdPCFTkXJjeIMj2Kk41ihCt8ES+Lk= X-Google-Smtp-Source: ACHHUZ7abjcugk2lhVD4lNDGS+PRhG9sYCE5ndLjyLfjCIc10wlrOvZHOU9OCduw8bHKBHCcwu3bBw3NKsBARIFynhU= X-Received: by 2002:a7b:cb94:0:b0:3f4:ec32:69fd with SMTP id m20-20020a7bcb94000000b003f4ec3269fdmr1218830wmi.40.1683814557346; Thu, 11 May 2023 07:15:57 -0700 (PDT) MIME-Version: 1.0 References: <20230508091845.646caf17@hermes.local> In-Reply-To: From: Yasin CANER Date: Thu, 11 May 2023 17:14:03 +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="0000000000008eee9c05fb6ba03a" 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 --0000000000008eee9c05fb6ba03a Content-Type: text/plain; charset="UTF-8" Content-Transfer-Encoding: quoted-printable Hello all, I fixed both bugs on my work computer. but it is hard to push a patch because dpdk git has so many steps. https://bugs.dpdk.org/show_bug.cgi?id=3D1227 https://bugs.dpdk.org/show_bug.cgi?id=3D1229 Best regards. Yasin CANER , 9 May 2023 Sal, 14:13 tarihinde =C5=9F= unu yazd=C4=B1: > 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 a= s >> > used. So, after following rte_pktmbuf_free >> > < >> http://doc.dpdk.org/api/rte__mbuf_8h.html#a1215458932900b7cd5192326fa4a6= 902 >> > >> > 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#a9f188d53834978aca01ea101576d7= 432 >> > >> > and rte_pktmbuf_free_seg >> > < >> http://doc.dpdk.org/api/rte__mbuf_8h.html#a006ee80357a78fbb9ada2b0432f82= f37 >> >. >> > I will focus on them. >> > >> > If there is another suggestion, I will be very pleased. >> > >> > Best regards. >> > >> > Yasin CANER >> > Ulak >> >> --0000000000008eee9c05fb6ba03a Content-Type: text/html; charset="UTF-8" Content-Transfer-Encoding: quoted-printable
Hello all,

=C2=A0I fixed both bugs on m= y work computer. but it is hard to push a patch because dpdk git has so man= y steps.

<= div>https://bugs.d= pdk.org/show_bug.cgi?id=3D1229

Best regard= s.

Yasin CANER <yasinncane= r@gmail.com>, 9 May 2023 Sal, 14:13 tarihinde =C5=9Funu yazd=C4=B1:<= br>
Hello,

I draw a flow via asciiflow to = explain myself better. Problem is after transmitting=C2=A0packets(mbufs) , = it never puts in the kni->free_q to back to the original pool. Each cycl= e, it allocates another 32 units that cause leaks. Or I am missing somethin= g.

I already tried the rte_eth_tx_done_cleanup() f= unction but it didn't fix anything.

I am worki= ng on a=C2=A0patch to fix this issue but I am not sure if there is=C2=A0ano= ther way.

Best regards.

<= a href=3D"https://pastebin.ubuntu.com/p/s4h5psqtgZ/" target=3D"_blank">http= s://pastebin.ubuntu.com/p/s4h5psqtgZ/


=
unsigned
rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbu= f **mbufs, unsigned int num)
{
unsigned int ret =3D kni_fifo_get(kni= ->tx_q, (void **)mbufs, num);

/* If buffers removed, allocate mb= ufs and then put them into alloc_q */
/* Question, how to test bu= ffers is removed or not?*/
if (ret)
=C2=A0 =C2=A0 kni_allocate_mbufs= (kni);

return ret;
}

Stephen Hemminger <stephen@networkplumber.= org>, 8 May 2023 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

--0000000000008eee9c05fb6ba03a--