From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from out1-smtp.messagingengine.com (out1-smtp.messagingengine.com [66.111.4.25]) by dpdk.org (Postfix) with ESMTP id 108B31BB3D for ; Thu, 5 Jul 2018 03:55:27 +0200 (CEST) Received: from compute1.internal (compute1.nyi.internal [10.202.2.41]) by mailout.nyi.internal (Postfix) with ESMTP id 711D821B25; Wed, 4 Jul 2018 21:55:24 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute1.internal (MEProxy); Wed, 04 Jul 2018 21:55:24 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:content-transfer-encoding:content-type:date:from:in-reply-to :message-id:mime-version:references:subject:to:x-me-sender :x-me-sender:x-sasl-enc; s=mesmtp; bh=5ScOh5bRFJoEiIf+NirmgL9zdQ DdT50b5m8dqscw41E=; b=GuLJhPeyDMEQA/1QFVa6szK+Jh9HOX5lH6af9wf/Gc 0Me51/QFe8PL7fMd/N0P/AQkioVhq2xD6SroMzvRje2og7/PluEY+VQxfGEsrfGt q1IZQNQifu72EwCXvTKPcW74Opm9BBMXxD7eLecylY3SANmUQcxQ9hXe2QPNoWnO o= DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:content-transfer-encoding:content-type :date:from:in-reply-to:message-id:mime-version:references :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm3; bh=5ScOh5 bRFJoEiIf+NirmgL9zdQDdT50b5m8dqscw41E=; b=Ofs7stedpYTqQImzET1EEO v9y0+I3fuMJFb/qyUiuOU60ouU1bbqb0D7vqZ64oTglHwX1M1iD3oxU+kPpl97qa gPxGeqiSJKNIeHjaTK5DupxrrdDo9yncr7TJq3g7FqKye3F1aotZHh9kXf6WWykF /ehcJ6/ibTau0DMVKoPOtEWtNMocn/GuCdGQdpXREopaTzynhvHj7z5ZXT7g6NAJ +twBia5ZNzdalCQUWDtReS0mawUDd/J43LUbiItRQlzodsBFfLhv7MKl3LpVHT06 LaudcTAryBvkpqZy/me1DiPJAjtbwtXO5ttcRwqLmYUza0N9Y2L6Vlhp3BRgQ5Og == X-ME-Proxy: X-ME-Sender: Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184]) by mail.messagingengine.com (Postfix) with ESMTPA id 118C9102B2; Wed, 4 Jul 2018 21:55:22 -0400 (EDT) From: Thomas Monjalon To: "Zhang, Qi Z" Cc: "dev@dpdk.org" , "Burakov, Anatoly" , "Ananyev, Konstantin" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" , "arybchenko@solarflare.com" Date: Thu, 05 Jul 2018 03:55:21 +0200 Message-ID: <4330736.hRnLL86zNI@xps> In-Reply-To: <039ED4275CED7440929022BC67E7061153250867@SHSMSX103.ccr.corp.intel.com> References: <20180607123849.14439-1-qi.z.zhang@intel.com> <6105228.vaBHSlUH0d@xps> <039ED4275CED7440929022BC67E7061153250867@SHSMSX103.ccr.corp.intel.com> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" Subject: Re: [dpdk-dev] [PATCH v8 04/19] ethdev: introduce device lock X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Thu, 05 Jul 2018 01:55:27 -0000 05/07/2018 03:38, Zhang, Qi Z: > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > 04/07/2018 12:49, Zhang, Qi Z: > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > 04/07/2018 03:47, Zhang, Qi Z: > > > > > From: Thomas Monjalon [mailto:thomas@monjalon.net] > > > > > > 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. > > [...] > > > > > > 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? > > > > > > > > > > I have thought about this before. > > > > > Not like RTE_ETH_EVENT_DESTROY and other event hook, the hook here > > > > need to give feedback, pass or fail will impact the following > > > > behavior, this make it special, so I separate it from all exist > > > > rte_eth_event_type handle mechanism. > > > > > > > > Look at _rte_eth_dev_callback_process, there is a "ret_param". > > > > > > OK, that should work. > > > > > > > > > The alternative solution is > > > > > we just introduce a new event type like RTE_ETH_EVENT_PRE_DETACH > > > > > and reuse all exist API > > > > rte_eth_dev_callback_register/rte_eth_dev_callback_unregister. > > > > > > > > I don't think we need a new event. > > > > Let's try to use RTE_ETH_EVENT_DESTROY. > > > > > > The problem is RTE_ETH_EVENT_DESTROY is used in > > rte_eth_dev_release_port already. > > > And in PMD, rte_eth_dev_release_port is called after dev_uninit, that > > > mean its too late to reject a detach > > > > You're right. > > > > It's a real mess currently. > > The right order should be to remove ethdev ports before removing the > > underlying EAL device. But it's strangely not the case. > > > > We need to separate things. > > The function rte_eth_dev_close can be used to remove an ethdev port if we > > add a call to rte_eth_dev_release_port. > > So we could call rte_eth_dev_close in PMD remove functions. > > Is "close" a good time to ask confirmation to the application? > > Or should we ask confirmation a step before, on "stop"? > > I think the confirmation should before any cleanup stage, it should at the beginning of driver->remove. So you stop a port, even if the app policy is against detaching it? > Also we should not put it into rte_eth_dev_stop, because, rte_eth_dev_stop can invoked by application directly, in that case, we don't what any callback be invoked. It it the same to detach a port: it is invoked directly by application. I thought you wanted a callback as helper for inter-process management? > > > So , do you mean we can remove > > > _rte_eth_dev_callback_process(RTE_ETH_EVENT_DESTROPY) in > > > rte_eth_dev_release_port > > > > I would say we need RTE_ETH_EVENT_DESTROY to notify that the port is really > > destroyed. > > Maybe the right thing to do is to add a new event > > RTE_ETH_EVENT_CLOSE_REQUEST or something else. > > Note that we already have 2 removal events in ethdev: > > - RTE_ETH_EVENT_INTR_RMV when the port cannot be used anymore > > - RTE_ETH_EVENT_DESTROY when the port is going to be deleted > > > > > And where is right place to call > > _rte_eth_dev_callback_process(RTE_ETH_EVENT_DESTROY)? > > > If can't be called in rte_eth_dev_detach, because if device is removed by > > rte_eal_hotplug_remove, it will be skipped. > > > > No, rte_eth_dev_detach and rte_eal_hotplug_remove are 2 different things. > > One is a mix of ethdev and EAL (and should be deprecated), the other one is > > for the underlying device at EAL level. > > > > > probably we need to call this at the beginning of each PMD driver->remove?, > > that means, we need to change all PMD drivers? > > > > Yes, we can call rte_eth_dev_stop and rte_eth_dev_close at the beginning of > > PMD remove. > > Note that there is already a helper rte_eth_dev_destroy called in some PMD to > > achieve the removal, but curiously, it doesn't call stop and close functions. > > Currently PMD implement driver->remove with different way, rte_eth_dev_stop / rte_eth_dev_close / rte_eth_dev_destroy is not always be invoked. > So Before we standardize what ethdev API and what sequence should be called in driver->remove (I think this is a separate task) > I will suggest > 1. Create another help function like _rte_eth_dev_allow_to_remove, > 2. the help function will call _rte_eth_dev_callback_process(RTE_ETH_EVENT_PRE_REMOVE) and update ret_param which contain a reject count. > 3. the help function should to invoked at beginning at driver->remove and driver->remove will abort if the help function failed. > > But once we standardized that , we can do cleanup to merge it into another rte_eth_xxx API in next step. > > What do you think? No All the problems we have today are because we preferred add more and more functions instead of fixing the basic stuff. And it is especially the case for all the detach crap. So no. Let's fix stuff first.