Lightweight RDMA virtualization method, system, device, electronic device and medium

Abstract

The present disclosure relates to a lightweight RDMA virtualization method, system, device, electronic device and medium, and in particular to the field of virtualization technology. The method comprises: obtaining configuration parameters of virtual devices, the configuration parameters including the set number of virtual devices; allocating a corresponding number of network devices to the set number of virtual devices; wherein the network addresses of the virtual devices and the network devices correspond; obtaining idle resources based on a global resource bitmap query, and allocating the idle resources to the set number of virtual devices; wherein the resource identifiers of the virtual devices and the idle resources correspond. The embodiment of the present disclosure implements a lightweight virtualization function based on software on a hardware device by managing the resource allocation of virtual devices.

Description

Technical Field

[0001] The present disclosure relates to the field of embedded technology, and in particular to a lightweight RDMA virtualization method, system, device, electronic device, and medium. Background Art

[0002] Scalable Function (SF) is a hardware virtualization technology used to provide high-performance network and storage device virtualization. SF allows physical devices to be divided into multiple virtual devices, each of which has independent performance and functions and can be directly accessed by different virtual machines or containers.

[0003] Currently, common SF implementations primarily use Remote Direct Memory Access (RDMA) hardware to partition PCIE BAR space during resource allocation. Each BAR space is then assigned to a different SF virtual device, allowing the driver software for each SF virtual device to read and write registers corresponding to each BAR space, enabling independent operation and achieving lightweight virtualization. The specific process is as follows: the RDMA IP core responds to SF configuration commands issued by the device firmware, partitions the PCIE BAR space, then cold-restarts the device to enable the SF configuration, and then loads the host driver to recognize the SF configuration, thereby implementing SF functionality on the hardware device. Device firmware is the manufacturer's control software running on the device, providing an access interface for the host driver.

[0004] However, existing solutions require the hardware itself to support SF functions, which is hardware-dependent and has limited compatibility. The RDMA IP core also requires additional design to implement SF functions, which increases the hardware complexity. In addition, cold restarting the device will affect other tasks currently being performed by the device, which limits the solution's use cases. Summary of the Invention

[0005] To solve the above technical problems or at least partially solve the above technical problems, the present disclosure provides a lightweight RDMA virtualization allocation method, system, apparatus, electronic device and medium, which can implement SF functions based on software on hardware devices by managing resource allocation of virtual devices.

[0006] In order to achieve the above objectives, the technical solutions provided by the embodiments of the present disclosure are as follows:

[0007] In a first aspect, the present disclosure provides a lightweight RDMA virtualization method, comprising:

[0008] Obtain configuration parameters of the virtual device, including the set number of virtual devices;

[0009] Allocating a corresponding number of network devices to a set number of virtual devices; wherein the network addresses of the virtual devices and the network devices correspond to each other;

[0010] Based on the global resource bitmap query, the idle resources are obtained and the idle resources are allocated to a set number of virtual devices; wherein the virtual devices correspond to the resource identifiers of the idle resources.

[0011] As an optional implementation of the embodiment of the present disclosure, the global resource bitmap includes: a global resource bitmap corresponding to a queue pair QP;

[0012] Get idle resources based on the global resource bitmap query and allocate them to a set number of virtual devices, including:

[0013] Based on the global resource bitmap corresponding to the QP, query the idle QP;

[0014] When idle QPs are found, they are allocated to a set number of virtual devices.

[0015] A correspondence between the QP identifiers of the idle QPs and the set number of virtual devices is established.

[0016] As an optional implementation of the embodiment of the present disclosure, after establishing the correspondence between the QP identifiers of the idle QPs and the set number of virtual devices, the method further includes:

[0017] receiving a general service interface (GSI) data packet transmitted by a first virtual device, wherein the first virtual device is any one of a set number of virtual devices, and the GSI data packet includes a destination address and an original QP identifier;

[0018] Based on the mapping table, check whether the original QP identifier corresponds to the destination address; the mapping table is used to represent the correspondence between the network address and the GSI QP identifier;

[0019] In the case that the original QP identifier does not correspond to the destination address, the original QP identifier is modified to the target QP identifier according to the mapping table to obtain a GSI corrected data packet;

[0020] According to the target QP identifier, the GSI correction data packet is transmitted to the second virtual device corresponding to the destination address.

[0021] As an optional implementation of the embodiment of the present disclosure, after transmitting the GSI correction data packet to the second virtual device corresponding to the destination address according to the target QP identifier, the method further includes:

[0022] Obtain the GSI data packet to be replied from the second virtual device;

[0023] Determine the pending QP identifier of the GSI data packet to be replied based on the mapping table and the network address corresponding to the second virtual device;

[0024] If the pending QP identifier is not the preset QP identifier, the pending QP identifier is modified to the preset QP identifier to obtain a GSI data packet to be processed;

[0025] The GSI data packet to be processed is transmitted to the first virtual device.

[0026] As an optional implementation of the embodiment of the present disclosure, after obtaining the configuration parameters of the virtual devices and before allocating a corresponding number of network devices to a set number of virtual devices, the method further includes:

[0027] Configure virtual devices according to the set quantity through the driver software resource management layer;

[0028] A set number of virtual devices share the global hardware resources of the RDMA IP core.

[0029] As an optional implementation of the embodiment of the present disclosure, after allocating a corresponding number of network devices to a set number of virtual devices, obtaining idle resources based on a global resource bitmap query, and before allocating the idle resources to the set number of virtual devices, the method further includes:

