On Thu, Jan 18, 2018 at 11:07:52PM +0000, Carrillo, Erik G wrote: > > -----Original Message----- > > From: Pavan Nikhilesh [mailto:pbhagavat...@caviumnetworks.com] > > Sent: Thursday, January 11, 2018 6:19 AM > > To: Carrillo, Erik G <erik.g.carri...@intel.com>; > > jerin.ja...@caviumnetworks.com; nipun.gu...@nxp.com; > > hemant.agra...@nxp.com > > Cc: dev@dpdk.org > > Subject: Re: [PATCH v6 15/23] eventtimer: add buffering of timer expiry > > events > > > > On Wed, Jan 10, 2018 at 06:21:06PM -0600, Erik Gabriel Carrillo wrote: > > > Buffer timer expiry events generated while walking a "run list" > > > in rte_timer_manage, and burst enqueue them to an event device to the > > > extent possible. > > > > > > > IMO in some cases this adds a lot of delay between expiries and events being > > published to event dev. For example, having long expiry interval (default > > 300 > > seconds for mac expiry) the expired entries would remain in the buffer till > > 32 > > other entries expire. > > > > The service function invokes rte_timer_manage to handle expired timers, and > as it does so, the buffer will be flushed under two conditions: the buffer > is full of expired timer events, or the buffer is not full but there are no > more expired timers to handle for this iteration of the service. The latter > condition will flush the buffer even if only one event has been buffered > after walking the list of expired rte_timers.
Ah, I missed the flush call after timer_manage(). > > So, there could be some delay for the events that got buffered earliest, but > it seems like the throughput benefit outweighs the small delay there. > Thoughts? > > We could also make the buffer size configurable. Maybe make it compile time configurable i.e. in config/common_base. > > > > > > Signed-off-by: Erik Gabriel Carrillo <erik.g.carri...@intel.com> > > > --- > > > lib/librte_eventdev/rte_event_timer_adapter.c | 118 > > > +++++++++++++++++++++++--- > > > 1 file changed, 108 insertions(+), 10 deletions(-) > > > > > <snip>
