From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <dev-bounces@dpdk.org>
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 <dev@dpdk.org>; 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: <xms:e3jpYVLlmQrZW4gq2RfhNg9YglKDWFCc2wnsWOpUWaYStRTBvdjN4Q>
 <xme:e3jpYRJsHJMmd8IEIOqhopOrSSU7ZuWsGhupg8vO5f5b8AloXfj81ySrGKILEkEPs
 EmAhmhjCj8k4vPUSg>
X-ME-Received: <xmr:e3jpYduHKmCj1BRHNLJPdu-CV9TAOzDoGvApQd-A4lfidc3tZfUNX_P-6xuLMLpp610IAzI_IlKL6xWUL6Tr5aHPeQ>
X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvvddrudekgdeikecutefuodetggdotefrodftvf
 curfhrohhfihhlvgemucfhrghsthforghilhdpqfgfvfdpuffrtefokffrpgfnqfghnecu
 uegrihhlohhuthemuceftddtnecusecvtfgvtghiphhivghnthhsucdlqddutddtmdenuc
 fjughrpefhvffufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhmrghs
 ucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenucggtf
 frrghtthgvrhhnpedugefgvdefudfftdefgeelgffhueekgfffhfeujedtteeutdejueei
 iedvffegheenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfhhroh
 hmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght
X-ME-Proxy: <xmx:e3jpYWYG8pSSiqFcPaCwZyt7kfnrAYOQvb3imoe-Ibiga3lKA0Nbkg>
 <xmx:e3jpYcYhGHM9y9ZqCF4QcfWjeuY6jTIdzm0ACnB-ZP4-O65p_nhgwQ>
 <xmx:e3jpYaDhDAdkwmCMQiEzy4Evqh_YgPBR1eyHhcVwnIwz1_kOmhtBZQ>
 <xmx:e3jpYWCcHl8fTN5OhBfXku5fwEDuO1xsrIXOmBIKJ0KubaFJ-P6_7w>
Received: by mail.messagingengine.com (Postfix) with ESMTPA; Thu,
 20 Jan 2022 09:58:01 -0500 (EST)
From: Thomas Monjalon <thomas@monjalon.net>
To: Rohit Raj <rohit.raj@nxp.com>
Cc: Bruce Richardson <bruce.richardson@intel.com>, Ray Kinsella <mdr@ashroe.eu>,
 Dmitry Kozlyuk <dmitry.kozliuk@gmail.com>,
 Narcisa Ana Maria Vasile <navasile@linux.microsoft.com>,
 Dmitry Malloy <dmitrym@microsoft.com>, Pallavi Kadam <pallavi.kadam@intel.com>,
 "dev@dpdk.org" <dev@dpdk.org>, Nipun Gupta <nipun.gupta@nxp.com>,
 Sachin Saxena <sachin.saxena@nxp.com>, Hemant Agrawal <hemant.agrawal@nxp.com>,
 "ferruh.yigit@intel.com" <ferruh.yigit@intel.com>,
 "david.marchand@redhat.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: <VE1PR04MB650957475119A366DDF8FC70EC5A9@VE1PR04MB6509.eurprd04.prod.outlook.com>
References: <20201008153048.19369-1-rohit.raj@nxp.com>
 <8133639.5OynTdThKG@thomas>
 <VE1PR04MB650957475119A366DDF8FC70EC5A9@VE1PR04MB6509.eurprd04.prod.outlook.com>
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 <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=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 <thomas@monjalon.net>
> > 10/01/2022 06:26, rohit.raj@nxp.com:
> > > From: Rohit Raj <rohit.raj@nxp.com>
> > >
> > > 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().