From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga01.intel.com (mga01.intel.com [192.55.52.88]) by dpdk.org (Postfix) with ESMTP id 3AC8268AE for ; Fri, 1 Aug 2014 16:24:39 +0200 (CEST) Received: from fmsmga002.fm.intel.com ([10.253.24.26]) by fmsmga101.fm.intel.com with ESMTP; 01 Aug 2014 07:26:43 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.01,780,1400050800"; d="scan'208";a="578760514" Received: from asomayaj-mobl.amr.corp.intel.com (HELO [10.254.69.42]) ([10.254.69.42]) by fmsmga002.fm.intel.com with ESMTP; 01 Aug 2014 07:26:09 -0700 Message-ID: <53DBA381.7080400@intel.com> Date: Fri, 01 Aug 2014 07:26:09 -0700 From: "Venkatesan, Venky" User-Agent: Mozilla/5.0 (Windows NT 6.2; WOW64; rv:24.0) Gecko/20100101 Thunderbird/24.6.0 MIME-Version: 1.0 To: dev@dpdk.org 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> <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com> In-Reply-To: <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit 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:24:40 -0000 On 8/1/2014 6:56 AM, 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. :-) So if I read this right, the fast path scalar to the new "generic" vector implementation is 35%? That's is a bit higher than anticipated, but great!! One caution - we should probably get a performance read on Atom cores before we remove the scalar fast path completely. >> >> 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. > Konstantin The change is really to keep the __mm_shuffle_epi8 and replace the _mm_popcnt_u64 with the builtin variant. That should allow compilation all the way up from SSSE3.