From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from dpdk.org (dpdk.org [92.243.14.124]) by inbox.dpdk.org (Postfix) with ESMTP id 71F52A046B for ; Thu, 25 Jul 2019 20:56:31 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 06C111C38F; Thu, 25 Jul 2019 20:56:31 +0200 (CEST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 1DEFB1C384; Thu, 25 Jul 2019 20:56:25 +0200 (CEST) Received: from pps.filterd (m0098404.ppops.net [127.0.0.1]) by mx0a-001b2d01.pphosted.com (8.16.0.27/8.16.0.27) with SMTP id x6PIql0a018682; Thu, 25 Jul 2019 14:56:21 -0400 Received: from ppma04dal.us.ibm.com (7a.29.35a9.ip4.static.sl-reverse.com [169.53.41.122]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tyj0pg7nb-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2019 14:56:21 -0400 Received: from pps.filterd (ppma04dal.us.ibm.com [127.0.0.1]) by ppma04dal.us.ibm.com (8.16.0.27/8.16.0.27) with SMTP id x6PItC5E012039; Thu, 25 Jul 2019 18:56:20 GMT Received: from b03cxnp08025.gho.boulder.ibm.com (b03cxnp08025.gho.boulder.ibm.com [9.17.130.17]) by ppma04dal.us.ibm.com with ESMTP id 2tx61n8jg3-1 (version=TLSv1.2 cipher=ECDHE-RSA-AES256-GCM-SHA384 bits=256 verify=NOT); Thu, 25 Jul 2019 18:56:20 +0000 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08025.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6PIuJSf35062064 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jul 2019 18:56:19 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 292BF136051; Thu, 25 Jul 2019 18:56:19 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id 29B9713604F; Thu, 25 Jul 2019 18:56:18 +0000 (GMT) Received: from davids-mbp.usor.ibm.com (unknown [9.70.84.231]) by b03ledav002.gho.boulder.ibm.com (Postfix) with ESMTP; Thu, 25 Jul 2019 18:56:17 +0000 (GMT) To: Jerin Jacob Kollanukkaran , Bruce Richardson , hgovindh Cc: Remy Horton , Marko Kovacevic , Ori Kam , Pablo de Lara , Radu Nicolau , Akhil Goyal , Tomasz Kantecki , "dev@dpdk.org" , "maciej.czekaj@caviumnetworks.com" , "stable@dpdk.org" , Gavin Hu References: <20190724164354.18811-1-hariprasad.govindharajan@intel.com> <20190725162903.106262-1-hariprasad.govindharajan@intel.com> <20190725164600.GA1621@bricha3-MOBL.ger.corp.intel.com> From: David Christensen Message-ID: <0087f68b-482e-65cd-d940-d6b9f405699f@linux.vnet.ibm.com> Date: Thu, 25 Jul 2019 11:56:17 -0700 User-Agent: Mozilla/5.0 (Macintosh; Intel Mac OS X 10.14; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 MIME-Version: 1.0 In-Reply-To: Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 7bit X-TM-AS-GCONF: 00 X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-25_07:, , signatures=0 X-Proofpoint-Spam-Details: rule=outbound_notspam policy=outbound score=0 priorityscore=1501 malwarescore=0 suspectscore=0 phishscore=0 bulkscore=0 spamscore=0 clxscore=1011 lowpriorityscore=0 mlxscore=0 impostorscore=0 mlxlogscore=999 adultscore=0 classifier=spam adjust=0 reason=mlx scancount=1 engine=8.0.1-1906280000 definitions=main-1907250223 Subject: Re: [dpdk-stable] [dpdk-dev] [PATCH v2] examples/l3fwd: fix unaligned memory access X-BeenThere: stable@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches for DPDK stable branches List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: stable-bounces@dpdk.org Sender: "stable" >> 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 >>> --- >>> 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