Adrian Saileanu wrote:
I read the sched/qdiscs code from kernel source ... and I have some questions :
When the .enqueue, .dequeue, .drop, .requeue functions are called ?
Do you mean in sfq.c - ie sfq_enqueue etc. Maybe you mean something else.
Yes, I ment the functions in the Qdisc_ops struct :
+static struct Qdisc_ops dup_qdisc_ops = { + .next = NULL, + .cl_ops = NULL, + .id = "sfq", + .priv_size = sizeof(struct sfq_sched_data), + .enqueue = sfq_enqueue, + .dequeue = sfq_dequeue, + .requeue = sfq_requeue, + .drop = sfq_drop, + .init = sfq_init, + .reset = sfq_reset, + .destroy = NULL, + .change = sfq_init, + .dump = sfq_dump, + .owner = THIS_MODULE, +};
What
is the event that triggers them and how often this event apears ( per second ? ) ?
I don't know as such, but always assumed that when attached to HTB - a packet gets enqueued if there aren't enough (c)tokens to send it and dequeued when there are. As for timing I don't think sfq uses any - it's up to whatever it is attached to.
Ok, the packet gets enqueued ... and the queue gets full. Then if a new
packet arrives and the queue is still full ( it has not been dequeued )
then this packet is dropped.
I think a packet gets enqueued - then the queue length is checked and if it's full sfq_drop is called. sfq_drop drops a packet from the longest slot - hence the packet that filled the queue may or may not be the one that is dropped depending on which slot it got hashed to.
My question is ... is the queue dequeued when it is full ? Or t can be dequeued even when the maximum has not been reatched ? When this .dequeue function is called ?
It is normal for dequeue to be called before the queue is full - exactly when it gets called is the job of whatever the sfq got attached to.
Andy.
_______________________________________________ LARTC mailing list / LARTC@xxxxxxxxxxxxxxx http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/
