From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id E2ECE1F3 for ; Wed, 9 Oct 2013 14:02:05 +0200 (CEST) Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP; 09 Oct 2013 04:59:35 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="4.90,1063,1371106800"; d="scan'208";a="390504109" Received: from irsmsx101.ger.corp.intel.com ([163.33.3.153]) by orsmga001.jf.intel.com with ESMTP; 09 Oct 2013 05:02:38 -0700 Received: from irsmsx105.ger.corp.intel.com (163.33.3.28) by IRSMSX101.ger.corp.intel.com (163.33.3.153) with Microsoft SMTP Server (TLS) id 14.3.123.3; Wed, 9 Oct 2013 13:02:37 +0100 Received: from irsmsx102.ger.corp.intel.com ([169.254.2.234]) by IRSMSX105.ger.corp.intel.com ([169.254.7.29]) with mapi id 14.03.0123.003; Wed, 9 Oct 2013 13:02:37 +0100 From: "Dumitrescu, Cristian" To: "dev@dpdk.org" Thread-Topic: [dpdk-dev] How to guarantee bandwith using DPDK QoS library? Thread-Index: AQHOw8yJaeCCeuFnn0mwl8Sl9sRI55nsNT8Q Date: Wed, 9 Oct 2013 12:02:37 +0000 Message-ID: <3EB4FA525960D640B5BDFFD6A3D891261A5AFBA8@IRSMSX102.ger.corp.intel.com> References: <2b472bcc.931c.14195d8fc5e.Coremail.mydpdk@126.com> In-Reply-To: <2b472bcc.931c.14195d8fc5e.Coremail.mydpdk@126.com> Accept-Language: en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-originating-ip: [163.33.239.180] Content-Type: text/plain; charset="us-ascii" MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Subject: Re: [dpdk-dev] How to guarantee bandwith using DPDK QoS library? X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 09 Oct 2013 12:02:07 -0000 Hi, Yes, bandwidth can be guaranteed to pipes (users) and subports (groups of u= sers) through the traffic shaping feature. I am also providing a bit more information below, maybe anticipating some o= f 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 en= ough demand (input traffic) and there are no other restrictions triggered a= t other levels in the hierarchy affecting this pipe / subport. = For example, the pipe might have enough credits to send more packets, but u= nable to do so because all its input traffic is currently best effort (traf= fic 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 differe= nt subports or between different pipes within the same subport. This is because the requirement set for Intel DPDK hierarchical scheduler i= s suitable for telecom environments, where each user pays for a specific se= rvice level (e.g. rate). = At every moment, out of many thousands of users (i.e. thousands of pipes) i= n the network, only a relatively small fraction is active (have demand), so= allowing the active users to reuse the bandwidth left unused by the inacti= ve 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 ope= rators. HTB bandwidth borrowing concept is probably more suitable for LAN networks,= where there are multiple users, machines, applications, etc sharing the sa= me WAN link. As the service paid for is the WAN link, it does not really ma= tter 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 th= e 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 f= amily 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 specifi= c 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 sam= e pipe to serve its lower priority traffic classes. A user (pipe) can have multiple connections at the same time: some voice co= nnections, some video connections and some data transfers which typically g= et 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 que= ues each). The traffic classes are scheduled in strict priority, so e.g. we do not sen= d out any FTP packets (typically traffic class 3, low priority) while we ha= ve 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 pip= e, 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 pi= pe 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 transf= ers 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 wi= th 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 s= ole use of the intended recipient(s). Any review or distribution by others = is strictly prohibited. If you are not the intended recipient, please conta= ct the sender and delete all copies.