ring: introduce staged ordered ring

Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues
with multiple processing 'stages'.
It is based on conventional DPDK rte_ring, re-uses

ring: introduce staged ordered ring

Staged-Ordered-Ring (SORING) provides a SW abstraction for 'ordered' queues
with multiple processing 'stages'.
It is based on conventional DPDK rte_ring, re-uses many of its concepts,
and even substantial part of its code.
It can be viewed as an 'extension' of rte_ring functionality.
In particular, main SORING properties:
- circular ring buffer with fixed size objects
- producer, consumer plus multiple processing stages in the middle.
- allows to split objects processing into multiple stages.
- objects remain in the same ring while moving from one stage to the other,
initial order is preserved, no extra copying needed.
- preserves the ingress order of objects within the queue across multiple
stages, i.e.:
at the same stage multiple threads can process objects from the ring in
any order, but for the next stage objects will always appear in the
original order.
- each stage (and producer/consumer) can be served by single and/or
multiple threads.
- number of stages, size and number of objects in the ring are
configurable at ring initialization time.

Data-path API provides four main operations:
- enqueue/dequeue works in the same manner as for conventional rte_ring,
all rte_ring synchronization types are supported.
- acquire/release - for each stage there is an acquire (start) and
release (finish) operation.
after some objects are 'acquired' - given thread can safely assume that
it has exclusive possession of these objects till 'release' for them is
invoked.
Note that right now user has to release exactly the same number of
objects that was acquired before.
After 'release', objects can be 'acquired' by next stage and/or dequeued
by the consumer (in case of last stage).

Expected use-case: applications that uses pipeline model
(probably with multiple stages) for packet processing, when preserving
incoming packet order is important. I.E.: IPsec processing, etc.

Signed-off-by: Eimear Morrissey <eimear.morrissey@huawei.com>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

ring: make dump function more verbose

The current rte_ring_dump function uses the generic rte_ring_headtail
structure to access head/tail positions. This is incorrect for the RTS
case where the head

ring: make dump function more verbose

The current rte_ring_dump function uses the generic rte_ring_headtail
structure to access head/tail positions. This is incorrect for the RTS
case where the head is stored in a different offset in the union of
structs. Switching to a separate function for each sync type allows
to dump correct head/tail values and extra metadata.

Signed-off-by: Eimear Morrissey <eimear.morrissey@huawei.com>
Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

ring: make copying functions generic

Note upfront: that change doesn't introduce any functional
or performance changes.
It is just a code-reordering for:
- improve code modularity and re-usability

ring: make copying functions generic

Note upfront: that change doesn't introduce any functional
or performance changes.
It is just a code-reordering for:
- improve code modularity and re-usability
- ability in future to re-use the same code to introduce new functionality

There is no real need for enqueue_elems()/dequeue_elems()
to get pointer to actual rte_ring structure, instead it is enough to pass
a pointer to actual elements buffer inside the ring.
In return, we'll get a copying functions that could be used for other
queueing abstractions that do have circular ring buffer inside.

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

ring: deduplicate move head functions

Note upfront: that change doesn't introduce any functional or
performance changes.
It is just a code-reordering for:
- code deduplication
- ability in future

ring: deduplicate move head functions

Note upfront: that change doesn't introduce any functional or
performance changes.
It is just a code-reordering for:
- code deduplication
- ability in future to re-use the same code to introduce new functionality

For each sync mode corresponding move_prod_head() and
move_cons_head() are nearly identical to each other,
the only differences are:
- do we need to use a @capacity to calculate number of entries or not.
- what we need to update (prod/cons) and what is used as
read-only counterpart.
So instead of having 2 copies of nearly identical functions,
introduce a new common one that could be used by both functions:
move_prod_head() and move_cons_head().

As another positive thing - we can get rid of referencing whole rte_ring
structure in that new common sub-function.

Signed-off-by: Konstantin Ananyev <konstantin.ananyev@huawei.com>
Acked-by: Morten Brørup <mb@smartsharesystems.com>
Acked-by: Stephen Hemminger <stephen@networkplumber.org>

show more ...

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 ...

version: 24.11-rc0

Start a new release cycle with empty release notes.

The ABI version becomes 25.0.
The map files are updated to the new ABI major number (25).
The ABI exceptions are dropped and C

version: 24.11-rc0

Start a new release cycle with empty release notes.

The ABI version becomes 25.0.
The map files are updated to the new ABI major number (25).
The ABI exceptions are dropped and CI ABI checks are disabled because
compatibility is not preserved.

Signed-off-by: David Marchand <david.marchand@redhat.com>
Acked-by: Thomas Monjalon <thomas@monjalon.net>

show more ...