[0030] Determine the target virtual device for resource application through the driver software resource management layer;

[0031] Based on the global resource bitmap query, the idle resources are obtained and allocated to a set number of virtual devices, including:

[0032] Get free resources by querying the global resource bitmap through the resource management layer of the driver software;

[0033] Allocate idle resources to the target virtual device.

[0034] In a second aspect, the present disclosure provides a lightweight RDMA virtualization system, which includes: a virtual device, a high-speed serial computer expansion bus standard base address register PCIE BAR space and a remote direct memory access hardware RDMA IP core, a driver software resource management layer, and a network device MAC layer outside the RDMA core;

[0035] Among them, the driver software resource management layer is used to: obtain configuration parameters of virtual devices, the configuration parameters include a set number of virtual devices; allocate a corresponding number of network devices to the set number of virtual devices; wherein the virtual devices correspond to the network addresses of the network devices; obtain idle resources based on the global resource bitmap query, and allocate the idle resources to the set number of virtual devices; wherein the virtual devices correspond to the resource identifiers of the idle resources.

[0036] In a third aspect, the present disclosure provides a lightweight RDMA virtualization device, the device comprising:

[0037] An acquisition module is used to: acquire configuration parameters of the virtual device, the configuration parameters including the set number of virtual devices;

[0038] An allocation module is used to: allocate a corresponding number of network devices to a set number of virtual devices; wherein the virtual devices correspond to the network addresses of the network devices; obtain idle resources based on a global resource bitmap query, and allocate the idle resources to a set number of virtual devices; wherein the virtual devices correspond to the resource identifiers of the idle resources.

[0039] In a fourth aspect, the present disclosure provides an electronic device comprising: a processor, a memory, and a computer program stored in the memory and executable on the processor, wherein when the computer program is executed by the processor, the lightweight RDMA virtualization method according to the first aspect or any one of its optional embodiments is implemented.

[0040] In a fifth aspect, the present disclosure provides a computer-readable storage medium, comprising: a computer program stored on the computer-readable storage medium, and when the computer program is executed by a processor, it implements the lightweight RDMA virtualization method as described in the first aspect or any one of its optional embodiments.

[0041] In a sixth aspect, the present disclosure provides a computer program product, comprising: the computer program product comprises a computer program, and when the computer program runs on a computer, the computer implements the lightweight RDMA virtualization method as described in the first aspect or any one of its optional embodiments.

[0042] The technical solution provided by the embodiments of the present disclosure has the following advantages over the prior art:

[0043] The embodiments of the present disclosure provide a lightweight RDMA virtualization method, system, device, electronic device, and medium, wherein the method first obtains configuration parameters of virtual devices, the configuration parameters including a set number of virtual devices, and then allocates a corresponding number of network devices to the set number of virtual devices, so that the network addresses of the virtual devices and the network devices correspond to each other; then, based on a global resource bitmap query, idle resources are obtained, and the idle resources are allocated to the set number of virtual devices, so that the resource identifiers of the virtual devices and the idle resources correspond to each other. In this way, the present disclosure manages the resource allocation of virtual devices and implements the SF function based on software on a hardware device, even if the hardware device does not support the SF function; effectively reduces the hardware dependency of the SF function implementation, and eliminates the need for additional complex design of the RDMA IP core at the hardware level, thereby reducing the difficulty of hardware development and eliminating the need for a cold restart, avoiding adverse effects on other tasks, and improving the scenario adaptability of the SF function implementation. BRIEF DESCRIPTION OF THE DRAWINGS

[0044] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present disclosure and, together with the description, serve to explain the principles of the present disclosure.

[0045] In order to more clearly illustrate the embodiments of the present disclosure or the technical solutions in the prior art, the following briefly introduces the drawings required for use in the embodiments or the description of the prior art. Obviously, for ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0046] Figure 1A This is a schematic diagram of the RDMA architecture;

[0047] Figure 1B It is a schematic diagram of the existing SF implementation scheme;

[0048] Figure 2A A schematic diagram of the architecture of a lightweight RDMA virtualization system provided in an embodiment of the present disclosure;

[0049] Figure 2B A flowchart of a lightweight RDMA virtualization method according to an embodiment of the present disclosure is shown;

[0050] Figure 2C A schematic diagram of the GSI service provided by an embodiment of the present disclosure;

[0051] Figure 3 A schematic diagram of the structure of a lightweight RDMA virtualization device provided in an embodiment of the present disclosure;

[0052] Figure 4 A structural diagram of an electronic device is provided in accordance with an embodiment of the present disclosure. DETAILED DESCRIPTION

[0053] In order to more clearly illustrate the technical solutions in the embodiments of the present disclosure or the prior art, the following briefly introduces the technical terms required to be used in the embodiments or the prior art description:

[0054] Remote Direct Memory Access (RDMA) is a computer network technology that allows two nodes on a network to directly access each other's memory to complete data communication without the involvement of the operating system. Due to its advantages such as low latency and high bandwidth, it has been increasingly widely used in high-performance computing, big data processing, cloud computing, and distributed storage. Figure 1A As shown, Figure 1A The following is a schematic diagram of the RDMA architecture. The RDMA architecture consists of a user layer, a driver layer, and hardware. The user layer includes user applications (user apps) and software interfaces (verbs APIs); the driver layer includes the RDMA driver; and the hardware includes the RDMA IP core and network devices (Media Access Control, MAC devices).

