From: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
To: Yuanhan Liu <yliu@fridaylinux.org>
Cc: dev@dpdk.org, Thomas Monjalon <thomas@monjalon.net>
Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax
Date: Wed, 17 Jan 2018 11:11:15 +0100 [thread overview]
Message-ID: <20180117101115.o3jl7kmbse3hv5db@bidouze.vm.6wind.com> (raw)
In-Reply-To: <1516114218-21501-1-git-send-email-yliu@fridaylinux.org>
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.
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.
-------------------------------
> +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.
-------------------------------
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?
--
Gaëtan Rivet
6WIND
next prev parent reply other threads:[~2018-01-17 10:11 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 [this message]
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=20180117101115.o3jl7kmbse3hv5db@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).