Data-plane throughput pass: batched I/O + zero-repair FEC bypass #2
No reviewers
Labels
No labels
bug
documentation
duplicate
enhancement
good first issue
help wanted
invalid
question
wontfix
No milestone
No project
No assignees
1 participant
Notifications
Due date
No due date set.
Dependencies
No dependencies set
Reference
femboy/yip!2
Loading…
Reference in a new issue
No description provided.
Delete branch "data-plane-throughput-pass"
Deleting a branch is permanent. Although the deleted branch may continue to exist for a short time before it actually gets removed, it CANNOT be undone in most cases. Continue?
A measurement-driven optimization pass on the yipd data-plane hot path. Spec + plan committed; executed as 6 reviewed tasks.
What landed (no wire-format change — netns ping 3/3 throughout)
sendmmsg; ingress reads bursts viarecvmmsg(MSG_WAITFORONE). yipd now uses yip-io'sPlainIoinstead of a rawUdpSocket.SO_SNDBUF/SO_RCVBUFvia a yip-ioset_socket_buffershelper. yipd is now#![forbid(unsafe_code)];libcpinned exactly.yip-transport) — skips the ~24 µsEncoder::newsolve, emitting source symbols byte-identically to the encoder (verified across 13 object sizes in the final review).Honest verdict (see
crates/yip-bench/README.md)Clean-link single-stream TCP ~220–285 Mbit/s — no regression. The FEC-encode bypass is dormant: the controller's
repair_countfloors atmax(1), so it never requests zero repair. That floor is load-bearing until the daemon feeds observed loss back to the controller (deferred ARQ/feedback) — dropping repair to zero without that would disable FEC entirely. So the clean-link win (skip encode + halve per-packet datagram count) is unlocked by the adaptive loss-feedback loop (the next milestone), not this pass alone. This pass shipped the plumbing and a ready, tested bypass.Review
Per-task reviews + a final whole-branch opus review: READY TO MERGE, no Critical/Important findings; cumulative
unsafe(sendmmsg/recvmmsg/setsockopt) verified sound, no network-input panic paths.🤖 Generated with Claude Code