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 C4A6E42A5D for ; Thu, 4 May 2023 15:36:23 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 543BF41144; Thu, 4 May 2023 15:36:23 +0200 (CEST) Received: from EUR04-VI1-obe.outbound.protection.outlook.com (mail-vi1eur04on2118.outbound.protection.outlook.com [40.107.8.118]) by mails.dpdk.org (Postfix) with ESMTP id 11581410DC for ; Thu, 4 May 2023 15:00:37 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=Rzarx6LTAXUo9Gl3Qat2WheTWfpoJANM91W19Dnn/QwjNeIuGBqjpvfIlc7FaqxNrdKZsLf18C0T7RO4aR3QRAznEUyILW3+euU8yPLmz1Jpb6tGNNT8Urhm9UrNSegxPCZW9uQD/+solMuEo4kp7hRLsiKBm6H2eS3dMkvEvxD3oqMCeJLHcR10m9Z/5bECXoz5wgxMN7iDeOfBcEM2N50KTBuef9RaDU0Ri6xGio6S/MXVVrU7+dLv9vqxlklDXqZHXPMKzhojiRBC6cZRWR5qhDKpfH/TVVnyRftnaVly2Fe/ugXrebo9XsiqYxk/gBiNvyOjTNhgBukELPQJiA== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=n+7OMCM18aDHExVRSJ5j7I7AN9iQI6xZrojkgMCGmZ8=; b=XmZPsQmz1GNjUCUTohavhMGJB6krn5dm4uMWsc4+b47FCpyU9dXXFC0elZua0M0ChIRWFI4AhYAJAoyxs1spBggA1wUXVOj1GBueAZk5qWjc3CyknJpTMMe1mcGtxIyMKCK7V2RgpSMTuQIG5eQpHzJv2gygMa78QBfQ93z/cTB7lkKUW63rgWacfLvufPwmaUMRB2tqYU/OQlgo5Pak1gelzxNw7aFumKFL+mZNEqsP1Y/sDBnfAABlKN7twKAZVJM5+MxiHP0EzX/pXHzJRY1ykTshqd28fv2ovlRrALrMAnlCMrFfSmObGlsA+megks0q3d2TfAurOqSUKQP2kw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=ulakhaberlesme.com.tr; dmarc=pass action=none header.from=ulakhaberlesme.com.tr; dkim=pass header.d=ulakhaberlesme.com.tr; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=ulakhaber.onmicrosoft.com; s=selector2-ulakhaber-onmicrosoft-com; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=n+7OMCM18aDHExVRSJ5j7I7AN9iQI6xZrojkgMCGmZ8=; b=QgrqgZ0ShAPaw95yPuBihzAZxlQAAp62iuXd5d+eXO/QdIdpDbAnY+Zhalko5dNf3BpoxScURMtMgkkXSJp3+A5MRcXYBVHmxe4reuc78lSa+ljKiWo7OQujCYsVXmanclUPM3FwEqLJDGGv0gfgA3oJAfZkWgZxQrDYQiRwHFo= Received: from AM9P189MB1554.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:2fc::7) by AS4P189MB2254.EURP189.PROD.OUTLOOK.COM (2603:10a6:20b:582::15) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6363.26; Thu, 4 May 2023 13:00:33 +0000 Received: from AM9P189MB1554.EURP189.PROD.OUTLOOK.COM ([fe80::9f85:4e01:21c6:137d]) by AM9P189MB1554.EURP189.PROD.OUTLOOK.COM ([fe80::9f85:4e01:21c6:137d%6]) with mapi id 15.20.6363.026; Thu, 4 May 2023 13:00:32 +0000 From: Yasin CANER To: "users@dpdk.org" Subject: RE: DPDK 22.11 - How to fix memory leak for KNI - How to debug Thread-Topic: DPDK 22.11 - How to fix memory leak for KNI - How to debug Thread-Index: Adl+WjVTffkHhbsmSXqNKY6l+gB1VAAKlAWg Date: Thu, 4 May 2023 13:00:32 +0000 Message-ID: References: In-Reply-To: Accept-Language: tr-TR, en-US Content-Language: tr-TR X-MS-Has-Attach: X-MS-TNEF-Correlator: authentication-results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=ulakhaberlesme.com.tr; x-ms-publictraffictype: Email x-ms-traffictypediagnostic: AM9P189MB1554:EE_|AS4P189MB2254:EE_ x-ms-office365-filtering-correlation-id: 94aaeeb9-79a8-4569-cf14-08db4c9f8b85 x-ms-exchange-senderadcheck: 1 x-ms-exchange-antispam-relay: 0 x-microsoft-antispam: BCL:0; x-microsoft-antispam-message-info: ATq7WZGUI6pDkj+VVLN4hn7Ptn9NlG6sonuAhIor4ZVv5lhu04Fko6rkJy5QwChDiYdi/B2Io7hvY9X5T74x7Wznkc24XHTp8teCep6nhFu0h/gBoAJoh7OnWG2bFqVx+uQ6usjCsCvJC9WKEYqwhcBcAHBNOiYIMq4vUi3sbhtNQt1A1+/7MN0bRVySRqrAmI3QaKTRalVoBzWouheaoiK06xF9IQiN0CLBWOKvZdIwuEhBS/aHRw1MhB/esWmEWPOaYE+dyeSDuMy9m+NeifVM12BrR+qv68ZyXXjiQr8IBR4D6qFxngOfuvHsIFlboxaZ0hKdLCMNhDx8Ispt+0OdJe54uZPMweG/jWmYIb6SUMT94cfIFBh2I5yHHh9wv9pDUWeL4DpcJ4AXULiHL5XLq6IlWf4wMvgIa80wfVRAMola4wGqLxCf0odtYfNlY4V9WyT2xH3hkPCwRovKjzXim42PY7qCMjQUylxSX0UoNqgfZ4MwpB8GizuF8Gg4eFYcY4cNgOsrY/WztkbU34tJiGuHPlL+Rhs/1UQExDEJN784uhWFqZwz5CiZQOZlcXUxIHBs1O+KJB1cK3dexr/ike/DGIPk4fDcJZSMgHWghw4HOPN+EqdP4UkA4J3Y x-forefront-antispam-report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:AM9P189MB1554.EURP189.PROD.OUTLOOK.COM; PTR:; CAT:NONE; SFS:(13230028)(4636009)(376002)(366004)(396003)(136003)(346002)(39850400004)(451199021)(38100700002)(478600001)(122000001)(55016003)(52536014)(5660300002)(8936002)(8676002)(86362001)(26005)(76116006)(66946007)(66574015)(66446008)(7696005)(6916009)(64756008)(83380400001)(66556008)(6506007)(2940100002)(33656002)(316002)(9686003)(186003)(41300700001)(53546011)(2906002)(66476007)(19627235002)(71200400001)(38070700005); DIR:OUT; SFP:1102; x-ms-exchange-antispam-messagedata-chunkcount: 1 x-ms-exchange-antispam-messagedata-0: =?iso-8859-9?Q?lx9MbM8yJeKWsZrqP8tmjFK1gwnsaeVa64kdj4c1WQDXC/O+V5fLtQdRct?= =?iso-8859-9?Q?1uiK/4cKTWYnmiVXwaESW4SvqeuhBb/PyaJN9f8mz90ReTPv8KVBDnKCbC?= =?iso-8859-9?Q?RyFbys3awsw4VyfhRM5NnilVMShFF0/G5ArwQo24ZruMomhbTDN6GvD+QL?= =?iso-8859-9?Q?lZOIJlYvgAbnB0M1NWNJ7DeLBmb2oYJc/2as7n6N85hg4LQEjFQNwofrbD?= =?iso-8859-9?Q?sEljApsSnpi53Mg9pJVnQz0174vKXJb18djICTpfLANR98RT8ZgC4OaHFP?= =?iso-8859-9?Q?o2wACIKym2oJoYT7TKbWttdadiz7IKR/GE1lyZ3M4o2OetvokX8MC5lljI?= =?iso-8859-9?Q?Q3oHKacO62JNNb6apVX6BCbSngG2W0X3XfezsXYx6SrbwHth9COCdekw6D?= =?iso-8859-9?Q?OfRbhZGTveDyxyM6ZClZxFO6sw3jqYRaxPqprx+5qNhlBqUbtSeWdxrXyU?= =?iso-8859-9?Q?d9ldSRd+zTjbPmMi/rWvixxXGzIJJrEzf7wA0o/WdtC/TtV4Ecx6MYMSr7?= =?iso-8859-9?Q?Ypy4MUilh1V0+6yb+HRZyBpyG195uGyFeEuaEkS93lHFeSMQzEl5iXXoON?= =?iso-8859-9?Q?IS8CocGYbyDNTfJB9eKU2O7QzCJqWFXxvbTdjMJUycR7WY1zUlQdNPaRzm?= =?iso-8859-9?Q?YEiRhOhL5KrFNmvN3f6Uco/3sO4IKMVl0ul0GsjnbPBAMuc7ZfAkTUOJnn?= =?iso-8859-9?Q?Xv0CmJwG41/X9Kq7H1AvmOGmckS5LJ33xS6TVTBZ2Ik0kf/xZNI2/4/bQA?= =?iso-8859-9?Q?XmY6lnWhWYlz4qvQNGJm0HDHhcnByYTdRlHgNVCJML8biToLdlX4eUmsyI?= =?iso-8859-9?Q?TYkCdbagcF0XYno5SXtGf6JEJyKlpaSjNIIpiIsy76BlrPtFUH1i5MFY2K?= =?iso-8859-9?Q?UF56+oL5j7yEQievbccPEIXeWnvUprozO20VeU3pvfNfnz2dphfnNFeVhE?= =?iso-8859-9?Q?+dEG/Lk7FNyoxv2hIw1RcnBnCAJCIudn5tHHR4drifejtmhpDCs4S6xCaP?= =?iso-8859-9?Q?vv9b3G4DnafGeM2d+DDi23+SYs/l9d6TNwT9xJzkZtIaOdjgA7FOciAQ7K?= =?iso-8859-9?Q?bAAGZZySTE0rMgQ/pILmTLYmwU+dN8u1ZW7BteqNrEYoXBG/yYit+uUjul?= =?iso-8859-9?Q?zrs5sp2Gd9rIKLv8grTXn0snY7f2v7KR0krazRtYlDrVmj7Tv5Veds3z/+?= =?iso-8859-9?Q?iFRfubsqB97yJXM1dkfmJIi7hYkSrNSem94VpDdm/oePx0nQAd+uG4ISdJ?= =?iso-8859-9?Q?D2CEUs+szUYk5Oz7puhMgQ3bVcW7zDZlzfaNy+770ewmZxB6i9II1fwTWg?= =?iso-8859-9?Q?ydLsN/bOCa8U5j/pMvbuKvoZSU5PZH3ASX0dM1usKAW9x7Sl0rhq91BirX?= =?iso-8859-9?Q?LA7zcZUQvUyzClIVau6+H1oTxGLQgrtx0Tn62y2EuWZuGn+qULFylzzmnV?= =?iso-8859-9?Q?SVsIEMGx0sUn2v/Cbp7pmAphDOr9Y5q4DZmf+//hQ6O4PaEuQit6NGup1p?= =?iso-8859-9?Q?F/9H2l7ruoeZprZJYmjoSCo/qCg7cD1IOfQHGshzkD1tIsMZR+S2ND/WSL?= =?iso-8859-9?Q?x0yqsHln5HPD6ydQ3131QoHGfd68z55p1dDvUTmInqMxbvs0qUV3RMvSk6?= =?iso-8859-9?Q?Kz/JqlZRNGinNWcMV5HjETeCMAzSJIfwTJtDkLOCK94weNyJGHkQRohdcE?= =?iso-8859-9?Q?Eujw3oAKVbkqB6wA0Ns=3D?= Content-Type: multipart/alternative; boundary="_000_AM9P189MB155428CC0218E33AADF29B8CB96D9AM9P189MB1554EURP_" MIME-Version: 1.0 X-OriginatorOrg: ulakhaberlesme.com.tr X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-AuthSource: AM9P189MB1554.EURP189.PROD.OUTLOOK.COM X-MS-Exchange-CrossTenant-Network-Message-Id: 94aaeeb9-79a8-4569-cf14-08db4c9f8b85 X-MS-Exchange-CrossTenant-originalarrivaltime: 04 May 2023 13:00:32.6876 (UTC) X-MS-Exchange-CrossTenant-fromentityheader: Hosted X-MS-Exchange-CrossTenant-id: 39e36fd9-0f21-4c96-ae71-dbd87cae7b33 X-MS-Exchange-CrossTenant-mailboxtype: HOSTED X-MS-Exchange-CrossTenant-userprincipalname: Jn1JQ2bKi83hN1zShmLHLudhQsi+DSlUOTOQzGGFAdx1C++mOXprf9z+c4llpPrLs3PTH3+4hvnnoFhy87V8V3BVmdNzBKOExi6UeW0KueVd8Q90kRhfwy5rkWS84Djs X-MS-Exchange-Transport-CrossTenantHeadersStamped: AS4P189MB2254 X-Mailman-Approved-At: Thu, 04 May 2023 15:36:21 +0200 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 --_000_AM9P189MB155428CC0218E33AADF29B8CB96D9AM9P189MB1554EURP_ Content-Type: text/plain; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable Hello all, I got issue, may be there is a missing solution in rte_kni.c or other parts= . There is not any function to free kni allocated bufs and rte_pktmbuf_free i= s not enough to handle it. (kni_free_mbufs is not reachable.) In default-testing kni application works as below 1. Call rte_kni_rx_burst function to get messages 2. Then push to other KNI interface via rte_kni_tx_burst. There is no me= mory-leak because kni_free_mbufs is called and freed unused allocations. On the other hand, in my scenario 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 pa= cket is received from Kernel 2. Then try to free all messages via rte_pktmbuf_free 3. Freed 1 unit and 31 unit is not freed. memory leak Other scenario, 1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1 p= acket is received from Kernel 2. Push to ethernet_device via rte_eth_tx_burst 3. There is not any free operation by rte_eth_tx_burst 4. Try to free via rte_pktmbuf_free 5. 1 unit is freed 31 unit is left in memory. Still memory leak What i am missing ? I think same issue happens in version 17.11 . unsigned rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbuf **mbufs, unsigned int= num) { num =3D RTE_MIN(kni_fifo_free_count(kni->rx_q), num); void *phy_mbufs[num]; unsigned int ret; unsigned int i; for (i =3D 0; i < num; i++) phy_mbufs[i] =3D va2pa_all(mbufs[i]); ret =3D kni_fifo_put(kni->rx_q, phy_mbufs, num); /* Get mbufs from free_q and then free them */ kni_free_mbufs(kni); <-------- Here is freeing unused alloca= tions. return ret; } 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 */ if (ret) kni_allocate_mbufs(kni); return ret; } static void kni_free_mbufs(struct rte_kni *kni) { int i, ret; struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM]; ret =3D kni_fifo_get(kni->free_q, (void **)pkts, MAX_MBUF_BUR= ST_NUM); <<<--- to free all allocated memory needs to use this function. = (kni->free_q) if (likely(ret > 0)) { for (i =3D 0; i < ret; i++) rte_pktmbuf_free(pkts[i]); } } Best Regards. ___ Yasin CANER Lider M=FChendis Ulak Haberle=FEme A.=DE. Ankara 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 Hello all, I think there is a memory leak for KNI. Firstly, try to active trace mod=FCle to follow memory management but could= not. =DDt doesn't create file and dont have any clue. 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=3Dkni --trace-dir= =3D/tmp/ Secondly, I used followed functions. ``code used_mpool =3D rte_mempool_in_use_count(rdpdk_cfg->mbuf_pool); count_mpool =3D rte_mempool_avail_count(rdpdk_cfg->mbuf_pool); `` 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! How to fix or understand this issue. Follow logs, 1. (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 2. (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:468][avai= l_mpool:9931] 3. (59383) 6:55:10 pkni():2536> [KNI] i:0/1 4. (59383) 6:55:10 pkni():2616> [KNI][EGR] P:[IPv6] P:[0] [fe80::f= 816:3eff:fe93:f5fd]->[ff02::2] --> Packet is a broadcast packet IPv6 5. (59383) 6:55:10 pkni():2620> [KNI][EGR][pkt-len:70] 6. (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:467][avai= l_mpool:9932] --> mbuf is freed to understand mem-leak. =DDt is same happen= s after calling rte_eth_tx_burst 7. (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 9= 932 to 9900 then same process happens and 31 units is not freed. 8. (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:499][avai= l_mpool:9900] 9. (59383) 6:55:10 pkni():2536> [KNI] i:0/1 10. (59383) 6:55:10 pkni():2616> [KNI][EGR] P:[IPv6] P:[1] [fe80:= :f816:3eff:fed2:9101]->[ff02::2] 11. (59383) 6:55:10 pkni():2620> [KNI][EGR][pkt-len:70] 12. (59383) 6:55:10 print_mempool_tx():2511> [UseCount_mpool:498][avai= l_mpool:9901] 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 Ubuntu 20.04 DPDK dpdk-stable-22.11.1 =DDgb_uio is used. Best regards. ___ Yasin CANER Lider M=FChendis Ulak Haberle=FEme A.=DE. Ankara Bu elektronik posta ve onunla iletilen b=FCt=FCn dosyalar sadece g=F6nderic= isi taraf=FDndan almas=FD ama=E7lanan yetkili, ger=E7ek ya da t=FCzel ki=FE= inin kullan=FDm=FD i=E7indir. E=F0er s=F6z konusu yetkili al=FDc=FD de=F0il= seniz, bu elektronik postan=FDn i=E7eri=F0ini a=E7=FDklaman=FDz, kopyalaman= =FDz, y=F6nlendirmeniz ve kullanman=FDz kesinlikle yasakt=FDr ve bu elektro= nik postay=FD derhal silmeniz gerekmektedir. =DEirketimiz bu mesaj=FDn i=E7= erdi=F0i bilgilerin do=F0rulu=F0u veya eksiksiz oldu=F0u konusunda herhangi= bir garanti vermemektedir. Bu nedenle, bu bilgilerin ne =FEekilde olursa o= lsun i=E7eri=F0inden, iletilmesinden, al=FDnmas=FDndan ve saklanmas=FDndan = sorumlu de=F0ildir. Bu mesajdaki g=F6r=FC=FEler yaln=FDzca g=F6nderen ki=FE= iye aittir ve =DEirketimizin g=F6r=FC=FElerini yans=FDtmayabilir. Taraf=FDn= =FDz ile payla=FE=FDlan ki=FEisel verilerin, 6698 say=FDl=FD Ki=FEisel Veri= lerin Korunmas=FD Kanununa uygun olarak i=FElenmesi gere=F0ini bilginize su= nar=FDz. ________________________________ 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 discl= osing, 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 th= is 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 wo= uld like to inform you that any personal data shared with you should be pro= cessed in accordance with the Law on Protection of Personal Data numbered 6= 698. --_000_AM9P189MB155428CC0218E33AADF29B8CB96D9AM9P189MB1554EURP_ Content-Type: text/html; charset="iso-8859-9" Content-Transfer-Encoding: quoted-printable

