RDMA completion, ordering, and buffer ownership
Follow registered memory through submitted work and distinguish local completion from remote application consumption.
On this page
The question for today
What you’ll understand
- Separate memory registration and access keys from application authorization.
- Explain buffer lifetime through asynchronous submission and completion.
- Distinguish transport completion, remote notification, and application processing.
Remote Direct Memory Access moves some communication work into the network interface and allows specified operations on registered memory. Removing a conventional copy or kernel path does not remove ownership and synchronization requirements. A buffer can remain in use after submission returns, and a completion can mean less than the application assumes. Reason from the exact transport, operation, queue, and memory-visibility contract rather than treating RDMA as one universal remote-store primitive.
Registration grants a bounded capability
Registration associates a memory region with permissions and keys used by the interface to validate access. Local and remote operations use the appropriate keys and addresses within allowed bounds. The region's lifetime must cover outstanding operations, and registration costs or pinned-resource limits belong in the capacity budget. A valid key does not determine which business user should access data; application authentication and authorization still decide who receives capabilities and for how long.
An RDMA write, an RDMA read, and a send/receive exchange have different participation requirements. An ordinary write can place data into permitted remote memory without producing the same remote receive completion as a send; write-with-immediate has an explicit notification behavior and receive-resource requirements. Queue-pair transport modes also differ in reliability and supported operations. Name the exact operation instead of assuming every verbs call automatically wakes the remote application with a usable message.
Completion is an ownership boundary with scope
Posting work successfully means it was accepted for execution, not that its source buffer can immediately be overwritten. The application must observe the relevant successful completion or another documented retirement guarantee before reusing storage still needed by the operation. Error completions and queue teardown need explicit handling. Inline sends have distinct source-buffer semantics when supported, so never generalize that exception to arbitrary registered operations or to memory that remote peers may still access.
A local successful completion can establish the operation's documented local reuse condition and, for a reliable transport, associated transport guarantees. It does not prove the remote application has polled, validated, or consumed the result, nor that bytes are durably stored. Ordering may hold for specified operations on a queue while not extending across independent queues, different memory agents, or CPU/GPU visibility without further rules. Build an explicit publication and acknowledgment protocol for the application's stronger requirement.
Bound outstanding work and reclaim deliberately
Track every live region and operation through normal completion, cancellation, and connection failure. A ring of buffers is safe only if reuse waits for the correct generation's retirement; wrapping an index does not prove the previous operation finished. Batching completions can reduce polling overhead but makes ownership bookkeeping more important. Benchmark registration, warm steady transfers, and teardown separately when the production path pays different subsets of those costs, and preserve end-to-end correctness checks.
The cache lab is a limited state-history contrast, not an RDMA model. Reset and set both C=4, s=4, predict four misses and twelve hits in its initial sixteen requests, then Step to add a hit. The empty-start LRU model tracks address identifiers, capped at 4096 requests. It has no operations, registration keys, completions, or asynchronous ownership. Use the trace to explain why a numerical slot index alone cannot establish a buffer's generation or retirement, then describe the missing lifecycle state explicitly.
Work it through
A buffer ring that must not wrap early
A sender reserves eight 64 KiB source buffers, permits one outstanding transfer per buffer, and cannot reuse a buffer until its relevant successful completion. Six transfers remain outstanding.
Each buffer is 65,536 bytes, so eight buffers reserve 524,288 bytes, or 512 KiB of source payload. Registration and completion metadata are additional.
Six live transfers own 393,216 bytes, or 384 KiB. Only two buffers are immediately eligible for new work under the stated one-operation-per-buffer rule.
If the producer posts three more operations without waiting or allocating another safe buffer, it must violate the eight-slot bound or reuse a still-owned slot. A remote business-level acknowledgment may be required for additional semantics, but cannot be inferred from a local completion alone.
A bounded buffer ring needs lifecycle accounting. Index arithmetic and submission success cannot establish safe reuse or remote consumption.
The living notebook
Explore the model
Interactive lab · cache
A slot number is not a completion
Reset and set C=4, s=4; predict four misses and twelve hits at t=0, then Step to add one hit. This capped 4096-request LRU address trace is only a history contrast, not an RDMA queue, buffer-lifetime model, or completion simulator.
- Hits / requests
- 0 / 16
- Hit rate
- 0%
- Address-stream period
- 16 addresses
A fully associative LRU cache starts empty and requests address (i·s) mod 16. Hits move an address to the newest position; misses evict the oldest when full. Playback starts with 16 requests and adds two per second, capped at 4096 explicitly simulated requests. This toy stream is not a processor-cache benchmark. Parameter changes pause playback and recompute the model at the current elapsed time. Reset restores both parameters and returns time to zero. Playback starts paused. Adjust either parameter, then choose Play or Step.
Look forAn asynchronous buffer needs explicit ownership and generation state beyond its numerical slot address.
Pause & reason
Check your understanding
Your turn
Try it yourself
A producer sustains 1,000 operations/s, with each 64 KiB buffer owned for an assumed fixed 10 ms. Estimate the minimum steady number of concurrently owned buffers under evenly spaced work, then name a reason to provision more.
Take a moment to make a prediction or work it out on paper. Open a hint when you need one.
Give me a hint
Multiply rate by ownership duration, using compatible seconds.
Compare with the solution
The ideal occupancy is 1,000×0.01=10 buffers, holding 640 KiB of payload. This is a deterministic steady estimate, not a safe maximum under real latency variation. Bursts, slower completions, batching, and failure handling can require extra headroom or backpressure. The reuse rule remains tied to retirement, regardless of how many buffers are provisioned.
Keep the idea
Take it with you
- Registration and keys define bounded memory access, not business authorization.
- Submission, local completion, remote visibility, and application consumption differ.
- Safe reuse requires the exact operation's documented ownership and ordering rules.
Read further
Original sources and deeper explanations to follow at your own pace.
Optional progress, saved in this browser when available. Revisit any lesson at any time.
Lesson not marked complete.