On Fri, 2007-11-05 at 11:13 -0700, Waskiewicz Jr, Peter P wrote: > After thinking about this a bit more: even if the queue is stopped, > you'd end up requeueing anyways. Plus, you'd need to re-acquire > dev->queue_lock (which is what happens today). I think the best way > overall would be to check the queue state before you physically dequeue > (whether it's in qdisc_restart() or in the qdisc's ->dequeue()).
For lockless drivers, I think it could be moved up; only thing is nothing is stopping it from changing again at transmit time. For drivers that are not lockless, i am wondering if its even useful to have that check given we have already grabbed the tx lock. > That > way you still hold dev->queue_lock in case the queue is stopped, and > haven't yet pulled an skb causing a requeue event. It certainly sounds like a useful optimization. Defer that thought - for now i just want to make sure its doing what the previous code did. I will repost the fixed patch later today after some testing; if you have time i will appreciate some eyeballing. That piece of code is hairy. Hopefully we can make it bald. cheers, jamal - To unsubscribe from this list: send the line "unsubscribe netdev" in the body of a message to [EMAIL PROTECTED] More majordomo info at http://vger.kernel.org/majordomo-info.html
