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 A67A9A0C55; Wed, 13 Oct 2021 20:52:22 +0200 (CEST) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7C23F41173; Wed, 13 Oct 2021 20:52:22 +0200 (CEST) Received: from out3-smtp.messagingengine.com (out3-smtp.messagingengine.com [66.111.4.27]) by mails.dpdk.org (Postfix) with ESMTP id 2F0AF4111B for ; Wed, 13 Oct 2021 20:52:21 +0200 (CEST) Received: from compute4.internal (compute4.nyi.internal [10.202.2.44]) by mailout.nyi.internal (Postfix) with ESMTP id 9660C5C01FE; Wed, 13 Oct 2021 14:52:20 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute4.internal (MEProxy); Wed, 13 Oct 2021 14:52:20 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= from:to:cc:subject:date:message-id:in-reply-to:references :mime-version:content-transfer-encoding:content-type; s=fm2; bh= wElIezA2cAJobJdgfUl2L7oKVszH08INbPgWJjClB7M=; b=Y4/Ht4VFAwV/WWMs c5cDW0nHIXz3n+2ONmFdaOgXp21ASKuphlcfLWaO0T6mV0Lk1X9t84nCmEU0fXqe 8yTpPJORx0cTSlhBlDqr6vZTFmeFAmVCd4u/eIdjzIjwy2t2yBmqI/wMbafrQ8IU OFoX5Vm+jZLwP2a477wwvHP4+61qytVFWhZvMXWYIjW1UjSQxg65onvH3bI7V0Bk V2vNHHe48mkaXZJ67SO1uPQ3Ilm86aWeEGJsWfW742bYRm80DfyLsuTP7zA2f1yi 4U045BMws/4RSoILSPsJojdrvB/81njXKhqV48v6oeTjNZ1RtdzOSkmnXRF9fKOu mYl0ig== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=wElIezA2cAJobJdgfUl2L7oKVszH08INbPgWJjClB 7M=; b=H/v5IckS5KOttCe4Xor/pkIPIU90a7Q074CgNCtLvFia2dLRK+LtYZJA3 YOylrXMoVAQhaY8pOnbgOfFgdgUu9wtmf3iEGN+2R9HCYPyPLXqTBcLuY2PXCJEn 8Ltw9T3KZTBzWGi3SFtda2nuXGpALAVV2HR3BaOlAciAuVBtcgbAqoYCggH09+Mx B1jg5DACcYNoFvV2Ucj63ThOUuSOlMsR248pU92b6c0qfdG1Q2GrdS2NaG2ZDF/L Lu3ESutcuBsBaZziKQJDhwV3mCcYJ8uodd15eNqYCHpy1UzyXekM36Z/k0kuzBr0 O91HunPcQKAV64ctIrUj9hEPpVTfg== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvtddrvddutddguddvjecutefuodetggdotefrod ftvfcurfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfgh necuuegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmd enucfjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdej ueeiiedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Wed, 13 Oct 2021 14:52:18 -0400 (EDT) From: Thomas Monjalon To: Harman Kalra Cc: Raslan Darawsheh , "dev@dpdk.org" , Ray Kinsella , Dmitry Kozlyuk , David Marchand , "viacheslavo@nvidia.com" , "matan@nvidia.com" Date: Wed, 13 Oct 2021 20:52:15 +0200 Message-ID: <24392547.dnzkRMgc80@thomas> In-Reply-To: References: <20210826145726.102081-1-hkalra@marvell.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [EXT] Re: [PATCH v1 2/7] eal/interrupts: implement get set APIs 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 Sender: "dev" 13/10/2021 19:57, Harman Kalra: > From: dev On Behalf Of Harman Kalra > > From: Thomas Monjalon > > > 04/10/2021 11:57, David Marchand: > > > > On Mon, Oct 4, 2021 at 10:51 AM Harman Kalra > > > wrote: > > > > > > > +struct rte_intr_handle *rte_intr_handle_instance_alloc(int size, > > > > > > > + bool > > > > > > > +from_hugepage) { > > > > > > > + struct rte_intr_handle *intr_handle; > > > > > > > + int i; > > > > > > > + > > > > > > > + if (from_hugepage) > > > > > > > + intr_handle = rte_zmalloc(NULL, > > > > > > > + size * sizeof(struct rte_intr_handle), > > > > > > > + 0); > > > > > > > + else > > > > > > > + intr_handle = calloc(1, size * sizeof(struct > > > > > > > + rte_intr_handle)); > > > > > > > > > > > > We can call DPDK allocator in all cases. > > > > > > That would avoid headaches on why multiprocess does not work in > > > > > > some rarely tested cases. > > > > > > Wdyt? > > > > > > > > > > > > Plus "from_hugepage" is misleading, you could be in --no-huge > > > > > > mode, rte_zmalloc still works. > > > > > > > > > > In mellanox 5 driver interrupt handle instance is freed in > > > > > destructor " mlx5_pmd_interrupt_handler_uninstall()" while DPDK > > > > > memory allocators are already cleaned up in "rte_eal_cleanup". > > > > > Hence I allocated interrupt instances for such cases from normal heap. > > > > > There could be other such cases so I think its ok to keep this support. > > > > > > > > This is surprising. > > > > Why would the mlx5 driver wait to release in a destructor? > > > > It should be done once no interrupt handler is necessary (like when > > > > stopping all ports), and that would be before rte_eal_cleanup(). > > > > > > I agree with David. > > > I prefer a simpler API which always use rte_malloc, and make sure > > > interrupts are always handled between rte_eal_init and rte_eal_cleanup. > > > The mlx5 PMD could be reworked to match this requirement. > > > In any case we should not any memory management in > > > constructors/destructors. For info, Dmitry is going to send a fix for mlx5. > > Hi Thomas, David > > > > There are couple of more dependencies on glibc heap APIs: > > 1. "rte_eal_alarm_init()" allocates an interrupt instance which is used for > > timerfd, is called before "rte_eal_memory_init()" which does the memseg > > init. > > Not sure what all challenges we may face in moving alarm_init after > > memory_init as it might break some subsystem inits. > > Other option could be to allocate interrupt instance for timerfd on first > > alarm_setup call. Indeed it is an issue. [...] > > There are many other drivers which statically declares the interrupt handles > > inside their respective private structures and memory for those structure > > was allocated from heap. For such drivers I allocated interrupt instances also > > using glibc heap APIs. Could you use rte_malloc in these drivers?