Hello Cristian, Are the slides shown in that video available? They're very helpful.
-Mike On Fri, Jun 5, 2015 at 4:50 PM, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > Hi Avinash, > > > -----Original Message----- > > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Yeddula, Avinash > > Sent: Friday, June 5, 2015 6:06 PM > > To: dev at dpdk.org > > Subject: [dpdk-dev] 4 Traffic classes per Pipe limitation > > > > Hi, > > This is related to the QOS scheduler functionality provided by dpdk. > > > > I see a limit on the number of traffic classes to be 4. I'm exploring > the > > available options to increase that limit to 8. > > Yes, there are 4x traffic classes (scheduled in strict priority), but each > traffic class has 4x queues (scheduled using WFQ); for big weight ratios > between queues (e.g. 1:4 or 1:8, etc), WFQ becomes very similar to strict > priority, a king of strict priority without starvation. So the 16x queues > per pipe can be considered 16x sub-traffic-classes. > > You might want to watch this video on DPDK QoS: > https://youtu.be/_PPklkWGugs > > > > > This is what I found when I researched on this topic. > > The limitation on number's of TC (and pipes) comes from the number of > > bits available. Since the QoS code overloads the 32 bit RSS field in > > the mbuf there isn't enough bits to a lot. But then again if you add lots > > of pipes or subports the memory footprint gets huge. > > It is not that simple. The number of 4x traffic classes in deeply built > into the implementation for performance reasons. Increasing the number of > bits allocated to traffic class in mbuf->sched would not help. > > > > > Any more info or suggestions on increasing the limit to 8 ? > > Yes, look at the 16x pipe queues as 16x (sub)traffic classes. > > > > Thanks > > -Avinash >
