On 2021/6/17 3:14, Jason Gunthorpe wrote: > On Wed, Jun 16, 2021 at 09:55:45AM +0000, liweihang wrote: > >> If there is still any issues in this process, could you please tell us where to >> add the barrier? Thank you :) > > I don't know ARM perfectly well, but generally look at > > 1) Do these special stores barrier with the spin unlock protecting > the post send? Allowing them to leak out will get things out of > order I do not think we need to rely on the spin unlock to ensure correct ordering for ST4 store. ST4 store is similiar as DB store, the difference is that DB store writes 8 bytes to the device's MMIO space and ST4 store writes 64 bytes, the ST4 store can be ordered by udma_to_device_barrier() too, which mean we can also use udma_to_device_barrier() to ensure correct ordering between ST4 store and DB store too. > > 2) ARM MMIO stores are not ordered, so that DB store the ST4 store > are not guaranteed to execute in program order without a barrier. > The spinlock is not a MMIO barrier > As there is udma_to_device_barrier() between each round of post send, we can guarantee that the last DB store/ST4 store reaches the device before issuing the the next DB store/ST4 store. > You could ignore some of this when the DB rings were basically > idempotent, but if you are xfering data it is more tricky. This is why > we always see a barrier after a WC store to put all future MMIO > strongly in order with the store. > > Jason > "st4 store" writes the doorbell and the content of WQE to the roce engine, and the st4 store ensure doorbell and the content of WQE both reach the roce engine at the same time. we tried to avoid WC store by using st4 store here, as WC store might need a different barrier in order to flush the data to the device. Thanks Weihang
