Hi Gagan, > I have to claim incomplete familiarity for the code. But still, if > you're out there running with no locks for a period, there's no > assumption you can make. The "lock could be held quickly" assertion is a > fallacy.
I will try to explain since the code is pretty complicated. Packets coming to IP (in dev_queue_xmit) are first added to a FIFO queue associated with the device (queue_lock is first held). Then qdisc_run is called and if it can set the QDISC_RUNNING bit (making it the "sole dequeue'r"), it calls qdisc_restart (which *could* get the tx lock) and drops the queue_lock to call the actual driver xmit routine. Meanwhile 'n' cpus can race and add more skbs to the same queue, each getting this lock for a short time and dropping, and all these skbs are added to the end of the queue. These are "pure enqueuer's" (since their attempt to set the same bit fails and they return from qdisc_run). In the original thread, the dequeue'r gets an error from driver xmit. It first re-gets the queue_lock and calls requeue, which adds the skb to the head of the queue. Since no one else has been able to dequeue packets while the RUNNING bit is set, packet re-ordering cannot happen. After returning to __qdisc_run, the RUNNING bit is cleared. Hope that clarifies the code. thanks, - KK - 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
