I would suggest that instead of:

typedef struct
{
  u16 *resource_idx;
  struct rte_crypto_op **ops;
  u16 cipher_resource_idx[IPSEC_CRYPTO_N_ALG];
  u16 auth_resource_idx[IPSEC_INTEG_N_ALG];
    CLIB_CACHE_LINE_ALIGN_MARK (pad);
} crypto_worker_main_t __attribute__ ((aligned (CLIB_CACHE_LINE_BYTES)));

We simply do:

typedef struct
{
    CLIB_CACHE_LINE_ALIGN_MARK (cacheline0);
  u16 *resource_idx;
  struct rte_crypto_op **ops;
  u16 cipher_resource_idx[IPSEC_CRYPTO_N_ALG];
  u16 auth_resource_idx[IPSEC_INTEG_N_ALG];
} crypto_worker_main_t;

That will always automatically pad each element to the full cacheline. In 
conjunction with XXX_aligened macros it will always create data properly 
aligned.
Also, this is coding pattern we already do at many places and it helps to 
understand in GDB where the cacheline boundary is...

-- 
Damjan

> On 26 Apr 2018, at 18:08, Dave Barach <dbar...@cisco.com> wrote:
> 
> Yes, it’s arguably a compiler bug.
>
> But, it makes no sense to vec_validate_aligned(…), pool_get_aligned(…) etc. 
> objects whose size is not a multiple of the alignment request. Only the first 
> element will be aligned to the specified boundary. 
>
> __attribute__((aligned(xxx))) is not the same thing as ensuring that objects 
> are sized correctly.
>
> D.
>
> From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> <vpp-dev@lists.fd.io 
> <mailto:vpp-dev@lists.fd.io>> On Behalf Of Radu Nicolau
> Sent: Thursday, April 26, 2018 4:54 AM
> To: Florin Coras <fcoras.li...@gmail.com <mailto:fcoras.li...@gmail.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Florin,
>
> Thanks! The patch fixes the issue.
> Any idea why is it happening?
>
> Regards,
> Radu
>
>  <>From: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io> 
> [mailto:vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>] On Behalf Of Florin 
> Coras
> Sent: Tuesday, April 24, 2018 11:25 PM
> To: Nicolau, Radu <radu.nico...@intel.com <mailto:radu.nico...@intel.com>>
> Cc: vpp-dev@lists.fd.io <mailto:vpp-dev@lists.fd.io>
> Subject: Re: [vpp-dev] segfault due to movaps unaligned access
>
> Hi Radu, 
>
> Making the crypto_worker_main_t a full cache line in size (see patch [1]) 
> seems to solve the issue. Could you confirm?
>
> Florin
>
> [1] https://gerrit.fd.io/r/#/c/12086/ <https://gerrit.fd.io/r/#/c/12086/>
>
> 
> On Apr 24, 2018, at 9:23 AM, Radu Nicolau <radu.nico...@intel.com 
> <mailto:radu.nico...@intel.com>> wrote:
>
> Hello all,
>
> We’re seeing a weird issue, that is a segfault that looks to be caused by a 
> movaps instruction that is trying to access an address that is not 16 byte 
> aligned.
> The call originates from a vec_validate_init_empty_aligned that has the 
> argument aligned to 16 bytes.
> I have seen something like this in the past, we couldn’t find a root cause 
> and considered it a GCC bug (version 5 then), but now it pops up again on 
> version 7, so probably it isn’t.
> Any idea? A snapshot of the gdb screen below.
>
> gcc (Ubuntu 7.2.0-8ubuntu3.2) 7.2.0
> https://postimg.cc/image/9jy4p38at/ <https://postimg.cc/image/9jy4p38at/>
>
> thanks and I will appreciate any help,
> Radu
>
> 

Reply via email to