On 2022-03-24 05:52, Honnappa Nagarahalli wrote: > <snip> > >> Hi Mattias, >> >>> Would it make sense to have a seqlock implementation in DPDK? > I do not have any issues with adding the seqlock to DPDK. > > However, I am interested in understanding the use case. As I understand, > seqlock is a type of reader-writer lock. This means that it is possible that > readers (data plane) may be blocked till the writer completes the updates. > Does not this mean, data plane might drop packets while the writer is > updating entries?
Yes, it's not preemption-safe, just like for example a spinlock-protected data structure. If the writer is interrupted after having stored the first counter update, but before storing the second, all subsequent read attempts will fail. The reading workers would have decide to either give up reading the data structure being protected, or keep retrying indefinitely. This issue is common across all non-preemption-safe data structures (default rings, spinlocks etc), and can be avoided by (surprise!) avoiding preemption by running the control plane thread on RT priority or on a dedicated core, or to use a preemption safe way to tell one of the worker lcore threads to do the actual update. A seqlock is much more efficient on the reader side for high-frequency accesses from many cores than a regular RW lock (i.e., one implemented by two spinlocks or mutexes). A spinlock being lock/unlocked on a per-packet basis by every core is a total performance killer. >>> I think so, since it's a very useful synchronization primitive in data >>> plane applications. >>> >> Agree, it might be useful. >> As I remember rte_hash '_lf' functions do use something similar to seqlock, >> but >> in hand-made manner. >> Probably some other entities within DPDK itself or related projects will >> benefit >> from it too... >> >> Konstantin
