From: Stephen Hemminger <stephen@networkplumber.org>
To: Ivan Malov <ivan.malov@arknetworks.am>
Cc: Thomas Monjalon <thomas@monjalon.net>,
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: Tue, 6 Jun 2023 08:32:06 -0700 [thread overview]
Message-ID: <20230606083206.7ff84ecf@hermes.local> (raw)
In-Reply-To: <9283e499-fc1a-2e68-8b3f-ba6d2e340b5@arknetworks.am>
On Tue, 6 Jun 2023 11:16:21 +0400 (+04)
Ivan Malov <ivan.malov@arknetworks.am> wrote:
> In general, I agree that there might not be too many vendors
> that provide multi-port adapters. But in what comes to
> bifurcated model = I'm not sure that I understand why
> we confine our discussion to it. What I mean is not
> Linux interface IDs. I mean enumerating physical
> ports on the network card and providing mappings
> to the application, like "physical port 0 maps
> to PF 0". My hunch is that this information
> can be available in vendors that do not use
> the bifurcated model; they might be able to
> retrieve it from their internals just like
> any other aspect of card configuration.
>
> When you suggest that I stick with using PCI information, do
> you mean precisely "/sys/class/net/<iface>/dev_port" et al?
> If yes, unfortunately, it seems like these fields are not
> filled the same way for different vendors, sometimes they
> aren't supported at all. So, I'm not pushing to add such
> means to DPDK, but it might be useful to applications.
I meant look in /sys/devices/pci0000:00/0000:00:01.1/ etc.
But after looking deeper, it gets messy, so probably does need to be in
EAL to handle FreeBSD and Windows.
There is a multitude of different values possible.
- acpi_index - which comes from BIOS
- dev_port - only available if device has multiple ports
- pci_slot - comes from hotplug
- dev_id - old kernels with ipoib
These all do not depend on a bifurcated driver. All devices even
dedicated ones will have this. Probably more likely to see a dual
port dedicated NIC.
If some one makes a new API (rte_ethdev_slot_info_get)? it could
provide both slot and port in slot information.
next prev parent reply other threads:[~2023-06-06 15:32 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-06-05 13:09 Ivan Malov
2023-06-05 13:40 ` Thomas Monjalon
2023-06-05 14:03 ` Ivan Malov
2023-06-05 14:10 ` Thomas Monjalon
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 [this message]
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=20230606083206.7ff84ecf@hermes.local \
--to=stephen@networkplumber.org \
--cc=Andrei.Izrailev@arknetworks.am \
--cc=dev@dpdk.org \
--cc=ferruh.yigit@amd.com \
--cc=ivan.malov@arknetworks.am \
--cc=thomas@monjalon.net \
/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).