Virtualized I / O communication method, system, electronic device, medium and product

Abstract

Embodiments of the present application provide a virtual I / O communication method, system, electronic device, medium and product, relating to the field of virtualization, the method comprising: a device driver component writing a descriptor of a to-be-processed I / O request to a free entry of a descriptor table, and writing an entry index of the to-be-processed I / O request in the descriptor table to a submission queue, the descriptor being used to describe metadata required by a device virtualization component to receive the to-be-processed I / O request; reading a reception confirmation pointer updated by the device virtualization component, the reception confirmation pointer being used to indicate a queue boundary corresponding to the submission queue of an I / O request that has been received by the device virtualization component; and based on the reception confirmation pointer and a reception progress variable, releasing an entry corresponding to the I / O request that has been received as a free entry, the reception progress variable being used to represent a reception confirmation pointer based on which an entry was released last time. Embodiments of the present application can improve the reuse efficiency and logical concurrency capability of descriptor entries, effectively supporting higher IOPS performance and elastic concurrent scaling capability.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a virtualized I / O communication method, system, electronic device, medium and product, which can be applied to the field of device virtualization. Background Technology

[0002] The standard Virtualization Ring (Virtio Ring) format is primarily designed for low-latency, high-IOPS scenarios, effectively supporting high-performance storage or network devices with a fixed and limited queue depth. However, in high-latency-tolerant workloads, this mechanism has significant limitations: because the queue depth (e.g., the number of entries in the descriptor table) is fixed, if a large number of I / O requests are not completed due to long-tail latency, the entries they occupy will remain blocked, reducing the number of available entries and thus limiting system concurrency, impacting the overall throughput and Quality of Service (QoS) of the device. Therefore, for high-bandwidth, high-concurrency, but latency-insensitive big data processing scenarios, the standard Virtio Ring queue struggles to meet the performance requirements of input / output (I / O) communication. Summary of the Invention

[0003] In a first aspect, embodiments of this application provide a virtualized I / O communication method applied to a device driver component, comprising: writing a descriptor of a pending I / O request to a free entry of a descriptor table, and writing the entry index of the pending I / O request in the descriptor table to a submission queue, wherein the descriptor is used to describe the metadata required by the device virtualization component to receive the pending I / O request; reading an updated receive acknowledgment pointer of the device virtualization component, wherein the receive acknowledgment pointer is used to indicate the queue boundary corresponding to the submission queue of the received I / O request of the device virtualization component; and releasing the entry corresponding to the received I / O request as a free entry based on the receive acknowledgment pointer and a receive progress variable, wherein the receive progress variable is used to represent the receive acknowledgment pointer on which the last release of the entry was based.

[0004] Secondly, embodiments of this application provide a virtualized I / O communication method applied to a device virtualization component, comprising: reading an entry index written by a device driver component from a submission queue; reading a descriptor corresponding to the entry index from a descriptor table, the descriptor being used to describe metadata of an I / O request to be processed; receiving the I / O request to be processed according to the metadata of the I / O request to be processed, and updating a receive confirmation pointer, the receive confirmation pointer being used to indicate the queue boundary of the received I / O request of the device virtualization component in the submission queue, and being used by the device driver component to release the entry corresponding to the received I / O request as an idle entry based on the receive confirmation pointer and a receive progress variable, the receive progress variable being used to represent the receive confirmation pointer on which the device driver component last released the entry.

[0005] Thirdly, embodiments of this application provide a virtualized I / O communication system, including: a host machine configured to run a device virtualization component, the device virtualization component being used to implement the method described in the second aspect; and a virtual machine hosted by the host machine, the virtual machine being configured to run a device driver component, the device driver component being used to implement the method described in the first aspect.

[0006] Fourthly, embodiments of this application provide an electronic device, including a memory, a processor, and a computer program stored in the memory, wherein the processor implements any of the methods of embodiments of this application when executing the computer program.

[0007] Fifthly, embodiments of this application provide a computer-readable storage medium storing a computer program, which, when executed by a processor, implements the method of any one of the embodiments of this application.

[0008] Sixthly, embodiments of this application provide a computer program product, including a computer program that, when executed by a processor, implements any of the methods described in the embodiments of this application.

[0009] According to the technical solution of this application embodiment, by maintaining a receiving progress variable in the device driver component and combining it with the receiving confirmation pointer updated by the device virtualization component, the device driver component can dynamically identify the descriptor table entries corresponding to I / O requests that have been received by the device virtualization component but may not yet be processed. This allows the device driver component to release the corresponding descriptor table entries for I / O requests that are only in the received state. Specifically, by decoupling the submission queue from the descriptor table, after receiving an I / O request, the device virtualization component updates the receiving confirmation pointer. The device driver component reads the receiving confirmation pointer and reclaims the corresponding descriptor table entries accordingly for reuse by new I / O requests, without waiting for the I / O request to actually complete. Thus, while maintaining a fixed physical depth of the descriptor table, the reuse efficiency and logical concurrency of descriptor table entries can be significantly improved, alleviating the resource bottleneck of descriptor table entries caused by the virtualization I / O ring queue depth. In high-throughput scenarios with large amounts of data, this avoids request blocking caused by descriptor resource exhaustion, effectively supports higher I / O operation per second (IOPS) performance, and achieves elastic concurrent scaling capabilities under fixed resource constraints.

[0010] The above description is only an overview of the technical solution of this application. In order to better understand the technical means of this application, it can be implemented according to the contents of the specification. In order to make the above and other objects, features and advantages of this application more obvious and understandable, specific embodiments of this application are given below. Attached Figure Description

[0011] In the accompanying drawings, unless otherwise specified, the same reference numerals throughout the various drawings denote the same or similar parts or elements. These drawings are not necessarily drawn to scale. It should be understood that these drawings depict only some embodiments according to this application and should not be construed as limiting the scope of this application.

[0012] Figure 1A This diagram illustrates the intermediate state of a standard virtualized I / O ring at a given moment.

[0013] Figure 1B This diagram illustrates the issuance of new I / O requests based on the standardized Virtio Ring.

[0014] Figure 1C A schematic diagram based on the standardized Virtio Ring recycling table entries is shown.

[0015] Figure 2 This diagram illustrates the architecture of a virtualized I / O communication system 200 provided in an embodiment of this application.

[0016] Figure 3A flowchart illustrating a virtualized I / O communication method 300 according to an embodiment of this application is shown.

[0017] Figure 4A and Figure 4B This diagram illustrates the intermediate state of the virtualized I / O queue in an embodiment of this application.

[0018] Figure 5 A flowchart illustrating the virtualized I / O communication method 500 provided in this application is shown.

[0019] Figure 6A and Figure 6B This diagram illustrates the intermediate state of the virtualized I / O queue in an embodiment of this application.

[0020] Figure 7 A flowchart illustrating a virtualized I / O communication method 700 according to an embodiment of this application is shown.

[0021] Figure 8 A block diagram of an electronic device provided in an embodiment of this application is shown. Detailed Implementation

[0022] In the following description, only certain exemplary embodiments are briefly described. As those skilled in the art will recognize, the described embodiments can be modified in various ways without departing from the concept or scope of this application. Therefore, the drawings and description are considered to be exemplary in nature and not restrictive.

[0023] To facilitate understanding of the technical solutions of the embodiments of this application, the relevant technologies of the embodiments of this application are described below. The following relevant technologies are optional solutions and can be combined with the technical solutions of the embodiments of this application in any way, and all of them fall within the protection scope of the embodiments of this application.

[0024] The following terms will be used in the following text.

[0025] Virtualization I / O (Virtio): A device virtualization technology that defines a standardized communication interface between the front end (device driver components) and the back end (device virtualization components) in a virtualization environment, as specified by the Virtio specification.

[0026] Virtualized I / O Ring (Virtio Ring): A shared memory data structure format defined in the Virtio specification for passing I / O requests and completion status between the front-end and back-end. It includes components such as a descriptor table, an available ring, and a used ring.

[0027] In the standard Virtio Ring queuing technology, the available ring and the used ring are logically tightly coupled and share the same descriptor table. Under this mechanism, the descriptor table entry occupied by an I / O request submitted by the frontend must wait until the backend writes the corresponding completion event to the used ring before it can be released, and only then can the frontend continue to issue new I / O requests. The following section combines... Figure 1A , Figure 1B and Figure 1C To illustrate.

