A memory region registration management method and device of an RDMA network card and a medium

Abstract

The application provides a memory region registration management method and device of an RDMA network card and a medium, relates to the technical field of memory region registration management, and the method comprises the following steps: obtaining the running configuration of the memory region registration of the RDMA network card; receiving a memory region registration request from a current running instance; allocating a processing path for the memory region registration request; directly responding to the memory region registration request on a data plane path by the host-side driver program, maintaining the MPT / MTT resource by the driver program, and directly issuing the hardware mapping relationship of the memory region to a hardware configuration register of the RDMA network card; taking over the allocation and maintenance of the MPT / MTT resource according to the registration instruction by the hardware firmware; completing the memory region registration based on the driver execution mode or the firmware execution mode, and returning a registration result to the current running instance; and the application reduces the registration delay and can meet the requirement of high-speed processing of the data plane.

Description

Technical Field

[0001] This invention relates to the field of memory region registration management technology, and in particular to a memory region registration management method, device and medium for an RDMA network card. Background Technology

[0002] RDMA (Remote Direct Memory Access) technology allows network interface cards (NICs) to directly read and write host memory, avoiding host CPU intervention and significantly improving data exchange rates. In RDMA NIC applications, memory region (MR) registration is a crucial step in establishing the mapping relationship between the NIC hardware and the host's physical memory. MR registration requires converting the host memory address information into Memory Protection Table (MPT) / Memory Translation Table (MTT) resources that the NIC hardware can recognize.

[0003] Currently, traditional MR registration schemes often employ a single, fixed processing path: either the host-side driver manages MPT / MTT resources entirely, or the underlying firmware takes over entirely. However, in practical applications, this single registration processing path has significant limitations: while direct driver management offers high data interaction speeds, it fails to provide global resource coordination in scenarios with multiple virtual function (VF) passthroughs or multiple driver coexistence, easily leading to hardware mapping resource conflicts; conversely, while complete management by the underlying firmware unifies resource allocation, the increased interaction with the firmware significantly increases registration latency, making it difficult to meet the demands of high-speed data plane processing. Summary of the Invention

[0004] To address the aforementioned technical problems, the technical solution adopted by this invention is as follows:

[0005] According to a first aspect of this application, a memory region registration management method for an RDMA network card is provided, the method comprising the following steps:

[0006] S100, Obtain the running configuration for the memory region registration of the RDMA network card; the running configuration indicates whether to select a mode, such as driver execution mode or firmware execution mode, as the processing path for the current registration operation;

[0007] S200, Receive a memory region registration request from the currently running instance; the memory region registration request is used to convert the address information of the physical memory region to be mapped on the host side into hardware-recognizable MPT / MTT resources;

[0008] S300, according to the running configuration, allocate a processing path for the memory region registration request;

[0009] S400, if the processing path is driver execution mode, the host-side driver directly responds to the memory region registration request on the data plane path, the driver maintains the MPT / MTT resources, and directly sends the hardware mapping relationship of the memory region to the hardware configuration register of the RDMA network card;

[0010] S500, if the processing path is firmware execution mode, the host-side driver encapsulates the memory region registration request into a preset format registration instruction through the hardware command queue and sends it to the hardware firmware of the RDMA network card. The hardware firmware then takes over the allocation and maintenance of the MPT / MTT resources according to the registration instruction.

[0011] S600: Based on the driver execution mode or the firmware execution mode, complete the registration of the memory region and return the registration result to the currently running instance.

[0012] According to another aspect of this application, a non-transitory computer-readable storage medium is also provided, wherein at least one instruction or at least one program is stored in the storage medium, and the at least one instruction or at least one program is loaded and executed by a processor to implement the memory region registration management method of the RDMA network card described above.

[0013] According to another aspect of this application, an electronic device is also provided, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0014] The present invention has at least the following beneficial effects:

[0015] The memory region registration management method for RDMA network cards of this invention obtains the runtime configuration and flexibly selects either driver execution mode or firmware execution mode as the processing path for the current MR registration operation, effectively solving the problem that a single path cannot adapt to multiple service scenarios. When driver execution mode is selected, the host-side driver directly responds to the MR registration request and maintains MPT / MTT resources on the data plane path, directly sending the hardware mapping relationship to the hardware configuration register. This not only completely bypasses firmware processing and greatly reduces communication overhead, but also achieves low-latency, high-performance memory region registration, fully meeting the requirements of bare metal hosts or single-driver scenarios for extreme data throughput. When firmware execution mode is selected, the driver encapsulates the MR registration request into a preset format instruction through the hardware command queue and sends it to the firmware, which then uniformly takes over the allocation and maintenance of MPT / MTT resources. This invention enables the optional scheduling of two different processing paths through a configuration mechanism, allowing the same RDMA network card device to flexibly cope with single high-performance scenarios as well as effectively accommodate multi-functional and complex scenarios requiring global resource coordination. This significantly improves the adaptability and deployment convenience of RDMA network cards in different application environments; it also reduces registration latency and meets the needs of high-speed data plane processing. Attached Figure Description

[0016] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0017] Figure 1 A flowchart of a memory region registration and management method for an RDMA network card provided in an embodiment of the present invention. Detailed Implementation

[0018] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0019] It should be noted that, based on this disclosure, those skilled in the art will understand that one aspect described herein can be implemented independently of any other aspect, and two or more of these aspects can be combined in various ways. For example, any number of aspects set forth herein can be used to implement the device and / or practice the method. Furthermore, this device and / or practice the method can be implemented using other structures and / or functionalities besides one or more of the aspects set forth herein.

[0020] The following will refer to Figure 1 The flowchart shown is a method for registering and managing the memory region of an RDMA network card, which introduces a method for registering and managing the memory region of an RDMA network card.

[0021] The memory region registration management method for this RDMA network card may include the following steps:

[0022] S100, obtain the running configuration for the memory region registration of the RDMA network card; the running configuration indicates whether to select a mode, such as driver execution mode or firmware execution mode, as the processing path for the current registration operation.

[0023] In this embodiment, during the RDMA network card device startup or configuration phase, the system obtains the runtime configuration for memory region registration in the current scenario through the control plane. This configuration acts as a path selection switch, and its core function is to determine whether MR registration adopts the "driver execution mode" of direct driver management or the "firmware execution mode" of firmware coordination, thus setting the processing tone for subsequent registration operations.

[0024] Furthermore, step S100 includes the following steps:

[0025] S110, receive configuration instructions through the control plane of the RDMA network card; the configuration instructions are binary command line configuration parameters.

