From: Yuanhan Liu <yliu@fridaylinux.org>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: Thomas Monjalon <thomas@monjalon.net>,
Stephen Hemminger <stephen@networkplumber.org>,
dev@dpdk.org, Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Ciara Loftus <ciara.loftus@intel.com>,
Kevin Traynor <ktraynor@redhat.com>,
hemant.agrawal@nxp.com
Subject: Re: [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name
Date: Mon, 4 Dec 2017 21:55:31 +0800 [thread overview]
Message-ID: <20171204135531.GB13614@yliu-dev> (raw)
In-Reply-To: <20171201094750.tpsbovk6julcyzrm@bidouze.vm.6wind.com>
On Fri, Dec 01, 2017 at 10:47:50AM +0100, Gaëtan Rivet wrote:
> On Thu, Nov 30, 2017 at 10:44:58PM +0100, Thomas Monjalon wrote:
> > 30/11/2017 22:21, Stephen Hemminger:
> > > On Thu, 30 Nov 2017 18:35:11 +0100
> > > Thomas Monjalon <thomas@monjalon.net> wrote:
> > >
> > > > 30/11/2017 18:15, Stephen Hemminger:
> > > > > Some thoughts.
> > > > > 1) Not all devices are PCI; look at recent VMBUS
> > > >
> > > > Yes, we need a syntax which works for every devices.
> > > > I suggest to use the prefix "pci:" before the PCI id.
> > > > We need also a prefix and ids for NXP buses.
> > > > We could use "vmbus:" before VMBUS ids.
> > > > How VMBUS ids look like?
> > > >
>
> rte_devargs are easily accessible, user-readable. Only thing missing
> would be requiring a 1-1 mapping between an rte_devargs and a port, thus
> requiring PMDs to have at least one version of a device string that
> would probe a single port (as is done with port= in mlx4).
>
> Implementing an rte_devargs to rte_device in rte_bus is simple enough,
> and this would allow implementing an rte_devargs to port_id in rte_eth.
>
> What am I missing?
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.
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.
--yliu
>
> > > > > 2) The name may have to be set before MAC address is determined on boot.
> > > >
> > > > I don't understand this comment.
> > > > Do you mean MAC may be unknown when starting DPDK?
> > >
> > > The MAC be known by the hardware, but the device would have to be
> > > created before using hardware to read it.
> >
> > Indeed, it is a problem if we want to use this syntax for blacklist.
> >
> >
> > > > > 3) The names themselves are not persistent or human friendly. This is hard
> > > > > see the effort udev goes to.
> > > >
> > > > Yes udev has a syntax to identify devices. It can be inspiring.
> > > > Qemu may also be inspiring:
> > > > https://github.com/qemu/qemu/blob/master/docs/qdev-device-use.txt
> >
>
> --
> Gaëtan Rivet
> 6WIND
next prev parent reply other threads:[~2017-12-04 13:55 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 [this message]
2017-12-05 11:04 ` Adrien Mazarguil
2017-12-05 13:20 ` Thomas Monjalon
2017-12-05 13:58 ` Yuanhan Liu
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=20171204135531.GB13614@yliu-dev \
--to=yliu@fridaylinux.org \
--cc=adrien.mazarguil@6wind.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
--cc=hemant.agrawal@nxp.com \
--cc=ktraynor@redhat.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).