DPDK patches and discussions
 help / color / mirror / Atom feed
From: Yuanhan Liu <yliu@fridaylinux.org>
To: Thomas Monjalon <thomas@monjalon.net>
Cc: "Adrien Mazarguil" <adrien.mazarguil@6wind.com>,
	"Gaëtan Rivet" <gaetan.rivet@6wind.com>,
	"Stephen Hemminger" <stephen@networkplumber.org>,
	dev@dpdk.org, "Ciara Loftus" <ciara.loftus@intel.com>,
	"Kevin Traynor" <ktraynor@redhat.com>,
	hemant.agrawal@nxp.com,
	"Mohammad Abdul Awal" <mohammad.abdul.awal@intel.com>,
	"Declan Doherty" <declan.doherty@intel.com>
Subject: Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name
Date: Tue, 5 Dec 2017 21:58:31 +0800	[thread overview]
Message-ID: <20171205135831.GC9111@yliu-dev> (raw)
In-Reply-To: <4433948.XFY0rnHxgs@xps>

On Tue, Dec 05, 2017 at 02:20:05PM +0100, Thomas Monjalon wrote:
> 05/12/2017 12:04, Adrien Mazarguil:
> 
> > Hi Yuanhan,
> 
> >
> 
> > On Mon, Dec 04, 2017 at 09:55:31PM +0800, Yuanhan Liu wrote:
> > > rte_devargs is identified by the name (pci id for pci device). It also
> > > includes other driver specific key-value options. It's not clear for the
> > > user to know which one (or few) of them should be used together with the
> > > PCI id to identify a specific port. For example, as you mentioned, in
> > > mlx4, it's "pci_id,port=x". It could be something else in other drivers.
> 
> > Just for information, this "port=x" argument in mlx4 is consistent with the
> > value found in /sys/class/net/ethX/dev_port under Linux. If we choose to use
> > a port index (instead of a MAC or something else), it would make sense to
> > standardize it on the same order as given by the host OS for consistency
> > across all PMDs.

Thanks for the info.

But FYI, for most of other PMDs, such sys file won't exist, as the host
driver should have been unbind and bind with something like uio. So I
don't think it applies to all other nics.

> 
> Good idea, thanks.
> 
>  
> 
> I think we will MAC in some cases and port number in others.

Could you list some examples?

> It is important to have identifiers available even without initializing
> the device.

I don't object that. I think that's good for whitelisting/blacklisting
before the device initialization. However, once the initialization is
done, everything could be used to identify a port (say, the mac this patch
mentioned).

> > Devices with a single port per PCI address would simply use/allow "0".

Yes.

> >
> 
> > > Actually, this patch also proposes a devarg like naming style: "name[,mac]
> ".
> > > What it does try to do is to define a standard syntax, so that the user
> > > doesn't have to know any driver specific options.
> > >
> > > However, the mac address is changeable, leaving this naming inconsistent.
> > > Well, in practice, PCI id is also changeable.
> 
> > >
> 
> > > OTOH, having a consistent naming seems a bit far away from this patch's
> > > goal: define a standard ethdev naming and leave less harassment to the
> users.
> 
> >
> 
> > I'm not a fan of the MAC naming scheme either, a kind of per-device physical
> > port index seems more robust and doesn't require much initialization to
> > determine how many ports are supported by the device and whether the index is
> > known/valid (particularly given the vast majority exposes only one per bus
> > address).

I'm not a fan of the MAC naming, neither. The reason this patch proposes mac
naming is that it's more clear for the user to specify a port. I also agree
that the port index could be another good option.

One thing I really haven't considered yet is how it becomes when the VF
reprenstor comes to play? (more guys are cc'ed).

> > Would it make sense to have this name usable unmodified as a valid device
> > (-w) argument, including parameters?
> 
> Yes we must provide some new key/value arguments for devargs.
> So it can be used anywhere, including -w/-b options in DPDK
> or port configuration in OVS.
>  
> 
> > If so, PMDs could append parameters while probing the underlying device, by
> > appending ",port=x", ",mac=x" followed by other unspecified parameters with
> > default values. This could uniquely identify the port _and_ its
> > configuration in a reusable fashion.
> 
>  
> 
> Question: should we separate device identification and configuration
> in the syntax?

Yes, we should. I think we should parse the identification generically,
and leave the left to the driver.

> > Otherwise if all we need is unique names, we can use the opposite and much
> > simpler approach. Let librte_ether assign them sequentially
> > (e.g. "rte_eth%d", no need for consistency with OS netdevices), applications
> > can figure the rest based on data structures if needed.
> 
> No, unique names are not useful / not usable by users.

Agree. We don't really need another unique name, since the port id is
already unique.

However, I think a consistent naming might be useful: user doesn't have
to worry it even though MAC is changed or the PCI slot is changed.

	--yliu

  reply	other threads:[~2017-12-05 13:58 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-30  7:35 Yuanhan Liu
2017-11-30 17:15 ` Stephen Hemminger
2017-11-30 17:35   ` Thomas Monjalon
2017-11-30 21:21     ` Stephen Hemminger
2017-11-30 21:44       ` Thomas Monjalon
2017-12-01  9:47         ` Gaëtan Rivet
2017-12-04 13:55           ` Yuanhan Liu
2017-12-05 11:04             ` Adrien Mazarguil
2017-12-05 13:20               ` Thomas Monjalon
2017-12-05 13:58                 ` Yuanhan Liu [this message]
2017-12-05 15:28                   ` Thomas Monjalon
2017-12-05 17:22                     ` Adrien Mazarguil
2017-12-06 15:49                       ` Yuanhan Liu
2017-12-18 22:25                 ` Thomas Monjalon
2017-12-18 22:30                   ` Stephen Hemminger
2017-12-18 22:41                     ` Thomas Monjalon
2017-12-18 23:05 ` Thomas Monjalon
2017-12-20 22:02   ` [dpdk-dev] standardize device identification Thomas Monjalon
2017-12-22  7:01     ` Shreyansh Jain
2017-12-22  9:00       ` Thomas Monjalon
2018-01-05  7:52     ` Finn Christensen
2018-01-05  8:39       ` Thomas Monjalon
2018-01-05 11:09         ` Finn Christensen
2018-01-05 12:01           ` Thomas Monjalon
2018-01-05 14:14             ` Finn Christensen
2018-01-05 15:34               ` Thomas Monjalon
2018-01-05 20:32                 ` Finn Christensen
2018-01-16 20:20 ` [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name Ferruh Yigit

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=20171205135831.GC9111@yliu-dev \
    --to=yliu@fridaylinux.org \
    --cc=adrien.mazarguil@6wind.com \
    --cc=ciara.loftus@intel.com \
    --cc=declan.doherty@intel.com \
    --cc=dev@dpdk.org \
    --cc=gaetan.rivet@6wind.com \
    --cc=hemant.agrawal@nxp.com \
    --cc=ktraynor@redhat.com \
    --cc=mohammad.abdul.awal@intel.com \
    --cc=stephen@networkplumber.org \
    --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).