From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: dev@dpdk.org, arybchenko@solarflare.com
Subject: Re: [dpdk-dev] [PATCH v2 07/13] ethdev: add device matching field name
Date: Fri, 21 Sep 2018 15:06:48 +0200 [thread overview]
Message-ID: <4913069.0xk8QlEqK7@xps> (raw)
In-Reply-To: <20180921121621.rjo7esvng7gjuri4@bidouze.vm.6wind.com>
21/09/2018 14:16, Gaëtan Rivet:
> On Thu, Sep 20, 2018 at 06:17:13PM +0200, Thomas Monjalon wrote:
> > 19/09/2018 18:03, Gaetan Rivet:
> > > The eth device class can now parse a field name,
> > > matching the eth_dev name with one passed as
> > >
> > > "class=eth,name=xxxxxx"
> >
> > I am not sure what is the purpose of the "name" property.
> > I think we should not need it to choose a port by its ethdev name.
>
> rte_eth_dev_get_port_by_name seems pretty close.
Exact, this function already exists to get a port id by name.
I think we should discourage the use of ethdev "internal" name.
The point of the devargs is to match device with explicit known properties.
> Which fields do you think should be proposed first as a getter on the eth class?
> Or do you have a list of fields the eth class should be restricted to?
In other words, which ethdev properties can help to match a port?
I think about "mac=" (which is already implemented in OVS devargs),
and "representor=" (which requires a new field in ethdev).
About representors, we could also match all representor ports of a switch
(see rte_eth_switch_info).
We could also have a property for the kernel netdev we are (or were) bound.
Does it make sense?
> > If you are thinking about a vdev, we can use the rte_device name (at bus level).
>
> This patch is only about eth class, it has no impact on buses.
So we agree :)
next prev parent reply other threads:[~2018-09-21 13:06 UTC|newest]
Thread overview: 47+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-30 13:41 [dpdk-dev] [PATCH v1 00/13] Implement new devargs framework Gaetan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 01/13] bus/pci: implement device iteration and comparison Gaetan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 02/13] bus/pci: add device matching field id Gaetan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 03/13] bus/vdev: implement device iteration Gaetan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 04/13] bus/vdev: add device matching field driver Gaetan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 05/13] ethdev: add private generic device iterator Gaetan Rivet
2018-08-31 10:09 ` Andrew Rybchenko
2018-08-31 10:22 ` Gaëtan Rivet
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 06/13] ethdev: register ether layer as a class Gaetan Rivet
2018-08-31 10:09 ` Andrew Rybchenko
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 07/13] ethdev: add device matching field name Gaetan Rivet
2018-08-31 10:10 ` Andrew Rybchenko
2018-08-30 13:41 ` [dpdk-dev] [PATCH v1 08/13] app/testpmd: add show device command Gaetan Rivet
2018-08-30 13:42 ` [dpdk-dev] [PATCH v1 09/13] bus/pci: pre-process declarative PCI devargs Gaetan Rivet
2018-08-30 13:42 ` [dpdk-dev] [PATCH v1 10/13] bus/vdev: pre-process declarative vdev devargs Gaetan Rivet
2018-08-30 13:42 ` [dpdk-dev] [PATCH v1 11/13] bus/pci: process declarative PCI devargs Gaetan Rivet
2018-08-30 16:15 ` Stephen Hemminger
2018-08-30 16:37 ` Gaëtan Rivet
2018-08-30 13:42 ` [dpdk-dev] [PATCH v1 12/13] ethdev: process declarative eth devargs Gaetan Rivet
2018-08-31 10:10 ` Andrew Rybchenko
2018-08-31 12:16 ` Gaëtan Rivet
2018-08-30 13:42 ` [dpdk-dev] [PATCH v1 13/13] eal: add generic dev parameter Gaetan Rivet
2018-08-30 15:42 ` [dpdk-dev] [PATCH v1 00/13] Implement new devargs framework Stephen Hemminger
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 " Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 01/13] bus/pci: implement device iteration and comparison Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 02/13] bus/pci: add device matching field id Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 03/13] bus/vdev: implement device iteration Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 04/13] bus/vdev: add device matching field driver Gaetan Rivet
2018-09-20 16:11 ` Thomas Monjalon
2018-09-21 11:53 ` Gaëtan Rivet
2018-09-21 12:55 ` Thomas Monjalon
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 05/13] ethdev: add private generic device iterator Gaetan Rivet
2018-09-20 10:02 ` Andrew Rybchenko
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 06/13] ethdev: register ether layer as a class Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 07/13] ethdev: add device matching field name Gaetan Rivet
2018-09-20 16:17 ` Thomas Monjalon
2018-09-21 12:16 ` Gaëtan Rivet
2018-09-21 13:06 ` Thomas Monjalon [this message]
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 08/13] app/testpmd: add show device command Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 09/13] bus/pci: pre-process declarative PCI devargs Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 10/13] bus/vdev: pre-process declarative vdev devargs Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 11/13] bus/pci: process declarative PCI devargs Gaetan Rivet
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 12/13] ethdev: process declarative eth devargs Gaetan Rivet
2018-09-20 10:11 ` Andrew Rybchenko
2018-09-19 16:03 ` [dpdk-dev] [PATCH v2 13/13] eal: add generic dev parameter Gaetan Rivet
2018-10-03 12:31 ` [dpdk-dev] [PATCH v2 00/13] Implement new devargs framework Thomas Monjalon
2020-02-19 5:43 ` Pavan Nikhilesh Bhagavatula
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=4913069.0xk8QlEqK7@xps \
--to=thomas@monjalon.net \
--cc=arybchenko@solarflare.com \
--cc=dev@dpdk.org \
--cc=gaetan.rivet@6wind.com \
/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).