From: Saber Rezvani <irsaber@zoho.com>
To: "Wiles, Keith" <keith.wiles@intel.com>
Cc: Stephen Hemminger <stephen@networkplumber.org>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] IXGBE throughput loss with 4+ cores
Date: Tue, 28 Aug 2018 23:46:34 +0430 [thread overview]
Message-ID: <9e7b00bb-285b-fe37-f298-6d20d47a77ec@zoho.com> (raw)
In-Reply-To: <CC7A1A46-ED26-415E-AB52-BEA9AAEBBD7A@intel.com>
On 08/28/2018 11:39 PM, Wiles, Keith wrote:
> Which version of Pktgen? I just pushed a patch in 3.5.3 to fix a performance problem.
I use Pktgen verion 3.0.0, indeed it is O.k as far as I have one core.
(10 Gb/s) but when I increase the number of core (one core per queue)
then I loose some performance (roughly 8.5 Gb/s for 8-core). In my
scenario Pktgen shows it is generating at line rate, but receiving 8.5 Gb/s.
Is it because of Pktgen???
>
>> On Aug 28, 2018, at 12:05 PM, Saber Rezvani <irsaber@zoho.com> wrote:
>>
>>
>>
>> On 08/28/2018 08:31 PM, Stephen Hemminger wrote:
>>> On Tue, 28 Aug 2018 17:34:27 +0430
>>> Saber Rezvani <irsaber@zoho.com> wrote:
>>>
>>>> Hi,
>>>>
>>>>
>>>> I have run multi_process/symmetric_mp example in DPDK example directory.
>>>> For a one process its throughput is line rate but as I increase the
>>>> number of cores I see decrease in throughput. For example, If the number
>>>> of queues set to 4 and each queue assigns to a single core, then the
>>>> throughput will be something about 9.4. if 8 queues, then throughput
>>>> will be 8.5.
>>>>
>>>> I have read the following, but it was not convincing.
>>>>
>>>> http://mails.dpdk.org/archives/dev/2015-October/024960.html
>>>>
>>>>
>>>> I am eagerly looking forward to hearing from you, all.
>>>>
>>>>
>>>> Best wishes,
>>>>
>>>> Saber
>>>>
>>>>
>>> Not completely surprising. If you have more cores than packet line rate
>>> then the number of packets returned for each call to rx_burst will be less.
>>> With large number of cores, most of the time will be spent doing reads of
>>> PCI registers for no packets!
>> Indeed pktgen says it is generating traffic at line rate, but receiving less than 10 Gb/s. So, it that case there should be something that causes the reduction in throughput :(
>>
>>
> Regards,
> Keith
>
next prev parent reply other threads:[~2018-08-28 19:16 UTC|newest]
Thread overview: 11+ messages / expand[flat|nested] mbox.gz Atom feed top
2018-08-28 13:04 Saber Rezvani
2018-08-28 16:01 ` Stephen Hemminger
2018-08-28 17:05 ` Saber Rezvani
2018-08-28 19:09 ` Wiles, Keith
2018-08-28 19:16 ` Saber Rezvani [this message]
2018-08-28 21:09 ` Wiles, Keith
2018-08-29 17:19 ` Saber Rezvani
2018-08-29 18:52 ` Wiles, Keith
2018-08-30 4:08 ` Saber Rezvani
2018-09-06 6:10 Saber Rezvani
2018-09-06 17:48 ` Wiles, Keith
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=9e7b00bb-285b-fe37-f298-6d20d47a77ec@zoho.com \
--to=irsaber@zoho.com \
--cc=dev@dpdk.org \
--cc=keith.wiles@intel.com \
--cc=stephen@networkplumber.org \
/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).