From mboxrd@z Thu Jan 1 00:00:00 1970 Return-Path: Received: from mga03.intel.com (mga03.intel.com [134.134.136.65]) by dpdk.org (Postfix) with ESMTP id 3A0605902 for ; Mon, 29 Sep 2014 12:31:16 +0200 (CEST) Received: from azsmga001.ch.intel.com ([10.2.17.19]) by orsmga103.jf.intel.com with ESMTP; 29 Sep 2014 03:35:39 -0700 X-ExtLoop1: 1 X-IronPort-AV: E=Sophos;i="5.04,619,1406617200"; d="scan'208";a="480706178" Received: from bricha3-mobl.ger.corp.intel.com (HELO bricha3-mobl.ir.intel.com) ([10.243.20.21]) by azsmga001.ch.intel.com with SMTP; 29 Sep 2014 03:37:48 -0700 Received: by bricha3-mobl.ir.intel.com (sSMTP sendmail emulation); Mon, 29 Sep 2014 11:37:47 +0001 Date: Mon, 29 Sep 2014 11:37:47 +0100 From: Bruce Richardson To: "Ananyev, Konstantin" Message-ID: <20140929103747.GC12072@BRICHA3-MOBL> References: <1411649768-8084-1-git-send-email-michalx.k.jastrzebski@intel.com> <20140925150807.GD32725@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB977258213769DE@IRSMSX105.ger.corp.intel.com> <20140925172358.GG32725@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB97725821378B50@IRSMSX104.ger.corp.intel.com> <20140926114630.GA3930@hmsreliant.think-freely.org> <20140926134014.GB3930@hmsreliant.think-freely.org> <2601191342CEEE43887BDE71AB9772582137D7F1@IRSMSX104.ger.corp.intel.com> MIME-Version: 1.0 Content-Type: text/plain; charset=us-ascii Content-Disposition: inline In-Reply-To: <2601191342CEEE43887BDE71AB9772582137D7F1@IRSMSX104.ger.corp.intel.com> Organization: Intel Shannon Ltd. User-Agent: Mutt/1.5.22 (2013-10-16) Cc: "dev@dpdk.org" Subject: Re: [dpdk-dev] [PATCH v2] Change alarm cancel function to thread-safe: X-BeenThere: dev@dpdk.org X-Mailman-Version: 2.1.15 Precedence: list List-Id: patches and discussions about DPDK List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , X-List-Received-Date: Mon, 29 Sep 2014 10:31:16 -0000 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