[0055] The RDMA IP core is key hardware in RDMA, typically a Field Programmable Gate Array (FPGA) or Reduced Instruction Set Computing (RISC) device. It implements the RDMA protocol, including processing user-submitted RDMA tasks and unpacking RDMA packets. The RDMA IP core possesses physical resources such as queue pairs (QPs), memory regions (MRs), completion queues (CQs), protection domains (PDs), double-data-rate synchronous dynamic random access memory (DDRs), and registers. RDMA packets are ultimately encapsulated into Ethernet frames and transmitted through network devices.

[0056] A queue pair (QP), consisting of a send queue (SQ) and a receive queue (RQ), stores RDMA communication requests and is the basic unit of RDMA communication. A small number of QPs are reserved and cannot be used for user data communication.

[0057] A Media Access Control (MAC) device is a device that operates at the data link layer in the Open Systems Interconnection Model (OSI) network communication theory framework. It is used to control the transmission and access of data in the network. Common MAC devices include network cards, bridges, etc.

[0058] The high-speed serial computer expansion bus standard, Peripheral Component Interconnect Express (PCIE), is primarily used to connect the motherboard's central processing unit (CPU) to various external devices, such as graphics cards, sound cards, and hard drives. The PCIE bus replaced the traditional Peripheral Component Interconnect (PCI) bus, offering faster transmission speeds and more channels to better meet the demands of modern computer hardware.

[0059] Devices on the PCIE bus use the allocated base address register (BAR) space to store and access configuration space, memory space, and input / output (I / O) space. The PCIE BAR space is an interface for communication between PCIE devices and the motherboard. It contains the device's address, data, control, and other information. Different PCIE devices can have different PCIE BAR spaces, and the motherboard needs to correctly configure and access the device based on the device's PCIE BAR space. The PCIE BAR space plays a key role in computer hardware systems. Through the PCIE BAR space, the motherboard can identify and configure PCIE devices, and PCIE devices can communicate and transfer data with the motherboard. Different PCIE BAR spaces have different functions, and together they constitute the interface between PCIE devices and the motherboard.

[0060] At present, the general SF implementation solution mainly divides the PCIE BAR space through RDMA devices and allocates each BAR space to different SF virtual devices, such as Figure 1B As shown, Figure 1B This is a schematic diagram of the existing SF implementation scheme. The figure divides the PCIE BAR space into: SF0, SF1, SF2, SF3, and allocates them to the corresponding SF virtual devices: rdma_sf_dev0, rdma_sf_dev1, rdma_sf_dev2, rdma_sf_dev3. In this way, each SF virtual device can drive the software to read and write the registers corresponding to each BAR space, realize independent operation, and achieve the purpose of lightweight virtualization.

[0061] The specific process is as follows: The RDMA IP core responds to the SF configuration command issued by the device firmware, allocates the PCIE BAR space, then cold-restarts the device to make the SF configuration effective. The host driver is then loaded to recognize the SF configuration, thus implementing SF functionality on the hardware device. The device firmware is the manufacturer's control software running on the device, providing an access interface for the host driver. Each SF virtual device is mapped to a corresponding BAR space address. When controlling the SF virtual device, the host directly accesses the corresponding BAR space address to complete related operations.

[0062] However, existing solutions require the hardware itself to support the SF function, which is hardware-dependent and has limited compatibility. SF is not a standard RDMA function, and the RDMA IP core requires additional complex design to implement SF. The high hardware complexity is also not conducive to the encapsulation of the RDMA IP core. In addition, cold restarting the device will have an unacceptable impact on other tasks currently being performed by the device, which leads to certain restrictions on the solution's use cases.

[0063] In order to solve some or all of the technical problems existing in the related art, the embodiments of the present disclosure provide a lightweight RDMA virtualization method, system, device, electronic device and storage medium, wherein the method first obtains the configuration parameters of the virtual device, which includes a set number of virtual devices, and then allocates a corresponding number of network devices to the set number of virtual devices, so that the network addresses of the virtual devices and the network devices correspond to each other; then, based on the global resource bitmap query, the idle resources are obtained, and the idle resources are allocated to the set number of virtual devices, so that the resource identifiers of the virtual devices and the idle resources correspond to each other. In this way, the present disclosure implements the SF function based on software on the hardware device by managing the resource allocation of virtual devices, even if the hardware device does not support the SF function, effectively reducing the hardware dependence of the SF function implementation; there is no need to make additional complex designs for the RDMA IP core at the hardware level, thereby reducing the difficulty of hardware development, and no cold restart is required, avoiding adverse effects on other tasks, and improving the scenario adaptability of the SF function implementation.

[0064] In order to more clearly understand the above-mentioned objectives, features and advantages of the present disclosure, the scheme of the present disclosure will be further described below. It should be noted that the embodiments of the present disclosure and the features therein can be combined with each other in the absence of conflict.

[0065] In the following description, many specific details are set forth to facilitate a full understanding of the present disclosure, but the present disclosure may also be implemented in other ways different from those described herein; it is obvious that the embodiments in the specification are only part of the embodiments of the present disclosure, rather than all of the embodiments.

