devik wrote:
If you read comment above htb_dequeue_tree, it should be called
only when it is sure that there are packets inside of the level/prio.
It is known by other HTB mechanism (per-level activity lists).
Thus the bugtrap is to catch case where class was inserted
into activity list
Yes I agree with you regarding zero queue size. I plan
to make patch similar to your proposal. I hope it will
be today.
---
Martin Devera aka devik
Linux kernel QoS/HTB maintainer
http://luxik.cdi.cz/~devik/
On Mon, 21 Jul 2003 [EMAIL PROTECTED] wrote:
devik
If you read comment above htb_dequeue_tree, it should be called
only when it is sure that there are packets inside of the level/prio.
It is known by other HTB mechanism (per-level activity lists).
Thus the bugtrap is to catch case where class was inserted
into activity list because it
devik wrote:
If you read comment above htb_dequeue_tree, it should be called
only when it is sure that there are packets inside of the level/prio.
It is known by other HTB mechanism (per-level activity lists).
Thus the bugtrap is to catch case where class was inserted
into activity list because it
If you read comment above htb_dequeue_tree, it should be called
only when it is sure that there are packets inside of the level/prio.
It is known by other HTB mechanism (per-level activity lists).
Thus the bugtrap is to catch case where class was inserted
into activity list because it had packets
devik wrote:
If you read comment above htb_dequeue_tree, it should be called
only when it is sure that there are packets inside of the level/prio.
It is known by other HTB mechanism (per-level activity lists).
Thus the bugtrap is to catch case where class was inserted
into activity list because it