Hello all,

 

I got issue, may be there is a missing solution in r= te_kni.c or other parts.

 

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 re= achable.)

 

In default-testing kni application works as below

 

  1. Call rte_kni_rx_burst function to get messages
  2. T= hen push to other KNI interface via rte_kni_tx_burst. There is no memory-le= ak because  kni_free_mbufs is called and freed unused allocations.

 

On the other hand, in my scenario

 

  1. Call rte_kni_rx_burst func to get messages, burst_size is 32 but 1= packet is received from Kernel
  2. Then try to free al= l messages via rte_pktmbuf_free
  3. Freed 1 unit and 31= unit is not freed. memory leak

 

Other scenario,

 

  1. Call rte_kni_rx_burst func to  get messages, burst_size is 32= but 1 packet is received from Kernel
  2. Push to ether= net_device via rte_eth_tx_burst
  3. There is not any free operation by rte_eth_tx_burs= t
  4. Try to free via rte_pktmbuf_free
    5. <= li class=3D"MsoListParagraph" style=3D"margin-left:-8.0pt;mso-list:l4 level= 1 lfo6">1 unit is freed 31 unit is left in memory. Still memory leak

 

 

What i am missing ? I think same issue happens in ve= rsion 17.11 .

 

unsigned

rte_kni_tx_burst(struct rte_kni *kni, struct rte_mbu= f **mbufs, unsigned int num)

