On Sat, Sep 13, 2008 at 11:16:10PM -0700, Herbert Xu wrote:
quoted text
> On Sat, Sep 13, 2008 at 10:54:08PM +0200, Jarek Poplawski wrote:
> >
> > If I get it right peek + dequeue should do all current dequeue logic
> > plus additionally write down the child qdisc or skb (leaves) info,
> > plus, probably, some ifs btw., which looks like a bit of overhead,
> > if we consider requeuing as something exceptional. Unless we don't -
> > then of course something like this could be useful.
> 
> I don't see the overhead in writing down something that we alrady
> have.  In any case, do you have an alternative solution to the
> current problem that qdisc_run looks at an arbitrary queue's
> status to decide whether it should process a qdisc that empties
> into n queues?

If it's only for this initial check I still think my earlier proposal
should be enough:
http://marc.info/?l=linux-netdev&m=122113717013988&w=2

Anyway, the main problem here was a high cpu load despite stopped
queue. Are you sure this peek, which is almost full dequeue, can
really help for this? BTW, since after current fix there were no
later complains I guess it's just about full netif_stop or non-mq
device.

Cheers,
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