> packets at dequeue time only in clasfull qdisc. It also makes better > sense because qdosc can also instruct SFQ to drop packet - this drop > > I don't understand. What other qdisc instructs SFQ to drop? CBQ only at the moment. It can call q->ops->drop on inner qdisc as response to overlimit event. It forces system to converge faster to underlimit state > Another important info: you really CAN'T drop packets in dequeue > routine if you don't want to fool classfull parent. Many logic > in CBQ/HTB/ATM/PRIO qdisc is based on the existence of backlog. > > I gather you only care whether this qdisc is waiting to send, not how > much is in the queue. yes .. > SOLUTIONS: > One way is to monitor (store) q.qlen variable of all children of > classfull qdisc. When I call enqueue/drop/dequeue on it I'll see > its discrepancy agains last stored value and will update my counter > > This seems like the right solution, except that you shouldn't even > need to store a counter. Just use the one in the child qdisc. > BTW, I think you are justified in assuming that this counter can only > change in two ways: decrease when dequeue is called (but possibly by > more than one packet) and increase by 1 when enqueue is called. > And I guess also requeue. Which raises another problem, since that's > not called by the parent, right? No - you can't use the q.qlen of inner. It is under inner's control and you can't change it. And the assumption how it can change should not be used unless you have some rules for all qdisc how to change it. Somewhere in sources you can read that one of qdisc duties is to ensure that it's q.qlen value is correct. It doesn't restrict how it can change and when. I'd suggest for each leaf to maintain last_qlen variable which would start with 0 (also q.qlen will be 0). Then time to time (in enqueue, dequeue, drop ....) you can "repair" your own q.qlen by doing: q.qlen += cl->q.qlen - cl->last_qlen; cl->last_qlen = cl->q.qlen; for each leaf cl. Hence xl->last_qlen tells you what part of total q.qlen is "owned" by cl. Simple and robust, isn't it ? > I like those, but also suggested that HTB would be a good place to add > code for dropping stale packets. If you're interested in doing that I > should mention: > Not all packets come with timestamps (e.g., locally generated ones). > Solution: at enqueue, if the timestamp is 0, set it to the current > time. It would be better done in fifo/sfq. It is because HTB can do it only when dequeuing and at that time some packets were already dropped by SFQ because if has had queues full of "old" packets. SFQ should maintain pqio queue of all packets and look at head of the list sometimes to keep its queues frre of old packets and thus to have room for new ones. devik
