[EXT] Re: [PATCH v5 1/2] eal: add API for bus close

[Rohit Raj]

> -----Original Message-----
> From: Thomas Monjalon <thomas at monjalon.net>
> Sent: Thursday, January 20, 2022 8:28 PM
> To: Rohit Raj <rohit.raj at nxp.com>
> Cc: Bruce Richardson <bruce.richardson at intel.com>; Ray Kinsella
> <mdr at ashroe.eu>; Dmitry Kozlyuk <dmitry.kozliuk at gmail.com>; Narcisa Ana
> Maria Vasile <navasile at linux.microsoft.com>; Dmitry Malloy
> <dmitrym at microsoft.com>; Pallavi Kadam <pallavi.kadam at intel.com>;
> dev at dpdk.org; Nipun Gupta <nipun.gupta at nxp.com>; Sachin Saxena
> <sachin.saxena at nxp.com>; Hemant Agrawal <hemant.agrawal at nxp.com>;
> ferruh.yigit at intel.com; david.marchand at redhat.com
> Subject: Re: [EXT] Re: [PATCH v5 1/2] eal: add API for bus close
> 
> Caution: EXT Email
> 
> 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

FSLMC bus has hardware resources for memory pools, queues, hardware access lock(called portal). 
These are common resources, which can be associated with any device. So they don't belong to a specific device. 
Eg: mempool resource can be used by both eth and crypto device. So, we cannot close mempool while closing just one of the device(It can happen in multiprocess applications). So, these resources should be specifically closed/freed with the bus instead with a device.

There is no need to expose these devices to users and their usages is limited to other devices on the bus. There is no reason to create yet another type of device in DPDK to expose these internal only resources.


> > From: Thomas Monjalon <thomas at monjalon.net>
> > > 10/01/2022 06:26, rohit.raj at nxp.com:
> > > > From: Rohit Raj <rohit.raj at 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().
> 
>