On Thu, Oct 5, 2023 at 6:01 PM Bruce Richardson
<bruce.richard...@intel.com> wrote:
>
> On Thu, Oct 05, 2023 at 12:51:00PM +0100, Bruce Richardson wrote:
> > The event structure in DPDK is 16-bytes in size, and events are
> > regularly passed as parameters directly rather than being passed as
> > pointers. To help compiler optimize correctly, we can explicitly request
> > 16-byte alignment for events, which means that we should be able
> > to do aligned vector loads/stores (e.g. with SSE or Neon) when working
> > with those events.
> >
> > Signed-off-by: Bruce Richardson <bruce.richard...@intel.com>
> > ---
> >  lib/eventdev/rte_eventdev.h | 2 +-
> >  1 file changed, 1 insertion(+), 1 deletion(-)
> >
> > diff --git a/lib/eventdev/rte_eventdev.h b/lib/eventdev/rte_eventdev.h
> > index 2ba8a7b090..bb0d59b059 100644
> > --- a/lib/eventdev/rte_eventdev.h
> > +++ b/lib/eventdev/rte_eventdev.h
> > @@ -1344,7 +1344,7 @@ struct rte_event {
> >               struct rte_event_vector *vec;
> >               /**< Event vector pointer. */
> >       };
> > -};
> > +} __rte_aligned(16);
> >
>

+ Eventdev driver maintainers for review and for performance testing.

> Looking for feedback on this idea - hence the fact this is going as an RFC.

Are you seeing any performance improvement ? Look like only DLB2
driver only using SEE or AVX512 instructions.

> It seems to me something that should be done for performance reasons, but
> I'm not sure if there are any negative consequences of doing this.

In general, it looks OK, However, We may need more testing.
I can only speculate the following as of now, Since event memory is
allocated from stack most case,
there may stack pointer fix up in code for desired alignment ie. some
add/sub instructions which comes for free most likely due to pipeline.

We will test on Marvel HW. Request others to test on their HWs.


>
> Since this is an ABI-affecting change, a decision on this needs to be made
> for 23.11, or else it will be locked in for at least another year. Hence me
> sending it now as an RFC late in the release cycle, rather than deferring
> to next release.
>
> /Bruce

Reply via email to