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 22D6642C36; Tue, 6 Jun 2023 00:39:11 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id AE8DF40A84; Tue, 6 Jun 2023 00:39:10 +0200 (CEST) Received: from mail-pf1-f182.google.com (mail-pf1-f182.google.com [209.85.210.182]) by mails.dpdk.org (Postfix) with ESMTP id E5B89406B7 for ; Tue, 6 Jun 2023 00:39:09 +0200 (CEST) Received: by mail-pf1-f182.google.com with SMTP id d2e1a72fcca58-65299178ac5so4979728b3a.1 for ; Mon, 05 Jun 2023 15:39:09 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1686004749; x=1688596749; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:from:to:cc:subject:date :message-id:reply-to; bh=mHCpyJyLlIVo6byO+JIPdgTvniGoiT8VFk0Cp3/+3UI=; b=P7rsDayP6v/MfH35MG1k9sBHJa2C42Fn11T1iDukfRz2FcyDJjEFmV+2fvP1dcA9J8 RVCh7Lqo15+BnmZIjh8jltdyxvqgZflzlAnClvZJ77rBT6XYDUkH1e+v1KylsfVP6tRv WJ7bVYruHmI3e+9jVS9xBxJlRlKNySP6aMRZGFIAcvHyjWr1HCl+tVs5H4djxUXpsq9g 1qA5nvm4RcsegxFNrw+AGYj+b7GgA2WAdWUKkCGqLC+mSC1E1L2DCoVP59H1fYnovp2n nAm7tcEF3Zyo+bjh5MM9Q9ZsgGlx8sYcYmSWTZYRS+/X6A1NM5bU+S+aQkSyvUMS262T 4HbQ== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1686004749; x=1688596749; h=content-transfer-encoding:mime-version:references:in-reply-to :message-id:subject:cc:to:from:date:x-gm-message-state:from:to:cc :subject:date:message-id:reply-to; bh=mHCpyJyLlIVo6byO+JIPdgTvniGoiT8VFk0Cp3/+3UI=; b=CXSTsnXRr2PHo1vJnHTMAZaxFS9blr2y9ASx0fEzyuUB4Avi5i+7/3jj0ogdvm2dOF iLQ0WijWp3OkApzBNoyFKzSh/EZWtc4M7sux0dcPbunhVzLvjKIVDlpwq7MUd8XgxDWm mqOMEu/Ith2ICymCqPhQxJ5FaQeIJRaHJLsBPmVBRCHAjvDYIj5v+hJF2+8HVT6cRMtk H9RKdAbB8EUvEvxN6AhXFJ/+4DLytZ8GV7SFyvJd1B9rg2gjr3Mxs07wVCNFfe9eU6mk KDbOM7F7ggovXqklipugBjmevtA9Aczn9iwTyweeFt7gcEzWNEAzQO7W/+18RyECK/ps Ph3g== X-Gm-Message-State: AC+VfDwEGr1kzPFPlx4VfybtnYGXO5sMRVSJymNnS5GX069eEwWJ7uZa kLPfJx+aNOJo4bZRrijmYn0dJQ== X-Google-Smtp-Source: ACHHUZ6ab1/Hb2B5uKa603lxeB1g7aiuqW+2wZa3uI9NFIRZuWSNsa9xPN+d5bipSntdTf3iAIczVw== X-Received: by 2002:a05:6a00:1686:b0:63d:47c8:856e with SMTP id k6-20020a056a00168600b0063d47c8856emr68096pfc.2.1686004748847; Mon, 05 Jun 2023 15:39:08 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id b8-20020aa78708000000b00640ddad2e0dsm5622397pfo.47.2023.06.05.15.39.08 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jun 2023 15:39:08 -0700 (PDT) Date: Mon, 5 Jun 2023 15:39:06 -0700 From: Stephen Hemminger To: Ivan Malov Cc: Thomas Monjalon , dev@dpdk.org, Andrei Izrailev , Ferruh Yigit Subject: Re: Getting network port ID by ethdev port ID Message-ID: <20230605153906.0b7912b0@hermes.local> In-Reply-To: References: <19381599.sIn9rWBj0N@thomas> <42152109.doPnVEEUbh@thomas> <20230605115054.62cdc8e2@hermes.local> MIME-Version: 1.0 Content-Type: text/plain; charset=US-ASCII Content-Transfer-Encoding: 7bit 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 On Tue, 6 Jun 2023 00:30:18 +0400 (+04) Ivan Malov wrote: > Hi Stephen, Thomas, > > Thanks for responding. PSB. > > On Mon, 5 Jun 2023, Stephen Hemminger wrote: > > > On Mon, 05 Jun 2023 18:03:14 +0200 > > Thomas Monjalon 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//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? > > > > 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. > > > > So.. by the sound of it, it would be nice to introduce > something like "int phys_port_id" to rte_eth_dev_info, > correct? That would indicate either -1 (for example, > in the case of VFs connected with representors) > or some sensible value, as per internal mapping. > > That would help certain applications to have > physical port IDs mapped to ethdev IDs. > Right now they have no way of knowing. > > Thank you. You are better off using PCI information. That is what systemd does in general. If you really need it use the PCI go look in sysfs in application. The multiport bifuricated nvidia driver is unique. IMHO not worth adding general support in DPDK until/unless we have three vendors doing it.