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 CFC1FA046B for ; Fri, 26 Jul 2019 00:06:18 +0200 (CEST) Received: from [92.243.14.124] (localhost [127.0.0.1]) by dpdk.org (Postfix) with ESMTP id 5FA961C38C; Fri, 26 Jul 2019 00:06:18 +0200 (CEST) Received: from mx0a-001b2d01.pphosted.com (mx0a-001b2d01.pphosted.com [148.163.156.1]) by dpdk.org (Postfix) with ESMTP id 7894D1C36F for ; Fri, 26 Jul 2019 00:06:17 +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 x6PLpu5T066503 for ; Thu, 25 Jul 2019 18:06:16 -0400 Received: from e32.co.us.ibm.com (e32.co.us.ibm.com [32.97.110.150]) by mx0a-001b2d01.pphosted.com with ESMTP id 2tymep8xrr-1 (version=TLSv1.2 cipher=AES256-GCM-SHA384 bits=256 verify=NOT) for ; Thu, 25 Jul 2019 18:06:16 -0400 Received: from localhost by e32.co.us.ibm.com with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted for from ; Thu, 25 Jul 2019 23:06:15 +0100 Received: from b03cxnp08027.gho.boulder.ibm.com (9.17.130.19) by e32.co.us.ibm.com (192.168.1.132) with IBM ESMTP SMTP Gateway: Authorized Use Only! Violators will be prosecuted; (version=TLSv1/SSLv3 cipher=AES256-GCM-SHA384 bits=256/256) Thu, 25 Jul 2019 23:06:11 +0100 Received: from b03ledav002.gho.boulder.ibm.com (b03ledav002.gho.boulder.ibm.com [9.17.130.233]) by b03cxnp08027.gho.boulder.ibm.com (8.14.9/8.14.9/NCO v10.0) with ESMTP id x6PM6ApR53215490 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-GCM-SHA384 bits=256 verify=OK); Thu, 25 Jul 2019 22:06:11 GMT Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id DF6F8136072; Thu, 25 Jul 2019 22:06:10 +0000 (GMT) Received: from b03ledav002.gho.boulder.ibm.com (unknown [127.0.0.1]) by IMSVA (Postfix) with ESMTP id E3ACA136076; Thu, 25 Jul 2019 22:06:09 +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 22:06:09 +0000 (GMT) From: David Christensen 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> <0087f68b-482e-65cd-d940-d6b9f405699f@linux.vnet.ibm.com> Date: Thu, 25 Jul 2019 15:06:09 -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: <0087f68b-482e-65cd-d940-d6b9f405699f@linux.vnet.ibm.com> Content-Type: text/plain; charset=utf-8; format=flowed Content-Language: en-US Content-Transfer-Encoding: 8bit X-TM-AS-GCONF: 00 x-cbid: 19072522-0004-0000-0000-0000152EAEF5 X-IBM-SpamModules-Scores: X-IBM-SpamModules-Versions: BY=3.00011493; HX=3.00000242; KW=3.00000007; PH=3.00000004; SC=3.00000287; SDB=6.01237417; UDB=6.00652275; IPR=6.01018791; MB=3.00027891; MTD=3.00000008; XFM=3.00000015; UTC=2019-07-25 22:06:15 X-IBM-AV-DETECTION: SAVI=unused REMOTE=unused XFE=unused x-cbparentid: 19072522-0005-0000-0000-00008C9C4466 Message-Id: <51a3bc00-105e-ce2b-520a-e2049b08aafb@linux.vnet.ibm.com> X-Proofpoint-Virus-Version: vendor=fsecure engine=2.50.10434:, , definitions=2019-07-25_08:, , 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=1015 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-1907250263 Subject: Re: [dpdk-dev] [PATCH v2] examples/l3fwd: fix unaligned memory access X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" >>>> 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. 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 and ends at 0x10146fc0 . (gdb) disass /m 0x10146fbc,0x10146fc0 Dump of assembler code from 0x10146fbc to 0x10146fc0: 290 key.xmm[1] = *(xmm_t *)data1; 0x0000000010146fbc : 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. Dave