> > If they have multiple TX queues, independantly programmable, that > > single lock is stupid. > > > > We could use per-queue TX locks for such hardware, but we can't > > support that currently. > > There could be bad packet reordering with this (like some SMP > routers used to do).
My original multiqueue patches I submitted actually had a per-queue Tx lock, but it was removed since the asymmetry in the stack for locking was something people didn't like. Locking a queue for ->enqueue(), unlocking, then locking for ->dequeue(), unlocking, was something people didn't like very much. Also knowing what queue to lock on ->enqueue() was where the original ->map_queue() idea came from, since we wanted to lock before calling ->enqueue(). -PJ - 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
