On 3/12/2012, at 10:37 AM, Toke Høiland-Jørgensen <[email protected]> wrote:
> Eric Dumazet <[email protected]> writes: > >> This can help if you really want to avoid a thick flow sharing a thin >> flow bucket, but given that all packets are going eventually into the >> Internet (or equivalent crowded network), its not really a clear win. > > I've been trying to grok the fq_codel code by reading through it while > following the discussion in the article, and I'm having a bit of trouble > squaring the thin/thick (or "hog"/"non-hog") flow designation of the > article with the code. As far as I can tell from the code, there are two > lists, called new_flows and old_flows; and a flow starts out as 'new' > and stays that way until it has sent a quantum of bytes or codel fails > to dequeue a packet from it, whereupon it is moved to the end of the > old_flows list. It then stays in the old_flows list for the rest of its > "life". 'new' is what I was calling 'thin', and 'old' is the 'thick' list. When a flow drains, it disappears from both lists (but is not garbage collected), and will come back on the 'new' or 'thin' list. The code for this is in enqueue, where if the flow is not on either list it gets put on the tail of the 'new' list. > > Now, talking about thin flows being distinguished from thick ones, it > seems to me that if a flow sends packets at a low enough rate it can in > principle stay 'thin' indefinitely. So I'm assuming I've missed > something in the code that allows a flow to stay in the new_flows list > if it is sufficiently thin. Could someone please point out to me what > I'm missing? :) It's the implicit return to the 'new' list. > > Thanks, > > -Toke > > -- > Toke Høiland-Jørgensen > [email protected] > _______________________________________________ > Codel mailing list > [email protected] > https://lists.bufferbloat.net/listinfo/codel _______________________________________________ Codel mailing list [email protected] https://lists.bufferbloat.net/listinfo/codel
