> -----Original Message-----
> From: Thomas Monjalon [mailto:tho...@monjalon.net]
> Sent: Tuesday, July 3, 2018 5:56 PM
> To: Zhang, Qi Z <qi.z.zh...@intel.com>
> Cc: dev@dpdk.org; Burakov, Anatoly <anatoly.bura...@intel.com>; Ananyev,
> Konstantin <konstantin.anan...@intel.com>; Richardson, Bruce
> <bruce.richard...@intel.com>; Yigit, Ferruh <ferruh.yi...@intel.com>; Shelton,
> Benjamin H <benjamin.h.shel...@intel.com>; Vangati, Narender
> <narender.vang...@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v8 04/19] ethdev: introduce device lock
>
> 02/07/2018 07:44, Qi Zhang:
> > Introduce API rte_eth_dev_lock and rte_eth_dev_unlock to let
> > application lock or unlock on specific ethdev, a locked device can't
> > be detached, this help applicaiton to prevent unexpected device
> > detaching, especially in multi-process envrionment.
>
> Trying to understand: a process of an application could try to detach a port
> while another process is against this decision.
> Why an application needs to be protected against itself?
I think we can regard this as a help function, it help application to
simplified the situation when one process want to detach a device while another
one is still using it.
Application can register a callback which can do to necessary clean up (like
stop traffic, release memory ...) before device be detached.
> I guess it is only an application inter-process management.
> If we really want to provide such helper in DPDK, it should not be limited to
> ethdev.
Once we move to eal layer, we will have rte_eal_dev_lock/unlock(devname,
busname).
But its also better we keep rte_eth_dev_lock/unlock to make ethdev API more
completed (any port be locked means underline rte_device also be locked?)
and this is same for other device family.
> (for info, see class implementation: https://patches.dpdk.org/patch/41605/)
>
> What about hardware unplug?
> Can we detach the locked ports associated to the unplugged device?
NO, we can't.
But do you think, we need to introduce a "force detach" version, which will
ignore all locks.
>
> > Aslo introduce the new API rte_eth_dev_lock_with_callback and
> > rte_eth_dev_unlock_with callback to let application to register a
> > callback function which will be invoked before a device is going to be
> > detached, the return value of the function will decide if device will
> > continue be detached or not, this support application to do condition
> > check at runtime.
>
> You don't need 2 flavors for the lock.
> We can have only the "_with_callback" flavour and provide a default callback
> which says always no.
OK, I can rollback this.
Regards
Qi
>