Blog
Notes on RDMA, EFA, and building a remote-memory cache on AWS.
Optimizing LMCache's prefix lookup for one-sided RDMA
How LMCache's existence check works, why it does it (prefix caching), the batched contains it already uses, and how a one-sided RDMA backend folds the read address into that check and releases the GIL.
Read →
Deploy Rasa in your own AWS account with the CDK
What the stack creates, every context parameter, and the controls the console gives you, from adding a data node to draining and rotating arenas.
Read →
Connections, queue depth, and batch reads: tuning a one-sided RDMA cache
How many connections each size needed to saturate EFA (32 for 4 KiB, one from 4 MiB up), why queue depth is the cheaper knob, the security-group rule that silently drops all EFA traffic, and the write path that turned out to be CPU-bound.
Read →
How a one-sided RDMA cache stays correct without trusting the reader
No server runs on the read path. One decision makes that safe: values are immutable. Write-once removes torn and stale reads, leaving three guards: a signed descriptor, a checksum over every read, and rkey rotation as a hardware fence on the one moment memory is reused. Why the worst case is always a recompute, never a wrong value.
Read →
When the cache server writes the answer into you
One-sided reads are a pull, but a value on NVMe can't be pulled because the NIC can't fi_read block storage. Flip the direction: the client hands the node a write-key and the node RDMA-writes the value straight into the client's buffer. One round trip, the reply is the completion.
Read →
How Rasa writes: allocate, RDMA-write, commit
RDMA writes move bytes quickly. The correctness comes from allocation grants, commit ordering, signed descriptors, and not publishing half-written memory.
Read →
How Rasa reads: descriptors, bulk reads, and the cost of moving memory
One-sided reads are simple once the client has a descriptor. The work is in descriptor batching, keeping the client map small, and keeping remote memory stable.
Read →
Why mutability is hard with RDMA
One-sided reads are fast because nobody is home on the read path, which also makes changing a value in place hard: torn reads, no read-side validation, and memory you cannot safely reclaim. Why immutability is the usual answer.
Read →
Rasa architecture in one page
A system map: client SDK, Valkey control plane, data nodes, registered arenas, EFA/libfabric, and the rule we used to decide what belongs where.
Read →
SRD: the cloud-native transport under EFA
Why AWS replaced TCP and InfiniBand inside the cloud with SRD: packet spraying across many paths, out-of-order delivery, microsecond hardware retransmission in the Nitro card, and where it powers EFA, ENA Express, and EBS.
Read →
RDMA on AWS: what it is, how it works, and what makes EFA different
Kernel bypass and one-sided reads, why RDMA is hard, how it differs from a normal key/value GET, what SRD changes, and why you cannot tell from an instance name whether it supports a one-sided read.
Read →
