>
> Hi Honnappa,
>
> snipped
> > >
> > > Add callback event handler for enqueue dequeue operation on ring.
> > > The pre-enqueue and post-dequeue operation on ring is selected to
> > > invoke user callback handler.
> > Can you provide a use case for this to better understand the need?
> Use cases:
> - allow user to investigate the contents pre-enqueue.
> - allow user to investigate the contents post-dequeue.
> - modify pre-enqueue and post-dequeue stage content.
> - investigate PMD meta data for debug in field nodes.
>
> snipped
> > > + struct rte_ring_enq_cb_list enq_cbs;
> > > + struct rte_ring_deq_cb_list deq_cbs; };
> > This breaks ABI compatibility
> Can you help me understand this more clearly?
'struct rte_ring' is exposed to the application. It is possible that the
application has declared a variable of type 'struct rte_ring'. Any addition to
this structure will increase the size of 'struct rte_ring'. Hence, it won't be
compatible.
>
> snipped
> > > -rte_ring_enqueue_burst(struct rte_ring *r, void * const *obj_table,
> > > +rte_ring_enqueue_burst(struct rte_ring *r, void **obj_table,
> > > unsigned int n, unsigned int *free_space) {
> > > +#ifdef RTE_RING_ENQDEQ_CALLBACKS
> > > + struct rte_ring_callback *cb = NULL;
> > > +
> > > + TAILQ_FOREACH(cb, &(r->enq_cbs), next) {
> > Need to take the TAILQ lock before this. For ex: what happens if a
> > un-register is called concurrently?
> Let me check this, using rx|tx callback as reference.
>
> > Also, traversing a linked list for every enqueue call would be too
> > costly. May be, understanding the use case will help.
> Internal testing with SP-SC is 0.1% (with extra cost of user function). But I
> will
> try to explore other alternatives too.
>
> Snipped
