What’s the Difference Between SR-IOV SSDs and Hypervisors for Automotive Apps?

What you’ll learn:

• How SR-IOV technology enables virtualization in automotive applications, allowing for multiple systems (like eCockpit and ADAS) to share storage resources, thereby reducing component count and improving efficiency.
• The tradeoffs and potential benefits of single-port versus multi-port SR-IOV SSD solutions, including cost considerations, performance impacts, and long-term adoption in the automotive industry.

As many automotive makers look to reduce the number of components in their vehicles, the addition of eCockpit and advanced driver-assistance system (ADAS) features instead pushes them to increase the component count. Amid this tug-a-war, is there a way to share storage between applications by using virtualization to reduce the number of storage units as well as reduce duplicate copies of commonly used data? This article looks at single-root input/output virtualization (SR-IOV) and how it can be a possible solution to consolidate and reduce the amount of storage needed in a software-defined vehicle (SDV).

Single-Root Input/Output Virtualization (SR-IOV) vs. Hypervisors

SR-IOV has been around for many years, but it’s been mainly targeted to enterprise networking applications to help improve performance, scalability, resource utilization, and security in virtualized and cloud environments. Now it’s moving into other markets like automotive. SR-IOV functionality isn’t limited to data storage devices; however, in this article, we will limit the discussion to solid-state disks (SSDs).

First, let’s look at the components of SR-IOV and what they do. SR-IOV contains physical functions (PFs) that are PCIe functions responsible for moving data on and off the SSD. Typically, there’s one PF per host. Multiple hosts can also be used with a single PF, but it requires a PCIe switch. Having more than one host directly attached to the SSD will require one PF per host.

Virtual functions (VFs) are also PCIe functions that support data flow and determine how the device resources are configured. At a high level, think of a PF as the port(s) to the host(s). VFs are how you partition the storage device for the virtual machines (VMs) that it’s supporting. SR-IOV simplifies this by removing the need for the data to go through a hypervisor as well as eliminating the overhead caused by the data translation, thus improving latency (Fig. 1).

VFs can have their own namespaces (storage partitions) or share namespaces across VFs. For example, a design could have the same map data available for both in-vehicle infotainment—IVI—(VM1) and ADAS (VM2). Rather than have two copies, the VM could share the namespace where the map data is located.

In recent years, interest in SR-IOV has grown in automotive applications. Simple single-port to multi-port solutions have been pitched. The idea of having many hosts sharing one storage device appears to be a great way to reduce components and save costs. This can be satisfied by using a single-port SR-IOV SSD with a PCIe switch or a multi-port SR-IOV.

The advantage of a multi-port device is that you don’t need a switch. The disadvantage is that if the multi-port device has only four lanes and, in the case of a quad-port, each port gets one lane. This would result in each host merely getting 25% of the maximum performance of the SSD even if other hosts were idle.

With a single port in a PCIe switch solution, the switch can help system-on-chips (SoCs) maximize the available throughput since all four lanes are available to it. Case in point, if there are four hosts and three are idle, the active host will get 100% of the four-lane bandwidth.

If performance isn’t a concern, the next hurdle is the complexity of the software involved in making such a design work well. This will likely be the stumbling block for many, which will require reverting to simpler architectures (Fig. 2).

SoCs, SR-IOV, and the Car

Even as SoCs become more powerful and the number needed per vehicle decreases, the need for SR-IOV will remain—or even ramp up. In eCockpits, each function will have separate VMs/VFs—digital cluster, navigation, telematics, passenger entertainment, and dash camera. ADAS/AD will also have the need for VMs/VFs. An event data recorder (EDR) will have a high-endurance (SLC) namespace. While demand for SR-IOV will continue, we’ll see a decrease in the need for multi-port SSDs.

Another way in which a single port SR-IOV solution can support multiple hosts—without a switch—is to have the data of the indirect hosts pass through a single host that’s directly attached to the SSD. Figure 3 represents how this is done at a high level.

Cost is another consideration that can’t be overlooked. The more ports that are supported on the SSD, the higher the cost. Initially, the cost of automotive-grade PCIe switches was seen as too expensive to use, thus making multi-port SSDs a more favorable option. However, as more suppliers entered the market, the costs have come down, making this a very good option in addition to the performance advantages mentioned earlier.

Multi-port SSDs also lack any industry standard, leaving each supplier to have their own “custom” design, which the automotive industry wants to avoid for supply continuity and options. In the long run, single-port SR-IOV SSDs will become mainstream.

Making the Move to SR-IOV

While the automotive market is new to integrating SR-IOV technology, the desire to adopt it is strong. The use cases exist; it’s just a matter of engineers learning the technology and being comfortable with it.

This was the same situation with UFS when it first entered the automotive market. Engineers were familiar with e.MMC, but UFS was new. Today, UFS storage devices are the largest part of the automotive NAND flash TAM. Once the ecosystem develops more and customers become more comfortable using SR-IOV, it will also become a strong driver of NAND flash’s growth in automotive applications.