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 59DB842C3E; Tue, 6 Jun 2023 10:42:01 +0200 (CEST) Received: from mails.dpdk.org (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id D1F2F40A84; Tue, 6 Jun 2023 10:42:00 +0200 (CEST) Received: from NAM11-DM6-obe.outbound.protection.outlook.com (mail-dm6nam11on2050.outbound.protection.outlook.com [40.107.223.50]) by mails.dpdk.org (Postfix) with ESMTP id 08FD440697 for ; Tue, 6 Jun 2023 10:41:59 +0200 (CEST) ARC-Seal: i=1; a=rsa-sha256; s=arcselector9901; d=microsoft.com; cv=none; b=L6csJpstK0zCWjsXHN+5ChZLcebinIlOLiuzk/8uyHchqPUGnDWr46DXcFz5hXag3I/dqUdoLevtT5rrJ0VAP/fbQ1KSqBkBCjklN8IoTaMsr9vlyJUzsa+QLNG/2omzAmjUmZNbefXy35VqbNmmZDYs0DlvRzeBotoFOMPzmNtZnJ+wh7Ehv03VYkmN04l8Raus9XeB3kNc/R2jWzd+anZ0bMZ0mLrYJGggup5eP/BArNZvyrTt/L2A30+74am3fW2UpMh+V4IuSfHImhnuEoSTwTWZimzzGQu4TEdoFCFCiXWMoXcMxtIhi03oWOvSNOBMYnH6XUaPaKBJaIqqvg== ARC-Message-Signature: i=1; a=rsa-sha256; c=relaxed/relaxed; d=microsoft.com; s=arcselector9901; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-AntiSpam-MessageData-ChunkCount:X-MS-Exchange-AntiSpam-MessageData-0:X-MS-Exchange-AntiSpam-MessageData-1; bh=ia9KG0vZa3aCejDVu3yNmCIzBBnrrVSPqRNkoBQnyJ0=; b=TtohO2qK7QBJ8zLf2LPGFPPlKTKJRnweZK+nE8y8jERL5ZllxnFemX+oWx9eIEDipOM85bPo6y/TI5fwoLLTvFp3LT38R8AXt1HiMEDZW37z+Sp6PRkD7lsVgUXZzC9omF2odkEDsxVDVwy8IwYKEXvQGIKatYHC3uiBhGKDTKW91E7wzpqNW6PmoZdPdUxPTBQL2hjnQ2R9KrkHXRSnijZZ6rLG17DxriVg6867ba+JAEy2RTBI5sztXenhStWUk+4XUmrMgW34gXZ9Dq/YfUT6ZJqnGnTmiqJeOvLebDE1fmvJD6Xk2FXbmZxSOQ1TX40E0jtrImg227hMZGFdJg== ARC-Authentication-Results: i=1; mx.microsoft.com 1; spf=pass smtp.mailfrom=amd.com; dmarc=pass action=none header.from=amd.com; dkim=pass header.d=amd.com; arc=none DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=amd.com; s=selector1; h=From:Date:Subject:Message-ID:Content-Type:MIME-Version:X-MS-Exchange-SenderADCheck; bh=ia9KG0vZa3aCejDVu3yNmCIzBBnrrVSPqRNkoBQnyJ0=; b=LTqNWRZ1pSJJSWuSvFydcrd/MmvQw2kL5BqW7Y5bYTvZqau28wNAFFXLLB2rlAWM8I63z8NfK9ZKDPRP1NnCR4RsQHhhhZQsUIqXk4cRPTQ2O0gCJ7lAIHHhOAhv3uj/gadFOmGMu56o2vTO14inRw5PKrA7Cp+cAdiPsrRp9aw= Authentication-Results: dkim=none (message not signed) header.d=none;dmarc=none action=none header.from=amd.com; Received: from CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) by BN9PR12MB5384.namprd12.prod.outlook.com (2603:10b6:408:105::20) with Microsoft SMTP Server (version=TLS1_2, cipher=TLS_ECDHE_RSA_WITH_AES_256_GCM_SHA384) id 15.20.6455.33; Tue, 6 Jun 2023 08:41:56 +0000 Received: from CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::cf07:30f7:a92a:c53b]) by CH2PR12MB4294.namprd12.prod.outlook.com ([fe80::cf07:30f7:a92a:c53b%4]) with mapi id 15.20.6455.030; Tue, 6 Jun 2023 08:41:56 +0000 Message-ID: <9ae155ce-b011-994b-60c0-537a615a2878@amd.com> Date: Tue, 6 Jun 2023 09:41:50 +0100 User-Agent: Mozilla/5.0 (Windows NT 10.0; Win64; x64; rv:102.0) Gecko/20100101 Thunderbird/102.11.2 Subject: Re: Getting network port ID by ethdev port ID Content-Language: en-US To: Ivan Malov , Stephen Hemminger Cc: Thomas Monjalon , dev@dpdk.org, Andrei Izrailev References: <19381599.sIn9rWBj0N@thomas> <42152109.doPnVEEUbh@thomas> <20230605115054.62cdc8e2@hermes.local> From: Ferruh Yigit In-Reply-To: Content-Type: text/plain; charset=UTF-8 Content-Transfer-Encoding: 8bit X-ClientProxiedBy: LO4P123CA0336.GBRP123.PROD.OUTLOOK.COM (2603:10a6:600:18c::17) To CH2PR12MB4294.namprd12.prod.outlook.com (2603:10b6:610:a9::11) MIME-Version: 1.0 X-MS-PublicTrafficType: Email X-MS-TrafficTypeDiagnostic: CH2PR12MB4294:EE_|BN9PR12MB5384:EE_ X-MS-Office365-Filtering-Correlation-Id: 7a36f830-4c33-476b-4049-08db6669e2ab X-MS-Exchange-SenderADCheck: 1 X-MS-Exchange-AntiSpam-Relay: 0 X-Microsoft-Antispam: BCL:0; X-Microsoft-Antispam-Message-Info: L51+t4lhjokU1K4tqJfINDSjH9YRPyhN3m6X6D7jhXrwUNKFamtnb6KarPbkfeGeHncNW6XINsU7Ha+eiscwfNhyRsplLE7Uugqfne6GWIHYYq33e4Fm0eDcESAWPB6oAWCXZiMrOb/rVnVZvRMnewhbAibA9pVT5xrkD0uyiR9s6Z74LIdldKJMPi8O9e3JEQe5ovaGlWaK6GdeScSpWmTxCF1kSP/X2qJl97PrEnWOPMaY64s2QGZ64PvyG6tM5aglwsimiOjrPPox3/No5qOoC+Y2OrOvAI1hMHNb0zmba0ywzSn6z9VTE1uxXYdkzRzLQkK600gMBgCxnawqXAZYGpB2JqboxcMWPeHB2fkApbOSEpnduCdCm1fn0oVp9EriS+gFwnX7jv23fmMpVeQ3XtuXsAd8SzgzEG2it41jfwwYY0reDZ2rx2E1gAbW0c82mKcBrydAdOjYfZrVUBFr7BBzlhaHsHcw6On888pP1sn1TaBzosFlwUWMTh+LzK2Uwym2oPS1mX/7FWmBDcs8hokomIajw0g+vE3AZC8UH3IfuYRhDH/5W7PWVXF4AYHU/5bVzXTibVGZCo0VOnk0AbhbQq7iyFJYZ4ZqdN4vP2mAHixRkWle4nbR5kQdJldJVQGBTkXkwWhldjua3Q== X-Forefront-Antispam-Report: CIP:255.255.255.255; CTRY:; LANG:en; SCL:1; SRV:; IPV:NLI; SFV:NSPM; H:CH2PR12MB4294.namprd12.prod.outlook.com; PTR:; CAT:NONE; SFS:(13230028)(4636009)(376002)(396003)(39860400002)(136003)(346002)(366004)(451199021)(36756003)(2906002)(31696002)(86362001)(5660300002)(44832011)(31686004)(83380400001)(6486002)(6666004)(53546011)(26005)(6512007)(6506007)(478600001)(186003)(54906003)(110136005)(38100700002)(316002)(41300700001)(4326008)(66946007)(2616005)(66556008)(66476007)(8676002)(8936002)(43740500002)(45980500001); DIR:OUT; SFP:1101; X-MS-Exchange-AntiSpam-MessageData-ChunkCount: 1 X-MS-Exchange-AntiSpam-MessageData-0: =?utf-8?B?alVYK3lWVkJ3Zzl2WVRQeW1VUk1KR0hBeVZScUR6U0ROUkNJT2RNUSt3UXA4?= =?utf-8?B?bUpyelQrb3BXRHQ1aUI1N2lydktHdGR4MlR1VEZ5d2Z0ZDcrT2E2TXpwWHFQ?= =?utf-8?B?SzlXNTNTank4d041TEhGNnEwUVJ0cm11di9VSHNXVHpWUlpWSHBXcTRiazd4?= =?utf-8?B?ZVl5Uy9yMVpTcitkWUxHZzZadmRKd01zK2J5eXJqeWdZWXhhTFgzQVlYbisv?= =?utf-8?B?aGVIUThhMnJmM3NVOGtOZjVDUHd3Q0x1ejJVdHlvSmdNWnlFVXo0dENiWTZv?= =?utf-8?B?M3duQmIwb1NLd1NHU1M4ZDlocFB5bTROdnJJVndQMWZBK2lMbWNBNmNaSVdT?= =?utf-8?B?clY2WHZXNXd0SWp5OXJFaWROazh5OFN0anZtWEtlRnJHdTZucUJhTVlFaEg4?= =?utf-8?B?NFQvL0xjSnlIZWsrazdTR1VuVEhqZ0JmRzgxOS9QWEZyZVZIOTI5TnFLaVR1?= =?utf-8?B?UUUzQTFFZ250TGZkYTJJdXp5MGdNMnRyWkVzUkVVVUNSdGc5NUFtM3ppY3FK?= =?utf-8?B?RE1ReC9Gcmd1YjNXdUpoSWl0OWNGUkRJK0pzeklxV0RhcHNlV2ZwRjVpZ3NH?= =?utf-8?B?djBRbllUc3ArNVlZY25PVkV6VnoxdDVLUWZpbE95S3V0QjlQMVFGdGYyQlBR?= =?utf-8?B?dXUzcm1RSXFObEpZcENGeEpkRTNjYU5kUCtkWExBRGsrZVRpbWNLaFRlRlNT?= =?utf-8?B?d1lhejFOTGR1OVNyVnJOVEsvREdSK2dHYXErelRDODZGUVdxQ3JOcitQT2tJ?= =?utf-8?B?ekp6S0hVdk5NU2NOYUVxazcwZjZIOW9CRlNYY1JLVHY1YXhRSGEzd2FiWWdV?= =?utf-8?B?T0I1VjlKTVF1bjdJZHloT3pVemtMektXZUczOTlaSFVCTU1scXJkZ0FOcDdP?= =?utf-8?B?TTF4Q0phcS8wTnErSlNVT0dNWitNVE9uMC9CcWU0SVRYZUtXSzJyUUE0TzZ1?= =?utf-8?B?WlQ4VG0zT1ZWcW1CMklNUkNvVnI2VEJNUkZoZ3lLMGtKTSt5SWV0d2o0eXJX?= =?utf-8?B?UjhYTjB4YjhqeTNRM2JCeDhGbS9XMzJyR1lTT1BHUG03eGYxOG1ndXE5Ui9J?= =?utf-8?B?ejRjRVE0c1g2cHpMRUN0dEhPbU5NN3ZiWDU2anZHekIwVVpPMUlqRFJPYUFN?= =?utf-8?B?eWZEd0crZXVvalBFa01oUU5idE82M2taVXFOUW9RM2VEbWtXRlNPN29CRnpN?= =?utf-8?B?N1Y2M0xxMjV0anFjZGU3aDdrb1B6YnV4ekZ4U2tVY1k2UUhyUzdCNXhlNXdG?= =?utf-8?B?T2pEMzVjMGM3SHNDNTFjTnQ1NUJKSUQrSUlPQUFpU2dNanNSaHB5aGtWTmxZ?= =?utf-8?B?Y0d6dk5mT1pqUDU3eUZ5dXczZTlUMFZiRy82YkY4ZlRiMWxzRThrYWRRZWV2?= =?utf-8?B?NFFEMW1QV0FDNzN3eFBUYXNiQVZwcXBhYmtsSFdMQmo1TnZxcGx0MmIvNTRO?= =?utf-8?B?RXVtbTRtM1VCcVYrRVpwa01jTm1Hb3FmUWlJaE13RzkzSVVLQUh4bnphS1A4?= =?utf-8?B?NTdIRC9OMU9zbjQxd0J0YTlZSThwZXJmK2paK2dMU055a05FT3BhcTdsb1ZF?= =?utf-8?B?YmJHQVJDaW54TkRsMU5ZSXJ3VTRBY2FPOUN6NjZCdVRuNXlxeU81M05oOFZW?= =?utf-8?B?TzRsWStMR0czZ0NPazdiTmxMREVCbEtvbjd0S0hJS3JRRUsyNGFoTGlYYlhl?= =?utf-8?B?Y3hock9nU3ZBMmRaZHNRMU9ud3kyaFJuQjIzYUpTelRGQmZ2Q1MweFhrc2VN?= =?utf-8?B?VjdkV2JiN2UrUXdjUGhBUkRUNFpiSFUxOFgwYkJUdWRIOEJoQWhsR3RnUnU0?= =?utf-8?B?WVRzeWZaeGc3empnT0M4ZDFmYUhncmQ5Rmw2eWJ5SU1GQVVKZlBDSzFkNEto?= =?utf-8?B?Zk5sQjFhbGJKODBBeVVYdDNna254TnJNcDM0ZHFRd2RkYitOcEhBTGZESXUw?= =?utf-8?B?MWwyOXRLNDMyZGNGakoySmFCUFdhbnF1bDR6b0JpQzFrWCttVUJpNFNFK1pn?= =?utf-8?B?Y3dINDUzcnpSQTRiZGJNQzNCditGREQ2T000eUk1bzRvQlE4UVRpUVFSd09L?= =?utf-8?B?MktuVkc5RURTeVFZT2dJTkJJWmIyczRvS3pJOXE1d1BUZm9xaGdCam9IN0tW?= =?utf-8?Q?QQqNoxflhW3oE8dpU93GlWppt?= X-OriginatorOrg: amd.com X-MS-Exchange-CrossTenant-Network-Message-Id: 7a36f830-4c33-476b-4049-08db6669e2ab X-MS-Exchange-CrossTenant-AuthSource: CH2PR12MB4294.namprd12.prod.outlook.com X-MS-Exchange-CrossTenant-AuthAs: Internal X-MS-Exchange-CrossTenant-OriginalArrivalTime: 06 Jun 2023 08:41:56.5881 (UTC) X-MS-Exchange-CrossTenant-FromEntityHeader: Hosted X-MS-Exchange-CrossTenant-Id: 3dd8961f-e488-4e60-8e11-a82d994e183d X-MS-Exchange-CrossTenant-MailboxType: HOSTED X-MS-Exchange-CrossTenant-UserPrincipalName: TuUkje/mtcFqThZVn1JPdDi2VpePkXn0HOKI4V75MO8O7WL6cZ6VnBC63nIEgtZh X-MS-Exchange-Transport-CrossTenantHeadersStamped: BN9PR12MB5384 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 6/5/2023 9:30 PM, 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. > I am for having specific API for it (if we will have it), instead of overloading the 'rte_eth_dev_info_get()', so purpose of new information (and new API) can be more focused and clear. > That would help certain applications to have > physical port IDs mapped to ethdev IDs. > Right now they have no way of knowing. > > Thank you.