Introduction

This specification describes the core components of the Software-Enabled Flash™️ (SEF) application programming interface (API). It is platform-agnostic and is usable by any code that can use a C interface.

The SEF API provides a simple but powerful interface for developers that abstracts low-level flash details of low-level flash memory device mechanics in such a way that allows hosts to interact with flash memory devices as though they were simple performance-optimized read/write devices. Hosts can make use of the SEF API to implement a custom Flash Translation Layer (FTL) or build SEF native applications bypassing all file systems in accordance with their application-specific requirements.

The SEF API interfaces with SEF Units. SEF Units are PCIe®️ based NVMe™️ devices that implement the SEF specific extensions to the NVMe Base Specification. These extensions are separately defined as the SEF Command Set.

The SEF API addresses the following:

• Maintaining interface compatibility across flash memory generations
• Allowing host control over data placement to enable application-specific optimizations
• Providing mechanisms to enforce hardware isolation to support multi-tenancy and workload isolation
• Provides control over housekeeping functions to support predictable latency
• Reduces CPU cycles and host overhead via powerful API primitives
• Improves flash memory life and health via intelligent automatic resource allocation

The SEF Library implements the SEF API as a linkable library module. The following figure 1 illustrates where the SEF Library is located in the context of a traditional SSD-like application stack. It shows multiple possible integrations of the SEF Library. In some cases the integration is direct like with a SEF enable FIO. Other cases require a host-define FTL exposed to applications as a virtual block device in a QEMU guest. Tooling can also use the SEF Library for configuring SEF units with a command line interface. In all cases, the SEF Library accepts admin and I/O requests and issues a set of commands to the SEF Unit. The SEF Unit then translates this down to an appropriate set of flash memory-level operations and returns status and data back up the stack.

Figure 1: SEF Library Application Stack

The SEF Unit handles functionality including super block allocation, identifying and working around defective blocks, low-level flash memory I/O, scheduling, prioritization and other device-level concerns. The host layer in turn is responsible for implementing its own data placement strategy (including devising an appropriate logical-to-physical address mapping) as well as coordinating housekeeping functions such as wear leveling, garbage collection, and responding to asynchronous event notifications. The following figure 2 provides a detailed view of data flow within a SEF Unit.

Figure 2: SEF Block Diagram

Built in conjunction with the SEF API is a SEF SDK that provides a starting point for host application development. The SEF SDK includes quick start guides for tooling to setup SEF devices for use, sample drivers, libraries, supporting documentation, and an implementation of a fully functional Reference FTL that can be extended or modified as appropriate. It is documented separately.