DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: Wei Shen <wshen0123@outlook.com>, "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] Order of system brought up affects throughput with	qos_sched app
Date: Wed, 9 Sep 2015 19:54:12 +0000	[thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D89126478B9630@IRSMSX108.ger.corp.intel.com> (raw)
In-Reply-To: <BAY174-W3150A526CEA3129F4BF89BB520@phx.gbl>

Hi Wei,

Here is another hypothesis for you to consider: if the size of your token buckets (used to store subport and pipe credits) is big (and it actually is set big in the default config file of the app), then when no packets are received for a long while (which is the case when you start the app first and the traffic gen later), the token buckets are continuously replenished (with nothing consumed) until they become full; when packets start to arrive, the token buckets are full and it can take a long time (might be minutes or even hours, depending on how big your buckets are) until they come down to their normal values (this time can actually be comuted/estimated).

If this is what happens in your case, lowering the size of your buckets will help.

Regards,
Cristian

> -----Original Message-----
> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Wei Shen
> Sent: Wednesday, September 9, 2015 9:39 PM
> To: dev@dpdk.org
> Subject: [dpdk-dev] Order of system brought up affects throughput with
> qos_sched app
> 
> Hi all,
> I ran into problems with qos_sched with different order of system brought
> up. I can bring up the system in two ways:
> 1. Start traffic gen first. Then start qos_sched.2. Start qos_sched first. Then
> start traffic gen.
> With 256K pipes and 64 queue size, 128B packet size, I got ~4Gbps with order
> #1. While I got 10G with order #2.
> qos_sched command stats showed that ~59% packets got dropped in RX
> (rte_ring_enqueue).
> Plus, with #1, if I restart the traffic gen later, I would regain 10Gbps
> throughput, which suggests that this is not an initialization issue but runtime
> behavior.
> I also tried to assign qos_sched on different cores and got the same result.
> I suspect that there is some rte_ring bugs when connecting two cores and
> one core started enqueuing before another core is ready for dequeue.
> Have you experienced the same issue? Appreciate your help.
> 
> Wei Shen.---------------------------------------------------------------------------------
> ---------------------------------------------------My system spec is:Intel(R) Xeon(R)
> CPU E5-2699 v3 @ 2.30GHz15 * 1G hugepages
> qos_sched argument: ./build/app/qos_sched -c 1c0002 -n 4 -- --pfc
> "0,1,20,18,19" --cfg profile.cfg
> profile.cfg:[port]frame overhead = 20number of subports per port =
> 1number of pipes per subport = 262144queue sizes = 64 64 64 64
> 
> ; Subport configuration[subport 0]tb rate = 1250000000           ; Bytes per
> secondtb size = 1000000                 ; Bytes
> tc 0 rate = 1250000000         ; Bytes per secondtc 1 rate = 1250000000         ;
> Bytes per secondtc 2 rate = 1250000000         ; Bytes per secondtc 3 rate =
> 1250000000         ; Bytes per secondtc period = 10                        ; Milliseconds
> pipe 0-262143 = 0                ; These pipes are configured with pipe profile 0
> ; Pipe configuration[pipe profile 0]tb rate = 1250000000           ; Bytes per
> secondtb size = 1000000                 ; Bytes
> tc 0 rate = 1250000000         ; Bytes per secondtc 1 rate = 1250000000         ;
> Bytes per secondtc 2 rate = 1250000000         ; Bytes per secondtc 3 rate =
> 1250000000         ; Bytes per secondtc period = 10                        ; Milliseconds
> tc 3 oversubscription weight = 1
> tc 0 wrr weights = 1 1 1 1tc 1 wrr weights = 1 1 1 1tc 2 wrr weights = 1 1 1 1tc 3
> wrr weights = 1 1 1 1

  reply	other threads:[~2015-09-09 19:54 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2015-09-09 18:39 Wei Shen
2015-09-09 19:54 ` Dumitrescu, Cristian [this message]
2015-09-09 22:47   ` Wei Shen
2015-09-10 12:16     ` Dumitrescu, Cristian

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=3EB4FA525960D640B5BDFFD6A3D89126478B9630@IRSMSX108.ger.corp.intel.com \
    --to=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=wshen0123@outlook.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).