jamal wrote: > On Fri, 2006-17-02 at 16:54 +0100, Patrick McHardy wrote: > >>You need neither a fifo nor a limit. All RED does is calculate the >>average queue occupancy and react on that based on the min and >>max parameters. The upper threshold is just there to have some >>fixed boundaries on delay and/or resource consumption. >> > > "You need neither a fifo nor a limit" is a pretty strong statement to > make;->. Either that or i am misunderstanding you. > RED is a _resource_ management algorithm and of course we need a limit > to resources being managed. Heck, if there was no resource problems > there would be no need for RED at all and lets just have infinite > queues.
It is a correct statement about the RED algorithm, prove me wrong by showing me code. As for your philosophical views on limits, please read again what I wrote. > On the issue of FIFO: > You cannot afford to have contradiction between the inner qdisc > decision and the RED decision which is likely to happen if you use > anything that is not FIFO based. This boils to MUST for: RED makes it decision before enqueuing, there is no decision involved in dequeueing. >>Again, it does have a regular graft operation. And also again, replacing >>the inner qdisc in the change operation is necessary to keep a backwards >>compatible meaning of limit. It is exactly what TBF does. Besides that, >>no other qdiscs destroy their inner qdiscs when changing class >>parameters, why do you insist that RED and TBF do so unless necessary? > > > I say something like this when i want to attach > different inner qdiscs for PRIO qdisc: > > #create a prio qdisc with three bfifo queues > tc qdisc add dev eth0 handle 1:0 root prio > #replace 1:1 with a tbf > tc qdisc replace dev eth0 parent 1:1 tbf blahblah > #replace 1:2 with a pfifo with limit of 10 packets > tc qdisc replace dev eth0 parent 1:2 pfifo limit 10 > > What i am suggesting is you do: > #create red as root > tc qdisc add dev eth0 handle 1:0 root red limit blah blahbleh > #replace the bfifo with sfq > tc qdisc add dev eth0 parent 1:1 sfq blahblah > > What am i missing? You will still do exactly that, but since the limit parameter (a byte limit that has no meaning for SFQ) is irrelevant, you can avoid creating the bfifo qdisc that will be immediately replaced by specifiying a limit of 0. It is an optimization possibility on init, on change it avoids destroying the inner SFQ qdisc when you change for example min and max. BTW, giving a limit of 0 to sch_fifo has no meaning, it will use 1 packet (for pfifo) or 1 mtu (for bfifo) anyway. To be honest, I'm not interested in continuing this discussion without any concrete examples of problems. And "you can create non-working combinations" doesn't count, you can do it with all qdisc. - 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
