DPDK patches and discussions
 help / color / mirror / Atom feed
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.


  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).