On Mon, Sep 15, 2008 at 04:44:08PM -0700, Duyck, Alexander H wrote:
...
quoted text
> The only thing I really prefer about my solution as opposed to the solution
> Dave implemented was that it would mean only one dequeue instead of a peek
> followed by a dequeue.  I figure the important thing is to push the
> discovery of us being stopped to as soon as possible in the process.
> 
> It will probably be a few days before I have a patch with my approach ready.
> I didn't realize how complex it would be to resolve this issue for CBQ, HTB,
> HFSC, etc.  Also it is starting to look like I will probably need to implement
> another function to support this since it seems like the dequeue operations
> would need to be split into a multiqueue safe version, and a standard version
> to support some workarounds like those found in qdisc_peek_len() for HFSC.

Actually, looking at this HFSC now I start to doubt we need to
complicate these things so much. If HFSC is OK with its simple
hfsc_requeue() I doubt other qdiscs need much more, and we should
reconsider David's idea to do the same on top, in dev_requeue_skb().
Qdiscs like multiq would probably never use this, and these above
mentioned (not mq-optimized) qdiscs could be used with multiq if
needed. Then, it seems, it would be enough to improve multiq as a
"leaf" adding these dedicated operations and/or flags.

Thanks,
Jarek P.
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html