From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga04.intel.com (mga04.intel.com [192.55.52.120]) by dpdk.org (Postfix) with ESMTP id A08005588 for ; Thu, 12 Jan 2017 03:28:58 +0100 (CET) Received: from orsmga003.jf.intel.com ([10.7.209.27]) by fmsmga104.fm.intel.com with ESMTP; 11 Jan 2017 18:28:48 -0800 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.33,347,1477983600"; d="scan'208";a="921565994" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by orsmga003.jf.intel.com with ESMTP; 11 Jan 2017 18:28:46 -0800 Date: Thu, 12 Jan 2017 10:30:58 +0800 From: Yuanhan Liu To: Thomas Monjalon Cc: Jianbo Liu , Jerin Jacob , Jan Viktorin , Chao Zhu , dev@dpdk.org, Tan Jianfeng , Wang Zhihong , Olivier Matz , Maxime Coquelin , "Michael S. Tsirkin" Message-ID: <20170112023058.GF2402@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> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <1610499.AMUobBPor6@xps13> 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: Thu, 12 Jan 2017 02:28:59 -0000 On Wed, Jan 11, 2017 at 03:51:22PM +0100, Thomas Monjalon wrote: > 2017-01-11 12:27, Yuanhan Liu: > > The fact that virtio net header is initiated to zero in PMD driver > > init stage means that these costly writes are unnecessary and could > > be avoided: > > > > if (hdr->csum_start != 0) > > hdr->csum_start = 0; > > > > And that's what the macro ASSIGN_UNLESS_EQUAL does. With this, the > > performance drop introduced by TSO enabling is recovered: it could > > be up to 20% in micro benchmarking. > > This patch is adding a condition to assignments. > We need a benchmark on other architectures like ARM. Please anyone? I think the cost of condition should be way lower than the cost from the penalty introduced by the cache issue, that I don't see it would perform bad on other platforms. But, of course, testing is always welcome! --yliu > > > [...] > > +/* avoid write operation when necessary, to lessen cache issues */ > > +#define ASSIGN_UNLESS_EQUAL(var, val) do { \ > > + if ((var) != (val)) \ > > + (var) = (val); \ > > +} while (0)