From: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
To: "Qiu, Michael" <michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
Cc: "dev-VfR2kkLFssw@public.gmane.org"
<dev-VfR2kkLFssw@public.gmane.org>,
Michael Qiu
<qdy220091330-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org>
Subject: Re: [PATCH v3] Fix two compile issues with i686 platform
Date: Sun, 7 Dec 2014 21:59:52 -0500 [thread overview]
Message-ID: <20141208025952.GA24461@localhost.localdomain> (raw)
In-Reply-To: <533710CFB86FA344BFBF2D6802E60286C9D736-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
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 <michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
> >>>>> ---
> >>>>> 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
diff --git a/lib/librte_eal/common/eal_common_memory.c b/lib/librte_eal/common/eal_common_memory.c
index 412b432..31a391c 100644
--- a/lib/librte_eal/common/eal_common_memory.c
+++ b/lib/librte_eal/common/eal_common_memory.c
@@ -96,7 +96,7 @@ rte_dump_physmem_layout(FILE *f)
fprintf(f, "Segment %u: phys:0x%"PRIx64", len:%zu, "
"virt:%p, socket_id:%"PRId32", "
- "hugepage_sz:%zu, nchannel:%"PRIx32", "
+ "hugepage_sz:%llu, nchannel:%"PRIx32", "
"nrank:%"PRIx32"\n", i,
mcfg->memseg[i].phys_addr,
mcfg->memseg[i].len,
diff --git a/lib/librte_eal/common/eal_internal_cfg.h b/lib/librte_eal/common/eal_internal_cfg.h
index aac6abf..e2ecb0d 100644
--- a/lib/librte_eal/common/eal_internal_cfg.h
+++ b/lib/librte_eal/common/eal_internal_cfg.h
@@ -49,7 +49,7 @@
* mount points of hugepages
*/
struct hugepage_info {
- size_t hugepage_sz; /**< size of a huge page */
+ uint64_t hugepage_sz; /**< size of a huge page */
const char *hugedir; /**< dir where hugetlbfs is mounted */
uint32_t num_pages[RTE_MAX_NUMA_NODES];
/**< number of hugepages of that size on each socket */
diff --git a/lib/librte_eal/common/include/rte_memory.h b/lib/librte_eal/common/include/rte_memory.h
index 1990833..7f8103f 100644
--- a/lib/librte_eal/common/include/rte_memory.h
+++ b/lib/librte_eal/common/include/rte_memory.h
@@ -92,7 +92,7 @@ struct rte_memseg {
phys_addr_t ioremap_addr; /**< Real physical address inside the VM */
#endif
size_t len; /**< Length of the segment. */
- size_t hugepage_sz; /**< The pagesize of underlying memory */
+ uint64_t hugepage_sz; /**< The pagesize of underlying memory */
int32_t socket_id; /**< NUMA socket ID. */
uint32_t nchannel; /**< Number of channels. */
uint32_t nrank; /**< Number of ranks. */
diff --git a/lib/librte_eal/common/include/rte_memzone.h b/lib/librte_eal/common/include/rte_memzone.h
index 7d47bff..3006e81 100644
--- a/lib/librte_eal/common/include/rte_memzone.h
+++ b/lib/librte_eal/common/include/rte_memzone.h
@@ -83,7 +83,7 @@ struct rte_memzone {
#endif
size_t len; /**< Length of the memzone. */
- size_t hugepage_sz; /**< The page size of underlying memory */
+ uint64_t hugepage_sz; /**< The page size of underlying memory */
int32_t socket_id; /**< NUMA socket ID. */
diff --git a/lib/librte_eal/linuxapp/eal/eal_memory.c b/lib/librte_eal/linuxapp/eal/eal_memory.c
index e6cb919..bae2507 100644
--- a/lib/librte_eal/linuxapp/eal/eal_memory.c
+++ b/lib/librte_eal/linuxapp/eal/eal_memory.c
@@ -300,7 +300,7 @@ map_all_hugepages(struct hugepage_file *hugepg_tbl,
#endif
for (i = 0; i < hpi->num_pages[0]; i++) {
- size_t hugepage_sz = hpi->hugepage_sz;
+ uint64_t hugepage_sz = hpi->hugepage_sz;
if (orig) {
hugepg_tbl[i].file_id = i;
next prev parent reply other threads:[~2014-12-08 2:59 UTC|newest]
Thread overview: 29+ messages / expand[flat|nested] mbox.gz Atom feed top
[not found] <1417329845-7482-1-git-send-email-michael.qiu@intel.com>
[not found] ` <1417594223-2573-1-git-send-email-michael.qiu@intel.com>
2014-12-03 11:32 ` [PATCH v2] Fix two compile issues with i686 platform Qiu, Michael
[not found] ` <1417594223-2573-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-03 15:40 ` Bruce Richardson
2014-12-04 2:49 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9C8C7-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-04 9:03 ` Thomas Monjalon
2014-12-04 10:21 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9CB12-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-04 9:12 ` [PATCH v3] " Michael Qiu
2014-12-05 6:56 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9D074-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-05 7:04 ` Chao Zhu
[not found] ` <1417684369-21330-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-05 8:31 ` Chao Zhu
[not found] ` <54816D73.1020906-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-12-05 14:22 ` Neil Horman
[not found] ` <20141205142205.GB29245-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-05 15:02 ` Bruce Richardson
2014-12-05 15:24 ` Neil Horman
2014-12-08 2:46 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9D736-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-08 2:59 ` Neil Horman [this message]
2014-12-08 3:37 ` Qiu, Michael
2014-12-08 4:57 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9D78A-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-08 11:37 ` Neil Horman
[not found] ` <20141208113738.GA18697-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-08 11:50 ` Thomas Monjalon
2014-12-08 14:59 ` Qiu, Michael
2014-12-10 10:46 ` [PATCH 0/2 v4] " Michael Qiu
[not found] ` <1418208402-7597-1-git-send-email-michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org>
2014-12-10 10:46 ` [PATCH 1/2 v4] Fix compile issue with hugepage_sz in 32-bit system Michael Qiu
2014-12-10 10:46 ` [PATCH 2/2] Fix compile issue of eal with icc compile Michael Qiu
2014-12-11 0:56 ` [PATCH 0/2 v4] Fix two compile issues with i686 platform Thomas Monjalon
2014-12-11 13:25 ` Neil Horman
2014-12-11 15:28 ` Qiu, Michael
[not found] ` <533710CFB86FA344BFBF2D6802E60286C9EEB1-0J0gbvR4kThpB2pF5aRoyrfspsVTdybXVpNB7YpNyf8@public.gmane.org>
2014-12-11 21:21 ` Thomas Monjalon
2014-12-12 11:38 ` Neil Horman
[not found] ` <20141212113824.GA14102-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-12 15:09 ` Thomas Monjalon
2014-12-12 15:29 ` Neil Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20141208025952.GA24461@localhost.localdomain \
--to=nhorman-2xusbdqka4r54taoqtywwq@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=michael.qiu-ral2JQCrhuEAvxtiuMwx3w@public.gmane.org \
--cc=qdy220091330-Re5JQEeQqe8AvxtiuMwx3w@public.gmane.org \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.