From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id 4DB061BE87 for ; Tue, 3 Jul 2018 17:09:01 +0200 (CEST) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by fmsmga104.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 03 Jul 2018 08:09:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.51,304,1526367600"; d="scan'208";a="68340292" Received: from fmsmsx105.amr.corp.intel.com ([10.18.124.203]) by fmsmga004.fm.intel.com with ESMTP; 03 Jul 2018 08:08:52 -0700 Received: from fmsmsx156.amr.corp.intel.com (10.18.116.74) by FMSMSX105.amr.corp.intel.com (10.18.124.203) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 3 Jul 2018 08:08:52 -0700 Received: from shsmsx102.ccr.corp.intel.com (10.239.4.154) by fmsmsx156.amr.corp.intel.com (10.18.116.74) with Microsoft SMTP Server (TLS) id 14.3.319.2; Tue, 3 Jul 2018 08:08:51 -0700 Received: from shsmsx103.ccr.corp.intel.com ([169.254.4.51]) by shsmsx102.ccr.corp.intel.com ([169.254.2.223]) with mapi id 14.03.0319.002; Tue, 3 Jul 2018 23:08:49 +0800 From: "Zhang, Qi Z" To: Thomas Monjalon CC: "dev@dpdk.org" , "Burakov, Anatoly" , "Ananyev, Konstantin" , "Richardson, Bruce" , "Yigit, Ferruh" , "Shelton, Benjamin H" , "Vangati, Narender" Thread-Topic: [dpdk-dev] [PATCH v8 04/19] ethdev: introduce device lock Thread-Index: AQHUEcfFbxDt7G1dj06vIuuMXtd6DqR8vnAAgAC+i3A= Date: Tue, 3 Jul 2018 15:08:49 +0000 Message-ID: <039ED4275CED7440929022BC67E7061153243573@SHSMSX103.ccr.corp.intel.com> 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> <3478184.SidI6Nhsfv@xps> In-Reply-To: <3478184.SidI6Nhsfv@xps> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOGVmYmNiZWQtNzQ0Ni00M2ExLWI1YWEtYzZkMGFmODZjNzc3IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX05UIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE3LjEwLjE4MDQuNDkiLCJUcnVzdGVkTGFiZWxIYXNoIjoiQlwvMnJqYVwvVFVxZ3BEa2RUc2JzNlBrMUtwMmxiSjVLQ3JcL09POVprRHBKNWZKSVVwOVwvRlRDeWpHcjlFOFJcLzEyIn0= x-ctpclassification: CTP_NT dlp-product: dlpe-windows dlp-version: 11.0.200.100 dlp-reaction: no-action x-originating-ip: [10.239.127.40] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 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: Tue, 03 Jul 2018 15:09:01 -0000 > -----Original Message----- > From: Thomas Monjalon [mailto:thomas@monjalon.net] > Sent: Tuesday, July 3, 2018 5:56 PM > To: Zhang, Qi Z > Cc: dev@dpdk.org; Burakov, Anatoly ; Ananyev, > Konstantin ; Richardson, Bruce > ; Yigit, Ferruh ; She= lton, > Benjamin H ; Vangati, Narender > > Subject: Re: [dpdk-dev] [PATCH v8 04/19] ethdev: introduce device lock >=20 > 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. >=20 > Trying to understand: a process of an application could try to detach a p= ort > 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 simpl= ified 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 (lik= e stop traffic, release memory ...) before device be detached. > I guess it is only an application inter-process management. > If we really want to provide such helper in DPDK, it should not be limite= d to > ethdev. Once we move to eal layer, we will have rte_eal_dev_lock/unlock(devname, bu= sname). 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. > (for info, see class implementation: https://patches.dpdk.org/patch/41605= /) >=20 > 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. >=20 > > 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. >=20 > You don't need 2 flavors for the lock. > We can have only the "_with_callback" flavour and provide a default callb= ack > which says always no. OK, I can rollback this. Regards Qi >=20