From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mails.dpdk.org (mails.dpdk.org [217.70.189.124]) by inbox.dpdk.org (Postfix) with ESMTP id 5E51542BF0; Mon, 5 Jun 2023 16:29:41 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DB1764021F; Mon, 5 Jun 2023 16:29:40 +0200 (CEST) Received: from agw.arknetworks.am (agw.arknetworks.am [79.141.165.80]) by mails.dpdk.org (Postfix) with ESMTP id ED9BD4003C for ; Mon, 5 Jun 2023 16:29:39 +0200 (CEST) Received: from debian (unknown [78.109.69.189]) (using TLSv1.3 with cipher TLS_AES_256_GCM_SHA384 (256/256 bits) key-exchange X25519 server-signature RSA-PSS (2048 bits) server-digest SHA256) (No client certificate requested) by agw.arknetworks.am (Postfix) with ESMTPSA id 39C75E0E15; Mon, 5 Jun 2023 18:29:39 +0400 (+04) Date: Mon, 5 Jun 2023 18:29:46 +0400 (+04) From: Ivan Malov To: Thomas Monjalon cc: dev@dpdk.org, Andrei Izrailev , Ferruh Yigit Subject: Re: Getting network port ID by ethdev port ID In-Reply-To: <19381599.sIn9rWBj0N@thomas> Message-ID: References: <5020360.e8TTKsaY2g@thomas> <19381599.sIn9rWBj0N@thomas> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII; format=flowed X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.29 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org 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//phys_port_name >>>>> /sys/class/net//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. > >>> Feel free to make a global status of device names. >>> >> Could you please elaborate on this? > > I thought you wanted to have device name in all device classes. > > >