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 F099342B2C for ; Wed, 17 May 2023 19:53:46 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 6D8A340EE1; Wed, 17 May 2023 19:53:46 +0200 (CEST) Received: from NAM11-BN8-obe.outbound.protection.outlook.com (mail-bn8nam11on2040.outbound.protection.outlook.com [40.107.236.40]) by mails.dpdk.org (Postfix) with ESMTP id EF3C2406B7 for ; Wed, 17 May 2023 19:53:44 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=EwZLmrz7Cs4bazyAQRCbpN+ML0WUL3SBc9lysk/8VlbfSpzH6RpUpc8biINRlveghXJhfShNzRo5haF2ToMt3o2n7MaI9P/sbhoBIjF7D4IMrkIYMghRrqUsTc8Ilv3vJCQ132XReiDtQQly+oQqgbMVkkA9jWO2qp49on6lTJqXQCFcubsnOhy+U+CoGMkyDDs7HjZ2K4HzKH2hMolwaI3AdnPzyZBcmCNCcTs+TLv/Ai4jw8LUXivPazBv7MYnR3IVIXcbsBekO5RIn9eIJ6oe3SQAdzPKU76fQBRlKRAbk4cIopU9ce41OlD/tS3oeA2qp01PYXfyQRulP+gDcQ== 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=qhS6QVlTmgqfPEXYSwMvDrNz8BzcQadQlB2AMHxMxf4=; b=Sc6rE0xC7DbHrVG0Irb6d1FYpNeedtTzambHUMrcNgOSfII2wDoiH518HjTcmAssePcFwKBPg6eFqYV19OJTbC9xO+8r69ZSFXXmxtHuwzfbnog57t+aRl6F4CU29vlBh5RhzoI+q7tDNvkpm6YUEiVr9XMTdpMvqGoTHC/KVhc+e1/RJgrCtqjf5pOnu51BeWerjhggfENw6GvKqAtv1j7CHQ37kDepA7lRfiQ7W6KbCd+/sro/6rEGzaKTW8mWbyd2iF6LcaX06pVFsmWxfuckkFYrpVebJvhyI0S+S8QiW6gfDPH6JKSm4ja1LtR9SATG/CFiZq8GtTCfbz+Rpw== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=qhS6QVlTmgqfPEXYSwMvDrNz8BzcQadQlB2AMHxMxf4=; b=GNIGPVDkLodu+MNrmwMJnHrfDjHN+575clXnPAS3ZPH2p6tLalQ3ofDE7MDCqcAxZbxJeJqcjoLNxk5u0ogIFGwsobQZQSXgxRke1EciMul9Sw7EPvzTsnV0farG2pllPvopB3hV+ZfkdDEkJ+fDKUv1p+qoaoEOBAILw7Oq2DM= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by MW6PR12MB8733.namprd12.prod.outlook.com (2603:10b6:303:24c::8) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6411.17; Wed, 17 May 2023 17:53:43 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::7957:641d:6aba:3f9a]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::7957:641d:6aba:3f9a%4]) with mapi id 15.20.6387.033; Wed, 17 May 2023 17:53:42 +0000 Message-ID: Date: Wed, 17 May 2023 18:53:37 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.0 Content-Language: en-US To: Yasin CANER , Stephen Hemminger References: <20230508091845.646caf17@hermes.local> Cc: users@dpdk.org From: Ferruh Yigit Subject: Re: DPDK 22.11 - How to fix memory leak for KNI - How to debug In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO2P123CA0021.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:a6::33) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|MW6PR12MB8733:EE_ X-MS-Office365-Filtering-Correlation-Id: 945792e8-c886-4cbe-6323-08db56ffa72e X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: I7MB8D+AwOgeIxfsn/RqBtl4Lg3L47RD3cVc+rzuuCG0Nur0679qfrdQn8itQO/3HZUw6N7R66S8JmGdUmRwT/tLik0ApczujDNPAdn1zMaV7JHgGylEPnywvlvS/e6ZdCa2gTD3x/mmm7/4WmHCjVd0nzJBE7N21G1FvisfVxzUAgKY6U4K87hiZcZx8udkuq0fFKyAq1CeuaxUW+WlAsptdLfRaz83nMNCRvV0LFTwj4N3kothJrgSYHkKJaDYN/vXaPs0ASsD9qqQhdzzYtZVGQRqaQTKkdC1+EiUPdhskkgfub8n9VJmfm0kPEM+Q/S+UQ92DAX8E+4hW+mRNZsBLBKlcflXvrMflWpVKBr4UFcMUhh4om5ktjR9mxHvcztMf7FF/nA9DFeIHfYasriHwq6q78Wx6IYikHu7ti9+1EQBaANNALd5Lf0nH4wnRbuD+sl5hJxVhlYvt7dg7pppA7kh0tIZRVYL7rPGNmIBR+hUXRXPid2U5ipm+lP1n4/u5Ccqh0vVJhxCgvx1esnA7F0dgXv9J1iG/SjixytxFjuJxBzG+j1LVvqdClqqXpkIj1sLAhCLFFqpr+/yXsn0Pl2S2U7nO8BIwbHLMJUBK9fkk6f6ovReswqnaxFvB7w9IZ5JRYF1qGWPjC8WXYEwsIZt0Q9o81IYhm0TRA0= X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(396003)(376002)(136003)(366004)(39860400002)(346002)(451199021)(83380400001)(26005)(186003)(6506007)(6512007)(53546011)(6666004)(36756003)(6486002)(966005)(2616005)(316002)(4326008)(66556008)(66946007)(66476007)(2906002)(38100700002)(8936002)(8676002)(31696002)(31686004)(86362001)(44832011)(5660300002)(41300700001)(110136005)(478600001)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?ZXVzWnlTTXpZd011Q3VqUXYvT29ab0swNGd4VHBsWlJFS1dYNGpVZTUyZmZh?= =?utf-8?B?Ylk3bmJiQVA0RW9Uc1BtMENlVkJGaHh3ZE45ZWY3QzdadkFobHRlWldEUWlC?= =?utf-8?B?MWw4NHdPdFp6VDhha0xMTS9jcDVVV0R1QXczRU4xQmRERG14enM5YUw2SXE4?= =?utf-8?B?N1c4UEF5by92NnNOU2xBT1lsRkNLdlBzdUNUZHJtbVgxS0JPbE1QOElNdys0?= =?utf-8?B?LzdCRG5KcG44SCsrL0ZUWnVrOWVFcmlhT0pjSGJ0aHkzTTJJdW05alVRSyt3?= =?utf-8?B?aEJyMzlGV1ZmTDRHempVOU8xMHp2eVNydmRmTWRpZTg3QjlJaERmdEphbFd2?= =?utf-8?B?OERGQ0xhNE41cTJaUFJmZU9NNkNtMEIzS2w3QmV0WkswU3V2QzdHK015UExJ?= =?utf-8?B?TlRXM012bXBoM3lKNVpJdXErVXhQMVo5aVpyNWNTR3JOTVBYSnBHWjRTaDJD?= =?utf-8?B?MUJVQlB0V29TMWNra2Z6QW54YmJDVUVFZnduaG1GL09XbldCUTR5VFBhNkEv?= =?utf-8?B?dDVoTTIwdnlGcitRa2RFbWNOQURxcDRsbVJ5Z2FyQXFSY1NRcDBFdEcyYXlE?= =?utf-8?B?VVg0ckQrTnFpMEYrNGE5cGxUVkVoMFNRc0RHN2R2QnBTYlBEMzVVWVZBNldI?= =?utf-8?B?TUZOWDRsT1hsV1EyemREbWNNajhqampyKy9ob21IMHFTY2hLMW9lWHhELzJK?= =?utf-8?B?NDA3ZWdSL0RFMXZoOTVTa2RUTHVpWHh6ejNpWDVkR2kzcnppeGc4azlqamNP?= =?utf-8?B?Q3hoVVRKdG1OTkNPWWUrZ1huUUxZVjZvOHhWMlNGNlo2MGJKN1BJSW9QZ3lh?= =?utf-8?B?QzBORXdVTFAzbHB5RjZLUUtvNzZCeXpXRlN5OE10cDVCSXZMei9EeDZpZHFP?= =?utf-8?B?NktkOWw0NkdCRnlSbjhyTFl0WlFXR2Z5b09BU1dDTFprZ3A2Y3MrbkpvYVQ0?= =?utf-8?B?WlZhVFpudTNjak5mSHU2R3hVbjcwWjhSRXFiRHdYT1NqTEtNUEpJWGlyZ1pq?= =?utf-8?B?N0hVeFh3N1hYN3M3SHRiaVpydVQ2cjJnZkdialg0VDFzdjlQcDd3R0xQNG43?= =?utf-8?B?Y0pOTXVLUXlvR1cySzJPVnVrMWkxZWFqSExLNGdXQ0VoajFJMm9lR3QxRGZP?= =?utf-8?B?UUdWS0V5QmZNSHFhbnpBMEEyTGtIN1NiR3NkcFdyOFBaeGdnNTVVTUphbnVK?= =?utf-8?B?VStNYlNwSWhjWVNOUElhOHl2VUZoMi9zdmFReERuMzJodDQ2Y0tQT1FNUkJM?= =?utf-8?B?SEVqTUxuZ3RIMC8wQ09rTHdsMlFmVlVQT3Jrcy9NTmZkMTN4SWE3ZWt1NVBz?= =?utf-8?B?R0FSMHozeVc1ODhHdytka0l2ZWFESmR3S1hGTEFtZ3FnUHhwUXZZUGVXelcx?= =?utf-8?B?RHhCQVRuSkFsbUlkM2RjakxrdHJLVUZoM3hDYjU1dUh3ZUJOTW5KOXY0dkxz?= =?utf-8?B?c1hFWUFtV1VYankvM0tlVTRuUEVmbEwyeXU2Z3JwMXpDRDh0WXBFczZ6dk8y?= =?utf-8?B?MWt5ZEgwNG5zM0hjTTA2amJBMGxTUStIYU5waG0vTHpZTmlCOUVpNnZhNXlC?= =?utf-8?B?VlRJc011SVpGOHhDYlVHQmg0WWhGUE1xUkZOZU5MNlhVQU1qbmZjSjJRUkZ4?= =?utf-8?B?bUFDK28vTmdMTm1YZ1hBWFVnOEdiN1lySk9VV0tGME1kQVdRa24wOEt3MnNy?= =?utf-8?B?OXhmZDJrMmZjYmpzVEtuNzZOVGVyak54WFk4SVY4OVlyNk4ra1hmK3RvY1lX?= =?utf-8?B?c2JqMDJ6V2xjanZ6Z1g1SjVudFJNRzNFSXlKcEVnZnpjaDFwdktuNTdvNEdw?= =?utf-8?B?YkRjY0MzUk1OZldpcnpKNzZKb3p1VkY0ZzhmWnZaUTZwVGh5TTI4Vmx3bnND?= =?utf-8?B?dCtsaVFDcmdsNWg2aWNlZWlUUGZCNXFSREpPSDdGcmdwcUtYbGFuVjVzN3dt?= =?utf-8?B?OWRGeEM4S0dPcE41eUl3TzUwKy8vbDZGeXBaeTdZbzVaWnRDUmhHVmtiWVJN?= =?utf-8?B?NDB4dlROK2NCdFFWTXpHYlNuVGgwVVFBZE92STJVYjhvRmdjWVBZbXpvR1Yy?= =?utf-8?B?WkFZU3VCV2pvNHQ4TjlUM0VHVlprdU40aGNmdmFwcE8za1N6USs3ZlBuR08z?= =?utf-8?Q?WlSInfRMrwyojaW47vSCTktX8?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 945792e8-c886-4cbe-6323-08db56ffa72e X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 17 May 2023 17:53:42.7349 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: zlPTEoHJ/Tva8FjxlnIYowmdyVsTcl+yKXnTkoEIkymNUkgTxV8go94AWUOaGRDw X-MS-Exchange-Transport-CrossTenantHeadersStamped: MW6PR12MB8733 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 On 5/9/2023 12:13 PM, Yasin CANER wrote: > 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 = 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; > } > Selam Yasin, You can expect 'kni->alloc_q' fifo to be full, this is not a memory leak. As you pointed out, number of mbufs consumed by kernel from 'alloc_q' and number of mbufs added to 'alloc_q' is not equal and this is expected. Target here is to prevent buffer underflow from kernel perspective, so it will always have available mbufs for new packets. That is why new mbufs are added to 'alloc_q' at worst same or sometimes higher rate than it is consumed. You should calculate your mbuf requirement with the assumption that 'kni->alloc_q' will be full of mbufs. 'kni->alloc_q' is freed when kni is removed. Since 'alloc_q' holds physical address of the mbufs, it is a little challenging to free them in the userspace, that is why first kernel tries to move mbufs to 'kni->free_q' fifo, please check 'kni_net_release_fifo_phy()' for it. If all moved to 'free_q' fifo, nothing left to in 'alloc_q', but if not, userspace frees 'alloc_q' in 'rte_kni_release()', with following call: `kni_free_fifo_phy(kni->pktmbuf_pool, kni->alloc_q);` I can see you have submitted fixes for this issue, although as I explained above I don't think a defect exist, I will review them today/tomorrow. Regards, Ferruh > Stephen Hemminger >, 8 May 2023 Pzt, 19:18 tarihinde > şunu yazdı: > > 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 > > > > > > function, > > i realized that there is 2 function to helps to mbufs back to pool. > > > > These are rte_mbuf_raw_free > > > > > >  and rte_pktmbuf_free_seg > > > >. > > I will focus on them. > > > > If there is another suggestion, I will be very pleased. > > > > Best regards. > > > > Yasin CANER > > Ulak >