RE: [RFC] lib/st_ring: add single thread ring

[Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>]

> -----Original Message-----
> From: Morten Brørup <mb@smartsharesystems.com>
> Sent: Monday, August 21, 2023 2:37 AM
> To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> jackmin@nvidia.com; konstantin.v.ananyev@yandex.ru
> Cc: dev@dpdk.org; Ruifeng Wang <Ruifeng.Wang@arm.com>; Aditya
> Ambadipudi <Aditya.Ambadipudi@arm.com>; Wathsala Wathawana Vithanage
> <wathsala.vithanage@arm.com>; nd <nd@arm.com>
> Subject: RE: [RFC] lib/st_ring: add single thread ring
> 
> > From: Honnappa Nagarahalli [mailto:honnappa.nagarahalli@arm.com]
> > Sent: Monday, 21 August 2023 08.04
> >
> > Add a single thread safe and multi-thread unsafe ring data structure.
> > This library provides an simple and efficient alternative to multi-
> > thread safe ring when multi-thread safety is not required.
> >
> > Signed-off-by: Honnappa Nagarahalli <honnappa.nagarahalli@arm.com>
> > ---
> 
> Good idea.
> 
> However, I prefer it to be implemented in the ring lib as one more ring type.
> That would also give us a lot of the infrastructure (management functions,
> documentation and tests) for free.
IMO, the current code for rte_ring seems complex with C11 and generic implementations, APIs for pointer objects vs APIs for flexible element size etc. I did not want to introduce one more flavor and make it more complex.
The requirements are different as well. For ex: single thread ring needs APIs for dequeuing and enqueuing at both ends of the ring which is not applicable to existing RTE ring.

But, I see how the existing infra can be reused easily.

> 
> The ring lib already has performance-optimized APIs for single-consumer and
> single-producer use, rte_ring_sc_dequeue_bulk() and
> rte_ring_sp_enqueue_burst(). Similar performance-optimized APIs for single-
> thread use could be added: rte_ring_st_dequeue_bulk() and
> rte_ring_st_enqueue_burst().
Yes, the names look fine.
Looking through the code. We have the sync type enum:

/** prod/cons sync types */
enum rte_ring_sync_type {
        RTE_RING_SYNC_MT,     /**< multi-thread safe (default mode) */
        RTE_RING_SYNC_ST,     /**< single thread only */
        RTE_RING_SYNC_MT_RTS, /**< multi-thread relaxed tail sync */
        RTE_RING_SYNC_MT_HTS, /**< multi-thread head/tail sync */
};

The type RTE_RING_SYNC_ST needs better explanation (not a problem). But, this name would have been ideal to use for single thread ring.
This enum does not need to be exposed to the users. However, there are rte_ring_get_prod/cons_sync_type etc which seem to be exposed to the user.
This all means, we need to have a sync type name RTE_RING_SYNC_MT_UNSAFE (any other better name?) which then affects API naming. rte_ring_mt_unsafe_dequeue_bulk?

> 
> Regardless if added to the ring lib or as a separate lib, "reverse" APIs (for single-
> thread use only) and zero-copy APIs can be added at any time later.