DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
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 11:54:58 +0100	[thread overview]
Message-ID: <11685797.rhpIizAFUB@xps> (raw)
In-Reply-To: <20180117101115.o3jl7kmbse3hv5db@bidouze.vm.6wind.com>

17/01/2018 11:11, Gaëtan Rivet:
> A new suggestion about the syntax.
> 
> On Tue, Jan 16, 2018 at 10:50:18PM +0800, Yuanhan Liu wrote:
> > This patch documents the new devargs syntax, which is going to be
> > implemented in DPDK v18.05.
> > 
> > The new devargs proposal is introduced for having a consistent
> > interface for:
> > 
> > - whitelisting/blacklisting devices
> > - identifying ports
> > - attaching/detaching devices
> > 
> > Please check the patch content for the details. Also, here is link
> > for the background:
> >     http://dpdk.org/ml/archives/dev/2017-November/082600.html
> > 
> > This syntax is suggestd by Thomas:
> >     http://dpdk.org/ml/archives/dev/2017-December/084234.html
> > 
> > Signed-off-by: Yuanhan Liu <yliu@fridaylinux.org>
> > ---
> >  doc/guides/prog_guide/env_abstraction_layer.rst | 34 +++++++++++++++++++++++++
> >  1 file changed, 34 insertions(+)
> > 
> > diff --git a/doc/guides/prog_guide/env_abstraction_layer.rst b/doc/guides/prog_guide/env_abstraction_layer.rst
> > index 34d871c..12f37f2 100644
> > --- a/doc/guides/prog_guide/env_abstraction_layer.rst
> > +++ b/doc/guides/prog_guide/env_abstraction_layer.rst
> > @@ -213,6 +213,40 @@ device having emitted a Device Removal Event. In such case, calling
> >  callback. Care must be taken not to close the device from the interrupt handler
> >  context. It is necessary to reschedule such closing operation.
> >  
> > +Devargs
> > +~~~~~~~
> > +
> > +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 can also be simple like below::
> > +
> > +    class=eth,mac=00:11:22:33:44:55
> > +
> 
> 1/
> 
> All categories are named, their order is known, and their name comes
> first.

The order of categories is known but some categories may be omitted.

> It is thus possible to declare categories unambiguously without using
> the field name first.
> 
>     pci,id=0000:01:00.0/eth,mac=00:11:22:33:44:55/PMD_NAME,driverspecificproperty=VALUE
>     eth,mac=00:11:22:33:44:55
>     pci,id=00:02.0
> 
> The only requirement for this to hold is for the layer names not to collide
> (bus, dev, drivers), which seems like an easy enough requirement to follow.

I don't like it for 2 reasons:
- it is less explicit
- it is less obvious to dispatch to parsers

> -------------------------------
> 
> > +A device is identified when every properties are matched. Before device is
> > +probed, only the bus category is relevant.
> > + 
> 
> 2/
> 
> When using the following ID:
> 
>     class=eth,mac=00:11:22:33:44:55
> 
> The bus is skipped, as well as the driver.
> Does that mean that it is allowed to skip any layer, as long as the
> resulting match is unambiguous?
> 
> What I mean is that a user could then do
> 
>     driver=net_ring
> 
> To find the one port using the driver net_ring.

I think yes, if there is only one net_ring device.

> -------------------------------
> 
> 3/
> 
> The driver would generate a name for the eth_dev structure.
> I guess it would be possible to identify the device with
> 
>     class=eth,name=net_ring0
> 
> Or something. Where does the rte_dev name appears? Is it a property
> of the bus layer? Is it merged with the eth_dev name? If so, which one
> will stay, the rte_dev name or the eth_dev name?

EAL device and ethdev are different layers.
There is no 1:1 mapping.
So both must stay.
rte_dev name should be a property of the bus layer.

  reply	other threads:[~2018-01-17 10:55 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
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 [this message]
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=11685797.rhpIizAFUB@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --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).