[0028] Figure 1A This diagram illustrates the intermediate state of a standard virtualized I / O ring at a given moment. Figure 1A As shown, the descriptor table contains multiple entries, each representing a descriptor for an I / O request. Therefore, each entry's descriptor contains several fields, including: the entry index of the current descriptor, whose values ​​are, for example, "0", "1", "2", "8", and "9" shown in the leftmost column; and the I / O request metadata described by the current descriptor, such as the address accessing the I / O request (usually labeled "addr", with values ​​such as "0x101000" or "0x102000"). The field values ​​are: “0x103000”, “Len”, “0x20”, “0x40”, “0x50”, “R” for I / O request (often marked “L”, with values ​​such as “0x20”, “0x40”, “0x50”), “R” for I / O request attributes (often marked “flags”, with “R” for read operation and “I” for indirect descriptor table); and the index of the next descriptor pointed to by the current descriptor (the next index, usually marked “next”), with values ​​such as “1”, “2”, “8”, “9”, and “10” as shown in the rightmost column.

[0029] The available ring (usually marked as avail_ring) is used to record the table indexes of the I / O requests submitted by the front end (the I / O requests to be processed by the back end). For example, avail_ring

[18] = 0 ("0" is written at position "18"), avail_ring

[19] = 1 ("1" is written at position "19"), avail_ring

[20] = 2 ("2" is written at position "20"), indicating that the front end has submitted I / O requests with table index "0", I / O requests with table index "1", and I / O requests with table index "2".

[0030] The used ring (usually marked as used_ring) is used to record completion information of I / O requests that have been processed by the backend. For example, used_ring

[29] .id = 0 (the "id" field at position "29" is written with "0"), which means that the index of the table entry for the I / O request that has been processed by the backend is "0".

[0031] The descriptor table, available rings, and used rings are all stored in shared memory between the front end and the back end.

[0032] In the standardized Virtio Ring structure, both the available ring (avail_ring) and the used ring (used_ring) contain a position index and a flag. For example, in the available_ring, the flag and the "20" to its left are represented as: available_ring.index = 20, indicating that the last committed I / O request written by the front end to the available_ring is located at position "20" in the available_ring. Similarly, in the used_ring, the flag and the "30" to its left are represented as used_ring.index = 30, indicating that the last completed I / O request written by the back end to the used_ring is located at position "30" in the used_ring.

[0033] The front end maintains a set of software variables, including: free_head, which represents the free entry header variable. For example, free_head = 8 (the value of the free entry header variable is "8"), which means that the index of the head entry of the current free descriptor chain (usually marked as "free") is "8", indicating that the index of the first free entry in the descriptor table is "8"; available_idx_shadow, which represents the position of the submitted I / O request recorded by the front end in the available ring; and last_used_idx, which represents the position of the harvested I / O request recorded by the front end in the used ring.

[0034] Therefore, based on free_head = 8, the frontend knows that if a new I / O request is submitted, the descriptor of that I / O request should be written to the table entry with index "8"; based on available_idx_shadow = 20 and available_ring.index = 20, the frontend knows that all submitted I / O requests have been successfully pushed to the backend and are waiting for backend processing; based on last_used_idx = 29 and used_ring.index = 30, the frontend knows that there is still one I / O request that has not been harvested.

[0035] Figure 1BThe diagram illustrates the issuance of a new I / O request based on the standardized Virtio Ring. As shown in Figure 1, the frontend obtains the index of the currently free entry in the table as "8" based on free_head = 8, and writes the metadata of the new I / O request into the entry in the descriptor table with the index "8". This includes: writing the address "0x104000" that accesses the I / O request into the address field, writing the length "0x30" of the I / O request into the length field, writing the attribute "R | I" of the I / O request into the attribute field, and updating the next field to the index of the next free entry, which is "9".

[0036] Furthermore, the table entry index "8" of the new I / O request is written to position "21" of the available ring, i.e., available_ring

[21] = 8. The backend can discover the new I / O request through polling or interruption mechanisms. At the same time, the frontend updates the software variables it maintains, including: (new) available_idx_shadow = 20+1=21, that is, the software variable available_idx_shadow is incremented by 1 from 20 to 21, indicating that a new I / O request has been submitted; (new) free_head = desc[8].next = 9, the frontend knows that the descriptor of the subsequent new I / O request should be written to the table entry with table entry index "9".

