GSO for the ARQ-retransmit egress path (currently non-GSO) #30

New issue

Open

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

vxfemboy commented

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

(Migrated from github.com)

Follow-up to #24 (FEC-safe GSO via fate tags). GSO batching was wired into the TUN-egress path only (handle_dispatch_tun → fate-tagged pending_gso). The ARQ-retransmit egress (handle_dispatch_udp, DispatchOut::Udp/Both) still sends per-datagram (allow_gso=false) because that batch already mixes symbols from multiple different objects (the retx buffer) and pre-dates the fate-tag mechanism.

Apply the same EgressDatagram { fate, bytes } fate-tagging to the retransmit path so retx sends can coalesce safely (≤1 datagram per fate per skb). Low priority — retx volume is small — but flagged so the fate-tag invariant is applied uniformly if/when it matters. See the "Risks" table in docs/superpowers/specs/2026-07-02-uring-gso-fate-tags-design.md.

Follow-up to #24 (FEC-safe GSO via fate tags). GSO batching was wired into the **TUN-egress** path only (`handle_dispatch_tun` → fate-tagged `pending_gso`). The **ARQ-retransmit** egress (`handle_dispatch_udp`, `DispatchOut::Udp`/`Both`) still sends per-datagram (`allow_gso=false`) because that batch already mixes symbols from multiple different objects (the retx buffer) and pre-dates the fate-tag mechanism. Apply the same `EgressDatagram { fate, bytes }` fate-tagging to the retransmit path so retx sends can coalesce safely (≤1 datagram per fate per skb). Low priority — retx volume is small — but flagged so the fate-tag invariant is applied uniformly if/when it matters. See the "Risks" table in `docs/superpowers/specs/2026-07-02-uring-gso-fate-tags-design.md`.