From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: 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" To: Tiwei Bie Cc: Maxime Coquelin , 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-dev] [PATCH] vhost: improve dirty pages logging performance X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-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