quoted

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