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