From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Stephen Hemminger <stephen@networkplumber.org>
Cc: dev@dpdk.org, Maxime Coquelin <maxime.coquelin@redhat.com>
Subject: Re: [dpdk-dev] [PATCH v2] devargs: announce ABI change for device parameters
Date: Wed, 10 May 2017 23:59:27 +0200 [thread overview]
Message-ID: <20170510215927.GG14914@bidouze.vm.6wind.com> (raw)
In-Reply-To: <20170510105407.0377a27c@xeon-e3>
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.
--
Gaëtan Rivet
6WIND
next prev parent reply other threads:[~2017-05-10 21:59 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-05-10 12:52 [dpdk-dev] [PATCH 1/2] pci: deprecate PCI detach Gaetan Rivet
2017-05-10 12:52 ` [dpdk-dev] [PATCH 2/2] devargs: announce ABI change for device parameters Gaetan Rivet
2017-05-10 13:04 ` Thomas Monjalon
2017-05-10 13:02 ` [dpdk-dev] [PATCH 1/2] pci: deprecate PCI detach Thomas Monjalon
2017-05-10 15:48 ` Gaëtan Rivet
2017-05-10 15:46 ` [dpdk-dev] [PATCH v2] devargs: announce ABI change for device parameters Gaetan Rivet
2017-05-10 17:28 ` Jerin Jacob
2017-05-10 17:54 ` Stephen Hemminger
2017-05-10 21:59 ` Gaëtan Rivet [this message]
2017-05-10 18:50 ` David Marchand
2017-05-10 19:54 ` Maxime Coquelin
2017-05-10 23:14 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20170510215927.GG14914@bidouze.vm.6wind.com \
--to=gaetan.rivet@6wind.com \
--cc=dev@dpdk.org \
--cc=maxime.coquelin@redhat.com \
--cc=stephen@networkplumber.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).