[0037] Figure 1C This diagram illustrates the process of reclaiming entries based on the standardized Virtio Ring. After processing an I / O request, the backend triggers an interrupt signal. The frontend responds to this interrupt signal by checking if its locally maintained software variable `last_used_idx` equals `used_ring.index`. If they are not equal, it indicates that there are entries (reclaimable entries) that the backend has processed but the frontend has not reclaimed. Subsequently, the frontend extracts the entry index corresponding to the reclaimable entry (i.e., `desc_[used_ring[idx].id="0")` and sets it to "0", releasing the entry with index "0" as a free entry. Then, `free_head` is updated to entry index "0", i.e., `(new) free_head = used_ring (old) [last_used_idx].id = 0`.

[0038] This means that until the backend completes processing the I / O requests, the entries related to these I / O requests in the descriptor table remain occupied and cannot be released. This design directly limits the system's maximum concurrent requests to the queue depth. In scenarios with high Service Level Agreement (SLA) requirements and where longer processing latency is acceptable, a large number of long-tail requests occupy queue slots (i.e., entries) for extended periods, severely limiting overall bandwidth utilization and making it difficult to meet the performance requirements of I / O communication in high-bandwidth, high-concurrency, but latency-insensitive big data processing scenarios.

[0039] To improve concurrency, one approach is to use a dual virtualization queue pair, i.e., a pair of independent Virtio queues, where one Virtio queue acts as the request sender and the other as the request receiver. However, when implemented in the backend by hardware logic, it is necessary to simultaneously monitor and maintain the states of both Virtio queues (including two descriptor tables, available rings, used rings, etc.), which increases the complexity and resource overhead of the hardware state machine. Another approach is to simply increase the queue depth of a single Virtio queue (e.g., by increasing the number of entries in the descriptor table) to accommodate more concurrent requests. However, this approach requires allocating large blocks of contiguous physical memory, which is difficult to implement in environments with hot-swappable virtual machines, small instances, or memory constraints, and is prone to memory fragmentation issues, lacking deployment flexibility.

[0040] In view of this, the embodiments of this application aim to provide a virtualized I / O communication scheme that supports high concurrency. A detailed description follows.

[0041] Figure 2 This diagram illustrates the architecture of a virtualized I / O communication system 200 provided in an embodiment of this application. Figure 2 As shown, the virtualized I / O communication system 200 includes a host 210 and a virtual machine (i.e., a guest) 220.

[0042] For example, the host machine 210 includes a hardware layer and a host kernel space. The hardware layer includes physical resources such as physical memory, a processor, and non-volatile memory, providing basic computing and storage capabilities for the operation of the entire virtualized I / O communication system 200. Physical memory is used to store memory data; the processor is responsible for executing instructions and scheduling tasks; and non-volatile memory is used for persistent data storage. Above the hardware layer, the host machine 210 also includes a host operating system, which runs in the host kernel space.

[0043] For example, virtual machine 220 is hosted by host machine 210, and its internal architecture includes guest user space and guest kernel space. The guest user space runs multiple guest applications, such as database services, web services or big data services, which initiate I / O requests to access external storage or network resources.

[0044] In this system, virtual machine 220 loads and runs device driver component 221 through its Guest operating system. Device driver component 221 acts as the frontend, responsible for receiving I / O requests from the Guest user space, encapsulating them into a standardized Virtio format, and submitting them to device virtualization component 211 based on virtualized I / O communication method 300 or method 500 (described below). The submission is made through shared memory between device driver component 221 and device virtualization component 211. Host machine 210 loads and runs device virtualization component 211 through its Host operating system. Device virtualization component 211 acts as the backend, located in the Host kernel space, and can simulate the behavior of physical devices (such as block storage devices). Based on virtualized I / O communication method 700 (described below), it processes and responds to I / O requests submitted by device virtualization component 211.

[0045] Thus, the device driver component 221 and the device virtualization component 211 work together to achieve high-concurrency virtualized I / O communication. This I / O communication scheme supports efficient delivery and response to large-scale concurrent requests and is suitable for high-throughput scenarios such as big data processing and high-performance computing. For example, in application scenarios that are sensitive to I / O latency and require high service availability (such as real-time data analysis or online transaction processing systems), this I / O communication scheme can effectively improve the total end-to-end bandwidth by optimizing the request submission and recycling process. Furthermore, in virtualized I / O systems based on hardware offloading architectures (such as scenarios where device virtualization functions are offloaded to dedicated acceleration chips), this I / O communication scheme can overcome the serial bottleneck of the traditional Virtio ring queue on the request submission path, significantly improving downlink data throughput.

[0046] It is understood that other components of the aforementioned virtualized I / O communication system 200, host machine 210, and virtual machine 220 can employ various technical solutions now and in the future known to those skilled in the art, and will not be described in detail here. Furthermore, the deployment form or other configurations of the aforementioned virtualized I / O communication system 200, host machine 210, and virtual machine 220 may differ in different application scenarios, and this application embodiment does not specifically limit these aspects. For example, the communication protocol between device driver component 221 and device virtualization component 211 can be adapted to the protocol specifications of Virtio 1.0, Virtio 1.2, or later compatible versions; in addition, shared memory can be directly mapped by hardware-assisted virtualization technology or established through software simulation.

[0047] It should be noted that the application scenarios or examples provided in this application are for ease of understanding, and this application does not specifically limit the application of the technical solutions. Furthermore, the user information (including but not limited to user device information, user personal information, etc.) and data (including but not limited to data used for analysis, stored data, displayed data, etc.) involved in this application are all information and data authorized by the user or fully authorized by all parties. The collection, use, and processing of related data must comply with the relevant laws, regulations, and standards of the relevant countries and regions, and corresponding operation entry points are provided for users to choose to authorize or refuse.

[0048] The technical solution of this application and how it solves the aforementioned technical problems are described in detail below with specific embodiments. The listed specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments.

[0049] Figure 3 A flowchart illustrating a virtualized I / O communication method 300 according to an embodiment of this application is shown. This virtualized I / O communication method 300 can be applied to device driver components, such as those provided by… Figure 2 The device driver component 221 shown is implemented as follows. Figure 3 As shown, the virtualized I / O communication method 300 may include steps S301, S302 and S303.

[0050] Step S301: Write the descriptor of the pending I / O request to the free entry of the descriptor table, and write the index of the pending I / O request in the descriptor table to the submission queue. The descriptor is used to describe the metadata required by the device virtualization component to receive the pending I / O request.

[0051] In the Virtio specification, the descriptor table (usually denoted as desc) resides in shared memory between the device driver component (front end) and the device virtualization component (back end). For example... Figure 4A As shown, the descriptor table (desc) is a component of the Virtualization I / O Ring, consisting of multiple entries (slots). Each entry represents a descriptor for an I / O request. Therefore, each entry's descriptor contains several fields, including: the entry index, such as "0", "1", "2", "8", and "9" shown in the leftmost column; metadata fields for the I / O request, such as the "address" field, "length" field, and "attribute" field; and the "next" field, indicating the entry index of the next descriptor pointed to by the current descriptor. For a detailed introduction to the descriptor table (desc), please refer to the previous section... Figure 1A Related descriptions.

[0052] The Submission Queue (SQ) is written by the device driver component to record the index of the corresponding entry in the descriptor table (desc) for I / O requests submitted by the device driver component. For example, ... Figure 4A As shown, SQ

[18] = 0 (0 is written to queue position "18" of SQ), SQ

[19] = 1 (1 is written to queue position "19" of SQ), SQ

[20] = 2 (2 is written to queue position "20" of SQ), indicating that the device driver component has submitted I / O requests with table entry index "0", I / O requests with table entry index "1", and I / O requests with table entry index "2".

[0053] The device driver component submits pending I / O requests to the device virtualization component. These pending I / O requests are the I / O requests that need to be processed by the device virtualization component. For example, such as... Figure 4A As shown, the process may include: First, the device driver component determines that the index of the free entry is "8". Then, it writes the metadata of the pending I / O request to the 8th entry of the descriptor table (desc). For example, the address "0x104000" is written to the "Address" field of the 8th entry, pointing to the access address of the I / O request; the length "0x50" is written to the "Length" field of the 8th entry; the attribute "R|I" is written to the "Attribute" field of the 8th entry, indicating a read operation; the "next" field of the 8th entry is set to 9, indicating that the next entry index of this descriptor is 9. After writing the descriptor of the pending I / O request to the descriptor table, the device driver component writes the entry index (i.e., 8) of the descriptor in the descriptor table to the commit queue (SQ) to notify the device virtualization component that there is a new I / O request to be processed.

[0054] For example, such as Figure 4A As shown, the device virtualization component can monitor the status of the Submission Queue (SQ) through polling or interrupt mechanisms. For example, when it detects an update at the tail position of the Submission Queue (SQ), it knows that there is a new pending I / O request in the Submission Queue (SQ). For example, if the position index corresponding to the flag bit of the Submission Queue (SQ) is 21, it indicates that the current tail position is 21, and the entry index of the new pending I / O request has been written to SQ

[21] . The device virtualization component reads the value (i.e., 8) at position SQ

[21] and reads the corresponding descriptor from the 8th entry of the descriptor table to obtain the metadata of the pending I / O request. The device virtualization component parses the metadata to internally construct the processing task of the pending I / O request, thereby completing the reception of the pending I / O request.

[0055] Step S302: Read the updated receive confirmation pointer of the device virtualization component. The receive confirmation pointer is used to indicate the queue boundary corresponding to the submission queue of the received I / O request of the device virtualization component.

[0056] After successfully receiving the pending I / O request, the device virtualization component updates its maintained receive acknowledgment pointer. For example, in Figure 4B In the diagram, the receive confirmation pointer is marked as sq_head. The device virtualization component updates the value of sq_head from 19 (i.e., the value of last_sq_head) to 21, indicating that the device virtualization component has received the I / O request corresponding to SQ

[21] . Therefore, the receive confirmation pointer (sq_head) is used to indicate the queue boundary of the submitted queue (SQ) of the received I / O request of the device virtualization component, that is, the queue position of the latest received I / O request of the device virtualization component in the submitted queue (SQ).

[0057] The receive acknowledgment pointer (sq_head) resides in shared memory between the device driver component and the device virtualization component. For example, during the initialization phase, the device driver component and the device virtualization component can define a register to store the value of sq_head. The device driver component can directly read the value of this register to obtain the value of the receive acknowledgment pointer (sq_head), thereby knowing the progress of the device virtualization component in receiving I / O requests.

[0058] Step S303: Based on the receive acknowledgment pointer and the receive progress variable, release the table entry corresponding to the received I / O request as an idle table entry. The receive progress variable is used to represent the receive acknowledgment pointer on which the last table entry was released.

[0059] The receive progress variable (labeled last_sq_head) is a software variable stored and maintained locally by the device driver component (front end) to represent the receive acknowledgment pointer upon which the last released entry was based. For example, in Figure 4B In the last_sq_head = 19 stored locally by the device driver component, it is confirmed that the device virtualization component has received I / O requests up to position 19 of the commit queue when the descriptor table entry was last released.

[0060] For example, the device driver component first reads the current receive acknowledgment pointer sq_head (e.g., sq_head = 21) from shared memory, and then compares it with the local receive progress variable last_sq_head (e.g., last_sq_head = 19). For instance, if the difference is 2, it indicates that there are two descriptor entries corresponding to received I / O requests that have been committed and received by the device virtualization component and can be reclaimed. Further, the device driver component releases these entries as free entries for later writing descriptors of new I / O requests into these entries, thus completing the reclamation of entries corresponding to received I / O requests.

[0061] According to the technical solution of this application embodiment, by maintaining a receive progress variable (last_sq_head) in the device driver component and combining it with the receive acknowledgment pointer (sq_head) updated by the device virtualization component, the descriptor table entries corresponding to I / O requests that have been received by the device virtualization component but may not yet be processed are dynamically identified. This allows the device driver component to release the corresponding descriptor table entries (slots) for I / O requests that are only in the received state. Specifically, in the traditional Virtio ring scheme, the device driver component can only reclaim the corresponding descriptor table entries after knowing that an I / O request has been processed based on the used ring. Therefore, descriptor table entries need to be retained until the I / O request is processed, which can easily exhaust the fixed-size descriptor table resources in high-concurrency scenarios, limiting system scalability. This application decouples the commit queue (SQ) from the descriptor table. After receiving an I / O request, the device virtualization component updates the receive acknowledgment pointer (sq_head). The device driver component reads the receive acknowledgment pointer (sq_head) and reclaims the corresponding descriptor table entry for reuse in new I / O requests, without waiting for the I / O request to actually complete. Therefore, while maintaining a fixed physical depth of the descriptor table, the reuse efficiency and logical concurrency of descriptor table entries can be significantly improved. This alleviates the resource bottleneck of descriptor table entries caused by the virtio ring queue depth, thus avoiding request blocking due to descriptor resource exhaustion in high-throughput big data scenarios, effectively supporting higher IOPS performance, and achieving elastic concurrent scaling under fixed resource constraints.

[0062] In one implementation, step 303, based on the receive acknowledgment pointer and the receive progress variable, releases the entry corresponding to the received I / O request as an idle entry, which may include: in response to the need to write a descriptor of a new pending I / O request to the descriptor table, releasing the entry corresponding to the received I / O request as an idle entry based on the receive acknowledgment pointer and the receive progress variable.

[0063] When preparing to submit a new I / O request, the device driver component first checks whether there are any received but not yet reclaimed descriptor entries that need to be released. For example, if the device driver component reads the current receive acknowledgment pointer `sq_head` from shared memory and finds it to be 21, while its locally maintained receive progress variable `last_sq_head` is 19, it indicates that there are two descriptor entries corresponding to received I / O requests that can be safely reclaimed. Therefore, the device driver component triggers a resource reclamation process, releasing these entries as free entries for later writing of new I / O request descriptors, thus completing the reclamation of entries corresponding to received I / O requests.

[0064] Based on this, before writing a new descriptor for a pending I / O request to the descriptor table, the device driver component triggers a resource reclamation process, which can release descriptor table entries that have been received by the device virtualization component but are still occupied as free entries, thereby ensuring that there are enough free entries and avoiding the inability to submit new pending I / O requests due to the exhaustion of descriptor table entry resources.

[0065] In one implementation, step 303, based on the receive acknowledgment pointer and the receive progress variable, releases the entry corresponding to the received I / O request as an idle entry, which may include: determining the corresponding entry index range according to the difference between the receive acknowledgment pointer and the receive progress variable; releasing the entry corresponding to the entry index range in the descriptor table as an idle entry; further, the virtualized I / O communication method 300 may also include: updating the value of the receive progress variable to the value of the receive acknowledgment pointer.

[0066] For example, if the device driver component reads sq_head = 21 and last_sq_head = 19, the difference between the two is 2, indicating that there are 2 received I / O requests. This difference corresponds to two entries from position 19 to 20 in the commit queue (SQ). The device driver component reads the values ​​of SQ

[19] and SQ

[20] in sequence, which are 1 and 2 respectively. That is, the descriptor table entry indices recorded at these two positions are 1 and 2, and the difference determines that the corresponding table entry index range is the 1st to 2nd entries in the descriptor table. Therefore, the device driver component releases the 1st and 2nd entries in the descriptor table as free entries. Further, the device driver component updates the local receive progress variable last_sq_head to the current value of sq_head (i.e., 21), completing this resource reclamation process.

[0067] Based on this, when the value of the receive confirmation pointer is greater than the value of the receive progress variable, the index range of entries to be released is determined according to the difference between the receive confirmation pointer and the receive progress variable. The device driver component can accurately identify the range of continuous I / O requests that have been received by the device virtualization component but have not yet been reclaimed, thereby avoiding omission or duplicate release of descriptor entries. Furthermore, by releasing the entries corresponding to this index range in batches as idle entries and synchronously updating the receive progress variable to the current value of the receive confirmation pointer, the accuracy of the device driver component's progress on received requests is ensured, effectively preventing illegal reuse of descriptors due to progress asynchrony, and providing state management guarantees for stable and reliable I / O submission in high-concurrency scenarios.

[0068] In one implementation, in step S301, writing the entry index of the pending I / O request in the descriptor table to the submission queue may include: writing the pending I / O request into the submission queue based on the queue position represented by the tail variable of the submission queue, so as to submit the pending I / O request; further, the virtualized I / O communication method 300 may also include: incrementing the value of the tail variable of the submission queue by one.

[0069] The tail variable of the commit queue is a software variable that is stored and maintained locally by the device driver component. The tail variable of the commit queue is used to indicate the queue boundary of the committed I / O request of the device driver component in the commit queue (SQ), that is, the tail position of the commit queue, which is also the queue position of the last entry index that the device driver component has written to the commit queue (SQ).

[0070] Therefore, based on the tail position of the commit queue (SQ), the device driver component can determine the write position of the current entry index to be written in the commit queue (SQ), that is, increment the tail position of the commit queue by one, and update the tail variable of the commit queue after writing to the commit queue (SQ).

[0071] For example, in Figure 4A In the process, when the device driver component is ready to submit a pending I / O request, it first determines that the entry index of the descriptor corresponding to the pending I / O request in the descriptor table is 8. Then, it determines the write position of the entry index "8" in the commit queue (SQ). If the tail variable of the commit queue is marked as avail_idx_shadow, and its initial value is 20, it means that the tail position of the commit queue (SQ) is 20. Therefore, the write position of the current entry index "8" in the commit queue (SQ) is 20+1=21. Subsequently, the device driver component writes the entry index "8" to the 21st position of the commit queue (SQ), completing the submission of the pending I / O request with entry index 8.

[0072] Furthermore, the device driver component increments the value of the commit queue tail variable avail_idx_shadow by one, updating it to 21 to reflect the new tail position of the commit queue. At this time, avail_idx_shadow = 21 indicates that the index of the next table entry to be written will be located in SQ

[22] .

[0073] Based on this, by introducing a tail variable for the commit queue, the device driver component can determine the write position of the table entry index without frequently reading hardware registers or the actual queue pointer in shared memory, thereby reducing the overhead of accessing shared resources. Simultaneously, the tail variable for the commit queue, as a shadow copy maintained locally by the device driver component, enables efficient synchronization in a multi-threaded environment. Furthermore, timely updates to the tail variable for the commit queue ensure the orderliness and consistency of the commit queue, as well as the sequentiality and integrity of submitted I / O requests. Additionally, `avail_idx` is included in the native virito-ring protocol specification, and `avail_idx_shadow` is a mechanism already implemented in the operating system kernel. Therefore, this embodiment can reuse both the native virito-ring protocol and the operating system kernel's variable management mechanism to record the tail variable for the commit queue.

[0074] In one implementation, in step S301, writing the descriptor of the I / O request to be processed to the free entry of the descriptor table includes: writing the descriptor of the I / O request to be processed into the free entry represented by the free entry header variable in the descriptor table; the descriptor of the I / O request to be processed includes a field for describing metadata and a field for describing the next entry index corresponding to the I / O request to be processed; further, the virtualized I / O communication method 300 may also include: updating the value of the free entry header variable to the field value of the next entry index.

[0075] The free entry header variable represents the index of the head entry in the free descriptor chain, which is formed by linking the indexes of each free entry in the descriptor table using a chain pointer.

[0076] The descriptor includes fields for describing the metadata of the I / O request to be processed, such as the "address" field, the "length" field, and the "attribute" field. The descriptor also includes a field for describing the index of the next table entry corresponding to the I / O request to be processed, namely the "next" field.

[0077] For example, each free entry in the descriptor table points to the index of the next free entry through its "next" field, thus forming a unidirectional chain of free descriptors. The starting position (head) of the free descriptor chain is indicated by a free entry head variable (marked as free_head) maintained locally by the device driver component. The value of the free entry head variable is the index of the head entry of the current free descriptor chain, representing the first free entry that can be allocated.

[0078] For example, in Figure 4AIn the free descriptor list, the free entry header variable is marked as `free_head`, and its current value is 8, indicating that the 8th entry in the descriptor list is the currently available free entry. Therefore, the device driver component writes the descriptor for the pending I / O request to entry number 8. After completing the writing of the descriptor, the device driver component updates the value of the free entry header variable `free_head` to the value of the "next" field in entry number 8 (i.e., 9), thus making entry number 9, which originally belonged to the free descriptor chain, the new head of the free descriptor chain. At this time, `free_head = 9`, indicating that the next available free entry is entry number 9.

[0079] Based on this, the free descriptor chain consisting of the "next" field can be dynamically managed, and the available free entries can be quickly located using the free_head pointer. The device driver component can complete the allocation of descriptor entries in O(1) time complexity, which significantly improves the efficiency of I / O request submission and enhances the overall throughput and stability of the system.

[0080] In one embodiment, the virtualized I / O communication method 300 of this application may further include: adding the entry index of the released free entry to the free descriptor chain, and updating the head entry index of the free descriptor chain to: the entry index written at the queue position represented by the receiving progress variable in the submission queue.

[0081] For example, such as Figure 4B As shown, after entry 0 in the descriptor table is released as a free entry, the device driver component updates the value of the free entry header variable free_head to 1, that is, (new) free_head = sq[last_sq_head] = 1.

[0082] Wherein, last_sq_head represents the receive acknowledgment pointer on which the last entry was reclaimed (released), that is, the queue position (i.e., 19) of the submitted I / O request in the submitted queue (SQ); sq[last_sq_head] represents the index of the descriptor entry recorded at that position in the submitted queue (i.e., SQ

[19] = 1). Therefore, the device driver component releases the first entry as a free entry and adds the entry index 1 to the head of the free descriptor chain, that is, updates the head entry index of the free descriptor chain to the entry index 1, thereby updating the value of the free entry head variable free_head to the entry index 1.

[0083] Based on this, timely updates to the free descriptor chain can be achieved, ensuring the continuity and consistency of descriptor table entry allocation.

[0084] As mentioned earlier, when the device virtualization component receives an I / O request (i.e., an I / O request that the device virtualization component has received), the device driver component reclaims the entry corresponding to this I / O request from the descriptor table. However, when reclaiming the entry, the descriptor content of that entry is not demapped; that is, the memory mapping and other requested resources associated with the I / O request are not released at this time. Therefore, when the device virtualization component completes the processing of the I / O request and needs to demap it, there will be no information related to this I / O request in the descriptor table.

[0085] To ensure accurate identification and release of the associated requested resources after an I / O request is completed, in this embodiment, the request identifier of the I / O request can be transmitted between the device driver component and the device virtualization component. Specifically, Figure 5 A flowchart illustrating the virtualized I / O communication method 500 provided in this application is shown. The virtualized I / O communication method 500 can be applied to device driver components, such as those provided by… Figure 2 The device driver component 221 shown is implemented as follows. Figure 5 As shown, the virtualized I / O communication method 500 includes steps S501, S502 and S503.

[0086] Step S501: Configure the corresponding request identifier for the I / O request to be processed.

[0087] For example, when constructing an I / O request to be processed, the device driver component configures a corresponding request tag for it. For instance, such as... Figure 6A As shown, the device driver component assigns a unique request identifier "8104" to the I / O request to be processed and writes the request identifier into the I / O request header of the I / O request. The request header of the I / O request may include fields such as output header, opcode, and request identifier (tag).

[0088] Furthermore, the device driver component stores the request identifier "8104" together with the indirect descriptor array (indir_descs[]) and its metadata (such as address 0x104000, length 0x50, etc.) in the static request table (static_requests[]). Both the indirect descriptor array and the static request table are information stored and maintained locally by the device driver component.

[0089] The indirect descriptor array (indir_descs[]) stores description information (including the address and length of the indirect descriptor table) involved in an I / O request, thereby locating the indirect descriptor table involved in an I / O request. For example, ... Figure 6BAs shown, the I / O request corresponding to entry number 1 (table entry index) in the descriptor table has an indirect descriptor table that records the secondary index and description information of that I / O request. Through this indirect descriptor table, the device virtualization component can parse and execute complex I / O operations. For example, in the case of needing to read or write multiple non-contiguous data blocks, the device virtualization component can access each data block sequentially according to the description information provided in the indirect descriptor table to complete the entire I / O request.

[0090] In this embodiment, the static request table (static_requests[]) is a fixed-size array (or hash table) pre-allocated by the device driver component. Each entry corresponds to a request tag, and each entry can record the request resource associated with the I / O request identified by the request tag. Therefore, regardless of whether the entry in the descriptor table has been reclaimed, the device driver component can locate the request resource of the corresponding I / O request through the request tag.

[0091] Step S502: Read the request identifier field corresponding to the target queue interval from the completion queue, wherein the request identifier field is used to write the request identifier of the processed I / O request of the device virtualization component.

[0092] Processed I / O requests refer to requests received by the device virtualization component after all data transmission and status update operations have been performed. The Completion Queue (CQ) is written by the device virtualization component to record processed I / O requests. The Completion Queue includes a request identifier field to record the request identifier of the processed I / O request.

[0093] For example, such as Figure 6B As shown, the right column of the completion queue (CQ) is the request identifier field. The request identifier field of CQ

[19] is written with the request identifier "8104", indicating that the device virtualization component has completed the I / O request with the request identifier "8104".

[0094] The target queue range is a continuous queue range. For example, if the queue position when the device driver component last read the completed queue (CQ) was 18, and the current queue position to be read is 19, then the target queue range is from CQ

[18] (excluding the left boundary, because the device driver component has already read CQ

[18] ) to CQ

[19] , that is, it only contains the item CQ

[19] . The device driver component reads the request identifier field in CQ

[19] to obtain the request identifier "8104".

[0095] Step S503: Identify the processed I / O request based on the read request identifier field, and release the request resource associated with the processed I / O request.

[0096] For example, the device driver component reads the request identifier field corresponding to the target queue interval from the completion queue, such as... Figure 6B As shown, the device driver component reads the request identifier field in CQ

[19] and obtains the request identifier "8104". Therefore, the request identifier of the processed I / O request is identified as 8104. The device driver component uses the request identifier "8104" to look up the corresponding entry in the static request table (static_requests[]) and obtains the information of its associated resources (such as &indir_desc = 0x104000, length = 0x50). Then, it releases these associated resources, such as unmapping the page table of the memory region starting at 0x104000 and returning the indirect descriptor array to the memory pool.

[0097] Based on this, the device driver component configures a request identifier (tag) field for I / O requests, ensuring that each I / O request can be uniquely indexed by this request identifier. The device virtualization component then returns this request identifier to the completion queue, enabling the transfer of request identifiers between the device driver and device virtualization components. This ensures that the front end can accurately identify completed requests (processed I / O requests), allowing for accurate location and release of request resources associated with processed I / O requests, even after the identifier table entry has been recycled. Thus, without increasing hardware complexity, asynchronous completion notification of I / O requests can be achieved through a software-level request management mechanism. This also enables precise location and timely release of request resources such as indirect descriptor table entries and memory mappings, improving system stability and I / O throughput performance in high-concurrency scenarios.

[0098] In one implementation, step S502, reading the request identifier field corresponding to the target queue interval from the completion queue, may include: in response to a completion request interruption triggered by the device virtualization component, reading the updated completion queue tail pointer of the device virtualization component; determining the target queue interval based on the completion queue tail pointer and the completion progress variable; and reading the request identifier field corresponding to the target queue interval.

[0099] For example, after the device virtualization component completes processing an I / O request, it can update the tail pointer of the completion queue and trigger a completion request interruption, thereby notifying the device driver component that a new I / O request has been completed and the results in the completion queue need to be processed.

[0100] The completion queue tail pointer indicates the boundary of the completed I / O request queue. This pointer resides in shared memory between the device driver component and the device virtualization component and is updated by the device virtualization component. For example, ... Figure 6BAs shown, the tail pointer of the completion queue is marked as used_idx(CQ_tail), and its current value is 19, indicating that the device virtualization component has written completion information to queue position 19 of the completion queue (CQ). In this embodiment, the completion information includes the request identifier of the corresponding processed I / O request.

[0101] The completion progress variable is used to represent the completion queue tail pointer on which the previous read request identifier field was based. The completion progress variable is a software variable that is stored and maintained locally by the device driver component. For example, ... Figure 6B As shown, the completion progress variable is marked as last_used_idx, and its initial value is 18, indicating that the queue position of the device driver component when it last successfully read the completion queue (CQ) is 18.

[0102] The device driver component responds to the completion request interrupt, reads the tail pointer of the completion queue, compares it with the completion progress variable, and then determines the target queue interval. For example, Figure 6B As shown, the device driver component reads the tail pointer flag used_idx(CQ_tail) = 19, indicating that the current queue position to be read is 19, while the current completion progress variable last_used_idx = 18, indicating that the queue position when the device driver component read the completion queue (CQ) last time was 18. Therefore, the difference between the two is 1, that is, the target queue interval only contains the item CQ

[19] . The device driver component reads the request identifier field of CQ

[19] and obtains the request identifier "8104".

[0103] Furthermore, the device driver component reads the request identifier field corresponding to the target queue interval from the completion queue (CQ), as described above.

[0104] Based on this, by introducing a completion progress variable and a tail pointer of the completion queue, the completion information of the completion queue can be read in a timely manner, thereby asynchronously and promptly locating and releasing the requested resources of processed I / O requests, thus improving the efficiency of asynchronous resource reclamation and reducing system overhead.

[0105] In one implementation, after step S503, method 500 may further include: updating the value of the completion progress variable to the value of the tail pointer of the completion queue; and updating the head pointer of the completion queue according to the updated value of the completion progress variable.

[0106] The completion queue head pointer indicates the queue boundary corresponding to an I / O request whose requested resource has been released by the device driver component. For example, ... Figure 6BAs shown, the completion queue head pointer is marked as CQ_head, and its current value is 19, indicating that the device driver component has processed and released all completion items before CQ

[18] . The completion queue head pointer (CQ_head) is located in the shared memory of the device driver component and the device virtualization component, and is read by the device virtualization component.

[0107] For example, the device driver component updates the completion queue head pointer (CQ_head) after releasing the request resources associated with the processed I / O request. For instance, as... Figure 6B As shown, after reading the request identifier field of CQ

[19] and releasing the corresponding request resources, the device driver component updates the value of the completion queue head pointer (CQ_head) to 19, indicating that the completion information of CQ

[19] has been read (consumed).

[0108] Furthermore, the device virtualization component reads the completion queue head pointer (CQ_head) and obtains CQ_head = 19, thereby knowing that the device driver component has processed all completion information and can safely reuse CQ

[19] and the previous queue position.

[0109] Based on this, the device driver component actively updates the CQ_head, enabling the device virtualization component to promptly detect I / O requests for resources released by the device driver component.

[0110] In one implementation, a descriptor table, a commit queue (SQ), and a completion queue (CQ) are used to construct a virtualized I / O ring, which resides in shared memory between the device driver component and the device virtualization component.

[0111] In other words, the descriptor table can reuse the data structure of the descriptor table in the Virtio Ring; the submission queue (SQ) can reuse the data structure of the available ring (avail_ring) in the Virtio Ring; and the completion queue (CQ) can reuse the data structure of the used ring (used_ring) in the Virtio Ring. For example, the id field or length (len) field in the used ring can be used as the request identifier field.

[0112] Therefore, the I / O communication scheme of this application embodiment can significantly improve the reuse efficiency and logical concurrency of descriptor table entries without modifying the underlying data structure. It can effectively support higher IOPS performance and is compatible with and adaptable to the protocol specifications of Virtio 1.0, Virtio 1.2 or later compatible versions, thus having good deployability and portability in heterogeneous virtualization environments.

[0113] Figure 7 A flowchart illustrating a virtualized I / O communication method 700 according to an embodiment of this application is shown. This virtualized I / O communication method 700 can be applied to device virtualization components, such as those provided by… Figure 2 The device virtualization component 211 shown is implemented. For example... Figure 7 As shown, the virtualized I / O communication method 700 may include: step S701, reading the table entry index written by the device driver component from the submission queue; step S702, reading the descriptor corresponding to the table entry index from the descriptor table; step S703, receiving the I / O request to be processed according to the metadata of the I / O request to be processed, and updating the receive confirmation pointer.

[0114] The descriptor describes the metadata of the I / O request to be processed; the receive acknowledgment pointer indicates the queue boundary of the received I / O request in the submission queue of the device virtualization component, and is used by the device driver component to release the entry corresponding to the received I / O request as an idle entry based on the receive acknowledgment pointer and the receive progress variable; the receive progress variable represents the receive acknowledgment pointer on which the device driver component last released the entry.

[0115] For details on the implementation methods and technical effects, please refer to the previous introductions of Method 300 and Method 500.

[0116] In one implementation, the metadata includes a request identifier for a pending I / O request, and the virtualized I / O communication method 700 may further include: writing the request identifier of a processed I / O request to the request identifier field of the completion queue.

[0117] The completion queue is used by the device driver component to: read the request identifier field corresponding to the target queue interval; identify the processed I / O request based on the read request identifier field; and release the request resources associated with the processed I / O request. For specific implementation methods and technical effects, please refer to the previous introductions to methods 300 and 500.

[0118] In one implementation, the virtualized I / O communication method 700 may further include: after writing the request identifier of the processed I / O request of the device virtualization component into the request identifier field of the completion queue, updating the tail pointer of the completion queue; and triggering a completion request interrupt.

[0119] The completion queue tail pointer indicates the queue boundary corresponding to the completed I / O request. The completion request interrupt notifies the device driver component to read the completion queue tail pointer, determine the target queue interval based on the completion queue tail pointer and the completion progress variable, and read the request identifier field corresponding to the target queue interval. The completion progress variable represents the completion queue tail pointer on which the device driver component last read the request identifier field. For specific implementation details and technical effects, please refer to the previous descriptions of methods 300 and 500.

[0120] In one implementation, the virtualized I / O communication method 700 may further include: reading the head pointer of the completion queue.

[0121] The completion queue head pointer is updated by the device driver component and is used to indicate the queue boundary corresponding to the completion queue for I / O requests whose requested resources have been released by the device driver component. For specific implementation details and technical effects, please refer to the previous sections on methods 300 and 500.

[0122] It is understood that the virtualized I / O communication method 300, virtualized I / O communication method 500 and virtualized I / O communication method 700 of the embodiments of this application can be executed concurrently for multiple I / O requests.

[0123] Corresponding to the application scenarios and methods 300 and 500 provided in the embodiments of this application, the embodiments of this application also provide a virtualized I / O communication device applied to a device driver component, comprising: a submission module, configured to write a descriptor of a pending I / O request to an idle entry in a descriptor table, and write the entry index of the pending I / O request in the descriptor table to a submission queue, wherein the descriptor is used to describe the metadata required by the device virtualization component to receive the pending I / O request; a receive confirmation pointer reading module, configured to read the receive confirmation pointer updated by the device virtualization component, wherein the receive confirmation pointer is used to indicate the queue boundary corresponding to the received I / O request in the submission queue; and an entry reclamation module, configured to release the entry corresponding to the received I / O request as an idle entry based on the receive confirmation pointer and a receive progress variable, wherein the receive progress variable is used to indicate the receive confirmation pointer on which the last entry release was based.

[0124] In one implementation, the entry recycling module is specifically used to: in response to the need to write a new pending I / O request descriptor to the descriptor table, release the entry corresponding to the received I / O request as an idle entry based on the receive confirmation pointer and the receive progress variable.

[0125] In one embodiment, the entry recycling module is specifically used to: determine the corresponding entry index range based on the difference between the receive confirmation pointer and the receive progress variable; release the entry corresponding to the entry index range in the descriptor table as an idle entry; further, the virtualized I / O communication device may also include: a receive progress variable update module, used to update the value of the receive progress variable to the value of the receive confirmation pointer.

[0126] In one embodiment, the submission module is specifically used to: write the pending I / O request into the submission queue based on the queue position represented by the submission queue tail variable, whereby the entry index of the I / O request to be processed in the descriptor table is written to the submission queue to submit the pending I / O request. The submission queue tail variable is used to represent the queue boundary of the submitted I / O request of the device driver component in the submission queue. Further, the virtualized I / O communication device may also include: a submission queue tail variable update module, used to increment the value of the submission queue tail variable by one.

[0127] In one implementation, the submission module is specifically used to: write the descriptor of the I / O request to be processed into a free entry represented by a free entry header variable in the descriptor table. The free entry header variable is used to represent the header entry index in the free descriptor chain. The free descriptor chain is formed by connecting the entry indices of each free entry in the descriptor table through a chain pointer. The descriptor of the I / O request to be processed includes a field for describing the metadata and a field for describing the next entry index corresponding to the I / O request to be processed. Further, the virtualized I / O communication device may also include: a free entry header variable update module, used to update the value of the free entry header variable to the field value of the next entry index.

[0128] In one embodiment, the virtualized I / O communication device further includes: an idle descriptor chain update module, configured to add the entry index of the released idle entry to the idle descriptor chain, and update the head entry index of the idle descriptor chain to: the entry index written at the queue position represented by the receiving progress variable in the submission queue.

[0129] In one embodiment, the virtualized I / O communication device further includes: a request identifier configuration module, configured to configure a corresponding request identifier for the I / O request to be processed; a request identifier field reading module, configured to read the request identifier field corresponding to the target queue interval from the completion queue, wherein the request identifier field is used to write the request identifier of the processed I / O request of the device virtualization component; and a request resource reclamation module, configured to identify the processed I / O request according to the read request identifier field and release the request resources associated with the processed I / O request.

[0130] In one implementation, the request identifier field reading module is specifically configured to: in response to a completion request interruption triggered by the device virtualization component, read the updated completion queue tail pointer of the device virtualization component, the completion queue tail pointer being used to indicate the queue boundary corresponding to the completed I / O request in the completion queue; determine the target queue interval based on the completion queue tail pointer and a completion progress variable, the completion progress variable being used to represent the completion queue tail pointer on which the previous reading of the request identifier field was based; and read the request identifier field corresponding to the target queue interval.

[0131] In one embodiment, the device further includes a completion queue tail pointer update module, configured to update the value of the completion progress variable to the value of the completion queue tail pointer after identifying the processed I / O request based on the read request identifier field and releasing the request resource associated with the processed I / O request; and update the completion queue head pointer based on the updated value of the completion progress variable, wherein the completion queue head pointer is for the device virtualization component to read and is used to indicate the queue boundary corresponding to the completion queue for I / O requests whose request resources have been released by the device driver component.

[0132] In one implementation, the descriptor table, the commit queue, and the completion queue are used to construct a virtualized I / O ring, which is located in the shared memory of the device driver component and the device virtualization component.

[0133] Corresponding to the application scenario and method 700 provided in the embodiments of this application, the embodiments of this application also provide a virtualized I / O communication device applied to a device virtualization component, including: an entry index reading module, used to read entry indexes written by a device driver component from a submission queue; a descriptor reading module, used to read descriptors corresponding to the entry indexes from a descriptor table, the descriptors being used to describe the metadata of the I / O request to be processed; and a receive confirmation pointer updating module, used to receive the I / O request to be processed according to the metadata of the I / O request to be processed, and update the receive confirmation pointer, the receive confirmation pointer being used to indicate the queue boundary of the received I / O request of the device virtualization component in the submission queue, and being used for the device driver component to release the entry corresponding to the received I / O request as an idle entry based on the receive confirmation pointer and a receive progress variable, the receive progress variable being used to represent the receive confirmation pointer on which the device driver component last released the entry.

[0134] In one embodiment, the metadata includes a request identifier of the pending I / O request. The device further includes a request identifier writing module, configured to write the request identifier of the processed I / O request of the device virtualization component into the request identifier field of the completion queue. The completion queue is used for the device driver component to read the corresponding request identifier field and release the request resources associated with the processed I / O request based on the read request identifier field.

[0135] In one embodiment, the device further includes a completion triggering module, configured to update the completion queue tail pointer after writing the request identifier of the processed I / O request of the device virtualization component into the request identifier field of the completion queue, the completion queue tail pointer being used to indicate the queue boundary of the processed I / O request in the completion queue; trigger a completion request interruption, the completion request interruption being used to notify the device driver component to: read the completion queue tail pointer, and determine the target queue interval based on the completion queue tail pointer and a completion progress variable, and read the request identifier field corresponding to the target queue interval, the completion progress variable being used to represent the completion queue tail pointer on which the device driver component last read the request identifier field.

[0136] In one embodiment, the device further includes a completion queue head pointer reading module for reading a completion queue head pointer, which is updated by the device driver component and is used to indicate the queue boundary corresponding to the completion queue for I / O requests whose requested resources have been released by the device driver component.

[0137] The functions of each module in each device in the embodiments of this application can be found in the corresponding description in the above method, and they have corresponding beneficial effects, which will not be repeated here.

[0138] Figure 8 This is a block diagram of an electronic device used to implement embodiments of this application. For example... Figure 8 As shown, the electronic device includes a memory 801 and a processor 802. The memory 801 stores a computer program that can run on the processor 802. When the processor 802 executes the computer program, it implements the method described in the above embodiments. The number of memories 801 and processors 802 can be one or more. In a specific implementation, the electronic device may also include a communication interface 803 for communicating with external devices and performing data exchange and transmission.

[0139] In practical implementation, if the memory 801, processor 802, and communication interface 803 are implemented independently, they can be interconnected via a bus to complete communication. This bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. This bus can be divided into address bus, data bus, control bus, etc. For ease of representation, Figure 8 The bus is represented by a single thick line, but this does not mean that there is only one bus or one type of bus.

[0140] Optionally, in a specific implementation, if the memory 801, the processor 802, and the communication interface 803 are integrated on a single chip, then the memory 801, the processor 802, and the communication interface 803 can communicate with each other through an internal interface.

[0141] This application provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the method provided in this application.

[0142] This application provides a computer program product, including a computer program that, when executed by a processor, implements the method provided in this application.

[0143] This application also provides a chip including a processor for calling and executing instructions stored in a memory, causing a communication device with the chip installed to perform the method provided in this application.

[0144] This application also provides a chip, including: an input interface, an output interface, a processor, and a memory. The input interface, output interface, processor, and memory are connected through an internal connection path. The processor is used to execute code in the memory. When the code is executed, the processor is used to execute the method provided in the application embodiment.

[0145] It should be understood that the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGAs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. General-purpose processors can be microprocessors or any conventional processor. It is worth noting that the processor can be a processor supporting Advanced Reduced Instruction Set Machines (ARM) architecture.

[0146] Further, optionally, the aforementioned memory may include read-only memory and random access memory. The memory may be volatile memory or non-volatile memory, or may include both. Non-volatile memory may include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), or flash memory. Volatile memory may include random access memory (RAM), which serves as an external cache. By way of example, but not limitation, many forms of RAM are available. Examples include Static Random Access Memory (SRAM), Dynamic Random Access Memory (DRAM), Synchronous DRAM (SDRAM), Double Data Rate SDRAM (DDR SDRAM), Enhanced Synchronous DRAM (ESDRAM), Sync Link DRAM (SLDRAM), and Direct Rambus RAM (DR RAM).

