Hi Thomas, OK, I'll take a fresh look at these.
Thanks, Erik > -----Original Message----- > From: Thomas Monjalon [mailto:tho...@monjalon.net] > Sent: Wednesday, April 4, 2018 5:43 PM > To: Carrillo, Erik G <erik.g.carri...@intel.com> > Cc: dev@dpdk.org; rsanf...@akamai.com; Mcnamara, John > <john.mcnam...@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 > > > > > > > > > >
