Re: Getting network port ID by ethdev port ID

[Stephen Hemminger <stephen@networkplumber.org>]

On Mon, 05 Jun 2023 18:03:14 +0200
Thomas Monjalon <thomas@monjalon.net> wrote:

> 05/06/2023 16:29, Ivan Malov:
> > Sorry, I missed your question. See below.
> > 
> > On Mon, 5 Jun 2023, Thomas Monjalon wrote:
> >   
> > > 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.  
> > 
> > Theoretically, even a vdev may handle this request
> > appropriately. For example, a failsafe device may
> > ask its current underlying PCI device abot the
> > physical port ID in use. For af_xdp and the
> > likes, it's also possible. The PMD may
> > query sysfs to provide the value.
> > 
> > Strictly speaking, it's not limited, but the primary
> > use case is querying the phys. port ID for PFs, yes.
> > 
> > This information may be needed by some applications
> > that not only operate the higher-level ethdevs but
> > also take the real physical/wire interconnects
> > into account. It might be complex to explain
> > in a single email thread, though.
> > 
> > Previously, DPDK even used to have a flow action PHY_PORT.
> > Yes, it has been deprecated, but that's not a problem.
> > The information can be useful anyway.  
> 
> In this case, this is something the driver should fill in rte_eth_dev_info.
> Note that we already have rte_eth_dev_info::if_index but it looks different.
> 
> Who would be responsible of the numbering of the physical port?
> Should we report kernel numbering or do we need yet another numbering scheme?

Very few DPDK hardware devices support multiple ports on same card.
And only a couple of devices (like Mellanox/Nvidia) use a kernel driver component.