OSMOSIS: Enabling Multi-Tenancy in Datacenter SmartNICs

TL;DR

This work integrates OSMOSIS within an open-source RISC-V-based 400Gbit/s SmartNIC, a SmartNICs resource manager co-design that fully supports multi-tenancy and enables broader adoption of SmartNICs in datacenters with low overhead.

Abstract

Multi-tenancy is essential for unleashing SmartNIC's potential in datacenters. Our systematic analysis in this work shows that existing on-path SmartNICs have resource multiplexing limitations. For example, existing solutions lack multi-tenancy capabilities such as performance isolation and QoS provisioning for compute and IO resources. Compared to standard NIC data paths with a well-defined set of offloaded functions, unpredictable execution times of SmartNIC kernels make conventional approaches for multi-tenancy and QoS insufficient. We fill this gap with OSMOSIS, a SmartNICs resource manager co-design. OSMOSIS extends existing OS mechanisms to enable dynamic hardware resource multiplexing of the on-path packet processing data plane. We integrate OSMOSIS within an open-source RISC-V-based 400Gbit/s SmartNIC. Our performance results demonstrate that OSMOSIS fully supports multi-tenancy and enables broader adoption of SmartNICs in datacenters with low overhead.

Figures (13)

• Figure 1: A predictable NIC data path versus the unpredictable sNIC kernel execution.
• Figure 2: Schematic overview of on-path sNIC architectures. Red arrows indicate the data path and blue arrows correspond to the control/management path.
• Figure 3: sNIC core (PU) processing time needed to serve $1$ packet for common sNIC kernels. Workloads with triangle markers are compute-bound, and circular markers are IO-bound. All workloads with $\leq64$B packet size (including 28 bytes IPv4/UDP-header) exceed PPB showing congestion at PUs when link bandwidth is fully utilized. Note that our setup supports Ethernet payload sizes below $64$B to accommodate custom interconnects ibspec.
• Figure 4: Congestor and Victim tenants' flows with equal priorities are mapped to two different SR-IOV VFs with equal shares of Ingress bandwidth. With the round-robin scheduling of per-flow queues, the Congestor tenant with 2$\times$ higher compute cost per packet occupies a proportionally larger number of cores than the Victim tenant.
• Figure 5: Slow-down of various IO operations (e.g., DMA and sending packets to Egress) initiated by the tenant's kernel results in HoL-blocking small requests due to underlying IO path contention.