{

        &nbs= p;     num =3D RTE_MIN(kni_fifo_free_count(kni->rx_q= ), num);

        &nbs= p;     void *phy_mbufs[num];

        &nbs= p;     unsigned int ret;

        &nbs= p;     unsigned int i;

 

        &nbs= p;     for (i =3D 0; i < num; i++)

        &nbs= p;            &= nbsp;      phy_mbufs[i] =3D va2pa_all(mbufs[i]);

 

        &nbs= p;     ret =3D kni_fifo_put(kni->rx_q, phy_mbufs, nu= m);

 

        &nbs= p;     /* Get mbufs from free_q and then free them */

        &nbs= p;     kni_free_mbufs(kni);  =DF------ Here is freeing unused allocations.

 

        &nbs= p;     return ret;

}

unsigned

rte_kni_rx_burst(struct rte_kni *kni, struct rte_mbu= f **mbufs, unsigned int num)

{

        &nbs= p;     unsigned int ret =3D kni_fifo_get(kni->tx_q, = (void **)mbufs, num);

 

        &nbs= p;     /* If buffers removed, allocate mbufs and then p= ut them into alloc_q */

        &nbs= p;     if (ret)

        &nbs= p;            &= nbsp;      kni_allocate_mbufs(kni);

 

        &nbs= p;     return ret;

}

 

