DPDK usage discussions
 help / color / mirror / Atom feed
From: Nikhil Jagtap <nikhil.jagtap@gmail.com>
To: dev@dpdk.org, "Dumitrescu,
	Cristian" <cristian.dumitrescu@intel.com>,
	users@dpdk.org
Subject: Re: [dpdk-users] qos: traffic shaping at queue level
Date: Fri, 30 Sep 2016 09:42:06 +0530	[thread overview]
Message-ID: <CANKBMf1jFJ_1kft6v0UTWrJxh9idsPzj03qoqY-5oLM3a1tFbA@mail.gmail.com> (raw)
In-Reply-To: <CANKBMf2S5n2KxvjWo5Y73oQQ7qePc_x54BFDdo3Pb55jXtZgXA@mail.gmail.com>

Hi,
Can someone please answer my queries?
I tried using queue weights to distribute traffic-class bandwidth among the
child queues, but did not get the desired results.

Regards,
Nikhil

On 27 September 2016 at 15:34, Nikhil Jagtap <nikhil.jagtap@gmail.com>
wrote:

> Hi,
>
> I have a few questions about the hierarchical scheduler. I am taking a
> simple example here to get a better understanding.
>
> Reference example:
>   pipe rate = 30 mbps
>   tc 0 rate = 30 mbps
>   traffic-type 0 being queued to queue 0, tc 0.
>   traffic-type 1 being queued to queue 1, tc 0.
>   Assume traffic-type 0 is being received at the rate of 25 mbps.
>   Assume traffic-type 1 is also being received at the rate of 25 mbps.
>
> Requirement:
>   To limit traffic-type 0 to (CIR =  5 mbps, PIR = 30 mbps), AND
>       limit traffic-type 1 to (CIR = 25 mbps, PIR = 30 mbps).
>
> The questions:
> 1) I understand that with the scheduler, it is possible to do rate
> limiting only at the sub-port and pipe levels and not at the individual
> queue level. Is it possible to achieve rate limiting using the notion of
> queue weights? For the above example, will assigning weights in 1:5 ratio
> to the two queues help achieve shaping the two traffic-types at the two
> different rates?
>
> 2) In continuation to previous question: if queue weights don't help,
> would it be possible to use metering to achieve rate limiting? Assume we
> meter individual traffic-types (using CIR-PIR config mentioned above)
> before queuing it to the scheduler queues. So to achieve the respective
> queue rates, the dequeuer would be expected to prioritise green packets
> over yellow.
> Looking into the code, the packet color is used as an input to the dropper
> block, but does not seem to be used anywhere in the scheduler. So I guess
> it is not possible to prioritise green packets when dequeing?
>
> Regards,
> Nikhil
>
>

       reply	other threads:[~2016-09-30  4:12 UTC|newest]

Thread overview: 4+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
     [not found] <CANKBMf2S5n2KxvjWo5Y73oQQ7qePc_x54BFDdo3Pb55jXtZgXA@mail.gmail.com>
2016-09-30  4:12 ` Nikhil Jagtap [this message]
2016-10-03 18:12   ` Dumitrescu, Cristian
2016-10-05  7:09     ` Nikhil Jagtap
2016-10-11 14:11       ` 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=CANKBMf1jFJ_1kft6v0UTWrJxh9idsPzj03qoqY-5oLM3a1tFbA@mail.gmail.com \
    --to=nikhil.jagtap@gmail.com \
    --cc=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    --cc=users@dpdk.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).