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 09643A034E; Thu, 20 Jan 2022 15:58:05 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 8E596426FF; Thu, 20 Jan 2022 15:58:05 +0100 (CET) Received: from new1-smtp.messagingengine.com (new1-smtp.messagingengine.com [66.111.4.221]) by mails.dpdk.org (Postfix) with ESMTP id 39B5340042 for ; Thu, 20 Jan 2022 15:58:04 +0100 (CET) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailnew.nyi.internal (Postfix) with ESMTP id 9342E5803C7; Thu, 20 Jan 2022 09:58:03 -0500 (EST) Received: from mailfrontend1 ([10.202.2.162]) by compute2.internal (MEProxy); Thu, 20 Jan 2022 09:58:03 -0500 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:date:date:from:from :in-reply-to:in-reply-to:message-id:mime-version:references :reply-to:sender:subject:subject:to:to; s=fm3; bh=HZdj7/Rby98qMD LvsDMyw8lLOGVFRITzD6Bl9yvgr74=; b=Ylr/WF67CCbOiEkClR9gviTGWkA29a 5sILix9lkXZU8Lt5u+dKvbugw7MkVt3LHZwQ/cQxrqehUJyd2wXHYxFYJStAJDob T6cDj19NM70KaOHODJEIduckuZRx1+xjaRylM9EckcpM+RZU3bXjEeuFWeBF2aA0 lGEvuIczcR7ZVGpNznPxC11kqHaMkNPprRiyeKna2xpGx4jb8b3p5oG0lid9GD6Y WMDfGY2f2JKutkZqxhOgoMIeE8h51js6/nOqtK3R25IUWrpVJp6rvnFaGNKPIINu xIJVui2Rm1sOMxVmCN9xJi9MEsI+ML6qXE91FyHJABjoya+30rfULSkg== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:date:date:from:from:in-reply-to:in-reply-to :message-id:mime-version:references:reply-to:sender:subject :subject:to:to:x-me-proxy:x-me-proxy:x-me-sender:x-me-sender :x-sasl-enc; s=fm1; bh=HZdj7/Rby98qMDLvsDMyw8lLOGVFRITzD6Bl9yvgr 74=; b=kaUpG1fOi2ivtgRgut7VQ4+sSOJEi0L1pkjctZ11HNPUgtnDqHOIuxiTx FdOAnYPxV/mmcfLiutzXrgSAu2A4LumkHfzhQYt5Q35AAz9zr/ObeWvW6VwMkv1L zB/DmqwVQeQe2fJdTdSeAHOyXjnLwQ7UfCZmV8kSGP4sNC2b5E0mncKGt7oFzd1v uyzuNv42K+PFpn9OkN2gWli3bLkZg1AgEn/xKNrMOGXLhXJDpgBXPlcC21AWrYuP bNrxwG4cvdXuLbzIN/2uVrMuTQVXzLwbTa1yfKno4dgxGTnkcKsMpvTqkczBGv23 fIkypazRuG7zDpuMB5Znnu0F/feXw== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeikecutefuodetggdotefrodftvf curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu, 20 Jan 2022 09:58:01 -0500 (EST) From: Thomas Monjalon To: Rohit Raj Cc: Bruce Richardson , Ray Kinsella , Dmitry Kozlyuk , Narcisa Ana Maria Vasile , Dmitry Malloy , Pallavi Kadam , "dev@dpdk.org" , Nipun Gupta , Sachin Saxena , Hemant Agrawal , "ferruh.yigit@intel.com" , "david.marchand@redhat.com" Subject: Re: [EXT] Re: [PATCH v5 1/2] eal: add API for bus close Date: Thu, 20 Jan 2022 15:58:00 +0100 Message-ID: <16764163.5WZRyvrzyv@thomas> In-Reply-To: References: <20201008153048.19369-1-rohit.raj@nxp.com> <8133639.5OynTdThKG@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 20/01/2022 15:51, Rohit Raj: > Hi Thomas, > > This "rte_bus_close" API is introduced to do the opposite of what "rte_bus_probe" does. Just like there are plug and unplug APIs for plugging and unplugging a single device. > > The API you mentioned, "rte_dev_remove" supports only rte_device. But we also need to close/remove private devices of dpaa and fslmc buses which are not exposed directly to user (eg: mempool device). > Note that these private devices/bus objects are not associated with a particular rte_device but they are available as a resource to be used by any of the device based on these hardware specific buses. > So, to close these devices, we need a new API which can do this for us. That is why "rte_bus_close" is required. You mean some resources are associated to a bus but not to a device? It lools very weird. A resource on a bus *is* a device. PS: please avoid top-post > From: Thomas Monjalon > > 10/01/2022 06:26, rohit.raj@nxp.com: > > > From: Rohit Raj > > > > > > As per the current code we have API for bus probe, but the bus close > > > API is missing. This breaks the multi process scenarios as objects are > > > not cleaned while terminating the secondary processes. > > > > > > This patch adds a new API rte_bus_close() for cleanup of bus objects > > > which were acquired during probe. > > > > I don't understand how closing all devices of a bus will help better than just > > closing all devices. > > > > As Ferruh already suggested in the past, we could force closing all devices in > > rte_eal_cleanup(). > > And we already have the function rte_dev_remove().