[dpdk-dev] [PATCH v7 04/19] ethdev: introduce device lock

[Zhang, Qi Z]

From: Andrew Rybchenko [mailto:arybchenko at solarflare.com]
Sent: Friday, June 29, 2018 12:47 AM
To: Zhang, Qi Z <qi.z.zhang at intel.com>; thomas at monjalon.net; Burakov, Anatoly <anatoly.burakov at intel.com>
Cc: Ananyev, Konstantin <konstantin.ananyev at intel.com>; dev at dpdk.org; Richardson, Bruce <bruce.richardson at intel.com>; Yigit, Ferruh <ferruh.yigit at intel.com>; Shelton, Benjamin H <benjamin.h.shelton at intel.com>; Vangati, Narender <narender.vangati at intel.com>
Subject: Re: [dpdk-dev] [PATCH v7 04/19] ethdev: introduce device lock

On 06/28/2018 03:56 PM, Qi Zhang wrote:

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.

I think that locking deserves a bit more details on why it is needed.
When/why should it be used by applications or other libraries.
Right now the description is too generic and real usecases are unclear.

[Qi], the typical use case is described in cover letter.
Primary works as resource management process and secondary process do the network stuff.
And we need handshake to prevent a running device be detached unexpected.
So we introduce the lock/unlock API for this requirement,

I can add these information in commit log, if you think it’s necessary.


Should applications always lock device if some data cores are polling
its Rx/Tx queues?
[Qi] Application should know if it is possible to detach a running device on a separate process or separate thread.
The lock API helps application to handle such kind of case.

Does it imply that all apps which would like to be
hotplug-aware should be updated accordingly?
Do you have guidelines or is it too early stage for now?

Basically we didn’t break any thing what we already have, we just provide a new option which looks helpful to simplify
the development of application that need to handle hotplug.


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.

What should/will happen if two callbacks are registered and the
first says OK, but the second denies detach. The device will be
detached from the first callback point of view, but finally remains.

[Qi] Though I’m not very sure if this will be the real case, but if that happens, one method for
the lock owner to know that a device is exactly detached or not is also register a callback for
RTE_ETH_EVENT_DESTROY, so it will be notified when device is detached and do some following cleanup

But yes there will be an issue if some resource is freed during the first callback, it will not rollback.
So, application should consider this.

Thanks
Qi



Signed-off-by: Qi Zhang <qi.z.zhang at intel.com><mailto:qi.z.zhang at intel.com>

Reviewed-by: Anatoly Burakov <anatoly.burakov at intel.com><mailto:anatoly.burakov at intel.com>