Hi, > This has been discussed a number of times before on list, and the consensus > seems to be that the correct way to fix this is to introduce a set of specific > barrier operations that insert the correct barrier type on each architecture, > i.e. compiler barriers on IA, and full wmbs on architectures that require > that. Linux kernel contains two sets of macros: *mb() and smp_*mb(). As far as I understand, the former are meant to order memory accesses when interacting with peripherals (physical NICs in our case), and the latter - to provide synchronization between CPU cores (applicable for virtual NICs in our case). smp_*mb() for Intel architecture would be a simple compiler barrier, whereas for processors with weaker memory model they may use real barrier instructions. Maybe implementing barriers similar way would work in DPDK as well?
-- Best regards, Nikita Kalyazin, n.kalyazin at samsung.com Software Engineer Virtualization Group Samsung R&D Institute Russia Tel: +7 (495) 797-25-00 #3816 Tel: +7 (495) 797-25-03 Office #1501, 12-1, Dvintsev str., Moscow, 127018, Russia On Tue, Oct 20, 2015 at 03:29:51PM +0100, Bruce Richardson wrote: > On Tue, Oct 20, 2015 at 05:07:46PM +0300, Nikita Kalyazin wrote: > > Descriptors that have been put into the used vring must be observable by > > guest earlier than the new used index value. > > Although compiler barrier serves well for Intel architectue here, the > > proper cross-platform solution is to use write barrier before the used > > index is updated. > > > > Signed-off-by: Nikita Kalyazin <n.kalyazin at samsung.com> > > --- > Yes, but no! :-) > > This has been discussed a number of times before on list, and the consensus > seems to be that the correct way to fix this is to introduce a set of specific > barrier operations that insert the correct barrier type on each architecture, > i.e. compiler barriers on IA, and full wmbs on architectures that require > that. > > See discussion here: http://dpdk.org/dev/patchwork/patch/4293/ > and in the thread here: http://dpdk.org/ml/archives/dev/2015-March/015202.html > > So correct problem statment, but unfortunately NAK for the implementation. > > Patches for general memory barrier implementation as described above welcome > :-) > > Regards, > /Bruce
