From mboxrd@z Thu Jan 1 00:00:00 1970
Return-Path: <michael.qiu@intel.com>
Received: from mga11.intel.com (mga11.intel.com [192.55.52.93])
by dpdk.org (Postfix) with ESMTP id 849767E75
for <dev@dpdk.org>; Thu, 4 Dec 2014 03:51:22 +0100 (CET)
Received: from fmsmga001.fm.intel.com ([10.253.24.23])
by fmsmga102.fm.intel.com with ESMTP; 03 Dec 2014 18:51:13 -0800
X-ExtLoop1: 1
X-IronPort-AV: E=Sophos;i="5.07,512,1413270000"; d="scan'208";a="632398748"
Received: from kmsmsx151.gar.corp.intel.com ([172.21.73.86])
by fmsmga001.fm.intel.com with ESMTP; 03 Dec 2014 18:51:11 -0800
Received: from shsmsx104.ccr.corp.intel.com (10.239.4.70) by
KMSMSX151.gar.corp.intel.com (172.21.73.86) with Microsoft SMTP Server (TLS)
id 14.3.195.1; Thu, 4 Dec 2014 10:49:26 +0800
Received: from shsmsx101.ccr.corp.intel.com ([169.254.1.110]) by
SHSMSX104.ccr.corp.intel.com ([169.254.5.182]) with mapi id 14.03.0195.001;
Thu, 4 Dec 2014 10:49:25 +0800
From: "Qiu, Michael" <michael.qiu@intel.com>
To: "thomas.monjalon@6wind.com" <thomas.monjalon@6wind.com>, Michael Qiu
<qdy220091330@gmail.com>, "Richardson, Bruce" <bruce.richardson@intel.com>
Thread-Topic: [PATCH v2] Fix two compile issues with i686 platform
Thread-Index: AQHQDtC2sNKGP0Pvek+HmA2FP8qVgQ==
Date: Thu, 4 Dec 2014 02:49:24 +0000
Message-ID: <533710CFB86FA344BFBF2D6802E60286C9C8C7@SHSMSX101.ccr.corp.intel.com>
References: <1417329845-7482-1-git-send-email-michael.qiu@intel.com>
<1417594223-2573-1-git-send-email-michael.qiu@intel.com>
<20141203154029.GA6340@bricha3-MOBL3>
Accept-Language: en-US
Content-Language: en-US
X-MS-Has-Attach:
X-MS-TNEF-Correlator:
x-originating-ip: [10.239.127.40]
Content-Type: text/plain; charset="us-ascii"
Content-Transfer-Encoding: quoted-printable
MIME-Version: 1.0
Cc: "dev@dpdk.org" <dev@dpdk.org>,
"chaozhu@linux.vnet.ibm.com" <chaozhu@linux.vnet.ibm.com>
Subject: Re: [dpdk-dev] [PATCH v2] Fix two compile issues with i686 platform
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: patches and discussions about DPDK <dev.dpdk.org>
List-Unsubscribe: <http://dpdk.org/ml/options/dev>,
<mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <http://dpdk.org/ml/listinfo/dev>,
<mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Thu, 04 Dec 2014 02:51:24 -0000
On 12/3/2014 11:40 PM, Richardson, Bruce wrote:=0A=
> On Wed, Dec 03, 2014 at 04:10:23PM +0800, Michael Qiu wrote:=0A=
>> lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison=0A=
>> is always false due to limited range of data type [-Werror=3Dtype-limits=
]=0A=
>> || (hugepage_sz =3D=3D RTE_PGSIZE_16G)) {=0A=
>> ^=0A=
>> cc1: all warnings being treated as errors=0A=
>>=0A=
>> lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer=0A=
>> conversion from "long long" to "void *" may lose significant bits=0A=
>> RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M);=0A=
>>=0A=
>> This was introuduced by commit b77b5639:=0A=
>> mem: add huge page sizes for IBM Power=0A=
>>=0A=
>> The root cause is that size_t and uintptr_t are 32-bit in i686=0A=
>> platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit.=0A=
>>=0A=
>> Define RTE_PGSIZE_16G only in 64 bit platform to avoid=0A=
>> this issue.=0A=
>>=0A=
>> Signed-off-by: Michael Qiu <michael.qiu@intel.com>=0A=
> Minor comment below.=0A=
>=0A=
> Acked-by: Bruce Richardson <bruce.richardson@intel.com>=0A=
>=0A=
>> ---=0A=
>> app/test/test_memzone.c | 18 ++++++++++++------=0A=
>> lib/librte_eal/common/eal_common_memzone.c | 2 ++=0A=
>> lib/librte_eal/common/include/rte_memory.h | 14 ++++++++------=0A=
>> lib/librte_eal/linuxapp/eal/eal_memory.c | 12 +++++-------=0A=
>> 4 files changed, 27 insertions(+), 19 deletions(-)=0A=
>>=0A=
> ... snip ...=0A=
>> --- a/lib/librte_eal/common/include/rte_memory.h=0A=
>> +++ b/lib/librte_eal/common/include/rte_memory.h=0A=
>> @@ -53,12 +53,14 @@ extern "C" {=0A=
>> #endif=0A=
>> =0A=
>> enum rte_page_sizes {=0A=
>> - RTE_PGSIZE_4K =3D 1ULL << 12,=0A=
>> - RTE_PGSIZE_2M =3D 1ULL << 21,=0A=
>> - RTE_PGSIZE_1G =3D 1ULL << 30,=0A=
>> - RTE_PGSIZE_64K =3D 1ULL << 16,=0A=
>> - RTE_PGSIZE_16M =3D 1ULL << 24,=0A=
>> - RTE_PGSIZE_16G =3D 1ULL << 34=0A=
>> + RTE_PGSIZE_4K =3D 1UL << 12,=0A=
>> + RTE_PGSIZE_2M =3D 1UL << 21,=0A=
>> + RTE_PGSIZE_1G =3D 1UL << 30,=0A=
>> + RTE_PGSIZE_64K =3D 1UL << 16,=0A=
>> + RTE_PGSIZE_16M =3D 1UL << 24,=0A=
>> +#ifdef RTE_ARCH_64=0A=
>> + RTE_PGSIZE_16G =3D 1ULL << 34=0A=
> you don't need the "LL" here as long type is 64-bits on 64-bit systems. C=
hanging=0A=
> it to 1UL << 34 will keep all entries consistent.=0A=
=0A=
Hi Thomas,=0A=
=0A=
Should I resend V3 patch to modify this or you can do it when you plan=0A=
to merge this patch?=0A=
=0A=
Thanks,=0A=
Michael=0A=
>=0A=
=0A=