From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-vk0-f47.google.com (mail-vk0-f47.google.com [209.85.213.47]) by dpdk.org (Postfix) with ESMTP id 2211FC424 for ; Thu, 18 Feb 2016 21:01:13 +0100 (CET) Received: by mail-vk0-f47.google.com with SMTP id e185so55036776vkb.1 for ; Thu, 18 Feb 2016 12:01:13 -0800 (PST) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:date:message-id:subject:from:to :cc:content-type; bh=L3M1S+CD9vn03NYdcxqpYh22VfNmg8o0W6EE6CFRIM0=; b=lfP/LGego+gesugz/p8sl90+rJFyloKXCxiCPf/OXSDnmkX+I0TZSnCbyq260hpbW4 5E47yfpDRRqGOQN0ASaXEVZvmkwC0YO8FKwoO1c+egY/oqcPTa+9k3WijYV90TvoLDFe Lzc73GhmYochRcEmeSnYirSNiPnWY2+hlt14hDHCJSX9af4jI3DdFYzPxR0QF5zpmClS LzGdrKjLez0xH3KLKUP+43F8fEyKkGVS+maTOKl6gWFJFTr0fOR5UlC74RCMdfL8kJ1A t/5CrkwTzk1yd6gdsS2iIPSXlJqeVe1haA21TpJK3w9e0R4yoF5gYAkRW/lYrhb0R00L 6adg== X-Google-DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=1e100.net; s=20130820; h=x-gm-message-state:mime-version:in-reply-to:references:date :message-id:subject:from:to:cc:content-type; bh=L3M1S+CD9vn03NYdcxqpYh22VfNmg8o0W6EE6CFRIM0=; b=IFE8Lt8rn1vaVAhW82AGwPY7TBdy73oqVXBt17/UmzOP3x1FPLWGAjf6dY00aLkZWe ePZzs59sspAT3niA23WXE5yjy4Dkzv7gF7mo9sKeKJ8aeOw9WLBsqG+Lwf8TrsQiv+i6 UKJgWQ9WRbEhSpiG8w2wieF8EXl03/phdaoRN3+FX4PbkmF1fgr7NawrruwLiK5m0nrJ N4xASUYo5CT1BbpeKeKT0EnpSujYdFyZNzR3jGNdHDbU+qTL6vr39p5MjCbg4oNQ+/Wa N6qdypAQPoI5NeUTU4lNzI7KQbfI5rPLrgJ218HE/OsCltLErouxlzM+V1SYVi5tigoI 4XtA== X-Gm-Message-State: AG10YOSE9a0NEleQB4qxG/UC2rMDeIS7150IwDJJD35mK6DHBXT/wa3v6QhgxnXj6rDuraXJvygh5L54t+Wo4g== MIME-Version: 1.0 X-Received: by 10.31.149.135 with SMTP id x129mr7769992vkd.62.1455825672550; Thu, 18 Feb 2016 12:01:12 -0800 (PST) Received: by 10.159.32.45 with HTTP; Thu, 18 Feb 2016 12:01:12 -0800 (PST) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647952060@IRSMSX108.ger.corp.intel.com> References: <3EB4FA525960D640B5BDFFD6A3D8912647952060@IRSMSX108.ger.corp.intel.com> Date: Thu, 18 Feb 2016 12:01:12 -0800 Message-ID: From: sreenaath vasudevan To: "Dumitrescu, Cristian" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] DPDK-QoS - link sharing across classes 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: Thu, 18 Feb 2016 20:01:13 -0000 Hi Cristian Thanks for detailed response. Your solution works so long as I have four queues in my current implementation. Following are the two issues I have now 1. I have 8 queues in the current implementation. This means I need to map the existing 8 queues to two sets of 4 queues across two different classes (C0 and C1) in DPDK-QOs right? The problem with that approach is that queue weights are not relative across classes. Is there a way to work around this? 2. B/w redistribution - a) The moment I map the current implementation's 8 queues across two different classes (say C0 and C1), would remaining b/w be distributed across the two classes C0 and C1? Is it true that in the current DPDK-QoS implementation, unused b/w gets distributed only to the last class C3? Would not un-used b/w from C0 come to C1? b) In current DPDK QoS implemention, if C1 has un-used b/w would that get used by C0? Or is it only "lower priority class (C3, more specifically) uses the un-used b/w from higher priority classes (C0,C1,C2) ? On Tue, Feb 16, 2016 at 2:46 PM, Dumitrescu, Cristian < cristian.dumitrescu@intel.com> wrote: > > > > -----Original Message----- > > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of sreenaath > > vasudevan > > Sent: Tuesday, February 2, 2016 9:09 PM > > To: dev@dpdk.org > > Subject: [dpdk-dev] DPDK-QoS - link sharing across classes > > > > Hi > > I currently have QoS implemented in hardware and I am thinking of using > > DPDK's QoS feature to move it to software. > > Currently in the hardware,Based on the 4 class per pipe and 4 queues per > > class limitation, I was thinking of using 4 classes in DPDK-QoS and > spread > > out the 8 h/w queues across the 4 classes. > > Let me explain with an example. Currently, this is how the h/w queue is > > represented > > Q0 - 10% b/w > > Q1- 10% b/w > > Q2- 15% b/w > > Q3 - 15% b/w > > Q4 - 15% b/w > > Q5 - 15% b/w > > Q6 - 10% b/w > > Q7 - 10% b/w > > > > Translating the above config to DPDK-QoS, based on my application need, > Q0 > > and Q1 can be logically grouped under class0 with upper b/w = 20%; Q2, > Q3, > > Q4, Q5 can be logically grouped under class2 with upper b/w = 60%; Q6 and > > Q7 can be logically grouped under class 3 with super b/w = 20%. > > > > However, in the h/w, link sharing is available across all the 8 queues. > > DPDK materials say link sharing "typically" is enabled for last class, in > > this case class2. However, I also want class 1 or class 0 to use the > > remaining bandwidth when class2 does not have any traffic and so on. Can > > this be done in DPDK ? Do we have a concept of min and max b/w guarantee > > at > > the class level in DPDK-QoS ? > > Your requirements seem to be: > - minimal rate for each class (with rates fully provisioned, i.e. sum of > rate not exceeding 100%) > - avoid b/w waste by redistributing unused b/w to the traffic classes that > currently have traffic according to their relative weights > > In our implementation, traffic classes are scheduled in strict priority > (with upper limit defined, to avoid starvation), so TC0 traffic is always > prioritized for the current pipe over TC1 .. TC3 traffic (as long as > current pipe has TC0 traffic and pipe TC0 rate is not reached). Therefore, > the traffic class hierarchy level is not going to help you here. > > On the other hand, if you map all your queues/traffic classes to the > queues of one of our pipe traffic classes (it does not matter which one of > TC0 .. TC3 you pick, as long as you pick just one), your requirements > become possible, as we have 4 queues per each pipe traffic class, and they > are scheduled using weighted fair queuing (byte-level weighted round > robin). Simply map your class0 to our pipe TC0 queue 0 (weight of 20%), > your class2 to our pipe TC0 queue 1 (weight of 60%) and your class3 to our > pipe TC0 queue 2 (weight of 20%), with our pipe TC0 queue 3 unused, which > should work exactly what you need. Makes sense? > > Regards, > Cristian > > > > > Thanks ! > > > > -- > > regards > > sreenaath > -- regards sreenaath