From: Ferruh Yigit <ferruh.yigit@intel.com>
To: Wenzhuo Lu <wenzhuo.lu@intel.com>, dev@dpdk.org
Subject: Re: [dpdk-dev] [RFC PATCH 0/3] configurable max queue number per VF
Date: Fri, 15 Dec 2017 11:24:11 -0800 [thread overview]
Message-ID: <dd4aee93-2c3f-0936-1c19-8cd0fc21e245@intel.com> (raw)
In-Reply-To: <1501529240-64181-1-git-send-email-wenzhuo.lu@intel.com>
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(-)
>
next prev parent reply other threads:[~2017-12-15 19:24 UTC|newest]
Thread overview: 6+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-07-31 19:27 Wenzhuo Lu
2017-07-31 19:27 ` [dpdk-dev] [RFC PATCH 1/3] librte_ether: VF max queue number setting Wenzhuo Lu
2017-07-31 19:27 ` [dpdk-dev] [RFC PATCH 2/3] net/i40e: max VF " Wenzhuo Lu
2017-07-31 19:27 ` [dpdk-dev] [RFC PATCH 3/3] app/testpmd: a parameter to set max queue per VF Wenzhuo Lu
2017-12-15 19:24 ` Ferruh Yigit [this message]
2017-12-22 2:26 ` [dpdk-dev] [RFC PATCH 0/3] configurable max queue number " Ferruh Yigit
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=dd4aee93-2c3f-0936-1c19-8cd0fc21e245@intel.com \
--to=ferruh.yigit@intel.com \
--cc=dev@dpdk.org \
--cc=wenzhuo.lu@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).