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 Neil
