[BUG] net_sched: pfifo_head_drop problem

5 messages, 4 authors, 2011-01-05 · open the first message on its own page

[BUG] net_sched: pfifo_head_drop problem

From: Eric Dumazet <hidden>
Date: 2011-01-05 17:14:02

While reviewing CHOKe stuff, I found following problem :

commit 57dbb2d83d100ea (sched: add head drop fifo queue)
introduced pfifo_head_drop, and broke the invariant that
sch->bstats.bytes and sch->bstats.packets are COUNTER (increasing
counters only)

This can break estimators because est_timer() handle unsigned deltas
only. A decreasing counter can then give a huge unsigned delta.

My suggestion would be to change things so that sch->bstats.bytes and
sch->bstats.packets are incremented in dequeue() only, not at enqueue()
time.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in estimators.

Or maybe my understanding of estimators is wrong, and only apply to
enqueue rate, not dequeue rate ?

If so, we should remove the 

sch->bstats.bytes -= qdisc_pkt_len(skb_head);
sch->bstats.packets--;

done in pfifo_tail_enqueue() in case we drop the head skb.


My preference would be to add dropped pack/byte rates to estimators...
It might be good for tuning.


Re: [BUG] net_sched: pfifo_head_drop problem

From: Stephen Hemminger <hidden>
Date: 2011-01-05 17:15:50

On Wed, 05 Jan 2011 18:00:50 +0100
Eric Dumazet [off-list ref] wrote:
While reviewing CHOKe stuff, I found following problem :

commit 57dbb2d83d100ea (sched: add head drop fifo queue)
introduced pfifo_head_drop, and broke the invariant that
sch->bstats.bytes and sch->bstats.packets are COUNTER (increasing
counters only)

This can break estimators because est_timer() handle unsigned deltas
only. A decreasing counter can then give a huge unsigned delta.

My suggestion would be to change things so that sch->bstats.bytes and
sch->bstats.packets are incremented in dequeue() only, not at enqueue()
time.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in estimators.

Or maybe my understanding of estimators is wrong, and only apply to
enqueue rate, not dequeue rate ?

If so, we should remove the 

sch->bstats.bytes -= qdisc_pkt_len(skb_head);
sch->bstats.packets--;

done in pfifo_tail_enqueue() in case we drop the head skb.


My preference would be to add dropped pack/byte rates to estimators...
It might be good for tuning.
Agreed counters should reflect dequeued packets not enqueued packets.


-- 

[PATCH] net_sched: pfifo_head_drop problem

From: Eric Dumazet <hidden>
Date: 2011-01-05 20:35:48

commit 57dbb2d83d100ea (sched: add head drop fifo queue)
introduced pfifo_head_drop, and broke the invariant that
sch->bstats.bytes and sch->bstats.packets are COUNTER (increasing
counters only)

This can break estimators because est_timer() handles unsigned deltas
only. A decreasing counter can then give a huge unsigned delta.

My mid term suggestion would be to change things so that
sch->bstats.bytes and sch->bstats.packets are incremented in dequeue()
only, not at enqueue() time. We also could add drop_bytes/drop_packets
and provide estimations of drop rates.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in byte/packets
abolute counters and rate estimators.

Before this mid term change, this patch makes pfifo_head_drop behavior
similar to other qdiscs in case of drops :
Dont decrement sch->bstats.bytes and sch->bstats.packets

Signed-off-by: Eric Dumazet <redacted>
---
 net/sched/sch_fifo.c |    2 --
 1 file changed, 2 deletions(-)
diff --git a/net/sched/sch_fifo.c b/net/sched/sch_fifo.c
index 4dfecb0..aa4d633 100644
--- a/net/sched/sch_fifo.c
+++ b/net/sched/sch_fifo.c
@@ -54,8 +54,6 @@ static int pfifo_tail_enqueue(struct sk_buff *skb, struct Qdisc* sch)
 
 	/* queue full, remove one skb to fulfill the limit */
 	skb_head = qdisc_dequeue_head(sch);
-	sch->bstats.bytes -= qdisc_pkt_len(skb_head);
-	sch->bstats.packets--;
 	sch->qstats.drops++;
 	kfree_skb(skb_head);
 

Re: [PATCH] net_sched: pfifo_head_drop problem

From: Hagen Paul Pfeifer <hidden>
Date: 2011-01-05 20:52:19

* Eric Dumazet | 2011-01-05 21:35:02 [+0100]:
My mid term suggestion would be to change things so that
sch->bstats.bytes and sch->bstats.packets are incremented in dequeue()
only, not at enqueue() time. We also could add drop_bytes/drop_packets
and provide estimations of drop rates.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in byte/packets
abolute counters and rate estimators.

Before this mid term change, this patch makes pfifo_head_drop behavior
similar to other qdiscs in case of drops :
Dont decrement sch->bstats.bytes and sch->bstats.packets
Thanks Stephen and Erik for spotting this bug!
Signed-off-by: Eric Dumazet <redacted>
Acked-by: Hagen Paul Pfeifer <redacted>

Re: [PATCH] net_sched: pfifo_head_drop problem

From: David Miller <davem@davemloft.net>
Date: 2011-01-05 21:39:08

From: Hagen Paul Pfeifer <redacted>
Date: Wed, 5 Jan 2011 21:52:17 +0100
* Eric Dumazet | 2011-01-05 21:35:02 [+0100]:
quoted
My mid term suggestion would be to change things so that
sch->bstats.bytes and sch->bstats.packets are incremented in dequeue()
only, not at enqueue() time. We also could add drop_bytes/drop_packets
and provide estimations of drop rates.

It would be more sensible anyway for very low speeds, and big bursts.
Right now, if we drop packets, they still are accounted in byte/packets
abolute counters and rate estimators.

Before this mid term change, this patch makes pfifo_head_drop behavior
similar to other qdiscs in case of drops :
Dont decrement sch->bstats.bytes and sch->bstats.packets
Thanks Stephen and Erik for spotting this bug!
quoted
Signed-off-by: Eric Dumazet <redacted>
Acked-by: Hagen Paul Pfeifer <redacted>
Applied and queued up for -stable, thanks.
Keyboard shortcuts
hback out one level
jnext message in thread
kprevious message in thread
ldrill in
Escclose help / fold thread tree
?toggle this help