[0026] This step is the "input and status lock" process for switching MR registration modes. Before or during the initial loading phase of the RDMA network card device, the system provides a control plane configuration channel independent of the data plane forwarding. For the network card control plane, RDMA network card manufacturers typically provide dedicated out-of-band or in-band configuration tools. Maintenance personnel use these tools to issue configuration commands.

[0027] The binary command-line configuration parameters are sent to the RDMA network card's control plane interface via the host's operating system. Upon receiving these parameters, the network card's control plane writes them to the network card's internal non-volatile RAM (NVRAM) or dedicated hardware configuration registers (such as the PCIe VPD area or firmware reserved registers). This write operation ensures that the configuration remains effective even after the device is powered off and restarted, forming a persistent "running configuration."

[0028] S120, parse the configuration instruction. If the value of the configuration instruction is a first preset value, then select the driver execution mode as the processing path for the current registration operation; if the value of the configuration instruction is a second preset value, then select the firmware execution mode as the processing path for the current registration operation.

[0029] This step is the "resolution and internal state machine binding" process of the driver during the initialization phase. When the host-side driver is loaded and initialized, the initialization probe module in the driver reads the binary configuration parameters that were previously stored in NVRAM or hardware registers.

[0030] Binary value parsing: The configuration value obtained by the driver is an integer value (such as 0 or 1).

[0031] Response to the first preset value (e.g., 0): If the configuration value parsed by the driver is equal to the first preset value (0), the driver's internal state machine marks the MR registration path of this device instance as "driver execution mode". In this mode, the driver will initialize the memory pool, and all subsequent MR registration operations will complete the construction of MPT / MTT in the host driver memory, and directly write the mapping relationship into the underlying hardware configuration register of the network card through the DMA or MMIO interface, without calling the instruction queue on the firmware side.

[0032] Response to the second preset value (e.g., 1): If the configuration value parsed by the driver is equal to the second preset value (1), the driver's internal state machine marks the MR registration path as "firmware execution mode". In this mode, the driver disables the right to directly manipulate the underlying hardware registers to build MPT / MTT, and instead configures the command queue (Cmdq) interface for communication with the firmware. Subsequent MR registration requests will be uniformly encapsulated by the driver into instructions of a preset structure, submitted to the Cmdq for queuing, and await firmware takeover and allocation of hardware resources.

[0033] It should be noted that this parsing process is executed only once, typically during the probe phase of driver loading. If the configuration needs to be modified later, the administrator will need to modify the S110 configuration instructions and then reload the driver (or restart the host / virtual machine) for the new parsing results to take effect.

[0034] The above steps provide a clear and stable manually operable configuration path for RDMA network card MR registration by offering an explicit binary command-line configuration interface and corresponding numerical parsing logic. In actual cloud data centers or high-performance computing clusters, operations and maintenance personnel can set the network card's working mode with a single click using simple command-line commands, based on the actual deployment configuration of the current physical machine (e.g., determining whether the current network card is used for high-performance bare metal / container nodes or for nodes that pass through multiple virtual machines). This static "configure first, load later" setting method avoids unknown interference that may be caused by mode switching during operation, greatly reducing the operational threshold for operations and maintenance personnel to optimize the underlying network devices. Simultaneously, because this configuration supports writing to non-volatile memory, its configuration state remains effective even after the device is powered off and restarted, ensuring that single-node network cards can be initialized in the expected consistent mode during unified image deployment in large-scale data centers, enhancing the reliability and reproducibility of system deployment.

[0035] S200, receive a memory region registration request from the currently running instance; the memory region registration request is used to convert the address information of the physical memory region to be mapped on the host side into hardware-recognizable MPT / MTT resources.

[0036] This step is the "Initiation and Metadata Parsing" phase of the MR registration process. It determines the data interaction protocol between the host side and the application layer, and provides raw input data for subsequent mode splitting (driver processing or firmware processing).

[0037] The specific implementation is as follows:

[0038] S210, Initiate Memory Region Registration Request: The currently running instance (usually referring to the RDMA network card driver loaded within the host operating system; in a physical machine scenario, it's the PF driver, and in a virtual machine pass-through scenario, it's the VF driver) receives a memory registration instruction from an upper-layer application (such as the NVMe-oF storage protocol layer or user-space IB Verbs applications). This instruction is essentially a "hardware resource acquisition" request, which triggers the RDMA driver's mapping procedure for that host memory region. This request is typically processed as a high-priority control instruction in the driver's memory management module.

[0039] S220, Parsing Physical Memory Addresses and Generating Basic Metadata: After receiving the request, the driver parses the parameters carried in the request, mainly including: the starting virtual address (VA) of the physical memory to be mapped on the host side, the length of the memory region, and access permission attributes (local read / write, remote read / write). The driver obtains the host physical page frame number (PFN) corresponding to the virtual address by looking up a table and calculates its contiguousness or non-contiguousness in the Memory Management Unit (MMU). Through this step, the driver transforms the application-layer virtual memory abstraction into the actual physical memory description information at the system's underlying level, serving as the basic data for constructing MPT / MTT.

[0040] S230, Calculate the data payload size and prepare the registration structure: Based on the parsed physical address length and memory distribution, the driver begins calculating the amount of MTT information required for registration. In high-performance scenarios like NVMe over RDMA (encapsulating NVMe disk commands and data, originally usable only on the local host, into RDMA network packets and sending them to a remote storage server over the network), MR registration often involves mapping a large number of continuous or discrete page table entries, resulting in an extremely large MTT table (up to 256K×8B=2MB). At this point, the driver allocates a temporary storage area in the host memory, arranges the address information of the physical memory to be mapped according to the hardware-defined MTT format, forming a data payload packet to be sent, and binds this payload packet to the MR request context (containing reserved L_Key / R_Key entries). This completes the preparation for the conversion "from the host-side physical memory space to a hardware-recognizable MPT / MTT data source."

[0041] The above steps achieve "input decoupling and precise conversion" of MR registration requests from high-level applications to low-level hardware identification data. By establishing a standard parsing protocol at the driver receiver, the address information and length attributes of the host's physical memory are accurately extracted, providing rigorous raw data and mathematical basis for subsequent hardware mapping resource allocation. This step effectively accommodates the data plane memory management requirements under the NVMe over RDMA protocol. Regardless of the size of the MR registration initiated by the application layer or whether the memory is contiguous, this parsing process can accurately construct the corresponding MTT / MPT data structure. At the same time, this process cleverly reserves a data buffer area within the driver. Even when faced with a massive 2MB MTT table data structure, it will not cause host kernel memory overflow or resource contention due to sudden large memory registration requests. This provides a clear and clean input interface and state context for different processing paths between the driver and firmware, significantly improving the robustness of RDMA network cards in receiving memory registration requests and the hardware pre-processing capability in complex scenarios.

