On Mon, 05 Jun 2023 18:03:14 +0200 Thomas Monjalon <tho...@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.