[0147] In the above embodiments, implementation can be achieved, in whole or in part, through software, hardware, firmware, or any combination thereof. When implemented in software, it can be implemented, in whole or in part, as a computer program product. A computer program product includes one or more computer instructions. When the computer program instructions are loaded and executed on a computer, all or part of the processes or functions according to this application are generated. The computer can be a general-purpose computer, a special-purpose computer, a computer network, or other programmable device. The computer instructions can be stored in a computer-readable storage medium or transferred from one computer-readable storage medium to another.

[0148] In the description of this specification, references to terms such as "one embodiment," "some embodiments," "example," "specific example," or "some examples," etc., indicate that a specific feature, structure, material, or characteristic described in connection with that embodiment or example is included in at least one embodiment or example of this application. Furthermore, the specific features, structures, materials, or characteristics described may be combined in any suitable manner in one or more embodiments or examples. Moreover, without contradiction, those skilled in the art can combine and integrate the different embodiments or examples described in this specification, as well as the features of those different embodiments or examples.

[0149] Furthermore, the terms "first" and "second" are used for descriptive purposes only and should not be construed as indicating or implying relative importance or implicitly specifying the number of technical features indicated. Thus, a feature defined as "first" or "second" may explicitly or implicitly include at least one of that feature. In the description of this application, "a plurality of" means two or more, unless otherwise explicitly specified.

