[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CABa6K_Fk07CUR1+hOx06cwJ5MuNYi7vpeLYFOc_1Qwmu5ubYhQ@mail.gmail.com>
Date: Fri, 11 May 2012 23:03:10 +0800
From: Changli Gao <xiaosuo@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Dave Taht <dave.taht@...ferbloat.net>,
Kathleen Nichols <nichols@...lere.com>,
Van Jacobson <van@...lere.net>,
Tom Herbert <therbert@...gle.com>,
Matt Mathis <mattmathis@...gle.com>,
Yuchung Cheng <ycheng@...gle.com>,
Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [PATCH net-next] fq_codel: Fair Queue Codel AQM
On Fri, May 11, 2012 at 9:59 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> From: Eric Dumazet <edumazet@...gle.com>
>
> Fair Queue Codel implementation.
>
> Principles :
>
> - Packets are classified (internal classifier or external) on flows.
> - This is a Stochastic model (as we use a hash, several flows might
> be hashed on same slot)
> - Each flow has a CoDel managed queue.
> - Flows are linked onto two (Round Robin) lists,
> so that new flows have priority on old ones.
I don't think it is a good idea, as the old ones may be starved. It isn't
fair. Why not use the conventional DRR?
> +
> + /* Queue is full! Find the fat flow and drop packet from it.
> + * This might sound expensive, but with 1024 flows, we scan
> + * 4KB of memory, and we dont need to handle a complex tree
> + * in fast path (packet queue/enqueue) with many cache misses.
> + */
How about the tricks used by SFQ?
Thanks.
--
Regards,
Changli Gao(xiaosuo@...il.com)
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at http://vger.kernel.org/majordomo-info.html
Powered by blists - more mailing lists