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:srikanth...@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.
