RE: rte_ring_elem_pvt historical question

["Morten Brørup" <mb@smartsharesystems.com>]

> From: Konstantin Ananyev [mailto:konstantin.v.ananyev@yandex.ru]
> Sent: Tuesday, 5 July 2022 10.55
> 
> 04/07/2022 12:35, Morten Brørup пишет:
> > Does anyone here remember why the
> __rte_ring_enqueue/dequeue_elems_64/128() functions support unaligned
> object arrays, when the __rte_ring_enqueue/dequeue_elems_32() functions
> require 4 byte aligned object arrays?
> 
> As I remember, we added 'unaligned' to be able to use rte_ring with
> elements that might have smaller alignment.

Was there a use case behind this, or just trying to future proof the ring library?

Using arrays of unaligned objects seems quite exotic to me.

> For 32 - as I remember we never explicitly require 4B aligned
> objects for the rings ... Am I missing something here?

Not related to my question; I was only referring to 32 to show the difference for the 64/128 functions.

> My guess, we just never hit such problem so it gets unnoticed.
> Probably worth updating 32-bit version too with explicit 'unaligned'
> type.

I would suggest doing the opposite, i.e. removing unaligned from 64/128, unless there is a real use case requiring unaligned elements.

Either way, we agree that it should be consistent across the 32-bit version too.

> >
> > I'm wondering if the compiler could do better with a simpler
> implementation than the manually implemented loop unrolls, and if the
> unalignment silliness would stand in the way.
> >
> > Med venlig hilsen / Kind regards,
> > -Morten Brørup
> >
>