From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id C120C2C72 for ; Fri, 1 Sep 2017 12:55:01 +0200 (CEST) Received: from fmsmga006.fm.intel.com ([10.253.24.20]) by orsmga103.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 01 Sep 2017 03:55:00 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,457,1498546800"; d="scan'208,217";a="147070479" Received: from irsmsx105.ger.corp.intel.com ([163.33.3.28]) by fmsmga006.fm.intel.com with ESMTP; 01 Sep 2017 03:54:58 -0700 Received: from irsmsx107.ger.corp.intel.com ([169.254.10.65]) by irsmsx105.ger.corp.intel.com ([169.254.7.75]) with mapi id 14.03.0319.002; Fri, 1 Sep 2017 11:54:58 +0100 From: "O Mahony, Billy" To: "dev@dpdk.org" CC: "stephen@networkplumber.org" , "Lu, Wenzhuo" , "Wang, Zhihong" , "Zhang, Qi Z" , "Richardson, Bruce" Thread-Topic: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over Thread-Index: AdMjEHcRIwiTdXbRTda0ZvQPpJR8Hg== Date: Fri, 1 Sep 2017 10:54:57 +0000 Message-ID: <03135AEA779D444E90975C2703F148DC58C1741C@IRSMSX107.ger.corp.intel.com> Accept-Language: en-IE, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiOWNmMDRmMzYtOTMwNy00N2JlLWIxMTgtNDZhN2I4OTlhMzE2IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IlN0QnpzRlwvRGN4eGZRZ3JGZVFHcDdZbEpocWlcL1drYk9iSmZXXC9icU1yaDA9In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 11.0.0.116 dlp-reaction: no-action x-originating-ip: [163.33.239.181] MIME-Version: 1.0 X-Mailman-Approved-At: Fri, 01 Sep 2017 17:10:44 +0200 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable X-Content-Filtered-By: Mailman/MimeDel 2.1.15 Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over 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: , X-List-Received-Date: Fri, 01 Sep 2017 10:55:02 -0000 Hi, FYI, Just to note a bug I found when using FMV with -O flag: https://gcc.gnu.org/bugzilla/show_bug.cgi?id=3D81128 I see the fix is on the trunk now but not sure if it's been back ported to = other point releases so dev's might need to be careful about which gcc vers= ions they use and be aware that compiler support in the wild could be an is= sue. The only version marked 'Known to work' on the bug ticket is 8.0. Apologies if this does not get added to the correct thread - I don't subsc= ribe to this dev list so I didn't have the original email to reply to. Regards, Billy. > -------- Forwarded Message -------- > Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over > memcpy > Date: Thu, 31 Aug 2017 05:24:25 +0000 > From: Li, Xiaoyun > > To: Stephen Hemminger >, Lu, Wenzhuo > > > CC: Wang, Zhihong >= , dev@dpdk.org > >, Zhang, Qi Z >, Richardson, Bruce > > > > About gcc FMV, I tried it several days ago. > But the way that the same function name with different attributions > only works in C++. > And then I tried GCC6 since it is said that GCC6 would support both C > and > C++. > But it doesn't work. > > However, if using different function names with attributions, it works. > And the function with attribution AVX512 means this function would be > compiled via AVX512. > So I add attribution for each function and delete -mavx512 in makefile. > But I haven't sent the patch. > Because there are some compilation issues. > > Before, only if both compiler and cpu support AVX512 and users want, > the > AVX512 codes would be compiled since the macro > RTE_MACHINE_CPUFLAG_AVX512. > Now, we hope to compiler them all and choose one at runtime based on cpu. > But only above gcc4.9 and newest clang would support AVX512. > So I am thinking adding a macro switch in mk which will determine > whether the compiler supports AVX512 and whether users hope to use 512. > (don't need cpu support because it will be determined at run-time) > Only if the compiler supports AVX512 and users hope to use 512, the > 512 codes would be compiled. > > > Best Regards, > Xiaoyun Li > > > > From: Stephen Hemminger [mailto:stephen@networkplumber.org] > Sent: Thursday, August 31, 2017 13:06 > To: Lu, Wenzhuo > > Cc: Wang, Zhihong >= ; dev@dpdk.org; Zhang, Qi Z > >; Li, Xiaoyun >; > Richardson, Bruce > > Subject: RE: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over > memcpy > > I was referring to gcc multiversion > > https://gcc.gnu.org/wiki/FunctionMultiVersioning > > > On Aug 30, 2017 6:24 PM, "Lu, Wenzhuo" > >> wrote: > Hi Stephen, > > > > -----Original Message----- > > From: Stephen Hemminger > > > [mailto:stephen@networkplumber.org rg>] > > Sent: Thursday, August 31, 2017 2:01 AM > > To: Li, Xiaoyun >> > > Cc: Richardson, Bruce > > >>; > > dev@dpdk.org>; Lu, Wenzhuo > > >>; Wang, Zhihong > > >>; Zhang, Qi Z > > >> > > Subject: Re: [dpdk-dev] [PATCH 1/3] eal/x86: run-time dispatch over > > memcpy > > > > On Fri, 25 Aug 2017 10:06:11 +0800 > > Xiaoyun Li >> wrote: > > > > > This patch dynamically selects functions of memcpy at run-time > > > based on CPU flags that current machine supports. This patch uses > > > function pointers which are bind to the relative functions at constrc= tor time. > > > To make AVX512 instructions pass compilation, enable the switch in > > > makefile. > > > > > > Signed-off-by: Xiaoyun Li > > > >> > > > > Recent versions of GCC also have better ways to handle this. > I think the assumption of using the instructions is that we believe we > can do better than the compiler. If it turns out not, maybe we need to > change the instructions back to C. But it's another stor