On 2022-05-09 05:48, Stephen Hemminger wrote:
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.
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.
Should rte_seqcount_t be in a separate file?
Normally, I would use the "header file per 'class'" pattern (unless
things are very tightly coupled), but I suspect DPDK style is the
"header file per group of related 'classes'".
