NVMe Discovery Controller Pull Model for Bidirectional Zoning
Find Innovative SolutionsGenerate Solutions
Solution Overview
Problem
Existing NVMe-oF™ environments face limitations in zoning configurations and communication between controller entities, particularly between centralized discovery controllers (CDC) and direct discovery controllers (DDC), due to the unidirectional data transfer capabilities of NVMe® commands, which hinder efficient management and operation in SAN environments.
Innovation Solution
Implementing push and pull model embodiments that enhance DDCs to support both host and controller functionality, allowing for bidirectional data transfer through Fabric Zoning Lookup (FZL), Fabric Zoning Send (FZS), and Fabric Zoning Receive (FZR) commands, and utilizing Asynchronous Event Notifications (AEN) for pull model DDCs to request operations from CDCs.
Engineering Contradictions & Design Principles
Engineering Contradiction Analysis
1Adaptability or versatility
If NVMe commands are used for data transfer between CDC and DDC, then data transfer can be performed, but bidirectional communication is hindered due to unidirectional transfer capabilities
Solution Approach 1:
The patent applies inversion by allowing the DDC (normally a passive device) to initiate operations through AEN notifications, reversing the traditional command-initiation role. This enables bidirectional communication where the DDC can request operations from the CDC without requiring traditional command structures from the DDC to CDC direction.
Solution Approach 2:
The AEN (Asynchronous Event Notification) mechanism serves as an intermediary that enables communication in the otherwise unidirectional NVMe command structure. The AEN allows the DDC to send requests to the CDC without using traditional NVMe commands, effectively creating a bidirectional communication path through this intermediate notification mechanism.
2Ease of operation
If traditional NVMe command structure is used, then simple command-response interaction is maintained, but DDC cannot initiate operations autonomously
Solution Approach 1:
The DDC is enhanced with multi-functionality, serving both as a traditional passive storage device and as an autonomous initiator of operations. By combining these roles, the DDC can now both respond to commands and autonomously initiate operations through AEN notifications, reducing the need for separate host intervention.
Solution Approach 2:
The DDC performs self-service by autonomously initiating operations such as zone group management without requiring host system intervention. The DDC can independently send AEN notifications to the CDC to request operations, enabling it to manage its own discovery information and zone configurations without external control.
3Productivity
If CDC manages all zoning operations, then centralized control is maintained, but communication efficiency decreases during discovery events
Solution Approach 1:
The DDC prepares and sends AEN notifications in advance when discovery events occur, allowing the CDC to be notified immediately rather than waiting for periodic polling or host-initiated queries. This preliminary action of notifying the CDC proactively reduces the time required for zoning operations during discovery events.
Data Source
AI summary
Embodiments presented herein enable non-volatile memory express (NVMe®) subsystem-driven commands. By configuring subsystems as pull model devices, subsystems can request a centralized discovery controller to perform Send Log Page commands, include Host Discovery. Embodiments may leverage a command execution request architecture to achieve the subsystem-driven Send Log Page commands.