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 9FAE22C10 for ; Wed, 17 Aug 2016 11:42:28 +0200 (CEST) Received: from fmsmga004.fm.intel.com ([10.253.24.48]) by orsmga101.jf.intel.com with ESMTP; 17 Aug 2016 02:42:27 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.28,529,1464678000"; d="scan'208";a="157054409" Received: from yliu-dev.sh.intel.com (HELO yliu-dev) ([10.239.67.162]) by fmsmga004.fm.intel.com with ESMTP; 17 Aug 2016 02:42:26 -0700 Date: Wed, 17 Aug 2016 17:51:11 +0800 From: Yuanhan Liu To: Maxime Coquelin Cc: "Wang, Zhihong" , "dev@dpdk.org" Message-ID: <20160817095111.GQ30752@yliu-dev.sh.intel.com> References: <1471319402-112998-1-git-send-email-zhihong.wang@intel.com> <8F6C2BD409508844A0EFC19955BE09411077206B@SHSMSX103.ccr.corp.intel.com> <20160817023825.GO30752@yliu-dev.sh.intel.com> <8F6C2BD409508844A0EFC19955BE09411077220A@SHSMSX103.ccr.corp.intel.com> <020de331-94f0-049a-6e7d-30825faf54dd@redhat.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <020de331-94f0-049a-6e7d-30825faf54dd@redhat.com> User-Agent: Mutt/1.5.23 (2014-03-12) Subject: Re: [dpdk-dev] [PATCH] optimize vhost enqueue X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Wed, 17 Aug 2016 09:42:29 -0000 On Wed, Aug 17, 2016 at 11:17:46AM +0200, Maxime Coquelin wrote: > >>>This is something I've thought about while writing the code, the reason I > >>>keep it as one function body is that: > >>> > >>> 1. This function is very performance sensitive, and we need full control of > >>> code ordering (You can compare with the current performance with the > >>> mrg_rxbuf feature turned on to see the difference). > >> > >>Will inline functions help? > > > > > >Optimization in this patch actually reorganizes the code from its logic, > >so it's not suitable for making separated functions. > > > >I'll explain this in v2. > > I agree with Yuanhan. > Inline functions should not break the optimizations. > IMHO, this is mandatory for the patch to be accepted. Yes. > It seems you are not the only one facing the issue: > https://github.com/YanVugenfirer/kvm-guest-drivers-windows/issues/70 > > So a dedicated fix is really important. Yes. > > >This patch doesn't try to fix this issue, it rewrites the logic totally, > >and somehow fixes this issue. > > > >Do you think integrating this whole patch into the stable branch will work? > >Personally I think it makes more sense. > > No. > We don't even know why/how it fixes the Windows issue, which would be > the first thing to understand before integrating a fix in stable branch. Yes. > > And the stable branch is not meant for integrating such big reworks, > it is only meant to fix bugs. Yes. > The risk of regressions have to be avoided as much as possible. Yes. --yliu