From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <mst@redhat.com>
Received: from mx1.redhat.com (mx3-rdu2.redhat.com [66.187.233.73])
 by dpdk.org (Postfix) with ESMTP id 8B20816E;
 Mon,  7 May 2018 05:58:24 +0200 (CEST)
Received: from smtp.corp.redhat.com (int-mx06.intmail.prod.int.rdu2.redhat.com
 [10.11.54.6])
 (using TLSv1.2 with cipher AECDH-AES256-SHA (256/256 bits))
 (No client certificate requested)
 by mx1.redhat.com (Postfix) with ESMTPS id 1399F406EA5E;
 Mon,  7 May 2018 03:58:24 +0000 (UTC)
Received: from redhat.com (ovpn-123-58.rdu2.redhat.com [10.10.123.58])
 by smtp.corp.redhat.com (Postfix) with SMTP id 18EC7215CDA7;
 Mon,  7 May 2018 03:58:21 +0000 (UTC)
Date: Mon, 7 May 2018 06:58:21 +0300
From: "Michael S. Tsirkin" <mst@redhat.com>
To: Tiwei Bie <tiwei.bie@intel.com>
Cc: Maxime Coquelin <maxime.coquelin@redhat.com>, dev@dpdk.org,
 jianfeng.tan@intel.com, stable@dpdk.org
Message-ID: <20180507065450-mutt-send-email-mst@kernel.org>
References: <20180430155954.9939-1-maxime.coquelin@redhat.com>
 <20180503115634.feaimkzpnbodferd@debian>
 <6125f044-d557-666a-8228-4930ead16089@redhat.com>
 <20180507034949.cicjhwlzz664psst@debian>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Content-Disposition: inline
In-Reply-To: <20180507034949.cicjhwlzz664psst@debian>
X-Scanned-By: MIMEDefang 2.78 on 10.11.54.6
X-Greylist: Sender IP whitelisted, not delayed by milter-greylist-4.5.16
 (mx1.redhat.com [10.11.55.7]); Mon, 07 May 2018 03:58:24 +0000 (UTC)
X-Greylist: inspected by milter-greylist-4.5.16 (mx1.redhat.com [10.11.55.7]);
 Mon, 07 May 2018 03:58:24 +0000 (UTC) for IP:'10.11.54.6'
 DOMAIN:'int-mx06.intmail.prod.int.rdu2.redhat.com'
 HELO:'smtp.corp.redhat.com' FROM:'mst@redhat.com' RCPT:''
Subject: Re: [dpdk-stable] [PATCH] vhost: improve dirty pages logging
	performance
X-BeenThere: stable@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches for DPDK stable branches <stable.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/stable>,
 <mailto:stable-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/stable/>
List-Post: <mailto:stable@dpdk.org>
List-Help: <mailto:stable-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/stable>,
 <mailto:stable-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Mon, 07 May 2018 03:58:24 -0000

On Mon, May 07, 2018 at 11:49:49AM +0800, Tiwei Bie wrote:
> On Fri, May 04, 2018 at 05:48:05PM +0200, Maxime Coquelin wrote:
> > Hi Tiwei,
> > 
> > On 05/03/2018 01:56 PM, Tiwei Bie wrote:
> > > On Mon, Apr 30, 2018 at 05:59:54PM +0200, Maxime Coquelin wrote:
> [...]
> > > > +static __rte_always_inline void
> > > > +vhost_log_cache_sync(struct virtio_net *dev, struct vhost_virtqueue *vq)
> > > > +{
> > > > +	uint32_t *log_base;
> > > > +	int i;
> > > > +
> > > > +	if (likely(((dev->features & (1ULL << VHOST_F_LOG_ALL)) == 0) ||
> > > > +		   !dev->log_base))
> > > > +		return;
> > > > +
> > > > +	log_base = (uint32_t *)(uintptr_t)dev->log_base;
> > > > +
> > > > +	/* To make sure guest memory updates are committed before logging */
> > > > +	rte_smp_wmb();
> > > 
> > > It seems that __sync_fetch_and_or() can be considered a full
> > > barrier [1]. So do we really need this rte_smp_wmb()?
> > 
> > That's a good point, thanks for the pointer.
> > 
> > > Besides, based on the same doc [1], it seems that the __sync_
> > > version is deprecated in favor of the __atomic_ one.
> > 
> > I will change to __atomic_. For the memory model, do you agree I should
> > use __ATOMIC_SEQ_CST?
> 
> Maybe we can use __ATOMIC_RELAXED and keep rte_smp_wmb().
> 
> Best regards,
> Tiwei Bie

Yes I think if you do your own barriers, you can use __ATOMIC_RELAXED
in theory.

One issue is that as one lwn article noted
"there will be some seriously suboptimal code production before
gcc-7.1".  So if you are using these new APIs, you should also check
that a relatively new compiler is used.


> > 
> > > [1] https://gcc.gnu.org/onlinedocs/gcc/_005f_005fsync-Builtins.html
> > > 
> > > > +
> > > > +	for (i = 0; i < vq->log_cache_nb_elem; i++) {
> > > > +		struct log_cache_entry *elem = vq->log_cache + i;
> > > > +
> > > > +		__sync_fetch_and_or(log_base + elem->offset, elem->val);
> > > > +	}
> > > > +
> > > > +	vq->log_cache_nb_elem = 0;
> > > > +}
> > > > +
> > > [...]
> > > 
> > 
> > Thanks,
> > Maxime