Michael> Hmm, I think I have it covered.
Michael> If the read of netif_queue_stopped is delayed by a huge
Michael> margin, we see the interface stopped and wake it up.
Michael> If the read of tx_tail is delayed, we see the tail
Michael> updated and wake it up in the send routine.
Michael> No? What is the race you see?
I think the wmb() has to at least become barrier() -- otherwise the
send routine has no reason to reread tx_tail after it stops the queue.
I don't see a specific race -- I'm just not totally comfortable yet,
even with that fixed. The issue is not necessarily reads being
delayed, since both an out-of-order CPU and a compiler may move reads
much _earlier_ than they appear in the code (for example a read may be
speculatively executed because of branch prediction for a test in an
if statement).
- R.
_______________________________________________
openib-general mailing list
[email protected]
http://openib.org/mailman/listinfo/openib-general
To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
