On Fri, 2006-17-02 at 16:54 +0100, Patrick McHardy wrote: > jamal wrote:
> > > 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. > > 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. >From a local perspective resources imply managing queue buffers. From an end to end angle, it translates to congestion control. Essentially "limit" is fundamental and a mismatch with what the inner vs outer(RED) limits is problematic. 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: So far you have mentioned only SFQ which is fifo based and has limits; so i dont see a contradiction there. If SFQ was LIFO based, there would be a contradiction etc. Again i may be misreading what you are saying. > > > Maybe you could separate the fix of what was broken before with the new > > "signalling". > > Why? The patch is easy to understand and clearly commented in the > changelog entry. > Because you said it was of the same nature as the RED one in terms of using limit to imply something else;-> > > > 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. > > 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? 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
