All of lore.kernel.org
 help / color / mirror / Atom feed
* [PATCH 1/1] cbq: incorrect processing of high limits
@ 2013-04-01 13:01 Vasily Averin
  2013-04-01 16:24 ` Eric Dumazet
  0 siblings, 1 reply; 3+ messages in thread
From: Vasily Averin @ 2013-04-01 13:01 UTC (permalink / raw)
  To: netdev; +Cc: Alexey Kuznetsov, David S. Miller, Jamal Hadi Salim

currently cbq works incorrectly for limits > 10% real link bandwidth,
and practically does not work for limits > 50% real link bandwidth.
Below are results of experiments taken on 1 Gbit link

 In shaper | Actual Result
-----------+---------------
  100M     | 108 Mbps
  200M     | 244 Mbps
  300M     | 412 Mbps
  500M     | 893 Mbps

This happen because of q->now changes incorrectly in cbq_dequeue():
when it is called before real end of packet transmitting,
L2T is greater than real time delay, q_now gets an extra boost
but never compensate it.

To fix this problem we prevent change of q->now until its synchronization
with real time.

Signed-off-by: Vasily Averin <vvs@openvz.org>
Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
---
 net/sched/sch_cbq.c |    5 ++++-
 1 files changed, 4 insertions(+), 1 deletions(-)

diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
index 6aabd77..5b5c83a 100644
--- a/net/sched/sch_cbq.c
+++ b/net/sched/sch_cbq.c
@@ -962,8 +962,11 @@ cbq_dequeue(struct Qdisc *sch)
		cbq_update(q);
		if ((incr -= incr2) < 0)
			incr = 0;
+		q->now += incr;
+	} else {
+		if (now > q->now)
+			q->now = now;
	}
-	q->now += incr;
	q->now_rt = now;

	for (;;) {
--
1.7.5.4

^ permalink raw reply related	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] cbq: incorrect processing of high limits
  2013-04-01 13:01 [PATCH 1/1] cbq: incorrect processing of high limits Vasily Averin
@ 2013-04-01 16:24 ` Eric Dumazet
  2013-04-02 18:30   ` David Miller
  0 siblings, 1 reply; 3+ messages in thread
From: Eric Dumazet @ 2013-04-01 16:24 UTC (permalink / raw)
  To: Vasily Averin; +Cc: netdev, Alexey Kuznetsov, David S. Miller, Jamal Hadi Salim

On Mon, 2013-04-01 at 17:01 +0400, Vasily Averin wrote:
> currently cbq works incorrectly for limits > 10% real link bandwidth,
> and practically does not work for limits > 50% real link bandwidth.
> Below are results of experiments taken on 1 Gbit link
> 
>  In shaper | Actual Result
> -----------+---------------
>   100M     | 108 Mbps
>   200M     | 244 Mbps
>   300M     | 412 Mbps
>   500M     | 893 Mbps
> 
> This happen because of q->now changes incorrectly in cbq_dequeue():
> when it is called before real end of packet transmitting,
> L2T is greater than real time delay, q_now gets an extra boost
> but never compensate it.
> 
> To fix this problem we prevent change of q->now until its synchronization
> with real time.
> 
> Signed-off-by: Vasily Averin <vvs@openvz.org>
> Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
> ---
>  net/sched/sch_cbq.c |    5 ++++-
>  1 files changed, 4 insertions(+), 1 deletions(-)
> 
> diff --git a/net/sched/sch_cbq.c b/net/sched/sch_cbq.c
> index 6aabd77..5b5c83a 100644
> --- a/net/sched/sch_cbq.c
> +++ b/net/sched/sch_cbq.c
> @@ -962,8 +962,11 @@ cbq_dequeue(struct Qdisc *sch)
> 		cbq_update(q);
> 		if ((incr -= incr2) < 0)
> 			incr = 0;
> +		q->now += incr;
> +	} else {
> +		if (now > q->now)
> +			q->now = now;
> 	}
> -	q->now += incr;
> 	q->now_rt = now;
> 
> 	for (;;) {

Acked-by: Eric Dumazet <edumazet@google.com>

Still, after your patch a limit of 500Mbit gives :

 rate 515872Kbit 946pps backlog 0b 2p requeues 0 

HTB is more precise :

 rate 500667Kbit 41336pps backlog 0b 2p requeues 0 

^ permalink raw reply	[flat|nested] 3+ messages in thread

* Re: [PATCH 1/1] cbq: incorrect processing of high limits
  2013-04-01 16:24 ` Eric Dumazet
@ 2013-04-02 18:30   ` David Miller
  0 siblings, 0 replies; 3+ messages in thread
From: David Miller @ 2013-04-02 18:30 UTC (permalink / raw)
  To: eric.dumazet; +Cc: vvs, netdev, kuznet, jhs

From: Eric Dumazet <eric.dumazet@gmail.com>
Date: Mon, 01 Apr 2013 09:24:36 -0700

> On Mon, 2013-04-01 at 17:01 +0400, Vasily Averin wrote:
>> currently cbq works incorrectly for limits > 10% real link bandwidth,
>> and practically does not work for limits > 50% real link bandwidth.
>> Below are results of experiments taken on 1 Gbit link
>> 
>>  In shaper | Actual Result
>> -----------+---------------
>>   100M     | 108 Mbps
>>   200M     | 244 Mbps
>>   300M     | 412 Mbps
>>   500M     | 893 Mbps
>> 
>> This happen because of q->now changes incorrectly in cbq_dequeue():
>> when it is called before real end of packet transmitting,
>> L2T is greater than real time delay, q_now gets an extra boost
>> but never compensate it.
>> 
>> To fix this problem we prevent change of q->now until its synchronization
>> with real time.
>> 
>> Signed-off-by: Vasily Averin <vvs@openvz.org>
>> Reviewed-by: Alexey Kuznetsov <kuznet@ms2.inr.ac.ru>
 ...
> Acked-by: Eric Dumazet <edumazet@google.com>

Applied, thanks.

^ permalink raw reply	[flat|nested] 3+ messages in thread

end of thread, other threads:[~2013-04-02 18:30 UTC | newest]

Thread overview: 3+ messages (download: mbox.gz / follow: Atom feed)
-- links below jump to the message on this page --
2013-04-01 13:01 [PATCH 1/1] cbq: incorrect processing of high limits Vasily Averin
2013-04-01 16:24 ` Eric Dumazet
2013-04-02 18:30   ` David Miller

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.