static void

kni_free_mbufs(struct rte_kni *kni)

{

        &nbs= p;     int i, ret;

        &nbs= p;     struct rte_mbuf *pkts[MAX_MBUF_BURST_NUM];<= /o:p>

 

        &nbs= p;     ret =3D kni_fifo_get(kni->free_q, (void **)pk= ts, MAX_MBUF_BURST_NUM);   <<=DF- to free all allocated memory needs to use this function= . (kni->free_q)

        &nbs= p;     if (likely(ret > 0)) {

        &nbs= p;            &= nbsp;      for (i =3D 0; i < ret; i++)

        &nbs= p;            &= nbsp;           &nbs= p;        rte_pktmbuf_free(pkts[i]);

        &nbs= p;     }

}

 

 

Best Regards.

 

___

Yasin CANER

Lider M=FChendis

Ulak Haberle=FEme A.=DE. Ankara

 

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>

 

Hello all,

 

I think there is a memory leak for KNI. <= /p>

 

Firstly, try to active trace mod=FCle to follow memo= ry management but could not. =DDt doesn’t create file and dont have a= ny clue.

 

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 lib= rte_mempool_stack.so -d librte_mempool_bucket.so -d librte_kni.so --log-lev= el lib.kni:debug --log-level lib.eal:debug --log-level lib.ethdev:debug --trace=3Dkni --trace-dir=3D/tmp/<= /p>

 

 

