[dpdk-dev] How to guarantee bandwith using DPDK QoS library?

[dpdk-dev] How to guarantee bandwith using DPDK QoS library?

[William Rolinson]

 Apologies if this is a dumb question, but how can we guarantee bandwith with librte_sched like what HTB do in Linux?

Re: [dpdk-dev] How to guarantee bandwith using DPDK QoS library?

[Dumitrescu, Cristian]

Hi,

Yes, bandwidth can be guaranteed to pipes (users) and subports (groups of users) through the traffic shaping feature.

I am also providing a bit more information below, maybe anticipating some of the future questions.

1. Traffic shaping for pipes and subports
Basically, each pipe and each subport get assigned a rate, which represents exactly the amount of traffic the respective pipe / subport is allowed to send.
Of course, this rate will be saturated only when that pipe / subport has enough demand (input traffic) and there are no other restrictions triggered at other levels in the hierarchy affecting this pipe / subport. 
For example, the pipe might have enough credits to send more packets, but unable to do so because all its input traffic is currently best effort (traffic class 3) and the subport level limit for best effort traffic class has been reached.

2. Bandwidth sharing between subports or between pipes: NO
Please note that, unlike HTB, there is no bandwidth sharing between different subports or between different pipes within the same subport.
This is because the requirement set for Intel DPDK hierarchical scheduler is suitable for telecom environments, where each user pays for a specific service level (e.g. rate). 
At every moment, out of many thousands of users (i.e. thousands of pipes) in the network, only a relatively small fraction is active (have demand), so allowing the active users to reuse the bandwidth left unused by the inactive users will usually result in those users getting a significantly better service level for extended periods of time for free. Paying for the lowest service while getting the best service is not particularly appealing to operators.
HTB bandwidth borrowing concept is probably more suitable for LAN networks, where there are multiple users, machines, applications, etc sharing the same WAN link. As the service paid for is the WAN link, it does not really matter who is using the excess bandwidth, as long as every user is getting a minimum/guaranteed rate, so the borrowing/link sharing is encouraged, as the ultimate interest is to use the WAN link efficiently/as much as possible. The HTB sharing is done in a hierarchical way starting from the bottom of the hierarchy, so whatever I am not using, my family can use; whatever my family is not using, my neighbourhood can use; whatever my neighbourhood is not using, my city can use; so on so forth for county, country, continent, planet, galaxy :)

3. Bandwidth sharing within the same pipe: YES
Yes, the bandwidth sharing is possible between the connections belonging to the same user.
Whatever rate was assigned to higher priority traffic classes for a specific pipe, when not used for these traffic classes (because the pipe currently does not have demand for those traffic classes), it can be used by the same pipe to serve its lower priority traffic classes.
A user (pipe) can have multiple connections at the same time: some voice connections, some video connections and some data transfers which typically get mapped to different traffic classes and queues within traffic classes of the same user (16 queues per pipe, split into 4 traffic classes with 4 queues each).
The traffic classes are scheduled in strict priority, so e.g. we do not send out any FTP packets (typically traffic class 3, low priority) while we have voice or video packets (typically traffic class 0 and 1, high priority). Although there is a rate assigned to each traffic class for a specific pipe, the sum of all traffic class rates can be bigger than 100%. For example, we can configure voice (TC0) as 10% of pipe rate, video (TC1) as 20% of pipe rate, cached video (TC2) as 30% of pipe rate and data transfers as 100% of the pipe rate. The pipe rate will never be exceeded, but whenever there is no voice or video or cached video traffic for this pipe, the data transfers can use up to 100% of the pipe rate.

Hope this helps!

Regards,
Cristian

-----Original Message-----
From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of William Rolinson
Sent: Tuesday, October 8, 2013 3:15 AM
To: dev@dpdk.org
Subject: [dpdk-dev] How to guarantee bandwith using DPDK QoS library?

 Apologies if this is a dumb question, but how can we guarantee bandwith with librte_sched like what HTB do in Linux?
--------------------------------------------------------------
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.