[0042] S300, according to the running configuration, allocate a processing path for the memory region registration request.

[0043] This step is the policy adjudication and business scheduling phase for MR registration requests. It serves as a bridge between the preceding and following steps, translating the static / dynamic configurations obtained by S100 into actual execution actions. The specific implementation is as follows:

[0044] S310, Read and lock the currently effective processing path state: After receiving the memory region registration request context from S200, the host-side driver immediately enters the internal MR routing scheduling module. This module first queries the global processing path state variable maintained internally by the driver, which represents the effective operating configuration of the current network card device. In this embodiment, it can be denoted as global_mr_mode.

[0045] State consistency guarantee: Since MR registration requests may face high concurrency on the high-speed data plane (e.g., multiple CPU cores initiating registration at the same time), when reading state variables, the driver will use an atomic read or a short-term spinlock protection mechanism to ensure that the state variables are not corrupted by asynchronous writes from other cores or firmware during the instant of reading.

[0046] Automatic sensing compatibility: If the scheme supports both manual configuration and automatic sensing, then global_mr_mode is actually a dynamic variable whose initial value is set by S100 and can be updated and overwritten by the hardware firmware via interrupts. S310 obtains the final, instantaneously determined operating configuration.

[0047] S320 performs path distribution and context switching: The driver's route scheduler makes conditional judgments based on the value of global_mr_mode read from S310, and completes the flow of different logic through the driver's function pointer dispatch table.

[0048] If the detected status is the first preset value (corresponding to the driver execution mode): the scheduler will directly mount the context of the current MR registration request (including physical memory address, length, permission attributes, and data temporary storage pointer) to the "data plane pass-through processing queue" corresponding to the S400. At this time, the core processing function inside the driver will be automatically pointed to the direct_hw_config_func interface, and all subsequent operations will not call the underlying firmware.

[0049] If the detected status is the second preset value (corresponding to the firmware execution mode): the scheduler attaches the context of the current MR registration request to the "Firmware Command Queue Processing (Cmdq) Module" corresponding to the S500. At this time, the driver's internal core processing function is pointed to the build_cmdq_packet_func interface, and the driver will immediately prepare to encapsulate the request into a preset format instruction and send it to the command queue.

[0050] Throughout the distribution process, the driver accurately transmits the unique transaction ID of the MR request, ensuring that when the S600 returns a result after different logical branches have been executed, it can accurately correspond to the original initiator.

[0051] The above steps decouple the initial management configuration from the actual business execution in time by building an independent MR routing scheduling module and an atomic state variable reading mechanism within the driver. This "state reading first, function pointer scheduling later" distribution logic gives the system extremely strong runtime security. Even in high-concurrency scenarios where multiple CPUs simultaneously initiate MR registration requests, the atomic reading mechanism can ensure the consistency of the processing path states it collects, avoiding misjudgments caused by multi-threaded race conditions (such as incorrectly using driver mode to write hardware registers when firmware mode should be used, causing hardware resource conflicts). At the same time, by introducing a function pointer distribution table, this routing distribution mechanism achieves scalability. It can be compatible with static requirements that rely solely on command-line configuration, and can seamlessly connect to dynamic updates that are automatically triggered by firmware in real time (after the firmware interrupts the update of global_mr_mode, the next S310 will immediately adopt the new value for scheduling and distribution). This gives the RDMA network card's MR registration process extremely strong business adaptability, greatly improving the network card's processing accuracy and robustness in high-performance computing and cloud computing virtualization hybrid scenarios.

[0052] S400, if the processing path is driver execution mode, the host-side driver directly responds to the memory region registration request on the data plane path, the driver maintains the MPT / MTT resources, and directly sends the hardware mapping relationship of the memory region to the hardware configuration register of the RDMA network card.

[0053] In this embodiment, under driver execution mode, the host-side driver directly processes the registration request on the network card's data plane path. The driver autonomously builds and maintains an MPT / MTT resource table for address translation in the host memory, bypassing intermediate firmware, and directly programs and configures the hardware mapping relationships (such as access keys, memory base addresses, and other control information) corresponding to the memory regions into the underlying hardware configuration registers of the RDMA network card. This step achieves extremely low registration latency and is suitable for bare metal or single-container scenarios that pursue ultimate performance.

[0054] Furthermore, in step S400, the host-side driver maintains the MPT / MTT resources, including the following steps:

[0055] S410, detects the number of driver instances in the physical machine environment where the current RDMA network card is located. .

[0056] On the hardware firmware side of the RDMA network card, an internal linked list of driver instances and a corresponding reference count variable (ref_cnt) are maintained. This linked list records how many driver instances are currently using this physical network card in the host system or multiple virtual machines (VMs) (for example, the host PF driver counts as one, and the pass-through VF driver counts as one).

[0057] During the initial loading and initialization process, the host-side driver sends a DRIVER_INSTANCE_ANNOUNCE command to the hardware firmware via the hardware control channel. Upon receiving this command, the firmware adds the driver instance to the linked list and increments ref_cnt by 1.

[0058] When the driver executes step S410, its internal scheduling module obtains the instance count maintained by the current hardware firmware by sending a low-level query command (or directly reading the shared status register maintained by the firmware and mapped to host memory), and assigns it to the parameter. .

[0059] S420, when detected When the value equals 1, it is determined that the current running instance is a single-driver scenario, and the MPT / MTT resources are directly mapped to the memory space of the driver on the host side for creation and maintenance.

[0060] The driver scheduler reads from S410 Perform a logical judgment. If the judgment result is... The driver confirms that the current network card is in exclusive mode, meaning that there is no interference from a second driver and it can directly take over the hardware.

[0061] After confirming the exclusive access status, the driver directly allocates a large contiguous memory pool in its kernel-mode memory space for constructing the MPT and MTT. The driver obtains the physical page frame number (PFN) of the host physical memory to be mapped by calling low-level operating system functions, fills the PFN into the MTT table entry according to the data structure format specified by the RDMA hardware, and simultaneously generates access credentials such as L_Key / R_Key.

[0062] Because it's an exclusive mode and doesn't involve firmware handover, the driver no longer uses the slow hardware command queue (Cmdq), but instead directly calls MMIO (Memory Mapped I / O) or DMA (Direct Memory Access) mechanisms. The driver directly writes the starting address and descriptor of the MPT / MTT hardware control structure, which has just been built in the host memory, into the underlying hardware configuration register (or internal hardware context table) of the RDMA network card, completing the entire pass-through registration of MR. Subsequently, the RDMA network card hardware will directly use this driver physical memory for addressing and data reading / writing.

