DPDK patches and discussions
 help / color / mirror / Atom feed
From: "Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>
To: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] How to guarantee bandwith using DPDK QoS library?
Date: Wed, 9 Oct 2013 12:02:37 +0000	[thread overview]
Message-ID: <3EB4FA525960D640B5BDFFD6A3D891261A5AFBA8@IRSMSX102.ger.corp.intel.com> (raw)
In-Reply-To: <2b472bcc.931c.14195d8fc5e.Coremail.mydpdk@126.com>

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.

      reply	other threads:[~2013-10-09 12:02 UTC|newest]

Thread overview: 2+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2013-10-08  2:15 William Rolinson
2013-10-09 12:02 ` Dumitrescu, Cristian [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=3EB4FA525960D640B5BDFFD6A3D891261A5AFBA8@IRSMSX102.ger.corp.intel.com \
    --to=cristian.dumitrescu@intel.com \
    --cc=dev@dpdk.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).