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

New issue

Open

opened 2026-07-01 13:09:58 +00:00 by vxfemboy · 1 comment

vxfemboy commented

2026-07-01 13:09:58 +00:00

(Migrated from github.com)

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 #7.
Needs its own design → spec → plan. Depends on io_uring Phase B (#7) landing first (reuses the ring/GSO/buffer machinery per shard).

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 #7. - Needs its own design → spec → plan. Depends on io_uring Phase B (#7) landing first (reuses the ring/GSO/buffer machinery per shard).

vxfemboy commented

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

(Migrated from github.com)

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

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