From: Thomas Monjalon <thomas@monjalon.net>
To: Shreyansh Jain <shreyansh.jain@nxp.com>
Cc: dev@dpdk.org, Yuanhan Liu <yliu@fridaylinux.org>,
Adrien Mazarguil <adrien.mazarguil@6wind.com>,
Ciara Loftus <ciara.loftus@intel.com>,
Kevin Traynor <ktraynor@redhat.com>,
stephen@networkplumber.org, ferruh.yigit@intel.com
Subject: Re: [dpdk-dev] standardize device identification
Date: Fri, 22 Dec 2017 10:00:22 +0100 [thread overview]
Message-ID: <4197715.cXtSenmrem@xps> (raw)
In-Reply-To: <023a90af-bfcd-328d-4ed9-783ee76203fd@nxp.com>
22/12/2017 08:01, Shreyansh Jain:
> On Thursday 21 December 2017 03:32 AM, Thomas Monjalon wrote:
> > Changing the title and adding more comments inline:
> >
> > 19/12/2017 00:05, Thomas Monjalon:
> >> Let's summarize and resume this thread.
> >>
> >> We need a generic syntax to describe a device.
> >> This syntax can be used
> >> - before initializing the device (i.e. whitelist/blacklist)
> >> - or after the initialization (e.g. user config)
> >>
> >> We need to answer 4 questions:
> >> 1/ what are the separators (comma, colon, etc)?
> >> 2/ how to distinguish a device identification from a configuration?
> >> 3/ what are the mandatory parts?
> >> 4/ what can be the optional properties?
> >>
> >> 30/11/2017 08:35, Yuanhan Liu:
> >>> What this patch proposes is to use "name[,mac]" syntax. "name" is the
> >>> PCI id for pci device. For vdev, it's the vdev name given by user. The
> >>> reason "mac" is needed is for some devices (say ConnectX-3), 2 ports
> >>> (in a single NIC) have the same PCI id.
> >>
> >> Based on the feedbacks we had, I suggest a syntax where everything is
> >> optional key/value pairs, and split in 3 categories:
> >> - bus (pci, vdev, vmbus, fslmc, etc)
> >> - class (eth, crypto)
> >> - 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
> >
> >> Between categories, the separator is a slash.
>
> Why is a '/' required as a separator? Are you expecting the key in
> key,value pair to duplicate across categories?
We need to separate categories because each category is parsed by
a different parser.
The first level parser will get strings for each category and will
call the appropriate parser (by going through different levels of
bus parsers for bus and driver categories).
> >> Inside a category, the separator is a comma.
> >> Inside a key/value pair, the separator is an equal sign.
>
> sounds reasonable to me.
>
> >>
> >> It may look like this:
> >> bus=BUS_NAME,id=BUS_ID/class=CLASS_NAME,dev_port=PORT_NUM,mac=MAC_ADDRESS/driver=DRIVER_NAME,driverspecificproperty=VALUE
>
> If I take cue from fslmc and dpaa bus:
>
> for fslmc: bus=fslmc,id=dpni.1
> bus=fslmc,id=dpsec.1
> for dpaa: bus=dpaa,id=fm1-mac1
> bus=dpaa,id=dpaa-sec1
>
> So, at least from fslmc/dpaa perspective, above fits.
>
> Just want to highlight: in some cases the device names can contain ',' -
> but then, that can be handled at bus scan level.
> For dpaa bus, the device identified from platform identifiers contains a
> longer ',' separated string - which is then stripped to form a name like
> 'fm1-mac1' before being added to device->name.
>
> >>
> >> A device is identified when every properties are matched.
>
> So, a ovs-dpdk user would have to know a dpdk bus to identify a device
> to plug into a OVS bridge?
Yes, the user must know the bus if using a bus id.
But he can use another kind of id like the MAC address.
> >> Before device is probed, only the bus category is relevant.
> >> For the simple PCI whitelist, it means moving from
> >> -w 0000:01:00.0
> >> to
> >> -w bus=pci,id=0000:01:00.0
>
> OK
>
> >> It is possible to mix some settings in these devargs syntax if the keys
> >> are differents. Example: mac= is for identification by MAC, whereas
> >> newmac= would be for specifying a MAC address to set.
> >>
> >> Agreement?
>
> in principle, yes.
> just need clarity on '/' as a separator.
Thanks for reviewing.
next prev parent reply other threads:[~2017-12-22 9:00 UTC|newest]
Thread overview: 28+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-11-30 7:35 [dpdk-dev] [PATCH] [RFC] ether: standardize getting the port by name 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
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 [this message]
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=4197715.cXtSenmrem@xps \
--to=thomas@monjalon.net \
--cc=adrien.mazarguil@6wind.com \
--cc=ciara.loftus@intel.com \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@intel.com \
--cc=ktraynor@redhat.com \
--cc=shreyansh.jain@nxp.com \
--cc=stephen@networkplumber.org \
--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).