<snip>
> >
> > > +
> > > +/**
> > > + * Start to enqueue several objects on the ring.
> > > + * Note that no actual objects are put in the queue by this
> > > +function,
> > > + * it just reserves for user such ability.
> > > + * User has to call appropriate enqueue_finish() to copy objects
> > > +into the
> > > + * queue and complete given enqueue operation.
> > > + *
> > > + * @param r
> > > + * A pointer to the ring structure.
> > > + * @param n
> > > + * The number of objects to add in the ring from the obj_table.
> > > + * @param free_space
> > > + * if non-NULL, returns the amount of space in the ring after the
> > > + * enqueue operation has finished.
> > > + * @return
> > > + * The number of objects that can be enqueued, either 0 or n
> > > + */
> > > +__rte_experimental
> > > +static __rte_always_inline unsigned int
> > > +rte_ring_enqueue_bulk_start(struct rte_ring *r, unsigned int n,
> > > + unsigned int *free_space)
> > If one wants to use _elem_ APIs for ring peek, a combination of legacy API
> (format) and a _elem_ API is required.
> > For ex:
> > rte_ring_enqueue_bulk_start
> > rte_ring_enqueue_elem_finish
> >
> > I understand why you have done this. I think this is getting somewhat too
> inconsistent.
> >
>
> Agree, there could be some confusion.
> Don't know what would be a better approach here....
> 2 similar functions with exactly same parameter list (one wrapper for
> another):
> rte_ring_enqueue_elem_bulk_start() and
> rte_ring_enqueue_elem_bulk_start().
> ?
We should go with 2 functions 'rte_ring_enqueue_bulk_start' and
'rte_ring_enqueue_bulk_elem_start'. There is a slight variation in the way
obj_table is provided.
'rte_ring_enqueue_bulk_start' can be the wrapper.
>
> > > +{
> > > + return __rte_ring_do_enqueue_start(r, n, RTE_RING_QUEUE_FIXED,
> > > + free_space);
> > > +}
> > > +
> >
