From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id E37B068AE for ; Fri, 1 Aug 2014 16:25:56 +0200 (CEST) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XDDoJ-0006DJ-4b; Fri, 01 Aug 2014 10:28:00 -0400 Date: Fri, 1 Aug 2014 10:27:54 -0400 From: Neil Horman To: "Ananyev, Konstantin" Message-ID: <20140801142754.GC31979@hmsreliant.think-freely.org> References: <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> <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Fri, 01 Aug 2014 14:25:57 -0000 On Fri, Aug 01, 2014 at 01:56:24PM +0000, Ananyev, Konstantin wrote: > > 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 > > > > 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 generic > > > > > x86_64 build. I've run a quick test here, and changing "_mm_popcnt_u64" > > > > > to "__builtin_popcountll" [and the include from nmmintrin to tmmintrin] > > > > > allows a compile for machine type default, and testpmd can still forward > > > > > packets at a good rate (roughly perf down about 10% vs native compile on > > > > > SNB). > > > > > The ACL is a tougher nut to crack, but anyone see any issues with that > > > > > two-line change to ixgbe_rxtx_vec.c? [Neil, since you started the patch > > > > > 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 performance > > > > 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='-msse4.2' to turn on the > > > 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 find > > > what would be the best general way to solve this problem across all > > > libraries. Also, I think that anyone who needs that extra 4% performance > > > probably wants the other 3% too, and so will compile up the code from > > > source using the "native" compilation target. :-) > > > > > > > > > Wait a moment, I'm not entirely sure what you did here. I understand that you > > replaced the _mm_popcnt_u64 call in the ixgbe pmd vector receive path with > > __builtin_popcnt, which is good, but ixgbe also uses the __mm_shuffle_epi8 > > intrinsic which is only available with sse4.2 from what I can see. did you > > 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 first pass > > and Konstantin gave some pretty convicing evidence that this was an unworkable > > solution: > > http://dpdk.org/ml/archives/dev/2014-July/004443.html > > > > I think that _mm_shuffle_epi8 (PSHUFB) is available starting from SSE3. > So I presume, there is no need for replacement. Ah, I see, its just because we're using the nmmintrinsic.h header. We need to replace the popcount instruction and change the include header to tmmintrins.h to avoid the #error from the failed sse4.2 check Thanks! Neil > Konstantin >