Herbert Xu wrote:

On Tue, Aug 19, 2008 at 03:08:57PM +0200, Patrick McHardy wrote:

quoted

quoted

Another possibility would to replace requeue by a peek+force_dequeue
interface, where you can peek at the next packet, and you could then
dequeue that particular packet if you're satisfied.

That would be fine for TBF since it only needs to check whether
the current packet exceeds the limit and reschedule otherwise.
HFSC OTOH really needs to know the length of the next packet for
calculating the deadline.

You mean a peek interface is insufficient for HFSC? Could you
elaborate?

I might have misunderstood you, but the way I imagine force_dequeue
is that it would give you the packet peeked at, even if a higher
priority packet is available.

But actually I don't understand the use for force_dequeue at all,
assuming ->peek behaves correctly ->dequeue should already hand
out the correct packet.

(Note: Its OK to hand out a different packet if we had a ->enqueue
operation after ->peek since the upper qdisc can just re-peek and
recalculate based on the new highest priority packet).