Understanding CXL Part 2: System Networking and Memory Ecosystem

Understanding CXL Part 2: System Networking and Memory Ecosystem

📋 Summary: Compute Express Link (CXL) has evolved from a direct CPU-to-memory expansion interface into a broader system-level interconnect technology. CXL 1.1 focused on single-host memory expansion, CXL 2.0 introduced switching and memory pooling, while CXL 3.x expands the architecture toward multi-host coherency and large-scale fabric networking. This article examines that evolution, the CXL product ecosystem, memory-vendor strategies, controller and switch silicon, and the practical limitations of CXL deployment.

CXL is no longer simply a faster way to attach another memory device to a CPU.

Since the first CXL specification was released in 2019, the technology has steadily expanded from single-host memory expansion toward shared memory resources, switching, pooling, and system-scale interconnect fabrics.

The underlying objective has remained remarkably consistent:

Put memory farther away, make memory capacity easier to scale, and allow more compute resources to access that capacity efficiently.

That evolution can be summarized as:

CXL 1.1 → Direct Attachment

CXL 2.0 → Switching and Memory Pooling

CXL 3.x → Fabric Networking and Multi-Host Coherency

Understanding this progression is essential because the commercial CXL market today sits between these generations. Type 3 memory expansion products are already being deployed, while the more ambitious CXL 3.x fabric architecture is still moving toward broader hardware adoption.

🧭 CXL 1.1: Direct Memory Expansion for a Single Host

#

The original practical CXL architecture was relatively straightforward.

A CXL device connects directly to a CPU through a standard PCIe physical interface.

The host sees the attached device as an additional memory resource, extending capacity beyond the DDR memory directly attached to the processor.

The Core Objective

#

CXL 1.1 primarily addressed a simple problem:

What happens when a server needs more memory than its CPU’s native DDR channels can provide?

Adding more conventional DDR is constrained by factors such as:

• Number of memory channels
• DIMM slots
• CPU memory-controller design
• Motherboard layout
• Electrical signaling constraints
• Maximum supported DIMM capacity

CXL provides another path.

Instead of requiring additional DDR channels, a server can attach CXL memory through the PCIe infrastructure.

The trade-off is that CXL memory generally has higher latency than local DDR.

Nevertheless, for capacity-bound workloads, adding slower memory can be considerably more useful than running out of memory altogether.

CXL 1.1 Is Fundamentally Single-Host

#

The limitation is equally important.

A CXL 1.1 memory device is fundamentally attached to one host.

There is no rack-scale memory pool where multiple servers dynamically consume the same resource.

This makes CXL 1.1 a memory expansion technology, rather than a true memory fabric.

🔀 CXL 2.0: Switching Changes the Architecture

#

CXL 2.0, released in 2020, introduced a major architectural change:

CXL switches.

Instead of connecting one memory device directly to one host, switches allow multiple hosts and CXL devices to participate in a larger topology.

This opened the door to one of CXL’s most commercially important concepts:

memory pooling.

What Is CXL Memory Pooling?

#

Consider a datacenter with hundreds or thousands of servers.

A traditional server might be configured with enough memory to handle its theoretical peak workload.

But peak memory demand may occur only occasionally.

As a result, one server could be running out of memory while another server has a large amount of unused capacity.

CXL pooling attempts to turn that stranded capacity into a shared resource.

Instead of permanently assigning all memory to individual servers, memory can be placed into a centralized pool and allocated to hosts as required.

The result is conceptually similar to virtualization:

memory becomes a resource that can be dynamically assigned instead of a permanently fixed component of each server.

CXL 2.0 Sharing Is Not Concurrent Sharing

#

This distinction is extremely important.

When CXL 2.0 is described as enabling memory “sharing,” it does not necessarily mean that multiple CPUs simultaneously access the exact same cache lines.

Instead, memory can be divided into multiple logical regions and dynamically assigned to different hosts.

A large CXL memory device can expose multiple Multi-Logical Devices (MLDs).

The Fabric Manager (FM) controls how those resources are assigned.

For example:

CXL Memory Pool
├── Chunk A → Host A
├── Chunk B → Host B
├── Chunk C → Host C
└── Chunk D → Host D

At a given moment, each chunk has a defined owner.

This avoids the complexity of allowing multiple hosts to modify the same cache line simultaneously.

🏨 Hotel Room Analogy

#

A useful analogy is a hotel.

Each host is a guest.

