Quoting r. Roland Dreier <[EMAIL PROTECTED]>: > Subject: Re: [PATCH (updated)] ipoib: dont lock tx on completion > > Michael> We are now only looking at tx_tail and > Michael> netif_queue_stopped outside the lock (tx_head is only > Michael> used inside the lock): > > Thanks, that helps. > > Michael> We have a write barrier in between, so its guaranteed > Michael> tx_tail is written before we test netif_queue_stopped. > > Michael> On the other hand, the send code has a barrier after it > Michael> stops the interface, so this bit is written before we > Michael> test tx_tail the second time. > > Michael> So, in the scenario where send stops the interface, > Michael> either the completion code will see it stopped, or the > Michael> send code will see tx tail updated. > > You may be right but I'm having a hard time convincing myself. I > don't think just the write barriers are enough -- they just mean that > the CPU where the writes are being done will complete the writes in > order.
I know. I put it there so that read coming after that wont be done after the write. > Without a read barrier, the CPU doing the tests can execute > the read whenever it wants. Isnt the read barrier basically the same, just ensuring reads are done in order? > I've seen the PPC 970 move reads absurdly > far, and the compiler can reorder things even more. > > - R. > Hmm, I think I have it covered. If the read of netif_queue_stopped is delayed by a huge margin, we see the interface stopped and wake it up. If the read of tx_tail is delayed, we see the tail updated and wake it up in the send routine. No? What is the race you see? -- MST - Michael S. Tsirkin _______________________________________________ openib-general mailing list [email protected] http://openib.org/mailman/listinfo/openib-general To unsubscribe, please visit http://openib.org/mailman/listinfo/openib-general