[0066] A lightweight RDMA virtualization method provided in the embodiments of the present disclosure can be implemented by a resource allocation device or an electronic device, and the electronic device includes but is not limited to a server, a personal computer, a laptop computer, a tablet computer, a smart phone, etc. The operating system of the electronic device may include Android, a mobile operating system (iOS) developed by Apple, an operating system (Windows) developed by Microsoft Corporation of the United States, etc., and the embodiments of the present disclosure are not limited to this. The electronic device can be run alone to implement the present disclosure, or it can be connected to a network and implement the present disclosure through interactive operations with other computer devices in the network. Among them, the network in which the electronic device is located includes but is not limited to the Internet, a wide area network, a metropolitan area network, a local area network, a virtual private network (VPN) network, etc.

[0067] It should be noted that the protection scope of the lightweight RDMA virtualization method described in the embodiment of the present disclosure is not limited to the execution order of the steps listed in this embodiment. All solutions implemented by adding, subtracting, or replacing steps in the existing technology based on the principles of the present disclosure are included in the protection scope of the present disclosure.

[0068] like Figure 2A As shown, Figure 2A This is a schematic diagram of the architecture of a lightweight RDMA virtualization system provided by an embodiment of the present disclosure. The illustrated architecture includes virtual devices, a driver software resource management layer, PCIe BAR space, an RDMA IP core, and a MAC layer outside the RDMA core. The virtual devices include: rdma_sf_dev0, rdma_sf_dev1, rdma_sf_dev2, and rdma_sf_dev3. It should be noted that the number of virtual devices shown is for illustrative purposes only.

[0069] The driver software resource management layer is used to obtain virtual device configuration parameters, including the set number of virtual devices; allocate a corresponding number of network devices to the set number of virtual devices; the virtual devices and network devices have corresponding network addresses; obtain idle resources based on a global resource bitmap query and allocate the idle resources to the set number of virtual devices; the virtual devices and idle resource identifiers correspond to each other. This layer is responsible for logically partitioning and managing the hardware resources owned by the RDMA IP core and providing SF control functions to the user layer.

[0070] The MAC layer outside the RDMA core is used to modify the General Service Interface (GSI) service data packets for each virtual device. Based on the principle, the QP identifier is changed to 1. It should be noted that GSI services are a set of management services for RDMA. The RDMA specification stipulates that GSI uses the internally reserved QP numbered 1 to provide services. It is understood that each virtual device must have a QP that handles GSI services, and this QP must be numbered 1.

[0071] like Figure 2B As shown, Figure 2B This is a flow chart of a lightweight RDMA virtualization method according to an embodiment of the present disclosure. The method can be executed by a lightweight RDMA virtualization device, wherein the device can be implemented in software and / or hardware and can generally be integrated into an electronic device. Figure 2B As shown, the method mainly includes the following steps S201 to S203:

[0072] S201. Obtain configuration parameters of a virtual device.

[0073] Configuration parameters include, but are not limited to, the number of virtual devices. Configuration parameters can be modified.

[0074] Optionally, the configuration parameters of the virtual device input by the user are received. It is understood that the number of SF virtual devices can be specified by the user.

[0075] refer to Figure 2A , specifically step S201 is to receive the configuration parameters of the virtual device input by the user by the driver software resource management layer. In some embodiments, reference Figure 2A , through the driver software resource management layer, virtual devices are configured according to the set number; the set number of virtual devices share the global hardware resources of the RDMA IP core, and different virtual devices are controlled to only access the corresponding hardware resources.

[0076] S202: Allocate a corresponding number of network devices to a set number of virtual devices.

[0077] The virtual device corresponds to the network address (MAC address) of the network device. Each virtual device is bound to a network device, which is used to send and receive Ethernet data packets.

[0078] In some embodiments, the target virtual device for requesting resources is determined by driving the software resource management layer, so that resources are allocated to the target virtual device during subsequent idle resource allocation, thereby achieving on-demand allocation.

[0079] S203 : Obtain idle resources based on a global resource bitmap query, and allocate the idle resources to a set number of virtual devices.

[0080] The virtual device corresponds to the resource identifier of the idle resource.

[0081] Optionally, the driver resource management layer searches the RDMA IP core global hardware resources to check whether there are idle resources. If idle resources are found, they are allocated to the virtual device.

[0082] Idle resources include, but are not limited to, queue pairs (QPs), memory regions (MRs), completion queues (CQs), protection domains (PDs), and double-rate synchronous dynamic random access memory (DDRs). A global resource bitmap exists for each resource, such as the global resource bitmap corresponding to a QP. The queue pair (QP) is used to process GSI services.

[0083] In some embodiments, in the aforementioned embodiment, after the driver software resource management layer determines the target virtual device for resource application, step S203 includes: first, querying the driver software resource management layer based on the global resource bitmap to obtain idle resources, and then allocating the idle resources to the target virtual device. This achieves dynamic partitioning of idle resources and allocates idle resources to the target virtual device as needed, thereby avoiding resource waste.

[0084] The following describes a possible implementation of step S203 by taking the idle resources including the queue pair QP as an example:

[0085] In some embodiments, a free QP is first queried based on the global resource bitmap corresponding to the queue pair QP. If a free QP is found, the free QP is allocated to a set number of virtual devices, and a correspondence is established between the QP identifier of the free QP and the set number of virtual devices. The QP identifier of the free queue pair QP may be a GSIQP Number.

