[PATCH v4 2/2] ring: introduce peek API for soring

[Konstantin Ananyev]

> > +static inline uint32_t
> > +soring_enqueue_start(struct rte_soring *r, uint32_t num,
> > +	enum rte_ring_queue_behavior behavior, uint32_t *free_space)
> > +{
> > +	enum rte_ring_sync_type st;
> > +	uint32_t free, head, n, next;
> > +
> > +	RTE_ASSERT(r != NULL && r->nb_stage > 0);
> > +
> > +	st = r->prod.ht.sync_type;
> > +
> > +	switch (st) {
> > +	case RTE_RING_SYNC_ST:
> > +		n = __rte_ring_headtail_move_head(&r->prod.ht, &r->cons.ht,
> > +			r->capacity, RTE_RING_SYNC_ST, num, behavior,
> > +			&head, &next, &free);
> > +		break;
> > +	case RTE_RING_SYNC_MT_HTS:
> > +		n = __rte_ring_hts_move_head(&r->prod.hts, &r->cons.ht,
> > +			r->capacity, num, behavior, &head, &free);
> > +		break;
> > +	default:
> > +		/* unsupported mode, shouldn't be here */
> > +		RTE_ASSERT(0);
> 
> Is RTE_ASSERT(0) the right choice for failure here?
> Unless built with assertions enabled, RTE_ASSERT(0) does nothing, and this
> function also does nothing but returns 0 as free_space, which may not be
> correct.
> 
> Maybe rte_panic() instead.
> It's an application bug to call this with the wrong SORING sync type.
> We cannot handle it gracefully, so better to fail early.

Yep, it is a bug in application in such case, but as rule of thumb we avoid panics in
the libs, even when user provided incorrect input.
At least, all lib/ring API function work like that - if given sync type is not supported,
then function doesn't touch the ring contents and fills 'free/available'
parameter with zero. So ring is sort-of unusable to the caller.

> Just an idea; I have no strong preference.

Ok, then I leave it like that.
Thanks for the review.
Konstantin

> > +		free = 0;
> > +		n = 0;
> > +	}
> > +
> > +	if (free_space != NULL)
> > +		*free_space = free - n;
> > +	return n;
> > +}
> > +