ouroboros/src/ipcpd/unicast/fa.h, branch master

build: Update copyright to 2026

2026-02-18T06:54:56+00:00

Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Replace rdrbuff with a proper slab allocator

2026-01-26T06:50:33+00:00

This is a first step towards the Secure Shared Memory (SSM) infrastructure for Ouroboros, which will allow proper resource separation for non-privileged processes. This replaces the rdrbuff (random-deletion ring buffer) PoC allocator with a sharded slab allocator for the packet buffer pool to avoid the head-of-line blocking behaviour of the rdrb and reduce lock contention in multi-process scenarios. Each size class contains multiple independent shards, allowing parallel allocations without blocking. - Configurable shard count per size class (default: 4, set via SSM_POOL_SHARDS in CMake). The configured number of blocks are spread over the number of shards. As an example: SSM_POOL_512_BLOCKS = 768 blocks total These 768 blocks are shared among 4 shards (not 768 × 4 = 3072 blocks) - Lazy block distribution: all blocks initially reside in shard 0 and naturally migrate to process-local shards upon first allocation and subsequent free operations - Fallback with work stealing: processes attempt allocation from their local shard (pid % SSM_POOL_SHARDS) first, then steal from other shards if local is exhausted, eliminating fragmentation while maintaining low contention - Round-robin condvar signaling: blocking allocations cycle through all shard condition variables to ensure fairness - Blocks freed to allocator's shard: uses allocator_pid to determine target shard, enabling natural load balancing as process allocation patterns stabilize over time Maintains existing robust mutex semantics including EOWNERDEAD handling for dead process recovery. Internal structures exposed in ssm.h for testing purposes. Adds some tests (pool_test, pool_sharding_test.c. etc) verifying lazy distribution, migration, fallback stealing, and multiprocess behavior. Updates the ring buffer (rbuff) to use relaxed/acquire/release ordering on atomic indices. The ring buffer requires the (robust) mutex to ensure cross-structure synchronization between pool buffer writes and ring buffer index publication. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

lib: Revise app flow allocation

2024-02-23T15:41:37+00:00

This revises the application flow allocator to use the flow_info struct/message between the components. Revises the messaging to move the use protocol buffers to its own source (serdes-irm). Adds a timeout to the IRMd flow allocator to make sure flow allocations don't hang forever (this was previously taken care of by the sanitize thread). Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Update licenses to 2024

2024-01-13T09:20:14+00:00

Slow but steady. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Update copyright to 2023

2023-02-13T20:10:10+00:00

2022 was a rather slow year... Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Update copyright to 2022

2022-04-03T16:01:02+00:00

Growing pains. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

build: Update email addresses

2021-01-03T10:57:05+00:00

The ugent email addresses are shut down, updated to Ouroboros mail addresses. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

2021-01-03T10:56:28+00:00

Happy New Year, Ouroboros! Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Use 64-bit flow endpoint IDs for DT

2020-12-07T17:39:48+00:00

The EIDs are now 64-bit. This makes it a tad harder to guess them (think of port scanning). The implementation has only the most significant 32 bits random to quickly map EIDs to N+1 flows. While this is equivalent to a random cookie as a check on flows, the rationale is that valid endpoint IDs should be pretty hard to guess (and thus be 64-bit random at least). Ideally one would use content-addressable memory for this kind of mapping. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders

ipcpd: Remove DT-FA bypass on receiver side

2020-12-07T17:39:41+00:00

The DT will now post all packets for N+1 flows through the flow allocator component. This means that N+1 flows can be monitored through the flow allocator stats, and N-1 flows through the DT stats. The DT component still keeps stats for the local components (FA and DHT), but this can be removed once the DHT has its own RIB output. The flow allocator show statistics for Sent packets: total packets that were presented for sending on this specific flow Send failed: packets that were unable to be sent Received packets: total packets that were presented by the DT component on this specific flow Received failed: packets that were unable to be delivered These stats are presented as both packet counts and byte counts. To know how many were successful, the values for failed need to be subtracted from the values for total. Signed-off-by: Dimitri Staessens Signed-off-by: Sander Vrijders