On Thu, 2006-16-02 at 21:26 +0100, Patrick McHardy wrote: > jamal wrote: [..] > > What you have introduced is a single set of RED parameters for possibly > > many physical queues/classes. I am trying to make sense of what that means. > > 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. > 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 ;-> > > 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 The limit and other byte counting parameters are essential components of 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
