From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 4EC652BA7; Mon, 7 May 2018 05:49:19 +0200 (CEST) X-Amp-Result: UNSCANNABLE X-Amp-File-Uploaded: False Received: from orsmga001.jf.intel.com ([10.7.209.18]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 06 May 2018 20:49:16 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.49,372,1520924400"; d="scan'208";a="53718582" Received: from debian.sh.intel.com (HELO debian) ([10.67.104.164]) by orsmga001.jf.intel.com with ESMTP; 06 May 2018 20:49:15 -0700 Date: Mon, 7 May 2018 11:49:49 +0800 From: Tiwei Bie To: Maxime Coquelin Cc: dev@dpdk.org, jianfeng.tan@intel.com, mst@redhat.com, stable@dpdk.org Message-ID: <20180507034949.cicjhwlzz664psst@debian> References: <20180430155954.9939-1-maxime.coquelin@redhat.com> <20180503115634.feaimkzpnbodferd@debian> <6125f044-d557-666a-8228-4930ead16089@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=utf-8 Content-Disposition: inline In-Reply-To: <6125f044-d557-666a-8228-4930ead16089@redhat.com> User-Agent: NeoMutt/20170113 (1.7.2) 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:49:20 -0000 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 > > > [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