From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga02.intel.com (mga02.intel.com [134.134.136.20]) by dpdk.org (Postfix) with ESMTP id 4EDDB108F for ; Mon, 16 Jan 2017 08:10:07 +0100 (CET) Received: from orsmga002.jf.intel.com ([10.7.209.21]) by orsmga101.jf.intel.com with ESMTP; 15 Jan 2017 23:10:07 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,238,1477983600"; d="scan'208";a="31033438" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga002.jf.intel.com with ESMTP; 15 Jan 2017 23:10:04 -0800 Date: Mon, 16 Jan 2017 15:12:18 +0800 From: Yuanhan Liu To: Jan Viktorin Cc: Thomas Monjalon , Jianbo Liu , Jerin Jacob , Chao Zhu , dev@dpdk.org, Tan Jianfeng , Wang Zhihong , Olivier Matz , Maxime Coquelin , "Michael S. Tsirkin" , =?iso-8859-1?Q?Ors=E1k?= Michal Message-ID: <20170116071218.GN9770@yliu-dev.sh.intel.com> References: <1484108832-19907-1-git-send-email-yuanhan.liu@linux.intel.com> <1484108832-19907-2-git-send-email-yuanhan.liu@linux.intel.com> <1610499.AMUobBPor6@xps13> <20170112023058.GF2402@yliu-dev.sh.intel.com> <20170112160256.6915ff12.viktorin@rehivetech.com> <20170113061309.GF9770@yliu-dev.sh.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <20170113061309.GF9770@yliu-dev.sh.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [dpdk-stable] [PATCH 1/2] net/virtio: fix performance regression due to TSO enabling 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, 16 Jan 2017 07:10:08 -0000 On Fri, Jan 13, 2017 at 02:13:09PM +0800, Yuanhan Liu wrote: > But it's not the test methodology I'd expect. You are purely testing > the instruction cycles. The drop on ARM is something more like "the > if instruction takes more cycles than the simple assignment". > > This macro is used in the case that one process is heavily writing > same value (0 here) again and again while another process is heavily > read it also again and again. That means cache violation always > happen. With this macro, however, this cache issue could be avoided, > since no write happens. > > For such workload, I don't think it would behaviour worse on ARM. No reply yet; I will treat it as no objections, and please shout out if any. Both applied to dpdk-next-virtio. --yliu