From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id C12385F13 for ; Thu, 15 Mar 2018 15:42:19 +0100 (CET) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Mar 2018 07:42:18 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,311,1517904000"; d="scan'208";a="37675968" Received: from bricha3-mobl.ger.corp.intel.com ([10.237.221.118]) by fmsmga004.fm.intel.com with SMTP; 15 Mar 2018 07:42:15 -0700 Received: by (sSMTP sendmail emulation); Thu, 15 Mar 2018 14:42:14 +0000 Date: Thu, 15 Mar 2018 14:42:14 +0000 From: Bruce Richardson To: Ferruh Yigit Cc: "Ananyev, Konstantin" , Shreyansh Jain , "Horton, Remy" , "dev@dpdk.org" , "Lu, Wenzhuo" , "Wu, Jingjing" , "Zhang, Qi Z" , "Xing, Beilei" , Thomas Monjalon Message-ID: <20180315144214.GB9172@bricha3-MOBL.ger.corp.intel.com> References: <20180307120851.5822-2-remy.horton@intel.com> <023fbd6c-7cac-6c8b-9a40-7a62e5d47bb7@intel.com> <30b8575d-4aeb-912d-6f74-c49ad7ce879a@intel.com> <591e1a23-8d27-0c59-fd39-0bde9e48e96f@intel.com> <2601191342CEEE43887BDE71AB9772589E28FD57@irsmsx105.ger.corp.intel.com> <2b3a2579-6bce-55f5-6e03-0974729cc95b@intel.com> <2601191342CEEE43887BDE71AB9772589E2901EC@irsmsx105.ger.corp.intel.com> <3499e49e-4617-3faf-2a8e-883859d8eefd@intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline Content-Transfer-Encoding: 8bit In-Reply-To: <3499e49e-4617-3faf-2a8e-883859d8eefd@intel.com> Organization: Intel Research and Development Ireland Ltd. User-Agent: Mutt/1.9.4 (2018-02-28) Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters 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: Thu, 15 Mar 2018 14:42:20 -0000 On Thu, Mar 15, 2018 at 01:57:31PM +0000, Ferruh Yigit wrote: > On 3/15/2018 12:51 PM, Ananyev, Konstantin wrote: > > > > > >> -----Original Message----- > >> From: Yigit, Ferruh > >> Sent: Wednesday, March 14, 2018 9:03 PM > >> To: Ananyev, Konstantin ; Shreyansh Jain ; Horton, Remy > >> ; dev@dpdk.org > >> Cc: Lu, Wenzhuo ; Wu, Jingjing ; Zhang, Qi Z ; Xing, Beilei > >> ; Thomas Monjalon > >> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters > >> > >> On 3/14/2018 6:53 PM, Ananyev, Konstantin wrote: > >>> > >>> > >>>> -----Original Message----- > >>>> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Ferruh Yigit > >>>> Sent: Wednesday, March 14, 2018 5:52 PM > >>>> To: Shreyansh Jain ; Horton, Remy ; dev@dpdk.org > >>>> Cc: Lu, Wenzhuo ; Wu, Jingjing ; Zhang, Qi Z ; Xing, Beilei > >>>> ; Thomas Monjalon > >>>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD-tuned Tx/Rx parameters > >>>> > >>>> On 3/14/2018 5:23 PM, Shreyansh Jain wrote: > >>>>>> -----Original Message----- > >>>>>> From: Ferruh Yigit [mailto:ferruh.yigit@intel.com] > >>>>>> Sent: Wednesday, March 14, 2018 10:13 PM > >>>>>> To: Remy Horton ; dev@dpdk.org > >>>>>> Cc: Wenzhuo Lu ; Jingjing Wu > >>>>>> ; Qi Zhang ; Beilei Xing > >>>>>> ; Shreyansh Jain ; > >>>>>> Thomas Monjalon > >>>>>> Subject: Re: [dpdk-dev] [RFC PATCH v1 1/4] ethdev: add support for PMD- > >>>>>> tuned Tx/Rx parameters > >>>>>> > >>>>>> On 3/14/2018 3:48 PM, Remy Horton wrote: > >>>>>>> > >>>>>>> On 14/03/2018 14:43, Ferruh Yigit wrote: > >>>>>>> [..] > >>>>>>>>> lib/librte_ether/rte_ethdev.c | 18 ++++++++++++++++++ > >>>>>>>>> lib/librte_ether/rte_ethdev.h | 15 +++++++++++++++ > >>>>>>>> > >>>>>>>> Can you please remove deprecation notice in this patch. > >>>>>>> > >>>>>>> Done. > >>>>>>> > >>>>>>>>> + /* Defaults for drivers that don't implement preferred > >>>>>>>>> + * queue parameters. > >>>>>>> [..] > >>>>>>>> Not sure about having these defaults here. It is OK to have defaults > >>>>>> in driver, > >>>>>>>> in application or in config file, but I am not sure if putting them > >>>>>> into device > >>>>>>>> abstraction layer hides them. > >>>>>>>> > >>>>>>>> What about not providing any default in ethdev layer, and get zero > >>>>>> as invalid > >>>>>>>> when using them? > >>>>>>> > >>>>>>> This is something I have been thinking about, and I am going to > >>>>>> remove > >>>>>>> them for the V2. Original motive was to avoid breaking testpmd for > >>>>>> PMDs > >>>>>>> that don't give defaults (i.e. almost all of them). The alternative > >>>>>> is > >>>>>>> to put place-holders into all the PMDs themselves, but I am not sure > >>>>>> if > >>>>>>> this is appropriate. > >>>>>> > >>>>>> I think preferred values should be optional, PMD should have right to > >>>>>> not > >>>>>> provide any. Implementation in 4/4 forces preferred values, either in > >>>>>> all PMDs > >>>>>> or in ethdev layer. > >>>>>> > >>>>>> What about changing approach in application: > >>>>>> is preferred value provided [1] ? > >>>>>> yes => use it by sending value 0 > >>>>>> no => use application provided value, same as now, so control should > >>>>>> be in > >>>>>> application. > >>>>>> > >>>>>> I am aware this breaks the comfort of just providing 0 and PMD values > >>>>>> will be > >>>>>> used but covers the case there is no PMD values. > >>>>>> > >>>>>> [1] > >>>>>> it can be possible to check if preferred value provided by comparing 0, > >>>>>> but if 0 > >>>>>> is a valid value that can be problem. It may not be problem with > >>>>>> current > >>>>>> variables but it may be when this struct extended, it may be good to > >>>>>> think about > >>>>>> alternative here. > >>>>> > >>>>> I don't think we should use the condition of "yes => use it by sending value 0". That is non-intuitive. Ideally, the application should query > >>>> and then if query responds with value as '0' (which can be valid for some variables in future), it sends its own value to setup functions > >>>> (whether '0' or something else, in case of 0 response, would depend on the knob). > >>>> > >>>> Right, at that stage application already knows what is the preferred value and > >>>> can directly use it. > >>>> > >>>> > >>>> Will it be too much to: > >>>> > >>>> 1) Adding a new field into "rte_eth_[rt]xconf" to say if exists prefer PMD > >>>> values. "prefer_device_values" ? > >>>> Application can provide values as usual, but if that field is set, abstraction > >>>> layer overwrites the application values with PMD preferred ones. If there is no > >>>> PMD preferred values continue using application ones. > >>>> > >>>> > >>>> 2) Add a bitwise "is_set" field to new "preferred_size" struct, which may show > >>>> status of other fields in the struct, if PMD set a valid value for them or not, > >>>> so won't have to rely on the 0 check. > >>> > >>> That all seems like too much hassle for such small thing. > >> > >> Fair enough. > >> > >>> If we really want to allow PMD not to provide preferred values - > >>> then instead of adding rte_eth_dev_pref_info into dev_info we can simply > >>> introduce a new optional ethdev API call: > >>> rte_eth_get_pref_params() or so. > >>> If the PMD doesn’t want to provide preferred params to the user it simply > >>> wouldn't implement that function. > >> > >> Same can be done with updated rte_eth_dev_info. > >> Only application needs to check and use PMD preferred values, so this will mean > >> dropping "pass 0 to get preferred values" feature in initial set. > > > > That's ok by me, but it means every PMD has to provide some preferred values? > > No don't have to, if PMD provides preferred values app will use it, if not app > defined values will be used. > I don't like forcing apps to provide values for this. For usability the DPDK should be set up in a way such that an app writer can use defaults without having to think about it. We also need to provide hooks for specific use cases where the app writer does care, but we should provide the "easy" path too. It's worked well for the queue configuration structs, and I believe it will work fine for ring sizes too. /Bruce