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 00AE8A0566; Mon, 8 Mar 2021 17:12:11 +0100 (CET) Received: from [217.70.189.124] (localhost [127.0.0.1]) by mails.dpdk.org (Postfix) with ESMTP id 7E12122A3FB; Mon, 8 Mar 2021 17:12:11 +0100 (CET) Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by mails.dpdk.org (Postfix) with ESMTP id 022B522A384 for ; Mon, 8 Mar 2021 17:12:09 +0100 (CET) IronPort-SDR: pv2xpNYQkR2epZzfUimSKi2+b8yQulhl7BwTHjw24p2GKaIz8zxM+sRu/Q4lyqeCXP6WSuO3AO WZ7NQ8MMxO0A== X-IronPort-AV: E=McAfee;i="6000,8403,9917"; a="188107805" X-IronPort-AV: E=Sophos;i="5.81,232,1610438400"; d="scan'208";a="188107805" Received: from orsmga008.jf.intel.com ([10.7.209.65]) by orsmga103.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 08:12:08 -0800 IronPort-SDR: C1jXNppTGQJ1b4LVdPFp3yGQIOh7HSmG0CPMr9JP1Kpd39L7+8j4kVtmS+YR6p2U8eJJIJtRsy RbguKnPZXudw== X-IronPort-AV: E=Sophos;i="5.81,232,1610438400"; d="scan'208";a="409352516" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.213.195.201]) ([10.213.195.201]) by orsmga008-auth.jf.intel.com with ESMTP/TLS/ECDHE-RSA-AES256-GCM-SHA384; 08 Mar 2021 08:12:06 -0800 To: "Xueming(Steven) Li" , Andrew Rybchenko Cc: "dev@dpdk.org" , Slava Ovsiienko , Asaf Penso , NBU-Contact-Thomas Monjalon , Ray Kinsella , Neil Horman References: <1608303356-13089-2-git-send-email-xuemingl@nvidia.com> <1614868228-13685-8-git-send-email-xuemingl@nvidia.com> From: Ferruh Yigit X-User: ferruhy Message-ID: <5c0d7b37-3ec6-0c0a-ff43-03b1f4bf6268@intel.com> Date: Mon, 8 Mar 2021 16:12:03 +0000 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH v8 7/9] ethdev: new API to get representor info 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 Sender: "dev" On 3/8/2021 3:31 PM, Xueming(Steven) Li wrote: > >> -----Original Message----- >> From: Ferruh Yigit >> Sent: Monday, March 8, 2021 10:44 PM >> To: Xueming(Steven) Li ; Andrew Rybchenko >> Cc: dev@dpdk.org; Slava Ovsiienko ; Asaf Penso ; NBU-Contact-Thomas Monjalon >> ; Ray Kinsella ; Neil Horman >> Subject: Re: [PATCH v8 7/9] ethdev: new API to get representor info >> >> On 3/4/2021 2:30 PM, Xueming Li wrote: >>> The NIC can have multiple PCIe links and can be attached to multiple >>> hosts, for example the same single NIC can be shared for multiple >>> server units in the rack. On each PCIe link NIC can provide multiple >>> PFs and VFs/SFs based on these ones. The full representor identifier >>> consists of three indices - controller index, PF index, and VF or SF index (if any). >>> >>> This patch introduces a new API rte_eth_representor_info_get() to >>> retrieve representor corresponding info mapping: >>> - caller controller index and pf index. >>> - supported representor ID ranges. >>> - type, controller, pf and start vf/sf ID of each range. >>> The API is useful to convert representor from devargs to representor ID. >>> >>> New ethdev callback representor_info_get() is added to retrieve info >>> from PMD driver, optional for PMD that doesn't support new devargs >>> representor syntax. >>> >>> Signed-off-by: Xueming Li >>> Acked-by: Andrew Rybchenko >> >> This is middle layer implementation, and there is not problem with it but without PMD and application implementations it is harder to >> get why/how this API will be used. >> >> As far as I can see this API is not directly needed for this set, what do you think making this another set with PMD and application >> implementations on top of current set? > > Hi Ferruh, > > Thanks for checking this! The patch next, 8/9 which update device iterator for SF representor needs this API to get representor ID then compare. > Got it thanks. Intention of the new API seems to get info to be able to calculate the unique "representor ID" and the helper function 'rte_eth_representor_id_get()' implements a logic to calculate this unique ID but that logic is not clear, can you please document it more to help the PMD developers to implement 'representor_info_get()'?