All of lore.kernel.org
 help / color / mirror / Atom feed
From: Thomas Monjalon <thomas@monjalon.net>
To: Ivan Malov <ivan.malov@arknetworks.am>
Cc: dev@dpdk.org, Andrei Izrailev <Andrei.Izrailev@arknetworks.am>,
	Ferruh Yigit <ferruh.yigit@amd.com>
Subject: Re: Getting network port ID by ethdev port ID
Date: Mon, 05 Jun 2023 16:10:52 +0200	[thread overview]
Message-ID: <19381599.sIn9rWBj0N@thomas> (raw)
In-Reply-To: <ee956844-8b17-f525-d62b-c447867c7e15@arknetworks.am>

05/06/2023 16:03, Ivan Malov:
> Hi Thomas,
> 
> Thanks for responding. Please see below.
> 
> On Mon, 5 Jun 2023, Thomas Monjalon wrote:
> 
> > Hello,
> >
> > 05/06/2023 15:09, Ivan Malov:
> >> Dear community,
> >>
> >> Is there any means in DPDK to discover relationship between
> >> network/physical ports of the given adapter/board and
> >> etdevs deployed in DPDK application on top of it?
> >>
> >> For example, in Linux, there are facilities like
> >>
> >>> /sys/class/net/<iface>/phys_port_name
> >>> /sys/class/net/<iface>/dev_port
> >>
> >> and
> >>
> >>> devlink port show
> >>
> >> Do we have something similar in DPDK?
> >
> > We can get the device name of a port:
> > 	rte_eth_dev_get_name_by_port()
> 
> I'm afraid this won't do. Consider the following example.
> Say, there's a NIC with two network ports and two PFs,
> 0000:01:00.0 and 0000:01:00.1. The user plugs these
> PFs to DPDK application. The resulting ethdev IDs
> are 0 and 1. If the user invokes the said API,
> they will get 0000:01:00.0 and 0000:01:00.1.
> But that's not what is really needed.
> 
> We seek a means to get the network port ID by
> ethdev ID. For example, something like this:
> - get_netport_by_ethdev(0) => 0
> - get_netport_by_ethdev(1) => 1
> 
> If two different PCI functions are associated with the
> same network port (0, for instance), this should be
> - get_netport_by_ethdev(0) => 0
> - get_netport_by_ethdev(1) => 0
> 
> Do we have something like that in DPDK?

No we don't have such underlying index.
I don't understand why it is needed.
To me the name is more informative than a number.


> >> If no, would the feature be worthwhile implementing?
> >
> > We may have discrepancies in different device classes.
> 
> I mean precisely "ethdev"s. I do realise, though, that
> an ethdev may be backed by a vdev (af_xdp, etc.) = in
> such cases the assumed "get_netport" method could
> just return (-ENOTSUP). What do you think?

Are you interested only in PCI devices? Looks limited.

> > Feel free to make a global status of device names.
> >
> Could you please elaborate on this?

I thought you wanted to have device name in all device classes.



  reply	other threads:[~2023-06-05 14:10 UTC|newest]

Thread overview: 13+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2023-06-05 13:09 Getting network port ID by ethdev port ID Ivan Malov
2023-06-05 13:40 ` Thomas Monjalon
2023-06-05 14:03   ` Ivan Malov
2023-06-05 14:10     ` Thomas Monjalon [this message]
2023-06-05 14:17       ` Ivan Malov
2023-06-05 14:29       ` Ivan Malov
2023-06-05 16:03         ` Thomas Monjalon
2023-06-05 18:50           ` Stephen Hemminger
2023-06-05 20:30             ` Ivan Malov
2023-06-05 22:39               ` Stephen Hemminger
2023-06-06  7:16                 ` Ivan Malov
2023-06-06 15:32                   ` Stephen Hemminger
2023-06-06  8:41               ` 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=19381599.sIn9rWBj0N@thomas \
    --to=thomas@monjalon.net \
    --cc=Andrei.Izrailev@arknetworks.am \
    --cc=dev@dpdk.org \
    --cc=ferruh.yigit@amd.com \
    --cc=ivan.malov@arknetworks.am \
    /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.