> -----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. 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. > > > 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>