[0086] Specifically, an idle queue pair QP is queried based on the global resource bitmap corresponding to the queue pair QP. If an idle queue pair QP is found, the idle queue pair QP is allocated to a set number of virtual devices. A bit is set in the global resource bitmap corresponding to the queue pair QP to mark the idle queue QP as belonging to the set number of virtual devices. This establishes a correspondence between the queue pair QP identifier and the idle queue pair QP. If no idle queue pair QP is found, resource allocation is terminated. This disclosure does not elaborate on this further.

[0087] In the above embodiment, resources are allocated through software to implement the SF function on the hardware device. The RDMA IP core is unaware of the process, which reduces the dependence of the SF function on the hardware. After resource allocation, each virtual device can directly use the hardware resources of the RDMA IP core, and only logical division is performed, which reduces performance loss.

[0088] In some embodiments, after step S202 (assigning a corresponding number of network devices to a set number of virtual devices), each virtual device is already bound to a corresponding MAC device, and can process GSI services and send and receive GSI packets through the corresponding MAC device. Optionally, after step S203 (obtaining idle resources based on a global resource bitmap query and allocating the idle resources to a set number of virtual devices), a GSI packet transmitted by a first virtual device is first received via an idle QP. This first virtual device is any one of the set number of virtual devices. The GSI packet includes a destination address and an original QP identifier. A mapping table is then used to check whether the original QP identifier corresponds to the destination address. If the original QP identifier does not correspond to the destination address, the original target QP is modified to the target QP identifier according to the mapping table to obtain a modified GSI packet. The modified GSI packet is then transmitted to a second virtual device corresponding to the destination address according to the target QP identifier.

[0089] The mapping table is used to store the correspondence between the network address and the QP identifier, as shown in Table 1 below:

[0090] Table 1

[0091] Network address GSIQP logo MAC0 GSIQP01 MAC1 GSIQP21 MAC2 GSIQP31 MAC3 GSIQP51

[0092] As shown in Table 1, GSIQP01 indicates queue pair QP1, GSIQP21 indicates queue pair QP21, GSIQP31 indicates queue pair QP31, and GSIQP51 indicates queue pair QP51. The MAC address of virtual device rdma_sf_dev0 is MAC0, and its corresponding GSIQP identifier is GSIQP01; the MAC address of virtual device rdma_sf_dev1 is MAC1, and its corresponding GSIQP identifier is GSIQP21; the MAC address of virtual device rdma_sf_dev2 is MAC2, and its corresponding GSIQP identifier is GSIQP31; and the MAC address of virtual device rdma_sf_dev3 is MAC3, and its corresponding GSIQP identifier is GSIQP51.

[0093] The use of queue pair QP1 complies with the RDMA specification and can be used to process GSI services. However, as in the aforementioned embodiment, each virtual device in the present disclosure has its own corresponding QP, and the QP identifier is not necessarily QP01. Referring to Table 1, except for virtual device rdma_sf_dev0, which can use queue pair QP1 identified by GSIQP01, the remaining virtual devices do not have a queue pair numbered 1 that complies with the RDMA specification to process GSI services.

[0094] Therefore, when processing GSI services, the disclosed embodiment performs corrections based on the mapping table shown in Table 1 to comply with the RDMA specification. Specifically, upon receiving a GSI packet, the destination address and original QP identifier contained therein are parsed. Due to the requirements of the RDMA specification, the original QP identifier is GSIQP01. A determination is then made as to whether the destination address is MAC0. If so, the GSI packet should be received and processed by the virtual device rdma_sf_dev0 and transmitted to the virtual device rdma_sf_dev0. If not, this indicates that the original QP identifier GSIQP01 does not correspond to the destination address and has been corrected to comply with the RDMA specification. In this case, the original QP identifier GSIQP01 is modified according to the mapping table, being converted to the target QP identifier corresponding to the destination address in the mapping table. This results in a corrected GSI packet. Furthermore, the corrected GSI packet is transmitted to the second virtual device corresponding to the destination address according to the target QP identifier. This ensures accurate transmission of the GSI packet to the second virtual device, improving the accuracy of GSI service execution.

[0095] For example, Figure 2C As shown, Figure 2C Schematic diagram of the GSI service provided by an embodiment of the present disclosure. When a GSI data packet is received through the RDMA out-of-core MAC layer, the GSI data packet is parsed. The destination address is MAC2 and the original QP identifier is GSIQP01, indicating that the GSI data packet needs to be sent to the virtual device rdma_sf_dev2. Referring to Table 1 above, it is detected that the original QP identifier GSIQP01 does not correspond to the destination address rdma_sf_dev2. Based on Table 1 above, the original QP identifier GSIQP01 is modified to the target QP identifier GSIQP31, resulting in a GSI correction data packet with the destination address MAC2 and the target QP identifier GSIQP31. The GSI correction data packet is then transmitted to the second virtual device rdma_sf_dev2 corresponding to the destination address MAC2 according to the target QP identifier GSIQP31.

[0096] In the above embodiment, based on the mapping table and the destination address included in the GSI data packet, the original QP identifier is modified to the correct target QP identifier, so that the modified GSI correction data packet is accurately transmitted to the virtual device corresponding to the destination address for processing, thereby achieving accurate transmission of the GSI data packet between the first virtual device and the second virtual device, and ensuring the accurate implementation of the GSI service.

