All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: "Gaëtan Rivet" <gaetan.rivet@6wind.com>
Cc: dev@dpdk.org, arybchenko@solarflare.com
Subject: Re: [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 :)

  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 [PATCH v1 00/13] Implement new devargs framework Gaetan Rivet
2018-08-30 13:41 ` [PATCH v1 01/13] bus/pci: implement device iteration and comparison Gaetan Rivet
2018-08-30 13:41 ` [PATCH v1 02/13] bus/pci: add device matching field id Gaetan Rivet
2018-08-30 13:41 ` [PATCH v1 03/13] bus/vdev: implement device iteration Gaetan Rivet
2018-08-30 13:41 ` [PATCH v1 04/13] bus/vdev: add device matching field driver Gaetan Rivet
2018-08-30 13:41 ` [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 ` [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 ` [PATCH v1 07/13] ethdev: add device matching field name Gaetan Rivet
2018-08-31 10:10   ` Andrew Rybchenko
2018-08-30 13:41 ` [PATCH v1 08/13] app/testpmd: add show device command Gaetan Rivet
2018-08-30 13:42 ` [PATCH v1 09/13] bus/pci: pre-process declarative PCI devargs Gaetan Rivet
2018-08-30 13:42 ` [PATCH v1 10/13] bus/vdev: pre-process declarative vdev devargs Gaetan Rivet
2018-08-30 13:42 ` [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 ` [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 ` [PATCH v1 13/13] eal: add generic dev parameter Gaetan Rivet
2018-08-30 15:42 ` [PATCH v1 00/13] Implement new devargs framework Stephen Hemminger
2018-09-19 16:03 ` [PATCH v2 " Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 01/13] bus/pci: implement device iteration and comparison Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 02/13] bus/pci: add device matching field id Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 03/13] bus/vdev: implement device iteration Gaetan Rivet
2018-09-19 16:03   ` [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   ` [PATCH v2 05/13] ethdev: add private generic device iterator Gaetan Rivet
2018-09-20 10:02     ` Andrew Rybchenko
2018-09-19 16:03   ` [PATCH v2 06/13] ethdev: register ether layer as a class Gaetan Rivet
2018-09-19 16:03   ` [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   ` [PATCH v2 08/13] app/testpmd: add show device command Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 09/13] bus/pci: pre-process declarative PCI devargs Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 10/13] bus/vdev: pre-process declarative vdev devargs Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 11/13] bus/pci: process declarative PCI devargs Gaetan Rivet
2018-09-19 16:03   ` [PATCH v2 12/13] ethdev: process declarative eth devargs Gaetan Rivet
2018-09-20 10:11     ` Andrew Rybchenko
2018-09-19 16:03   ` [PATCH v2 13/13] eal: add generic dev parameter Gaetan Rivet
2018-10-03 12:31   ` [PATCH v2 00/13] Implement new devargs framework Thomas Monjalon
2020-02-19  5:43     ` [dpdk-dev] " 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 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.