QoS Domains
A QoS domain is the mechanism used to access data within a SEF device. QoS domains are created within a virtual device, and it is possible to have multiple QoS domains sharing a single virtual device. When multiple QoS domains share a virtual device, they will draw from a common pool of super blocks. However a super block is never shared between QoS domains and so data for QoS domains will never be intermingled in a super block. When QoS domains share a virtual device, there is no hardware isolation between them, so die-time conflicts are possible. The scheduling and prioritization features of SEF are used to order I/O for shared virtual devices and to resolve these die-time conflicts (e.g. software-defined isolation/quality of service).
When a QoS domain is created, several parameters are specified to define the characteristics of the QoS domain, which will be discussed below. Upon successful creation of a QoS domain, a device node will be created in the operating system namespace corresponding to the newly created QoS domain. At boot time the SEF device driver will create device nodes for all QoS domains previously defined for the device. Device nodes for QoS domains may be used to enumerate existing QoS domains as well as to restrict access to/enforce ownership of a QoS domain. All user data access commands are issued against a QoS domain. Typically, a QoS domain will be used by a single application or Flash Translation Layer/block driver/key value driver.
Figure 8.1 shows an example of how the virtual devices of a SEF Unit could be divided into QoS domains. A QoS domain is a logical construct that defines a capacity taken from its virtual device’s capacity. It also defines a quota that may exceed the capacity of the virtual device as shown with QoS domains three through four. A SEF Unit can have at most 65534 QoS domains defined. The actual limit depends on specific hardware limitations.
Allocated super blocks are owned by only one QoS domain at a time and never shared. Super blocks are allocated from a shared pool allowing for host-managed thin provisioning. A QoS domain can allocate super blocks until it hits its quota or the free pool is exhausted.
Figure 8.1: QoS Domain Example
Creation-time Parameters
vdHandle: the handle to the virtual device the QoS domain will be created in.
QoSDomainID: an identifier that will later be used to specify the created QoS domain. This identifier must be unique across the entire SEF device. IDs 0 and 1 are reserved.
flashCapacity: the number of ADUs reserved for the QoS domain. It is subtracted from the available ADUs from the virtual device so must be less than the currently available ADUs.
flashQuota: the quota for the amount of space this QoS domain may consume. The value is specified as the total number of ADUs. If less than flashCapacity, it will be set to flashCapacity. Since a super block is never shared between QoS domains, the actual capacity allocated for the QoS domain may be greater than requested to fill out an entire super block.
ADUsize: this is the ADU size requested for this QoS domain. Different QoS domains, even within the same virtual device, may have different ADU sizes. A list of supported ADU sizes for a SEF device may be queried from the SEF device.
api: this field specifies the API to be used for this QoS domain. Currently only the super block API is supported.
recovery: Specifies the error recovery strategy for this QoS domain.
encryption: specifies that the QoS domain is to be encrypted.
numRootPointers: specifies the number of user defined metadata pointers to be created for this QoS domain. A typical use for this would be to preserve metadata for the QoS domain within the QoS domain itself. For example, an L2P lookup table for a block FTL could be written/persisted within the QoS domain, keeping track of the physical addresses of the table. ADUs could then be written containing a tree of pointers to all of the ADUs making up the table, and finally the root pointer of the tree of pointers could be saved. At initialization time the root pointer could be read to restore the entire table. Up to 16 root pointers may be saved per QoS domain.
numPlacementIDs: specifies the number of separate, simultaneously opened super blocks that may be used by the QoS domain in auto allocation mode. It does not affect the number of manually opened super blocks, which instead depends on the device itself.
FMQDefaults: specifies the default FMQ to use for each type of I/O operation. This can be optionally overridden when submitting I/O to a QoS domain.