Re: [LARTC] Question(s) for the programming gurus

[Michael Renzmann <mrenzmann@otaku42.de>]

Hi.

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@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/