> -----Original Message----- > From: Carrillo, Erik G <[email protected]> > Sent: Saturday, April 27, 2019 12:29 AM > To: Honnappa Nagarahalli <[email protected]>; > [email protected] > Cc: [email protected]; [email protected]; > [email protected]; nd <[email protected]>; nd <[email protected]> > Subject: RE: [dpdk-dev] [PATCH v6 1/1] eventdev: add new software event timer > adapter > > > > > -----Original Message----- > > From: Honnappa Nagarahalli [mailto:[email protected]] > > Sent: Friday, April 26, 2019 1:51 PM > > To: Carrillo, Erik G <[email protected]>; > > [email protected] > > Cc: [email protected]; [email protected]; > > [email protected]; Honnappa Nagarahalli <[email protected]>; nd > > <[email protected]>; nd <[email protected]> > > Subject: RE: [dpdk-dev] [PATCH v6 1/1] eventdev: add new software > > event timer adapter > > > > Hi Erik, > > A quick question. > > > > > -----Original Message----- > > > From: dev <[email protected]> On Behalf Of Erik Gabriel Carrillo > > > Sent: Friday, April 26, 2019 10:14 AM > > > To: [email protected] > > > Cc: [email protected]; > > [email protected]; > > > [email protected] > > > Subject: [dpdk-dev] [PATCH v6 1/1] eventdev: add new software event > > > timer adapter > > > > > > This patch introduces a new version of the event timer adapter > > > software > > PMD. > > > In the original design, timer event producer lcores in the primary > > > and secondary processes enqueued event timers into a ring, and a > > > service core in the primary process dequeued them and processed them > further. > > > To improve performance, this version does away with the ring and
In general idea and patch looks good to me. Could you update git commit log with # Percentage of performance improvement seen with this method? # Means(test command etc) of measuring the performance improvement? > > > lets lcores in both primary and secondary processes insert timers > > > directly into timer skiplist data structures; the service core > > > directly accesses the lists as well, when looking for timers that have > > > expired. > > How do you ensure concurrent access to the timer skiplist? Are you > > using any locks or is it a lock-free data structure? > > > > <snip> > > There are multiple timer skiplists, one for each lcore, and each has its > lock that > is acquired as necessary when adding or removing timers from the skiplists. > This > locking occurs in the underlying timer library, in the timer reset and stop > functions. > > Regards, > Erik
