[PATCH] eventdev: fix alignment padding

[Morten Brørup]

> From: Jerin Jacob [mailto:jerinjacobk at gmail.com]
> Sent: Wednesday, 17 May 2023 15.20
> 
> On Tue, Apr 18, 2023 at 8:46 PM Mattias Rönnblom
> <mattias.ronnblom at ericsson.com> wrote:
> >
> > On 2023-04-18 16:07, Morten Brørup wrote:
> > >> From: Mattias Rönnblom [mailto:mattias.ronnblom at 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 at ericsson.com
> > >>>
> > >>> Signed-off-by: Sivaprasad Tummala <sivaprasad.tummala at 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];
> > >
> >