Secondly, I used followed functions.

 

``code

  used_mpool &nb= sp;=3D rte_mempool_in_use_c= ount(rdpdk_cfg->mbuf_pool);

  count_mpool = =3D rte_mempool_avail_count= (rdpdk_cfg->mbuf_pool);

``

 

After calling function rte_kni_rx_burst, 32 unit is = allocated. Then i force to free message_buf (mbuf). It frees 1 unit. 31 uni= ts left in memory!

 

 

How to fix or understand this issue.

Follow logs,

 

 

 

  1. (59383)  6:55:10    lrtc():3212> [KNI]Picked up 1 pa= ckets from port 0 [KNI:F000]   =E0 1 packet is received from = Kernel that is allocate 32 unit
  2. (59383)  6:55:10   print_mempool_tx():2511> [UseCount_mpo= ol:468][avail_mpool:9931]
  3. (59383)  6:55:10    pkni():2536> [KNI] i:0/1
  4. (59383)  6:55:10    pkni():2616> [KNI][EGR]  P:= [IPv6]  P:[0] [fe80::f816:3eff:fe93:f5fd]->[ff02::2] =E0 Packet is a broadcast pack= et IPv6
  5. (59383)  6:55:10    pkni():2620> [KNI][EGR][pkt-len:= 70]
  6. (59383)  6:55:10   print_mempool_tx():2511> [UseCount_mpo= ol:467][avail_mpool:9932] =E0 mbuf is freed to understan= d mem-leak. =DDt is same happens after calling rte_eth_tx_burst<= /li>
  7. (59383)  6:55:10    lrtc():3212> [KNI]Picked up 1 pa= ckets from port 1 [KNI:F000] =E0 1 packet is received from Kernel that is allocate 32 unit 9932 t= o 9900 then same process happens and 31 units is not freed.
    8. =
  8. (59383)  6:55:10   print_mempool_tx():2511> [UseCount_mpo= ol:499][avail_mpool:9900]
  9. (59383)  6:55:10    pkni():2536> [KNI] i:0/1
  10. (59383)  6:55:10    pkni():2616> [KNI][EGR]  P:= [IPv6]    P:[1] [fe80::f816:3eff:fed2:9101]->[ff02::2]
  11. (59383)  6:55:10    pkni():2620> [KNI][EGR][pkt-len:= 70]
  12. (59383)  6:55:10   print_mempool_tx():2511> [UseCount_mpo= ol:498][avail_mpool:9901]

 

 

