On Wed, May 17, 2023 at 7:05 PM Morten Brørup <m...@smartsharesystems.com>
wrote:
>
> > From: Jerin Jacob [mailto:jerinjac...@gmail.com]
> > Sent: Wednesday, 17 May 2023 15.20
> >
> > On Tue, Apr 18, 2023 at 8:46 PM Mattias Rönnblom
> > <mattias.ronnb...@ericsson.com> wrote:
> > >
> > > On 2023-04-18 16:07, Morten Brørup wrote:
> > > >> From: Mattias Rönnblom [mailto:mattias.ronnb...@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/98cbd80474fa8b44bf855df32c47dc35d87...@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.ronnb...@ericsson.com
> > > >>>
> > > >>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tumm...@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];
> > > >
> > >
