Deferred: multi-queue throughput sharding (scale past one core)

[vxfemboy]

The single-ring io_uring busy-poll loop (#7) is single-core by design: one thread does all crypto+FEC. Its wins are latency + GSO + lock removal, NOT raw multi-Gbit throughput. Scaling throughput across cores is a separate architecture, explicitly deferred out of the io_uring milestone.

Scope (future)

• Multiple io_uring rings/threads, one per core, with flows sharded across them (e.g. by 5-tuple hash / RSS-style steering) so aggregate throughput scales with core count toward multi-Gbit.
• Per-core DataPlane state (the mutex-free DataPlane extracted in Phase A makes this feasible — each shard owns one), with careful handling of the feedback loop / ARQ / retransmit buffer per shard.
• Steering: kernel RSS + SO_REUSEPORT, or userspace demux.

Notes

• Bigger, different architecture than the latency-focused single-ring loop; only worth it once bulk throughput is a demonstrated bottleneck. yip's north-star is latency, so this is lower priority than io_uring busy-poll Phase B: UringDriver (status + remaining work) #7.
• Needs its own design → spec → plan. Depends on io_uring Phase B (io_uring busy-poll Phase B: UringDriver (status + remaining work) #7) landing first (reuses the ring/GSO/buffer machinery per shard).

[vxfemboy]

Design spec written: docs/superpowers/specs/2026-07-03-multicore-sharding-design.md (PR #32). Recommended model: per-peer engine sharding (N single-thread DataPlane engines, one per core, SO_REUSEPORT + IFF_MULTI_QUEUE, no shared state). Depends on the multi-peer data plane (sub-project #2) — a no-op for today's single connected peer. Single-flow crypto worker-pool split out as #28 (deferred).