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.
