Eric Dumazet <eric.dumazet@gmail.com> 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
toke@toke.dk