From mboxrd@z Thu Jan 1 00:00:00 1970 From: Thomas Monjalon Subject: Re: [PATCH v4 0/3] timer library enhancement Date: Thu, 05 Apr 2018 00:42:42 +0200 Message-ID: <23441980.cXtjEeRPDa@xps> References: <1505340308-86141-1-git-send-email-erik.g.carrillo@intel.com> <1505840548-77004-1-git-send-email-erik.g.carrillo@intel.com> <53861185.JAf0AvXReA@xps> Mime-Version: 1.0 Content-Type: text/plain; charset="us-ascii" Content-Transfer-Encoding: 7Bit Cc: dev@dpdk.org, rsanford@akamai.com, john.mcnamara@intel.com To: Erik Gabriel Carrillo Return-path: Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 59FEB1C89A for ; Thu, 5 Apr 2018 00:42:45 +0200 (CEST) In-Reply-To: <53861185.JAf0AvXReA@xps> List-Id: DPDK patches and discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Errors-To: dev-bounces@dpdk.org Sender: "dev" Let's revive these patches. Erik, could you rebase them with experimental tag, please? Someone for a review? 11/10/2017 22:42, Thomas Monjalon: > This patchset is waiting for review. > > Robert, are you available? > > 19/09/2017 19:02, Erik Gabriel Carrillo: > > In the current implementation of the DPDK timer library, timers can be > > created and set to be handled by a target lcore by adding it to a > > skiplist that corresponds to that lcore. However, if an application > > enables multiple lcores, and each of these lcores repeatedly attempts > > to install timers on the same target lcore, overall application > > throughput will be reduced as all lcores contend to acquire the lock > > guarding the single skiplist of pending timers. > > > > This patchset addresses this scenario by adding an option to enable an > > array of skiplists in each lcore's priv_timer struct. Then, when lcore i > > installs a timer on lcore k, the timer will be added to the ith skiplist > > for lcore k. If lcore j installs a timer on lcore k simultaneously, > > lcores i and j can both proceed since they will be acquiring different > > locks for different lists. This functionality is off by default, and > > can be enabled via a new function. > > > > When lcore k processes its pending timers, if the multiple pending list > > option is enabled, it will traverse skiplists in its array and acquire > > the current skiplist's lock while a run list is broken out; meanwhile, > > all other lists can continue to be modified. Then, all run lists for > > lcore k are collected and traversed together so timers are executed in > > their relative order. If the multiple pending list option is not enabled > > (the default), only a single list will be traversed, as before. > > > > Erik Gabriel Carrillo (3): > > timer: add multiple pending lists option for each lcore > > timer: handle timers installed from non-EAL threads > > doc: update timer lib docs > > >