Each memory chunk is a hotel room.

When Guest A checks out, the room can be assigned to Guest B.

But Guest A and Guest B do not occupy the same room simultaneously.

That is broadly the model behind CXL 2.0 memory pooling.

The key benefit is therefore resource utilization, rather than true shared-memory concurrency.

Why Pooling Matters

#

This architecture can reduce the amount of memory each server needs to reserve for rare peak workloads.

Instead of purchasing enough local memory for every machine to handle its theoretical maximum independently, a datacenter can potentially maintain a shared memory reserve.

CXL therefore begins to move beyond:

“Add more memory to this server.”

toward:

“Treat memory as a datacenter-level resource.”

🌐 CXL 3.x: From Pooling to Networked Memory

#

CXL 3.0, 3.1, and 3.2 push the architecture substantially further.

The focus shifts toward two major concepts:

1. Multi-host coherent access
2. Large-scale CXL fabric networking

This is where CXL begins to resemble a complete system interconnect rather than simply a memory expansion interface.

🔗 Global Fabric Attached Memory and Multi-Host Access

#

One of the major goals of CXL 3.x is moving beyond host-exclusive memory allocation.

Instead of:

Memory Region → Host A

the architecture can support scenarios where:

             ┌── Host A
Memory Region ── Host B
             └── Host C

Multiple hosts can access the same memory resource while the hardware infrastructure maintains the required coherency mechanisms.

This concept is associated with Global Fabric Attached Memory (GFAM).

The important difference from CXL 2.0 is that memory is no longer merely rotated between hosts.

Instead, multiple hosts can participate in accessing shared memory resources.

Cache-Line-Level Coordination

#

Concurrent access introduces a much harder problem.

If Host A modifies a cache line while Host B is reading or modifying the same line, the system needs mechanisms to maintain a coherent view of memory.

This is fundamentally different from CXL 2.0’s host-exclusive partitioning model.

CXL 3.x therefore introduces a much more sophisticated coherency and fabric-management architecture.

The benefit is greater flexibility.

The cost is substantially greater hardware and software complexity.

🕸️ From Trees to Flexible CXL Fabrics

#

CXL 2.0 switching can be visualized relatively easily as a hierarchical topology:

             Host
              │
           CXL Switch
          /     |     \
      Memory  Memory  Device

CXL 3.x expands this model.

Multiple switches can be interconnected, allowing the system to form much larger networks.

One important mechanism is Port-Based Routing (PBR).

Rather than relying exclusively on a fixed hierarchical path, packets can be routed using Destination Port IDs.

This opens the door to more flexible topologies, including:

• Mesh
• Dragonfly
• 3D Torus
• Other customized fabric arrangements

The result is a fundamental architectural shift.

CXL is no longer just a point-to-point memory expansion interface.

It is becoming a network for compute, memory, and attached devices.

CXL and Accelerator Interconnects

#

At this level, CXL begins to occupy architectural territory similar to technologies such as:

• NVIDIA NVLink
• UALink
• Other accelerator and memory interconnect fabrics

However, the objectives are not identical.

CXL’s major advantage is its broader industry ecosystem and its relationship with the PCIe infrastructure already present in modern servers.

Its long-term potential is therefore not limited to connecting GPUs.

It can potentially connect:

CPU + memory + accelerators + switches + pooled resources

within a common system architecture.

🏭 The Current CXL Hardware Landscape

#

As of 2026, the commercial situation remains more conservative than the full CXL 3.x specification might suggest.

Most volume-production CXL memory hardware is still centered around CXL 2.0-era Type 3 memory expansion.

The CXL 3.x specifications are already published, but CPUs, switches, memory devices, operating systems, and management software all need to mature together before large-scale CXL 3.x deployments become widespread.

This distinction matters.

A specification can define a capability years before the commercial ecosystem is ready to deploy it at scale.

🧩 CXL Product Ecosystem: How the Major Memory Vendors Are Positioned

#

The CXL ecosystem is not being built by CPU vendors alone.

Major memory manufacturers such as Samsung, SK hynix, and Micron have all developed CXL memory products.

Their product strategies can broadly be divided into two paths:

Path 1: Standard memory expansion

Path 2: Pooling and near-memory computing

The following table summarizes the product families described in this ecosystem:

The exact product configurations vary by generation and market, but the overall direction is clear.

The industry is moving from simple memory modules toward complete memory infrastructure solutions.