[0097] In some embodiments, the second virtual device can reply to the first virtual device, optionally obtaining the GSI data packet to be replied of the second virtual device, and determining the GSI data packet to be replied based on the mapping table and the network address corresponding to the second virtual device; when the pending QP identifier is not the preset QP identifier, the pending QP identifier is modified to the preset QP identifier to obtain the GSI data packet to be processed, and then transmit the GSI data packet to be processed to the first virtual device.

[0098] The preset QP identifier is a QP identifier that complies with the RDMA specification, GSIQP01.

[0099] For example, follow the above example and refer to Figure 2C As shown, the second virtual device rdma_sf_dev2 needs to reply to the GSI correction data packet. First, a GSI data packet to be replied including the reply content is obtained. The network address corresponding to the second virtual device is MAC2. Referring to the mapping table shown in Table 1 above, the pending QP identifier of the GSI data packet to be replied is GSIQP31, which is not GSIQP01 and does not comply with the RDMA specification and cannot be transmitted. Then, the pending QP identifier is modified to the preset QP identifier GSIQP01, which now complies with the RDMA specification. The pending GSI data packet with the QP identifier GSIQP01 is obtained and can be transmitted to the first virtual device to complete the reply to the GSI correction data packet transmitted by the first virtual device, so that the second virtual device can reply to the first virtual device, thereby realizing communication interaction between virtual devices that complies with the RDMA specification.

[0100] The above embodiment is a scenario in which a GSI packet transmitted from a first virtual device to a second virtual device is received via an RDMA IP core, and the second virtual device then replies to the first virtual device. It should be noted that prior to this, the process also includes: the first virtual device transmits a GSI packet to the second virtual device via the RDMA IP core. This process first obtains the GSI packet, determines the network address and QP identifier of the second virtual device, and transmits the packet to the first virtual device via the RDMA IP core if the QP identifier is a preset QP identifier (GSIQP01). If the QP identifier is not a preset QP identifier, the QP identifier in the GSI packet is modified to the preset QP identifier to comply with the RDMA specification, and then transmitted to the first virtual device via the RDMA IP core.

[0101] After step S203 is executed, the virtual device configuration is completed, and the driver software can also be used to initialize and load other functions. When the driver software is loaded, the SF function can be implemented on the hardware device without restarting the device and the host.

[0102] In some embodiments, the present disclosure supports configuration parameter modification. When the configuration parameters of the modified virtual device are obtained, the specific implementation method is the same as the implementation method involved in the aforementioned embodiments, and the present disclosure will not go into details here, thereby supporting the modification of the configuration parameters of the virtual device, reloading the driver software after modification, and realizing the SF function of the hardware device, which is simple, convenient and highly scalable.

[0103] In the above embodiment, the SF function is implemented through simple and quick configuration and initialization together with the driver software. When the configuration parameters are modified, only the driver needs to be reloaded without restarting the host device, thereby avoiding the adverse effects of restart on other tasks running on the device and improving the scenario adaptability of the SF function.

[0104] In summary, the lightweight RDMA virtualization method provided by the embodiments of the present disclosure first obtains the configuration parameters of the virtual devices, including a set number of virtual devices. It then allocates a corresponding number of network devices to the set number of virtual devices, so that the network addresses of the virtual devices and the network devices correspond. It then obtains idle resources based on a global resource bitmap query and allocates the idle resources to the set number of virtual devices, so that the resource identifiers of the virtual devices and the idle resources correspond. In this way, the present disclosure implements the SF function on a hardware device based on software by managing the resource allocation of virtual devices. Even if the hardware device does not support the SF function, this effectively reduces the hardware dependency of the SF function implementation. It eliminates the need for additional complex design of the RDMA IP core at the hardware level, thereby reducing the difficulty of hardware development and eliminating the need for a cold restart, which avoids adverse effects on other tasks and improves the scenario adaptability of the SF function implementation.

[0105] like Figure 3 As shown, Figure 3 A schematic diagram of the structure of a lightweight RDMA virtualization device provided in an embodiment of the present disclosure, the device comprising:

[0106] The acquisition module 301 is used to: acquire configuration parameters of the virtual device, wherein the configuration parameters include a set number of virtual devices;

[0107] The allocation module 302 is used to: allocate a corresponding number of network devices to the set number of virtual devices; wherein the virtual devices correspond to the network addresses of the network devices; obtain idle resources based on a global resource bitmap query, and allocate the idle resources to the set number of virtual devices; wherein the virtual devices correspond to the resource identifiers of the idle resources.

[0108] In some embodiments, the global resource bitmap includes: a global resource bitmap corresponding to a queue pair QP; the allocation module 302, in the process of obtaining idle resources based on the global resource bitmap query and allocating the idle resources to a set number of virtual devices, is specifically configured to: query an idle QP based on the global resource bitmap corresponding to the QP; when the idle QP is found, allocate the idle QP to the set number of virtual devices; and establish a correspondence between the QP identifier of the idle QP and the set number of virtual devices.

[0109] In some embodiments, after establishing a correspondence between the QP identifier of the idle QP and the set number of virtual devices, the allocation module 302 is further configured to: receive a general service interface (GSI) data packet transmitted by a first virtual device; wherein the first virtual device is any one of the set number of virtual devices, and the GSI data packet includes a destination address and an original QP identifier; detect, based on a mapping table, whether the original QP identifier corresponds to the destination address; the mapping table is used to indicate a correspondence between a network address and a GSIQP identifier; if the original QP identifier does not correspond to the destination address, modify the original QP identifier to a target QP identifier according to the mapping table to obtain a modified GSI data packet; and transmit the modified GSI data packet to a second virtual device corresponding to the destination address according to the target QP identifier.

