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 531CE42BF0; Mon, 5 Jun 2023 16:10:57 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id DA4384021F; Mon, 5 Jun 2023 16:10:56 +0200 (CEST) Received: from out2-smtp.messagingengine.com (out2-smtp.messagingengine.com [66.111.4.26]) by mails.dpdk.org (Postfix) with ESMTP id 0117F4003C for ; Mon, 5 Jun 2023 16:10:54 +0200 (CEST) Received: from compute5.internal (compute5.nyi.internal [10.202.2.45]) by mailout.nyi.internal (Postfix) with ESMTP id 753AF5C01F0; Mon, 5 Jun 2023 10:10:54 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute5.internal (MEProxy); Mon, 05 Jun 2023 10:10:54 -0400 DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h= cc:cc:content-transfer-encoding:content-type:content-type:date :date:from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to; s=fm1; t= 1685974254; x=1686060654; bh=pTvD0tt8T9FH9tf8+c06TcDy9OlSmGeRwlT 19cPJ/L8=; b=peZPh9h0w2HOXX0n2s5ZYU4OgK37CVl/uBflDFi+m9k97DVkPQq l+9mjMsjF9dHLPgsoFlz1mk/DJgXTZjBImypQPitlbgplffhrGcl0HiUTsQFA9vh 4sE8im43HRd05oa6H6Jyi6362utn5PefqkgHqY0wBpcnNdIb75Qi/v2MuCTk9LOQ MtJc8v2bHIiPVLpsD6oPrfm1NSDj4zEXtLj6lkXMQYEeKftPBQuwQJRI5rByAGSq 4avpBvQwsBVlDbNTJuhtjY81EIlqir6PcoM5A3/lUiP6L8uRh//EI938AoNlxGnm VkElO/ezLFONq0vecWcJXaUpMPpwcl4iifw== DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d= messagingengine.com; h=cc:cc:content-transfer-encoding :content-type:content-type:date:date:feedback-id:feedback-id :from:from:in-reply-to:in-reply-to:message-id:mime-version :references:reply-to:sender:subject:subject:to:to:x-me-proxy :x-me-proxy:x-me-sender:x-me-sender:x-sasl-enc; s=fm1; t= 1685974254; x=1686060654; bh=pTvD0tt8T9FH9tf8+c06TcDy9OlSmGeRwlT 19cPJ/L8=; b=jw24DQyrGR3u7zfHhi5zxO5pZdYF4hZCnVoheMOoFYepgcUQjEo RMqOWPkGapUWv5EeVP/n7hCoFdPaaL5jFMP8T9v2egodeHQerZu8xexU24xqE7WH Ep5ECIrn3RrgxrmVLFo/WnO1gzCSfQes1KDIEbYjDZiUgSHGCr7Pzfor7PujU33l xC5N6f8lTX778UdOI37U9JSYaAPXycaOudsaZ5eZVg0RKTUBmqdomx1+/TYJWrlS s0MyGo4eo8pA8iVIeoqTbJQdVFH71ED9xo5FIWw5UIGa29VsUAHmSuonsSzD3b3X PsIupbtcKRwOEQ72AEPNA67X+j07wXg6OqA== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelledgjeegucetufdoteggodetrfdotf fvucfrrhhofhhilhgvmecuhfgrshhtofgrihhlpdfqfgfvpdfurfetoffkrfgpnffqhgen uceurghilhhouhhtmecufedttdenucesvcftvggtihhpihgvnhhtshculddquddttddmne cujfgurhephffvvefufffkjghfggfgtgesthfuredttddtvdenucfhrhhomhepvfhhohhm rghsucfoohhnjhgrlhhonhcuoehthhhomhgrshesmhhonhhjrghlohhnrdhnvghtqeenuc ggtffrrghtthgvrhhnpedtjeeiieefhedtfffgvdelteeufeefheeujefgueetfedttdei kefgkeduhedtgfenucevlhhushhtvghrufhiiigvpedtnecurfgrrhgrmhepmhgrihhlfh hrohhmpehthhhomhgrshesmhhonhhjrghlohhnrdhnvght X-ME-Proxy: Feedback-ID: i47234305:Fastmail Received: by mail.messagingengine.com (Postfix) with ESMTPA; Mon, 5 Jun 2023 10:10:53 -0400 (EDT) From: Thomas Monjalon To: Ivan Malov Cc: dev@dpdk.org, Andrei Izrailev , Ferruh Yigit Subject: Re: Getting network port ID by ethdev port ID Date: Mon, 05 Jun 2023 16:10:52 +0200 Message-ID: <19381599.sIn9rWBj0N@thomas> In-Reply-To: References: <5020360.e8TTKsaY2g@thomas> MIME-Version: 1.0 Content-Transfer-Encoding: 7Bit Content-Type: text/plain; charset="us-ascii" 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 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. > > 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.