LARTC - Dec 2004 - qdisc monitoring

Hello,
I am interrested in the monitoring of the qos qdiscs parameters such as size
of the queue, enqueues, dequeues, delay in queue, I made a tool to have 
those
results availlable at http://rawsoft.org, but it will probably not work 
anymore
because of the kernel evolutions (the file sch_red.c is patched for the 
tool to work).
I would like to have all the necessary data coming from the kernel so as to
monitor the qdisc queues in a real time way without kernel modification.
Could I have a modified sch_red.c or sch_fifo.c that would contain hooks to
monitor and bring back the results to the user space?
How do I proceed to have a qdisc module creation in the kernel?
Is it possible?
The need to monitor is great: how do we prove the quality of the 
existing qdiscs?
A monitoring tool that needs kernel module modifications is just useless.
Regards
Vincent Perrier

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

* vincent perrier <41D40E5B.8030108@club-internet.fr> 2004-12-30
15:19
> I am interrested in the monitoring of the qos qdiscs parameters such as
size
> of the queue, enqueues, dequeues, delay in queue, I made a tool to have 
> those
> results availlable at http://rawsoft.org,
Good effort, I was having something like this in mind for several
months.
> I would like to have all the necessary data coming from the kernel so as to
> monitor the qdisc queues in a real time way without kernel modification.
Not possible, you can access queue length, number of requeues and number
of enqueues via statistics but it will be delayed.
> Could I have a modified sch_red.c or sch_fifo.c that would contain hooks to
> monitor and bring back the results to the user space?
Your current way of doing is correct but the hooks should be macros
being NIL if tracing is not enabled. Furthermore I would favour
using netlink callbacks instead of a char device. I give it good
chances to get into mainline iff there is no performance decrease
if tracing is not enabled and no new char device is created.

I''m willing to help you out in the kernel part.

My thoughts on this are basically:

#ifdef CONFIG_NET_SCHED_TRACE
#define tct_hook_enqueue(...) { ... }
...
#else
#define tct_hook_enqueue(...)
...
#endif

Modify all qdiscs/classifiers to call those hooks (simple).

The hooks generate messages which contain a timestamp
and some data. The skb or at least the header is transfered
to userspace when first seen. Messages are broadcast
over a netlink socket to all subscribers.

So you could basically record the events and then debug it
step-by-step and follow the path of a specific skb, etc.
> How do I proceed to have a qdisc module creation in the kernel?
> Is it possible?
I don''t get this question.
> The need to monitor is great: how do we prove the quality of the 
> existing qdiscs?
The algorithms usually get verified in a simulator such as nsim.
The correctness of the implementation is verified through tcsim
in tcng.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/