RE: [RFC 0/1] ring: add callback infrastructire to ring library

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

<snip>

> 
> Hi Honnappa,
> 
> Responses inline.
> I will continue with an initial implementation of this feature and capture
> performance data as suggested.
> 
> Rgds,
> Rory
> 
> > -----Original Message-----
> > From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
> > Sent: Wednesday, April 5, 2023 1:46 AM
> > To: Sexton, Rory <rory.sexton@intel.com>;
> > konstantin.v.ananyev@yandex.ru
> > Cc: dev@dpdk.org; nd <nd@arm.com>; nd <nd@arm.com>
> > Subject: RE: [RFC 0/1] ring: add callback infrastructire to ring
> > library
> >
> > Hi Roxy,
Sincere apologies for spelling your name incorrectly.

> > 	Thanks for the work, few questions inline.
> >
> > > -----Original Message-----
> > > From: Rory Sexton <rory.sexton@intel.com>
> > > Sent: Thursday, March 23, 2023 6:38 AM
> > > To: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>;
> > > konstantin.v.ananyev@yandex.ru
> > > Cc: dev@dpdk.org; Rory Sexton <rory.sexton@intel.com>
> > > Subject: [RFC 0/1] ring: add callback infrastructire to ring library
> > >
> > > This is an RFC proposing the addition of a callback infrastructure
> > > to the ring library, particularly in the ring dequeue functions, but
> > > they could also be added to the enqueue functions if desired.
> > >
> > > Callbacks in the ring dequeue functions would be beneficial for a
> > > number of reasons including but not limited to the following:
> > > - would allow users to register specific functions to be called on dequeue
> of a
> > >   ring avoiding the need to call the function within application code on
> several
> > >   threads reading from said ring.
> > I do not completely understand the 'avoiding the need to call the function
> within application code on several threads reading from said ring'.
> Irrespective of where the feature is implemented (either in ring library or the
> application), the call back function will be called on all the threads that
> receive from this queue.
> I just mean the callback infrastructure would handle the call back function
> rather than developer needing to call their implemented function explicitly
Thanks for clarifying

> 
> >
<snip>

> 
> >
> > >
> > > The addition of callbacks wouldn't impact the reading of rings by
> > > more than 1 cycle when no callbacks are registered. They could also
> > > additionally be compiled in/out as desired to give more confidence
> > > in maintaining performance when callbacks are not required.
> > I would prefer to keep this feature on always as maintenance is easier. But, I
> think we should make that decision only after we have performance data. Is it
> possible to provide some performance data with this feature on but no
> callbacks registered?
> Agreed that keeping the feature always on would be easier long-term.
> I can capture performance data with the feature on but no callbacks
> registered.
> We can base the final implementation with that data in mind.
Ack

<snip>