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

Gaëtan Rivet gaetan.rivet at 6wind.com
Thu Jun 29 12:23:53 CEST 2017


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.

-- 
Gaëtan Rivet
6WIND


More information about the dev mailing list