From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga09.intel.com (mga09.intel.com [134.134.136.24]) by dpdk.org (Postfix) with ESMTP id 9E331376C for ; Thu, 10 Aug 2017 16:09:08 +0200 (CEST) Received: from orsmga005.jf.intel.com ([10.7.209.41]) by orsmga102.jf.intel.com with ESMTP/TLS/DHE-RSA-AES256-GCM-SHA384; 10 Aug 2017 07:08:31 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.41,353,1498546800"; d="scan'208";a="135904214" Received: from irsmsx151.ger.corp.intel.com ([163.33.192.59]) by orsmga005.jf.intel.com with ESMTP; 10 Aug 2017 07:08:29 -0700 Received: from irsmsx103.ger.corp.intel.com ([169.254.3.185]) by IRSMSX151.ger.corp.intel.com ([169.254.4.181]) with mapi id 14.03.0319.002; Thu, 10 Aug 2017 15:04:02 +0100 From: "Richardson, Bruce" To: Neil Horman CC: "dev@dpdk.org" , Thomas Monjalon Thread-Topic: [dpdk-dev] [PATCH] atm: Remove machine definition Thread-Index: AQHTEU2bvJIWH/rCQEiHYrML/VNx2aJ9RE4AgAAhboCAADZPgA== Date: Thu, 10 Aug 2017 14:04:00 +0000 Message-ID: <59AF69C657FD0841A61C55336867B5B0721B6138@IRSMSX103.ger.corp.intel.com> References: <20170809202425.1356-1-nhorman@tuxdriver.com> <20170810083418.GA53940@bricha3-MOBL3.ger.corp.intel.com> <20170810113356.GA14414@hmswarspite.think-freely.org> In-Reply-To: <20170810113356.GA14414@hmswarspite.think-freely.org> Accept-Language: en-GB, en-US Content-Language: en-US X-MS-Has-Attach: X-MS-TNEF-Correlator: x-titus-metadata-40: eyJDYXRlZ29yeUxhYmVscyI6IiIsIk1ldGFkYXRhIjp7Im5zIjoiaHR0cDpcL1wvd3d3LnRpdHVzLmNvbVwvbnNcL0ludGVsMyIsImlkIjoiNzhlMTVjNmUtODQzYy00ZjgwLWI3ZTYtM2Q4NjMwODhjYTU5IiwicHJvcHMiOlt7Im4iOiJDVFBDbGFzc2lmaWNhdGlvbiIsInZhbHMiOlt7InZhbHVlIjoiQ1RQX0lDIn1dfV19LCJTdWJqZWN0TGFiZWxzIjpbXSwiVE1DVmVyc2lvbiI6IjE2LjUuOS4zIiwiVHJ1c3RlZExhYmVsSGFzaCI6IjQ2MDF3U1dwZjh2RHRaa1AxTjlaQmNDU3pxZXYyeitsTVdEOFFJaE1EQ289In0= x-ctpclassification: CTP_IC dlp-product: dlpe-windows dlp-version: 10.0.102.7 dlp-reaction: no-action x-originating-ip: [163.33.239.182] Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: quoted-printable MIME-Version: 1.0 Subject: Re: [dpdk-dev] [PATCH] atm: Remove machine definition 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: Thu, 10 Aug 2017 14:09:10 -0000 > -----Original Message----- > From: Neil Horman [mailto:nhorman@tuxdriver.com] > Sent: Thursday, August 10, 2017 12:34 PM > To: Richardson, Bruce > Cc: dev@dpdk.org; Thomas Monjalon > Subject: Re: [dpdk-dev] [PATCH] atm: Remove machine definition >=20 > On Thu, Aug 10, 2017 at 09:34:18AM +0100, Bruce Richardson wrote: > > On Wed, Aug 09, 2017 at 04:24:25PM -0400, Neil Horman wrote: > > > With the new updated requirement for SSE4.2, dpdk no longer supports > > > building on atom machines, as they only support up to SSE3. Remove > > > the machine definition. > > > > > > Signed-off-by: Neil Horman CC: Thomas > > > Monjalon --- mk/machine/atm/rte.vars.mk | 58 > > > ---------------------------------------------- 1 file changed, 58 > > > deletions(-) delete mode 100644 mk/machine/atm/rte.vars.mk > > > > > Yes, good catch, that should have been removed. However, I think the > > commit log should be updated to mention that it no longer supports > > "early" atom machines, or some similar phrase. Atom cores for the last > > number of years do support SSE4, see: > > https://en.wikipedia.org/wiki/Silvermont for example. > > >=20 > I don't really agree with that. If you want to make the claim that only > early atom machines aren't supported, the implication then is that later > atom machines are, and we should keep the machine type, and fix it to > build for those targeted machines (as it stands currently, the compiler > errors out on building atom because it only emits SSE3 instructions and > can't inline an SSE4 builtin). I'd be totally fine with fixing the atom > build (which I imageine amounts to passing -machine=3Datom -msse4 or > something simmilar to the build options. Once we do that however, we > likely need a runtime check for sse4 support as well, so we don't just ge= t > random SIGILL errors at run time. >=20 > Neil For the runtime checks, "rte_eal_init()" already calls "rte_cpu_is_supporte= d()" checks to ensure that all instruction sets that are built in are suppo= rted by the runtime platform. For fixing the atom build, I actually thought we were moving away from havi= ng special confirm files for the rte_machine type, and just passing the RTE= _MACHINE build-time value directly through to the compiler as -march - espe= cially since gcc and clang have started using the microarchitecture names d= irectly in the march flag rather than the older names like core-i7-avx. In = fact, "atom" is no longer listed in the manpage for gcc on my Fedora 26 sys= tem, only "bonnell", "silvermont" are present as atom architectures. If you see a need for fixing the atm build file, I have no objections, but = I think removing it is an acceptable solution as anyone who needs it can bu= ild for atom by manually editing the RTE_MACHINE type to "silvermont". [Tho= ugh, I do think the comments in config/common_base could do with being upda= ted, since it's not required any more to have a build directory for each ma= chine type.] Regards, /Bruce