From: Jerin Jacob <jerinjacobk@gmail.com>
To: "Morten Brørup" <mb@smartsharesystems.com>
Cc: "Mattias Rönnblom" <mattias.ronnblom@ericsson.com>,
"Sivaprasad Tummala" <sivaprasad.tummala@amd.com>,
jerinj@marvell.com, dev@dpdk.org
Subject: Re: [PATCH] eventdev: fix alignment padding
Date: Tue, 23 May 2023 20:45:44 +0530 [thread overview]
Message-ID: <CALBAE1Oe9zkGR2o9oKezfTxYxJ5CUU8xVqw9QxT0iSyEQSvFiw@mail.gmail.com> (raw)
In-Reply-To: <98CBD80474FA8B44BF855DF32C47DC35D8792A@smartserver.smartshare.dk>
On Wed, May 17, 2023 at 7:05 PM Morten Brørup <mb@smartsharesystems.com> wrote:
>
> > 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.
Yes.
>
> >
> > 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.
It is good to merge.
Shiva,
Please send ABI change notice for this for 23.11 NOW.
Once it is Acked and merged. I will merge the patch for 23.11 release.
I am marking the patch as DEFERRED in patchwork and next release
window it will come as NEW in patchwork.
>
> >
> >
> >
> > >
> > > >>
> > > >>> 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-23 15:16 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
2023-05-23 15:15 ` Jerin Jacob [this message]
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=CALBAE1Oe9zkGR2o9oKezfTxYxJ5CUU8xVqw9QxT0iSyEQSvFiw@mail.gmail.com \
--to=jerinjacobk@gmail.com \
--cc=dev@dpdk.org \
--cc=jerinj@marvell.com \
--cc=mattias.ronnblom@ericsson.com \
--cc=mb@smartsharesystems.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).