[0063] After confirming the exclusive single-driver state, this step completely entrusts the management and construction of MPT / MTT resources to the host-side driver, and directly connects to the underlying hardware configuration registers via MMIO / DMA. This "zero firmware intervention" approach greatly simplifies the control plane process of memory region registration, bypassing the lengthy firmware command queuing, arbitration, and parsing stages. For data plane protocols that employ NVMe over RDMA and require nanosecond-level latency, this design can compress the response latency of MR registration to the extreme, fully leveraging the performance limits of direct hardware physical register connections. Simultaneously, since there is no need to send and wait for responses to firmware, it also significantly reduces the context switching cost of the host CPU during MR registration, ensuring high throughput and high stability of storage services in single-driver scenarios.

[0064] S500, if the processing path is firmware execution mode, the host-side driver encapsulates the memory region registration request into a preset format registration instruction through a hardware command queue and sends it to the hardware firmware of the RDMA network card. The hardware firmware then takes over the allocation and maintenance of the MPT / MTT resources according to the registration instruction.

[0065] In firmware execution mode, the host-side driver cannot directly manipulate the network card's underlying hardware configuration registers. Instead, it packages the memory region registration request into a preset format of hardware control instructions and sends them to the onboard hardware firmware of the RDMA network card through a dedicated hardware command queue (Cmdq). The hardware firmware acts as a global manager, uniformly taking over the actual allocation and maintenance of MPT / MTT resources and the underlying hardware mapping configuration, thereby effectively avoiding hardware resource conflicts that may occur when multiple VFSs or multiple driver instances coexist.

[0066] Furthermore, the S500 encapsulates the registration instruction in a preset format and sends it to the hardware firmware of the RDMA network card, including the following steps:

[0067] S510, Obtain the MTT information table carried in the memory region registration request, and calculate the total size of the MTT information table in bytes. .

[0068] Once the host-side driver determines that the current processing path is firmware execution mode and has parsed the MR registration request, it allocates a large temporary data buffer (temporary storage area) in its kernel-mode memory. The driver then fills this temporary storage area with the previously parsed host physical page frame number (PFN) and access attributes, strictly adhering to the MTT data structure format specified by the RDMA network card hardware protocol (such as an 8-byte / entry page table entry). After filling, the driver calls the kernel memory management function to calculate the actual byte length of the MTT information table and records this length value as an integer variable. The calculation must be accurate to the byte level to ensure that no data goes out of bounds or is missed during subsequent splitting.

[0069] S520, Obtain the single-pass receive buffer space size of the RDMA network card hardware firmware. .

[0070] During the RDMA network interface card (NIC) device initialization phase, the hardware firmware exposes its capabilities to the host-side driver. Specifically, the firmware exposes the size of its internal single-pass receive buffer (RX buffer) for receiving host commands to the driver through hardware status registers mapped to the PCIe configuration space (or dedicated BAR space). The driver reads the value of this register during the device probe phase and records it as a global constant. (For example, 10KB). Since this size is directly determined by the current physical memory capacity of the firmware, the driver must strictly adhere to this length limit in subsequent communications to avoid overwriting data and causing system crashes by directly stuffing excessively large messages into the firmware buffer.

[0071] S530, employing a splitting mechanism, divides the MTT information table into N transmission blocks; wherein, ; This is for rounding up.

[0072] Rounding up ensures that even if the remaining data is less than the size of a single buffer, it can still be allocated as a separate transfer block. Assuming... It is 2MB (approximately 2,097,152 bytes). If the value is 10KB (10240 bytes), then the calculation result is... It is approximately equal to 205. (Calculated) After the value is set, the driver will allocate a local memory containing... A linked list of transport descriptors for each indexed entry, used for subsequent batch transmissions.

[0073] S540 sequentially encapsulates N transport blocks into N independent hardware command queue instructions and sends them to the hardware firmware so that the hardware firmware can sequentially assemble and restore the complete MTT information.

[0074] The driver divides the MTT information table into segments based on the number of blocks and offsets calculated by the S530. Each transport block is encapsulated by the driver, which adds a private command header to its front. This command header contains at least three fields: ① Total data length (fixed to 10 ... ); ② Current serial number ( ); ③ End flag (indicates whether this is the last transmission block).

[0075] The driver fills each encapsulated transport block (including the header) into a separate entry in the hardware command queue (Cmdq) and notifies the hardware firmware of "new command has arrived" by performing an MMIO write operation to the network card doorbell register.

[0076] The hardware firmware retrieves each transport block sequentially from the Cmdq. Due to limited firmware buffer space, after receiving a single block, it temporarily stores it in a pre-allocated contiguous memory area within the firmware. The firmware maintains this memory space based on the "serial number" and "end flag" in the private command header. The integrity of each block is ensured. Upon receiving the last block with the end flag set to 1, the firmware sequentially splices together all temporary fragments and completely reconstructs the original block in firmware memory. A complete MTT information table. At this point, the firmware officially performs MPT / MTT resource allocation and hardware mapping operations based on the complete MTT table.

[0077] The above steps, by introducing a mathematically-based MTT data splitting mechanism at the driver layer and a sequence number-based concatenation and restoration mechanism at the firmware layer, overcome the rigid physical limitation of the small physical memory capacity (e.g., 10KB) of the underlying hardware firmware's receive buffer. This successfully enables the complete and error-free transmission of ultra-large MTT information tables, up to 2MB in size, to the firmware for unified arbitration. This "large packet splitting, sequential reassembly" hardware-software collaborative strategy eliminates the need to modify the complex underlying firmware architecture or increase the cost of expensive hardware memory chips in the firmware itself, solving the hardware resource bottleneck with software algorithms. Simultaneously, during the splitting and distribution process, the sequence number and end flag in the command header ensure high fidelity and sequential consistency in the transmission of massive concurrent command queues, avoiding the risk of MR registration failure due to out-of-order delivery or packet loss. This mechanism effectively expands the capabilities of RDMA network card hardware when registering large-scale memory regions, enabling low-cost, small-buffer firmware hardware to be safely applied in multi-tenant virtualization shared scenarios, achieving extremely high engineering cost-effectiveness and operational reliability.

[0078] S600: Based on the driver execution mode or the firmware execution mode, complete the registration of the memory region and return the registration result to the currently running instance.

[0079] Regardless of whether the registration operation is completed based on the S400 driver path or the S500 firmware path, the network card's underlying layer needs to collect the final effective memory mapping credentials (such as the L_Key / R_Key returned by the hardware) by the corresponding processing entity and return the final registration result to the currently running instance (driver) that initiated the operation. At this point, the MR registration process ends, and the RDMA network card officially obtains permission to directly access the specified host memory region via DMA read and write.

