From: Jerin Jacob Kollanukkaran <jerinj@marvell.com>
To: David Christensen <drc@linux.vnet.ibm.com>,
Bruce Richardson <bruce.richardson@intel.com>,
hgovindh <hariprasad.govindharajan@intel.com>
Cc: Remy Horton <remy.horton@intel.com>,
Marko Kovacevic <marko.kovacevic@intel.com>,
Ori Kam <orika@mellanox.com>,
Pablo de Lara <pablo.de.lara.guarch@intel.com>,
Radu Nicolau <radu.nicolau@intel.com>,
Akhil Goyal <akhil.goyal@nxp.com>,
Tomasz Kantecki <tomasz.kantecki@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>,
"maciej.czekaj@caviumnetworks.com"
<maciej.czekaj@caviumnetworks.com>,
"stable@dpdk.org" <stable@dpdk.org>, Gavin Hu <gavin.hu@arm.com>
Subject: Re: [dpdk-stable] [EXT] Re: [dpdk-dev] [PATCH v2] examples/l3fwd: fix unaligned memory access
Date: Fri, 26 Jul 2019 10:58:08 +0000 [thread overview]
Message-ID: <BYAPR18MB2424E4E1E045B515D217B8F4C8C00@BYAPR18MB2424.namprd18.prod.outlook.com> (raw)
In-Reply-To: <51a3bc00-105e-ce2b-520a-e2049b08aafb@linux.vnet.ibm.com>
> -----Original Message-----
> From: David Christensen <drc@linux.vnet.ibm.com>
> Sent: Friday, July 26, 2019 3:36 AM
> To: Jerin Jacob Kollanukkaran <jerinj@marvell.com>; Bruce Richardson
> <bruce.richardson@intel.com>; hgovindh
> <hariprasad.govindharajan@intel.com>
> Cc: Remy Horton <remy.horton@intel.com>; Marko Kovacevic
> <marko.kovacevic@intel.com>; Ori Kam <orika@mellanox.com>; Pablo de
> Lara <pablo.de.lara.guarch@intel.com>; Radu Nicolau
> <radu.nicolau@intel.com>; Akhil Goyal <akhil.goyal@nxp.com>; Tomasz
> Kantecki <tomasz.kantecki@intel.com>; dev@dpdk.org;
> maciej.czekaj@caviumnetworks.com; stable@dpdk.org; Gavin Hu
> <gavin.hu@arm.com>
> Subject: [EXT] Re: [dpdk-dev] [PATCH v2] examples/l3fwd: fix unaligned
> memory access
>
>
>>>> 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-p
> > ower8)
> > 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.
>
> Tested original bugzilla 279 on Power 9 system with RHEL 7.6 and gcc 4.8.5, no
> segmentation fault observed after 30 minutes (observed segmentation fault
> on Intel system immediately).
>
> Code dissassembly:
> (gdb) info line l3fwd_em.c:290
> Line 290 of "/home/davec/src/dpdk/examples/l3fwd/l3fwd_em.c" starts at
> address 0x10146fbc <em_main_loop+1660>
> and ends at 0x10146fc0 <em_main_loop+1664>.
> (gdb) disass /m 0x10146fbc,0x10146fc0
> Dump of assembler code from 0x10146fbc to 0x10146fc0:
> 290 key.xmm[1] = *(xmm_t *)data1;
> 0x0000000010146fbc <em_main_loop+1660>: li r7,20
>
> End of assembler dump.
>
> Since vector element ordering is different on Intel vs Power/ARM, suggest
> only applying vector operation to Intel code at this time otherwise additional
> steps may be required to modify MASK values to match the new vector
> operations.
On arm64, Generated assembly is following. Where LDUR and STR works
With unaligned memory(i.e no need for special handling).
I would suggest to have eal function to abstract The difference between x86 vs Power/ARM
to avoid ifdef clutter in all the applications.
key.xmm[1] = *(xmm_t *)data1;
0x00000000004ebed4 <+1188>: 60 40 c1 3c ldur q0, [x3, #20]
0x00000000004ebedc <+1196>: a0 73 80 3d str q0, [x29, #448]
0x00000000004ec064 <+1588>: 41 40 c1 3c ldur q1, [x2, #20]
0x00000000004ec06c <+1596>: a1 73 80 3d str q1, [x29, #448]
>
> Dave
next prev parent reply other threads:[~2019-07-26 10:58 UTC|newest]
Thread overview: 25+ messages / expand[flat|nested] mbox.gz Atom feed top
2019-07-24 16:43 [dpdk-stable] [PATCH] " hgovindh
2019-07-25 7:01 ` [dpdk-stable] [dpdk-dev] " Ruifeng Wang (Arm Technology China)
2019-07-25 9:05 ` [dpdk-stable] " Bruce Richardson
2019-07-25 13:27 ` [dpdk-stable] [dpdk-dev] " Aaron Conole
2019-07-25 14:01 ` Burakov, Anatoly
2019-07-25 14:08 ` Govindharajan, Hariprasad
2019-07-25 14:01 ` Lipiec, Herakliusz
2019-07-25 14:23 ` Burakov, Anatoly
2019-07-25 16:29 ` [dpdk-stable] [PATCH v2] " hgovindh
2019-07-25 16:46 ` Bruce Richardson
2019-07-25 17:14 ` [dpdk-stable] [dpdk-dev] " Jerin Jacob Kollanukkaran
2019-07-25 18:56 ` David Christensen
2019-07-25 22:06 ` David Christensen
2019-07-26 10:58 ` Jerin Jacob Kollanukkaran [this message]
2019-07-26 13:27 ` [dpdk-stable] [PATCH v3] " hgovindh
2019-07-26 13:37 ` [dpdk-stable] [dpdk-dev] " Burakov, Anatoly
2019-07-26 13:58 ` [dpdk-stable] [PATCH v4] " hgovindh
2019-07-30 8:50 ` Thomas Monjalon
2019-07-30 9:47 ` Bruce Richardson
2019-07-30 11:03 ` [dpdk-stable] [dpdk-dev] " Jerin Jacob Kollanukkaran
2019-07-30 17:45 ` David Christensen
2019-07-31 1:27 ` Ruifeng Wang (Arm Technology China)
2019-07-30 13:26 ` [dpdk-stable] [PATCH v5] Examples/l3fwd: " Hariprasad Govindharajan
2019-07-30 15:48 ` [dpdk-stable] [dpdk-dev] " Lipiec, Herakliusz
2019-07-30 19:58 ` Thomas Monjalon
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=BYAPR18MB2424E4E1E045B515D217B8F4C8C00@BYAPR18MB2424.namprd18.prod.outlook.com \
--to=jerinj@marvell.com \
--cc=akhil.goyal@nxp.com \
--cc=bruce.richardson@intel.com \
--cc=dev@dpdk.org \
--cc=drc@linux.vnet.ibm.com \
--cc=gavin.hu@arm.com \
--cc=hariprasad.govindharajan@intel.com \
--cc=maciej.czekaj@caviumnetworks.com \
--cc=marko.kovacevic@intel.com \
--cc=orika@mellanox.com \
--cc=pablo.de.lara.guarch@intel.com \
--cc=radu.nicolau@intel.com \
--cc=remy.horton@intel.com \
--cc=stable@dpdk.org \
--cc=tomasz.kantecki@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).