On Wed, 30 Mar 2022 16:26:02 +0200
Mattias Rönnblom wrote:
> +/**
> + * A static seqlock initializer.
> + */
> +#define RTE_SEQLOCK_INITIALIZER { 0, RTE_SPINLOCK_INITIALIZER }
Used named field initializers here please.
> +/**
> + * Initialize the seqlock.
> + *
> + * This function initializes t
m.com" ,
"konstantin.anan...@intel.com" ,
"m...@smartsharesystems.com" ,
"step...@networkplumber.org" Subject:
Re: [PATCH v2] eal: add seqlock Date: Thu, 31 Mar 2022 16:53:00 +0200
User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
Thunderbird/91.7.0
(T
> >> +static inline void
> >> +rte_seqlock_write_end(rte_seqlock_t *seqlock) {
> >> + uint32_t sn;
> >> +
> >> + sn = seqlock->sn + 1;
> >> +
> >> + /* synchronizes-with the load acquire in rte_seqlock_begin()
> >> */
> >> + __atomic_store_n(&seqlock->sn, sn, __ATOMIC_RELEASE);
> >> +
> >> +
On 4/2/22 02:50, Stephen Hemminger wrote:
On Wed, 30 Mar 2022 16:26:02 +0200
Mattias Rönnblom wrote:
+ __atomic_store_n(&seqlock->sn, sn, __ATOMIC_RELAXED);
+
+ /* __ATOMIC_RELEASE to prevent stores after (in program
order)
+* from happening before the sn store.
+
On 4/2/22 12:25, Morten Brørup wrote:
From: Stephen Hemminger [mailto:step...@networkplumber.org]
Sent: Saturday, 2 April 2022 02.54
Semantics and naming should be the same as Linux kernel or you risk
having to reeducate too many people.
Although I do see significant value in that point, I do
> From: Stephen Hemminger [mailto:step...@networkplumber.org]
> Sent: Saturday, 2 April 2022 02.54
>
> Semantics and naming should be the same as Linux kernel or you risk
> having to reeducate too many people.
Although I do see significant value in that point, I don't consider the Linux
kernel A
On Thu, 31 Mar 2022 13:51:32 +
Mattias Rönnblom wrote:
> >
> > Regarding naming, you should also consider renaming
> > rte_seqlock_write_begin/end() to rte_seqlock_write_lock/unlock(),
> > following the naming convention of the other locks. This could
> > prepare for future extensions, such
" ,
> "konstantin.anan...@intel.com" ,
> "m...@smartsharesystems.com" ,
> "step...@networkplumber.org" Subject:
> Re: [PATCH v2] eal: add seqlock Date: Thu, 31 Mar 2022 16:53:00 +0200
> User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:91.0) Gecko/20100101
> Thunderbird
On Wed, 30 Mar 2022 16:26:02 +0200
Mattias Rönnblom wrote:
> + __atomic_store_n(&seqlock->sn, sn, __ATOMIC_RELAXED);
> +
> + /* __ATOMIC_RELEASE to prevent stores after (in program
> order)
> + * from happening before the sn store.
> + */
> + rte_atomic_thread_fence(__ATOMIC
(Thunderbird suddenly refuses to edit in plain text mode, hope the mail
gets sent as text anyway)
On 3/31/22 15:38, Mattias Rönnblom wrote:
On 2022-03-31 11:04, Ola Liljedahl wrote:
On 3/31/22 09:46, Mattias Rönnblom wrote:
On 2022-03-30 16:26, Mattias Rönnblom wrote:
Should the rte_seql
On 2022-03-31 13:44, Ola Liljedahl wrote:
>
I think lock()/unlock() should be avoided in the read operation
names, because no lock is taken during read. I like the critical region
begin()/end() names.
>>> I was following the naming convention of rte_rwlock. Isn't the seqlock
>>> jus
On 2022-03-31 11:25, Morten Brørup wrote:
>> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
>> Sent: Thursday, 31 March 2022 11.05
>>
>> On 3/31/22 09:46, Mattias Rönnblom wrote:
>>> On 2022-03-30 16:26, Mattias Rönnblom wrote:
A sequence lock (seqlock) is synchronization primitive which a
On 2022-03-31 11:04, Ola Liljedahl wrote:
>
> On 3/31/22 09:46, Mattias Rönnblom wrote:
>> On 2022-03-30 16:26, Mattias Rönnblom wrote:
>>> A sequence lock (seqlock) is synchronization primitive which allows
>>> for data-race free, low-overhead, high-frequency reads, especially for
>>> data struct
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Thursday, 31 March 2022 13.44
>
>
> >>> I think lock()/unlock() should be avoided in the read operation
> >>> names, because no lock is taken during read. I like the critical
> region
> >>> begin()/end() names.
> >> I was following the
I think lock()/unlock() should be avoided in the read operation
names, because no lock is taken during read. I like the critical region
begin()/end() names.
I was following the naming convention of rte_rwlock. Isn't the seqlock
just a more scalable implementation of a reader/writer lock?
I se
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Thursday, 31 March 2022 11.39
>
> On 3/31/22 11:25, Morten Brørup wrote:
> >> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> >> Sent: Thursday, 31 March 2022 11.05
> >>
> >> On 3/31/22 09:46, Mattias Rönnblom wrote:
> >>> On 2022-0
On 3/31/22 11:25, Morten Brørup wrote:
From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
Sent: Thursday, 31 March 2022 11.05
On 3/31/22 09:46, Mattias Rönnblom wrote:
On 2022-03-30 16:26, Mattias Rönnblom wrote:
A sequence lock (seqlock) is synchronization primitive which allows
for data-r
> From: Ola Liljedahl [mailto:ola.liljed...@arm.com]
> Sent: Thursday, 31 March 2022 11.05
>
> On 3/31/22 09:46, Mattias Rönnblom wrote:
> > On 2022-03-30 16:26, Mattias Rönnblom wrote:
> >> A sequence lock (seqlock) is synchronization primitive which allows
> >> for data-race free, low-overhead,
On 3/31/22 09:46, Mattias Rönnblom wrote:
On 2022-03-30 16:26, Mattias Rönnblom wrote:
A sequence lock (seqlock) is synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, especially for
data structures shared across many cores and which are updated with
On 2022-03-30 16:26, Mattias Rönnblom wrote:
> A sequence lock (seqlock) is synchronization primitive which allows
> for data-race free, low-overhead, high-frequency reads, especially for
> data structures shared across many cores and which are updated with
> relatively infrequently.
>
>
Some qu
A sequence lock (seqlock) is synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, especially for
data structures shared across many cores and which are updated with
relatively infrequently.
A seqlock permits multiple parallel readers. The variant of seqloc
21 matches
Mail list logo