[0080] In one exemplary embodiment, since the method in the above embodiment is manually configured, resulting in a poor user experience, the following method is provided to achieve automatic switching.

[0081] Furthermore, the method also includes the following steps:

[0082] S700, in the RDMA network card firmware, a driver instance management list and reference count are set. .

[0083] In this implementation, this step is executed during the RDMA network card firmware power-on startup phase, earlier than the host driver loading. During the RDMA network card device initialization and firmware image loading process, the control module inside the firmware requests the underlying microcontroller memory to allocate a dedicated static storage space for building a "driver instance management linked list," and simultaneously initializes an integer unsigned variable reference count. And assign it the value 0.

[0084] The data structure of this management linked list contains multiple nodes, each node mainly records three key fields: ① Driver instance ID (used to uniquely identify a host-side driver); ② Startup status (marking whether it is currently online); ③ Representative function ID (i.e., ... The firmware initializes these infrastructure components during network card startup, preparing them for receiving status announcements from the host driver. Because this linked list is built within the firmware, its logic operates entirely independently of the host CPU.

[0085] S710, when any driver instance experiences a load or unload event, it interacts with the hardware firmware via preset communication commands, and the hardware firmware updates the management list and the reference count. .

[0086] In this implementation, this step is executed when triggered by an asynchronous event of host driver loading / unloading, with data flowing through the control plane. When the host-side driver loads or unloads, the driver's underlying communication module encapsulates a preset communication instruction (DRIVER_INSTANCE_ANNOUNCE command) according to a predetermined protocol. The payload of this instruction contains two core flags: ① action type (indicating whether it is "joining" or "removing" an instance); ② identifier representing the function (such as the PF's PCIe BDF number). The driver sends this instruction to the firmware through the hardware control channel. After receiving the instruction, the instruction parser inside the firmware executes the following logic according to the action type:

[0087] If the action type is "Join": The firmware searches for the instance ID in the management list. If it does not exist, it creates a new node and adds it to the list, while also updating the global reference count. Perform the +1 operation.

[0088] If the action type is "remove": The firmware traverses the management list, finds the corresponding node, deletes it, releases the related memory space, and resets the global reference count. Perform the -1 operation.

[0089] During this process, the firmware's underlying operations will strictly employ atomic operations for updates. This is to prevent counting errors in high-concurrency, hot-plugging scenarios.

[0090] S720, the hardware firmware monitors the reference count in real time. The value, if If so, it will actively trigger the switch of the current processing path to driver execution mode; if If so, it will actively trigger the switching of the current processing path to firmware execution mode.

[0091] The firmware internally maintains a high-priority mode arbitration and status monitoring process. This process is implemented after the S710 update. Then, immediately read the latest value and perform a pattern check:

[0092] like (From multiple instances to a single instance): The firmware determines that the current environment has become an exclusive scenario. It immediately triggers a hardware interrupt signal and reports it to the only driver instance in the current linked list (usually the first driver instance). After receiving the interrupt, the host driver executes the callback function of "switching to driver execution mode". Internally, the driver will clean up the MR requests that were previously placed under firmware management due to shared mode and synchronize the resource status on the firmware side to the driver side.

[0093] like (From Single Instance to Multiple Instances): The firmware determines that the current environment has changed to a shared scenario. It immediately triggers a hardware interrupt signal and reports it to the first driver instance (representing the function) in the linked list. The driver responds to the interrupt and executes the callback to "switch to firmware execution mode". At this time, the driver needs to synchronize the MR resources that already exist on the driver side to the firmware. Subsequent MR registrations are all converted to the Cmdq process corresponding to S500.

[0094] Understandably, step S100 parses the initial "runtime configuration" based on the binary command line during driver initialization; while this solution dynamically refreshes (overwrites) the "runtime configuration status variables" generated during driver initialization by actively reporting hardware interrupts through firmware. These two approaches do not conflict but rather form a complementary mechanism of "default configuration values ​​+ dynamic runtime correction."

[0095] The above steps establish a driver instance management linked list and reference counting on the firmware side, constructing a "scenario-adaptive arbitration mechanism" that is entirely based on hardware-level awareness. Compared to the solutions in the above embodiments, this automatic awareness solution completely achieves unattended operation, greatly reducing the manual configuration costs for data center operations and maintenance personnel.

[0096] By linking the DRIVER_INSTANCE_ANNOUNCE preset command with the firmware counter, the network card device can automatically detect the increase or decrease in the number of driver instances in milliseconds under dynamic business scenarios such as virtual machine (VM) hot migration and hot plugging, and actively trigger hardware interrupt callbacks, so as to seamlessly complete the switching of MR management mode without the need for host restart.

[0097] Furthermore, when the processing path switch is triggered in step S720, the method further includes the following steps:

[0098] S721, check if there is a memory region resource that has been allocated to the currently running instance; if it exists, proceed to S722; otherwise, exit the current process.

[0099] After receiving the mode switching hardware interrupt signal actively sent by the S720 hardware firmware, the host-side driver first enters the interrupt service routine (ISR), and then immediately starts the pre-mode switching resource detection process. This process quickly queries the local MR resource list maintained internally by the driver (this list records the MR context ID, L_Key / R_Key, etc. of all MR contexts that have been requested and allocated MPT / MTT and are in the "registered" state under the current running instance).

[0100] The driver traverses the linked list to determine if there are any currently used MapReduce (MR) resources. If the linked list is not empty, it records the list of currently existing MR resources and marks the system as being in a state of "dirty data to be synchronized". If the linked list is empty, it means that there are no resources that need to be transitioned at runtime, and the synchronization protection logic of S722 and S723 can be skipped directly to refresh the underlying state.

[0101] S722 establishes a synchronization critical section lock on the hardware firmware side when switching modes. The memory region resources allocated before the switch will be migrated between the host-side driver and the hardware firmware for state synchronization.

[0102] When the driver decides to migrate resources, it first writes a "synchronization flag" to the network card's underlying doorbell register or shared control register, establishing a global mutex (or critical section lock). Once the lock takes effect, all MapReduce processing modules within the driver will detect that they are currently in a lock-protected state through an atomic check. Under the protection of the lock, the driver performs the underlying data migration according to the direction of the switch:

[0103] Option 1: Exclusive to Shared (1 becomes >1, driver to firmware): The driver packages the complete control data (MPT / MTT entries, L_Key / R_Key, etc.) of the allocated MR resources detected in the S721 into a preset firmware takeover instruction packet and sends it to the hardware firmware via the command queue (Cmdq). After receiving the packet, the firmware takes over the hardware ownership of these resources. Subsequently, the driver marks the local MR copy as "migrated to firmware" and cleans up the local hardware mapping to prevent duplicate mapping.

