jamal wrote: > On Wed, 2006-15-02 at 09:54 +0100, Patrick McHardy wrote: > > [..] > >> [PKT_SCHED]: Convert sch_red to a classful qdisc > > > This is the only one i have issues with (i.e ACK all the other ones)[1]. > > I can understand for a RED algorithm to have a set of parameters for > a physical queue (even in the case of multiple virtual queues within > a physical queue); > 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 :) It is mostly intended for use with SFQ, but if someone can think of other reasonable combinations, also fine. > 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. > My suggestion is you perhaps make this a new qdisc (and ensure multiple > RED parameter sets - one per class) Thats not the same. If I want multiple classes, I need a scheduling algorithm for these classes. With just a single class, RED can do just RED and leave scheduling to other qdiscs. > > cheers, > jamal > > [1]I have to put a disclaimer: I am always a stickler as far as RED > is concerned (Thomas can testify to that) because it is very delicate > (not the code rather the algorithm) and i have suffered a lot in the > past getting those parameters tuned. There was a gent who was interested > in putting together regression tests for RED but he keeps disappearing on us. - 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
