and unintentionaly sent out earlier using my work email. Doesnt seem to be a good start this morning.
cheers, jamal On Fri, 2006-17-02 at 10:25 -0500, Jamal Hadi Salim wrote: > 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
