CXL, or Compute Express Link, is one of those acronyms that has gone from research curiosity to a line item on server spec sheets in a remarkably short time - and most buyers have never had it explained plainly. In one sentence: CXL is a high-speed interconnect that lets a processor talk to memory and accelerators outside its own sockets as if they were local, with cache coherence, over the PCIe physical layer. That capability quietly rewrites assumptions that have held for decades - that memory is fixed to a server, and that accelerators live in one box. This is the no-jargon guide to what CXL is, the three protocols inside it, the device types, and why it matters.
The problem CXL solves
Two long-standing frustrations sit behind CXL. The first is stranded memory: every server is bought with its own DRAM, sized for peak, mostly idle, and impossible to share - so an estate carries far more memory than it ever uses at once, and memory is among the priciest components in a server. The second is that PCIe, the standard way to attach devices, was never coherent: a CPU and a PCIe device do not share a consistent view of memory, so passing data between them means copying it back and forth, which is slow and wasteful for tightly-coupled work.
CXL tackles both. It rides on the PCIe physical layer - same slots, same electrical foundation - but adds cache coherence, so a processor and an attached device share a consistent view of memory and can work on the same data without constant copying. That single change is what lets memory and accelerators become shared, fabric-attached resources rather than fixed per-server inventory.
The three protocols: CXL.io, CXL.cache, CXL.mem
CXL is really three sub-protocols running over the same link, and understanding them demystifies the whole thing. CXL.io is the foundation - essentially PCIe-equivalent functionality for discovery, configuration and basic I/O, so every CXL device speaks it. CXL.cache lets an attached device cache the host's memory coherently, which matters for accelerators that need fast, consistent access to data the CPU also touches. CXL.mem lets the host access memory attached to a device as if it were its own system memory - this is the protocol behind memory expansion and pooling, and the one driving most of the excitement.
Different devices use different combinations of the three, which is exactly how CXL classifies them into types. You do not need to implement any of this yourself - but knowing that .mem is the memory protocol and .cache is the coherent-accelerator protocol makes every CXL product description suddenly readable.
- •CXL.io - PCIe-equivalent discovery, configuration and basic I/O; the common foundation
- •CXL.cache - lets a device coherently cache host memory; for tightly-coupled accelerators
- •CXL.mem - lets the host use device-attached memory as system memory; behind expansion and pooling
The three device types
CXL devices come in three types defined by which protocols they use. A Type 1 device is an accelerator with no large local memory of its own that needs coherent access to host memory - it uses CXL.io and CXL.cache; think smart NICs or accelerators that operate on the host's data. A Type 2 device is an accelerator with its own substantial memory - a GPU or similar - that wants two-way coherence so the host and the accelerator can share each other's memory; it uses all three protocols. A Type 3 device is a memory device - a memory expander or pool - that adds capacity or bandwidth to the host; it uses CXL.io and CXL.mem.
Type 3 is the one most server buyers will meet first, because memory expansion is the earliest, most concrete CXL use case: a device in a CXL slot that gives a host more memory capacity or bandwidth than its DIMM slots allow. Type 2 matters for the AI and accelerator world, where coherent host-accelerator memory sharing is valuable. Plan accelerators that may use CXL with our GPU and accelerators guidance.
From expansion to pooling: the topology
CXL's uses scale up in ambition. The simplest is memory expansion: one Type 3 device adding memory to one host - useful today and entirely undramatic operationally. The bigger idea is memory pooling: a shared pool of memory that several hosts can be allocated capacity from, so instead of buying every server for its individual peak you provision a common pool and hand out capacity where it is needed, cutting the stranded-memory waste across the estate. Further out, CXL switching connects many hosts and devices into a fabric where memory and accelerators become composable - assigned to workloads dynamically.
These tiers arrive in sequence - expansion now, pooling emerging, large-scale fabrics on the horizon - and that adoption curve, plus how to buy for it without over-investing, is the subject of PCIe 6.0 and CXL memory pooling. The key idea is that CXL turns memory from a fixed per-server quantity into something more like a shared utility.
What it means for a server buyer today
For most buyers in the near term, CXL means two practical things. First, memory expansion is a real, available option where a workload needs more memory capacity or bandwidth than a platform's DIMM slots provide - a concrete tool, not a future promise. Second, and more importantly, it is a reason to favour CXL-capable platforms on your next refresh so you keep the door open to pooling and composition as they mature, rather than locking yourself out of a direction the whole industry is moving in.
You do not need to re-architect around CXL today, and most workloads are well served by conventional DIMMs - but you should understand it and buy with it in mind. When you are specifying servers, we make sure the platform has the CXL support and PCIe headroom to age well; start from our server configuration service, and size conventional memory sensibly with our memory and RAM guidance.