jamal wrote: > On Thu, 2006-16-02 at 21:26 +0100, Patrick McHardy wrote: > >>Well just because you could add another classful qdisc as child >>doesn't necessarily means its a good idea :) > > > This is what i was worried about. But you could live with the philosophy > of "i gave you the gun, i didn't say to shoot your toe with it", then > fine ;-> Should be noted that at times users tend to find creative > unintended ways to use the gun such as shooting down fruits off a tall > tree.
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. >>It is mostly intended >>for use with SFQ, but if someone can think of other reasonable >>combinations, also fine. > > > Yes, SFQ makes sense. I wonder what it means though for any of the other > qdiscs ;-> 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 :) >>>In addition i am not sure if the idea of mucking around with "limit" as >>>a signal to the kernel. >> >>The limit value is _only_ used to limit the internal bfifo queue, my >>patch still does exactly that. The only difference is that if you want >>to replace the automatically created inner bfifo qdisc anyway, you can >>give a value of 0 for the limit and avoid having it created. Current >>iproute versions always use a value > 0, so nothing changes at all. > > > 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. 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). > 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. - 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
