NVIDIA ASAP² Direct datapath offloading

Warning

This blueprint documents findings and validated procedures for enabling NVIDIA ASAP² Direct datapath offloading on MOSK.

It does not productize ASAP² as a supported MOSK feature. Mirantis provides no support commitment for this configuration, and NIC compatibility is limited to the hardware and firmware that were explicitly tested for this research. Do not treat this blueprint as a guarantee of production readiness.

Cloud platforms that handle large volumes of tenant traffic often spend a significant share of compute capacity on packet switching rather than on customer workloads. NVIDIA ASAP² (Accelerated Switching And Packet Processing) addresses that cost by moving eligible virtual switching work from the host CPU onto SmartNIC hardware, so more server capacity remains available for applications.

Benefits of NVIDIA ASAP²:

• Frees host CPU for business workloads (VMs) by offloading eligible packet switching to the NIC—especially valuable for high-traffic tenant workloads where software switching would otherwise dominate capacity, such as cloud security inspection and policy enforcement, virtual firewalls and other network functions, and dense multi-tenant east-west traffic.

• Improves throughput and efficiency on high-bandwidth links while retaining OpenStack overlay networking, for example, VXLAN tenant networks.

• Preserves an OpenStack and OVS-centric operational model relative to pure SR-IOV passthrough. Where classic SR-IOV typically trades away virtual-switch features for raw passthrough performance, NVIDIA ASAP² aims to keep cloud networking semantics for users while accelerating the data path in hardware.

The following sections cover the scope, architecture, use cases, requirements, configuration, limitations, and performance of NVIDIA ASAP² Direct on MOSK:

• Blueprint scope and intended audience
• Architecture
  • Key components and their roles
  • Datapath behavior
  • Comparison with related networking modes
• Topologies and use cases
  • Validated host OS network layout
  • Underlay, overlay, and physical networks
  • Validated use cases and traffic paths
  • Non-validated use cases and traffic paths
• Requirements
  • Hardware prerequisites
  • Host software stack
  • MOSK and OpenStack matrix
  • Cluster assumptions
• Configuration and activation
  • Starting point
  • Approach
  • Host and NIC preparation
  • OpenStackDeployment configuration
  • Instance and port attachment
  • Validation checks
  • Useful documentation
• Limitations
  • Functional and feature limitations
  • Operational and life-cycle caveats
  • Compatibility constraints
• Performance
  • Test methodology
  • Results
  • Interpretation