On Mon, 2006-16-01 at 06:51 +0100, Patrick McHardy wrote: > jamal wrote: > > On Mon, 2006-16-01 at 05:56 +0100, Patrick McHardy wrote: > > > > This is a dead horse since I ACKed the patch, but that patch > > is _wrong_ without the user space fix. > > What's wrong with this: > > tc qdisc add dev dummy0 root handle 1: prio bands 5 > for i in $(seq 1 5); do > tc filter add dev dummy0 parent 1: handle $i fw classid 1:$i > done >
Clearly nothing in the kernel patch fixed anything for the above. [dummy by default just blackholes packets - so it doesnt matter if you have noop or fifo or red qdiscs attached on all 5 classes]. But in the case you are using some other netdevice like eth0, you oughta specify the priomap otherwise 3 of those bands are valid. > > ;-> so in your opinion was it fine for tc to send it anyways or does tc > > need fixing? ;-> > > It shouldn't use the default mapping if its known to be invalid. > ;-> what is invalid is to use a priomap for 3 bands when there is infact X bands - where X !=3. Would you agree? > > Then why bother sending a priomap at all? Lets just use the one in the > > kernel > > For the default that would be fine, but it doesn't have a seperate > attribute. I believe it is easier to just do it from user space. IIIRC, at one point the default map was in the kernel and caused all sorts of issues with users. Ok Patrick, we can discuss this until the cows come home, for simplicity sake: just answer the question above if you think it is ok for tc to behave the way it does (then the debate on the patch is resolved while we can still disagree at the latte-philosophical level). i.e: tc always assumes a map to 3 queues regardless of whether you have 15 or 2. I say it should not - what says you? 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
