[dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from a device name

[Richardson, Bruce]

> -----Original Message-----
> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Gaëtan Rivet
> Sent: Thursday, June 29, 2017 11:24 AM
> To: Jan Blunck <jblunck at infradead.org>
> Cc: Thomas Monjalon <thomas at monjalon.net>; dev <dev at dpdk.org>
> Subject: Re: [dpdk-dev] [PATCH v5 5/7] bus: add helper to find a bus from
> a device name
> 
> On Thu, Jun 29, 2017 at 09:56:30AM +0200, Jan Blunck wrote:
> > On Wed, Jun 28, 2017 at 7:03 PM, Thomas Monjalon <thomas at monjalon.net>
> wrote:
> > > 27/06/2017 20:55, Jan Blunck:
> > >> On Wed, Jun 21, 2017 at 1:30 AM, Gaetan Rivet
> <gaetan.rivet at 6wind.com> 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.
> 

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 picture is not yet complete. Once we are sure we have a fully settled new scheme, then we can being to deprecate the old.

/Bruce