Stephen Hemminger wrote: > There is an design problem with the qdisc interface that causes qlen related > bugs > in netem, tbf, and other qdisc's that peek at the top of the queue. The > problem is > that requeue needs to be called from the dequeue function but requeue can > fail. > If requeue fails, then the calling qdisc can not properly handle the error. > If it > returns NULL, then the parent's expectation about qlen gets messed up. > > Example: > > prio (qlen = 1) > skb = netem dequeue > skb = htb dequeue > ... decides not to send this skb now > htp requeue(skb) fails > ?? what now > --netem.qlen // := 0 > return NULL > skb is NULL > > at this point prio qlen is 1 but underlying queue's are empty. > > My proposal is to require requeue to always succeed and change it to be > void instead of returning int.
Perhaps we should add a ->peek() operation which guarantees that the next dequeued packet is the one peeked at. This would also help with a second problem resulting from requeueing in at least TBF and HFSC. TBF looks at a packet and if it can't be sent immediately calculates the delay from the packet's length. HFSC does the same to calculate the deadline for a class. Both assume the next packet dequeued from the underlying qdisc is the one requeued, which is only true with non-reordering qdiscs. Adding a peek-operation increases the worst-case delay by one maximum sized packet transmission time, but otherwise these qdiscs can't make proper use of reordering qdiscs like SFQ at all. Regards Patrick _______________________________________________ LARTC mailing list [email protected] http://mailman.ds9a.nl/cgi-bin/mailman/listinfo/lartc
