[dpdk-dev] meter: excess token bucket update in srtcm

2016-09-06 Thread Nikhil Jagtap
Hi, Can someone please comment on this? Nikhil On 31 August 2016 at 15:32, Nikhil Jagtap wrote: > Hi, > > As per srTCM RFC 2697, we should be updating the E bucket only after the C > bucket overflows. > "Thereafter, the token counts Tc and Te are updated CIR times per

[dpdk-dev] meter: excess token bucket update in srtcm

2016-09-06 Thread Nikhil Jagtap
--Original Message- > From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Nikhil Jagtap > Sent: Tuesday, September 6, 2016 9:43 AM > To: Dumitrescu, Cristian > Cc: dev at dpdk.org > Subject: Re: [dpdk-dev] meter: excess token bucket update in srtcm > > Hi, > Can som

[dpdk-dev] [PATCH] meter: fix excess token bucket update in srtcm implementation

2016-09-07 Thread Nikhil Jagtap
As per srTCM RFC 2697, we should be updating the E bucket only after the C bucket overflows. This patch fixes the current DPDK implementation, where we are updating both the buckets simultaneously at the same rate (CIR) which results in token accumulation rate of (2*CIR). Signed-off-by: Nikhil

[dpdk-dev] meter: excess token bucket update in srtcm

2016-09-07 Thread Nikhil Jagtap
ooks to me that you are right. Sorry, my mistake when translating > the RFC into code. > > Challenge in fixing this is how to code it using minimal number of > branches ... > > Thanks, > Cristian > > > -Original Message- > > From: dev [mailto:dev-bounc

[dpdk-dev] [PATCH] meter: fix excess token bucket update in srtcm implementation

2016-09-20 Thread Nikhil Jagtap
Hi Cristian, My comments inline prefixed with [nikhil]. On 19 September 2016 at 21:21, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > > > > > -Original Message----- > > From: Nikhil Jagtap [mailto:nikhil.jagtap at gmail.com] > > Sent: Wed

[dpdk-dev] [PATCH v2] meter: fix excess token bucket update in srtcm implementation

2016-09-21 Thread Nikhil Jagtap
As per srTCM RFC 2697, we should be updating the E bucket only after the C bucket overflows. This patch fixes the current DPDK implementation, where we are updating both the buckets simultaneously at the same rate (CIR) which results in token accumulation rate of (2*CIR). Signed-off-by: Nikhil

[dpdk-dev] qos: traffic shaping at queue level

2016-09-27 Thread Nikhil Jagtap
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 tra

[dpdk-dev] qos: traffic shaping at queue level

2016-09-30 Thread Nikhil Jagtap
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. Regards, Nikhil On 27 September 2016 at 15:34, Nikhil Jagtap wrote: > Hi, > > I have a few questions about the hie

[dpdk-dev] meter: excess token bucket update in srtcm

2016-08-31 Thread Nikhil Jagtap
Hi, As per srTCM RFC 2697, we should be updating the E bucket only after the C bucket overflows. "Thereafter, the token counts Tc and Te are updated CIR times per second as follows: o If Tc is less than CBS, Tc is incremented by one, else o if Te is less then EBS, Te is incremented by on

[dpdk-dev] acl: delete/modify rule support

2016-11-15 Thread Nikhil Jagtap
Hi, I had a couple of questions about ACL support in DPDK. 1) Is it possible to build the ACL context over a period of time, one rule at a time by calling build post each add operation? Something like this : rte_acl_add_rules(ctx, rule1, 1); rte_acl_build(ctx, build_cfg); rte_acl_add_

[dpdk-dev] qos: traffic shaping at queue level

2016-10-05 Thread Nikhil Jagtap
Hi Cristian, Thanks for the info. A few more comments/questions inline. On 3 October 2016 at 23:42, Dumitrescu, Cristian < cristian.dumitrescu at intel.com> wrote: > > > > > *From:* Nikhil Jagtap [mailto:nikhil.jagtap at gmail.com] > *Sent:* Friday, September 30, 201