[LARTC] Re: More on qdiscs - about dangling backlogs

[don-lartc@isis.cs3-inc.com (Don Cohen)]

Martin Devera writes:
 > So that to be clear - I have NO problem reading backlog info.
 > However I (and CBQ too) have problem to maintain our own qlen !
Oh, of course.  Now everything makes sense.
When I asked whether all you care about inner qlen is whether it's 0
you mislead me by confirming my incorrect guess.  Or perhaps it used
to be right but now is wrong.  You now need it (not just whether it's
0) in order to figure out and maintain your own qlen.

 > right. What you know:
 > - each qdisc's (own) qlen is valid at all (for us important) times
 > - qdisc's qlen can increase only after successfull (!) enqueue
But I think there's another case - requeue.  Maybe you consider that
the same as enqueue.
(I've never seen evidence that it was executed, but it's called in
sch_generic.c)

 > > I see, you suggest that I could do better if enqueue started with
 > > something like
 > >  while (oldest packet expired) drop oldest packet
 > > Of course this is still only an approximation.  There will still be
 > > times when you have to drop a packet but it turns out that, before the
 > > next one is dequeued another packet will have expired (so if you only
 > > knew that you could have saved the packet you dropped before).
 > 
 > yes somethink like :) If we would maintain these copies above then
 > you could drop any number of packets.
 > It would be helpful to drop all of these in both dequeue & enqueue
 > to assure that you will not dequeue old packet if too much time
 > passes between last enqueue and dequeue.

Unfortunately, for SFQ it's not so easy to find all expired packets in
the queue.  We'd have to add a fifo data structure to do that in the
desired time (proportional to the number of expired packets).  
This is only important when the queue is full, of course.
I still think it's reasonable to check only at dequeue.  Basically if
you know max time between dequeues is t, then a queue filled by a
flood can only remain full for time t + expire_time after the flood
ends.  After that there will be a dequeue that throws out all the
flood packets.  Then your next packet will be accepted and delayed at
most expire_time.

This is only slightly worse than the guarantee you get by expiring at
both enqueue and dequeue.  I see that the same could be said for only
expiring at enqueue, but that's much harder.  In particular the
dequeue only solution can be done by the classful qdiscs on their own
while the enqueue only (or both) cannot.
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/