[Bloat] Please enter issues into the issue tracker - Issue system organisation needed.
Eric Dumazet
eric.dumazet at gmail.com
Thu Feb 24 14:29:29 EST 2011
Le jeudi 24 février 2011 à 11:31 -0700, Dave Täht a écrit :
> I would really like a sane implementation of some basic tc scripts for
> SFB and CHOKe to be out there.
>
> Dan Siemon's recent set of bufferbloat-related tests
>
> http://www.coverfire.com/archives/2011/02/21/network-latency-experiments/
>
> appeared to invoke issues between multiple queuing disciplines when
> using SFB.
>
Hmm.. hard to say because I personally use SFQ a lot, in ingress and
egress. It's really good for many uses, but you also need a shaper above
SFQ, of course !
Notes:
- We had some bugs in SFQ that I fixed two months ago, take care !
- Its important to set TSO off (ethtool -K eth0 tso off), or else we
send big packets (up to 64Kbytes) and this used to break SFQ fairness.
This can really hurt latencies of interactive flows.
Extract of SFQ changelog :
commit 18c8d82ae5b802c5d82e0dfbcc08b1b568955f46
Author: Eric Dumazet <eric.dumazet at gmail.com>
Date: Fri Dec 31 12:48:55 2010 -0800
sfq: fix slot_dequeue_head()
slot_dequeue_head() should make sure slot skb chain is correct in both
ways, or we can crash if all possible flows are in use.
Jarek pointed out slot_queue_init() can now be done in sfq_init() once,
instead each time a flow is setup.
Signed-off-by: Eric Dumazet <eric.dumazet at gmail.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
commit eeaeb068f1393b4db4861481bf594bcd1c3eda7a
Author: Eric Dumazet <eric.dumazet at gmail.com>
Date: Tue Dec 28 21:53:33 2010 +0000
sch_sfq: allow big packets and be fair
SFQ is currently 'limited' to small packets, because it uses a 15bit
allotment number per flow. Introduce a scale by 8, so that we can handle
full size TSO/GRO packets.
Use appropriate handling to make sure allot is positive before a new
packet is dequeued, so that fairness is respected.
Signed-off-by: Eric Dumazet <eric.dumazet at gmail.com>
Acked-by: Jarek Poplawski <jarkao2 at gmail.com>
Cc: Patrick McHardy <kaber at trash.net>
Signed-off-by: David S. Miller <davem at davemloft.net>
commit ee09b3c1cff0335137dc1b146488e4352f640f13
Author: Eric Dumazet <eric.dumazet at gmail.com>
Date: Wed Dec 22 11:39:59 2010 -0800
sfq: fix sfq class stats handling
sfq_walk() runs without qdisc lock. By the time it selects a non empty
hash slot and sfq_dump_class_stats() is run (with lock held), slot might
have been freed : We then access q->slots[SFQ_EMPTY_SLOT], out of
bounds, and crash in slot_queue_walk()
On previous kernels, bug is here but out of bounds qs[SFQ_DEPTH] and
allot[SFQ_DEPTH] are located in struct sfq_sched_data, so no illegal
memory access happens, only possibly wrong data reported to user.
Also, slot_dequeue_tail() should make sure slot skb chain is correctly
terminated, or sfq_dump_class_stats() can access freed skbs.
Signed-off-by: Eric Dumazet <eric.dumazet at gmail.com>
Signed-off-by: David S. Miller <davem at davemloft.net>
commit eda83e3b63e88351310c13c99178eb4634f137b2
Author: Eric Dumazet <eric.dumazet at gmail.com>
Date: Mon Dec 20 12:54:58 2010 +0000
net_sched: sch_sfq: better struct layouts
Here is a respin of patch.
I'll send a short patch to make SFQ more fair in presence of large
packets as well.
Thanks
[PATCH v3 net-next-2.6] net_sched: sch_sfq: better struct layouts
This patch shrinks sizeof(struct sfq_sched_data)
from 0x14f8 (or more if spinlocks are bigger) to 0x1180 bytes, and
reduce text size as well.
text data bss dec hex filename
4821 152 0 4973 136d old/net/sched/sch_sfq.o
4627 136 0 4763 129b new/net/sched/sch_sfq.o
All data for a slot/flow is now grouped in a compact and cache friendly
structure, instead of being spreaded in many different points.
commit aa3e219997e4b949be4199660936099ded0b401f
Author: Eric Dumazet <eric.dumazet at gmail.com>
Date: Mon Dec 20 13:18:16 2010 -0800
net_sched: sch_sfq: fix allot handling
When deploying SFQ/IFB here at work, I found the allot management was
pretty wrong in sfq, even changing allot from short to int...
We should init allot for each new flow, not using a previous value found
in slot.
Before patch, I saw bursts of several packets per flow, apparently
denying the default "quantum 1514" limit I had on my SFQ class.
More information about the Bloat-devel
mailing list