From mboxrd@z Thu Jan  1 00:00:00 1970
From: Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [PATCH v8 04/19] ethdev: introduce device lock
Date: Tue, 03 Jul 2018 11:56:04 +0200
Message-ID: <3478184.SidI6Nhsfv@xps>
References: <20180607123849.14439-1-qi.z.zhang@intel.com>
 <20180702054450.29269-1-qi.z.zhang@intel.com>
 <20180702054450.29269-5-qi.z.zhang@intel.com>
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: 7Bit
Cc: dev@dpdk.org, anatoly.burakov@intel.com, konstantin.ananyev@intel.com,
 bruce.richardson@intel.com, ferruh.yigit@intel.com,
 benjamin.h.shelton@intel.com, narender.vangati@intel.com
To: Qi Zhang <qi.z.zhang@intel.com>
Return-path: <dev-bounces@dpdk.org>
Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com
 [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 25E2B1BE9C
 for <dev@dpdk.org>; Tue,  3 Jul 2018 11:56:07 +0200 (CEST)
In-Reply-To: <20180702054450.29269-5-qi.z.zhang@intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://mails.dpdk.org/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://mails.dpdk.org/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://mails.dpdk.org/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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.