From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <konstantin.ananyev@intel.com>
Received: from mga14.intel.com (mga14.intel.com [192.55.52.115])
 by dpdk.org (Postfix) with ESMTP id D27AB68AE
 for <dev@dpdk.org>; Fri,  1 Aug 2014 15:54:23 +0200 (CEST)
Received: from fmsmga003.fm.intel.com ([10.253.24.29])
 by fmsmga103.fm.intel.com with ESMTP; 01 Aug 2014 06:49:29 -0700
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="4.97,862,1389772800"; d="scan'208";a="366721537"
Received: from irsmsx103.ger.corp.intel.com ([163.33.3.157])
 by FMSMGA003.fm.intel.com with ESMTP; 01 Aug 2014 06:53:15 -0700
Received: from irsmsx152.ger.corp.intel.com (163.33.192.66) by
 IRSMSX103.ger.corp.intel.com (163.33.3.157) with Microsoft SMTP Server (TLS)
 id 14.3.195.1; Fri, 1 Aug 2014 14:56:25 +0100
Received: from irsmsx105.ger.corp.intel.com ([169.254.7.240]) by
 IRSMSX152.ger.corp.intel.com ([169.254.6.214]) with mapi id 14.03.0195.001;
 Fri, 1 Aug 2014 14:56:24 +0100
From: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
To: Neil Horman <nhorman@tuxdriver.com>, "Richardson, Bruce"
 <bruce.richardson@intel.com>
Thread-Topic: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of
 some isolated features
Thread-Index: AQHPrPIMyxOvxeKbSEaZ4mzC/qZsY5u7wZiZgAADkdA=
Date: Fri, 1 Aug 2014 13:56:24 +0000
Message-ID: <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com>
References: <1406665466-29654-1-git-send-email-nhorman@tuxdriver.com>
 <20140730210920.GB6420@localhost.localdomain>
 <20140731131351.GA20718@hmsreliant.think-freely.org>
 <5766264.li3nkTmgY6@xps13>
 <20140731143228.GB20718@hmsreliant.think-freely.org>
 <20140731181032.GC20718@hmsreliant.think-freely.org>
 <20140731183631.GC6420@localhost.localdomain>
 <20140731190117.GD20718@hmsreliant.think-freely.org>
 <20140731201949.GA28495@localhost.localdomain>
 <20140801133655.GA31979@hmsreliant.think-freely.org>
In-Reply-To: <20140801133655.GA31979@hmsreliant.think-freely.org>
Accept-Language: en-IE, en-US
Content-Language: en-US
X-MS-Has-Attach: 
X-MS-TNEF-Correlator: 
x-originating-ip: [163.33.239.180]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of
 some isolated features
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <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>
X-List-Received-Date: Fri, 01 Aug 2014 13:54:24 -0000

> From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> Sent: Friday, August 01, 2014 2:37 PM
> To: Richardson, Bruce
> Cc: dev@dpdk.org
> Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of=
 some isolated features
>=20
> On Thu, Jul 31, 2014 at 01:19:50PM -0700, Bruce Richardson wrote:
> > On Thu, Jul 31, 2014 at 03:01:17PM -0400, Neil Horman wrote:
> > > On Thu, Jul 31, 2014 at 11:36:32AM -0700, Bruce Richardson wrote:
> > > >
> > > > I think a good first step here that I can't see anyone objecting to=
 is
> > > > to enable the ixgbe driver to use the vector code path for a generi=
c
> > > > x86_64 build. I've run a quick test here, and changing "_mm_popcnt_=
u64"
> > > > to "__builtin_popcountll" [and the include from nmmintrin to tmmint=
rin]
> > > > allows a compile for machine type default, and testpmd can still fo=
rward
> > > > packets at a good rate (roughly perf down about 10% vs native compi=
le on
> > > > SNB).
> > > > The ACL is a tougher nut to crack, but anyone see any issues with t=
hat
> > > > two-line change to ixgbe_rxtx_vec.c? [Neil, since you started the p=
atch
> > > > set thread, do you want to submit an official patch here, or would =
you prefer I
> > > > do so?]
> > > >
> > >
> > > I'm happy to do so, Though 10% performance degradation vs. using the =
sse4.2
> > > instructions in that path seems significant, isn't it? Given that per=
formance
> > > delta, it seems like it would still be preferable to have a path that=
 used the
> > > sse4.2 instructions when they're available.  Or am I misreading what =
you mean
> > > when you say down 10%
> > >
> > > Neil
> > >
> > Ok, I did a little bit more testing here. Using the vector pmd compiled
> > for generic x86_64 and using __builtin_popcountll is approx 35% faster
> > for packet IO than the existing fast-path functions. It is also 7% (a
> > bit lower than ~10% as I originally stated) slower than the existing
> > native-compiled vpmd on a Sandy Bridge platform.
> >
> > I then ran an extra test, using EXTRA_CFLAGS=3D'-msse4.2' to turn on th=
e
> > extra instructions. The ~7% performance drop went to ~3%, so we would
> > gain a little more with using SSE4.2, but compared to the gain from
> > having the vector driver at all, it's not that much. [I don't have a
> > system handy with AVX2 support to see what boosts might come from
> > compiling with that instruction set enabled.]
> >
> > Because of this, I'd take the ~35% speed boost for now, and try and fin=
d
> > what would be the best general way to solve this problem across all
> > libraries. Also, I think that anyone who needs that extra 4% performanc=
e
> > probably wants the other 3% too, and so will compile up the code from
> > source using the "native" compilation target. :-)
> >
>=20
>=20
> Wait a moment, I'm not entirely sure what you did here.  I understand tha=
t you
> replaced the _mm_popcnt_u64 call in the ixgbe pmd vector receive path wit=
h
> __builtin_popcnt, which is good, but ixgbe also uses the __mm_shuffle_epi=
8
> intrinsic which is only available with sse4.2 from what I can see. did yo=
u
> replace those calls with a __builtin_shuffle variant?  Otherwise, how did=
 you
> get the pmd to build?  I'm asking because this is what I tried in the fir=
st pass
> and Konstantin gave some pretty convicing evidence that this was an unwor=
kable
> solution:
> http://dpdk.org/ml/archives/dev/2014-July/004443.html
>=20

I think that _mm_shuffle_epi8 (PSHUFB) is available starting from SSE3.
So I presume, there is no need for replacement.
Konstantin