DPDK patches and discussions
 help / color / mirror / Atom feed
From: Neil Horman <nhorman@tuxdriver.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>
Cc: "dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features
Date: Fri, 1 Aug 2014 10:27:54 -0400	[thread overview]
Message-ID: <20140801142754.GC31979@hmsreliant.think-freely.org> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772582134F31F@IRSMSX105.ger.corp.intel.com>

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
> 

  parent reply	other threads:[~2014-08-01 14:25 UTC|newest]

Thread overview: 45+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2014-07-29 20:24 Neil Horman
2014-07-29 20:24 ` [dpdk-dev] [PATCH 1/2] ixgbe: test sse4.2 support at runtime for vectorized receive operations Neil Horman
2014-07-29 20:24 ` [dpdk-dev] [PATCH 2/2] acl: Preform dynamic sse4.2 support check Neil Horman
2014-07-30 12:07 ` [dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features Ananyev, Konstantin
2014-07-30 13:01   ` Neil Horman
2014-07-30 13:44     ` Ananyev, Konstantin
2014-07-30 14:49 ` [dpdk-dev] [PATCH v2 " Neil Horman
2014-07-30 14:49   ` [dpdk-dev] [PATCH v2 1/2] ixgbe: test sse4.2 support at runtime for vectorized receive operations Neil Horman
2014-07-30 14:49   ` [dpdk-dev] [PATCH v2 2/2] acl: Preform dynamic sse4.2 support check Neil Horman
2014-07-30 15:36   ` [dpdk-dev] [PATCH v2 0/2] dpdk: Allow for dynamic enablement of some isolated features Ananyev, Konstantin
2014-07-30 19:03   ` Venky Venkatesan
2014-07-30 19:17     ` Neil Horman
2014-07-30 19:34     ` Neil Horman
2014-07-30 18:59 ` [dpdk-dev] [PATCH " Bruce Richardson
2014-07-30 19:28   ` Neil Horman
2014-07-30 21:09     ` Bruce Richardson
2014-07-31  9:30       ` Thomas Monjalon
2014-07-31 11:36       ` Ananyev, Konstantin
2014-07-31 13:13       ` Neil Horman
2014-07-31 13:26         ` Thomas Monjalon
2014-07-31 14:32           ` Neil Horman
2014-07-31 18:10             ` Neil Horman
2014-07-31 18:36               ` Bruce Richardson
2014-07-31 19:01                 ` Neil Horman
2014-07-31 20:19                   ` Bruce Richardson
2014-08-01 13:36                     ` Neil Horman
2014-08-01 13:56                       ` Ananyev, Konstantin
2014-08-01 14:26                         ` Venkatesan, Venky
2014-08-01 14:27                         ` Neil Horman [this message]
2014-07-31 19:58                 ` John W. Linville
2014-07-31 20:20                   ` Bruce Richardson
2014-07-31 20:32                     ` John W. Linville
2014-08-01  8:46                       ` Vincent JARDIN
2014-08-01 14:06                         ` Neil Horman
2014-08-01 14:57                           ` Vincent JARDIN
2014-08-01 15:19                             ` Neil Horman
2014-07-31 20:10                 ` Neil Horman
2014-07-31 20:25                   ` Bruce Richardson
2014-08-01 15:06                     ` Neil Horman
2014-08-01 19:22                       ` Bruce Richardson
2014-08-01 20:43                         ` Neil Horman
2014-08-01 21:08                           ` Bruce Richardson
2014-08-02 12:56                             ` Neil Horman
2014-07-31 21:53               ` Thomas Monjalon
2014-07-31 21:25             ` Thomas Monjalon

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=20140801142754.GC31979@hmsreliant.think-freely.org \
    --to=nhorman@tuxdriver.com \
    --cc=dev@dpdk.org \
    --cc=konstantin.ananyev@intel.com \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).