[dpdk-dev,v2] devargs: announce ABI change for device parameters
Checks
Commit Message
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@6wind.com>
---
v1 -> v2
* The first part of this series has been dropped.
After discussion with Thomas, it was decided to postpone the removal
of the relevant rte_pci_* functions.
* Add the parameters evolution in-tree additionally to the commit log.
---
doc/guides/rel_notes/deprecation.rst | 7 +++++++
1 file changed, 7 insertions(+)
Comments
-----Original Message-----
> Date: Wed, 10 May 2017 17:46:10 +0200
> From: Gaetan Rivet <gaetan.rivet@6wind.com>
> To: dev@dpdk.org
> Subject: [dpdk-dev] [PATCH v2] devargs: announce ABI change for device
> parameters
> X-Mailer: git-send-email 2.1.4
>
> 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@6wind.com>
Looks forward to seeing vdev and PCI under driver/bus/
Acked-by: Jerin Jacob <jerin.jacob@caviumnetworks.com>
> ---
> v1 -> v2
> * The first part of this series has been dropped.
> After discussion with Thomas, it was decided to postpone the removal
> of the relevant rte_pci_* functions.
> * Add the parameters evolution in-tree additionally to the commit log.
> ---
> doc/guides/rel_notes/deprecation.rst | 7 +++++++
> 1 file changed, 7 insertions(+)
>
> diff --git a/doc/guides/rel_notes/deprecation.rst b/doc/guides/rel_notes/deprecation.rst
> index a3e7c72..8f800dc 100644
> --- a/doc/guides/rel_notes/deprecation.rst
> +++ b/doc/guides/rel_notes/deprecation.rst
> @@ -81,3 +81,10 @@ Deprecation Notices
>
> - ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get``
> - ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set``
> +
> +* devargs: An ABI change is planned for 17.08 for the structure ``rte_devargs``.
> + The current version is dependent on bus-specific device identifier, which will
> + be made generic and abstracted, in order to make the EAL bus-agnostic.
> +
> + Accompanying this evolution, device command line parameters will thus support
> + explicit bus definition in a device declaration.
> --
> 2.1.4
>
On Wed, 10 May 2017 17:46:10 +0200
Gaetan Rivet <gaetan.rivet@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@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?
Hey Gaetan,
On Wed, May 10, 2017 at 5:46 PM, Gaetan Rivet <gaetan.rivet@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@6wind.com>
Glad to see people working on this.
Acked-by: David Marchand <david.marchand@6wind.com>
On 05/10/2017 05:46 PM, Gaetan Rivet 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@6wind.com>
I understand the change is necessary, so:
Acked-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Looking forward for the proposal, I guess you already have some ideas
that you could share?
Thanks,
Maxime
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@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@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.
10/05/2017 17:46, Gaetan Rivet:
> 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@6wind.com>
> ---
> +* devargs: An ABI change is planned for 17.08 for the structure ``rte_devargs``.
> + The current version is dependent on bus-specific device identifier, which will
> + be made generic and abstracted, in order to make the EAL bus-agnostic.
> +
> + Accompanying this evolution, device command line parameters will thus support
> + explicit bus definition in a device declaration.
Acked-by: Thomas Monjalon <thomas@monjalon.net>
Applied, thanks
@@ -81,3 +81,10 @@ Deprecation Notices
- ``rte_crpytodev_scheduler_mode_get``, replaced by ``rte_cryptodev_scheduler_mode_get``
- ``rte_crpytodev_scheduler_mode_set``, replaced by ``rte_cryptodev_scheduler_mode_set``
+
+* devargs: An ABI change is planned for 17.08 for the structure ``rte_devargs``.
+ The current version is dependent on bus-specific device identifier, which will
+ be made generic and abstracted, in order to make the EAL bus-agnostic.
+
+ Accompanying this evolution, device command line parameters will thus support
+ explicit bus definition in a device declaration.