DPDK patches and discussions
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Yuanhan Liu <yliu@fridaylinux.org>
Cc: "Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Ferruh Yigit" <ferruh.yigit@intel.com>,
	dev@dpdk.org
Subject: Re: [dpdk-dev] [PATCH] doc: document the new devargs syntax
Date: Thu, 25 Jan 2018 15:58:11 +0100	[thread overview]
Message-ID: <8785061.Eg1DoYrWuq@xps> (raw)
In-Reply-To: <20180125144142.GA29540@yliu-mob>

25/01/2018 15:41, Yuanhan Liu:
> On Wed, Jan 24, 2018 at 05:57:34PM +0100, Thomas Monjalon wrote:
> > 24/01/2018 16:04, Yuanhan Liu:
> > > On Wed, Jan 24, 2018 at 11:37:31AM +0100, Thomas Monjalon wrote:
> > > > 24/01/2018 11:36, Yuanhan Liu:
> > > > > On Wed, Jan 24, 2018 at 11:21:44AM +0100, Thomas Monjalon wrote:
> > > > > > 24/01/2018 10:28, Yuanhan Liu:
> > > > > > > On Wed, Jan 24, 2018 at 09:19:10AM +0100, Thomas Monjalon wrote:
> > > > > > > > 24/01/2018 07:43, Yuanhan Liu:
> > > > > > > > > On Tue, Jan 23, 2018 at 03:29:34PM +0100, Thomas Monjalon wrote:
> > > > > > > > > > 23/01/2018 13:46, Yuanhan Liu:
> > > > > > > > > > > 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.
> > > > > > > > > > 
> > > > > > > > > > It does not have to be redundant.
> > > > > > > > > > It can be:
> > > > > > > > > > 	bus=pci,id=04:00.0/class=eth,port=0;driver=mlx4,mlx4_arg1=settings1,...
> > > > > > > > > 
> > > > > > > > > I knew you would make such reply :)
> > > > > > > > > Then there is a contradiction. According your suggestion, the "port=0" belongs
> > > > > > > > > to the matching section, but it also has to be used in the settings section.
> > > > > > > > 
> > > > > > > > If port=0 is matched, it is already set, right?
> > > > > > > 
> > > > > > > Yes.
> > > > > > > 
> > > > > > > > Why it needs to be in settings?
> > > > > > > 
> > > > > > > But I was talking the case it's not matched, say it's not probed and here
> > > > > > > we do hotplug.
> > > > > > 
> > > > > > I don't understand.
> > > > > > Anyway, the port property should be read-only.
> > > > > 
> > > > > All proberties should be read-only.
> > > > > 
> > > > > > Are we talking about the dev_port from the Linux kernel?
> > > > > 
> > > > > Yes. And it can be used for probing one port only (out of 2 ports in a NIC)
> > > > > at probe stage. So, at this stage, it's a setting but not a match.
> > > > 
> > > > No it's a match!
> > > > 
> > > > A settings is changing data in the port.
> > > 
> > > So I see that's your definition about the "settings". What I think is
> > > everything needed for driver initiation are settings.
> > > 
> > > For example, one proposed interface for VF rep is the "vf_id" property,
> > > Similar to "port" property we have just discussed above,  it's used for
> > > probing one specific VR rep for the given VF id.
> > > 
> > > You can say it's a match here, just like the "port" property.
> > > 
> > > But note that "vf_id" could be a range, to enable multiple VF reps.
> > > The semantics looks like "setting" more than "match".
> > 
> > Not sure why it would look like settings.
> > 
> > > Another example is from the failsafe PMD that Gaetan had mentioned:
> > > 
> > >     driver=failsafe,dev(bus=pci,id=00:02.0),fd(/some/file/)
> > > 
> > > They (dev and fd) should belong the "setting" section, for 2 reasons:
> > > 
> > > - they should not be used for matching
> > > - they are used for failsafe PMD initiation
> > 
> > Yes these ones are settings.
> > 
> > > But it belongs "match", according to your definition about "settings",
> > > because it doesn't change data in the port.
> > 
> > No, it changes data, dev() is adding a slave, and fd() is adding
> > a file descriptor.
> 
> Then "port" should be settings, as it's used for adding a port.
> Moreover, "vf_id=0-3" is definitely settings (according your definition),
> as it's going to add 4 VF rep ports.

They are properties to identify a device.
Question we should ask is which device is identified by this string?

In the failsafe case, it is different because at first, we identify
the failsafe vdev itself. So the slaves are not part of this.
Slaves id are settings to bind another device to the failsafe.

> > So we agree these are settings.
> > 
> > > That also means, the word "settings" might not be well named. It's
> > > probably better to name it "drvargs".
> > 
> > I disagree. But it's only naming.
> > Settings can be class settings, not only driver settings.
> > And driver properties can be matching or settings.
> > So "drvargs" does not make sense.

  reply	other threads:[~2018-01-25 14:58 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
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 [this message]
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=8785061.Eg1DoYrWuq@xps \
    --to=thomas@monjalon.net \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --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).