[0104] Option 2: Shared to Exclusive (>1 becomes 1, firmware switches to driver): The driver sends a resource reclamation request command to the hardware firmware. Upon receiving the command, the firmware returns complete information about all MR resource tables currently under its control to the host driver via a command queue. The driver then reloads these MPT / MTT resources into its own memory space and rewrites them to the hardware configuration register, thus announcing the takeover is complete.

[0105] S723, during the synchronous migration process, if a registration request for a newly arrived memory region is received... ,use Will The process will be suspended and waited until the synchronization migration is complete and the new mode takes effect, after which the execution will proceed according to the new mode. .

[0106] Locks in S722 During the effective period, the driver's main entry function (MR registration and distribution interface) will respond to new MR registration requests. Perform an interception judgment.

[0107] Suspension interception: Driver checks global locks If the state is detected as high (indicating synchronization), the driver will not [process the request / action]. Instead of executing the S300 dispatch process, it puts its context (including request parameters, initiator PID, etc.) into a dedicated synchronous wait queue (Wait_Queue) and puts the thread that initiated the request into a suspended (sleep) state.

[0108] Wake-up and Retry: Once the synchronization migration in the S722 is completely complete, the hardware firmware sends a "synchronization complete" confirmation to the driver, and the driver then clears the lock. The state is determined, and the waiting queue is updated according to the latest global path state variables (which have been updated to the new mode by S720). Execute the wake-up operation one by one.

[0109] New mode execution: Awakened Upon re-entering the processing flow, it detects that the effective mode is the new mode after the switch. Therefore, it strictly follows the new state (S400 driver execution mode or S500 firmware execution mode) to successfully complete the registration process and returns a successful registration result to the application layer.

[0110] It is understandable that the processing path configuration of S100~S120 is a "pre-set" that is executed once during the moment the driver is loaded (device probe phase), and no switching is triggered at this time; while the process of S721~S723 is a dynamic adjustment period during the operation of the network card, which is only triggered after the S720 firmware detects the change in the number of instances and actively reports a hardware interrupt. The two are completely staggered in execution time. Therefore, this embodiment is a protection against dynamic runtime changes and will not interfere with the silent setting scheme. The two are progressive and complementary.

[0111] The above steps, through the introduction of a closed-loop protection mechanism of "state detection - critical section locking - request suspension," solve the system-level problem of "inconsistent resource states due to concurrent registration" that is prone to occur when RDMA network cards dynamically switch MR management paths in runtime. By establishing a synchronous critical section lock between the hardware firmware and the host driver, and promoting the precise and complete migration of the MR resources in use between the two, the risks of memory mapping failure, abnormal network card hangs, or interruption of data plane storage services caused by the handover of underlying management rights are completely eliminated. Furthermore, suspending newly arriving memory region registration requests using a waiting queue achieves a non-destructive concurrent flow control while ensuring data security. This design of "intercepting first, waiting for the switch to complete, and then precisely processing according to the new mode" is equivalent to adding a smooth "soft landing" buffer to the dynamic switching process. It takes into account the extremely stringent concurrent processing requirements in RDMA scenarios while avoiding application-layer retry storms caused by abruptly rejecting or discarding user requests, greatly improving the service continuity assurance capability of RDMA network cards in complex cloud-native virtual machine hot migration environments.

[0112] Furthermore, when the current driver instance includes a physical function (PF) and a virtual function (VF), the hardware firmware determines the first physical or virtual function to complete initialization as the representative function, and records the function ID of this representative function as... As a target identifier for communication with the host-side driver, the method further includes the following steps:

[0113] S724, Detect the current running instance. Whether the corresponding PF or VF has been removed.

[0114] In this embodiment, this step is executed at any time after the firmware completes the initialization of the "representative function" and at any time during the continuous operation of the current driver instance, once a "hot removal" event occurs in the underlying PCIe link state.

[0115] When the current driver instance is in a multi-functional (i.e., containing one PF and multiple VF) configuration state, a "representative function link status monitoring thread" is resident inside the hardware firmware. This thread continuously monitors the link status changes of the underlying PCIe bus (for example, when the virtual machine manager QEMU / KVM triggers a VF hot-plug operation, the hardware will receive a physical link removal signal).

[0116] When the monitoring thread detects a PF or VF function removal event at the underlying level, the state machine module inside the firmware first extracts the unique hardware identifier (i.e., PCIe bus / device / function number, BDF) of the removed function. Subsequently, the firmware performs a strict numerical comparison between this BDF number and the global variable Rep_func_id recorded in the firmware memory by the current driver.

[0117] If the two match (i.e., the removed function is the current representative function), it is determined that the current communication path is about to be interrupted, and the system immediately triggers the "representative function transfer" protection process and enters S725; if the two do not match, it means that the removed function is a non-core ordinary VF, the firmware does not make any special processing, the original Rep_func_id remains unchanged, and the main driver channel is not affected.

[0118] S725, if a removal event is detected, the hardware firmware automatically traverses the driver instance management list, selects a currently online PF or VF as the new representative function ID, and updates... The value is set to maintain a valid interrupt notification path between the hardware firmware and the host-side driver.

[0119] After the hardware firmware detects that a representative function has been removed, it enters the following disaster recovery sequence:

[0120] Traversing and locking the driver instance management list: The firmware acquires the mutex lock of the driver instance management list corresponding to the current driver instance to prevent data structure corruption caused by other concurrent events (such as new VF loading) during traversal.

[0121] Status filtering and node detection: The firmware kernel module traverses each functional node in the linked list sequentially, obtaining the status flag bit of each node. The firmware only selects physical or virtual functions whose current status is "loaded" and "online and healthy" as candidates.

[0122] Optimal successor election: To maintain the stability of network interface card (NIC) functionality, firmware typically selects the first online function in the discovery list as the new representative function, based on the order in which they are found. This is a fixed preemptive election logic.

[0123] Atomic update Rep_func_id: The firmware performs an atomic write operation, updating the function ID (BDF number) of the newly selected online function to the Rep_func_id register inside the hardware in real time.

[0124] Re-establishing the interrupted communication path: The firmware immediately sends a low-level hardware interrupt or control message indicating that the representative function has been updated to the host-side driver through the new representative function node. Upon receiving this notification, the host-side driver automatically refreshes the communication target ID mapping relationship within the driver. At this point, all subsequent interrupt notifications involving mode switching between the firmware and the driver (such as the counter change interrupt in S720) and resource synchronization confirmation messages will smoothly and seamlessly migrate to the new representative function path for communication, completely eliminating the risk of control plane disconnection caused by the original representative function "going offline".

