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 5739D42C35; Mon, 5 Jun 2023 20:50:59 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id CA8FD4021F; Mon, 5 Jun 2023 20:50:58 +0200 (CEST) Received: from mail-pl1-f174.google.com (mail-pl1-f174.google.com [209.85.214.174]) by mails.dpdk.org (Postfix) with ESMTP id CBAFC4003C for ; Mon, 5 Jun 2023 20:50:57 +0200 (CEST) Received: by mail-pl1-f174.google.com with SMTP id d9443c01a7336-1b025d26f4fso45163695ad.1 for ; Mon, 05 Jun 2023 11:50:57 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=networkplumber-org.20221208.gappssmtp.com; s=20221208; t=1685991057; x=1688583057; 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=8XcCPm1Gv3hOnLF2WS+VgHnhcSnemrM1Cs1dio/sj7Q=; b=hQE6mvrfswMyQZoLbYU2+VtYFHnEl6yCaCLYLn7m03BBN/XBJXYtpcO9sCPMeg4Ckp WzhIQDGmDZAevWIWJUxt7A7ih9n5ip2mfzFEqxMwe9M/he4r4FvznOQM5YqjxK8QfEVG w4wMKA0I7S+3nzSIXnb/z9nd2gnLwa1eNX8Ue2lCAC4ETidCCUjirUIBVgL8inZ5umU3 b/0RIC+2S7vVQ7/IgLtCcUxQB4l2YDp73aabFHEhQWhfwdABy1okWZHREq13NfnhtQ+z fk/pr/flcfFT/OkakJ0ml1l/+1KXOvJMxEL0Ce1WbZR8yrqChmVf/NyxprO/t5Oa6juM kO3g== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20221208; t=1685991057; x=1688583057; 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=8XcCPm1Gv3hOnLF2WS+VgHnhcSnemrM1Cs1dio/sj7Q=; b=ODPmoVjS3NX377YKPFdxkJpiAAWQWhU08cO3cmpa/B0kEbkjxeYYhQbgB9pNj9Zbsz h1l5WhhXX5iepQJtwdW+MRfgLqpOzrjDMW3NukcWXqoC0Jj6O+VZz5S4z+/0tJ7k7cZN +YBE6iF49ncDp/xfLQBHbhzMlVOp1NVQJe3rf3kZmUm6bGcdPw2yTQkU8UPivAIgE1GN fKsXdEYIl6cp+5RmhTom5a/dCBMqBjdCxJF95Ahj8qRabmfjxSH9qKXQ8SBIzq0RCZZV O2coq9kG0uqG203FnmDJ3rn611XmI3t6oVaSqHStrGqtgZSpTSIp37pq2bMZpZ/HWtKy c1VQ== X-Gm-Message-State: AC+VfDxKt3J9l63+O4J2GbM3SmHsGqCv+KtqnNNsNjp/dsz7UT6awskf nXUJnC8EsPlBzQjvFWpVEnV21w== X-Google-Smtp-Source: ACHHUZ4BYhJ2qWVwNKU0s3m2bDXu26Xiky+cY9p8iKfxI1liI5IxPH4ga0AV+elIcAiXWCjFqBJBGQ== X-Received: by 2002:a17:902:860c:b0:1b0:1036:608c with SMTP id f12-20020a170902860c00b001b01036608cmr7771873plo.25.1685991056781; Mon, 05 Jun 2023 11:50:56 -0700 (PDT) Received: from hermes.local (204-195-120-218.wavecable.com. [204.195.120.218]) by smtp.gmail.com with ESMTPSA id l18-20020a170902d35200b001a060007fcbsm6919616plk.213.2023.06.05.11.50.56 (version=TLS1_3 cipher=TLS_AES_256_GCM_SHA384 bits=256/256); Mon, 05 Jun 2023 11:50:56 -0700 (PDT) Date: Mon, 5 Jun 2023 11:50:54 -0700 From: Stephen Hemminger To: Thomas Monjalon Cc: Ivan Malov , dev@dpdk.org, Andrei Izrailev , Ferruh Yigit Subject: Re: Getting network port ID by ethdev port ID Message-ID: <20230605115054.62cdc8e2@hermes.local> In-Reply-To: <42152109.doPnVEEUbh@thomas> References: <19381599.sIn9rWBj0N@thomas> <42152109.doPnVEEUbh@thomas> 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 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.