From: "Wu, Jingjing" <jingjing.wu@intel.com>
To: Thomas Monjalon <thomas.monjalon@6wind.com>,
"Zhang, Helin" <helin.zhang@intel.com>
Cc: "Mcnamara, John" <john.mcnamara@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] i40e queues per VF
Date: Thu, 16 Feb 2017 13:58:39 +0000 [thread overview]
Message-ID: <9BB6961774997848B5B42BEC655768F810CDE4AF@SHSMSX103.ccr.corp.intel.com> (raw)
In-Reply-To: <32336171.7h5g7kEJXa@xps13>
> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas.monjalon@6wind.com]
> Sent: Tuesday, February 14, 2017 6:07 PM
> To: Zhang, Helin <helin.zhang@intel.com>; Wu, Jingjing <jingjing.wu@intel.com>
> Cc: Mcnamara, John <john.mcnamara@intel.com>; dev@dpdk.org
> Subject: i40e queues per VF
>
> Hi,
>
> When reading the documentation, it is not easy to understand the capability of
> i40evf for the number of queues.
>
> First, please could you explain why we need a build-time config option?
> In the doc, there is neither justification nor tuning guidelines:
>
> http://dpdk.org/doc/guides/nics/i40e.html#config-file-options
> "
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_PF (default 64) Number of
> queues reserved for PF.
> CONFIG_RTE_LIBRTE_I40E_QUEUE_NUM_PER_VF (default 4) Number of
> queues reserved for each SR-IOV VF.
> "
This number is used as initialization time to allocate queue number
for PF/VF for HW's queue pool. Will add more description in i40e.rst.
>
> I feel these are hard limits and should be some constants in the code, not some
> build configuration options.
>
> The other doc to look at is:
> http://dpdk.org/doc/guides/nics/intel_vf.html#intel-fortville-10-40-gigabit-
> ethernet-controller-vf-infrastructure
> "
> Each VF can have a maximum of 16 queue pairs.
> "
>
> Do we agree that a queue pair is 1 Rx queue / 1 Tx queue?
> Note: the concept of queue pairs in Intel VF should be explained somewhere.
>
Yes.
> Below, a different limitation is given:
> "
> The available queue number(at most 4) per VF depends on the total number of
> pool, which is determined by the max number of VF at PF initialization stage and
> the number of queue specified in config "
>
I think there may be some inconsistent description in doc intel_vf.rst due to
Multiple kinds of NICs. We should correct them.
Thanks for pointing that.
> So what is the real maximum of queue pairs? 4 or 16?
> The datasheet talks about 16 queues. Is it 8 pairs?
That's is 16 queue pairs. 16 RX queues and 16 Tx queues.
>
> Is there something to configure the number of queues when creating VF with the
> kernel driver?
In kernel driver, it seems at most only 4 queues are supported. That's
Why we add build-time config option to make more queues are possible.
Thanks
Jingjing
next prev parent reply other threads:[~2017-02-16 13:58 UTC|newest]
Thread overview: 7+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-02-14 10:07 Thomas Monjalon
2017-02-16 10:03 ` Xu, Qian Q
2017-02-16 13:58 ` Wu, Jingjing [this message]
2017-02-16 14:55 ` Thomas Monjalon
2017-03-08 11:25 ` Thomas Monjalon
2017-03-14 9:31 ` Thomas Monjalon
2017-03-21 6:01 ` Wu, Jingjing
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=9BB6961774997848B5B42BEC655768F810CDE4AF@SHSMSX103.ccr.corp.intel.com \
--to=jingjing.wu@intel.com \
--cc=dev@dpdk.org \
--cc=helin.zhang@intel.com \
--cc=john.mcnamara@intel.com \
--cc=thomas.monjalon@6wind.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).