Non-Transparent Bridge API for Asynchronous Cross-Host Memory Access
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing Non-Transparent Bridge (NTB) technologies face challenges in supporting asynchronous and non-privileged access to memory across multiple hosts, requiring privileged processes for memory window reconfiguration and consuming network resources with RDMA connections.
Innovation Solution
An NTB device API and IO API that enable non-privileged processes to asynchronously access memory across hosts by registering key identifiers for memory regions, allowing access control and validation, and performing read/write transactions without waiting for completion, thus supporting memory isolation and reducing CPU overhead.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Ease of operation
If traditional NTB technologies are used for memory access across hosts, then memory isolation and security are maintained, but privileged processes are required for memory window reconfiguration and CPU overhead increases
Solution Approach 1:
The patent applies preliminary action by pre-configuring memory windows and establishing access permissions before actual memory access operations. The system pre-registers memory regions, pre-establishes key identifiers, and pre-configures the NTB bridge parameters in advance, allowing non-privileged processes to perform memory access without requiring real-time privileged operations for window reconfiguration.
Solution Approach 2:
The patent introduces an intermediary mechanism in the form of a specialized NTB driver or management module that acts as a mediator between privileged system components and non-privileged application processes. This intermediary handles the complex memory window reconfiguration tasks on behalf of non-privileged processes, translating their simple access requests into properly configured NTB operations, thereby shielding applications from complexity while maintaining security.
2Productivity
If RDMA connections are used for asynchronous memory access, then network resource usage increases, but asynchronous access capability is enabled
Solution Approach 1:
The patent extracts the asynchronous memory access functionality from the network layer (RDMA) and implements it directly at the hardware bridge level through the NTB device. By taking out the network protocol overhead and implementing asynchronous access natively in the NTB hardware and driver, the system achieves RDMA-like asynchronous capabilities without consuming network resources, as the access occurs through direct memory-mapped I/O rather than network protocols.
Solution Approach 2:
The patent copies the essential functionality of RDMA (asynchronous remote memory access) and implements it through a different mechanism - using NTB hardware with pre-configured memory windows and key-based access control. Instead of copying data over the network, the system creates a direct hardware pathway that mimics RDMA behavior, achieving the same productivity benefit without the network resource cost.
3Reliability
If key identifier registration and validation are implemented for each process, then access control security is improved, but system overhead increases
Solution Approach 1:
The patent merges the key identifier management functionality into the existing NTB hardware and driver infrastructure. Instead of implementing separate key management systems for each process, the solution combines key registration, validation, and access control into the unified NTB driver layer, leveraging the existing memory window configuration mechanisms to handle key-based access control for multiple processes simultaneously.
Solution Approach 2:
The patent creates a universal key management mechanism that serves multiple processes and memory regions through a single integrated system. The NTB driver implements a general-purpose key registration and validation framework that can be reused by any number of processes accessing any number of memory regions, eliminating the need for separate key management implementations for each process and reducing overall system complexity.
Data Source
AI summary
API in conjunction with a bridge chip and first and second hosts having first and second memories respectively. The bridge chip connects the memories. The API comprises key identifier registration functionality to register a key identifier for each of plural computer processes performed by the first host, thereby to define plural key identifiers; and/or access control functionality to provide at least computer process P1 performed by the first host with access, typically via the bridge chip, to at least local memory buffer M2 residing in the second memory, typically after the access control functionality first validates that process P1 has a key identifier which has been registered, e.g., via the key identifier registration functionality. Typically, the access control functionality also prevents at least computer process P2, performed by the first host, which has not registered a key identifier, from accessing local memory buffer M2, e.g., via the bridge chip.