From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga11.intel.com (mga11.intel.com [192.55.52.93]) by dpdk.org (Postfix) with ESMTP id 791BDE5D for ; Fri, 15 Dec 2017 20:24:15 +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 fmsmga102.fm.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 15 Dec 2017 11:24:12 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.45,406,1508828400"; d="scan'208";a="12184555" Received: from fyigit-mobl1.ger.corp.intel.com (HELO [10.241.225.53]) ([10.241.225.53]) by FMSMGA003.fm.intel.com with ESMTP; 15 Dec 2017 11:24:11 -0800 To: Wenzhuo Lu , dev@dpdk.org References: <1501529240-64181-1-git-send-email-wenzhuo.lu@intel.com> From: Ferruh Yigit Message-ID: Date: Fri, 15 Dec 2017 11:24:11 -0800 User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:52.0) Gecko/20100101 Thunderbird/52.5.0 MIME-Version: 1.0 In-Reply-To: <1501529240-64181-1-git-send-email-wenzhuo.lu@intel.com> Content-Type: text/plain; charset=utf-8 Content-Language: en-US Content-Transfer-Encoding: 8bit Subject: Re: [dpdk-dev] [RFC PATCH 0/3] configurable max queue number per VF 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, 15 Dec 2017 19:24:16 -0000 On 7/31/2017 12:27 PM, Wenzhuo Lu wrote: > Currently, on i40e, the max queue number per VF is set by a macro. > It means the value is decided when compiling. It's not friendly to > the users. Because every time the users want to change the value, > the code need to be re-compiled. > > The reason of using a macro for the max queue number is that the > number is needed at the very early stage. At this stage, we haven't > got the device configuration yet. > There's a simple idea to replace the macro by a global varialbe. > Then the users can set the value without compiling the code again > and again. Hi Wenzhuo, It is good to convert compile time options to something more dynamic, but I am not sure adding max_queue_number_per_vf global variable into ethdev lib. Also currently only i40e requires this but what if some other PMD requires this and conflicts with the values i40e requires? Application directly setting library global value is another concern. Problem looks like setting library defaults problem. Currently we are setting defaults via config options and changing them requires re-compiling the library, which indeed not should be required. This will be more ambitious but what about addressing problem in DPDK level so that we can move many config options. What about creating a global rte_default object and put all defaults from config file there, and other libraries access to this object to learn about default values. rte_config or lcore_config are already global config objects, and lcore_config seems already exposed to the applications, similar thing can be done here. Provide APIs to set / values in this object so that application dynamically set them before eal_init() _if_ they need to change something, but mostly defaults should be good to run apps without needs to modify them for majority of cases. Later this can be worked out to distribute defaults to own library, so that each library can hold their own default values. Any comments? > > This patch set implements this idea and is an example to show how > to use it. > > Wenzhuo Lu (3): > librte_ether: VF max queue number setting > net/i40e: max VF queue number setting > app/testpmd: a parameter to set max queue per VF > > app/test-pmd/parameters.c | 33 ++++++++++++++++++++++++++++++++- > app/test-pmd/testpmd.c | 2 ++ > app/test-pmd/testpmd.h | 1 + > config/common_base | 1 - > drivers/net/i40e/i40e_ethdev.c | 4 ++-- > lib/librte_ether/rte_ethdev.c | 3 +++ > lib/librte_ether/rte_ethdev.h | 2 ++ > 7 files changed, 42 insertions(+), 4 deletions(-) >