Shared-Memory Ring Communication for Hypervisor-Free AMP Upgrades

Resolve Bottlenecks,
Find Innovative Solutions
Generate Solutions

Solution Overview

Problem

Existing asymmetric multiprocessing systems with external hypervisors experience significant downtime during router software upgrades, necessitating a more efficient method to reduce application downtime and enable seamless communication and disk access between kernel instances.

Innovation Solution

Implementing a high-performance in-memory communication infrastructure and disk abstraction mechanism within the AMP system, allowing instances to run bare-metal and dynamically restructure disk layouts, enabling seamless network-to-native disk access and reducing downtime to hardware reinitialization time.

Engineering Contradictions & Design Principles

VSEngineering Contradiction Analysis

1Loss of time

If an external hypervisor is used to manage multiple kernel instances, then system control and resource management are simplified, but application downtime increases significantly during software upgrades

Engineering Contradiction:
Improveapplication downtimeVSAvoidsystem architecture complexity
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent removes the external hypervisor from the system architecture, allowing kernel instances to run bare-metal directly on hardware. This extraction eliminates the hypervisor overhead and enables faster instance switching, reducing application downtime during software upgrades while managing complexity through direct hardware access and inter-instance communication mechanisms.

Inventive Principle:
Principle #2Taking out (Extraction)

Solution Approach 2:

The patent implements preliminary actions by having the first kernel instance proactively create and prepare the second kernel instance before any upgrade is needed. The second instance is pre-configured with necessary resources and communication channels, so when an upgrade is required, the transition can occur immediately without waiting for instance creation, thus minimizing downtime.

Inventive Principle:
Principle #10Preliminary action

2Speed

If kernel instances run bare-metal without an external hypervisor, then communication speed and disk access efficiency are improved, but the complexity of managing inter-instance communication and resource partitioning increases

Engineering Contradiction:
Improvecommunication speedVSAvoidinter-instance communication complexity
Core Design Contradiction:
SpeedVSDevice complexity

Solution Approach 1:

The patent segments the system into distinct kernel instances (first and second instances) that run independently as bare-metal systems. Each instance has its own memory space and can be managed separately, allowing high-speed direct communication through defined interfaces while maintaining operational independence. This segmentation enables fast communication without hypervisor mediation while managing complexity through clear instance boundaries.

Inventive Principle:
Principle #1Segmentation

Solution Approach 2:

The patent introduces intermediary mechanisms including shared memory regions, message passing interfaces, and resource allocation protocols that mediate communication between bare-metal kernel instances. These intermediaries provide structured communication channels that simplify the complexity of direct inter-instance interaction while maintaining the performance benefits of bare-metal execution.

Inventive Principle:
Principle #24Intermediary (Mediator)

3Loss of time

If the second kernel instance is created and configured before the first instance shuts down, then application downtime is reduced to hardware reinitialization time, but resource contention and coordination complexity increase

Engineering Contradiction:
Improveapplication downtimeVSAvoidinstance coordination complexity
Core Design Contradiction:
Loss of timeVSDevice complexity

Solution Approach 1:

The patent implements preliminary action by having the first kernel instance create and fully configure the second kernel instance while still running and managing system resources. The second instance is prepared in advance with all necessary configurations, memory allocations, and communication channels established. This allows the first instance to shut down immediately after creating the second instance, reducing downtime to only the hardware reinitialization time required for the second instance to take over.

Inventive Principle:
Principle #10Preliminary action

Solution Approach 2:

The patent implements feedback mechanisms where the first kernel instance monitors the creation and configuration status of the second instance, and the second instance provides status feedback to confirm readiness. This coordinated feedback system allows both instances to manage resources efficiently during the transition period, reducing contention through synchronized resource allocation and handover protocols.

Inventive Principle:
Principle #23Feedback

Data Source

PatentEP4073645B1High performance in-memory communication infrastructure for asymmetric multiprocessing system without an external hypervisor
Publication Date: 2025.10.29 CISCO TECHNOLOGY INC
  • EP4073645B1 patent drawingFigure 1
  • EP4073645B1 patent drawingFigure 2
  • EP4073645B1 patent drawingFigure 3A

AI summary

The present disclosure is directed to an in-memory communication infrastructure for an asymmetric multiprocessing system without an external hypervisor, and includes one or more processors and one or more computer-readable non-transitory storage media comprising instructions that, when executed by the one or more processors, cause one or more components to perform operations including identifying data for transmission from a first instance to a second instance, writing, by the first instance, the data into a first ring of a shared memory, the first ring configured as a first transmit ring for the first instance, sending an inter-processor interrupt to the second instance to alert the second instance of the data written into the first ring, reading, by the second instance, the data from the first ring, the first ring configured as a first receive ring for the second instance, and transmitting the data to an application of the second instance.