[0150] Any process or method described in the flowchart or otherwise herein can be understood as representing a module, segment, or portion of code comprising one or more executable instructions for implementing a particular logical function or process. Furthermore, the scope of the preferred embodiments of this application includes additional implementations in which functions may be performed not in the order shown or discussed, including substantially simultaneously or in reverse order depending on the functionality involved.

[0151] The logic and / or steps described in the flowchart or otherwise herein, for example, can be considered as a sequenced list of executable instructions for implementing logical functions, and can be embodied in any computer-readable medium for use by, or in conjunction with, an instruction execution system, apparatus or device (such as a computer-based system, a processor-included system or other system that can fetch and execute instructions from, an instruction execution system, apparatus or device).

[0152] It should be understood that various parts of this application can be implemented using hardware, software, firmware, or a combination thereof. In the above embodiments, multiple steps or methods can be implemented using software or firmware stored in memory and executed by a suitable instruction execution system. All or part of the steps of the methods in the above embodiments can be implemented by a program instructing related hardware, the program being stored in a computer-readable storage medium, which, when executed, includes one or a combination of the steps of the method embodiments.

[0153] Furthermore, the functional units in the various embodiments of this application can be integrated into a processing module, or each unit can exist physically separately, or two or more units can be integrated into a module. The integrated module can be implemented in hardware or as a software functional module. If the integrated module is implemented as a software functional module and sold or used as an independent product, it can also be stored in a computer-readable storage medium. This storage medium can be a read-only memory, a disk, or an optical disk, etc.

