Modern infrastructure is moving beyond isolated server-centric designs where compute, storage, and networking are locked within fixed units and evolving toward architectures where resources are disaggregated and dynamically connected over high-speed, Ethernet-based fabrics.

In this fabric-native model:

• Compute and storage no longer need to be co-located
• Resources can be assigned on demand
• Scalability is elastic and not tied to physical servers

This evolution sets the stage for next-generation storage platforms to shed unnecessary complexity and embrace composability at the hardware level.

That’s exactly where iWave is headed in partnership with Altera by engineering an 800G JBoF platform that reimagines how flash storage fits into modern Ethernet-based data centers.

Understanding the JBoF Landscape

Just-a-Bunch-of-Flash (JBoF) systems are dense, high-capacity enclosures filled with arrays of high-performance NVMe SSDs, designed specifically for environments requiring ultra-low latency and massive throughput. Unlike traditional storage arrays that include embedded CPUs and RAID controllers, JBoFs are just storage shelves, they provide no onboard compute or data processing. Instead, they expose raw NVMe drives directly to external compute nodes using high-speed interfaces such as NVMe-over-Fabrics (NVMe-oF) using Ethernet, InfiniBand, or Fibre Channel.

JBoFs are foundational to disaggregated architectures, where compute, storage, and network resources are scaled and managed independently. This separation is critical for allowing data centres to pool flash storage centrally and dynamically allocate it to applications as needed, improving both utilization efficiency and cost-effectiveness.

Moving Beyond CPU-Bound JBoF Architectures

For years, JBoF systems have relied on embedded CPUs within the chassis to handle tasks like NVMe-over-Fabrics translation, SSD enumeration, telemetry (via NVMe-MI), and out-of-band management interfaces. While this architecture worked in traditional setups, it introduces several inefficiencies that become apparent in modern, disaggregated infrastructure.

Having a CPU in the control path brings with it:

• Additional power consumption and cooling overhead due to CPU and DRAM requirements.
• Software dependencies that require OS patching, driver maintenance, and constant monitoring.
• Unavoidable latency bottlenecks, as NVMe commands must be processed through the CPU’s software stack before reaching the storage fabric.
• An increased attack surface because of the software stack and general-purpose OS within the JBoF.

This model, while serviceable, starts to collapse under the scaling demands of AI clusters, multi-tenant cloud environments, and edge deployments where every watt, every microsecond, and every RU of space counts.

A New Direction: iWave’s 800G-Based, CPU-Free JBoF

In collaboration with Altera, iWave is building a next-generation 800G JBoF platform that completely removes the need for a CPU inside the storage shelf.

By removing the CPU from the JBoF and moving the control and data plane logic to the SmartNIC, iWave simplifies the hardware, reduces latency, power and thermal footprint, and eliminates the need for OS patches, software agents, or runtime dependencies. The iWave SmartNIC, becomes the central control engine and is responsible for the movement of data between the Remote Host and the Local SSDs. The system relies on iWave’s SmartNIC, powered by an OFED RDMA Core along with an NVMe-oF Controller to offload the full data and control plane stack.

It handles the following:

• NVMe command decoding
• Queue management
• SSD mapping and health checks
• Completion handling

Visualizing the Architectural Difference

The illustrations below showcase the key difference between traditional CPU-based JBoFs and iWave’s SmartNIC-offloaded design.
The figure 1 shows the traditional JBoF where on the server side, an NVMe-oF Initiator enables direct NVMe command offload onto the network, bypassing traditional TCP/IP stacks and reducing CPU overhead.

However, inside the JBoF, the NIC still relies on an embedded CPU to process NVMe-oF Target requests, manage PCIe switch routing, and forward I/Os to SSDs. This extra CPU layer adds latency and becomes a bottleneck as SSD parallelism increases.