📦 Path 1: Standard CXL Memory Expansion

#

The simplest CXL product is essentially a memory expansion device.

Representative products include:

• Samsung CMM-D
• SK hynix CMM-DDR5
• Micron CZ120 / CZ122

These products are generally categorized as CXL Type 3 memory devices.

From the operating system’s perspective, they appear as a slower memory resource attached through the CXL subsystem.

The fundamental operation remains load/store memory access.

Target Workloads

#

CXL Type 3 memory expansion is particularly attractive for workloads where capacity is more important than absolute memory latency.

Examples include:

• In-memory databases
• Large-scale analytics
• Key-Value caches
• LLM embedding stores
• Memory-constrained virtual machine consolidation
• Large datasets that do not fit comfortably into local DDR

For these applications, an additional tier of slower memory can be preferable to swapping data to storage.

🧮 Path 2: Memory Pooling and Near-Memory Computing

#

Memory vendors are increasingly exploring what happens after simple expansion.

Instead of treating CXL memory as a passive capacity extension, the memory device can become part of a larger system architecture.

Two important approaches are:

1. Memory pooling
2. Near-memory processing

Samsung CMM-B: Pooling Box

#

Samsung’s CMM-B (Box) approach combines multiple CMM-D memory cards with a CXL switch.

The objective is to create a larger memory pool that can be dynamically allocated across multiple hosts.

Conceptually:

Host A ─┐
Host B ─┼── CXL Switch ── CMM-D Memory
Host C ─┘

This moves the architecture from individual memory modules toward rack-level memory infrastructure.

Near-Memory Computing

#

The second direction is to place processing capabilities closer to the memory.

Examples include:

• SK hynix CMM-Ax
• Samsung CMM-H
• Samsung CXL-PNM

These approaches are related to Near-Memory Processing (NMP) and Processing-in-Memory (PIM).

The basic principle is straightforward:

Move computation closer to the data instead of repeatedly moving large amounts of data back to the CPU.

This matters because memory bandwidth can become a major bottleneck.

Suppose a workload needs to scan a huge embedding table.

Traditional processing may require:

Memory → Host CPU → Process → Memory

A near-memory architecture attempts to move more of the computation toward:

Memory → Local Processing → Final Result → Host

If the computation can dramatically reduce the amount of data returned to the CPU, system-level bandwidth pressure can also decrease.

Potential Workloads

#

Potential applications include:

• Vector embedding similarity search
• RAG workloads
• Database filtering
• Database aggregation
• LLM inference
• KV-cache processing
• Top-k selection
• Data reduction

The exact benefit depends heavily on whether an algorithm can be efficiently decomposed into operations that execute near memory.

🏗️ CXL Controllers and Switch Silicon

#

The CXL ecosystem extends beyond memory manufacturers.

A large number of companies provide controller IP, retimers, switch silicon, or other components required to construct CXL infrastructure.

Astera Labs

#

Astera Labs is one of the most visible CXL infrastructure vendors.

Its Leo family provides CXL memory controller solutions designed for server and datacenter deployments.

CXL controller silicon sits between the host and memory device and handles the protocol and memory-management requirements needed to turn the physical PCIe connection into a CXL memory link.

Marvell and Microchip

#

Marvell and Microchip are also active in the CXL ecosystem.

Microchip’s SMC 2000, for example, is used as the controller behind Micron’s CZ120 CXL memory product.

This illustrates an important point about the CXL ecosystem:

A CXL memory module does not necessarily require the memory manufacturer to design every piece of silicon itself.

Memory companies can combine:

• DRAM
• CXL controllers
• Firmware
• Board design
• Thermal management
• System software

into a complete product.

🔬 Panmnesia and CXL 3.2 Switching

#

Another interesting participant is Panmnesia, a fabless company originating from KAIST’s CAMELab.

The company is developing full-stack CXL 3.2 network switch silicon under the PANSWITCH family.

The architecture targets advanced CXL fabric topologies using mechanisms such as Port-Based Routing.

Potential supported network structures include:

• Mesh
• Dragonfly
• 3D Torus

According to the supplied roadmap, Panmnesia announced pre-release silicon distribution in April 2026 and planned commercial mass production for the second half of 2026.

If this roadmap materializes, products in this category could help bridge the gap between today’s relatively simple CXL memory expansion devices and future rack-scale CXL fabrics.

💰 Why Are Memory Manufacturers Moving Into CXL?

