From: "Verkamp, Daniel" <daniel.verkamp@intel.com>
To: "Ananyev, Konstantin" <konstantin.ananyev@intel.com>,
"dev@dpdk.org" <dev@dpdk.org>
Subject: Re: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
Date: Fri, 2 Jun 2017 22:24:20 +0000 [thread overview]
Message-ID: <A5F28D4A728A7E41839CDC5C3B5A01E87EA1B586@FMSMSX103.amr.corp.intel.com> (raw)
In-Reply-To: <2601191342CEEE43887BDE71AB9772583FB05190@IRSMSX109.ger.corp.intel.com>
The PROD/CONS_ALIGN values on x86-64 are set to 2 cache lines, so members of struct rte_ring are 128 byte aligned, and therefore the whole struct needs 128-byte alignment according to the ABI so that the 128-byte alignment of the fields can be guaranteed.
If the allocation is only 64-byte aligned, the beginning of the prod and cons fields may not actually be 128-byte aligned (but we've told the compiler that they are using the __rte_aligned macro). Accessing these fields when they are misaligned will work in practice on x86 (as long as the compiler doesn't use e.g. aligned SSE instructions), but it is undefined behavior according to the C standard, and UBSan (-fsanitize=undefined) checks for this.
Thanks,
-- Daniel Verkamp
> -----Original Message-----
> From: Ananyev, Konstantin
> Sent: Friday, June 2, 2017 1:52 PM
> To: Verkamp, Daniel <daniel.verkamp@intel.com>; dev@dpdk.org
> Cc: Verkamp, Daniel <daniel.verkamp@intel.com>
> Subject: RE: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
>
>
>
> > -----Original Message-----
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Daniel Verkamp
> > Sent: Friday, June 2, 2017 9:12 PM
> > To: dev@dpdk.org
> > Cc: Verkamp, Daniel <daniel.verkamp@intel.com>
> > Subject: [dpdk-dev] [PATCH v2] ring: use aligned memzone allocation
> >
> > rte_memzone_reserve() provides cache line alignment, but
> > struct rte_ring may require more than cache line alignment: on x86-64,
> > it needs 128-byte alignment due to PROD_ALIGN and CONS_ALIGN, which are
> > 128 bytes, but cache line size is 64 bytes.
>
> Hmm but what for?
> I understand we need our rte_ring cche-line aligned,
> but why do you want it 2 cache-line aligned?
> Konstantin
>
> >
> > Fixes runtime warnings with UBSan enabled.
> >
> > Fixes: d9f0d3a1ffd4 ("ring: remove split cacheline build setting")
> >
> > Signed-off-by: Daniel Verkamp <daniel.verkamp@intel.com>
> > ---
> >
> > v2: fixed checkpatch warnings
> >
> > lib/librte_ring/rte_ring.c | 3 ++-
> > 1 file changed, 2 insertions(+), 1 deletion(-)
> >
> > diff --git a/lib/librte_ring/rte_ring.c b/lib/librte_ring/rte_ring.c
> > index 5f98c33..6f58faf 100644
> > --- a/lib/librte_ring/rte_ring.c
> > +++ b/lib/librte_ring/rte_ring.c
> > @@ -189,7 +189,8 @@ rte_ring_create(const char *name, unsigned count, int
> socket_id,
> > /* reserve a memory zone for this ring. If we can't get rte_config or
> > * we are secondary process, the memzone_reserve function will set
> > * rte_errno for us appropriately - hence no check in this this function */
> > - mz = rte_memzone_reserve(mz_name, ring_size, socket_id, mz_flags);
> > + mz = rte_memzone_reserve_aligned(mz_name, ring_size, socket_id,
> > + mz_flags, __alignof__(*r));
> > if (mz != NULL) {
> > r = mz->addr;
> > /* no need to check return value here, we already checked the
> > --
> > 2.9.4
next prev parent reply other threads:[~2017-06-02 22:24 UTC|newest]
Thread overview: 42+ messages / expand[flat|nested] mbox.gz Atom feed top
2017-06-02 20:03 [dpdk-dev] [PATCH] " Daniel Verkamp
2017-06-02 20:12 ` [dpdk-dev] [PATCH v2] " Daniel Verkamp
2017-06-02 20:51 ` Ananyev, Konstantin
2017-06-02 22:24 ` Verkamp, Daniel [this message]
2017-06-03 10:00 ` Ananyev, Konstantin
2017-06-05 16:21 ` Verkamp, Daniel
2017-06-06 9:59 ` Ananyev, Konstantin
2017-06-06 12:42 ` Bruce Richardson
2017-06-06 13:19 ` Ananyev, Konstantin
2017-06-06 14:56 ` Bruce Richardson
2017-06-08 12:45 ` Olivier Matz
2017-06-08 13:20 ` Bruce Richardson
2017-06-08 14:05 ` Olivier Matz
2017-06-08 14:11 ` Bruce Richardson
2017-06-08 14:50 ` Ananyev, Konstantin
2017-06-08 15:24 ` Bruce Richardson
2017-06-08 15:35 ` Ananyev, Konstantin
2017-06-08 16:03 ` Bruce Richardson
2017-06-08 16:12 ` Ananyev, Konstantin
2017-06-08 16:20 ` Richardson, Bruce
2017-06-08 16:42 ` Ananyev, Konstantin
2017-06-09 9:02 ` Bruce Richardson
2017-06-12 9:02 ` Olivier Matz
2017-06-12 9:56 ` Bruce Richardson
2017-06-30 11:35 ` Olivier Matz
2017-06-09 12:47 ` Yerden Zhumabekov
2017-06-09 17:16 ` Stephen Hemminger
2017-06-09 17:28 ` Jerin Jacob
2017-06-10 8:16 ` Ananyev, Konstantin
2017-06-12 3:07 ` Jerin Jacob
2017-06-12 10:18 ` Ananyev, Konstantin
2017-06-12 10:34 ` Jerin Jacob
2017-06-12 11:09 ` Bruce Richardson
2017-06-12 11:41 ` Jerin Jacob
2017-06-12 12:17 ` Ananyev, Konstantin
2017-06-12 12:42 ` Jerin Jacob
2017-06-12 12:51 ` Ananyev, Konstantin
2017-06-12 13:06 ` Bruce Richardson
2017-06-12 13:20 ` Jerin Jacob
2017-06-30 11:36 ` Olivier Matz
2017-07-01 11:14 ` Thomas Monjalon
2017-07-01 11:25 ` 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=A5F28D4A728A7E41839CDC5C3B5A01E87EA1B586@FMSMSX103.amr.corp.intel.com \
--to=daniel.verkamp@intel.com \
--cc=dev@dpdk.org \
--cc=konstantin.ananyev@intel.com \
/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 a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).