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". 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? :) Thanks, -Toke -- Toke Høiland-Jørgensen [email protected]
pgpmpM2tfb6l8.pgp
Description: PGP signature
_______________________________________________ Cerowrt-devel mailing list [email protected] https://lists.bufferbloat.net/listinfo/cerowrt-devel
