From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id 617FB5A6E for ; Thu, 29 Jun 2017 12:30:27 +0200 (CEST) Received: from fmsmga001.fm.intel.com ([10.253.24.23]) by fmsmga105.fm.intel.com with ESMTP; 29 Jun 2017 03:30:26 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.40,280,1496127600"; d="scan'208";a="1166083834" Received: from irsmsx153.ger.corp.intel.com ([163.33.192.75]) by fmsmga001.fm.intel.com with ESMTP; 29 Jun 2017 03:30:25 -0700 Received: from irsmsx104.ger.corp.intel.com ([169.254.5.26]) by IRSMSX153.ger.corp.intel.com ([169.254.9.74]) with mapi id 14.03.0319.002; Thu, 29 Jun 2017 11:30:24 +0100 From: "Richardson, Bruce" To: =?iso-8859-1?Q?Ga=EBtan_Rivet?= , Jan Blunck CC: Thomas Monjalon , dev Thread-Topic: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from a device name Thread-Index: AQHS8K1jQnHE4T5V3kGjOy1PQoo31qI7kX6AgAASFgA= Date: Thu, 29 Jun 2017 10:30:23 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0721844F2@IRSMSX104.ger.corp.intel.com> References: <2359359.ae4fqFO3lF@xps> <20170629102353.GK13355@bidouze.vm.6wind.com> In-Reply-To: <20170629102353.GK13355@bidouze.vm.6wind.com> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiZDFlOGVmYzMtYWE1Yy00NDRmLTlkYmYtMDQwMGVhZDQ5NzI0IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6Ik9jeEFxMmZxaTZPR1FOUlBPb0N4MXhYRk1mS2RFUHNnNDNObmI2TTdjbW89In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from a device name 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, 29 Jun 2017 10:30:28 -0000 > -----Original Message----- > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ga=EBtan Rivet > Sent: Thursday, June 29, 2017 11:24 AM > To: Jan Blunck > Cc: Thomas Monjalon ; dev > Subject: Re: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from > a device name >=20 > On Thu, Jun 29, 2017 at 09:56:30AM +0200, Jan Blunck wrote: > > On Wed, Jun 28, 2017 at 7:03 PM, Thomas Monjalon > wrote: > > > 27/06/2017 20:55, Jan Blunck: > > >> On Wed, Jun 21, 2017 at 1:30 AM, Gaetan Rivet > wrote: > > >> > /** > > >> > + * Find a bus capable of identifying a device. > > >> > + * > > >> > + * @param str > > >> > + * A device identifier (PCI address, virtual PMD name, ...). > > >> > + * > > >> > + * @return > > >> > + * A valid bus handle if found. > > >> > + * NULL if no bus is able to parse this device. > > >> > + */ > > >> > +struct rte_bus *rte_bus_from_dev(const char *str); > > >> > > >> I still don't agree with this. The bus name should be passed > > >> explicitly by the user of the API. > > >> > > >> NAK. > > > > > > Please explain why you think the bus name should be explicit. > > > If the bus is ambiguous, it can be explicited by the user. > > > > > > I see some good benefits in being tolerant with the bus/device > > > representation. It provides a smooth transition to the bus model. > > > > > > > We build libraries. The applications we build with the help of those > > libraries get notified by the OS about device events. Those devices > > are chields of their parent bus. At the time the event is fired the OS > > already knows about: > > > > - the bus name (parent) > > - the device name (child) > > - additional event parameters (environment) > > > > Blame me that I probably spent too much time with Kay Sievers and > > GregKH to understand that device naming is easy to get wrong. Just > > look at the hyperv device names and how they switched to the UUID > > scheme. I don't think that hyperv is the only bus that uses UUID as > > device identification. We should not codify a policy of how to deduce > > a bus name from a given device name if that is knowledge that is > > already present externally. Otherwise I fear this part of the EAL will > > be subject to constant churn. >=20 > I agree in the context of device events. > But this development concerns all device identification scheme, not only > in the context of hotplug where we can retrieve events giving proper info= . > It is parsing user input as well (command line or configuration). >=20 > In this user-centric device specification, the issue is that the current > model expect the user to provide the bus implicitly by using the right > parameter (--vdev, -w). This identification *cannot* stay, as those are > parsed within the EAL and specifics are getting out. >=20 > What is left is thus a choice: either >=20 > * We let the current scheme work for a time, while the EAL is being > cleaned > out, during which we need some crutch to emulate the current behavior >=20 > * We force all users to migrate to the new format straight away with a > full identification scheme. >=20 > I planned for both eventuality in my deprecation notice, by warning that > device parameters and definition might change this version. However, whil= e > I thought that it was possible it would happen, I think it is best to > provide as much stability as possible while we work out the EAL internals= . >=20 > This API is only there because I choose to keep backward compatibility. > A compromise might be to make it private to the EAL (I proposed it before > but no one really responded so I haven't acted on it). This would help th= e > future transition to the fully-qualified-device-identifier that we will > have to require from our users. >=20 > I'd like to hear from other DPDK devs as I think that surprising users is > not something that should be done lightly. I understand your concern and > am not opposed to address it. >=20 I'm all in favour of stability and backward compatibility, so I don't like = the option of forcing users to change just now - especially as the whole pi= cture is not yet complete. Once we are sure we have a fully settled new sch= eme, then we can being to deprecate the old. /Bruce