From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v8 04/19] ethdev: introduce device lock Date: Wed, 04 Jul 2018 00:13:56 +0200 Message-ID: <1712900.Rv84bhh2vl@xps> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <3478184.SidI6Nhsfv@xps> <039ED4275CED7440929022BC67E7061153243573@SHSMSX103.ccr.corp.intel.com> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, "Burakov, Anatoly" , "Ananyev, Konstantin" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" To: "Zhang, Qi Z" Return-path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 9DC651BE3E for ; Wed, 4 Jul 2018 00:13:59 +0200 (CEST) In-Reply-To: <039ED4275CED7440929022BC67E7061153243573@SHSMSX103.ccr.corp.intel.com> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" 03/07/2018 17:08, Zhang, Qi Z: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 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. Yes I agree such hook can be a good idea. > > 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. No. Again, a port is not exactly a device. There can be several ports per device. I think the right place for this hook is in port-level API (ethdev, crypto, etc). And as we improve only ethdev currently, without any common genericity for other device classes, it is probably fine in ethdev for now. > > > (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. No, I don't think so. I am just trying to show that you cannot really "lock" a port. Maybe you should just rename those functions. After all, it is just a pre-detach hook. Wait, how is it different of RTE_ETH_EVENT_DESTROY callback? Perhaps we just need to improve the handling of the DESTROY event?