From: Honnappa Nagarahalli <Honnappa.Nagarahalli@arm.com>
To: "Mattias Rönnblom" <hofors@lysator.liu.se>,
"dev@dpdk.org" <dev@dpdk.org>
Cc: "thomas@monjalon.net" <thomas@monjalon.net>,
David Marchand <david.marchand@redhat.com>,
"onar.olsen@ericsson.com" <onar.olsen@ericsson.com>,
nd <nd@arm.com>,
"konstantin.ananyev@intel.com" <konstantin.ananyev@intel.com>,
"mb@smartsharesystems.com" <mb@smartsharesystems.com>,
"stephen@networkplumber.org" <stephen@networkplumber.org>,
Ola Liljedahl <Ola.Liljedahl@arm.com>, nd <nd@arm.com>
Subject: RE: [PATCH v3] eal: add seqlock
Date: Sun, 3 Apr 2022 17:27:48 +0000 [thread overview]
Message-ID: <DBAPR08MB58144CD8E7F1963F1DE8018298E29@DBAPR08MB5814.eurprd08.prod.outlook.com> (raw)
In-Reply-To: <7fa75549-c0db-a206-f642-69235bb7a3fb@lysator.liu.se>
<snip>
> >> a/app/test/test_seqlock.c b/app/test/test_seqlock.c new file mode
> >> 100644 index 0000000000..54fadf8025
> >> --- /dev/null
> >> +++ b/app/test/test_seqlock.c
> >> @@ -0,0 +1,202 @@
> >> +/* SPDX-License-Identifier: BSD-3-Clause
> >> + * Copyright(c) 2022 Ericsson AB
> >> + */
> >> +
> >> +#include <rte_seqlock.h>
> >> +
> >> +#include <rte_cycles.h>
> >> +#include <rte_malloc.h>
> >> +#include <rte_random.h>
> >> +
> >> +#include <inttypes.h>
> >> +
> >> +#include "test.h"
> >> +
> >> +struct data {
> >> + rte_seqlock_t lock;
> >> +
> >> + uint64_t a;
> >> + uint64_t b __rte_cache_aligned;
> >> + uint64_t c __rte_cache_aligned;
> >> +} __rte_cache_aligned;
> >> +
> >> +struct reader {
> >> + struct data *data;
> >> + uint8_t stop;
> >> +};
> >> +
> >> +#define WRITER_RUNTIME (2.0) /* s */
> >> +
> >> +#define WRITER_MAX_DELAY (100) /* us */
> >> +
> >> +#define INTERRUPTED_WRITER_FREQUENCY (1000) #define
> >> +WRITER_INTERRUPT_TIME (1) /* us */
> >> +
> >> +static int
> >> +writer_run(void *arg)
> >> +{
> >> + struct data *data = arg;
> >> + uint64_t deadline;
> >> +
> >> + deadline = rte_get_timer_cycles() +
> >> + WRITER_RUNTIME * rte_get_timer_hz();
> >> +
> >> + while (rte_get_timer_cycles() < deadline) {
> >> + bool interrupted;
> >> + uint64_t new_value;
> >> + unsigned int delay;
> >> +
> >> + new_value = rte_rand();
> >> +
> >> + interrupted =
> >> rte_rand_max(INTERRUPTED_WRITER_FREQUENCY) == 0;
> >> +
> >> + rte_seqlock_write_lock(&data->lock);
> >> +
> >> + data->c = new_value;
> >> +
> >> + /* These compiler barriers (both on the test reader
> >> + * and the test writer side) are here to ensure that
> >> + * loads/stores *usually* happen in test program order
> >> + * (always on a TSO machine). They are arrange in such
> >> + * a way that the writer stores in a different order
> >> + * than the reader loads, to emulate an arbitrary
> >> + * order. A real application using a seqlock does not
> >> + * require any compiler barriers.
> >> + */
> >> + rte_compiler_barrier();
> > The compiler barriers are not sufficient on all architectures (if the intention
> is to maintain the program order).
> >
>
> The intention is what is described in the comment (i.e., to make it likely, but
> no guaranteed, that the stores will be globally visible in the program order).
>
> The reason I didn't put in a release memory barrier, was that it seems a little
> intrusive.
>
> Maybe I should remove these compiler barriers. They are also intrusive in the
> way may prevent some compiler optimizations, that could expose a seqlock
> bug. Or, I could have two variants of the tests. I don't know.
I would suggest removing the compiler barriers, leave it to the CPU to do what it can do.
>
> >> + data->b = new_value;
> >> +
> >> + if (interrupted)
> >> + rte_delay_us_block(WRITER_INTERRUPT_TIME);
> >> +
> >> + rte_compiler_barrier();
> >> + data->a = new_value;
> >> +
> >> + rte_seqlock_write_unlock(&data->lock);
> >> +
> >> + delay = rte_rand_max(WRITER_MAX_DELAY);
> >> +
> >> + rte_delay_us_block(delay);
> >> + }
> >> +
> >> + return 0;
> >> +}
> >> +
<snip>
> >> +
> >> +/**
> >> + * Begin a write-side critical section.
> >> + *
> >> + * A call to this function acquires the write lock associated @p
> >> + * seqlock, and marks the beginning of a write-side critical section.
> >> + *
> >> + * After having called this function, the caller may go on to modify
> >> + * (both read and write) the protected data, in an atomic or
> >> + * non-atomic manner.
> >> + *
> >> + * After the necessary updates have been performed, the application
> >> + * calls rte_seqlock_write_unlock().
> >> + *
> >> + * This function is not preemption-safe in the sense that preemption
> >> + * of the calling thread may block reader progress until the writer
> >> + * thread is rescheduled.
> >> + *
> >> + * Unlike rte_seqlock_read_lock(), each call made to
> >> + * rte_seqlock_write_lock() must be matched with an unlock call.
> >> + *
> >> + * @param seqlock
> >> + * A pointer to the seqlock.
> >> + *
> >> + * @see rte_seqlock_write_unlock()
> >> + */
> >> +__rte_experimental
> >> +static inline void
> >> +rte_seqlock_write_lock(rte_seqlock_t *seqlock) {
> >> + uint32_t sn;
> >> +
> >> + /* to synchronize with other writers */
> >> + rte_spinlock_lock(&seqlock->lock);
> >> +
> >> + sn = seqlock->sn + 1;
> > The load of seqlock->sn could use __atomic_load_n to be consistent.
> >
>
> But why? I know it doesn't have any cost (these loads are going to be atomic
> anyways), but why use a construct with stronger guarantees than you have
> to?
Using __atomic_xxx ensures that the operation is atomic always. I believe (I am not sure) that, when not using __atomic_xxx, the compiler is allowed to use non-atomic operations.
The other reason is we are not qualifying 'sn' as volatile. Use of __atomic_xxx inherently indicate to the compiler not to cache 'sn' in a register. I do not know the compiler behavior if some operations on 'sn' use __atomic_xxx and some do not.
>
> >> +
> >> + __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_RELEASE);
> >> +}
> >> +
> >> +/**
> >> + * End a write-side critical section.
> >> + *
> >> + * A call to this function marks the end of the write-side critical
> >> + * section, for @p seqlock. After this call has been made, the
> >> +protected
> >> + * data may no longer be modified.
> >> + *
> >> + * @param seqlock
> >> + * A pointer to the seqlock.
> >> + *
> >> + * @see rte_seqlock_write_lock()
> >> + */
> >> +__rte_experimental
> >> +static inline void
> >> +rte_seqlock_write_unlock(rte_seqlock_t *seqlock) {
> >> + uint32_t sn;
> >> +
> >> + sn = seqlock->sn + 1;
> > Same here, the load of seqlock->sn could use __atomic_load_n
> >
> >> +
> >> + /* synchronizes-with the load acquire in rte_seqlock_read_lock() */
> >> + __atomic_store_n(&seqlock->sn, sn, __ATOMIC_RELEASE);
> >> +
> >> + rte_spinlock_unlock(&seqlock->lock);
> >> +}
> >> +
> >> +#ifdef __cplusplus
> >> +}
> >> +#endif
> >> +
> >> +#endif /* _RTE_SEQLOCK_H_ */
<snip>
next prev parent reply other threads:[~2022-04-03 17:28 UTC|newest]
Thread overview: 104+ messages / expand[flat|nested] mbox.gz Atom feed top
2022-03-22 16:10 DPDK seqlock Mattias Rönnblom
2022-03-22 16:46 ` Ananyev, Konstantin
2022-03-24 4:52 ` Honnappa Nagarahalli
2022-03-24 5:06 ` Stephen Hemminger
2022-03-24 11:34 ` Mattias Rönnblom
2022-03-25 20:24 ` [RFC] eal: add seqlock Mattias Rönnblom
2022-03-25 21:10 ` Stephen Hemminger
2022-03-26 14:57 ` Mattias Rönnblom
2022-03-27 14:49 ` Ananyev, Konstantin
2022-03-27 17:42 ` Mattias Rönnblom
2022-03-28 10:53 ` Ananyev, Konstantin
2022-03-28 14:06 ` Ola Liljedahl
2022-03-29 8:32 ` Mattias Rönnblom
2022-03-29 13:20 ` Ananyev, Konstantin
2022-03-30 10:07 ` [PATCH] " Mattias Rönnblom
2022-03-30 10:50 ` Morten Brørup
2022-03-30 11:24 ` Tyler Retzlaff
2022-03-30 11:25 ` Mattias Rönnblom
2022-03-30 14:26 ` [PATCH v2] " Mattias Rönnblom
2022-03-31 7:46 ` Mattias Rönnblom
2022-03-31 9:04 ` Ola Liljedahl
2022-03-31 9:25 ` Morten Brørup
2022-03-31 9:38 ` Ola Liljedahl
2022-03-31 10:03 ` Morten Brørup
2022-03-31 11:44 ` Ola Liljedahl
2022-03-31 11:50 ` Morten Brørup
2022-03-31 14:02 ` Mattias Rönnblom
2022-04-01 15:07 ` [PATCH v3] " Mattias Rönnblom
2022-04-02 0:21 ` Honnappa Nagarahalli
2022-04-02 11:01 ` Morten Brørup
2022-04-02 19:38 ` Honnappa Nagarahalli
2022-04-10 13:51 ` [RFC 1/3] eal: add macro to warn for unused function return values Mattias Rönnblom
2022-04-10 13:51 ` [RFC 2/3] eal: emit warning for unused trylock return value Mattias Rönnblom
2022-04-10 13:51 ` [RFC 3/3] examples/bond: fix invalid use of trylock Mattias Rönnblom
2022-04-11 1:01 ` Min Hu (Connor)
2022-04-11 14:32 ` Mattias Rönnblom
2022-04-11 11:25 ` David Marchand
2022-04-11 14:33 ` Mattias Rönnblom
2022-04-10 18:02 ` [RFC 1/3] eal: add macro to warn for unused function return values Stephen Hemminger
2022-04-10 18:50 ` Mattias Rönnblom
2022-04-11 7:17 ` Morten Brørup
2022-04-11 14:29 ` Mattias Rönnblom
2022-04-11 9:16 ` Bruce Richardson
2022-04-11 14:27 ` Mattias Rönnblom
2022-04-11 15:15 ` [PATCH " Mattias Rönnblom
2022-04-11 15:15 ` [PATCH 2/3] eal: emit warning for unused trylock return value Mattias Rönnblom
2022-04-11 15:29 ` Morten Brørup
2022-04-11 15:15 ` [PATCH 3/3] examples/bond: fix invalid use of trylock Mattias Rönnblom
2022-04-14 12:06 ` David Marchand
2022-04-11 15:25 ` [PATCH 1/3] eal: add macro to warn for unused function return values Morten Brørup
2022-04-11 18:24 ` [RFC " Tyler Retzlaff
2022-04-03 6:10 ` [PATCH v3] eal: add seqlock Mattias Rönnblom
2022-04-03 17:27 ` Honnappa Nagarahalli [this message]
2022-04-03 18:37 ` Ola Liljedahl
2022-04-04 21:56 ` Honnappa Nagarahalli
2022-04-03 6:33 ` Mattias Rönnblom
2022-04-03 17:37 ` Honnappa Nagarahalli
2022-04-08 13:45 ` Mattias Rönnblom
2022-04-02 18:15 ` Ola Liljedahl
2022-04-02 19:31 ` Honnappa Nagarahalli
2022-04-02 20:36 ` Morten Brørup
2022-04-02 22:01 ` Honnappa Nagarahalli
2022-04-03 18:11 ` Ola Liljedahl
2022-04-03 6:51 ` Mattias Rönnblom
2022-03-31 13:51 ` [PATCH v2] " Mattias Rönnblom
2022-04-02 0:54 ` Stephen Hemminger
2022-04-02 10:25 ` Morten Brørup
2022-04-02 17:43 ` Ola Liljedahl
2022-03-31 13:38 ` Mattias Rönnblom
2022-03-31 14:53 ` Ola Liljedahl
2022-04-02 0:52 ` Stephen Hemminger
2022-04-03 6:23 ` Mattias Rönnblom
2022-04-02 0:50 ` Stephen Hemminger
2022-04-02 17:54 ` Ola Liljedahl
2022-04-02 19:37 ` Honnappa Nagarahalli
2022-04-05 20:16 ` Stephen Hemminger
2022-04-08 13:50 ` Mattias Rönnblom
2022-04-08 14:24 ` [PATCH v4] " Mattias Rönnblom
2022-04-08 15:17 ` Stephen Hemminger
2022-04-08 16:24 ` Mattias Rönnblom
2022-04-08 15:19 ` Stephen Hemminger
2022-04-08 16:37 ` Mattias Rönnblom
2022-04-08 16:48 ` Mattias Rönnblom
2022-04-12 17:27 ` Ananyev, Konstantin
2022-04-28 10:28 ` David Marchand
2022-05-01 13:46 ` Mattias Rönnblom
2022-05-01 14:03 ` [PATCH v5] " Mattias Rönnblom
2022-05-01 14:22 ` Mattias Rönnblom
2022-05-02 6:47 ` David Marchand
2022-05-01 20:17 ` Stephen Hemminger
2022-05-02 4:51 ` Mattias Rönnblom
2022-05-06 1:26 ` fengchengwen
2022-05-06 1:33 ` Honnappa Nagarahalli
2022-05-06 4:17 ` fengchengwen
2022-05-06 5:19 ` Honnappa Nagarahalli
2022-05-06 7:03 ` fengchengwen
2022-05-08 11:56 ` Mattias Rönnblom
2022-05-08 12:12 ` [PATCH v6] " Mattias Rönnblom
2022-05-08 16:10 ` Stephen Hemminger
2022-05-08 19:40 ` Mattias Rönnblom
2022-05-09 3:48 ` Stephen Hemminger
2022-05-09 6:26 ` Morten Brørup
2022-05-13 6:27 ` Mattias Rönnblom
2022-03-23 12:04 ` DPDK seqlock Morten Brørup
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=DBAPR08MB58144CD8E7F1963F1DE8018298E29@DBAPR08MB5814.eurprd08.prod.outlook.com \
--to=honnappa.nagarahalli@arm.com \
--cc=Ola.Liljedahl@arm.com \
--cc=david.marchand@redhat.com \
--cc=dev@dpdk.org \
--cc=hofors@lysator.liu.se \
--cc=konstantin.ananyev@intel.com \
--cc=mb@smartsharesystems.com \
--cc=nd@arm.com \
--cc=onar.olsen@ericsson.com \
--cc=stephen@networkplumber.org \
--cc=thomas@monjalon.net \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox;
as well as URLs for NNTP newsgroup(s).