[openib-general] Re: [PATCH (updated)] ipoib: dont lock tx on completion

[Michael S. Tsirkin]

Quoting r. Roland Dreier <roland at topspin.com>:
> 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