Sorry, Unintentionaly trimmed Dave and netdev -------- Forwarded Message -------- From: jamal <[EMAIL PROTECTED]> Reply-To: [EMAIL PROTECTED] To: Patrick McHardy <[EMAIL PROTECTED]> Subject: Re: [PKT_SCHED 00/05]: net/sched patches for 2.6.17 Date: Fri, 17 Feb 2006 10:05:38 -0500
On Fri, 2006-17-02 at 14:56 +0100, Patrick McHardy wrote: > jamal wrote: [..] > We could add flags to the qdiscs (classful, work-conserving, > non-work-conserving, ...) and check for reasonable combinations > in the graft operation. Currently there are many possible > nonsensical combinations. > I think this is a good idea as long as it provides warnings instead of enforcement. Lets defer it to some later work. > Qdiscs have to keep backlog counters to be used as child qdisc with RED, > so with basically anything besides *fifo and SFQ it will simply do > nothing :) > Would pfifo even be a fit? The current RED is byte-counting - thats why you can map to the backlog of inner qdisc (since it keeps buyte counts). I have seen proposals to make it packet counting though. > > So why not use a "replace" operation to substitute the bfifo? i.e create > > a classful RED then replace the bfifo with sfq > > There is a replace operation and it does need to be used to replace the > inner qdisc by anything other than the default bfifo that is used for > backwards compatibility. But when a limit is given we _need_ to replace > the inner qdisc by a bfifo with the new limit to keep the meaning of > the parameter. With RED (as implemented) you _need_ a fifo of some sort which has a upper threshold in byte count thats why bfifo was natural fit there. However, sfq with your changes is also a fit since it provides the same parametrization. > Not replacing it if it is zero is just a possibility for > future users that don't want the default inner qdisc to say so, it > doesn't change anything today since iproute doesn't allow a limit of > zero. BTW, you ACKed the exact same change for TBF (Patch 03/05). > I almost commented on TBF;-> but then handwaved that your TBF patch was also fixing something else which broke by using the limit "signal". Maybe you could separate the fix of what was broken before with the new "signalling". The idea of replacing the inner qdisc is standard procedure - think of a prio qdisc (which also comes in with built in bfifo) and you wanted it to be a pfifo/RED/TBF instead. It would be preferable not to deviate from this scheme. > > The limit and other byte counting parameters are essential components of > > the algorithm. > > The limit has no effect on the RED algorithm itself, only min and max > matter. > The code may appear that way - however, look at all the papers and the RED curves appearing in those papers - the limit is a hard threshold in the algorithm. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
