On Wed, 2007-09-05 at 01:12 -0700, David Miller wrote: > Something this evening is obviously making it impossible > for my brain to understand this function and your patch, > so I'm going to sleep on it and try again tomorrow :-)
It is one of those areas that are hard to size-up in a blink;-> Gut-feeling: It doesnt sit right with me as well. With (2.6.18-rxX++) QDISC_RUNNING changes that mean only one of N CPUs will be dequeueing while the N-1 maybe enqueueing concurently. All N CPUs contend for the queue lock; and theres a possible window between releasing the queue lock by the dequeuer-CPU and enqueuer-CPU for a race. The dequeuer-CPU entering one last time helps. Krishna, you probably saw this "wasted entry into qdisc" under low traffic conditions with more than likely only one CPU sending, am i correct? Under heavier traffic when we have multiple CPUs funneling to the same device, that entry is not really a "waste" because we endup only go in once per X number of packets enqueued on the qdisc and that check is absolutely necessary because a different CPU may have enqueued while you were not looking. In the case of low traffic, X=1 - so it is a waste there albeit a necessary one. 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
