Re: [dpdk-users] qos: traffic shaping at queue level

["Dumitrescu, Cristian" <cristian.dumitrescu@intel.com>]

From: Nikhil Jagtap [mailto:nikhil.jagtap@gmail.com]
Sent: Friday, September 30, 2016 7:12 AM
To: dev@dpdk.org; Dumitrescu, Cristian <cristian.dumitrescu@intel.com>; 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?

Regards,
Nikhil

On 27 September 2016 at 15:34, Nikhil Jagtap <nikhil.jagtap@gmail.com<mailto:nikhil.jagtap@gmail.com>> 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).

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