[dpdk-dev] [PATCH 0/2] dpdk: Allow for dynamic enablement of some isolated features

[Bruce Richardson]

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. :-)

/Bruce