DPDK patches and discussions
 help / color / mirror / Atom feed
From: Yuanhan Liu <yliu@fridaylinux.org>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Thomas Monjalon" <thomas@monjalon.net>
Cc: Ferruh Yigit <ferruh.yigit@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax
Date: Tue, 23 Jan 2018 20:46:02 +0800	[thread overview]
Message-ID: <20180123124602.GS29540@yliu-mob> (raw)
In-Reply-To: <20180118094623.gu5ahrfd75b5gcct@bidouze.vm.6wind.com>

On Thu, Jan 18, 2018 at 10:46:23AM +0100, Gaëtan Rivet wrote:
> On Thu, Jan 18, 2018 at 09:46:29AM +0100, Thomas Monjalon wrote:
> > 18/01/2018 08:35, Yuanhan Liu:
> > > On Wed, Jan 17, 2018 at 12:34:08PM +0000, Ferruh Yigit wrote:
> > > > So does it make sense to separate them logically? Perhaps as "device identifier"
> > > > and "device args".
> > > 
> > > Then I think it returns back to the old issue: how could we identify a
> > > port when the bus id (say BDF for PCI bus) is not enough for identifying
> > > a port? Such case could happen when a single NIC has 2 ports sharing
> > > the same BDF. It could also happen with the VF representors that will
> > > be introduced shortly.
> > 
> > Yes, the device matching syntax must include bus category, class category
> > and driver category. So any device can be identified in future.
> > 
> > But I think Ferruh is talking about separating device matching
> > (which is described in this proposal) and device settings
> > (which are usually mixed in -w and --vdev options).
> > I agree there are different things and may be separate.
> > They could share the same syntax (bus/class/driver) but be separate
> > with a semicolon:
> > 	matching;settings
>
> Can you give an example?

Let's take port addition in OVS-DPDK as an example. It happens in 2
steps:
- port lookup (if port is already probed)
- dev attachment (if lookup fails)

And also let's assume we need probe a ConnectX-3 port. Note that for
ConnectX-3, there are 2 ports sharing the same PCI addr. Thus, PCI
BDF is not enough. And let's assume we use another extra property
"port".

If the proposal described in this patch is being used, the devarg
would look like following:

    bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,...

Then "bus=pci,id=04:00.0/class=eth,port=0" will be used for lookup,
It means we are looking for a port with PCI BDF == 04:00.0 AND
port == 0 (the first port of the 2 ports).

Note that in my proposal the driver category is not intended for lookup.
If any properties needed be looked in the driver category, they would
probably need be elevated to the class category.

If port not found, then the whole string will be used for dev attachment.
It means we are attaching a port with PCI BDF == 04.00.0 AND
port == 0 (the 2nd port will not be attached).


And here is how the devargs would look like if "matching;settings" is
being used:

    bus=pci,id=04:00.0/class=eth,port=0;bus=pci,id=04:00.0/class=eth,port=0/driver=mlx4,mlx4_arg_A=val,...

The part before ";" will be used for lookup and the later part will be
used for attachment. It should work. It just looks redundant.

	-yliu

  reply	other threads:[~2018-01-23 12: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
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 [this message]
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=20180123124602.GS29540@yliu-mob \
    --to=yliu@fridaylinux.org \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=gaetan.rivet@6wind.com \
    --cc=thomas@monjalon.net \
    /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).