[0110] In some embodiments, after transmitting the GSI correction data packet to the second virtual device corresponding to the destination address according to the target QP identifier, the allocation module 302 is further configured to: obtain a pending GSI data packet from the second virtual device; determine a pending QP identifier of the pending GSI data packet based on the mapping table and the network address corresponding to the second virtual device; if the pending QP identifier is not a preset QP identifier, modify the pending QP identifier to the preset QP identifier to obtain a pending GSI data packet; and transmit the pending GSI data packet to the first virtual device.

[0111] In some embodiments, after obtaining the configuration parameters of the virtual device, the acquisition module 301 is further used to configure the virtual devices according to the set number through the driver software resource management layer; wherein the set number of virtual devices share the global hardware resources of the RDMA IP core.

[0112] In some embodiments, the allocation module 302, after allocating a corresponding number of network devices to the set number of virtual devices, obtains idle resources based on a global resource bitmap query, and before allocating the idle resources to the set number of virtual devices, is further used to: determine the target virtual device for requesting resources through the driver software resource management layer; the allocation module 302 obtains idle resources based on a global resource bitmap query and allocates the idle resources to the set number of virtual devices, specifically for: obtaining idle resources based on a global resource bitmap query through the driver software resource management layer; and allocating the idle resources to the target virtual device.

[0113] like Figure 4 As shown, Figure 4 The present disclosure provides a schematic structural diagram of an electronic device, comprising a processor 401, a memory 402, and a computer program stored in the memory 402 and executable on the processor 401. When executed by the processor 401, the computer program implements the various processes of the lightweight RDMA virtualization method described in the aforementioned method embodiment. The aforementioned embodiments achieve the same technical effects, and therefore, to avoid repetition, are not described here.

[0114] The embodiments of the present disclosure provide a computer-readable storage medium storing a computer program. When the computer program is executed by a processor, the various processes of the lightweight RDMA virtualization method in the above-mentioned method embodiment are implemented, and the same technical effects are achieved. To avoid repetition, they are not described here.

[0115] The computer-readable storage medium may be a read-only memory (ROM), a random access memory (RAM), a magnetic disk, or an optical disk.

[0116] The embodiments of the present disclosure provide a computer program product that stores a computer program. When the computer program is executed by a processor, the various processes of the lightweight RDMA virtualization method in the above-mentioned method embodiment are implemented, and the same technical effects can be achieved. To avoid repetition, they are not described here.

[0117] Those skilled in the art will appreciate that embodiments of the present disclosure may be provided as methods, systems, or computer program products. Thus, the present disclosure may take the form of an entirely hardware embodiment, an entirely software embodiment, or an embodiment combining software and hardware. Furthermore, the present disclosure may take the form of a computer program product implemented on one or more computer-usable storage media containing computer-usable program code.

[0118] In the several embodiments provided by the present disclosure, it should be understood that the disclosed devices and methods can also be implemented in other ways. The device embodiments described above are merely illustrative. For example, the flowcharts and block diagrams in the accompanying drawings show the possible architectures, functions and operations of the devices, methods and computer program products according to the multiple embodiments of the present disclosure. In this regard, each box in the flowchart or block diagram can represent a module, program segment or part of the code, and the module, program segment or part of the code contains one or more executable instructions for implementing the specified logical function. It should also be noted that in some alternative implementations, the functions marked in the box can also occur in an order different from that marked in the accompanying drawings. For example, two consecutive boxes can actually be executed substantially in parallel, and they can sometimes be executed in the opposite order, depending on the functions involved. It should also be noted that each box in the block diagram and / or flowchart, and the combination of boxes in the block diagram and / or flowchart, can be implemented using a dedicated hardware-based system that performs the specified function or action, or can be implemented using a combination of dedicated hardware and computer instructions.

[0119] In the present disclosure, a processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), field-programmable gate arrays (FPGA), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor may be a microprocessor or any conventional processor, etc.

[0120] In this disclosure, memory may include non-permanent memory in a computer-readable medium, random access memory (RAM) and / or non-volatile memory in the form of read-only memory (ROM) or flash RAM. Memory is an example of a computer-readable medium.

[0121] In this disclosure, computer-readable media includes permanent and non-permanent, removable and non-removable storage media. Storage media can be implemented by any method or technology to store information, and the information can be computer-readable instructions, data structures, program modules or other data. Examples of computer storage media include, but are not limited to, phase change memory (PRAM), static random access memory (SRAM), dynamic random access memory (DRAM), other types of random access memory (RAM), read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory or other memory technology, compact disc read-only memory (CD-ROM), digital versatile disc (DVD) or other optical storage, magnetic cassettes, magnetic disk storage or other magnetic storage devices or any other non-transmission media that can be used to store information that can be accessed by a computing device. As defined herein, computer-readable media does not include transitory media such as modulated data signals and carrier waves.

[0122] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another entity or operation, and do not necessarily require or imply any actual relationship or order between these entities or operations. Moreover, the terms "comprises," "comprising," or any other variations thereof are intended to cover non-exclusive inclusion, so that a process, method, article, or device that includes a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. In the absence of further limitations, an element defined by the phrase "comprising a ..." does not exclude the presence of other identical elements in the process, method, article, or device that includes the element.

