From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-wm0-f47.google.com (mail-wm0-f47.google.com [74.125.82.47]) by dpdk.org (Postfix) with ESMTP id 5CCD2235 for ; Thu, 29 Jun 2017 12:24:04 +0200 (CEST) Received: by mail-wm0-f47.google.com with SMTP id i127so9383193wma.0 for ; Thu, 29 Jun 2017 03:24:04 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=6wind-com.20150623.gappssmtp.com; s=20150623; h=date:from:to:cc:subject:message-id:references:mime-version :content-disposition:content-transfer-encoding:in-reply-to :user-agent; bh=z605u8C4h5ecA23B9bHCL6BmrHf7o7/iinZpWVx8lV0=; b=DfVk4cEDVmYVigoDxjh0MjdKzzxUyv7xDfDdoqyx0nH4kSQzSAusf7dl0n12gQED8i uMwDsrqm9dYghGn8UHM+pM02nSFpxIL3FeyTR4CxeTr2m44W/Aw34EbjgUQvVT3kvTqS fn2Igxeaf6uDomDdtFWtaRRXyi3mINkY7MZV6+hH6yuUNY2sqAWF8pmnxqyGiz7FRP5I 5Sq9JEAb5UAxOHlm4iQ2fTnXJEJqt92xPY+IJKpCWlgMm+Ts5YO8jdgyqqeni0N5GrmY mKTkSmnL8qxjr09Zp38xTlvtNiA00JosW4t8Z6GLJMSbbor+3koGtxbSGNdkegulu0gW XpxA== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20161025; h=x-gm-message-state:date:from:to:cc:subject:message-id:references :mime-version:content-disposition:content-transfer-encoding :in-reply-to:user-agent; bh=z605u8C4h5ecA23B9bHCL6BmrHf7o7/iinZpWVx8lV0=; b=tgjq/B4TWK7j5UASh5cJlBxgyAqVyoNMQeyKqSz0SluEImM9g2oMxvIItcabUHUJnx BPHD5TpWdQFES6TZyW85XHhyl6+GrDPYLnAMRIVJX5wjccbNUsXY4+WhofB3rGMF1wJf B31vfDJzxYA+VcM0v9rRqflzEqVSH5C5SMm0i7ksvJWNHhipWphc+DKRCAueQ0RRik5H q2GTpK+pUXhWDbSee49kFyCLrfLRG8M1Kb/kMrJbIrhBq11mUmzdYWOWnav9Xu9MREhE VPeiif6hvJaw5zXQnqKkVRfXfxPz5FTYV96MVW/a614Q2603vymWrWeLjA7pjdWkjnTf bDBA== X-Gm-Message-State: AIVw111GXrNHf1ynijNf2K4GUCkV14XM/fnEk8JsEXvUx2mYEgOqyJqR MPLmgDcu2THLaSHJDZw= X-Received: by 10.28.218.145 with SMTP id r139mr1411000wmg.69.1498731843736; Thu, 29 Jun 2017 03:24:03 -0700 (PDT) Received: from bidouze.vm.6wind.com (host.78.145.23.62.rev.coltfrance.com. [62.23.145.78]) by smtp.gmail.com with ESMTPSA id r142sm922657wmg.24.2017.06.29.03.24.01 (version=TLS1_2 cipher=ECDHE-RSA-AES128-GCM-SHA256 bits=128/128); Thu, 29 Jun 2017 03:24:01 -0700 (PDT) Date: Thu, 29 Jun 2017 12:23:53 +0200 From: =?iso-8859-1?Q?Ga=EBtan?= Rivet To: Jan Blunck Cc: Thomas Monjalon , dev Message-ID: <20170629102353.GK13355@bidouze.vm.6wind.com> References: <2359359.ae4fqFO3lF@xps> MIME-Version: 1.0 Content-Type: text/plain; charset=iso-8859-1 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: User-Agent: Mutt/1.5.23 (2014-03-12) 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:24:04 -0000 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. 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). 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. What is left is thus a choice: either * 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 * We force all users to migrate to the new format straight away with a full identification scheme. I planned for both eventuality in my deprecation notice, by warning that device parameters and definition might change this version. However, while 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. 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 the future transition to the fully-qualified-device-identifier that we will have to require from our users. 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. -- Gaëtan Rivet 6WIND