Lars Landmark wrote:
It is optional to compile it as module or into the kernel.
Ok, and as long as I compile it as modules I just need to recompile those that have been modified, the kernel can stay untouched. Sounds good.
[ idea: implementing the statistics inside a "statistic qdisc" ]
I do not understand why you should do this, while a class has full control of the packets entering or leaving independent of the qdisc in use.
That's simple. This way I don't have to touch each and every scheduler's source that might be interesting now or in the future. And it is more in the sense of "modularity" the tc framework was built on. Just throw in the sch_stat, put it in the correct place of a "qdisc-hierarchie" and you are able to keep track of the packets that are enqueued and dequeued inside the sub-qdisc.
But this rises two questions:
1. Does the parent qdisc get information back if the called child-qdisc enqueued / dequeued packets? And for dequeuing: does the parent know how many packets have been dequeued by the child?
2. Are enqueue() and dequeue() of a qdisc called seperately for every single packet, or is it possible to enqueue / dequeue more than one packet per call?
Note; Packets may enter and/or leaving an interface at variable rate, which most likely leads to high oscillation of the packets counted. :(
Currently I don't see why this could be a problem for the idea of implementing sch_stat... what point do I miss here?
Bye, Mike
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
