Re: [dpdk-stable] [dpdk-dev] [PATCH v2] examples/l3fwd: fix unaligned memory access

[David Christensen <drc@linux.vnet.ibm.com>]

>> On Thu, Jul 25, 2019 at 05:29:03PM +0100, hgovindh wrote:
>>> Fix unaligned memory access when reading IPv6 header which leads to
>>> segmentation fault by changing aligned memory read to unaligned memory
>>> read.
>>>
>>> Bugzilla ID: 279
>>> Fixes: 64d3955de1de ("examples/l3fwd: fix ARM build")
>>> Cc: maciej.czekaj@caviumnetworks.com
>>> Cc: stable@dpdk.org
>>> Signed-off-by: hgovindh <hariprasad.govindharajan@intel.com>
>>> ---
>>> V2: Added functions which will do unaligned load based on the
>>> underlying architecture
>>> ---
>>> ---
>>>   examples/l3fwd/l3fwd_em.c | 26 ++++++++++++++++++++++++--
>>>   1 file changed, 24 insertions(+), 2 deletions(-)
>>>
>>> diff --git a/examples/l3fwd/l3fwd_em.c b/examples/l3fwd/l3fwd_em.c
>>> index fa8f82be6..f2641586b 100644
>>> --- a/examples/l3fwd/l3fwd_em.c
>>> +++ b/examples/l3fwd/l3fwd_em.c
>>> @@ -244,6 +244,29 @@ em_mask_key(void *key, xmm_t mask)  #error No
>>> vector engine (SSE, NEON, ALTIVEC) available, check your toolchain
>>> #endif
>>>
>>> +#if defined(RTE_MACHINE_CPUFLAG_SSE2) static inline xmm_t
>>> +em_load_key(void *key) {
>>> +	return _mm_loadu_si128((__m128i *)(key)); } #elif
>>> +defined(RTE_MACHINE_CPUFLAG_NEON)
>>> +static inline xmm_t
>>> +em_load_key(void *key)
>>> +{
>>> +	return vld1q_s32((int32_t *)key);
>>> +}
>>> +#elif defined(RTE_MACHINE_CPUFLAG_ALTIVEC)
>>> +static inline xmm_t
>>> +em_load_key(void *key)
>>> +{
>>> +	return vec_ld(0, (xmm_t *)(key));
>>> +}
> 
> Added power pc maintainer

> Not sure all architecture need SIMD instructions for access to unaligned memory location.
> 
> @hgovindh,
> Could you provide exact setup details for reproducing this issue, I can test it on arm64.
> Like l3fwd command, Traffic generator traffic pattern

The vec_ld() function requires 16 byte alignment.  (My understanding is 
that GCC code will mask the lower four bits of the address to enforce 
the requirement: 
https://gcc.gcc.gnu.narkive.com/cJndcMpR/vec-ld-versus-vec-vsx-ld-on-power8) 
  Power 8 and later processors support the vec_vsx_ld() function which 
does not have the same memory alignment requirements.

I'll need to try and reproduce the original bug to see what code is 
actually being generated.  Outside of vector instructions I wouldn't 
expect to see errors with unaligned data references.

Dave