#

There is a larger strategic reason behind all of this activity.

CXL changes what “memory” means from a product perspective.

Traditionally, memory manufacturers primarily sell components or modules.

The CPU determines how many memory channels exist.

The motherboard determines how many modules can be installed.

The server determines the final memory capacity.

CXL changes that relationship.

1. Larger Addressable Memory Capacity

#

CPU DDR channels are physically limited.

CXL provides another interface through which memory can be attached.

This creates a new market beyond the traditional DIMM capacity ceiling.

2. Higher-Value Memory Products

#

A conventional memory module mainly differentiates through:

• Capacity
• Speed
• Power
• Reliability
• Cost

CXL products introduce additional differentiation through:

• Memory pooling
• Fabric management
• Processing near memory
• CXL switching
• System-level software
• Data-center integration

That potentially increases the value of the product beyond the DRAM chips themselves.

3. Moving Toward System Solutions

#

A company selling CXL pooling hardware is no longer simply selling memory.

It is selling part of the datacenter architecture.

Samsung’s CMM-B is a good example of this transition.

The product combines memory modules, switching, firmware, and system-level resource management into a larger infrastructure component.

HBM and CXL Represent Two Different Scaling Directions

#

There is an interesting parallel with HBM.

HBM increases memory bandwidth by bringing very wide memory interfaces physically closer to GPUs.

CXL approaches the problem from a different direction.

Instead of maximizing bandwidth at the processor package, CXL emphasizes:

capacity, flexibility, pooling, and resource sharing.

In simplified terms:

HBM → More bandwidth, closer to accelerator
CXL → More capacity, farther from CPU, more flexible allocation

These technologies are therefore complementary rather than direct substitutes.

⚠️ CXL’s Real-World Constraints

#

The architecture is promising, but CXL is not free performance.

Several practical constraints must be considered before deploying it.

⏱️ 1. CXL Memory Has Higher Latency

#

The biggest issue is straightforward:

CXL memory is slower than local DDR5.

Typical figures depend heavily on platform, device, controller, memory configuration, and workload, but a representative comparison is:

That means CXL memory can have roughly 2× to 3× the latency of local DDR5 in some configurations.

Consequently, CXL should generally be viewed as a memory tier, rather than a direct replacement for primary local memory.

A useful conceptual hierarchy is:

Tier 0 / Cache
      ↓
Local DDR5
      ↓
CXL Memory
      ↓
Persistent Memory / Storage

The exact hierarchy depends on the platform, but the principle remains:

Put latency-sensitive data close to the CPU and capacity-oriented data farther away.

🧠 2. The Software Stack Must Understand Memory Tiers

#

Hardware alone does not solve the problem.

The operating system needs to understand that not all memory has identical performance characteristics.

A CXL memory device may appear as another NUMA node, but treating every NUMA node equally would be inefficient.

The system needs to distinguish between:

• Hot pages
• Warm pages
• Cold pages

Ideally:

Hot data   → Local DDR
Warm data  → CXL memory
Cold data  → Storage

This creates opportunities for automatic page migration.

But automatic memory tiering is not perfect.

For latency-sensitive applications such as LLM inference, explicit application-level memory management may still outperform generic operating-system policies.

The application often knows more about its own data access patterns than the operating system does.

🧩 3. Type 3 Dominates the Commercial Market

#

CXL defines several device categories.

Type 1

#

Primarily provides CXL.cache functionality.

These devices can cache host memory but do not provide their own large memory capacity.

Type 2

#

Combines:

• CXL.cache
• CXL.mem

This enables devices such as accelerators to participate in coherent memory systems.

Type 3

#

Primarily provides memory expansion.

This is currently the dominant commercial CXL category.

The reason is relatively simple.

Type 3 solves a straightforward business problem:

Server memory capacity is expensive and constrained.

Type 2 devices are much more complex because they require sophisticated bidirectional coherency between compute devices and host memory.

Meanwhile, GPU vendors have historically invested heavily in proprietary accelerator interconnects such as NVIDIA’s NVLink.

As a result, the market has naturally gravitated toward Type 3 memory expansion first.

🧱 Understanding the Three CXL Protocols

#

CXL itself is not a single protocol.

It consists of three closely related protocols.

CXL.io

#

CXL.io is based on the PCIe transaction model.

It handles functions such as:

• Device discovery
• Configuration
• Register access
• I/O operations

