hesela.devI/O completion polling
I/O completion polling checks for finished I/O requests in software instead of relying on an interrupt to initiate each completion check.
Polling need not mean waiting continuously for one request. SPDK's spdk_nvme_qpair_process_completions() handles ready completions and returns without waiting for outstanding commands to finish; a successful call can report zero completions. Applications can schedule further checks between other work [1].
That API requires one thread at a time to use a queue pair. Its max_completions argument limits the number of completions processed per call; zero means no such limit, not a request to wait until every outstanding command completes [1].
Polling and interrupt-assisted operation are not universally exclusive. SPDK also documents interrupt-capable PCIe and RDMA queue pairs, restricted to its primary process; after wakeup, software must still process completions. Check the transport and configuration rather than assuming every SPDK deployment disables interrupts [2].
A lower interrupt count is not a complete performance result. Tai et al. compare completion policies using latency, throughput and CPU cost; their calibrated-interrupt prototype emulates device notification on dedicated cores while executing real SSD I/O. Its results do not establish a universal winner for production workloads [3].
Relations
Citations
- SPDK: spdk_nvme_qpair_process_completions API contract
- SPDK: NVMe Interrupt Mode, supported transports and operational notes
- Tai et al., Optimizing Storage Performance with Calibrated Interrupts, OSDI 2021, sections 2, 4.2.1 and 5.1
Sources & caveats
- Definition concerns completion detection, not readiness polling, command submission or device health polling.
- SPDK documentation checked on 2026-10-20; support depends on the implementation, transport and configuration.
- No device benchmark, CPU-usage comparison or universal performance advantage is claimed.