[0154] The above description is merely an exemplary embodiment of this application, but the scope of protection of this application is not limited thereto. Any person skilled in the art can easily conceive of various variations or substitutions within the technical scope described in this application, and these should all be included within the scope of protection of this application. Therefore, the scope of protection of this application should be determined by the scope of the claims.

Claims

1. A virtualized I / O communication method, applied to a device driver component, comprising: Write the descriptor of the pending I / O request to the free entry of the descriptor table, and write the index of the pending I / O request in the descriptor table to the submission queue. The descriptor is used to describe the metadata required by the device virtualization component to receive the pending I / O request. Read the updated receive confirmation pointer of the device virtualization component, the receive confirmation pointer being used to indicate the queue boundary corresponding to the submission queue of the received I / O request of the device virtualization component; Based on the received confirmation pointer and the received progress variable, the entry corresponding to the received I / O request is released as an idle entry. The received progress variable is used to represent the received confirmation pointer on which the last entry release was based.

2. The method according to claim 1, wherein, The step of releasing the entry corresponding to the received I / O request as an idle entry based on the received confirmation pointer and the received progress variable includes: In response to the need to write a new pending I / O request to the descriptor table, the entry corresponding to the received I / O request is released as an idle entry based on the receive acknowledgment pointer and the receive progress variable.

