> 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. > > 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.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]; > > > > >
