jamal wrote:
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].
Admittedly using dummy in this example wasn't the best choice, the point
was that its absolutely fine to use prio without a priomap at all.
;-> 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?
If X < 3 then maybe, priomap points to nonexistant classes which the
kernel will reject, which it doesn't have to do, but I'm fine with
it. If X > 3 then this just means no value of skb->priority maps to some
classes, but this doesn't make them any less usable.
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?
See above. But I agree, lets stop this discussion, its leading nowhere.
-
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
