LARTC - May 2005 - Qdisc requeue should be void?

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.

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