From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dispatch1-us1.ppe-hosted.com (dispatch1-us1.ppe-hosted.com [67.231.154.164]) by dpdk.org (Postfix) with ESMTP id 60CF41B3A1 for ; Thu, 28 Jun 2018 18:46:49 +0200 (CEST) X-Virus-Scanned: Proofpoint Essentials engine Received: from webmail.solarflare.com (uk.solarflare.com [193.34.186.16]) (using TLSv1 with cipher ECDHE-RSA-AES256-SHA (256/256 bits)) (No client certificate requested) by mx1-us4.ppe-hosted.com (Proofpoint Essentials ESMTP Server) with ESMTPS id 1DE39B40088; Thu, 28 Jun 2018 16:46:48 +0000 (UTC) Received: from [192.168.38.17] (91.220.146.112) by ukex01.SolarFlarecom.com (10.17.10.4) with Microsoft SMTP Server (TLS) id 15.0.1044.25; Thu, 28 Jun 2018 17:46:41 +0100 To: Qi Zhang , , CC: , , , , , References: <20180607123849.14439-1-qi.z.zhang@intel.com> <20180628125708.39610-1-qi.z.zhang@intel.com> <20180628125708.39610-5-qi.z.zhang@intel.com> From: Andrew Rybchenko Message-ID: <15a3d55f-27da-84d1-00a5-97305e78133e@solarflare.com> Date: Thu, 28 Jun 2018 19:46:36 +0300 User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:52.0) Gecko/20100101 Thunderbird/52.8.0 MIME-Version: 1.0 In-Reply-To: <20180628125708.39610-5-qi.z.zhang@intel.com> Content-Language: en-GB X-Originating-IP: [91.220.146.112] X-ClientProxiedBy: ocex03.SolarFlarecom.com (10.20.40.36) To ukex01.SolarFlarecom.com (10.17.10.4) X-TM-AS-Product-Ver: SMEX-11.0.0.1191-8.100.1062-23934.003 X-TM-AS-Result: No--7.747300-0.000000-31 X-TM-AS-User-Approved-Sender: Yes X-TM-AS-User-Blocked-Sender: No X-MDID: 1530204408-w7pU3JmaUAxS Content-Type: text/plain; charset="utf-8"; format=flowed Content-Transfer-Encoding: 7bit X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH v7 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, 28 Jun 2018 16:46:49 -0000 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. Should applications always lock device if some data cores are polling its Rx/Tx queues? 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? > 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. > Signed-off-by: Qi Zhang > Reviewed-by: Anatoly Burakov