On Sat, 2006-18-02 at 08:45 +0100, Patrick McHardy wrote: > jamal wrote:
> It is a correct statement about the RED algorithm, prove me wrong by > showing me code. > RED makes it decision before enqueuing, there is no decision involved > in dequeueing. Parse error on your request for code. True - RED makes its decisions before enqueueing; theres also the implicit assumption that it knows a lot about the queue whose avg occupancy it computes, so much so that when it says "enqueue" then there will be space in the queue. This is why it is hard to make RED a scheduler (It is a scheduler when you make it classful and start attaching inner qdiscs to it). > > 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 introduced the backlog, so there is a mapping. You could also force the user to make sure the RED limit is slightly less or equal to the SFQ one using the RED avg pkt size. > 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. I see the coding value in doing it that way but thats not what i am arguing against. I also wouldnt make the fact that it can be coded easily trump sanity. > 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. Unfortunately, the new qdisc is going to be king of "non-working combinations" - so simply saying thats not a valid concern is hand-waving. My qualm is more related to the limit though; i care less about nonsensical setups. Why dont you restore the limit parameter to RED and note boldly somewhere that it can only be used with SFQ and bfifo? Your only use at the moment seems to be for SFQ, correct? I do like the combination of RED and something like SFQ that would introduce a lot more fairness actually; it would have made an excellent new classful qdisc. But not the way you have it now. Again, as i said earlier - perhaps you should create a new qdisc. Maybe the new qdisc combines both. Something close to that is FRED: http://www.acm.org/sigs/sigcomm/sigcomm97/papers/p078.pdf OTOH, if you insist that you want to keep it the way you have it right now in your patch, I would respectfully disagree with you and still ACK it for the sake of progress. 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
