Skip to content

analyze: IOSQE_CQE_SKIP_SUCCESS for fire-and-forget ops (cancels now, close-direct later) #105

Description

@MDA2AV

Severity: low / enhancement — analysis first; the win is micro today but grows with #91.

What it is

IOSQE_CQE_SKIP_SUCCESS (SQE flag 1 << 6, kernel 5.17+): a successfully-completing op posts no CQE; failures still post. For fire-and-forget ops it removes one CQE reap + dispatch per op.

Where it fits today

  • ASYNC_CANCEL SQEs — the only current candidate. Cancel completions are already ignored (case KindCancel: return;Reactor.Loop.SharedRing.cs#L177-L178), so skipping the success CQE is pure savings. Note cancels frequently "fail" benignly (-ENOENT target already completed, -EALREADY) — those still post and stay ignored; that's fine.

Where it must never be used

recv (multishot — CQEs are the data path), all sends (completions drive WriteHead, partial-send resubmit, CompleteFlush, ZC notifs), accept, the eventfd wake poll, and OP_TIMEOUT (its normal completion is -ETIME, a failure code, so skip changes nothing and only invites confusion).

Where it gets interesting later

Suggested analysis before implementing

  1. Add per-kind CQE counters (observability: per-reactor counters (ENOBUFS, overflows, accepts, sheds, pool hit rate) #101) and measure what fraction of reaped CQEs are ignorable — sizes the win with data.
  2. Feature-gate: on pre-5.17 kernels the flag yields -EINVAL per op; probe once at startup and fall back to plain SQEs.
  3. Verify flag interactions on the target kernel (notably with linked SQEs / drain semantics) before enabling anywhere near a chain.
  4. Invariant to preserve: nothing in the runtime may wait on or count a completion from a skipped op. Today cancels have no such accounting — keep it that way, and document the rule.

Metadata

Metadata

Assignees

No one assigned

    Labels

    Projects

    No projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions