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
>
>
next parent 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).