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.ri...@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.ri...@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
