Re: [dpdk-dev] DPDK-QoS - link sharing across classes

[sreenaath vasudevan <sreenaathkv@gmail.com>]

Hi Cristian
Thanks for detailed response.
Your solution works so long as I have four queues in my current
implementation.

Following are the two issues I have now
1. I have 8 queues in the current implementation. This means I need to map
the existing 8 queues to two sets of 4 queues across two different classes
(C0 and C1) in DPDK-QOs right? The problem with that approach is that queue
weights are not relative across classes. Is there a way to work around this?
2. B/w redistribution -
     a) The moment I map the current implementation's 8 queues across two
different classes (say C0 and C1), would remaining b/w be distributed
across the two classes C0 and C1? Is it true that in the current DPDK-QoS
implementation, unused b/w gets distributed only to the last class C3?
Would not un-used b/w from C0 come to C1?
     b) In current DPDK QoS implemention, if C1 has un-used b/w would that
get used by C0? Or is it only "lower priority class (C3, more specifically)
uses the un-used b/w from higher priority classes (C0,C1,C2) ?




On Tue, Feb 16, 2016 at 2:46 PM, Dumitrescu, Cristian <
cristian.dumitrescu@intel.com> wrote:

>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of sreenaath
> > vasudevan
> > Sent: Tuesday, February 2, 2016 9:09 PM
> > To: dev@dpdk.org
> > Subject: [dpdk-dev] DPDK-QoS - link sharing across classes
> >
> > Hi
> > I currently have QoS implemented in hardware and I am thinking of using
> > DPDK's QoS feature to move it to software.
> > Currently in the hardware,Based on the 4 class per pipe and 4 queues per
> > class limitation, I was thinking of using 4 classes in DPDK-QoS and
> spread
> > out the 8 h/w queues across the 4 classes.
> > Let me explain with an example. Currently, this is how the h/w queue is
> > represented
> > Q0 - 10% b/w
> > Q1- 10%  b/w
> > Q2- 15% b/w
> > Q3 - 15% b/w
> > Q4 - 15% b/w
> > Q5 - 15% b/w
> > Q6 - 10% b/w
> > Q7 - 10% b/w
> >
> > Translating the above config to DPDK-QoS, based on my application need,
> Q0
> > and Q1 can be logically grouped under class0 with upper b/w = 20%; Q2,
> Q3,
> > Q4, Q5 can be logically grouped under class2 with upper b/w = 60%; Q6 and
> > Q7 can be logically grouped under class 3 with super b/w = 20%.
> >
> > However, in the h/w, link sharing is available across all the 8 queues.
> > DPDK materials say link sharing "typically" is enabled for last class, in
> > this case class2. However, I also want class 1 or class 0 to use the
> > remaining bandwidth when class2 does not have any traffic and so on. Can
> > this be done in DPDK ? Do we have a concept of min and max b/w guarantee
> > at
> > the class level in DPDK-QoS ?
>
> Your requirements seem to be:
> - minimal rate for each class (with rates fully provisioned, i.e. sum of
> rate not exceeding 100%)
> - avoid b/w waste by redistributing unused b/w to the traffic classes that
> currently have traffic according to their relative weights
>
> In our implementation, traffic classes are scheduled in strict priority
> (with upper limit defined, to avoid starvation), so TC0 traffic is always
> prioritized for the current pipe over TC1 .. TC3 traffic (as long as
> current pipe has TC0 traffic and pipe TC0 rate is not reached). Therefore,
> the traffic class hierarchy level is not going to help you here.
>
> On the other hand, if you map all your queues/traffic classes to the
> queues of one of our pipe traffic classes (it does not matter which one of
> TC0 .. TC3 you pick, as long as you pick just one), your requirements
> become possible, as we have 4 queues per each pipe traffic class, and they
> are scheduled using weighted fair queuing (byte-level weighted round
> robin). Simply map your class0  to our pipe TC0 queue 0 (weight of 20%),
> your class2 to our pipe TC0 queue 1 (weight of 60%) and your class3 to our
> pipe TC0 queue 2 (weight of 20%), with our pipe TC0 queue 3 unused, which
> should work exactly what you need. Makes sense?
>
> Regards,
> Cristian
>
> >
> > Thanks !
> >
> > --
> > regards
> > sreenaath
>



-- 
regards
sreenaath