On 3/21/2016 10:07 PM, Ananyev, Konstantin wrote: > >> -----Original Message----- >> From: dev [mailto:dev-bounces at dpdk.org] On Behalf Of Ilya Maximets >> Sent: Monday, March 21, 2016 4:50 AM >> To: Yuanhan Liu >> Cc: dev at dpdk.org; Xie, Huawei; Dyasly Sergey >> Subject: Re: [dpdk-dev] [PATCH v4] vhost: use SMP barriers instead of >> compiler ones. >> >> >> >> On 18.03.2016 15:41, Yuanhan Liu wrote: >>> On Fri, Mar 18, 2016 at 03:23:53PM +0300, Ilya Maximets wrote: >>>> Since commit 4c02e453cc62 ("eal: introduce SMP memory barriers") virtio >>>> uses architecture dependent SMP barriers. vHost should use them too. >>>> >>>> Fixes: 4c02e453cc62 ("eal: introduce SMP memory barriers") >>>> >>>> Signed-off-by: Ilya Maximets <i.maximets at samsung.com> >>>> --- >>>> lib/librte_vhost/vhost_rxtx.c | 7 ++++--- >>>> 1 file changed, 4 insertions(+), 3 deletions(-) >>>> >>>> diff --git a/lib/librte_vhost/vhost_rxtx.c b/lib/librte_vhost/vhost_rxtx.c >>>> index b4da665..859c669 100644 >>>> --- a/lib/librte_vhost/vhost_rxtx.c >>>> +++ b/lib/librte_vhost/vhost_rxtx.c >>>> @@ -315,7 +315,7 @@ virtio_dev_rx(struct virtio_net *dev, uint16_t >>>> queue_id, >>>> rte_prefetch0(&vq->desc[desc_indexes[i+1]]); >>>> } >>>> >>>> - rte_compiler_barrier(); >>>> + rte_smp_wmb(); >>>> >>>> /* Wait until it's our turn to add our buffer to the used ring. */ >>>> while (unlikely(vq->last_used_idx != res_start_idx)) >>>> @@ -565,7 +565,7 @@ virtio_dev_merge_rx(struct virtio_net *dev, uint16_t >>>> queue_id, >>>> >>>> nr_used = copy_mbuf_to_desc_mergeable(dev, vq, start, end, >>>> pkts[pkt_idx]); >>>> - rte_compiler_barrier(); >>>> + rte_smp_wmb(); >>>> >>>> /* >>>> * Wait until it's our turn to add our buffer >>>> @@ -923,7 +923,8 @@ rte_vhost_dequeue_burst(struct virtio_net *dev, >>>> uint16_t queue_id, >>>> sizeof(vq->used->ring[used_idx])); >>>> } >>>> >>>> - rte_compiler_barrier(); >>>> + rte_smp_wmb(); >>>> + rte_smp_rmb(); >>> rte_smp_mb? >> rte_smp_mb() is a real mm_fence() on x86. And we don't need to synchronize >> reads with >> writes here, only reads with reads and writes with writes. It is enough >> because next >> increment uses read and write. Pair of barriers is better because it will >> not impact >> on performance on x86. > Not arguing about that particular patch, just a question: > Why do we have: > #define rte_smp_mb() rte_mb()
Konstantine, actually smp_mb is defined as mfence while smp_r/wmb are defined as barrier in kernel_src/arch/x86/include/asm/barrier.h. > for x86? > Why not just: > #define rte_smp_mb() rte_compiler_barrier() > here? > I meant for situations when we do need real mfence, there is an 'rte_mb' to > use. > Konstantin > >> Best regards, Ilya Maximets.