From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mail-it0-f44.google.com (mail-it0-f44.google.com [209.85.214.44]) by dpdk.org (Postfix) with ESMTP id A0D4E6CD5; Wed, 5 Oct 2016 09:09:31 +0200 (CEST) Received: by mail-it0-f44.google.com with SMTP id 188so90392613iti.1; Wed, 05 Oct 2016 00:09:31 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s=20120113; h=mime-version:in-reply-to:references:from:date:message-id:subject:to :cc; bh=bEOwQ+KlKjnjr0bt0aYkP+5t78EckfJ6AdhA8EiF+5I=; b=b305Gcjh0kUa7KCa1oCPJaDXP7tzJkl9IVPhJKFuaQAF8he4hd2vxwfGea/BZ31OGD xANrk8Z5Fctx9MtAOdRIJ3H0nAFSbQ57rSw5XHOsx1MyyqWVw1LcQJjMrJZWuk1JLsul wEiasGtmwI3lJMJvt/ie48CEMVMcN+iAShtBZcaK8Lf3Qtp7ciwtgVEbTpEsD/sdCzIB Zxke4VsknCZOKTKZK0GSoxKHLUxDqq9RU4DTMCeCJWhY6tQEcvWwpxQs6JfXWck5DjSt Cd3HlOxsFuFBjLmeaa+NNpmm9BqbHLaoS4nX4JmoZLvOvy436nkYebGlEiSeEt4VKQBW VYXA== 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:from:date :message-id:subject:to:cc; bh=bEOwQ+KlKjnjr0bt0aYkP+5t78EckfJ6AdhA8EiF+5I=; b=QO7lRywwLV+FSKPHWy1Yd0RMhRKt/Hmu8DyEArl6v+RkQEQ/VNDkts7L/SGXdw+MY5 8Pb0mqej4kDLQEvVQ2Ru+eBwiYtBzo9I07NbymrJ2h6EqjT9wnjjjmMgVeV9d3nG59Rq X/qVR1eX8yVAVBoMftLq2pEoQH8/Icdh85x4CGxFX3WCMmlhTM27+bbY750HnhTGYf0N Ow7pB/4/Jd3LwKq8KPSEFk+bkl3OsulRTRKnVeqPHQ5qAMVw7wSpy9eex38e/ratqvjU 6rolheY4FVFR5wydSIDxTx5LLIBKS4TmsNR3tWvTSfTMxwdsp4fJlKgWWXqc2vEDrQDb oCww== X-Gm-Message-State: AA6/9Rnl8jnJAJHP61w5XylVIAHf7FZUWTi00y3wifVjQMiJE0AUZcIZIH3WVF7/iIw9SNzJtNxDsnZzsK9e8A== X-Received: by 10.36.57.215 with SMTP id l206mr27087715ita.5.1475651370964; Wed, 05 Oct 2016 00:09:30 -0700 (PDT) MIME-Version: 1.0 Received: by 10.36.53.23 with HTTP; Wed, 5 Oct 2016 00:09:30 -0700 (PDT) In-Reply-To: <3EB4FA525960D640B5BDFFD6A3D8912647A8D693@IRSMSX108.ger.corp.intel.com> References: <3EB4FA525960D640B5BDFFD6A3D8912647A8D693@IRSMSX108.ger.corp.intel.com> From: Nikhil Jagtap Date: Wed, 5 Oct 2016 12:39:30 +0530 Message-ID: To: "Dumitrescu, Cristian" Cc: "dev@dpdk.org" , "users@dpdk.org" Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-users] qos: traffic shaping at queue level X-BeenThere: users@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: usage discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 05 Oct 2016 07:09:32 -0000 Hi Cristian, Thanks for the info. A few more comments/questions inline. On 3 October 2016 at 23:42, Dumitrescu, Cristian < cristian.dumitrescu@intel.com> wrote: > > > > > *From:* Nikhil Jagtap [mailto:nikhil.jagtap@gmail.com] > *Sent:* Friday, September 30, 2016 7:12 AM > *To:* dev@dpdk.org; Dumitrescu, Cristian ; > users@dpdk.org > *Subject:* Re: qos: traffic shaping at queue level > > > > Hi, > > Can someone please answer my queries? > > I tried using queue weights to distribute traffic-class bandwidth among > the child queues, but did not get the desired results. > > [Cristian] Can you please describe what issues you see? > [Nikhil] At the end of a 20 minute test, the total number of packets dequeued from the respective queues were not in the ratio 1:5. In one other test where 4 equal-rate traffic-streams were hitting 4 different queues of the same TC configured with weights 1:2:4:8, I observed that the queue with highest weight had the least number of dequeued packets when in theory it should have been the one with highest packet count. Regards, > > Nikhil > > > > On 27 September 2016 at 15:34, Nikhil Jagtap > wrote: > > Hi, > > > > I have a few questions about the hierarchical scheduler. I am taking a > simple example here to get a better understanding. > > > > Reference example: > > pipe rate = 30 mbps > > tc 0 rate = 30 mbps > > traffic-type 0 being queued to queue 0, tc 0. > > traffic-type 1 being queued to queue 1, tc 0. > > Assume traffic-type 0 is being received at the rate of 25 mbps. > > Assume traffic-type 1 is also being received at the rate of 25 mbps. > > > > Requirement: > > To limit traffic-type 0 to (CIR = 5 mbps, PIR = 30 mbps), AND > > limit traffic-type 1 to (CIR = 25 mbps, PIR = 30 mbps). > > > > The questions: > > 1) I understand that with the scheduler, it is possible to do rate > limiting only at the sub-port and pipe levels and not at the individual > queue level. > > [Cristian] Yes, correct, only subports and pipes own token buckets, with > all the pipe traffic classes and queues sharing their pipe token bucket. > > > > Is it possible to achieve rate limiting using the notion of queue weights? > For the above example, will assigning weights in 1:5 ratio to the two > queues help achieve shaping the two traffic-types at the two different > rates? > > [Cristian] Yes. However, getting the weight observed accurately relies on > all the queues being backlogged (always having packets to dequeue). When a > pipe and certain TC is examined for dequeuing, the relative weights are > enforced between the queues that have packets at that precise moment in > time, with the empty queues being ignored. The fully backlogged scenario is > not taking place in practice, and the set of non-empty queues changes over > time. As said it the past, having big relative weight ratios between queues > helps (1:5 should be good). > > [Nikhil] I see. So I guess not having fully backlogged queues could be one of the reasons for the observations I mentioned above where the weights-ratio does not directly translate into rate-ratio. I think I should also mention that there was no pipelining i.e. packet-processing, queueing, dequeing was all being done inline in a run-to-completion model. a) Would having some kind of pipelining help achieve better rate-ratio? May be say atleast splitting the enqueue and dequeue operations? b) If pipelining is not an option, what would be the recommended values for enqueue and dequeue packet count in the run-to-completion model? You have mentioned in one of your presentations to use different values for these two. If I go with (enqueue# > dequeue#), don't I run the risk of filling up the scheduler queues and failed enqueues even at rates lower than the scheduler pipe rates? In the other case where (dequeue# > enqueue#), we would end up dequeing all packets that were enqueued every time. > > > 2) In continuation to previous question: if queue weights don't help, > would it be possible to use metering to achieve rate limiting? Assume we > meter individual traffic-types (using CIR-PIR config mentioned above) > before queuing it to the scheduler queues. So to achieve the respective > queue rates, the dequeuer would be expected to prioritise green packets > over yellow. > > Looking into the code, the packet color is used as an input to the dropper > block, but does not seem to be used anywhere in the scheduler. So I guess > it is not possible to prioritise green packets when dequeing? > > [Cristian] Packet color is used by Weighted RED (WRED) congestion > management scheme on the enqueue side, not on the dequeue side. Once the > packet has been enqueued, it cannot be dropped (i.e. every enqueued packet > will eventually be dequeued), so rate limiting cannot be enforced on the > dequeue side. > > > > Regards, > > Nikhil > > > > > Thanks. Nikhil