From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from smtp.tuxdriver.com (charlotte.tuxdriver.com [70.61.120.58]) by dpdk.org (Postfix) with ESMTP id 173853F9 for ; Mon, 8 Dec 2014 12:38:36 +0100 (CET) Received: from hmsreliant.think-freely.org ([2001:470:8:a08:7aac:c0ff:fec2:933b] helo=localhost) by smtp.tuxdriver.com with esmtpsa (TLSv1:AES128-SHA:128) (Exim 4.63) (envelope-from ) id 1XxwdV-0007mK-31; Mon, 08 Dec 2014 06:38:03 -0500 Date: Mon, 8 Dec 2014 06:37:38 -0500 From: Neil Horman To: "Qiu, Michael" Message-ID: <20141208113738.GA18697@hmsreliant.think-freely.org> References: <533710CFB86FA344BFBF2D6802E60286C9CB12@SHSMSX101.ccr.corp.intel.com> <1417684369-21330-1-git-send-email-michael.qiu@intel.com> <54816D73.1020906@linux.vnet.ibm.com> <20141205142205.GB29245@hmsreliant.think-freely.org> <20141205150233.GA9704@bricha3-MOBL3> <20141205152406.GD29245@hmsreliant.think-freely.org> <533710CFB86FA344BFBF2D6802E60286C9D736@SHSMSX101.ccr.corp.intel.com> <20141208025952.GA24461@localhost.localdomain> <533710CFB86FA344BFBF2D6802E60286C9D78A@SHSMSX101.ccr.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <533710CFB86FA344BFBF2D6802E60286C9D78A@SHSMSX101.ccr.corp.intel.com> User-Agent: Mutt/1.5.23 (2014-03-12) X-Spam-Score: -2.9 (--) X-Spam-Status: No Cc: "dev@dpdk.org" , Michael Qiu Subject: Re: [dpdk-dev] [PATCH v3] 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 List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 08 Dec 2014 11:38:36 -0000 On Mon, Dec 08, 2014 at 03:37:19AM +0000, Qiu, Michael wrote: > On 12/8/2014 11:00 AM, Neil Horman wrote: > > On Mon, Dec 08, 2014 at 02:46:51AM +0000, Qiu, Michael wrote: > >> On 12/5/2014 11:25 PM, Neil Horman wrote: > >>> On Fri, Dec 05, 2014 at 03:02:33PM +0000, Bruce Richardson wrote: > >>>> On Fri, Dec 05, 2014 at 09:22:05AM -0500, Neil Horman wrote: > >>>>> On Fri, Dec 05, 2014 at 04:31:47PM +0800, Chao Zhu wrote: > >>>>>> On 2014/12/4 17:12, Michael Qiu wrote: > >>>>>>> lib/librte_eal/linuxapp/eal/eal_memory.c:324:4: error: comparison > >>>>>>> is always false due to limited range of data type [-Werror=type-limits] > >>>>>>> || (hugepage_sz == RTE_PGSIZE_16G)) { > >>>>>>> ^ > >>>>>>> cc1: all warnings being treated as errors > >>>>>>> > >>>>>>> lib/librte_eal/linuxapp/eal/eal.c(461): error #2259: non-pointer > >>>>>>> conversion from "long long" to "void *" may lose significant bits > >>>>>>> RTE_PTR_ALIGN_CEIL((uintptr_t)addr, RTE_PGSIZE_16M); > >>>>>>> > >>>>>>> This was introuduced by commit b77b5639: > >>>>>>> mem: add huge page sizes for IBM Power > >>>>>>> > >>>>>>> The root cause is that size_t and uintptr_t are 32-bit in i686 > >>>>>>> platform, but RTE_PGSIZE_16M and RTE_PGSIZE_16G are always 64-bit. > >>>>>>> > >>>>>>> Define RTE_PGSIZE_16G only in 64 bit platform to avoid > >>>>>>> this issue. > >>>>>>> > >>>>>>> Signed-off-by: Michael Qiu > >>>>>>> --- > >>>>>>> v3 ---> v2 > >>>>>>> Change RTE_PGSIZE_16G from ULL to UL > >>>>>>> to keep all entries consistent > >>>>>>> > >>>>>>> V2 ---> v1 > >>>>>>> Change two type entries to one, and > >>>>>>> leave RTE_PGSIZE_16G only valid for > >>>>>>> 64-bit platform > >>>>>>> > >>>>> NACK, this is the wrong way to fix this problem. Pagesizes are independent of > >>>>> architecutre. While a system can't have a hugepage size that exceeds its > >>>>> virtual address limit, theres no need to do per-architecture special casing of > >>>>> page sizes here. Instead of littering the code with ifdef RTE_ARCH_64 > >>>>> everytime you want to check a page size, just convert the size_t to a uint64_t > >>>>> and you can allow all of the enumerated page types on all architecutres, and > >>>>> save yourself some ifdeffing in the process. > >>>>> > >>>>> Neil > >>>> While I get your point, I find it distasteful to use a uint64_t for memory sizes, > >>>> when there is the size_t type defined for that particular purpose. > >>>> However, I suppose that reducing the number of #ifdefs compared to using the > >>>> "correct" datatypes for objects is a more practical optino - however distastful > >>>> I find it. > >>> size_t isn't defined for memory sizes in the sense that we're using them here. > >>> size_t is meant to address the need for a type to describe object sizes on a > >>> particular system, and it itself is sized accordingly (32 bits on a 32 bit arch, > >>> 64 on 64), so that you can safely store a size that the system in question might > >>> maximally allocate/return. In this situation we are describing memory sizes > >>> that might occur no a plurality of arches, and so size_t is inappropriate > >>> because it as a type is not sized for anything other than the arch it is being > >>> built for. The pragmatic benefits of ennumerating page sizes in a single > >>> canonical location far outweigh the desire to use a misappropriated type to > >>> describe them. > >> Neil, > >> > >> This patch fix two compile issues, and we need to do *dpdk testing > >> affairs*, if it is blocked in build stage, we can do *nothing* for testing. > >> > >> I've get you mind and your concern. But we should take care of changing > >> the type of "hugepage_sz", because lots of places using it. > >> > >> Would you mind if we consider this as hot fix, and we can post a better > >> fix later(like in dpdk 2.0)? Otherwise all test cycle are blocked. > >> > > Honestly, no. Because intels testing schedule shouldn't drive the inclusion of > > upstream fixes. Also, I'm not asking for a major redesign of anything, I'm > > asking for a proper fix for a very straightforward problem. I've attached the > > proper fix below. > > > > Regards > > Neil > > We test dpdk upstream now as 1,8 rc2 and rc3 released :) > Yes, I don't take issue with you testing dpdk, on the contrary, I appreciate it. What I take issue with is that you are asserting that the blockage of your testing is reason to ignore a proper fix an issue, rather than some substandard one. > I know that what you mean. but lots of please using "hugepage_sz" do you > confirm it will not affect other issue? > 5. There are 5 placees that use hugepage_sz, as the patch below indicates. Thats no alot. Also, I take issue with the assertion that this patch creates no additional problems. I'm sure it creates no additional problems that your patch wouldn't also create, arguably less. If we were really being pragmatic here, I would point out that this problem was caused by the fact that support for an entire new architecture was integrated during the -rc phase of a release, which seems extreemely risky to me, and as such, the most appropriate thing to do would be to back support for ppc out until after the 1.8 release when it could be properly tested. Instead we are slamming in hacked up fixes that throw arch specific ifdefs througout the code. > On other hand, we use 32 bit address in 32 bit platform for better > performance(some of places also use uintptr_t for address check and > alignment). > This has nothing to do with address bus size. > And it should not acceptable in 32 bit platform to use 64-bit platform > specification affairs(like RTE_PGSIZE_16G). > Ok, so add a single arch specific runtime check during hugepage mapping to exit on the 16G size use on 32 bit systems. Thats a fair and reasonable thing to do, though I think the hugepage remap is already ifdeffed for 54 bit arches only. Neil