> My opinion is that since these interfaces (ex qdisc) exist they
> exist to be (ab)used.
Stated in such a general way, that sounds dangerous ;-)
> Dsmark happens to work well with the single queue - maybe thats what
> needs to be documented as opposed to saying it deviates from a purist
tcio, section 2, towards the end:
| Typically, each class ``owns'' one queue, but it is in principle
| also possible that several classes share the same queue or even
| that a single queue is used by all classes of the respective
| queuing discipline.
Now, I've of course only documented the status quo, and one could
argue whether this actually makes sense. But then, it works well
for dsmark, and doesn't seem to break anything else.
I'm a bit confused about what the problem is here (or if there is
one at all): if dsmark_graft is changed to adjust the statistics
(which makes perfect sense to me), I don't see a reason why either
subtracting the queue length of the former inner qdisc, or simply
setting dsmark's queue lenghth to zero wouldn't work.
Patrick, was the experiment "I've now verified experimentally the
problem also exists in dsmark" done with or without your
"sch->q.qlen -= (*old)->q.qlen;" patch ? This looks just like the
behaviour I'd expect your patch to fix, no ?
/ Werner Almesberger, Buenos Aires, Argentina werner@xxxxxxxxxxxxxxx /