From: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
To: Neil Horman <nhorman-2XuSBdqkA4R54TAoqtyWWQ@public.gmane.org>
Cc: dev-VfR2kkLFssw@public.gmane.org,
Chao Zhu
<chaozhu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
Subject: Re: [PATCH] Fix KNI compiling issue on IBM Power
Date: Thu, 04 Dec 2014 14:47:03 +0100 [thread overview]
Message-ID: <1795169.cqFrYtuj77@xps13> (raw)
In-Reply-To: <20141204132939.GB16249-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-04 08:29, Neil Horman:
> On Thu, Dec 04, 2014 at 12:59:31PM +0100, Thomas Monjalon wrote:
> > > Because of different cache line size, the alignment of struct
> > > rte_kni_mbuf in rte_kni_common.h doesn't work on IBM Power. This patch
> > > changed from 64 to RTE_CACHE_LINE_SIZE micro to do the alignment.
> > >
> > > Signed-off-by: Chao Zhu <chaozhu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
> >
> > Acked-by: Thomas Monjalon <thomas.monjalon-pdR9zngts4EAvxtiuMwx3w@public.gmane.org>
> >
> > Applied
> >
> Woah! Slow down here, I'm not sure if this makes sense to fix his way. The
> exact same ifndef/define/endif construct is used for this macro in rte_memory.h.
> Currently their defined to the same vaule, but if that ever changes, this macro
> will return different values based on the order in which header files are
> included. That doesn't seem appropriate at all.
I agree (was my comment) but the patch was applied as a hot fix.
A better fix has to be found for DPDK 2.0.
Do you agree this fix is enough for DPDK 1.8 release?
> > I wonder if we could try to guess the cache line size instead of
> > configuring it in many places.
> > Maybe we could use something like sysconf(_SC_LEVEL1_DCACHE_LINESIZE)?
> >
> This is a good idea, but I think its a bit broken for a few reasons:
>
> 1) _SC_LEVEL1_DCACHE_LINESIZE I don't think is POSIX mandated, so there is every
> possibility that the above won't work on BSD
>
> 2) While getting the cache line size dynamically is a great idea, dpdk has
> several locations that size structures based on processor cache line size, which
> implicitly requires a static cache line definition.
It can be guessed dynamically in the first build step (kind of configure).
> It seems the right thing to do, in my mind is to define RTE_CACHE_LINE_SIZE per
> arch (perhaps in common/include/arch/<arch>/rte_<something>.h), then just let
> the build break if a given arch doesn't define it (i.e. make definig that value
> an arch reqirement).
It's the other option. For IBM Power, it's currently overwritten in the Makefile:
http://dpdk.org/browse/dpdk/tree/mk/arch/ppc_64/rte.vars.mk
Thanks for helping to find a better solution.
--
Thomas
next prev parent reply other threads:[~2014-12-04 13:47 UTC|newest]
Thread overview: 12+ messages / expand[flat|nested] mbox.gz Atom feed top
2014-12-04 10:14 [PATCH] Fix KNI compiling on IBM Power Chao Zhu
[not found] ` <1417688048-23076-1-git-send-email-chaozhu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-12-04 10:14 ` [PATCH] Fix KNI compiling issue " Chao Zhu
[not found] ` <1417688048-23076-2-git-send-email-chaozhu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org>
2014-12-04 11:59 ` Thomas Monjalon
2014-12-04 13:29 ` Neil Horman
[not found] ` <20141204132939.GB16249-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-04 13:47 ` Thomas Monjalon [this message]
2014-12-04 15:32 ` Neil Horman
[not found] ` <20141204153256.GE16249-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-04 15:59 ` Thomas Monjalon
2014-12-04 20:05 ` Neil Horman
[not found] ` <20141204200538.GB18930-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-05 9:11 ` Chao Zhu
2014-12-05 13:10 ` Thomas Monjalon
2014-12-05 14:42 ` Neil Horman
[not found] ` <20141205144200.GC29245-B26myB8xz7F8NnZeBjwnZQMhkBWG/bsMQH7oEaQurus@public.gmane.org>
2014-12-05 14:52 ` Thomas Monjalon
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=1795169.cqFrYtuj77@xps13 \
--to=thomas.monjalon-pdr9zngts4eavxtiumwx3w@public.gmane.org \
--cc=chaozhu-23VcF4HTsmIX0ybBhKVfKdBPR1lH4CV8@public.gmane.org \
--cc=dev-VfR2kkLFssw@public.gmane.org \
--cc=nhorman-2XuSBdqkA4R54TAoqtyWWQ@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.