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 17D11A0540; Tue, 13 Dec 2022 10:35:19 +0100 (CET) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AC3234021D; Tue, 13 Dec 2022 10:35:18 +0100 (CET) Received: from NAM04-MW2-obe.outbound.protection.outlook.com (mail-mw2nam04on2085.outbound.protection.outlook.com [40.107.101.85]) by mails.dpdk.org (Postfix) with ESMTP id 6E44D40146; Tue, 13 Dec 2022 10:35:16 +0100 (CET) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=fgy+8LbEH56vrfApPw/29BO4k2LYl+RkqRcAseh39LSEBMi16yLohO+brjyFkkMx6JAHfNsli/FA3CTVbaHtAL/3z64dLclRrgl4Qs2Oh/v4h7qY8Cess/1kdMN1MmW+UiKHleWxZJo9P+HsaLkaXBX2aYnv17bfB8THBnLN+b1RJxEnpXovStC8y4iqNA5tTSs0kK/bA+kRRHl1c4MDAeZbbx2K8U9VZo4GDv8hI1QYPrmDhbhFdG80/yhEnt2WizHdYnwHSJDpcFZWBRjeSyE2sRobf1an2mkYXguI5G7cspgELDThWKuXQe/NcCjPURjNSoly2HKRLfuwvzunCA== 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=q6Y8jwjBNfkqLx8sq/d0VQcjQZhnogdJEveFWJLeObQ=; b=XeH1VeFzf/bogik9KJF3MeV64hpBnfpF2sTzzihelal3RBqfJciJEH1VwMM6nO/Zq/zH0LvMjxlFLOopSD7DrJtuXqgRsxi1zNhtknQp5dB4sQylQ7FiS4P6td/ncdfGgxl+xFpGmvIRrgZ/Y3jffb1TDvN4H9KwDHCXi4oO7LLFp0pvjHoRVqhjFtGr9uKxeDB+zU7WLr+G4FlfDhyAH9X6Meac01PFQ5OZPky9+jbX5fVJYNpxNsWPxeZUIw4bGHZBp1haPbPz8LfnsgNcX+76LI11gIuYFpuWqxcU0R88jzDXfYhdNY3bbwl5gCyE4klv0q/WPZ52IBS5472aGA== 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=q6Y8jwjBNfkqLx8sq/d0VQcjQZhnogdJEveFWJLeObQ=; b=M1DuIsdw6f75gcdUoNhTy8N+1pH9J++KZdx/I05bN6gqPtzeV8sKSLkxp9RYxww6WrvRF+ksttsLCBxEchOYA9P7th0McAOcWtbAJ8WfDOj7/Is08/K2Gp9j9rdzKAdK5lr/bT1ekZVkIMrZB3+6s9Pa7635Bwk4kdInNxlEMl4= 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 SA1PR12MB7246.namprd12.prod.outlook.com (2603:10b6:806:2bc::22) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.5880.19; Tue, 13 Dec 2022 09:35:13 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::b482:d5bd:c7d0:3842%8]) with mapi id 15.20.5880.019; Tue, 13 Dec 2022 09:35:13 +0000 Message-ID: Date: Tue, 13 Dec 2022 09:35:05 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.5.1 Content-Language: en-US To: "You, KaisenX" , "dev@dpdk.org" , "Burakov, Anatoly" , David Marchand Cc: "stable@dpdk.org" , "Yang, Qiming" , "Zhou, YidingX" , "Wu, Jingjing" , "Xing, Beilei" , "Zhang, Qi Z" , Luca Boccassi , "Mcnamara, John" , Kevin Traynor References: <20221117065726.277672-1-kaisenx.you@intel.com> From: Ferruh Yigit Subject: Re: [PATCH] net/iavf:fix slow memory allocation In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P265CA0083.GBRP265.PROD.OUTLOOK.COM (2603:10a6:600:2bd::20) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|SA1PR12MB7246:EE_ X-MS-Office365-Filtering-Correlation-Id: e43bb2bf-168e-4552-8db3-08dadced555d X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: R/lX5Z9oczTydqZOhiJZi1R+07GJE1ZVpkiEOcA5xmPhWPJhl/Mptb1uS1CaJzWRjBujev/hVoawsMiGUMWeLIY3ihWtlFHRHw/sulRjXZqGuOAMER+zaJnmi1POsGpe0O3lqJVmxKdZpxl7c+RbELuI0b5tmhfTjJ9o8IBLT3ePRSf0qwLgnbgzw0oYeqY9dYOUxSCw0e9Z0fAXYzD/ssx3zY2xZ/vdSkhTqwDANbPYP2R5bJcl1EliUcp+zPK6mKAxRHImd1k/tuIBfeNMVQIt/LjXq1fqg+oW2xbrUphgHQ+cDnAU8DPqan9Z6jUB/WOagWZxfJuDODSKdPMcw27GilkNVLsjmiCTGmYfbg4p5al5YeWh+MTuwzyKVK3ioy6CJLFY5IdAa7wEzoki8jG1rj9oJVpkVCOYsr8a4rXtUsiWfIws9+GOmc4vM/2w6HqEcT2VE4fTScE1nYnoNy7CbZFSiqPPHBVYKzGClYXoA/3Agi2uiV7sRJVgz9p5Y77U/v/AY6C/qYo5LwJyomyTdNLi7uWYf9YGAIBIu4s/vsHiRCgH2loo2LgyoPyqpNH6aRCq+rFBGjyP8R+mTRxdriQhTk5YOVM6wbhFC3UI2KIEMen/lRMEf1xv+eJCFpc1lcS2Fvsvi8WzRg41UFPiu+fLswTmsazvmd8tR3+A+aAKLWIo+c4x0i3Y4j/bycwlKuPRBB/Kjd8DDM+KwyXnEATaHvg5n0y7JtdZDqY= 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:(13230022)(4636009)(346002)(136003)(39860400002)(366004)(376002)(396003)(451199015)(2616005)(36756003)(66476007)(2906002)(86362001)(44832011)(83380400001)(31696002)(54906003)(110136005)(6486002)(478600001)(26005)(6666004)(53546011)(6512007)(6506007)(186003)(38100700002)(4326008)(8936002)(7416002)(41300700001)(8676002)(66556008)(66946007)(5660300002)(316002)(31686004)(45980500001)(43740500002); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?dkFnaFp5akZuSGVUeUYxZWJsWi9mcldvUmxmSjdURUhNcHdwbi9XTGN6bCtl?= =?utf-8?B?T29LZFA1cDJNTUZuWGlqUlhvOWluVVl2cC9tS2lXKzloMDMybVpGL2RSTUR4?= =?utf-8?B?ZjVGZTBCYUJTQjVSWTU2Sm5xWnNmQ1I5elpSSUNpL1ZPT0g3a2RITnd3Rk1Y?= =?utf-8?B?dGREdVJQeVZ5T0hpdFM3RCtBdFUrZEIzb01EVUtEcnJ2Zm5xSzdOSVNiUXYw?= =?utf-8?B?QXNHUXgrWnJlODl1clBGNnAxRi9UNXRJbS9JR016NEFQbjY2cU9ISWhiVjB0?= =?utf-8?B?VURhbjhRUHNjcnNIbWJqMlVEWGpIOVZreVBoWkVHY1RCZWRkYTlTekhWSmw0?= =?utf-8?B?Ly9hOTVMM3dBcmtCczBLVW5zdTV2VVdHNnR0RndTdzMycGF4Z01TeUF0bElZ?= =?utf-8?B?SEQxcGhQS1M4NmhHc0NWeGE3cVMraEllNlZiamRuL25leFFYVExMa09CMTZ1?= =?utf-8?B?b0VCT0hkcEJuakVtMFpmQUlBSzZXbGtYUk9TTWpOZVRuUS9BVDZabm9iOGZN?= =?utf-8?B?UUpjcXo2OXROL25PWFpVaTlwYjNWcVRVNHVVY0dNZkFob1ZudC91eS8zU1hN?= =?utf-8?B?ejN4SmFKSERwWlVzRFVyeVlXS2t4cmFHV3l5OFFsTU5zZkdiUWx1N1o4MGhM?= =?utf-8?B?SVZEVHZSK2lqdEN2Mkl4VjhMaWZaM0dES1kxTlZCbDMxSS83dk9iVVdqc1FB?= =?utf-8?B?Q3cxL3grbWNOZnJCejZucHNmMDZ0L2NvODNGZ0IyTUt6Q1FrWnZySmlqZ3R3?= =?utf-8?B?YTBHRTRQQmFBNlBxNEt3ZHVZYk10cC83UVRoUi9UdDVSZDlPYXlOcWlPWnBH?= =?utf-8?B?MTAvOXNPMzRDN1hVdlNPTkthT1FnUFNRS0diN3FNV1ppeDcyMmdIRWlyQ3lM?= =?utf-8?B?Q2xraUZhY0cyZ2RuNm12VG5zTm04UmdVdEtoZ3hDRFppTzdwTUJsNXRkemJS?= =?utf-8?B?TkVvYk5YMDRpdkppSUZQbGlPN2RsNFRrRDdNQ3NST2VmdUtPLzhZRy9HTnJM?= =?utf-8?B?V0tjNU5sTGY2SHpySFlldXA5ei9BWVlwRTE3dTJQKzBSNjh2MXNJMU5uSGd0?= =?utf-8?B?YklySTk1bEtadVVSblZFWVlzWjFyT1cyemd5WEdOdmRBNUxzL0Jxc1daTGZ3?= =?utf-8?B?d2QzS1lkYy9EUlhXd2xiM1ROWWdBWVRNaHNTeFNON0FvYUJyVDZOOXZ5RVFP?= =?utf-8?B?R1J2OGQxb2hEZk9ZblJjYnlPazdoRlZMTEYweXQ2OWtrYWNLdFdoSTI1bkhC?= =?utf-8?B?WUdnSURWWVg2Mk5SREZRdWhhS1dxSDZnWWd2TGZWeUVLMTU1K0JmNWJrN0ds?= =?utf-8?B?T2JYSmVDbWVaQ1lNSjUvaWxJa3dPVmxYRERpbVRUVzBnMmRkN2xYeEhYRzFy?= =?utf-8?B?RHRtKzEyUEFuRzMydGpDMmVJQ0ZoUUFXMThZcDJaYXZobkt5MjZzSmV6bXgy?= =?utf-8?B?VVVkalRNb1F3MVZzRjVqTTVCSnh4S0NxMkNiK2tmUTRrOFZSM3lqL2EzY2dG?= =?utf-8?B?ZDUxbEdUWWZPTzRvS0NBbHdUS2dWVGlOem9icWpsYVcxV3BGanZpQnRqamFq?= =?utf-8?B?TWxRbmh3eHVtQlR5RGRScFZxSmpkR2NVUXdQWit3ajU4VThTcmhKbCt4cTQ0?= =?utf-8?B?RDZGVUlVd0h0SHM1SVI3b1VobnpBcFBGQUJzYkYwQ3pwUnZBV3BGWkVqMHVr?= =?utf-8?B?RnZDM0puRHowTTJmYlE0bjNCdWM1dVpoRFBNVXN1SWhtT2x4SS9LOGxqRXZQ?= =?utf-8?B?TnlINlNrUm1TZnJEM0tmcFJjam92ZWE2eHNIWVAyYURzMVFLY2FzUDZKRjgw?= =?utf-8?B?Z3R4b2NpMEVBclo3dEw5WE52dmNMalFJSDJScTBoaW5KT3BWTTZOenZjbmRS?= =?utf-8?B?QmlwTzBraEtIdk0yMjlFeUV4a29qVzNHQk5XTHVtWk1jM1RXcUluL3lXSEJu?= =?utf-8?B?TTUrU21ScVpxZzJVYjFCVFZKb2VvQmlGZW1rNnJ6djN4UFRwRlNsVy82K3Qz?= =?utf-8?B?UmlsNTBlNVZRc05ZcUVYZkNsOTU5VzRnNDVET0pZZDJxSGJpb3l4S3JHRTM2?= =?utf-8?B?VUVGamRCSWJ1WlljbDJ4RXFWZE9uUUo2RVVWNzNMeDNtK0gzZ0VIbXlYdkdt?= =?utf-8?Q?sntDAnrsrY2jwxsLjaNdVBgHI?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: e43bb2bf-168e-4552-8db3-08dadced555d X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 13 Dec 2022 09:35:13.6266 (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: PHlga7IGAgmjZNoQzepG3WwGAaknFUBvmdrHSQRQOlvXI16aFsSuWmAIIefIse0n X-MS-Exchange-Transport-CrossTenantHeadersStamped: SA1PR12MB7246 X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org On 12/13/2022 7:52 AM, You, KaisenX wrote: > > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: 2022年12月8日 23:04 >> To: You, KaisenX ; dev@dpdk.org; Burakov, >> Anatoly ; David Marchand >> >> Cc: stable@dpdk.org; Yang, Qiming ; Zhou, YidingX >> ; Wu, Jingjing ; Xing, >> Beilei ; Zhang, Qi Z ; Luca >> Boccassi ; Mcnamara, John >> ; Kevin Traynor >> Subject: Re: [PATCH] net/iavf:fix slow memory allocation >> >> On 11/17/2022 6:57 AM, Kaisen You wrote: >>> In some cases, the DPDK does not allocate hugepage heap memory to >> some >>> sockets due to the user setting parameters (e.g. -l 40-79, SOCKET 0 >>> has no memory). >>> When the interrupt thread runs on the corresponding core of this >>> socket, each allocation/release will execute a whole set of heap >>> allocation/release operations,resulting in poor performance. >>> Instead we call malloc() to get memory from the system's heap space to >>> fix this problem. >>> >> >> Hi Kaisen, >> >> Using libc malloc can improve performance for this case, but I would like to >> understand root cause of the problem. >> >> >> As far as I can see, interrupt callbacks are run by interrupt thread ("eal-intr- >> thread"), and interrupt thread created by 'rte_ctrl_thread_create()' API. >> >> 'rte_ctrl_thread_create()' comment mentions that "CPU affinity retrieved at >> the time 'rte_eal_init()' was called," >> >> And 'rte_eal_init()' is run on main lcore, which is the first lcore in the core list >> (unless otherwise defined with --main-lcore). >> >> So, the interrupts should be running on a core that has hugepages allocated >> for it, am I missing something here? >> >> > Thank for your comments. Let me try to explain the root cause here: > eal_intr_thread the CPU in the corresponding slot does not create memory pool. > That results in frequent memory subsequently creating/destructing. > > When testpmd started, the parameter (e.g. -l 40-79) is set. Different OS > has different topology. Some OS like SUSE only creates memory pool for > one CPU slot, while other system creates for two. That is why the problem > occurs when using memories in different OS. It is testpmd application that decides from which socket to allocate memory from, right. This is nothing specific to OS. As far as I remember, testpmd logic is too allocate from socket that its cores are used (provided with -l parameter), and allocate from socket that device is attached to. So, in a dual socket system, if all used cores are in socket 1 and the NIC is in socket 1, no memory is allocated for socket 0. This is to optimize memory consumption. Can you please confirm that the problem you are observing is because interrupt handler is running on a CPU, which doesn't have memory allocated for its socket? In this case what I don't understand is why interrupts is not running on main lcore, which should be first core in the list, for "-l 40-79" sample it should be lcore 40. For your case, is interrupt handler run on core 0? Or any arbitrary core? If so, can you please confirm when you provide core list as "-l 0,40-79" fixes the issue? >> >> >> And what about using 'rte_malloc_socket()' API (instead of rte_malloc), >> which gets 'socket' as parameter, and provide the socket that devices is on as >> parameter to this API? Is it possible to test this? >> >> > As to the reason for not using rte_malloc_socket. I thought rte_malloc_socket() > could solve the problem too. And the appropriate parameter should be the > socket_id that created the memory pool for DPDK initialization. Assuming that> the socket_id of the initially allocated memory = 1, first let the eal_intr_thread > determine if it is on the socket_id, then record this socket_id in the eal_intr_thread > and pass it to the iavf_event_thread. But there seems no way to link this parameter > to the iavf_dev_event_post() function. That is why rte_malloc_socket is not used. > I was thinking socket id of device can be used, but that won't help if the core that interrupt handler runs is in different socket. And I also don't know if there is a way to get socket that interrupt thread is on. @David may help perhaps. So question is why interrupt thread is not running on main lcore. > Let me know if there is anything else unclear. >> >>> Fixes: cb5c1b91f76f ("net/iavf: add thread for event callbacks") >>> Cc: stable@dpdk.org >>> >>> Signed-off-by: Kaisen You >>> --- >>> drivers/net/iavf/iavf_vchnl.c | 8 +++----- >>> 1 file changed, 3 insertions(+), 5 deletions(-) >>> >>> diff --git a/drivers/net/iavf/iavf_vchnl.c >>> b/drivers/net/iavf/iavf_vchnl.c index f92daf97f2..a05791fe48 100644 >>> --- a/drivers/net/iavf/iavf_vchnl.c >>> +++ b/drivers/net/iavf/iavf_vchnl.c >>> @@ -36,7 +36,6 @@ struct iavf_event_element { >>> struct rte_eth_dev *dev; >>> enum rte_eth_event_type event; >>> void *param; >>> - size_t param_alloc_size; >>> uint8_t param_alloc_data[0]; >>> }; >>> >>> @@ -80,7 +79,7 @@ iavf_dev_event_handle(void *param __rte_unused) >>> TAILQ_FOREACH_SAFE(pos, &pending, next, save_next) { >>> TAILQ_REMOVE(&pending, pos, next); >>> rte_eth_dev_callback_process(pos->dev, pos- >>> event, pos->param); >>> - rte_free(pos); >>> + free(pos); >>> } >>> } >>> >>> @@ -94,14 +93,13 @@ iavf_dev_event_post(struct rte_eth_dev *dev, { >>> struct iavf_event_handler *handler = &event_handler; >>> char notify_byte; >>> - struct iavf_event_element *elem = rte_malloc(NULL, sizeof(*elem) >> + param_alloc_size, 0); >>> + struct iavf_event_element *elem = malloc(sizeof(*elem) + >>> +param_alloc_size); >>> if (!elem) >>> return; >>> >>> elem->dev = dev; >>> elem->event = event; >>> elem->param = param; >>> - elem->param_alloc_size = param_alloc_size; >>> if (param && param_alloc_size) { >>> rte_memcpy(elem->param_alloc_data, param, >> param_alloc_size); >>> elem->param = elem->param_alloc_data; @@ -165,7 +163,7 >> @@ >>> iavf_dev_event_handler_fini(void) >>> struct iavf_event_element *pos, *save_next; >>> TAILQ_FOREACH_SAFE(pos, &handler->pending, next, save_next) { >>> TAILQ_REMOVE(&handler->pending, pos, next); >>> - rte_free(pos); >>> + free(pos); >>> } >>> } >>> >