All of lore.kernel.org
 help / color / mirror / Atom feed
From: Finn Christensen <fc@napatech.com>
To: Thomas Monjalon <thomas@monjalon.net>, "dev@dpdk.org" <dev@dpdk.org>
Cc: 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" <stephen@networkplumber.org>,
	"ferruh.yigit@intel.com" <ferruh.yigit@intel.com>
Subject: Re: standardize device identification
Date: Fri, 5 Jan 2018 07:52:14 +0000	[thread overview]
Message-ID: <cdaa0102074d4b15afe5be06ed577192@napatech.com> (raw)
In-Reply-To: <7044959.u7szEIarlR@xps>

    -----Original Message-----
    From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Thomas
    Monjalon
    Sent: 20. december 2017 23:03
    To: dev@dpdk.org
    Cc: 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
    
    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.
    > Inside a category, the separator is a comma.
    > Inside a key/value pair, the separator is an equal sign.
    >
    > It may look like this:
    >
    bus=BUS_NAME,id=BUS_ID/class=CLASS_NAME,dev_port=PORT_NUM,m
    ac=MAC_ADDR
    > ESS/driver=DRIVER_NAME,driverspecificproperty=VALUE
    >
    > A device is identified when every properties are matched.
    > 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
    >
    > 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?
    
 
We also need to distinguish between multiple ports sitting on same PCI bus ID.
and from our point of view, this will fully cover our needs.
Thanks - great proposal.

Regards,
Finn Christensen, Napatech


    Yuanhan is proposing to use this syntax in OVS option dpdk-devargs:
    https://mail.openvswitch.org/pipermail/ovs-dev/2017-
    December/342273.html
    
    Please, any feedback or approval that this syntax is good?

  parent reply	other threads:[~2018-01-05  7:52 UTC|newest]

Thread overview: 28+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2017-11-30  7:35 [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   ` 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 [this message]
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 ` [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=cdaa0102074d4b15afe5be06ed577192@napatech.com \
    --to=fc@napatech.com \
    --cc=adrien.mazarguil@6wind.com \
    --cc=ciara.loftus@intel.com \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@intel.com \
    --cc=ktraynor@redhat.com \
    --cc=stephen@networkplumber.org \
    --cc=thomas@monjalon.net \
    --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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.