On Wed, Aug 09, 2006 at 10:25:30AM +1000, Herbert Xu wrote:
> The problem here is that the TX clean function does not take the lock
> (nor do we want it to). It can thus come in while you're transmitting
> and empty the queue.
That can be solved with sequence numbers -- ie, we keep track of the number
of packets queued to the hardware, as well as tracking the number of tx
completions that have been reaped. Because those numbers are flushed to
memory by other locks (barriers) taken during processing, the code in
hard_start_xmit() and the actual tx completion reaping could be done without
the atomic ops. The key thing is that the higher level code in the network
stack calling dev->hard_start_xmit() would know that it needs to retry if
the tx complete sequence changes. I'll ponder this a bit more and try to
come up with some sample code.
-ben
--
"Time is of no importance, Mr. President, only life is important."
Don't Email: <[EMAIL PROTECTED]>.
-
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
