[dpdk-dev] [PATCH v4 0/3] timer library enhancement

[Thomas Monjalon]

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