Navigating Shared Storage: Mitigating Performance Challenges with SSD Quality of Service

Dan Helmick (Samsung) and Yuliya Tarnikova (Google) present the motivation and current status of SSD Quality of Service standardization at OCP Global Summit 2025. The talk covers Google's requirements for consistent, isolated multi-tenant SSD performance and the NVMe TP4176 technical proposal that addresses them through controller-level bandwidth and IOPS rate limits. Key topics include token bucket mechanics for rate limiting, hard vs. soft rate limit modes with concrete bandwidth examples, and a live migration use case demonstrating the value of soft limits. Future extensions beyond the current TP4176 scope—deallocate rate limiting, submission-queue group tenants, and end-to-end IO prioritization—are identified as gaps alongside a call to join NVMe and OCP Storage Project.

Key Takeaways

NVMe TP4176 (Quality of Service for PCIe Bandwidth and IOPS per controller) is still in active development as of October 2025; agreed parameters include Total BW, Total IOPS, Write BW, Write IOPS, and write-to-read scalars set in real-world units.
Google's four fundamental multi-tenant SSD QoS requirements are: advertise consistent performance, guarantee SLAs with noisy neighbors, fair resource sharing of NAND and PCIe bandwidth, and VM fungibility across SSD generations.
Hard rate limits strictly cap each tenant at its configured ceiling; soft rate limits allow bursting above the allocation to consume idle capacity—a 50 MB/s tenant can reach 80 MB/s when peers only use 20 MB/s combined on a 100 MB/s drive.
Live migration is a primary soft-rate-limit use case: a parent process set to 1 MB/s soft limit can consume the full 100 MB/s SSD when VM tenants go idle, achieving migration convergence rapidly.
Unlike networking, SSDs cannot drop commands when rate-limit tokens are exhausted; they must queue every command and return it at minimum with an error, making SSD rate limiting traffic policing rather than traffic shaping.
The current TP4176 scope covers only reads and writes at controller granularity; identified gaps include deallocate interference, bursty workload handling, credit sharing across multiple virtual functions, and true end-to-end single-tenant IO prioritization.
Future work proposes expanding the tenant definition from per-controller to per-group-of-submission-queues to better serve Linux namespace-based tenants and SPDK applications requiring intra-tenant priority differentiation.