DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: Yuanhan Liu <yliu@fridaylinux.org>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax
Date: Wed, 17 Jan 2018 00:46:33 +0100	[thread overview]
Message-ID: <20180116234633.i4j2itsuzxk7kl35@bidouze.vm.6wind.com> (raw)
In-Reply-To: <5324030.qnTS7Rnbq7@xps>

On Wed, Jan 17, 2018 at 12:22:43AM +0100, Thomas Monjalon wrote:
> 17/01/2018 00:19, Gaëtan Rivet:
> > Hi Yuanhan,
> > 
> > On Tue, Jan 16, 2018 at 10:50:18PM +0800, Yuanhan Liu wrote:
> > > +The ``devargs`` can be used for whitelisting/blacklisting devices, identifying
> > > +DPDK ports and attaching/deatching devices. They all share the same syntax.
> > > +
> > > +It is split in 3 categories, where almost everything is optional key/value pairs:
> > > +
> > > +* bus (pci, vdev, vmbus, fslmc, etc)
> > > +* class (eth, crypto, etc)
> > > +* driver (i40e, mlx5, virtio, etc)
> > > +
> > > +The key/value pair describing the category scope is mandatory and must be the
> > > +first pair in the category properties. Example: bus=pci, must be placed before
> > > +id=0000:01:00.0.
> > > +
> > > +The syntax has below rules:
> > > +
> > > +* Between categories, the separator is a slash.
> > > +* Inside a category, the separator is a comma.
> > > +* Inside a key/value pair, the separator is an equal sign.
> > > +* Each category can be used alone.
> > > +
> > > +Here is an example with all categories::
> > > +
> > > +    bus=pci,id=0000:01:00.0/class=eth,mac=00:11:22:33:44:55/driver=PMD_NAME,driverspecificproperty=VALUE
> > > +
> > 
> > It might be a nitpick, but the driver specific properties might not
> > follow the key/value pair syntax. At least for the fail-safe, a custom
> > parsing needs to happen. I think vdev in general will need flexibility.
> 
> What is more flexible than key/value?
> 

fail-safe does not need something more flexible, but different.
It needs to define substrings describing whole devices, thus substrings
following the aforementioned syntax.

I choose to use ( and ) as markers of beginning and end of the "special
sub-device part that we need to skip for the moment". In the end, I need
a way to mark the beginning and the end of a parameter. Without this,
the next parameter would be considered as the parameter of the
sub-device, not of the fail-safe.

= separated key/value pair does not allow for this (or with very
convoluted additional rules to the syntax).

> > There could be a note that after the comma past the eventual
> > "driver=xxxx" pair, the syntax is driver-specific and might not follow
> > the equal-separated key/value pair syntax.
> 
> Please give an example.

bus=vdev/driver=failsafe,dev(bus=pci,id=00:02.0),fd(/some/file/)

Here, without some kind of "end-of-parameter" mark, fd() would be
considered as a new parameter of the sub-device 00:02.0

--------------

And while I'm at it, there is an ambiguity that might need to be defined
before the whole shebang is implemented: whether the parameters
positions are meaningful or not. Currently some drivers might consider their
parameters to mean different things depending on their order of appearance.

It could help to explicitly say that the order is asemic and should not
be considered by drivers.

Why this is important: I think that depending on the new rte_devargs
representation, it could be beneficial to have a canonical representation
of an rte_devargs: given an arbitrary string given by users, the devargs
could then be rewritten in a determinist way, which would help implementing
comparison, assignment, and some other operations.

However, for this canonicalization to be possible, order needs to be
explicitly said to be meaningless.

-- 
Gaëtan Rivet
6WIND

  reply	other threads:[~2018-01-16 23:46 UTC|newest]

Thread overview: 33+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2018-01-16 14:50 Yuanhan Liu
2018-01-16 16:33 ` Mcnamara, John
2018-01-16 23:19 ` Gaëtan Rivet
2018-01-16 23:22   ` Thomas Monjalon
2018-01-16 23:46     ` Gaëtan Rivet [this message]
2018-01-17  0:03       ` Thomas Monjalon
2018-01-17  9:37         ` Gaëtan Rivet
2018-01-17  9:43           ` Thomas Monjalon
2018-01-17 10:11 ` Gaëtan Rivet
2018-01-17 10:54   ` Thomas Monjalon
2018-01-17 12:34 ` Ferruh Yigit
2018-01-18  7:35   ` Yuanhan Liu
2018-01-18  8:46     ` Thomas Monjalon
2018-01-18  9:46       ` Gaëtan Rivet
2018-01-23 12:46         ` Yuanhan Liu
2018-01-23 14:29           ` Thomas Monjalon
2018-01-23 16:08             ` Gaëtan Rivet
2018-01-23 17:22               ` Thomas Monjalon
2018-01-23 17:37                 ` Gaëtan Rivet
2018-01-23 18:12                   ` Thomas Monjalon
2018-01-24 15:24               ` Yuanhan Liu
2018-01-24 16:51                 ` Thomas Monjalon
2018-01-24  6:43             ` Yuanhan Liu
2018-01-24  8:19               ` Thomas Monjalon
2018-01-24  9:28                 ` Yuanhan Liu
2018-01-24 10:21                   ` Thomas Monjalon
2018-01-24 10:36                     ` Yuanhan Liu
2018-01-24 10:37                       ` Thomas Monjalon
2018-01-24 15:04                         ` Yuanhan Liu
2018-01-24 16:57                           ` Thomas Monjalon
2018-01-25 14:41                             ` Yuanhan Liu
2018-01-25 14:58                               ` Thomas Monjalon
2023-06-08 22:51 ` Stephen Hemminger

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=20180116234633.i4j2itsuzxk7kl35@bidouze.vm.6wind.com \
    --to=gaetan.rivet@6wind.com \
    --cc=dev@dpdk.org \
    --cc=thomas@monjalon.net \
    --cc=yliu@fridaylinux.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).