You can think of it as the management and I/O foundation of CXL.

CXL.cache

#

CXL.cache allows a device to cache memory that belongs to the host.

This is particularly relevant for coherent accelerators.

CXL.mem

#

CXL.mem allows the host processor to access memory attached to the CXL device.

For CXL Type 3 memory expansion, this is the most important protocol.

Together:

CXL.io    → Device / I/O management
CXL.cache → Device accesses host memory coherently
CXL.mem   → Host accesses device memory

Understanding this three-protocol structure makes the differences between CXL Type 1, Type 2, and Type 3 much easier to understand.

🗺️ The CXL Evolution in One Diagram

#

The entire architectural progression can be simplified as follows:

CXL 1.1
   │
   ├── Single Host
   ├── Direct Attachment
   └── Memory Expansion
          │
          ▼
CXL 2.0
   │
   ├── CXL Switches
   ├── Multiple Hosts
   ├── Memory Pooling
   └── Dynamic Allocation
          │
          ▼
CXL 3.x
   │
   ├── Multi-Host Coherency
   ├── GFAM
   ├── Port-Based Routing
   ├── Multi-Switch Fabrics
   └── Mesh / Dragonfly / 3D Torus

This is the key architectural story behind CXL.

It is gradually transforming from:

“memory attached to a CPU”

into:

“memory attached to a system fabric.”

📋 Summary: Where CXL Is Going

#

The most important points can be summarized as follows.

The Opportunity

#

CPU DDR memory channels are limited.

PCIe provides a scalable physical infrastructure, but conventional PCIe alone does not provide the coherent memory semantics required for efficient CPU-memory integration.

CXL fills this architectural gap.

The Three Protocols

#

CXL.io    → PCIe-like I/O and configuration
CXL.cache → Device caches host memory
CXL.mem   → Host accesses device memory

The Three Device Types

#

Type 1 → Cache
Type 2 → Cache + Memory
Type 3 → Memory Expansion

Type 3 currently dominates commercial CXL memory deployments.

The Architectural Evolution

#

CXL 1.1 → Single Host / Direct Attachment
CXL 2.0 → Switching / Memory Pooling
CXL 3.x → Fabric Networking / Multi-Host Coherency

The Two Major Vendor Strategies

#

Path 1: Memory Expansion

• Samsung CMM-D
• SK hynix CMM-DDR5
• Micron CZ120 / CZ122

Path 2: Pooling and Near-Memory Computing

• Samsung CMM-B
• Samsung CMM-H
• Samsung CXL-PNM
• SK hynix CMM-Ax

The Main Challenges

#

CXL still faces three major practical constraints:

1. Higher latency than local DDR5
2. Immature software and memory-tiering policies
3. Commercial concentration around Type 3 rather than more complex Type 2 architectures

These limitations do not invalidate the architecture.

Instead, they define where CXL currently makes the most sense.

CXL is particularly attractive when capacity, utilization, and resource flexibility matter more than absolute memory latency.

🔮 What Comes Next: CXL in Real LLM Infrastructure

#

The architectural foundation is now clear.

The next question is much more practical:

What does CXL actually do inside a production AI or datacenter system?

For LLM infrastructure, several applications stand out.

KV Cache Offloading

#

Large language models can consume enormous amounts of memory through KV cache during inference.

CXL provides a potential additional memory tier for KV cache data that does not need to remain entirely in local high-bandwidth memory.

VM Consolidation Through Memory Pooling

#

Instead of provisioning every VM host for its absolute peak memory requirement, CXL pooling can potentially provide additional memory capacity on demand.

This could improve utilization across server clusters.

Hot / Warm / Cold Memory Tiering

#

CXL also provides a natural intermediate tier:

HBM / DDR
    ↓
Hot Data

CXL Memory
    ↓
Warm Data

SSD / Storage
    ↓
Cold Data

The goal is not to replace every memory technology with CXL.

The goal is to place each class of data in the most appropriate tier.

Mapping CXL Products to Enterprise Architectures

#

The next stage is to connect these concepts to actual system designs.

That means examining:

• Which CXL products fit LLM inference?
• Where should KV cache reside?
• When does CXL pooling make sense for VM consolidation?
• How should hot, warm, and cold data be distributed?
• Which Samsung, SK hynix, and Micron products map to each architecture?
• When does CXL justify its latency overhead?

That practical deployment layer is where CXL moves from a specification into an actual infrastructure technology.