> -----Original Message-----
> From: Thomas Monjalon <tho...@monjalon.net>
> Sent: Thursday, January 20, 2022 8:28 PM
> To: Rohit Raj <rohit....@nxp.com>
> Cc: Bruce Richardson <bruce.richard...@intel.com>; Ray Kinsella
> <m...@ashroe.eu>; Dmitry Kozlyuk <dmitry.kozl...@gmail.com>; Narcisa Ana
> Maria Vasile <navas...@linux.microsoft.com>; Dmitry Malloy
> <dmit...@microsoft.com>; Pallavi Kadam <pallavi.ka...@intel.com>;
> dev@dpdk.org; Nipun Gupta <nipun.gu...@nxp.com>; Sachin Saxena
> <sachin.sax...@nxp.com>; Hemant Agrawal <hemant.agra...@nxp.com>;
> ferruh.yi...@intel.com; david.march...@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 <tho...@monjalon.net>
> > > 10/01/2022 06:26, rohit....@nxp.com:
> > > > From: Rohit Raj <rohit....@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().
>
>