3. The method according to claim 1, wherein, The step of releasing the entry corresponding to the received I / O request as an idle entry based on the received confirmation pointer and the received progress variable includes: The corresponding table entry index range is determined based on the difference between the received confirmation pointer and the received progress variable; Release the entries corresponding to the index range of the entries in the descriptor table as free entries; The method further includes: Update the value of the receiving progress variable to the value of the receiving confirmation pointer.

4. The method according to claim 1, wherein, The step of writing the index of the pending I / O request in the descriptor table to the submission queue includes: Based on the queue position represented by the tail variable of the submission queue, the I / O request to be processed is written into the submission queue according to the table entry index of the descriptor table to submit the I / O request to be processed. The tail variable of the submission queue is used to represent the queue boundary of the submitted I / O request of the device driver component in the submission queue. The method further includes: Increment the value of the variable at the tail of the submission queue by one.

5. The method according to claim 4, wherein, The step of writing the descriptor of the pending I / O request to the free entry of the descriptor table includes: The descriptor of the I / O request to be processed is written into the free entry represented by the free entry header variable in the descriptor table. The free entry header variable is used to represent the header entry index in the free descriptor chain. The free descriptor chain is formed by linking the entry indices of each free entry in the descriptor table through a chain pointer. The descriptor of the I / O request to be processed includes a field for describing the metadata and a field for describing the next entry index corresponding to the I / O request to be processed. The method further includes: Update the value of the header variable of the idle entry to the field value of the index of the next entry.

