On Sun, 2005-24-07 at 18:04 -0700, David S. Miller wrote: > But this simply doesn't work by itself, that's why we need the > per-queue "stopped" states. > > We need something that properly synchronizes the queue "full" > state transitions, so that the queue does not deadlock and when > one priority queue fills up, we do the right thing. > > All of the packet scheduler is keyed off of being able to atomically > "send the queue X while not stopped", and that transition from > stopped to not-stopped is interlocked properly with the asynchronous > sending path. > > Alexey explained this to both you and I about 3 years ago. At > the time we were talking about the prioritized queues provides > by a few gigabit NICs at the time. >
right - i remember that and the same suggestion of per-queue-stop states came up again at least twice in the discussion with Vladmir Kondratiev(finaly on CC), last time at least a year ago (most emails are on netdev). The difference now (problem) is the hardware behaviour is different depending on vendor or wire technology. The 802.11e appears to be almost TDM/CSMA/CD in its association of the rings with time slots and backoff timers while ethernet vendors have no such limitations. To make it more interesting they all really implement different "qdisc" behaviors of those tx rings (ranging from strict priority to weighted round robin and some really bizare ones - just looking at some stuff freescale, e1000, netiron etc in relation to the tx ring). I think to introduce a new code which says "continue to the next queue" (NETDEV_TX_CONT) maybe sufficient. When we get to the last queue we reschedule the softirq. Such a change would be trivial(as compared to the non-trivial per-queue state keeping interpretation); whether what i said would work _sufficiently_ is an exercise for the implementation. Now as i said before: I could be wrong. 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
