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