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 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. (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? > 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.
