Hi Cristian,
Thank you very much for your points and it should really help me in fixing few issues we might have. thanks again ! Regards, srikanth On Thu, Nov 6, 2014 at 12:37 PM, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > Hi Srikanth, > > > > >>Is there any difference between scheduler behavior for above two > scenarios while enqueing and de-queueing ?? > > All the pipe queues share the bandwidth allocated to their pipe. The > distribution of available pipe bandwidth between the pipe queues is > governed by features like traffic class strict priority, bandwidth sharing > between pipe traffic classes, weights of the queues within the same traffic > class, etc. In the case you mention, you are just using one queue for each > traffic class. > > > > Let?s take an example: > > - Configuration: pipe rate = 10 Mbps, pipe traffic class 0 .. 3 > rates = [20% of pipe rate = 2 Mbps, 30% of pipe rate = 3 Mbps, 40% of pipe > rate = 4 Mbps, 100% of pipe rate = 10 Mbps]. Convention is that traffic > class 0 is the highest priority. > > - Injected traffic per traffic class for this pipe: [3, 0, 0, 0] > Mbps => Output traffic per traffic class for this pipe: [2 , 0, 0, 0] Mbps > > - Injected traffic per traffic class for this pipe: [0, 0, 0, 15] > Mbps => Output traffic per traffic class for this pipe: [0, 0, 0, 10] Mbps > > - Injected traffic per traffic class for this pipe: [1, 10, 2, 15] > Mbps => Output traffic per traffic class for this pipe: [1, 3, 2, 4] Mbps > > > > Makes sense? > > > > >>Queue size is 64 , and number of packets enqueued and dequeued is 64 as > well. > > I strongly recommend you never use a dequeue burst size that is equal to > enqueue burst size, as performance will be bad. > > > > In the qos_sched sample app, we use [enqueue burst size, dequeue burst > size] set to [64, 32], other reasonable values could be [64, 48], [32, 16], > etc. An enqueue burst bigger than dequeue burst will cause the big packet > reservoir which is the traffic manager/port scheduler to fill up to a > reasonable level that will allow dequeu to function optimally, and then the > system regulates itself. > > > > The reason is: since we interlace enqueue and dequeue calls, if you push > on every iteration e.g. 64 packets in and then look to get 64 packets out, > you?ll only have 64 packets into the queues, then you?ll work hard to find > them, and you get out exactly those 64 packets that you pushed in. > > > > >>And what is the improvements i would gain if i move to DPDK 1.7 w.r.t > QOS ? > > The QoS code is pretty stable since release 1.4, not many improvements > added (maybe it?s the right time to revisit this feature and push it to the > next level ?), but there are improvements in other DPDK libraries that are > dependencies for QoS (e.g. packet Rx/Tx). > > > > Hope this helps. > > > > Regards, > > Cristian > > > > > > > > *From:* Srikanth Akula [mailto:srikanth044 at gmail.com] > *Sent:* Thursday, October 30, 2014 4:10 PM > *To:* dev at dpdk.org; Dumitrescu, Cristian > *Subject:* Max throughput Using QOS Scheduler > > > > Hello All , > > > > I am currently trying to implement QOS scheduler using DPDK 1.6 . I have > configured 1 subport , 4096 pipes for the sub port and 4 TC's and 4 Queues . > > > > Currently i am trying to send packets destined to single Queue of the > available 16 queues of one of the pipe . > > > > Could some body explain what could be the throughput we can achieve using > this scheme. The reason for asking this is , i could sense different > behavior each time when i send traffic destined to different destination > Queues . > > > > for example : > > > > 1. << Only one stream>>> Stream destined Q0 of TC0 .. > > > > > > 2. << 4 streams >>>> 1st Stream destined for Q3 of Tc3 ... > > 2nd stream destined for Q2 of Tc2 > > 3rd stream destined for Q1 of TC1 > > 4th Stream destined for Q0 of TC0 > > > > Is there any difference between scheduler behavior for above two > scenarios while enqueing and de-queueing ?? > > > > Queue size is 64 , and number of packets enqueud and dequeued is 64 as > well. > > And what is the improvements i would gain if i move to DPDK 1.7 w.r.t QOS ? > > > > > > Could you please clarify my queries ? > > > > > > Thanks & Regards, > Srikanth > > > > > > -------------------------------------------------------------- > Intel Shannon Limited > Registered in Ireland > Registered Office: Collinstown Industrial Park, Leixlip, County Kildare > Registered Number: 308263 > Business address: Dromore House, East Park, Shannon, Co. Clare > > This e-mail and any attachments may contain confidential material for the > sole use of the intended recipient(s). Any review or distribution by others > is strictly prohibited. If you are not the intended recipient, please > contact the sender and delete all copies. > >
