From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga05.intel.com (mga05.intel.com [192.55.52.43]) by dpdk.org (Postfix) with ESMTP id E2526FFA for ; Fri, 3 Feb 2017 13:00:55 +0100 (CET) Received: from fmsmga005.fm.intel.com ([10.253.24.32]) by fmsmga105.fm.intel.com with ESMTP; 03 Feb 2017 04:00:54 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,328,1477983600"; d="scan'208";a="60762848" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.252.22.184]) ([10.252.22.184]) by fmsmga005.fm.intel.com with ESMTP; 03 Feb 2017 04:00:53 -0800 To: "Iremonger, Bernard" , "Ananyev, Konstantin" , "Lu, Wenzhuo" , "dev@dpdk.org" References: <1485311962-62335-1-git-send-email-wenzhuo.lu@intel.com> <2601191342CEEE43887BDE71AB9772583F10FFA1@irsmsx105.ger.corp.intel.com> <410cf75d-0ceb-d372-778f-bfa19392443b@intel.com> <2601191342CEEE43887BDE71AB9772583F110053@irsmsx105.ger.corp.intel.com> <8CEF83825BEC744B83065625E567D7C224D25A9D@IRSMSX108.ger.corp.intel.com> <2601191342CEEE43887BDE71AB9772583F110909@irsmsx105.ger.corp.intel.com> <8CEF83825BEC744B83065625E567D7C224D25B6F@IRSMSX108.ger.corp.intel.com> From: Ferruh Yigit Message-ID: <1b6bd452-3585-f761-5eef-3e29914415a8@intel.com> Date: Fri, 3 Feb 2017 12:00:53 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:45.0) Gecko/20100101 Thunderbird/45.7.0 MIME-Version: 1.0 In-Reply-To: <8CEF83825BEC744B83065625E567D7C224D25B6F@IRSMSX108.ger.corp.intel.com> Content-Type: text/plain; charset=windows-1252 Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 03 Feb 2017 12:00:56 -0000 On 2/3/2017 10:02 AM, Iremonger, Bernard wrote: > Hi Konstantin, > >> -----Original Message----- >> From: Ananyev, Konstantin >> Sent: Friday, February 3, 2017 9:50 AM >> To: Iremonger, Bernard ; Yigit, Ferruh >> ; Lu, Wenzhuo ; >> dev@dpdk.org >> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: clean up rte_eth_dev_info_get >> >> Hi Bernard, >> >>> -----Original Message----- >>> From: Iremonger, Bernard >>> Sent: Friday, February 3, 2017 9:21 AM >>> To: Ananyev, Konstantin ; Yigit, Ferruh >>> ; Lu, Wenzhuo ; >>> dev@dpdk.org >>> Subject: RE: [dpdk-dev] [PATCH] net/ixgbe: clean up >>> rte_eth_dev_info_get >>> >>> Hi Konstantin, >>> >>>> -----Original Message----- >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ananyev, >>>> Konstantin >>>> Sent: Wednesday, February 1, 2017 6:10 PM >>>> To: Yigit, Ferruh ; Lu, Wenzhuo >>>> ; dev@dpdk.org >>>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up >>>> rte_eth_dev_info_get >>>> >>>> >>>> >>>>> -----Original Message----- >>>>> From: Yigit, Ferruh >>>>> Sent: Wednesday, February 1, 2017 5:40 PM >>>>> To: Ananyev, Konstantin ; Lu, >>>>> Wenzhuo ; dev@dpdk.org >>>>> Subject: Re: [dpdk-dev] [PATCH] net/ixgbe: clean up >>>>> rte_eth_dev_info_get >>>>> >>>>> On 2/1/2017 4:24 PM, Ananyev, Konstantin wrote: >>>>>> Hi Wenzhuo, >>>>>> >>>>>>> -----Original Message----- >>>>>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wenzhuo >> Lu >>>>>>> Sent: Wednesday, January 25, 2017 2:39 AM >>>>>>> To: dev@dpdk.org >>>>>>> Cc: Lu, Wenzhuo >>>>>>> Subject: [dpdk-dev] [PATCH] net/ixgbe: clean up >>>>>>> rte_eth_dev_info_get >>>>>>> >>>>>>> It'not appropriate to call rte_eth_dev_info_get in PMD, as >>>>>>> rte_eth_dev_info_get need to get info from PMD. >>>>>>> Remove rte_eth_dev_info_get from PMD code and get the info >>>>>>> directly. >>>>>>> >>>>>>> Signed-off-by: Wenzhuo Lu >>>>>>> --- >>>>>>> drivers/net/ixgbe/ixgbe_ethdev.c | 144 >>>>>>> ++++++++++++++++++--------------------- >>>>>>> 1 file changed, 68 insertions(+), 76 deletions(-) >>>>>>> >>>>>>> diff --git a/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>> b/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>> index 64ce55a..f14a68b 100644 >>>>>>> --- a/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>> +++ b/drivers/net/ixgbe/ixgbe_ethdev.c >>>>>>> @@ -4401,17 +4401,17 @@ static int >>>> ixgbevf_dev_xstats_get_names(__rte_unused struct rte_eth_dev *dev, >>>>>>> int rar_entry; >>>>>>> uint8_t *new_mac = (uint8_t *)(mac_addr); >>>>>>> struct rte_eth_dev *dev; >>>>>>> - struct rte_eth_dev_info dev_info; >>>>>>> + struct rte_pci_device *pci_dev; >>>>>>> >>>>>>> RTE_ETH_VALID_PORTID_OR_ERR_RET(port, -ENODEV); >>>>>>> >>>>>>> dev = &rte_eth_devices[port]; >>>>>>> - rte_eth_dev_info_get(port, &dev_info); >>>>>>> + pci_dev = IXGBE_DEV_TO_PCI(dev); >>>>>>> >>>>>>> - if (is_ixgbe_pmd(dev_info.driver_name) != 0) >>>>>>> + if (is_ixgbe_pmd(dev->data->drv_name)) >>>>>>> return -ENOTSUP; >>>>>> >>>>>> I wonder why do we need now that it is really an ixgbe device >>>>>> all over the >>>> place? >>>>> >>>>> This device specific API, so it is missing merits of abstraction >>>>> layer, application can these APIs with any port_id, API should be >>>>> protected >>>> for it. >>>> >>>> Ah ok, my bad - didn't realize from the patch that it affects only >>>> device specific API :) Would It be too much hassle to move these >>>> functions into a separate file (rte_ixgbe_pmd.c or so)? >>>> Konstantin >>>> >>>>> >>>>>> Konstantin >>>>>> >>> All the device specific API functions are prefixed with rte_pmd_ixgbe >> >> That's ok. >> >> >>> so I don't think a separate file is necessary. >> >> So far I didn't say it is necessary. >> Though I think it would be good to group these functions in a separate file to >> help avoid confusion (as happened to me) and keep ixgbe_ethdev.c smaller >> and cleaner. >> Again would be easier to maintain things in future, when more folks will >> come up with some extensions for it. >> That's why I am asking: would it be a lot of work to do? >> It is probably worth doing it now, while we have this API relatively small. >> Konstantin >> > I would need to investigate what is involved in moving the rte_pmd_ixgbe_* functions to a separate file. > They may be using some of the static functions and data in the ixgbe_ethdev.c file which could be a problem. > The rte_pmd_ixgbe_* functions are considered an "interim solution" until a "generic solution" is agreed. > It might be best to postpone this work until the "generic solution" is agreed. Still I believe it is good idea to move these functions into a separate file, but not for this release J. For PMD specific APIs, even we keep using direct API call method or benefit from abstraction layer, means of using ioctl perhaps, these APIs will be implemented in the PMD. And logically grouping them is good idea. Briefly, I don't think we need to wait until "generic solution" agreed for this. But, of course an investigation needs to be done on required effort, and decide based on that. Thanks, ferruh > > Regards, > > Bernard. >