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 053605F1D for ; Wed, 14 Mar 2018 17:42:37 +0100 (CET) X-Amp-Result: SKIPPED(no attachment in message) X-Amp-File-Uploaded: False Received: from fmsmga003.fm.intel.com ([10.253.24.29]) by fmsmga105.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 14 Mar 2018 09:42:34 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.48,471,1517904000"; d="scan'208";a="33840292" Received: from fyigit-mobl.ger.corp.intel.com (HELO [10.237.221.62]) ([10.237.221.62]) by FMSMGA003.fm.intel.com with ESMTP; 14 Mar 2018 09:42:32 -0700 To: Remy Horton , dev@dpdk.org Cc: Wenzhuo Lu , Jingjing Wu , Qi Zhang , Beilei Xing , Shreyansh Jain , Thomas Monjalon References: <20180307120851.5822-1-remy.horton@intel.com> <20180307120851.5822-2-remy.horton@intel.com> <023fbd6c-7cac-6c8b-9a40-7a62e5d47bb7@intel.com> <30b8575d-4aeb-912d-6f74-c49ad7ce879a@intel.com> From: Ferruh Yigit Message-ID: Date: Wed, 14 Mar 2018 16:42:31 +0000 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.6.0 MIME-Version: 1.0 In-Reply-To: <30b8575d-4aeb-912d-6f74-c49ad7ce879a@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit 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: Wed, 14 Mar 2018 16:42:39 -0000 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.