Martin Devera writes: Hi, only a few notes on the theme. You are right with the displacement and bad enqueue byte counters. Maybe it would be better to cound 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? is then not decremented from HTB/CBQ's stats. HTB uses enqueue time counting because CBQ does it too and at very I figured that's why it worked that way. begining I based my work on CBQ. Seems it is time to change things. 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. When you drop in dequeue, parent will think that he itself still has some packets somewhere (in children) and will constantly attempt to find them. And will be confused by the fact that it can't. Enqueue routine can give you confirmation of packet enqueue, drop routine the same. Only dequeue can't say hey there is your skb and by the way two others was dropped. What a pity. 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? accordingly. In the same way we could add q.bytelen and then we would be able to do the same for bytes - but this is not neccessary probably as we need to know only bytes dequeued ... My impression is that every qdisc is currently supposed to keep track of # packets in the queue, but not necessarily # bytes. Best not to change that, especially since we don't even have any currently proposed use for it. There is other way - add parameter to dequeue routine which tells us how many packets we should out qlen decrease by. But I think that former approach is simpler and prone to "silent" drops (for example by some timer). I think you're saying the former approach is better, but "prone" suggests otherwise. I prefer the former approach. It's better for all the other qdiscs out there to keep working without change. There are only a few classful qdiscs that would have to change, and they could still work unchanged with qdiscs that don't do silent drops. Don do you plan to implement these corrections for CBQ/PRIO ? Not any time soon. The last time I tried to read CBQ it was in order to figure out what all those parameters mean, and I didn't get very far. Now that I no longer use it I have less incentive. I'll do the change for HTB. Thanks. But which ones? It sounds like you plan to - count as sent only what's returned from dequeue - ignore the return value of enqueue and check the queue length to see whether it's empty 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.
