> Hmm... just to get it right: if I modify the source of any scheduler, > there is no need to recompile the kernel, as the schedulers are > "encapsulated" completely as loadable kernel modules? Because that is a > important criterion for my decision, I want to (better: have to) avoid > to recompile the kernel at any costs. It is optional to compile it as module or into the kernel. > > As far as I understood the concepts of the tc framework, each interface > has a queuing discipline attached. Optionally, this discipline may have > several filters and classes. Filters decide which packet belongs to > which class, and each class may optionally have other qdiscs attached to > it. Is this understanding correct? You may change the default FIFO discipline, for instance to sfq. Read the lartc documentation, where you can see an example for HTB, if I do remember right :-). > > If so, then in the following situation... > > +----[client1] > | > (Internet)---eth0--[router]--eth1--+----[client2] > | > +----[client3] > > ... I'd choose a discipline that implements classes. At least one class > per client with one qdisc attached to each class would be necessary to > allow bandwidth shaping for traffic that passes the router on its way > from the clients to the Internet. Right? > > In this case I need to modify the "root discipline" in order to > implement a "per class" counter, so that I can see if the queue for a > client fills up. As you explains; a client is associated to a class, then you need an extension to the "class struct" and not the global root "struct". > > > While thinking about the above, another idea came to my mind. Maybe > there is a way to avoid to modify every scheduler that might become > interesting for the described task. Wouldn't it be more reasonable to > write my own dummy qdisc handler that just implements the very basic > functions needed to attach another qdisc to it? In this case, the dummy > only needed to have the functions enqueue() and dequeue() which keep the > counter up-to-date. Of course one counter per class would be necessary > in the above described scenario, but that shouldn't be much harder than > having a global counter. That could be thought to be a "statistic qdisc" > which also could be used for simple accounting purposes... hmm, do you > think that this could work? If so, I'd like to try that one. 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. Note; Packets may enter and/or leaving an interface at variable rate, which most likely leads to high oscillation of the packets counted. :( > > Bye, Mike > _______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
