Re: [Bloat] Please enter issues into the issue tracker - Issue system organisation needed.

[Eric Dumazet <eric.dumazet@gmail.com>]

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@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@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit eeaeb068f1393b4db4861481bf594bcd1c3eda7a
Author: Eric Dumazet <eric.dumazet@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@gmail.com>
    Acked-by: Jarek Poplawski <jarkao2@gmail.com>
    Cc: Patrick McHardy <kaber@trash.net>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit ee09b3c1cff0335137dc1b146488e4352f640f13
Author: Eric Dumazet <eric.dumazet@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@gmail.com>
    Signed-off-by: David S. Miller <davem@davemloft.net>

commit eda83e3b63e88351310c13c99178eb4634f137b2
Author: Eric Dumazet <eric.dumazet@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@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.