From mboxrd@z Thu Jan  1 00:00:00 1970
From: Yuanhan Liu <yuanhan.liu@linux.intel.com>
Subject: Re: [dpdk-stable] [PATCH 1/2] net/virtio: fix
 performance regression due to TSO enabling
Date: Mon, 16 Jan 2017 15:12:18 +0800
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
Cc: Thomas Monjalon <thomas.monjalon@6wind.com>,
 Jianbo Liu <jianbo.liu@linaro.org>, Jerin Jacob <jerin.jacob@cavium.com>,
 Chao Zhu <chaozhu@linux.vnet.ibm.com>, dev@dpdk.org,
 Tan Jianfeng <jianfeng.tan@intel.com>,
 Wang Zhihong <zhihong.wang@intel.com>,
 Olivier Matz <olivier.matz@6wind.com>,
 Maxime Coquelin <maxime.coquelin@redhat.com>,
 "Michael S. Tsirkin" <mst@redhat.com>,
 =?iso-8859-1?Q?Ors=E1k?= Michal <xorsak01@stud.fit.vutbr.cz>
To: Jan Viktorin <viktorin@rehivetech.com>
Return-path: <dev-bounces@dpdk.org>
Received: from mga02.intel.com (mga02.intel.com [134.134.136.20])
 by dpdk.org (Postfix) with ESMTP id 4EDDB108F
 for <dev@dpdk.org>; Mon, 16 Jan 2017 08:10:07 +0100 (CET)
Content-Disposition: inline
In-Reply-To: <20170113061309.GF9770@yliu-dev.sh.intel.com>
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
Errors-To: dev-bounces@dpdk.org
Sender: "dev" <dev-bounces@dpdk.org>

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