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

["Venkatesan, Venky" <venky.venkatesan-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>]

On 8/1/2014 6:56 AM, Ananyev, Konstantin wrote:
>> From: dev [mailto:dev-bounces-VfR2kkLFssw@public.gmane.org] On Behalf Of Neil Horman
>> Sent: Friday, August 01, 2014 2:37 PM
>> To: Richardson, Bruce
>> Cc: dev-VfR2kkLFssw@public.gmane.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.