> -----Original Message----- > From: Carrillo, Erik G <erik.g.carri...@intel.com> > Sent: Saturday, April 27, 2019 12:29 AM > To: Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; > jerin.ja...@caviumnetworks.com > Cc: mattias.ronnb...@ericsson.com; pbhagavat...@caviumnetworks.com; > dev@dpdk.org; nd <n...@arm.com>; nd <n...@arm.com> > Subject: RE: [dpdk-dev] [PATCH v6 1/1] eventdev: add new software event timer > adapter > > > > > -----Original Message----- > > From: Honnappa Nagarahalli [mailto:honnappa.nagaraha...@arm.com] > > Sent: Friday, April 26, 2019 1:51 PM > > To: Carrillo, Erik G <erik.g.carri...@intel.com>; > > jerin.ja...@caviumnetworks.com > > Cc: mattias.ronnb...@ericsson.com; pbhagavat...@caviumnetworks.com; > > dev@dpdk.org; Honnappa Nagarahalli <honnappa.nagaraha...@arm.com>; nd > > <n...@arm.com>; nd <n...@arm.com> > > Subject: RE: [dpdk-dev] [PATCH v6 1/1] eventdev: add new software > > event timer adapter > > > > Hi Erik, > > A quick question. > > > > > -----Original Message----- > > > From: dev <dev-boun...@dpdk.org> On Behalf Of Erik Gabriel Carrillo > > > Sent: Friday, April 26, 2019 10:14 AM > > > To: jerin.ja...@caviumnetworks.com > > > Cc: mattias.ronnb...@ericsson.com; > > pbhagavat...@caviumnetworks.com; > > > dev@dpdk.org > > > 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
