rte_ring_elem_pvt historical question

rte_ring_elem_pvt historical question

[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?

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

Re: rte_ring_elem_pvt historical question

[Konstantin Ananyev]

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.
For 32 - as I remember we never explicitly require 4B aligned
objects for the rings ... Am I missing something here?
My guess, we just never hit such problem so it gets unnoticed.
Probably worth updating 32-bit version too with explicit 'unaligned' type.


> 
> 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
> 

RE: rte_ring_elem_pvt historical question

[Morten Brørup]

> 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
> >
>