1.1. Introduction (OX v1.4)

OX is a C-based NVMe controller solution for programmable storage devices, such as the Dragon Fire Card (DFC). It has been designed and primarily coded by Ivan L. Picoli during his PhD project at IT University of Copenhagen under the supervision of Philippe Bonnet.

The DFC has a powerful hardware, capable of running an entire operating system on its cores. That's where OX Controller takes place, intermediating between Non-Volatile memory channels and the host (over PCIe or network fabrics). The main idea behind this controller is keeping the control path on a hardware capable of running application-defined code, while the data path is linked directly to the NVM, bypassing the processing unit that controls the data flow. For a better explanation, OX has the choices of performing:

(1) WRITE:
  (a) from host memory to NVM;
  (b) from OX memory to NVM;

(2) READ:
  (a) from NVM to host memory;
  (b) from NVM to OX memory;

(a) cases: the data path is separated from control path. Managed by,
           but bypassing the OX controller.
(b) cases: the data path is merged into the control path. Used by internal
           data management, avoiding data movement through the interconnection
           (PCIe or network fabrics) while performing processes such as
           garbage collection and wear-leveling.

By programming the controller, a unique device can be modified to support emerging technologies in both host and NVM sides. OX Controller has been designed to support multiple solutions and technologies, abstracted by a set of user-specific modules registered on its core. Such modules are separated into layers (See Section 4).

Currently:

(1) on the host side: 
  (a) OX exposes the device as a compatible Open-Channel SSD.
  (b) OX exposes the device as a standard NVMe block device (See AppNVM FTL).
(2) on the NVM side:
  (a) OX abstracts the custom-made NAND DIMM designed for the DFC.
      It supports multiple versions of the FPGA.
  (b) OX abstracts a volatile emulation of MLC NAND, for those who
      do not have the NAND DIMMs in hands.

For Open-Channel SSD, see LightNVM. For the DFC as standard NVMe block device, see AppNVM FTL.

Based on such technologies, OX becomes the link in between the application needs and the media complexity. Indeed, each type of NVM has its own constraints and limitations, but at the same time, applications have their own requirements. This assumption brings a tradeoff between media management and performance but having the media management as an essential part of a reliable system. The OX Flash Translation Layer exposes a library for application-specific FTLs and allows applications to install their own code into the control path, bringing new ways of dealing with media:

- Redundant layers are merged into a single one (e.g.: Mapping and GC);
- Unnecessary data movement is avoided (e.g. GC and wear-leveling);
- No interference among multiple tenants (by isolating I/Os
  in different chunks of NVM);
- Open-Channel SSD benefits without media complexity being exposed
  (by splitting the management into modules);

Such benefits are essential pieces towards application-driven storage.