[dpdk-dev] [PATCH v2] devargs: announce ABI change for device parameters

[Gaëtan Rivet]

On Wed, May 10, 2017 at 10:54:07AM -0700, Stephen Hemminger wrote:
>On Wed, 10 May 2017 17:46:10 +0200
>Gaetan Rivet <gaetan.rivet at 6wind.com> wrote:
>
>> The PCI and virtual bus are planned to be moved to the generic
>> drivers/bus directory in v17.08. For this change to be possible, the EAL
>> must be made completely independent.
>>
>> The rte_devargs structure currently holds device representation internal
>> to those two busses. It must be made generic before this work can be
>> completed.
>>
>> Instead of using either a driver name for a vdev or a PCI address for a
>> PCI device, a devargs structure will have to be able to describe any
>> possible device on all busses, without introducing dependencies on
>> any bus-specific device representation. This will break the ABI for this
>> structure.
>>
>> Additionally, an evolution will occur regarding the device parsing
>> from the command-line. A user must be able to set which bus will handle
>> which device, and this setting is integral to the definition of a
>> device.
>>
>> The format has not yet been formally defined, but a proposition will
>> follow soon for a new command line parameter format for all devices.
>>
>> Signed-off-by: Gaetan Rivet <gaetan.rivet at 6wind.com>
>
>I understand why having a union of all bus types is an issues since it
>means that if a new bus type (like VMBUS with GUID) has a bigger value
>then the existing representation would break.
>
>Perhaps give an example of what the new model would look like?

Two functionalities from the EAL are currently still dependent on
bus-specific implementation from vdev and PCI: attach/detach and
device argument parsing.

attach/detach is currently being reworked by Jan Blunck. I am
handling the device parsing.

Device parsing consists in two core functionalities: parsing a device
name and storing the resulting information.

The semantic of validating a device from a bus PoV is to report whether it
would be able to parse the given name and generate information relevant to
its implementation.

The model is thus similar to that of the driver probe within a bus: if a
bus returns success on validate, then we register this bus as the handler
for this device. Otherwise, we try other busses. We only have to keep the
textual representation of the device within the devargs, given that the bus
is the one capable later on to parse it and re-generate its internal
representation for scanning / probing purposes.

So the model is pretty straightforward: a new rte_bus method and a
purely textual representation of devices within rte_devargs.

One problem that remains is the possible ambiguity regarding device
names. Several separate teams will maintain their busses and nothing
prevents the device syntax of one bus to conflict with that of another
one.

Two possible approaches regarding a generic device name syntax:

* Explicit bus-name header

  + Non-ambiguous, future-proof.
  - Forces scripts, tests and users to be updated everywhere.

  eg. --dev "virtual:net_ring0" --dev "pci:0000:00:02.0"

* Best effort

  + Maintains backward compatibility for device parameters.
  - Possible ambiguities if conflicting device name syntaxes.

  eg. --dev "net_ring0" --dev "pci:0000:00:02.0"

The bus name separator must be carefully considered. ':' plays nice in
scripts and complex command lines, but obviously conflicts with the PCI
device syntax. The compromise option seems appealing, but I think that
the probability of conflicts between bus names and device syntax is pretty
high.

What's missing is the "whitelisted/blacklisted" flag. This is
considered in the design, but this email is starting to get long (using
-w and -b instead of --dev is always possible, the question is whether
an evolution here could be useful).

This new syntax will be proposed alongside the new rte_bus method.
I will send the relevant patches pretty soon. I have a
dependency on the work from Jan Blunck however and I might wait for him
to submit his patches first. Probably next week.

-- 
Gaëtan Rivet
6WIND