<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.nagaraha...@arm.com> > > Sent: Wednesday, April 5, 2023 1:46 AM > > To: Sexton, Rory <rory.sex...@intel.com>; > > konstantin.v.anan...@yandex.ru > > Cc: dev@dpdk.org; nd <n...@arm.com>; nd <n...@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.sex...@intel.com> > > > Sent: Thursday, March 23, 2023 6:38 AM > > > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; > > > konstantin.v.anan...@yandex.ru > > > Cc: dev@dpdk.org; Rory Sexton <rory.sex...@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>
