From: "Morten Brørup" <mb@smartsharesystems.com>
To: "Jerin Jacob" <jerinjacobk@gmail.com>,
"Mattias Rönnblom" <mattias.ronnblom@ericsson.com>
Cc: "Sivaprasad Tummala" <sivaprasad.tummala@amd.com>,
<jerinj@marvell.com>, <dev@dpdk.org>
Subject: RE: [PATCH] eventdev: fix alignment padding
Date: Wed, 17 May 2023 15:35:18 +0200 [thread overview]
Message-ID: <98CBD80474FA8B44BF855DF32C47DC35D8792A@smartserver.smartshare.dk> (raw)
In-Reply-To: <CALBAE1P2aELhMaO0NqYuu8O9p_RZDmKKwTa9byhxDvFqV-TC0Q@mail.gmail.com>
> From: Jerin Jacob [mailto:jerinjacobk@gmail.com]
> Sent: Wednesday, 17 May 2023 15.20
>
> On Tue, Apr 18, 2023 at 8:46 PM Mattias Rönnblom
> <mattias.ronnblom@ericsson.com> wrote:
> >
> > On 2023-04-18 16:07, Morten Brørup wrote:
> > >> From: Mattias Rönnblom [mailto:mattias.ronnblom@ericsson.com]
> > >> Sent: Tuesday, 18 April 2023 14.31
> > >>
> > >> On 2023-04-18 12:45, Sivaprasad Tummala wrote:
> > >>> fixed the padding required to align to cacheline size.
> > >>>
> > >>
> > >> What's the point in having this structure cache-line aligned? False
> > >> sharing is a non-issue, since this is more or less a read only struct.
> > >>
> > >> This is not so much a comment on your patch, but the __rte_cache_aligned
> > >> attribute.
> > >
> > > When the structure is cache aligned, an individual entry in the array does
> not unnecessarily cross a cache line border. With 16 pointers and aligned, it
> uses exactly two cache lines. If unaligned, it may span three cache lines.
> > >
> > An *element* in the reserved uint64_t array won't span across two cache
> > lines, regardless if __rte_cache_aligned is specified or not. You would
> > need a packed struct for that to occur, plus the reserved array field
> > being preceded by some appropriately-sized fields.
> >
> > The only effect __rte_cache_aligned has on this particular struct is
> > that if you instantiate the struct on the stack, or as a static
> > variable, it will be cache-line aligned. That effect you can get by
> > specifying the attribute when you define the variable, and you will save
> > some space (by having smaller elements). In this case it doesn't matter
> > if the array is compact or not, since an application is likely to only
> > use one of the members in the array.
> >
> > It also doesn't matter of the struct is two or three cache lines, as
> > long as only the first two are used.
>
>
> Discussions stalled at this point.
Not stalled at this point. You seem to have missed my follow-up email clarifying why cache aligning is relevant:
http://inbox.dpdk.org/dev/98CBD80474FA8B44BF855DF32C47DC35D87897@smartserver.smartshare.dk/
But the patch still breaks the ABI, and thus should be postponed to 23.11.
>
> Hi Shiva,
>
> Marking this patch as rejected. If you think the other way, Please
> change patchwork status and let's discuss more here.
I am not taking any action regarding the status of this patch. I will leave that decision to Jerin and Shiva.
>
>
>
> >
> > >>
> > >>> Fixes: 54f17843a887 ("eventdev: add port maintenance API")
> > >>> Cc: mattias.ronnblom@ericsson.com
> > >>>
> > >>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala@amd.com>
> > >>> ---
> > >>> lib/eventdev/rte_eventdev_core.h | 2 +-
> > >>> 1 file changed, 1 insertion(+), 1 deletion(-)
> > >>>
> > >>> diff --git a/lib/eventdev/rte_eventdev_core.h
> > >> b/lib/eventdev/rte_eventdev_core.h
> > >>> index c328bdbc82..c27a52ccc0 100644
> > >>> --- a/lib/eventdev/rte_eventdev_core.h
> > >>> +++ b/lib/eventdev/rte_eventdev_core.h
> > >>> @@ -65,7 +65,7 @@ struct rte_event_fp_ops {
> > >>> /**< PMD Tx adapter enqueue same destination function. */
> > >>> event_crypto_adapter_enqueue_t ca_enqueue;
> > >>> /**< PMD Crypto adapter enqueue function. */
> > >>> - uintptr_t reserved[6];
> > >>> + uintptr_t reserved[5];
> > >>> } __rte_cache_aligned;
> > >>>
> > >>> extern struct rte_event_fp_ops rte_event_fp_ops[RTE_EVENT_MAX_DEVS];
> > >
> >
next prev parent reply other threads:[~2023-05-17 13:35 UTC|newest]
Thread overview: 13+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-04-18 10:45 Sivaprasad Tummala
2023-04-18 11:06 ` Morten Brørup
2023-04-18 12:40 ` Mattias Rönnblom
2023-04-18 12:30 ` Mattias Rönnblom
2023-04-18 14:07 ` Morten Brørup
2023-04-18 15:16 ` Mattias Rönnblom
2023-04-19 6:38 ` Morten Brørup
2023-05-17 13:20 ` Jerin Jacob
2023-05-17 13:35 ` Morten Brørup [this message]
2023-05-23 15:15 ` Jerin Jacob
2023-08-02 16:19 ` Jerin Jacob
2023-08-08 10:24 ` Jerin Jacob
2023-08-08 10:25 ` Jerin Jacob
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=98CBD80474FA8B44BF855DF32C47DC35D8792A@smartserver.smartshare.dk \
--to=mb@smartsharesystems.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=jerinjacobk@gmail.com \
--cc=mattias.ronnblom@ericsson.com \
--cc=sivaprasad.tummala@amd.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).