Multi-core: single-flow crypto+FEC worker-pool (regime B, deferred) #28

New issue

Open

opened 2026-07-03 19:11:10 +00:00 by vxfemboy · 0 comments

vxfemboy commented

2026-07-03 19:11:10 +00:00

(Migrated from github.com)

Design context: docs/superpowers/specs/2026-07-03-multicore-sharding-design.md (regime B, deferred alternative).

The recommended multi-core model (#10) is per-peer engine sharding — it scales aggregate throughput across many peers but a single peer's flow stays on one core. For a fat single point-to-point link (one peer, multi-Gbit), the WireGuard-style answer is to parallelize the crypto+FEC stage across cores: distribute inner packets to worker cores by inner-5-tuple hash, encrypt/FEC in parallel, share the UDP socket, reorder per-flow.

Bigger change — reintroduces cross-thread coordination (queues, per-flow ordering, shared/per-core send) that the Phase A single-thread design deliberately removed. Deferred until a single-link multi-Gbit bottleneck is actually demonstrated (most mesh-VPN throughput is aggregate → regime A suffices).

**Design context:** `docs/superpowers/specs/2026-07-03-multicore-sharding-design.md` (regime B, deferred alternative). The recommended multi-core model (#10) is per-peer engine sharding — it scales *aggregate* throughput across many peers but a *single* peer's flow stays on one core. For a fat single point-to-point link (one peer, multi-Gbit), the WireGuard-style answer is to parallelize the crypto+FEC stage across cores: distribute inner packets to worker cores by inner-5-tuple hash, encrypt/FEC in parallel, share the UDP socket, reorder per-flow. Bigger change — reintroduces cross-thread coordination (queues, per-flow ordering, shared/per-core send) that the Phase A single-thread design deliberately removed. **Deferred until a single-link multi-Gbit bottleneck is actually demonstrated** (most mesh-VPN throughput is aggregate → regime A suffices).