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 D0BC442BF1; Mon, 5 Jun 2023 18:03:21 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 620A04021F; Mon, 5 Jun 2023 18:03:21 +0200 (CEST) Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by mails.dpdk.org (Postfix) with ESMTP id 11F354003C for ; Mon, 5 Jun 2023 18:03:20 +0200 (CEST) Received: from compute2.internal (compute2.nyi.internal [10.202.2.46]) by mailout.nyi.internal (Postfix) with ESMTP id 71F825C005F; Mon, 5 Jun 2023 12:03:17 -0400 (EDT) Received: from mailfrontend2 ([10.202.2.163]) by compute2.internal (MEProxy); Mon, 05 Jun 2023 12:03:17 -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= 1685980997; x=1686067397; bh=Ae5kqkzReW1dh8nzDIusoqcvD/9Mm/gwUPE Y2SU59AY=; b=3b3TAXFbagjQ9J9YF5nlLxlYOZVKgMS2PN4XGF5cWLhtxQCK0wz AMEUjsOB1aXEW57RWQOwj79Mw3VXEZkXuNK0ZQq3APN8Z8xkCmzyDxmzwPyCTOqx PRenLv3ikfurZuvy7COpQqZ8so7F4MOlpmgJgmiRDjuLlfYLRaRqHinVcyTU3Qnn KwWtXzzZDZzsJtWpkFXxki40hfn2RMrz0aVMkCYhDw2otK6TaFj1tXtpAa3lNjKI E+ZXN7QdoIfNm4OAqvKX0srbkt0aaDRlhnEMRlhVwnN5IZnXYQhvfvNcepXkkP3q LGDykAuh6ashGnbUKRyNxUZh3WdNMVTlepA== 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= 1685980997; x=1686067397; bh=Ae5kqkzReW1dh8nzDIusoqcvD/9Mm/gwUPE Y2SU59AY=; b=EEOkTs0YzOkNnHHcWWXtCXW/FRX2xutvSVrb3m1iJGZ9obnQ61Y d+gSMosyK4u13UFB4H6h6Wq3C7spV/QahjCrr50cqEaxsJmshPlcBgzTEGIyHdud jylgty6rHPTa97t2bIzVSMOCVzn4KUjc7OJ+wsX8FeL6zgouMTwVoQnscgHko2N7 RQpJok9uBPwanBD7szUIDlpKbdsOBYtrtzly8byNjYFrd+u4dQDoYAPx1DoEpgl2 7raSXWK2rJ57zmfqHXFypyfHLbZOcpEP7hDhxy0pIC1ey/nKVsOR/gKVCrKUAqAl hazKiQeQg5+rm+s9v7J/kQtQNV5TFOhgNEQ== X-ME-Sender: X-ME-Received: X-ME-Proxy-Cause: gggruggvucftvghtrhhoucdtuddrgedvhedrfeelledgleejucetufdoteggodetrfdotf 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 12:03:16 -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 18:03:14 +0200 Message-ID: <42152109.doPnVEEUbh@thomas> In-Reply-To: References: <19381599.sIn9rWBj0N@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: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//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. 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?