From mboxrd@z Thu Jan  1 00:00:00 1970
Return-Path: <thomas@monjalon.net>
Received: from out5-smtp.messagingengine.com (out5-smtp.messagingengine.com
 [66.111.4.29]) by dpdk.org (Postfix) with ESMTP id 59FEB1C89A
 for <dev@dpdk.org>; Thu,  5 Apr 2018 00:42:45 +0200 (CEST)
Received: from compute1.internal (compute1.nyi.internal [10.202.2.41])
 by mailout.nyi.internal (Postfix) with ESMTP id 9422222818;
 Wed,  4 Apr 2018 18:42:44 -0400 (EDT)
Received: from mailfrontend1 ([10.202.2.162])
 by compute1.internal (MEProxy); Wed, 04 Apr 2018 18:42:44 -0400
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=monjalon.net; h=
 cc:content-transfer-encoding:content-type:date:from:in-reply-to
 :message-id:mime-version:references:subject:to:x-me-sender
 :x-me-sender:x-sasl-enc; s=mesmtp; bh=ehNlwKPwZw6qgucWvgGDvAmlWW
 sbdURs6SQvhVKtxug=; b=Akf9Wzx8VPNvfPE5jDGLuiBVeXXwSL/1Grw7PJ8HGV
 +IX6NggOnEWBgIVt1Bj/tfaLuH8+ms4Q3qmTL7xSqVQ2bsqc10DMmK5eoT0h4W2k
 R8VAC8RGI0R8IZ0EJU5HoZ8KrNub8cbPmZz2h3AkcpHDC8zf5ojpnmAvgZw7wCpZ
 M=
DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=
 messagingengine.com; h=cc:content-transfer-encoding:content-type
 :date:from:in-reply-to:message-id:mime-version:references
 :subject:to:x-me-sender:x-me-sender:x-sasl-enc; s=fm2; bh=ehNlwK
 PwZw6qgucWvgGDvAmlWWsbdURs6SQvhVKtxug=; b=gd/wSlXCet2kDoydDi5Lry
 AGqrKhUN4wpd6t/EXtX5n1irlVbqQMXJWuhQTEZuVDwmQgm1+CNtg0/pjVMQSN7g
 JOP5kfcrrTRf3y9GigtJQoiRESTh42VkDgx8vpApXN/0+aXln4RB5OAt+FKj+dqx
 5ppEuVvgaYZG2PSou6Rpe0sY8vzsV/xoDwvCoXwewVvlLf9S1wx+vTkpBMgyrLcx
 IAmGZu660wj1HOdcH55KuErzNHQYXdm7JJd+gHnyMY3gck658Gjp+9e1MoIBIJPF
 42qgNKVA9B11vp+uV+o+fJdvOBcgtuLEj//m2K4Ws4UAOfgbsavZAlzOIUfJedpA
 ==
X-ME-Sender: <xms:5FTFWqMplnzmEg67pcLIGW3rhnfFLtvVomCw2xtlhXU9G8uKNA9MLQ>
Received: from xps.localnet (184.203.134.77.rev.sfr.net [77.134.203.184])
 by mail.messagingengine.com (Postfix) with ESMTPA id C378FE43BE;
 Wed,  4 Apr 2018 18:42:43 -0400 (EDT)
From: Thomas Monjalon <thomas@monjalon.net>
To: Erik Gabriel Carrillo <erik.g.carrillo@intel.com>
Cc: dev@dpdk.org, rsanford@akamai.com, john.mcnamara@intel.com
Date: Thu, 05 Apr 2018 00:42:42 +0200
Message-ID: <23441980.cXtjEeRPDa@xps>
In-Reply-To: <53861185.JAf0AvXReA@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-Transfer-Encoding: 7Bit
Content-Type: text/plain; charset="us-ascii"
Subject: Re: [dpdk-dev] [PATCH v4 0/3] timer library enhancement
X-BeenThere: dev@dpdk.org
X-Mailman-Version: 2.1.15
Precedence: list
List-Id: DPDK patches and discussions <dev.dpdk.org>
List-Unsubscribe: <https://dpdk.org/ml/options/dev>,
 <mailto:dev-request@dpdk.org?subject=unsubscribe>
List-Archive: <http://dpdk.org/ml/archives/dev/>
List-Post: <mailto:dev@dpdk.org>
List-Help: <mailto:dev-request@dpdk.org?subject=help>
List-Subscribe: <https://dpdk.org/ml/listinfo/dev>,
 <mailto:dev-request@dpdk.org?subject=subscribe>
X-List-Received-Date: Wed, 04 Apr 2018 22:42:45 -0000

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