> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Monday, 9 May 2022 05.48
>
> On Sun, 8 May 2022 21:40:58 +0200
> Mattias Rönnblom <hof...@lysator.liu.se> wrote:
>
> > > I think would be good to have the sequence count (read side only)
> like
> > > the kernel and sequence lock (sequence count + spinlock) as
> separate things.
> > >
> > > That way the application could use sequence count + ticket lock if
> it
> > > needed to scale to more writers.
> > >
If we want a seqlock based on a ticket lock, I would prefer that DPDK offers
it, rather than requiring the application to implement it.
Regardless, adding the seqcount type as a separate thing could still make sense.
> >
> > Sounds reasonable. Would that be something like:
> >
> > typedef struct {
> > uint32_t sn;
> > } rte_seqlock_t;
> >
> > rte_seqlock_read_begin()
> > rte_seqlock_read_retry()
> > rte_seqlock_write_begin()
> > rte_seqlock_write_end()
> >
> > typedef struct {
> > rte_seqlock_t seqlock;
> > rte_spinlock_t wlock;
> > } rte_<something>_t;
> >
> > rte_<something>_read_begin()
> > rte_<something>_read_retry()
> > rte_<something>_write_lock()
> > rte_<something>_write_unlock()
> >
> > or are you suggesting removing the spinlock altogether, and leave
> > writer-side synchronization to the application (at least in this DPDK
> > release)?
>
>
> No, like Linux kernel. Use seqcount for the reader counter only object
> and seqlock for the seqcount + spinlock version.
In other words: Keep the existing names, i.e.
rte_seqlock_t/rte_seqlock_functions(), for what you have already implemented,
and use the names rte_seqcount_t/rte_seqcount_functions() for the variant
without the lock.
Linux source code here:
https://elixir.bootlin.com/linux/v5.10.113/source/include/linux/seqlock.h
I suppose that the rte_seqcount_t primitive should go into a separate file; it
is not really a lock.
