01/02/2022 06:40, Rohit Raj: > From: Thomas Monjalon <tho...@monjalon.net> > > 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.
OK I understand better now, thanks. > > > 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().