[0125] The above steps provide a self-healing disaster recovery guarantee for the underlying communication link in cloud environments where multiple PF / VF coexist and a single driver instance is used, by building a real-time status monitoring mechanism and automatic backup takeover logic for the representative function within the firmware. In real-world data center operations, hot migration of virtual machines (VMs) and hardware failure repairs of physical machines often lead to the hot removal of a PF or VF of the network card. Through this step, even if the "representative function" currently acting as the communication hub in the network card is accidentally removed, the firmware can quickly rebuild the control channel with the host driver within microseconds by traversing the dynamic linked list, automatically electing and updating Rep_func_id, without restarting the device or interrupting the global driver. This greatly enhances the long-term stability and risk resistance of the same physical network card in continuous multi-tenant operation, not only meeting the core requirements of high availability for cloud computing infrastructure, but also avoiding a chain of business failures caused by the control channel interruption, which would prevent higher-level software from sensing changes in the underlying driver instance count and thus triggering incorrect MR memory registration mode switching.

[0126] Furthermore, the method also includes the following steps:

[0127] S800, when a driver instance belonging to a virtual machine is abnormally destroyed and no driver instance uninstallation command is initiated, the hardware firmware retains the residual mapping state of the driver instance.

[0128] In a normal virtualization environment, when a virtual machine performs a normal soft shutdown or driver unloading, the driver within the virtual machine actively sends a `DRIVER_INSTANCE_ANNOUNCE (Phase out)` unloading command to the underlying hardware firmware. The firmware then removes the corresponding driver instance from the management list and releases its occupied resources. However, when a virtual machine experiences an abnormal crash (such as a kernel panic or a forced power-off by the hypervisor), the VF driver process on the host side is directly terminated, without any opportunity to send the aforementioned unloading command to the firmware. At this time, the underlying hardware state machine on the RDMA network card firmware side detects that the physical PCIe link corresponding to this VF has suddenly gone offline.

[0129] The firmware's mechanism for identifying this abnormal state is as follows: although the physical link is disconnected, no corresponding protocol offload signaling is received. Therefore, to ensure data security, the hardware firmware will not actively remove the instance node from the driver instance management list. Simultaneously, the MPT / MTT resources (memory-mapped table entries), L_Key / R_Key, and other physical hardware resources previously requested and occupied by this instance on the firmware side will be marked as "allocated and locked" residual mapping states. This "freezing" process is to prevent these firmware resources from being incorrectly reused by other driver instances during an abnormal power outage, thereby preventing potential dirty data conflicts on the data plane.

[0130] S810, when the virtual machine restarts and initializes the host-side driver, the host-side driver actively sends a driver instance clearing instruction to the hardware firmware before sending a new driver instance loading notice, so as to clear the residual mapping state stored in the hardware firmware before executing the new driver instance loading process.

[0131] When the virtual machine recovers from an abnormal crash and restarts, the host operating system reloads the RDMA driver.

[0132] Actively sending a cleanup command (Phase 1): Before performing any formal MR registration or hardware resource request, the driver's initial probe routine must first execute a preprocessing procedure. It sends a specially customized "Driver Instance Residual Cleanup Command (Clear_Residual_Instance)" to the hardware firmware. This command carries the unique identifier of the current virtual machine (such as the PCIe BDF number and VM UUID).

[0133] Firmware Cleanup and Resource Reclamation (Phase Two): Upon receiving the cleanup command, the hardware firmware immediately traverses the internal driver instance management list to precisely locate any abnormal residual nodes belonging to the virtual machine. Once found, the firmware: performs atomic operations to forcibly remove the node from the list; reclaims the MPT / MTT mapping entries and hardware access keys (L_Key / R_Key) originally occupied by the node, restoring the underlying hardware resources to an idle and usable state; and clears the residual context data of the node in the firmware's local cache.

[0134] Performing the formal loading (third phase): After receiving the "cleanup complete confirmation response (Ack)" from the firmware, the driver initialization process will continue, formally sending the DRIVER_INSTANCE_ANNOUNCE (Launch) instruction, executing the normal loading logic in step S710, and notifying the firmware to add the current brand-new driver instance to the management list (at this time, the reference count is...). It will be completely accurate and unaffected by previous abnormal shutdowns.

[0135] The above steps, by constructing a passive protection strategy for abnormal virtual machine destruction and an active cleanup strategy for restarting, solve the long-standing problem of "zombie-driven instance" resource leakage in RDMA network cards in cloud computing virtualization environments. In actual high-concurrency data center operations, unexpected virtual machine crashes are common occurrences. By using S800 to "freeze" the resources of abnormally disconnected instances in place instead of releasing them immediately, out-of-order memory access caused by concurrency anomalies is effectively avoided; by using S810 to execute dedicated residual cleanup instructions before the virtual machine restarts, the firmware is forced to remove zombie nodes and reclaim hardware MPT / MTT resources, completely eliminating the system "cognitive bias" caused by abnormal power outages.

[0136] Furthermore, although the steps of the method in this disclosure are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0137] Embodiments of the present invention also provide a non-transitory computer-readable storage medium that can be disposed in an electronic device to store at least one instruction or at least one program related to implementing a method in the method embodiments, wherein the at least one instruction or the at least one program is loaded and executed by the processor to implement the method provided in the above embodiments.

[0138] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0139] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0140] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0141] Program code for performing the operations of this application can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as Java and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0142] Embodiments of the present invention also provide an electronic device, including a processor and the aforementioned non-transitory computer-readable storage medium.

[0143] The electronic device is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments in this application.

[0144] Electronic devices are manifested in the form of general-purpose computing devices. Components of an electronic device may include, but are not limited to: at least one processor, at least one memory, and a bus connecting different system components (including memory and processor).

[0145] The memory stores program code that can be executed by the processor, causing the processor to perform the steps in the various embodiments described in this specification.

[0146] The memory may include readable media in the form of volatile memory, such as random access memory (RAM) and / or cache memory, and may further include read-only memory (ROM).

[0147] The memory may also include programs / utilities having a set (at least one) of program modules, including but not limited to: an operating system, one or more application programs, other program modules, and program data, each or some combination of these examples may include an implementation of a network environment.

[0148] A bus can represent one or more of several types of bus structures, including a memory bus or memory controller, a peripheral bus, a graphics acceleration port, a processor, or a local bus that uses any of the various bus structures.

