> > +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;
> > +}
> > +
