Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe:

[Bruce Richardson <bruce.richardson@intel.com>]

On Fri, Sep 26, 2014 at 02:13:55PM +0000, Ananyev, Konstantin wrote:
> > From: dev [mailto:dev-bounces@dpdk.org] On Behalf Of Neil Horman
> > Sent: Friday, September 26, 2014 2:40 PM
> > To: Wodkowski, PawelX
> > Cc: dev@dpdk.org
> > Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe:
> > 
> > On Fri, Sep 26, 2014 at 12:37:54PM +0000, Wodkowski, PawelX wrote:
> > > > So basically cancel() just set ALARM_CANCELLED and leaves actual alarm
> > > > deletion to the callback()?
> > > > That was the thought, yes.
> > > >
> > > > > I think it is doable - but I don't see any real advantage with that approach.
> > > > > Yes, code will become a bit simpler, as  we'll have one point when we remove
> > > > alarm from the list.
> > > > Yes, that would be the advantage, that the code would be much simpler.
> > > >
> > > > > But from other side, imagine such simple test-case:
> > > > >
> > > > > for (i = 0; i < 0x100000; i++) {
> > > > >    rte_eal_alarm_set(ONE_MIN, cb_func, (void *)i);
> > > > >    rte_eal_alarm_cancel(cb_func, (void *)i);
> > > > > }
> > > > >
> > > > > We'll endup with 1M of cancelled, but still not removed entries in the
> > > > alarm_list.
> > > > > With current implementation that means - few MBs of wasted memory,
> > > > Thats correct, and the tradeoff to choose between.  Do you want simpler code
> > > > that is easier to maintain, or do you want a high speed cancel and set
> > > > operation.  I'm not aware of all the use cases, but I have a hard time seeing
> > > > a use case in which the in-flight alarm list grows unboundedly large, which in
> > > > my mind mitigates the risk of deferred removal, but I'm perfectly willing to
> > > > believe that there are use cases which I'm not aware of.
> 
> After executing example above - from user perspective there is no active alarms in the system at all.
> Though in fact alarm_list contains 1M entries. 

This would concern me. It's likely that in applications, e.g. those with a 
network stack for instance, timers could be used for timeouts e.g. on 
connections, which would mean that the common case by far would be for 
timers to be cancelled or rescheduled without ever timing out.

/Bruce