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

[Michael Renzmann <mrenzmann@otaku42.de>]

Hi Lars.

First of all, thanks for your fast reply.

Lars Landmark wrote:
>>Is it possible, either for the device driver itself or for a userspace
>>program, to get information about how many packets are currently queued
>>for a given network interface?
> Yes, if a small extension to the scheduler in question is carried out.
> You may add a variable counting packets in the enqueue () and dequeue(),
> and either write this to the /proc file system or poll the result with the
> help from tc.  Look at sch_fifo.c, it counts packets in the queue. But it
> does not report it any further.

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.

>>Next question: if I understood the concepts of the "traffic control"
>>system correctly, one could add several queues to a single device. Is
>>there any way to simply get the total amount of packets that are waiting
>>in all attached queues? Or would I need to check each queue and sum up
>>the values?
>  Using class based queuing you may isolate each queue from each other and
> count packets each queue holds.  On the other hand, if you want the total
> amount of queued packets, then a global variable would help you.

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?

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.


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.

Bye, Mike

_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/