Kernel : 5.4.0-146-generic #163-Ubuntu SMP Fri Mar 1= 7 18:26:02 UTC 2023 x86_64 x86_64 x86_64 GNU/Linux

Ubuntu 20.04

DPDK dpdk-stable-22.11.1

=DDgb_uio is used.

 

Best regards.

___

Yasin CANER

Lider M=FChendis

Ulak Haberle=FEme A.=DE. Ankara

 

Bu elektronik posta ve onunla iletilen b=FCt=FCn dosyalar sadece g=F6nde= ricisi taraf=FDndan almas=FD ama=E7lanan yetkili, ger=E7ek ya da t=FCzel ki= =FEinin kullan=FDm=FD i=E7indir. E=F0er s=F6z konusu yetkili al=FDc=FD de= =F0ilseniz, bu elektronik postan=FDn i=E7eri=F0ini a=E7=FDklaman=FDz, kopya= laman=FDz, y=F6nlendirmeniz ve kullanman=FDz kesinlikle yasakt=FDr ve bu elektronik p= ostay=FD derhal silmeniz gerekmektedir. =DEirketimiz bu mesaj=FDn i=E7erdi= =F0i bilgilerin do=F0rulu=F0u veya eksiksiz oldu=F0u konusunda herhangi bir= garanti vermemektedir. Bu nedenle, bu bilgilerin ne =FEekilde olursa olsun i=E7eri=F0inden, iletilmesinden, al=FDnmas=FDndan ve saklanma= s=FDndan sorumlu de=F0ildir. Bu mesajdaki g=F6r=FC=FEler yaln=FDzca g=F6nde= ren ki=FEiye aittir ve =DEirketimizin g=F6r=FC=FElerini yans=FDtmayabilir. = Taraf=FDn=FDz ile payla=FE=FDlan ki=FEisel verilerin, 6698 say=FDl=FD Ki=FE= isel Verilerin Korunmas=FD Kanununa uygun olarak i=FElenmesi gere=F0ini bilginize sunar= =FDz.

This e-mail and all files sent with it are intended for authorized natur= al 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 di= sclosing, 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 c= ontent, 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.

--_000_AM9P189MB155428CC0218E33AADF29B8CB96D9AM9P189MB1554EURP_--