[0149] Electronic devices can also communicate with one or more external devices (e.g., keyboards, pointing devices, Bluetooth devices, etc.), one or more devices that enable user interaction with the electronic device, and / or any device that enables the electronic device to communicate with one or more other computing devices (e.g., routers, modems, etc.). This communication can be achieved through input / output (I / O) interfaces. Furthermore, electronic devices can communicate with one or more networks (e.g., local area networks (LANs), wide area networks (WANs), and / or public networks, such as the Internet) via network adapters. The network adapter communicates with other modules of the electronic device via a bus. It should be understood that other hardware and / or software modules can be used in conjunction with the electronic device, including but not limited to: microcode, device drivers, redundant processors, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0150] From the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this disclosure can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this disclosure.

[0151] Embodiments of the present invention also provide a computer program product including program code, which, when the program product is run on an electronic device, causes the electronic device to perform the steps of the methods described above in various exemplary embodiments of the present invention.

[0152] While specific embodiments of the invention have been described in detail by way of examples, those skilled in the art should understand that the examples are for illustrative purposes only and are not intended to limit the scope of the invention. Those skilled in the art should also understand that various modifications can be made to the embodiments without departing from the scope and spirit of the invention.

Claims

1. A method for memory region registration and management of an RDMA network card, characterized in that, The method includes the following steps: S100, Obtain the running configuration for the memory region registration of the RDMA network card; the running configuration indicates whether to select a mode, such as driver execution mode or firmware execution mode, as the processing path for the current registration operation; S200, Receive a memory region registration request from the currently running instance; the memory region registration request is used to convert the address information of the physical memory region to be mapped on the host side into hardware-recognizable MPT / MTT resources; S300, according to the running configuration, allocate a processing path for the memory region registration request; S400, if the processing path is driver execution mode, the host-side driver directly responds to the memory region registration request on the data plane path, the driver maintains the MPT / MTT resources, and directly sends the hardware mapping relationship of the memory region to the hardware configuration register of the RDMA network card; S500, if the processing path is firmware execution mode, the host-side driver encapsulates the memory region registration request into a preset format registration instruction through the hardware command queue and sends it to the hardware firmware of the RDMA network card. The hardware firmware then takes over the allocation and maintenance of the MPT / MTT resources according to the registration instruction. S600: Based on the driver execution mode or the firmware execution mode, complete the registration of the memory region and return the registration result to the currently running instance.

2. The memory region registration management method for an RDMA network card according to claim 1, characterized in that, Step S100 includes the following steps: S110, receive configuration instructions through the control plane of the RDMA network card; the configuration instructions are binary command-line configuration parameters; S120, parse the configuration instruction. If the value of the configuration instruction is a first preset value, then select the driver execution mode as the processing path for the current registration operation; if the value of the configuration instruction is a second preset value, then select the firmware execution mode as the processing path for the current registration operation.

3. The memory region registration management method for an RDMA network card according to claim 1, characterized in that, Step S400, in which the host-side driver maintains the MPT / MTT resources, includes the following steps: S410, detects the number of driver instances in the physical machine environment where the current RDMA network card is located. ; S420, when detected When the value equals 1, it is determined that the current running instance is a single-driver scenario, and the MPT / MTT resources are directly mapped to the memory space of the driver on the host side for creation and maintenance.

4. The memory region registration management method for an RDMA network card according to claim 1, characterized in that, The hardware firmware of S500, which encapsulates registration instructions in a preset format and sends them to the RDMA network card, includes the following steps: S510, Obtain the MTT information table carried in the memory region registration request, and calculate the total size of the MTT information table in bytes. ; S520, Obtain the single-pass receive buffer space size of the RDMA network card hardware firmware. ; S530, employing a splitting mechanism, divides the MTT information table into N transmission blocks; wherein, ; To round up; S540 sequentially encapsulates N transport blocks into N independent hardware command queue instructions and sends them to the hardware firmware so that the hardware firmware can sequentially assemble and restore the complete MTT information.

5. The memory region registration management method for an RDMA network card according to claim 1, characterized in that, The method further includes the following steps: S700, in the RDMA network card firmware, a driver instance management list and reference count are set. ; S710, when any driver instance experiences a load or unload event, it interacts with the hardware firmware via preset communication commands, and the hardware firmware updates the management list and the reference count. ; S720, the hardware firmware monitors the reference count in real time. The value, if If so, it will actively trigger the switch of the current processing path to driver execution mode; if If so, it will actively trigger the switching of the current processing path to firmware execution mode.

6. The memory region registration management method for an RDMA network card according to claim 5, characterized in that, When the processing path switch is triggered in step S720, the method further includes the following steps: S721, check if there is a memory region resource that has been allocated to the currently running instance; if it exists, proceed to S722; otherwise, exit the current process. S722 establishes a synchronization critical section lock on the hardware firmware side when switching modes. The memory region resources allocated before the switch will be migrated between the host-side driver and the hardware firmware for state synchronization. S723, during the synchronous migration process, if a registration request for a newly arrived memory region is received... ,use Will The process will be suspended and waited until the synchronization migration is complete and the new mode takes effect, after which the execution will proceed according to the new mode. .

7. The memory region registration management method for an RDMA network card according to claim 5, characterized in that, When the current driver instance contains a physical function (PF) and a virtual function (VF), the hardware firmware determines the first physical or virtual function that completes initialization as the representative function and records its function ID as follows: As a target identifier for communication with the host-side driver, the method further includes the following steps: S724, Detect the current running instance. Did the corresponding PF or VF have a removal event? S725, if a removal event is detected, the hardware firmware automatically traverses the driver instance management list, selects a currently online PF or VF as the new representative function ID, and updates... The value is set to maintain a valid interrupt notification path between the hardware firmware and the host-side driver.

8. The memory region registration management method for an RDMA network card according to claim 5, characterized in that, The method further includes the following steps: S800, when a driver instance belonging to a virtual machine is abnormally destroyed and no driver instance uninstallation command is initiated, the hardware firmware retains the residual mapping state of the driver instance. S810, when the virtual machine restarts and initializes the host-side driver, the host-side driver actively sends a driver instance clearing instruction to the hardware firmware before sending a new driver instance loading notice, so as to clear the residual mapping state stored in the hardware firmware before executing the new driver instance loading process.

9. A non-transitory computer-readable storage medium, wherein the storage medium stores at least one instruction or at least one program segment, characterized in that, The at least one instruction or the at least one program segment is loaded and executed by the processor to implement the memory region registration management method of the RDMA network card as described in any one of claims 1-8.

10. An electronic device, characterized in that, Includes a processor and the non-transitory computer-readable storage medium as described in claim 9.

Images