[0123] The above are merely specific embodiments of the present disclosure, intended to enable those skilled in the art to understand and implement the present disclosure. Various modifications to these embodiments will be readily apparent to those skilled in the art, and the general principles defined herein may be implemented in other embodiments without departing from the spirit or scope of the present disclosure. Therefore, the present disclosure is not limited to these embodiments, but is to be construed in the broadest manner consistent with the principles and novel features disclosed herein.

Claims

1. A lightweight RDMA virtualization method, characterized in that: include: Acquire configuration parameters of the virtual device, wherein the configuration parameters include a set number of virtual devices; Allocating a corresponding number of network devices to the set number of virtual devices; wherein the virtual devices correspond to network addresses of the network devices; Obtain idle resources based on a global resource bitmap query, and allocate the idle resources to the set number of virtual devices; wherein the virtual devices correspond to resource identifiers of the idle resources; After acquiring the configuration parameters of the virtual devices and before allocating a corresponding number of network devices to the set number of virtual devices, the method further includes: Configure the virtual device according to the set quantity through the driver software resource management layer; The set number of virtual devices share global hardware resources of the remote direct memory access hardware RDMA IP core.

2. The method according to claim 1, characterized in that The global resource bitmap includes: a global resource bitmap corresponding to a queue pair QP; The method of obtaining idle resources based on a global resource bitmap query and allocating the idle resources to a set number of virtual devices includes: Based on the global resource bitmap corresponding to the QP, query the idle QP; When the idle QP is found, allocating the idle QP to the set number of virtual devices; A correspondence between the QP identifier of the idle QP and the set number of virtual devices is established.

3. The method according to claim 2, characterized in that: After the establishing of the correspondence between the QP identifier of the idle QP and the set number of virtual devices, the method further includes: Receiving a general service interface GSI data packet transmitted by a first virtual device; wherein the first virtual device is any one of the set number of virtual devices, and the GSI data packet includes a destination address and an original QP identifier; Based on a mapping table, detecting whether the original QP identifier corresponds to the destination address; the mapping table is used to indicate the correspondence between the network address and the GSIQP identifier; In the case that the original QP identifier does not correspond to the destination address, modifying the original QP identifier to a target QP identifier according to the mapping table to obtain a GSI corrected data packet; According to the target QP identifier, the GSI modified data packet is transmitted to the second virtual device corresponding to the destination address.

4. The method according to claim 3, characterized in that After transmitting the GSI correction data packet to the second virtual device corresponding to the destination address according to the target QP identifier, the method further includes: Obtain a GSI data packet to be replied from the second virtual device; Determine the pending QP identifier of the to-be-replied GSI data packet based on the mapping table and the network address corresponding to the second virtual device; In the case that the pending QP identifier is not a preset QP identifier, modifying the pending QP identifier to the preset QP identifier to obtain a GSI data packet to be processed; The GSI data packet to be processed is transmitted to the first virtual device.

5. The method according to claim 1, characterized in that After allocating a corresponding number of network devices to the set number of virtual devices, and before obtaining idle resources based on a global resource bitmap query and allocating the idle resources to the set number of virtual devices, the method further includes: Determine the target virtual device for resource application through the driver software resource management layer; The obtaining idle resources based on the global resource bitmap query and allocating the idle resources to the set number of virtual devices includes: Obtaining idle resources through the driver software resource management layer based on the global resource bitmap query; The idle resource is allocated to the target virtual device.

6. A lightweight RDMA virtualization system, comprising: Virtual device, high-speed serial computer expansion bus standard base address register PCIE BAR space and RDMA IP core, characterized in that it includes: Driver software resource management layer, and network device MAC layer outside the RDMA core; The driver software resource management layer is used to: obtain configuration parameters of virtual devices, wherein the configuration parameters include a set number of virtual devices; allocate a corresponding number of network devices to the set number of virtual devices; wherein the virtual devices correspond to network addresses of the network devices; obtain idle resources based on a global resource bitmap query, and allocate the idle resources to the set number of virtual devices; wherein the virtual devices correspond to resource identifiers of the idle resources; The driver software resource management layer, after obtaining the configuration parameters of the virtual device and before allocating a corresponding number of network devices to the set number of virtual devices, is further used to: configure the virtual devices according to the set number; wherein the set number of virtual devices share the global hardware resources of the remote direct memory access hardware RDMA IP core.

7. A lightweight RDMA virtualization device, characterized in that: include: An acquisition module, used to: acquire configuration parameters of a virtual device, wherein the configuration parameters include a set number of virtual devices; An allocation module, configured to: allocate a corresponding number of network devices to the set number of virtual devices; wherein the virtual devices correspond to the network addresses of the network devices; obtain idle resources based on a global resource bitmap query, and allocate the idle resources to the set number of virtual devices; wherein the virtual devices correspond to the resource identifiers of the idle resources; The acquisition module is further used to: configure virtual devices according to the set number through the driver software resource management layer; wherein the set number of virtual devices share the global hardware resources of the remote direct memory access hardware RDMA IP core.

8. An electronic device, characterized in that: include: A processor, a memory, and a computer program stored in the memory and executable on the processor, wherein the computer program implements the lightweight RDMA virtualization method according to any one of claims 1 to 5 when executed by the processor.

9. A computer-readable storage medium, characterized in that: include: The computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the lightweight RDMA virtualization method according to any one of claims 1 to 5 is implemented.

Images