Accelerator Manager Virtual Function Table Failover
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Current computer systems face inefficiencies in performance due to traditional system architectures, which are not data-centric and often result in bottlenecks, limiting the effectiveness of hardware accelerators.
Innovation Solution
The Open Coherent Accelerator Processor Interface (OpenCAPI) specification allows processors to attach to coherent user-level accelerators and I/O devices, enabling a data-centric approach by sharing virtual addresses and dynamically routing calls between software libraries and hardware accelerators, with an accelerator manager that reroutes calls to software libraries in case of failures and retries them.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Productivity
If hardware accelerators are used to improve system performance, then processing speed and efficiency are improved, but system reliability deteriorates due to potential accelerator failures
Solution Approach 1:
The system prepares software library implementations as backup solutions before hardware accelerator failures occur. The virtual function table is pre-configured with multiple implementation options, and the system proactively monitors accelerator health to switch to software backups before complete failure occurs, cushioning against reliability issues while maintaining high performance.
Solution Approach 2:
The system dynamically changes the operational state of function implementations by modifying the virtual function table entries. When an accelerator fails, the system changes the routing parameter from hardware accelerator to software library implementation, allowing the same function to be executed through different physical implementations based on current system conditions.
2Productivity
If a data-centric architecture with OpenCAPI is implemented, then system performance and data processing efficiency are improved, but device complexity increases
Solution Approach 1:
The virtual function table serves as an intermediary layer between the processor and multiple implementation options (hardware accelerators and software libraries). This mediator abstracts the complexity of managing multiple accelerators and their failure states, presenting a simple interface to the processor while handling complex routing, monitoring, and failover operations in the background.
Solution Approach 2:
The virtual function table is designed to be universal, supporting multiple types of function implementations (different hardware accelerators and software libraries) through a single unified interface. This multi-functional design allows the same mechanism to manage diverse accelerators with different capabilities, reducing the need for separate management systems for each accelerator type.
3Productivity
If hardware accelerators are deployed to overcome bottlenecks, then system throughput is improved, but ease of operation deteriorates due to manual configuration requirements
Solution Approach 1:
The system implements self-service through automatic accelerator monitoring and dynamic virtual function table updates. The accelerator manager autonomously detects accelerator failures, determines appropriate fallback implementations, and updates routing without requiring manual intervention. This self-service capability maintains high throughput while eliminating the operational burden of manual configuration and troubleshooting.
Solution Approach 2:
The system establishes feedback loops where the accelerator manager continuously monitors accelerator performance and health status, and this feedback information is used to dynamically adjust the virtual function table routing. This closed-loop control enables the system to automatically respond to changing conditions, maintaining optimal throughput without manual reconfiguration.
Data Source
AI summary
An accelerator manager monitors hardware accelerators that are called by one or more computer programs. A virtual function table includes multiple entries, where each entry correlates a call from a computer program to a corresponding call to either a software library or a hardware accelerator. A call by the computer program to a function in the virtual function table results in the call being routed to either the software library or to a hardware accelerator depending on the contents of the corresponding entry in the virtual function table. The accelerator manager, in response to a detected failure in an accelerator, replaces one or more calls in the virtual function table to the failed accelerator with calls to the software library. The accelerator manager can then retry the call that caused the accelerator to fail, which will then be executed by the software library.