Re: [PATCH v4 0/3] timer library enhancement

["Carrillo, Erik G" <erik.g.carrillo@intel.com>]

Hi Thomas,

OK, I'll take a fresh look at these.

Thanks,
Erik

> -----Original Message-----
> From: Thomas Monjalon [mailto:thomas@monjalon.net]
> Sent: Wednesday, April 4, 2018 5:43 PM
> To: Carrillo, Erik G <erik.g.carrillo@intel.com>
> Cc: dev@dpdk.org; rsanford@akamai.com; Mcnamara, John
> <john.mcnamara@intel.com>
> Subject: Re: [dpdk-dev] [PATCH v4 0/3] timer library enhancement
> 
> 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
> >
> >
> >
> 
> 
> 
>