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?
