use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

use C linkage where appropriate in headers

Assure that 'extern "C" { /../ }' do not cover files included from a
particular header file, and address minor issues resulting from this
change of order.

Dealing with C++ should delegate to the individual include file level,
rather than being imposed by the user of that file. For example,
forcing C linkage prevents __Generic macros being replaced with
overloaded static inline functions in C++ translation units.

Eliminate 'extern "C"' from files which do not declare any symbols
(e.g., only macros or struct types).

On the other hand, the headers check is too naive in assuming that all
headers must contain a 'extern "C"'. Such a check was added in commit
1ee492bdc4ff ("buildtools/chkincs: check missing C++ guards").
Since this current change results in many headers not containing such
a token, remove the check for 'extern "C"' until we have a better
implementation.

Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Signed-off-by: David Marchand <david.marchand@redhat.com>

show more ...

seqlock: promote API as stable

These were added back in 22.07 release.

Signed-off-by: Stephen Hemminger <stephen@networkplumber.org>
Acked-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>

eal: annotate spinlock, rwlock and seqlock

clang offers some thread safety checks, statically verifying that locks
are taken and released in the code.
To use those checks, the full code leading to t

eal: annotate spinlock, rwlock and seqlock

clang offers some thread safety checks, statically verifying that locks
are taken and released in the code.
To use those checks, the full code leading to taking or releasing locks
must be annotated with some attributes.

Wrap those attributes into our own set of macros.

rwlock, seqlock and the "normal" spinlock are instrumented.

Those checks might be of interest out of DPDK, but it requires that the
including application locks are annotated.
On the other hand, applications out there might have been using
those same checks.
To be on the safe side, keep this instrumentation under a
RTE_ANNOTATE_LOCKS internal build flag.

A component may en/disable this check by setting
annotate_locks = true/false in its meson.build.

Note:
Doxygen preprocessor does not understand trailing function attributes
(this can be observed with the rte_seqlock.h header).
One would think that expanding the annotation macros to a noop in
rte_lock_annotations.h would be enough (since RTE_ANNOTATE_LOCKS is not
set during doxygen processing)). Unfortunately, the use of
EXPAND_ONLY_PREDEF defeats this.

Removing EXPAND_ONLY_PREDEF entirely is not an option as it would expand
all other DPDK macros.

The chosen solution is to expand the annotation macros explicitly to a
noop in PREDEFINED.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Reviewed-by: Maxime Coquelin <maxime.coquelin@redhat.com>
Acked-by: Chenbo Xia <chenbo.xia@intel.com>

show more ...

eal: add seqlock

A sequence lock (seqlock) is a synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, suitable for
data structures shared across many cores a

eal: add seqlock

A sequence lock (seqlock) is a synchronization primitive which allows
for data-race free, low-overhead, high-frequency reads, suitable for
data structures shared across many cores and which are updated
relatively infrequently.

A seqlock permits multiple parallel readers. A spinlock is used to
serialize writers. In cases where there is only a single writer, or
writer-writer synchronization is done by some external means, the
"raw" sequence counter type (and accompanying rte_seqcount_*()
functions) may be used instead.

To avoid resource reclamation and other issues, the data protected by
a seqlock is best off being self-contained (i.e., no pointers [except
to constant data]).

One way to think about seqlocks is that they provide means to perform
atomic operations on data objects larger than what the native atomic
machine instructions allow for.

DPDK seqlocks (and the underlying sequence counters) are not
preemption safe on the writer side. A thread preemption affects
performance, not correctness.

A seqlock contains a sequence number, which can be thought of as the
generation of the data it protects.

A reader will
1. Load the sequence number (sn).
2. Load, in arbitrary order, the seqlock-protected data.
3. Load the sn again.
4. Check if the first and second sn are equal, and even numbered.
If they are not, discard the loaded data, and restart from 1.

The first three steps need to be ordered using suitable memory fences.

A writer will
1. Take the spinlock, to serialize writer access.
2. Load the sn.
3. Store the original sn + 1 as the new sn.
4. Perform load and stores to the seqlock-protected data.
5. Store the original sn + 2 as the new sn.
6. Release the spinlock.

Proper memory fencing is required to make sure the first sn store, the
data stores, and the second sn store appear to the reader in the
mentioned order.

The sn loads and stores must be atomic, but the data loads and stores
need not be.

The original seqlock design and implementation was done by Stephen
Hemminger. This is an independent implementation, using C11 atomics.

For more information on seqlocks, see
https://en.wikipedia.org/wiki/Seqlock

Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Konstantin Ananyev <konstantin.ananyev@intel.com>
Reviewed-by: Ola Liljedahl <ola.liljedahl@arm.com>
Reviewed-by: Chengwen Feng <fengchengwen@huawei.com>
Signed-off-by: Mattias Rönnblom <mattias.ronnblom@ericsson.com>

show more ...