[<prev] [next>] [<thread-prev] [thread-next>] [day] [month] [year] [list]
Message-ID: <CAA93jw4ndMg-4BnhmspxgcXYdozu5+YX9VJgtHJ3N5HVX1b4yg@mail.gmail.com>
Date: Thu, 5 Jan 2012 14:03:43 +0100
From: Dave Taht <dave.taht@...il.com>
To: Eric Dumazet <eric.dumazet@...il.com>
Cc: David Miller <davem@...emloft.net>,
netdev <netdev@...r.kernel.org>,
Stephen Hemminger <shemminger@...tta.com>
Subject: Re: [PATCH net-next] net_sched: red: split red_parms into parms and vars
On Thu, Jan 5, 2012 at 1:25 PM, Eric Dumazet <eric.dumazet@...il.com> wrote:
> This patch splits the red_parms structure into two components.
>
> One holding the RED 'constant' parameters, and one containing the
> variables.
>
> This permits a size reduction of GRED qdisc, and is a preliminary step
> to add an optional RED unit to SFQ.
ah. I see where you are going with this. You are trying also to get your
'time in red' adaptation idea done, aren't you, or at least lay the groundwork
for that?
Are you trying to make the 3.3 merge window for all this?
I don't want to discourage you in any way, but byte oriented RED
with or without TSO doesn't work in your typical asymmetric
environment. If you set an appropriate byte limit for
stuff going one way, you end up with acks going out of
control - and vice versa.
and/or packet oriented RED has some hope, but in either
case you have to do something intelligent with a giant TSO
stream if you are going to use it on a server or host.
And the basic red still has two flaws that may or may
not go away with your adaptation, or combination with
SFQ - (I do retain hope, though)
I think you already grok this and you've already got the solution
outlined :)
so I'm going to go away now and finish writing up
what the problems are in sch_md, which are legion...
Keep having fun. I'll plan on a new build by the weekend.
--
Dave Täht
SKYPE: davetaht
US Tel: 1-239-829-5608
FR Tel: 0638645374
http://www.bufferbloat.net
--
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