6. The method according to claim 5, wherein, Also includes: The index of the released free entry is added to the free descriptor chain, and the head entry index of the free descriptor chain is updated to the entry index written at the queue position represented by the receiving progress variable in the submission queue.

7. The method according to any one of claims 1 to 6, wherein, Also includes: Configure a corresponding request identifier for the I / O request to be processed; Read the request identifier field corresponding to the target queue interval from the completion queue, wherein the request identifier field is used to write the request identifier of the processed I / O request of the device virtualization component; The processed I / O request is identified based on the read request identifier field, and the request resource associated with the processed I / O request is released.

8. The method according to claim 7, wherein, The step of reading the request identifier field corresponding to the target queue interval from the completion queue includes: In response to a completion request interruption triggered by the device virtualization component, the updated completion queue tail pointer of the device virtualization component is read. The completion queue tail pointer is used to indicate the queue boundary corresponding to the completed I / O request in the completion queue. Based on the tail pointer of the completion queue and the completion progress variable, the target queue interval is determined, and the completion progress variable is used to represent the tail pointer of the completion queue on which the previous read request identifier field was based. Read the request identifier field corresponding to the target queue interval.

9. The method according to claim 8, wherein, After identifying the processed I / O request based on the read request identifier field and releasing the request resource associated with the processed I / O request, the method further includes: Update the value of the completion progress variable to the value of the tail pointer of the completion queue; The completion queue head pointer is updated based on the updated value of the completion progress variable. The completion queue head pointer is used for the device virtualization component to read and to indicate the queue boundary corresponding to the completion queue for I / O requests whose requested resources have been released by the device driver component.

10. The method according to claim 7, wherein, The descriptor table, the submission queue, and the completion queue are used to construct a virtualized I / O ring, which is located in the shared memory of the device driver component and the device virtualization component.

11. A virtualized I / O communication method, applied to a device virtualization component, comprising: Read the table entry index written by the device driver component from the submission queue; Read the descriptor corresponding to the table entry index from the descriptor table. The descriptor is used to describe the metadata of the I / O request to be processed. The pending I / O request is received according to its metadata, and the receive confirmation pointer is updated. The receive confirmation pointer is used to indicate the queue boundary of the submitted queue for the received I / O request of the device virtualization component, and is used for the device driver component to release the table entry corresponding to the received I / O request as an idle table entry based on the receive confirmation pointer and the receive progress variable. The receive progress variable is used to represent the receive confirmation pointer on which the device driver component last released the table entry.

12. The method according to claim 11, wherein, The metadata includes the request identifier of the I / O request to be processed, and the method further includes: The request identifier of the processed I / O request of the device virtualization component is written into the request identifier field of the completion queue. The completion queue is used for the device driver component to read the corresponding request identifier field and release the request resources associated with the processed I / O request according to the read request identifier field.

13. The method according to claim 12, wherein, After writing the request identifier of the processed I / O request of the device virtualization component into the request identifier field of the completion queue, the method further includes: Update the tail pointer of the completion queue, which is used to indicate the queue boundary of the processed I / O request corresponding to the completion queue; Trigger a completion request interruption, which is used to notify the device driver component to: read the tail pointer of the completion queue, and determine the target queue interval based on the tail pointer of the completion queue and the completion progress variable, and read the request identifier field corresponding to the target queue interval. The completion progress variable is used to represent the tail pointer of the completion queue on which the device driver component last read the request identifier field.

14. The method according to claim 13, wherein, Also includes: Read the head pointer of the completion queue, which is updated by the device driver component and is used to indicate the queue boundary corresponding to the completion queue for I / O requests whose requested resources have been released by the device driver component.

15. A virtualized I / O communication system, comprising: A host machine is configured to run a device virtualization component, the device virtualization component being used to implement the method of any one of claims 11 to 14; A virtual machine, hosted by the host machine, is configured to run a device driver component, the device driver component being used to implement the method of any one of claims 1 to 10.

16. The system according to claim 15, wherein, Also includes: Shared memory, configured to be shared by the device driver component and the device virtualization component, has a circular buffer for storing a descriptor table, a commit queue, and a completion queue.

17. An electronic device comprising a memory, a processor, and a computer program stored in the memory, wherein the processor, when executing the computer program, implements the method of any one of claims 1 to 14.

18. A computer-readable storage medium storing a computer program that, when executed by a processor, implements the method of any one of claims 1 to 14.

19. A computer program product comprising a computer program that, when executed by a processor, implements the method according to any one of claims 1 to 14.

Images