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

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

> -----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