Fault resilient transactional processing device

Abstract

Embodiments of the present disclosure are directed to apparatuses, systems, and techniques for a fault resilient transactional processing device for a virtualized system. A request is received at a device connected to a computing system hosting one or more clients to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with the one or more clients. A page fault associated with execution of a DMA operation of a transaction is detected. A transaction fault handling protocol is selected from a set of transaction fault handling protocols to initiate to address the detected page fault. The selected transactional fault handling protocol is caused to be executed to address the detected page fault.

Description

Technical Field

[0001] At least one embodiment is directed to processing resources for performing and facilitating operations associated with a failure-resilient transaction processing device. Background Art

[0002] A computing system (e.g., a host system) may abstract and / or emulate one or more virtualized systems (e.g., client systems) as independent computing systems (e.g., from a user's perspective). The host system's virtualization manager may expose hardware devices (e.g., network devices, storage devices, graphics processing devices, etc.) as one or more virtual devices to a client (e.g., as part of a virtualized system) and may enable the client to communicate directly with the virtual devices. Direct memory access (DMA) refers to a function of a computing system that allows hardware to access memory without involving a processing unit (e.g., a central processing unit (CPU), etc.). Computing systems with devices that support DMA typically use an input / output memory management unit (IOMMU) to manage address translations between a device address space (e.g., a device address space associated with the device) and a physical address space (e.g., a physical address space associated with the host system). In a virtualized system, the client runs in the client address space and is unaware of the physical memory address of the data being accessed by the client. If the guest instructs the virtual device to perform DMA using addresses in the guest address space, the hardware device underlying the virtual device will not be aware of the mapping between the guest address space and the physical address space, so the DMA operation may be performed on an incorrect physical address.

[0003] In some cases, the host system can expose a larger amount of physical memory to each client than actually exists in the physical address space (referred to as memory overcommitment). As a result, when data associated with a client has not been accessed for a period of time, the data can be moved from the physical address space to a secondary data store (referred to as memory swapping). If a physical device performs a DMA operation to access memory that has been swapped out of the physical address space, an error (e.g., a page fault) can occur. BRIEF DESCRIPTION OF THE DRAWINGS

[0004] Various embodiments according to the present disclosure will be described with reference to the accompanying drawings, in which:

[0005] Figure 1A is a block diagram of an example system architecture according to at least one embodiment;

[0006] Figure 1B is a block diagram of another example system architecture according to at least one embodiment;

[0007] Figure 2 is a block diagram of an example device and an example computing system according to at least one embodiment;

[0008] Figure 3 A block diagram illustrating one or more engines associated with a failure resilient transaction processing device according to at least one embodiment is shown;

[0009] Figure 4 An example fault handling data structure is shown in accordance with at least one embodiment;

[0010] Figure 5 A flow chart illustrating an example method for handling page faults at a fault-resilient transaction processing device in accordance with at least one embodiment;

[0011] Fig. 6A A flow chart illustrating an example method of priority-based paging requests according to at least one embodiment;

[0012] Figure 6B A flow chart illustrating another example method for priority-based paging requests according to at least one embodiment is shown;

[0013] Figure 7 A flow chart illustrating yet another example method for priority-based paging requests according to at least one embodiment is shown;

[0014] FIG. 8A to FIG. 8B An example of completing one or more failed transactions at a device is shown in accordance with at least one embodiment;

[0015] FIG. 9A to FIG. 9B Another example of completing one or more failed transactions at a device is shown according to at least one embodiment;

[0016] Fig.10 An example completion recovery engine for a failure resilient transaction processing device according to at least one embodiment is shown;

[0017] Fig.11 A flowchart illustrating an example method for accomplishing synchronization according to at least one embodiment is shown;

[0018] Fig.12 A block diagram of an example computer device according to an embodiment of the present disclosure is shown. DETAILED DESCRIPTION

[0019] Modern computing systems (e.g., computing systems in data centers, etc.) can provide access to resources in virtualized environments (e.g., virtual machines, containers, etc.). For example, a virtualization manager of a computing system (referred to herein as a "host system" or simply "host") can abstract and / or emulate one or more virtualized systems (referred to herein as a "client system" or simply "client") as independent computing systems (e.g., from a user's perspective). The virtualization manager can be part of a host operating system, a hypervisor, a virtual machine monitor, etc., and the client can be a virtual machine, a container, etc. The virtualization manager can expose the physical resources of the host as virtual resources to the corresponding client. For example, the virtualization manager can partition one or more regions of the physical memory of the host (e.g., random access memory (RAM), storage memory, etc.), and can expose a collection of these partitioned memory regions as virtual memory (referred to herein as "client memory") to the client. Memory in a continuous physical memory address space or a non-contiguous physical memory address space can be exposed to the client as client memory in a continuous client memory address space.

[0020] Because a client may not consume all of the client memory allocated by the virtualization manager at any one point in time, some virtualization managers can expose a larger amount of memory to each client than actually exists in the physical memory space. This practice (referred to as memory over-allocation) can expand the amount of physical memory space available to the client without significantly affecting any single client's access to the client memory. If a client attempts to access data that is not located in the physical memory area allocated as client memory at the time (e.g., but is located in the host's secondary storage device), the virtualization manager can swap out other data from the allocated memory area according to a memory eviction protocol implemented on the computing system, and the requested data can be copied (e.g., from the secondary storage device) to replace the swapped out data. This practice is referred to herein as memory swapping.

[0021] In some computing systems, a virtualization manager can expose physical devices (e.g., network devices, storage devices, graphics processing devices, etc.) as one or more virtualized devices to a client. For example, the virtualization manager can divide the resources of each physical device (referred to herein as a "device") into one or more resources accessible to the client, and can expose and / or emulate these divided resource sets as virtual devices to the virtualization system. Thus, the client can communicate directly with the virtual device exposed by the virtualization manager (e.g., via a virtual connection, such as a virtual bus).

[0022] Direct memory access (DMA) refers to a function of a computing system that allows hardware to access memory without involving a processing unit (e.g., a central processing unit (CPU), etc.). The computing system can maintain an input / output memory management unit (IOMMU) that includes a mapping between a corresponding DMA memory address (e.g., associated with a device) and a physical address indicating a physical memory area where data is stored. In a non-virtualized system, the mapping can be provided and / or maintained by a driver associated with the device (e.g., run by a processing unit of the computing system). The device can access data residing in the physical memory of the computing system by transmitting a request indicating the corresponding DMA memory address to access the data. The corresponding DMA memory address is converted to a physical memory address using the IOMMU, and the data residing at the physical memory address can be retrieved in a memory area associated with the physical memory address (e.g., without involving decoding and analyzing the request by the processing unit of the computing system). To ensure that data associated with a DMA memory address is available in physical memory, one or more components of the computing system (e.g., an operating system (OS), etc.) may update metadata associated with the data to indicate that the data cannot be removed from or replaced at a specific area of ​​physical memory (referred to herein as "data pinning," "memory pinning," or simply "pinning"), and may update a mapping of the corresponding DMA memory address at the IOMMU to indicate the physical address of the specific area that includes the data. Pinned data may reside in a specific area of ​​physical memory until the operating system detects that the data is to be "unpinned" (e.g., metadata associated with the data is updated to indicate that the data may be removed from or replaced at a specific area).

[0023] In a virtualized environment, the IOMMU is managed by a virtualization manager. The virtualization manager can expose parts of the IOMMU to the client as a virtual IOMMU (vIOMMU) (e.g., parts of the IOMMU that include page tables that provide mappings of various levels of the client address space, etc.). However, the part of the IOMMU that involves converting DMA memory addresses to physical memory addresses is not exposed to the client, so it cannot be directly accessed by the client or device. Therefore, the driver of the hardware device cannot access the IOMMU to map and / or fix data in the client address space. The device driver can send a request to the virtualization manager to map and / or fix memory in the client address space. However, the device driver does not know the host address space allocated to the client, so it cannot specify an area of ​​the host address space to correspond to the client memory. Therefore, the device driver cannot facilitate mapping and / or pinning in the host address space and / or IOMMU.

[0024] To address the above problems, some virtualization managers provide emulation services, in which the virtualization manager presents a software interface to the client, which generally looks the same as the interface between the computing system and the physical device (e.g., from the client's perspective). According to such technology, the client may not be able to directly access the virtual device, but can access the emulated device through the software interface presented by the virtualization manager. The client can transmit the DMA memory address of a specific area of ​​the client address space to the virtualization manager, and the virtualization manager can map the DMA memory address to the corresponding client address at the IOMMU and / or can fix the memory associated with the client address in the host address space. Since the host system can host multiple clients, it may take a lot of time to map and / or fix the memory to enable DMA access between each client and the emulated device, and therefore consume a lot of computing resources. Therefore, there are fewer resources available for other processes in the computing system, which reduces the overall efficiency of the system and increases the overall latency of the system.

[0025] According to other techniques, the virtualization manager can map the entire portion of host memory allocated to the client to the DMA memory space, and can pin the client memory to the IOMMU before or during the client initialization period of the computing system (referred to as static mapping and static pinning). In such an implementation, the client can provide a DMA memory address to the device, and the device can perform DMA operations using the provided DMA memory address. However, mapping the entire allocated host memory portion and / or pinning the entire client memory may require a large amount of time, which consumes a large amount of computing resources. In addition, because the entire client memory is pinned to enable DMA access, the virtualization manager may no longer implement over-allocation techniques to optimize memory access for each corresponding client hosted on the computing system. In addition, pinning the entire client memory may prevent various optimization techniques (e.g., kernel memory sharing, etc.) that the OS running on the host can otherwise implement.

[0026] According to other techniques, the virtualization manager can intercept requests from clients to map and / or pin portions of client memory. The virtualization manager can map DMA memory addresses to corresponding client addresses and / or can pin host memory when intercepting such requests (referred to as dynamic mapping and dynamic pinning). The client can provide a DMA memory address to a device, and the device can perform DMA operations using the provided DMA addresses, as described above. However, switching between executing client operations and executing virtualization manager operations on a computing system may be computationally expensive and may have a negative impact on the performance of applications running on the client. In addition, the client may not know and cannot cooperate with a DMA mapping mechanism that enables the client to facilitate DMA mapping and / or pinning. Therefore, this technique cannot be applied to every type of client running on a host system. Finally, in some cases, a client that can cooperate with a DMA mapping mechanism (that enables the client to facilitate DMA mapping and / or pinning) can map and / or pin the entire client memory address space of the physical memory. In this case, the virtualization manager may not be able to implement a memory over-allocation technique to optimize memory access for each corresponding client hosted on the computing system without invoking a computationally complex protocol, which may reduce the overall efficiency of the computing system and increase the overall latency of the computing system. Additionally, a malicious client hosted on a computing system may abuse the interface between the virtualization manager and the client (e.g., by consuming a larger amount of host memory than is configured to be allocated to the malicious client), which may affect the performance of other clients and / or the computing system.

[0027] In some systems, a device abstracted or emulated by a virtualization manager for a client may issue a mapping request to the virtualization manager (e.g., in response to receiving a DMA memory address from a client). The virtualization manager may map the client memory, as described above. In such an implementation, the device knows the state of each page of the client memory (e.g., whether the client page is mapped into the client memory), and may issue a mapping request in response to determining that a page referenced by the client is not currently resident in the physical memory (referred to herein as a page fault). When the device controller waits for the virtualization manager to confirm that the client memory page is available in the physical memory and / or mapped to the IOMMU, the device controller may implement a page fault handling protocol on the device. For example, each DMA operation may be at least one of multiple operations of a transaction initiated on the device. The page fault handling protocol may involve the device controller suspending each operation of the transaction on the device until a confirmation is received that the client memory page is available in the physical memory and / or the client memory page has been mapped to the IOMMU. The device may take a significant amount of time (e.g., one second or more) to receive confirmation that the client memory page is available and / or has been pinned on the IOMMU, which may significantly delay the completion of the transaction and / or affect subsequent transactions. Such delays may significantly increase latency and reduce efficiencies associated with devices and computing systems. In another example, a page fault handling protocol for a device (e.g., a network device) may involve the device receiving a request to initiate a DMA operation to access a client memory page, discarding the request, and sending a notification to the requestor indicating that the device is currently unable to service the request and that the requestor should retransmit the request at a later time.

[0028] In conventional systems, a device may implement the same page fault handling protocol for each detected page fault. While it may be appropriate in some cases to delay transaction completion and / or discard the request and instruct the requester to retransmit the request at a later time, this approach may not be appropriate in every situation. For example, stalling a transaction at a network device may severely interrupt network traffic (e.g., for several milliseconds or longer), which can increase latency and reduce overall system efficiency and throughput. Other types of devices (e.g., data processing unit (DPU) emulation devices, etc.) may be associated with other types of constraints that can make stalling transactions a time-consuming and costly approach to resolving client page faults for DMA operations.

[0029] In addition, conventional techniques generally do not provide a mechanism that enables a device to pin client memory pages on the IOMMU to ensure that such client memory pages are available for future DMA operations in the client memory and to prevent page faults from occurring. If client memory pages frequently accessed by a particular virtual device are not pinned on the IOMMU, such memory pages may be evicted from the client memory and page faults may occur when the virtual device attempts to access such pages, as described above. Since each page fault may cause transaction delays on the device, the overall latency of the system may be further increased, and the overall efficiency and throughput of the system may be further reduced.

[0030] In addition, the system can use DMA techniques to access metadata (e.g., for work requests, completion requests, etc.), as described above. In some cases, if a page fault occurs (e.g., when a device attempts to access a memory page that includes data and a memory page that includes metadata), such a system can perform operations to handle page faults of the data memory page and / or the memory page that includes metadata. In an illustrative example, data of an inbound network packet can be successfully written to a memory page (e.g., by performing a DMA operation), but reporting completion of the successful write of the data may trigger a page fault. In this case, the device may implement additional fault handling protocols to handle page faults, which may delay transactions on the device, thereby increasing the overall latency of the system and reducing the overall efficiency and throughput of the system.

[0031] Embodiments of the present disclosure address the above and other deficiencies by providing techniques for transaction-aware devices for virtualized systems. Transaction-aware devices may include devices that can be abstracted and / or simulated by a virtualization manager as one or more virtual devices provided by a host system. In some embodiments, transaction-aware devices may include network devices (e.g., NIC devices), storage devices, data processing unit (DPU) devices, etc. In some embodiments, transaction-aware devices may include devices with emulation capabilities that may expose multiple emulated devices to a host system, each emulated device having a different interface type.

[0032] A fault resilient transaction processing device (referred to herein as a "device") may be configured to implement one or more of a set of transaction fault handling protocols in response to detecting a page fault during a DMA operation that is performing a transaction. A transaction refers to a series of one or more operations that are performed to perform a specific task associated with the device. A transaction may include one or more DMA operations and / or one or more non-DMA operations. The device may perform operations for one or more engines (e.g., a page processing engine, a transaction processing engine, an asynchronous request engine, etc.) to identify and implement the fault handling techniques described herein.

[0033] In some embodiments, a device may receive a request to initiate a transaction involving a DMA operation for accessing data associated with one or more clients of a host system. In response to detecting a page fault associated with the execution of a transaction, the device may select a transaction fault handling protocol to be initiated to resolve the detected page fault. The transaction fault handling protocol may be selected based on one or more matching criteria of the device, which may include one or more characteristics of the client associated with the transaction, one or more attributes associated with the transaction, and / or one or more attributes associated with a previous transaction initiated on the device. In an illustrative example, a device processor may access a transaction fault handling data structure, which includes a plurality of transaction fault handling protocols, each transaction fault handling protocol being associated with one or more matching criteria. In some embodiments, the device processor may identify an entry of a transaction fault handling data structure corresponding to a characteristic of the client, an attribute of the transaction, and / or an attribute of one or more previous transactions, and may determine a transaction fault handling protocol based on the identified entry. The device processor may cause the selected transaction fault handling protocol to be executed to resolve the detected page fault. In some embodiments, the transaction failure handling protocol may involve rescheduling at least one operation of the transaction (e.g., a DMA operation or a non-DMA operation), terminating the DMA operation of the transaction, and / or updating a memory address associated with the DMA operation to correspond to another memory address. Further details on selecting and executing a corresponding transaction failure handling protocol are described herein.

[0034] In additional or alternative embodiments, the fault-resilient transaction processing device may be configured to send a request to a virtualization manager associated with a client to make one or more memory pages associated with client data available in a specific area of ​​host memory and / or to pin one or more memory pages to a specific area of ​​host memory. For example, when a request to initiate a transaction is received at the device, the transaction may be added to a transaction queue. The device may evaluate the one or more transactions added to the transaction queue and may determine one or more memory pages to be accessed during the execution of the operation of the one or more transactions. In some embodiments, the device may determine whether the data of the memory page currently resides in the host memory, and if not, one or more requests to make the data of the memory page available in the host memory may be sent to the virtualization manager. In additional or alternative embodiments, the device processor may determine whether the data of the determined one or more memory pages should be retained in the host memory (e.g., at least until the execution of the operation of the one or more transactions is completed). If the data should be retained in the host memory, the device may send one or more requests to the virtualization manager to pin the memory page in the host memory. Once the device processor determines that execution of the operations of the one or more transactions has completed, the device processor may send one or more requests to unpin (eg, release) memory pages in the host memory to the virtualization manager.

[0035] Aspects and embodiments of the present disclosure provide a technology that enables a device to handle page faults caused by a DMA operation of a transaction according to a transaction fault handling protocol selected based on the characteristics of the client, the attributes of the transaction, and / or the attributes of a previous transaction on the device. For example, if a network device receives a request to write data to a specific area of ​​a client memory using a DMA operation and a page fault is detected, the network device can select a transaction fault handling protocol (e.g., write data to another area of ​​the client memory, etc.), which will resolve the detected page fault without pausing the transaction and interrupting network traffic. Therefore, the completion of the transaction on the device (e.g., access to the requested data and / or metadata) will not be unnecessarily delayed, which can improve the overall efficiency and throughput of the system and reduce the overall latency of the system. In addition, embodiments of the present disclosure provide a technology that enables a device to resolve page faults before encountering a page fault, which can significantly reduce the number of faulty transactions on the device. As the number of faulty transactions decreases, the overall throughput of the system increases. In addition, as the number of faulty transactions decreases, fewer computing resources are consumed to process such faulty transactions, which improves the overall efficiency of the system and reduces the overall latency of the system. Finally, by enabling the device to request memory pages that are available on host memory, the device may implement page handling techniques that improve performance at the device rather than relying on page handling techniques (eg, general purpose memory management algorithms) that may be implemented on the host computing system.

[0036] It should be noted that although some embodiments of the present disclosure relate to DMA operations, embodiments of the present disclosure may also be applied to remote DMA (RDMA) operations. Further details and examples related to RDMA operations are described herein. It should also be noted that although some embodiments of the present disclosure relate to computing systems that host one or more clients, embodiments of the present disclosure may be applied to any type of computing system (e.g., a computing system that does not host clients, etc.). In addition, embodiments of the present disclosure that relate to client data may also be applied to host data or any other type of data at a computing system.

[0037] Figure 1A 1 is a high-level block diagram of an example system architecture 100 according to at least one embodiment. Those skilled in the art will appreciate that other architectures of the system architecture 100 are possible, and implementations utilizing the embodiments and example system architectures of the present disclosure are not necessarily limited to Figure 1A Specific architecture shown.

[0038] In some embodiments, the system architecture 100 may include a computing system 102 that hosts one or more virtualized systems (e.g., clients 120A, 120B, and / or 120C). In some embodiments, the computing system 102 may correspond to one or more servers in a data center. The computing system 102 may include one or more physical devices that may be used to support the clients 120A, 120B, 120C (collectively and individually referred to herein as "clients 120" or "clients 120"). For example, the computing system 102 may include one or more processing devices 104 (e.g., central processing units (CPUs), graphics processing units, etc.) and / or memory 106. One or more processing units may be embodied as processing devices 104, which may be and / or include a microprocessor, a digital signal processor (DSP), or other processing component. The memory 106 may include volatile memory devices (e.g., random access memory (RAM)), non-volatile memory devices (e.g., flash memory), storage devices (e.g., magnetic hard disks, universal serial bus (USB) solid state drives, redundant array of independent disks (RAID) systems, network attached storage (NAS) arrays, etc.), and / or other types of memory devices. It should be noted that although Figure 1A 104, but this is merely illustrative, and in some embodiments, computing system 102 may include two or more processing devices 104. Similarly, in additional or alternative embodiments, computing system 100 may include two or more memory components instead of a single memory component. Processing device 104 may be connected to memory 106 via a host bus. In some embodiments, one or more components of computing system 102 may correspond to Fig.12 A computer device 1200 is described.

[0039] like Figure 1A As shown, system architecture 100 may include one or more devices 130A, 130B, 130C (individually and collectively referred to herein as "device 130" or "multiple devices 130"). Device 130 may include any device that is internally or externally connected to another device (e.g., host system 102) and performs input operations and / or output operations upon receiving a request from the connected device. In some embodiments, device 130 may be a network device, a storage device, a graphics processing device, etc. In additional or alternative embodiments, device 130 may host a device with emulation functionality that is configured to expose one or more emulated devices, the emulated devices having different interface types. For more details about devices with emulation functionality, please refer to Figure 1B Give a description.

[0040] As described above, the computing system 102 may host one or more virtualization systems 120. In some embodiments, the virtualization system 102 may include a virtual machine (e.g., a virtual runtime environment that emulates the underlying hardware of the computing system) and / or a container (e.g., a virtual runtime environment that runs on an OS kernel and emulates the OS instead of the underlying hardware). The computing system 102 may execute a virtualization manager 108 that is configured to manage a client 120 running on the computing system 102 (also referred to herein as a "host system 102" or simply "host 102"). The virtualization manager 108 may be a separate component or part of an operating system 110 (e.g., a host OS), a virtual machine manager (not shown), etc. A client representing a virtual machine may execute a client OS 122 to allow client software (one or more client applications) to access virtualized resources representing the underlying hardware. A client representing a container virtualizes the host OS 110 so that the client software (one or more containerized applications) perceives that it fully owns the host OS 110 and the underlying hardware (e.g., processing device 104, memory 106, etc.).

[0041] The virtualization manager 108 may abstract hardware components of the host system 102 and / or the device 130 and present the abstraction to the client 120. For example, the virtualization manager 108 may abstract the processing device 104 to the client 120A as a client processor 124A, to the client 120B as a client processor 124B, and / or to the client 120C as a client processor 124C. In some embodiments, the virtualization manager 108 may abstract the processing device 104 for the client 120 by selecting a time slot on the processing device 104, rather than dedicating the processing device 104 to the client 120. In other or similar embodiments, the virtualization manager 108 may abstract one or more portions of the memory 106 and present the abstraction to the client 120A as client memory 126A. In some embodiments, the virtualization manager 108 may abstract one or more different portions of the memory 106 and present the abstraction to the client 120B as client memory 126B and / or to the client 120C as client memory 126C. The virtualization manager 108 may abstract the memory 106 by using a page table to translate memory accesses associated with the abstracted memory 126 into physical memory addresses of the memory 106. During runtime of an application instance at the client 120, the virtualization manager 108 may intercept client memory access operations (e.g., read operations, write operations, etc.) and may translate client memory addresses associated with the intercepted operations into physical memory addresses at the memory 106 using the page table.

[0042] Since it is unlikely that each client 120 will consume a complete portion of memory 106 allocated by virtualization manager 108 at any one point in time, virtualization manager 108 may expose a greater amount of memory to each client than is actually present in memory 106. For example, memory 106 may include volatile memory (e.g., RAM). Virtualization manager 108 may expose a greater amount of total memory space to clients 120A, 120B, and 120C than is actually available in memory 106. In response to detecting that one or more of clients 120A, 120B, or 120C is attempting to access data of a memory page that is not currently resident in memory 106 (e.g., the memory page resides in a secondary storage device (not shown) of host system 102), virtualization manager 108 may remove another memory page from memory 106 (e.g., according to a memory page eviction protocol, etc.) and may copy the memory page containing the data to memory 106. Removing a memory page from memory 106 and copying another memory page to memory 106 is referred to as memory page swapping. Exposing a greater amount of memory to client 120 than is actually present in storage 106 is referred to as memory over-allocation.

[0043] The virtualization manager 108 may abstract one or more devices and present the abstraction as a virtual device to the client 120. For example, in some embodiments, the virtualization manager may abstract one or more of the devices 130A, 130B, 130C and present the abstraction as a virtual device 132A, 132B, 134A, 134B, 136A, and / or 136B to the client 120A, 120B, and / or 120C. In some embodiments, the virtualization manager 108 may abstract the device by assigning a specific port range to an interface slot of the device 130 to the client 120 and presenting the assigned port range as a virtual device (132, 134, and / or 136). The client 120 may utilize the client processor 124, the client memory 126, and / or the virtual devices 132, 134, 136 to support execution of an application or application instance on the client 120.

[0044] In some embodiments, one or more of devices 130A, 130B, and / or 130C may support direct memory access (DMA) of memory 106. DMA allows hardware (e.g., device 130, etc.) to access memory without involving a processing unit (e.g., processing device 104). Device 130 may access memory 106 by performing one or more DMA operations that reference DMA memory addresses. In some embodiments, the DMA operations may include operations for at least one of: reading data from a region of memory 106 associated with a DMA memory address, writing data to a region of memory 106 associated with a DMA memory address, and the like. In some embodiments, the DMA operations may be atomic operations. Virtualization manager 108 may manage input / output memory management unit (IOMMU) 112 that maintains a mapping between DMA memory addresses (e.g., DMA memory addresses associated with device 130) and physical memory addresses of memory 106 (e.g., physical memory addresses associated with host system 102). In response to receiving a DMA operation to perform a DMA operation (e.g., a DMA operation of a transaction, such as regarding Figure 2106 , the device 130 may determine whether a memory page associated with the requested DMA memory address is available at the memory 106. In some embodiments, the memory page may correspond to a client memory page. The memory page may be unavailable at the memory 106 if: the data of the memory page is not stored in the memory 106, the data of the memory page is present in the memory 106 but the IOMMU 112 does not contain a mapping of the memory page, and / or the data of the memory page is present in the memory 106 and the IOMMU 112 contains a mapping of the memory page, but one or more permissions associated with the IOMMU 112 (e.g., read / write permissions, user / supervisor permissions, executable permissions, etc.) prevent the device 130 from accessing the mapping of the memory page. In other or similar embodiments, a memory page may be unavailable at memory 106 if the memory page is a read-only memory page and device 130 attempts to write data to the memory page, the memory page is a write-only memory page and device 130 attempts to read data from the memory page, the memory page is associated with virtualization manager 108 (or another host entity associated with computing system 102 and / or another computing system) and a device 130 that is allowed to access client data is attempting to access the memory page, and so on.

[0045] In response to detecting that a memory page is unavailable at memory 106 (referred to herein as a page fault), device 130 may select a transaction fault handling protocol based on characteristics of client 120, attributes of a transaction including a DMA operation, and / or one or more of previous transactions initiated at device 130. Device 130 may initiate the selected transaction fault handling protocol to resolve the page fault. In some embodiments, the transaction fault handling protocol may include one or more of the following operations: rescheduling one or more operations of the transaction (e.g., a DMA operation, another DMA operation, a non-DMA operation), terminating a DMA operation, and / or updating a memory address associated with a DMA operation to correspond to another memory address. More details on selecting and initiating a transaction fault handling protocol will be referred to in detail in the accompanying drawings. Figure 2 Give a description.

[0046] In additional or alternative embodiments, the device 130 may determine one or more memory pages that should be available on the memory 106 (e.g., based on DMA operations for future transactions). The device 130 may send a request to the virtualization manager 108 to copy the one or more memory pages to the memory 106 and update the IOMMU 112 to include a mapping between a DMA memory address associated with the memory page and a physical address of a region in the memory 106 where the data of the memory page is stored. In some embodiments, the device 130 may send an additional or alternative request to the virtualization manager 108 to pin the data of the one or more memory pages to the region of the memory 106. As described above, pinning data to the memory 106 refers to updating metadata associated with the memory page including the data to indicate that the data will not be removed from the region of the memory 106 (e.g., until a request to unpin the data is received, until a certain amount of time has passed, etc.). Further details regarding sending a request to the virtualization manager 108 to make the data available at the memory 106 and / or to pin the data to the memory 106 will be referred to. Figure 2 Give a description.

[0047] Figure 1B 1 is a block diagram of another example system architecture 150 according to at least one embodiment. As described above, in some embodiments, the computing system 102 can be connected to one or more devices 180 with simulation capabilities. Devices 180 with simulation capabilities refer to devices that include one or more components (referred to herein as simulation components) that can be configured to function as another type of device. In some embodiments, the simulation components can be implemented as software components, hardware components, or a combination of software components and hardware components (e.g., software executed by a processor of the device).

[0048] In some embodiments, the device 180 with emulation function can be configured to expose one or more emulation devices (e.g., emulation device 182A, emulation device 182B, etc.) to the computing system 102. Each emulation device 182A, 182B (collectively and individually referred to herein as (one or more) emulation devices 182) can be associated with a different interface type exposed by the device 180 with emulation function to the computing system 102. In an illustrative example, the device 180 with emulation function can be a data processing unit (DPU) configured to expose an emulation processing unit (e.g., an emulation GPU, etc.), an emulation device with a non-volatile memory express (NVMe) interface, an emulation block device (e.g., a virtio-blk device, etc.), an emulation network device (e.g., a virtio-net device), and / or an emulation network controller device (e.g., a network interface card (NIC)). In some embodiments, the device 180 with emulation function can be configured to expose a native device interface (e.g., a NIC interface) and / or an emulation device interface (e.g., an NVMe interface). In additional or alternative embodiments, the device 180 with emulation function can support dynamic paging. Such a device 180 with emulation capability can insert dynamic paging capabilities for a static paging device (e.g., a legacy device). In an illustrative example, the device 180 with emulation capability can reside on or otherwise be connected to the computing system 102. One or more physical devices (e.g., device 130) can be connected to the device 180 with emulation capability. In such an example, the device 180 with emulation capability can expose one or more emulation interfaces to the device 130 and can mediate communications between the computing system 102, the client 120, and / or the device 130. In some embodiments, such mediation can include transferring data to and from the client 120 and handling page faults according to embodiments described herein. The device 180 with emulation capability can temporarily store (e.g., pin) client data in a specific area of ​​physical memory associated with the computing system 102. The device 130 can access the data from the temporary area of ​​the physical memory. Therefore, the client data is directly exposed to the device 130, and the device 130 is unaware of the page fault, which is handled by the device 180 with emulation capability.

[0049] It should be noted that the embodiments of the present disclosure can be applied to Figure 1A One or more devices 130 and / or Figure 1B One or more devices 180 with simulation function in the present invention. This article focuses on the embodiments particularly related to the device 180 with simulation function. However, unless otherwise specified, it should be understood that each embodiment of the present disclosure can be applied to the device 130 and / or the device 180 with simulation function.

[0050] Figure 2 is a block diagram of an example device 210 and an example computing system 100 according to at least one embodiment. In some embodiments, the device 210 may correspond to Figure 1A In other or similar embodiments, device 210 may correspond to any of devices 130A, 130B, or 130C described herein. Figure 1B The described emulated device 180. Figure 2 As shown, in some embodiments, the device 210 may have one or more processors 220 and / or memory 228. The processor 220 may include any type of processing unit configured to perform logical operations. In some embodiments, the processor 220 may include one or more CPUs or any other type of processing unit. In some embodiments, the processor 220 may be a programmable extension of the device 210 (e.g., the processor 220 is not exposed to the computing system 102 and / or otherwise accessible to the computing system 102). In other or similar embodiments, the processor 220 may be a programmable extension of one or more components or modules of the computing system 102 (e.g., the processor 220 is exposed to the computing system 102 and / or otherwise accessible to the computing system 102). For example, the processor 220 may be a programmable extension of the virtualization manager 108 and / or one or more clients 120. In some embodiments, the memory 228 may include volatile memory or non-volatile memory. It should be noted that although Figure 2 Memory 228 is depicted as a component of device 210 and may include any memory accessible to device 210 (eg, internal or external to device 210 ).

[0051] In some embodiments, the device 210 may receive a request to initiate one or more transactions. In some embodiments, a transaction may involve performing one or more operations, which may include DMA operations (e.g., accessing data associated with one or more clients 120) and / or non-DMA operations. The device 210 may receive a transaction request from one or more entities (referred to herein as a transaction requester). In some embodiments, the transaction requester may include one or more components or modules (e.g., client 120, etc.) executed at the computing system 102. In other or similar embodiments, the transaction requester may be an entity that runs independently of the computing system 102 (e.g., another computing system that can communicate with the device 210 via a network or system bus). The device 210 may provide services for the received requested transaction by performing one or more operations of the transaction. In some embodiments, the device 210 may access data associated with one or more entities (referred to herein as a transaction target) (e.g., read data, write data, erase data, etc.) after completing the execution of one or more operations. In some embodiments, the transaction target may be the same entity as the transaction requester and / or may run on the same computing system as the transaction requester. In other or similar embodiments, the transaction target may be a different entity than the transaction requester and / or may be running on a different computing system than the transaction requester.

[0052] In at least one example, the device 210 may be a transmitting (TX) network device (e.g., a TX Ethernet network device, etc.). In such an example, the device 210 may receive a request to initiate a transaction associated with sending a data packet to a transaction target (e.g., another computing system) that is not at the computing system 102 from one or more components or modules of the computing system 102 (e.g., one or more clients 120). According to embodiments described herein, the device 210 may access data associated with the transaction from the memory 106 and may send the data packet to the transaction target. In at least another example, the device 210 may be a receiving (RX) network device (e.g., an RX Ethernet network device, an RDMA network device, etc.). In such an example, the device 210 may receive a request to initiate one or more transactions associated with the data packet from a transaction requester that is not at the computing system 102. According to embodiments described herein, the device 210 may perform one or more DMA operations (and / or RDMA operations) of the transaction to write data of the data packet to a memory page associated with one or more clients 120. In yet at least another example, the device 210 may be a data compression device (e.g., a data encoder device, etc.). The device 210 may receive a request to initiate a transaction to compress data from a memory page of the memory 106 (e.g., a client memory page) and store the compressed data in the memory 106 from one or more components or modules of the computing system 102 (e.g., one or more clients 120). According to embodiments described herein, the device 210 may perform one or more DMA operations of the transaction to read data from the memory page of the memory 106 and write the compressed data to the memory page of the memory 106. In yet another example, the device 210 may be a block write device. The device 210 may receive a request to initiate a transaction to read data and / or metadata (e.g., an operation descriptor) from a memory page (e.g., a client memory page) of the computing system 102 and write a completion status of the read data and / or metadata to the memory 106 from one or more components or modules of the computing system 102 (e.g., one or more clients 120). According to embodiments described herein, the device 210 may perform one or more DMA operations to read data and / or metadata from the memory page of the memory 106 and write the completion status to the memory page of the memory 106. It should be noted that the examples provided above are for illustration purposes only. According to embodiments of the present disclosure, device 210 may be another type of device and / or may receive requests to initiate other types of transactions from entities residing in computing system 102 and / or other computing systems.

[0053] In some embodiments, device 210 may maintain a transaction queue 212. Figure 2As shown, in some embodiments, the transaction queue 212 may reside in one or more portions of the memory 228. For example, one or more portions of the memory 228 may include a memory buffer allocated at the transaction queue 212. In other or similar embodiments, the transaction queue 212 may reside in another portion of the device 210 (e.g., outside the memory 228). In still other or similar embodiments, the transaction queue 212 may reside in a portion of the memory 106 (e.g., at the client memory 230, as described below, etc.). In response to receiving a request to initiate a transaction, the device 210 may add the transaction to the transaction queue 212 (e.g., as a transaction 214). In some embodiments, the device 210 may add the transaction 214 to the transaction queue 212 according to a priority and / or ordering associated with the transaction 214 or other transactions 214 in the transaction queue 212. For example, the device 210 may add transactions 214B and / or 214N to the transaction queue 212 before receiving a request to initiate transaction 214A. However, device 210 may determine that transaction 214A is associated with a higher priority than transactions 214B and / or 214N (e.g., taking into account metadata received with the request, taking into account a state associated with the transaction requestor, etc.), and may add transaction 214A to a position such that transaction 214A will be resolved before transactions 214B and / or 214N.

[0054] In other or similar embodiments, the transaction requester may add the transaction 214 to the transaction queue 212. For example, the transaction queue 212 may reside in the memory 106 (e.g., in a portion of the client memory space 230A, 230N, etc., as described below, etc.). The transaction requester may add the transaction 214 to the transaction queue 212 at the client memory space 230, and one or more components of the computing system 102 (e.g., the virtualization manager 108) may send a notification to the device 210 indicating that the transaction 214 has been added to the transaction queue 212. In some embodiments, the notification may be provided directly through a memory management IO (MMIO) access. For example, the client 120 may send a request to write data to the client memory space 230. In some embodiments, a memory management unit (MMU) controlled by the virtualization manager 108 (not shown) may convert the write request to a PCIe request (or another type of communication protocol request). Thus, the MMU may directly access the device 210 (e.g., through a PCIe request) without intervention by the virtualization manager 108. Upon receiving the request, device 210 may access client memory space 230 and may initiate operations of transaction 214 (eg, in accordance with embodiments described herein).

[0055] In other or similar embodiments, the device 210 (e.g., an RX network device) may access (e.g., at the memory 228 or at the memory 106) a plurality of transaction queues 212, each transaction queue being associated with a transaction target (or a network address associated with a transaction target). In one or more examples, upon receiving a network packet, the device 210 may parse the network packet of the transaction 214 to determine the network address associated with the transaction target, and may add the transaction 214 to the queue 212 associated with the transaction target. Once the transaction 214 is added to the queue 212, the operation of the transaction 214 may be performed, as described herein. According to one or more of the foregoing examples, the operation of the transaction 214 may involve dispersing the data of the network packet to one or more buffers at the device 210 (e.g., indicated by one or more parameters of the network packet). It should be noted that according to other or similar embodiments, the device 210 (or another entity associated with the system architecture 100) may add the transaction 214 to the transaction queue 212.

[0056] It should be noted that although Figure 2 The transaction queue 212 is depicted as a single queue, but in some embodiments, the transaction queue 212 may include one or more queues. In other or similar embodiments, one or more portions of the transaction queue 212 may be configured to store different types of transactions 214. For example, if the device 210 is a network device (e.g., a TX network device, an RX network device, etc.), a first portion of the transaction queue 212 may be configured to store transactions 214 received from a first entity, and a second portion of the transaction queue 212 may be configured to store transactions 214 received from a second entity.

[0057] As described above, transaction 214 may involve performing one or more DMA operations 216A and / or one or more non-DMA operations 216B. According to the examples and embodiments described previously, one or more DMA operations may involve accessing data of a memory page residing in a memory 106 space allocated to client 120A (e.g., client memory space 230A of memory 106) and / or client 120N (e.g., client memory space 230N of memory 106). Page processing engine 222 may attempt to access a client memory page containing data by performing one or more DMA operations 216A. In some embodiments, data (or metadata) of transaction 214 may indicate a DMA memory address associated with performing DMA operation 216A. Therefore, device 210 may determine the DMA memory address of DMA operation 216A based on data (or metadata) of transaction 214.

[0058] In some embodiments, while performing one or more DMA operations, the data of the client memory page is not available on the memory 106 (e.g., the data is stored on a secondary storage device, etc.). As described above, this situation is referred to herein as a page fault. In response to the page processing engine 222 detecting the page fault, the transaction processing engine 224 may select a transaction fault handling protocol to resolve the page fault. In some embodiments, the transaction processing engine 224 may use a fault handling data structure (e.g., Figure 3 and Figure 4 The transaction processing engine 224 may select a transaction fault handling protocol based on other techniques. Further details on selecting and initiating a transaction fault handling protocol to resolve a detected page fault are described herein.

[0059] like Figure 2 As shown, the device 210 may also include an asynchronous request engine 226. The asynchronous request engine 226 may evaluate the transaction 214 added to the transaction queue 212, and may identify one or more memory pages (e.g., client memory pages) to be involved during the execution of the operation 216 of the transaction 214. In some embodiments, the asynchronous request engine 226 may send one or more requests to the virtualization manager 108 to make data of the client memory pages to be involved during the execution of the operation 216 available at the memory 106. In additional or alternative embodiments, the asynchronous request engine 226 may send one or more requests to the virtualization manager 108 to pin one or more client memory pages to the memory 106, as described above. Further details regarding the asynchronous request engine 226 are described above.

[0060] In some embodiments, the virtualization manager 108 may also include a page processing engine 240 and / or a transaction processing engine 242. The page processing engine 240 may be configured to make data of a client memory page available at the memory 106 (e.g., copy data from a secondary storage device to the memory 106, etc.). In some embodiments, the page processing engine 240 may make data of a client memory page available at the memory 106 in response to a request from the page processing engine 222 and / or the asynchronous request engine 226 of the device 210. In some embodiments, the page processing engine 240 may also generate a mapping between a DMA address associated with the client memory page (e.g., as indicated in a request received from the page processing engine 222 and / or the asynchronous request engine 226) and a physical address associated with a region of the memory 106 that includes the client memory page. The page processing engine 240 may update the IOMMU 112 to include the generated mapping. In additional or alternative embodiments, the page processing engine 240 may pin a client memory page to the memory 106 by updating metadata associated with the client memory page (e.g., in the memory 106, in the IOMMU 112, etc.) to indicate that the data of the client memory page is not to be removed from the memory 106. In some embodiments, the page processing engine 222 may pin a client memory page in response to a request from the page processing engine 222 and / or the asynchronous request engine 226. The page processing engine 222 may similarly unpin a client memory page on the memory 106 by updating metadata to indicate that the data of the client memory page may be removed from the memory 106. Further details regarding the page processing engine 222 are described herein. In some embodiments, the transaction processing engine 242 of the virtualization manager 108 may be configured to perform operations associated with a transaction failure handling protocol selected by the transaction processing engine 224. Further details regarding the transaction processing engine 242 are described herein. It should be noted that although Figure 2 While the page processing engine 240 and the transaction processing engine 242 are depicted as components of the virtualization manager 108 , the page processing engine 240 and / or the transaction processing engine 242 may be components of other engines or modules executing at the computing system 102 .

[0061] In some embodiments, device 210 may be an integrated component of computing system 102. In other or similar embodiments, device 210 may be an external component of computing system 102. Figure 2As shown, device 210 can be connected to computing system 102 via connection 250. In some embodiments, connection 250 may include a system bus. For example, connection 250 may correspond to at least one of a peripheral component interconnect express (PCIe) interface, a communication express link (CXL) interface, a die-to-die (D2D) interconnect interface, a chip-to-chip (C2C) interconnect interface, a graphics processing unit (GPU) interconnect interface, or a coherent accelerator processor interface (CAPI). In some embodiments, device 210 may be a root complex integrated endpoint device. In such embodiments, connection 250 may be exposed as a PCIe / CXL interface (e.g., exposed to client 120, etc.), even though connection 250 may not be a PCIe interface. In other or similar embodiments, connection 250 may be associated with a non-standard connection protocol. In still other or similar embodiments, connection 250 may be a connection through a network (e.g., a public network, a private network, a wired network, a cellular network, and / or a combination thereof). As Figure 2 As shown, the device 210 can communicate with each client 120 hosted by the computing system 102. In some embodiments, the device 210 can communicate with the client 120 via a virtual connection 252 (e.g., a virtual bus, etc.). For example, the device 210 can communicate with the client 120A via a first virtual connection 252A and can communicate with the client 120N via a second virtual connection 252N. According to the previously described embodiments, the virtualization manager 108 can abstract the hardware components of the computing system 102 (e.g., a system bus between the device 210 and the computing system 102) and present this abstraction to the client 120 as a virtual connection 252.

[0062] According to at least one embodiment, Figure 3 A block diagram of one or more engines associated with a failure resilient transaction processing device is shown. According to at least one embodiment, Figure 4 An example fault handling data structure 352 is shown. Figure 5 Detailed information is provided for one or more engines and example failure handling data structures associated with a failure resilient transaction processing device.

[0063] According to at least one embodiment, Figure 5 A flowchart of an example method 500 for handling page faults at a fault-resilient transaction processing device is shown. In some embodiments, one or more operations of the example method 500 may be performed by Figure 3, as described herein. Method 500 may be performed by processing logic, which may include hardware (circuitry, dedicated logic, etc.), software (e.g., instructions executed on a processing device), or a combination thereof. In one implementation, some or all of the operations of method 500 may be performed by device 210. For example, some or all of the operations of method 500 may be performed by one or more components of page processing engine 222 and / or transaction processing engine 224 (e.g., resident at device 210), as described herein.

[0064] At block 510, processing logic receives a request to initiate a transaction involving a DMA operation for accessing data associated with at least one of one or more clients hosted by a computing system. Figure 2 As described, the device 210 may receive a request to initiate a transaction 214 that includes one or more DMA operations 216A for accessing data residing at one or more client memory pages of the memory 106. The page request component 302 of the page processing engine 222 may determine a DMA memory address associated with the data, and may perform one or more DMA operations 216A to access the data at the memory region associated with the DMA memory address. In some embodiments, the page request component 302 may determine the DMA memory address based on information included in the received request. In other or similar embodiments, the page request component 302 may determine the DMA memory address using one or more data structures that store information associated with DMA accessible client data and that are accessible by the device 210. In additional or alternative embodiments, the page request component 302 may determine the DMA memory address based on other techniques.

[0065] review Figure 5At block 512, processing logic detects a page fault associated with the execution of a DMA operation (e.g., DMA operation 216A) of the transaction. The page request component 302 of the page processing engine 222 may perform one or more DMA operations 216A to attempt to access the requested data at one or more client memory pages associated with the DMA address. If the data of the client memory page is available at the memory 106, the page request component 302 may access the data and may complete the DMA operation 216A (and / or non-DMA operation 216B) to complete the transaction 214 as requested. However, if the data of the client memory page is not available at the memory 106, the page fault detection component 304 of the page processing engine 222 may detect the page fault. In some embodiments, even if the data is available at the memory 106, a page fault may occur because the DMA memory address (or access rights and / or privileges) associated with the requested data is inaccurate. For example, the mapping associated with the client memory page at the IOMMU 112 may not include the latest DMA memory address. In such embodiments, the page request component 302 may send a request to a page synchronization component 316 of the page processing engine 240. The page synchronization component 316 may update a mapping associated with a client memory page at the IOMMU 112 to include the latest DMA memory address. In response to receiving a confirmation from the page synchronization component 316 that the IOMMU 112 has been updated to include the updated mapping, the page request component 302 may access the data of the client memory page, as described above. Although the above embodiments provide that the page synchronization component 316 updates the mapping at the IOMMU 112 to include the latest DMA memory address in response to a request from the page request component 302, in some embodiments, the page synchronization component 316 may update the mapping at the IOMMU 112 asynchronously (e.g., without receiving a request). For example, in some embodiments, the page synchronization component 316 may remove a mapping from the IOMMU 112. When a page mapping is removed from the IOMMU 112, the page synchronization component 316 may notify the page request component 302 and / or the page fault detection component 304 that the page mapping is unavailable.

[0066] review Figure 5At block 514, the processing logic selects a transaction fault handling protocol to be initiated to resolve the detected page fault from two or more transaction fault handling protocols. Since the failed DMA operation 216A is part of the transaction 214, the transaction 214 including the failed DMA operation 216A is also considered to be faulted. In response to detecting that the transaction 214 has a transaction fault, the fault protocol lookup component 306 can select a transaction fault handling protocol to be initiated to resolve the transaction fault and the corresponding page fault. In some embodiments, the fault protocol lookup component 306 can select a transaction fault handling protocol from a plurality of different transaction fault handling protocols associated with the system architecture 100. The transaction fault handling protocol associated with the system architecture 100 can involve rescheduling one or more operations (e.g., the failed DMA operation 216A, another DMA operation 216A, a non-DMA operation 216B) at the device 210, terminating one or more operations of the transaction, and / or updating a DMA memory address associated with the failed DMA operation 216A and / or another DMA operation 216A to correspond to another DMA memory address. More details about the transaction failure handling protocol are provided herein. For purposes of example and illustration only, the embodiments described below may refer to transaction 214A as a failure transaction and transactions 214B-N as other transactions. However, it should be noted that according to the embodiments and examples described herein, any transaction 214 may be a failure transaction and / or another transaction.

[0067] In some embodiments, the fault protocol lookup component 306 can select a transaction fault handling protocol to resolve the fault transaction 214A and the corresponding page fault based on one or more matching criteria. The matching criteria can be based on state and / or stateless attributes, and can include characteristics associated with one or more clients 120 (e.g., the client 120 associated with the client memory page involved in the page fault, etc.), attributes of the fault transaction 214A, and / or attributes of one or more previous transactions 214 initiated at the device 210. The characteristics associated with the client 120 can refer to one or more types of applications running on the client 120, the state of the applications running on the client 120, the type associated with the client 120 (e.g., whether the client 120 is a virtual machine or a container), one or more security settings or protocols associated with the client 120 (e.g., whether the client 120 is an encrypted client or an unencrypted client, the encryption protocol associated with the client 120, etc.), and the like. The attributes of a transaction 214 (e.g., a fault transaction 214A and / or one or more previous transactions 214) may refer to a type associated with the transaction 214 (e.g., whether the transaction 214 is a transmit (TX) network transaction, a receive (RX) network transaction, a compression transaction, a work queue transaction, a completion queue transaction, etc.), a protocol associated with the transaction 214, a data type associated with the transaction (e.g., whether the TCP network packet of the transaction 214 is a TCP control packet or a TCP packet, etc.), a context affiliation of the transaction 214, a queue affiliation of the transaction 214, a client affinity of the transaction 214, etc. As described above, the device 210 may be a device with emulation functionality that is configured to expose multiple emulation devices to a host system, each emulation device having a different interface type. In such embodiments, the attributes of the transaction may additionally or alternatively include a subtype associated with the transaction 214, wherein the transaction subtype refers to the type of different interfaces associated with the emulation device exposed by the device with emulation functionality. In other or similar embodiments, the device 210 may expose multiple sets of functionality (with or without emulation) to the computing system 102. The transaction subtype may additionally or alternatively refer to the type of functionality provided by the single device 210 associated with the transaction 214 (e.g., data replication functionality, data compression functionality, data encryption functionality, etc.). In other or similar embodiments, the device 210 may support multiple interfaces. The transaction subtype may additionally or alternatively refer to the type of interface associated with the transaction 214. In some embodiments, the attribute of the previous transaction 214 may also refer to the number of previous transactions 214 that failed at the device 210.

[0068] In additional or alternative embodiments, the fault protocol lookup component 306 may be selected based on one or more state criteria associated with the device 210. A state criterion refers to the state of one or more entities of the system architecture 100. In some embodiments, the state criteria may include the state of the device 210, the state of the client 120, the state of the computing system 102, the state of a connection between two or more entities of the system architecture 100, and the like (referred to herein as global state criteria). In other or similar embodiments, the state criteria may include the state of one or more transactions 214 at the transaction queue 212 and / or the state of a previous transaction 214 initiated at the device 210 (referred to herein as transaction state criteria). For example, the state criteria of a transaction may include the execution state of the faulty transaction 214A and / or other transactions 214 in the transaction queue (e.g., whether the transaction 214 has been initiated, is being executed, has been completed, etc.), the fault state of the faulty transaction 214A and / or the previous transaction 214, and the like. In still other or similar embodiments, the state criteria may include the state of a subset (e.g., one or more operations) of the transaction 214 (referred to herein as a transaction subset state criteria). In some embodiments, the status criteria may be related to the failed transaction 214A and / or other failed transactions in the device 210. In other or similar embodiments, the status criteria may not be related to the failed transaction 214A and / or another failed transaction at the device 210. In additional or alternative embodiments, the status criteria may refer to the availability of one or more buffers (e.g., backup buffers 356A, 356B, etc.) associated with the device 210. The fault protocol lookup component 306 may use the status database to determine the status criteria associated with the device 210 to be considered with the matching criteria, as described in further detail herein.

[0069] In some embodiments, the fault protocol lookup component 306 may select a transaction fault handling protocol to initiate to resolve the transaction fault and the corresponding page fault. In some embodiments, the fault protocol lookup component 306 may select a transaction fault handling protocol using a fault handling data structure 352. In some embodiments, the fault handling data structure 352 may reside in the memory 228 of the device 210. In some embodiments, the fault handling data structure 352 may be stored in the memory 228 during the initialization of the device 210. In additional or alternative embodiments, the fault handling data structure 352 may not reside in the memory 228, but may reside in other memories associated with the system architecture 100 (e.g., in the memory 106, in another memory of the computing system 102, and / or in another computing system, etc.). In such embodiments, the device 210 may access the fault handling data structure 352 (e.g., via the connection 250, via a network, etc.) according to the embodiments described herein.

[0070] Figure 4 35 shows an example fault handling data structure 352 according to at least one embodiment. The fault handling data structure 352 can be any type of data structure configured to store one or more data items. In an illustrative example, the fault handling data structure 352 can be a table, such as Figure 4 However, it should be noted that in some embodiments, the fault handling data structure 352 may not be a table, but may be any other type of data structure that can store data items.

[0071] like Figure 4 As shown, the fault handling data structure 352 may include one or more entries 410. Each entry 410 may include a field 412 indicating one or more match criteria and a field 418 indicating a fault handling protocol to be initiated to handle a transaction fault (and corresponding page fault) with reference to the match criteria. The match criteria field 412 may include one or more fields that include information associated with the match criteria, as described above. For example, the match criteria field 412 may include fields associated with characteristics of the client 120, attributes of the fault transaction 214, and / or attributes of one or more previous transactions 214 initiated at the device 210. In the illustrative example, as Figure 4 As shown, the matching criteria field 412 may include a transaction type field 420 (e.g., including information about the type of transaction 214), a transaction subtype field 422 (e.g., including information about the subtype of the transaction 214), and / or one or more additional fields 426 (e.g., including information related to other matching criteria, such as client characteristics, emulation device characteristics, etc.). In some embodiments, the state criteria of the transaction 214 may depend on one or more matching criteria of the transaction. Therefore, the matching criteria field 412 may include a transaction state field 424 (e.g., including information related to the state of the transaction 214 or one or more previous transactions 214). In additional or alternative embodiments, the state criteria of the transaction 214 may be independent of the matching criteria of the transaction 214. Therefore, the entry 410 may include one or more state criteria 416, which includes information related to the state criteria, as described above. The information included in any matching criteria field 412 may be referred to as the matching criteria 412 in this article. The information contained in the state criteria field 416 may be referred to as the state criteria 416 in this article.

[0072] In additional or alternative embodiments, the state criteria field 416 may not indicate one or more state criteria associated with the device 210, but may include a state lookup field 428. In some embodiments, the state lookup field 428 may indicate the type of state data to be accessed and / or the technique to be used to determine the state criteria associated with the device 210. The state criteria determined according to the information contained in the state lookup field 428 (e.g., together with the matching criteria 412) may be considered to select the fault handling protocol 418 to be used to resolve the fault transaction 214, as described herein. In some embodiments, the information of the state lookup field 428 may indicate one or more state databases 450 that include state data associated with the device 210, the client 120, the computing system 102, a connection between two or more entities of the system architecture 100, etc. In some embodiments, the data contained in the state database 450 may correspond to global state criteria and / or transaction state criteria.

[0073] The fault handling protocol field 418 may include one or more of an action field 430, a range field 432, and / or a recovery field 434. The action field 430 may include an indication of an action that may be taken to resolve the transaction fault and the corresponding page fault. As described above, the action of the corresponding transaction fault handling protocol may involve rescheduling one or more operations 216 of the faulty transaction 214A (or another transaction 214B-214N) at the device 210 (referred to herein as a rescheduling action), terminating one or more operations 216 of the faulty transaction 214A (referred to herein as a termination action), and / or updating a DMA memory address associated with the faulty DMA operation 216A or another DMA operation 216A to correspond to another DMA memory address (referred to herein as a reassociation action). The action field 430 may include an indication of the type of action taken to resolve the faulty transaction 214A for the match criteria (e.g., as indicated by the match criteria field 412) and / or the state criteria (e.g., as determined based on the information indicated by the state lookup field 416) of the transaction.

[0074] Rescheduling one or more operations 216 of the faulting transaction 214A (or another transaction 214B-N) at the device 210 may involve attempting to re-execute the one or more operations 216 at a subsequent time period. In some embodiments, the device 210 may reschedule the execution of the one or more operations 216 at a time period (or after) a request to access a memory page that caused a page fault is sent to the computing system 102. In some embodiments (e.g., to perform operations associated with the rescheduling action, upon receiving a notification indicating that a page fault has been processed, etc.), the device 210 may block the operations 216 of the faulting transaction 214A, the operations 216 of a portion of the transactions 214 at the transaction queue 212, or the operations 216 of all transactions 214 at the transaction queue 212 (e.g., considering the matching criteria of the faulting transaction 214). The action field 430 of the entry 410 with a particular matching criteria may indicate whether to block the operations 216 of the faulting transaction 214A and / or one or more of the other transactions 214B-N in the transaction queue 212 until the faulting transaction 214A is processed (e.g., the problem that caused the page fault is resolved). If the action field 430 of the entry 410 indicates that a portion of the transactions 214 in the transaction queue 212 are to be blocked, the action field 430 may further indicate which transactions are to be blocked (e.g., transactions 214 of a particular type, transactions 214B-214N received within a certain time after the failed transaction 214A, etc.). In an illustrative example, the entry 410 with the matching criteria may have the action field 430, wherein the matching criteria indicates that the type of the device 210 is a transmitting (TX) network device (e.g., a TX NIC), and the action field 430 indicates that, in order to resolve the failed transaction 214A, the device 210 should block transactions 214 at a portion of the transaction queue 212 (e.g., corresponding to the transmit queue) until the failed transaction 214A is processed, but transactions 214B-214N at other portions of the transaction queue 212 (e.g., corresponding to one or more other transmit queues) may be initiated before or while the failed transaction 214A is processed. In another illustrative example, an entry 410 with matching criteria may have an action field 430, where the matching criteria indicates that the type of device 210 is a block device or a compression device, and the action field 430 indicates that operations 216 of the failed transaction will be blocked until the failed transaction 214A is processed, but operations 216 of other transactions 214B-214N (e.g., subsequent transactions 214) at the transaction queue 212 may be initiated before or while the failed transaction 214A is processed.

[0075] As described above, the termination action may involve terminating one or more operations of the failed transaction 214A and / or other transactions 214B-214N. In some embodiments, to perform the operations associated with the termination action, the device 210 may or may not notify the transaction requester and / or the transaction target that one or more operations 216 of the failed transaction 214 have been terminated and / or successfully completed. The action field 430 of an entry with a particular match criterion 412 and / or state criterion 416 may indicate whether the termination is to be notified to the requester (or another entity) of the failed transaction 214A. In an illustrative example, an entry 410 with a match criterion 412 may have an action field 430, wherein the match criterion 412 indicates that the type of the transaction 214 is an inbound network packet, indicating that the transaction is to be discarded and no notification is issued to the transaction requester. In another illustrative example, an entry 410 having a matching criterion 412 may have an action field 430, wherein the matching criterion 412 indicates that the type of the device 210 is an RDMA network device, the action field 430 indicating that the operation involving the RDMA read response and / or the subsequent inbound transaction 214 will be discarded and no notification will be issued to the transaction requester. The action field 430 may also indicate that the read request and / or the subsequent transaction will be retransmitted by the device 210, and the protocol will be repeated until a threshold number of transactions are retransmitted. The action field 430 may indicate that if the threshold number of transactions are retransmitted, an error completion notification will be issued to the transaction requester and / or the transaction target. In another illustrative example, an entry 410 having a matching criterion 412 may have an action field 430, wherein the matching criterion 412 indicates that the type of the device 210 is a compression device, the action field 430 indicating that the device 210 is to notify the requester and / or the target that a portion of the DMA operation 216A of the failed transaction 214 has been successfully completed (e.g., a portion of the data of the transaction has been compressed). In yet another illustrative example, an entry 410 with a match criterion 412 may have an action field 430, wherein the match criterion 412 indicates that the type of device 210 is a storage device, the action field 430 indicating that the device 210 will notify the requester and / or target after a page fault of a transaction 214 that the data has not been written to the memory 106. In yet another illustrative example, an entry 410 with a match criterion 412 may have an action field 430, wherein the match criterion 412 indicates that the type of device 210 is an RDMA network device, the action field 430 indicating that the device 210 will send a notification of the faulted transaction 214A to the requester, indicating that the requester will retransmit the request at a later time. In some embodiments, the action field 430 may also indicate that the device 210 will notify the requester of the amount of time the requester is to wait before retransmitting the request. In some embodiments, the amount of time may depend on the severity of the page fault.In additional or alternative examples, the action field 430 may instruct the device 210 to notify the requester of the failed transaction 214 but not instruct the requester to retransmit the request.

[0076] As described above, the reassociation action may involve reassociating the DMA memory address of the memory page that caused the page fault with another DMA memory address. For example, a transaction requester may request that data be written to one or more client memory pages associated with a specific DMA memory address. The reassociation action may involve determining one or more other client memory pages associated with another DMA memory address (e.g., memory pages available at the memory 106), and writing data to the other client memory pages through one or more DMA operations 216A. In some embodiments, the action field 430 may indicate one or more alternative DMA memory addresses to be used to perform the reassociation action. For example, the action field 430 may indicate one or more backup DMA memory addresses that will be used to perform the reassociation action in response to a fault transaction 214A having one or more specific matching criteria 412 and / or status criteria 416. According to embodiments described herein, such backup DMA memory addresses may be associated with a backup memory buffer (e.g., residing in the memory 228, residing in the memory 106, residing in another memory of the system architecture 100, etc.). In some embodiments, the backing memory buffer may be managed by a transaction requester, a transaction target, the device 210 , and / or one or more components of the computing system 102 (eg, the virtualization manager 108 ).

[0077] In other or similar embodiments, the action field 430 may indicate that an alternative DMA memory address may be determined based on data (or metadata) associated with the failed transaction 214A. For example, the transaction 214 received by the RX network device may include an indication of multiple operations 216. The RX network device may receive a packet, and upon receiving, the RX network device may initiate the execution of one or more operations of the RX transaction 214 based on the data of the received packet. An entry 410 with a matching criterion 412 may have an action field 430, the matching criterion 412 indicating that the type of the device 210 is an RX network device, and the action field 430 indicates that the device 210 will determine that the packet of the transaction (e.g., transaction 214A) will be reassociated with another transaction (e.g., transaction 214B). By reassociating the packet with the transaction 214B, the DMA memory address associated with the packet is updated according to the transaction 214B. In some embodiments, the transaction skip protocol may indicate the number of times a packet (e.g., a packet associated with the transaction 214A, another packet, etc.) can be reassociated with another transaction. For example, the protocol may dictate the total number of transactions that can be skipped, the number of transactions that can be skipped within a certain time frame, and so on.

[0078] After processing the failed transaction, the device may send a notification indicating the transaction status (e.g., to the transaction requester, the transaction target, etc.). Based on the previous example, the RX network device may send a notification indicating that the transaction has been skipped (e.g., according to the transaction skip protocol). The RX network device may send a notification when a transaction failure is detected or after processing a transaction failure. In some embodiments, the RX network device may indicate (e.g., in a notification) that the transaction requester will reissue the transaction in view of the skipped transaction. In other or similar embodiments, the RX network device may not send a notification to the transaction requester. Instead, the RX network device may reuse the failed transaction (e.g., after processing the failure) for the incoming packet.

[0079] In some cases, the action field 430 may indicate whether a notification is to be sent to the transaction requester and / or the transaction target indicating the DMA memory address associated with the failed client memory page. In other or similar cases, the action field 430 may indicate whether the DMA memory address associated with the failed client memory page is to be used to buffer data for subsequent transactions 214 (e.g., after the page fault is resolved).

[0080] In some embodiments, the action field 430 of the entry 410 may indicate that if a buffer associated with the backup or alternate DMA memory address is available (e.g., in memory 106, in memory 228, etc.), a reassociation action is to be taken. The action field 430 of the entry 410 may indicate that if the associated buffer is not available, an alternative action is to be taken (e.g., a termination action, a rescheduling action, etc.). In some embodiments, the status criteria field 416 and / or information indicated by the status lookup field 428 of such an entry 410 may indicate the status of a buffer (e.g., a backup buffer, etc.) associated with the backup or alternate DMA memory address.

[0081] like Figure 4As shown, the fault handling protocol field 418 may include a range field 432. The range field 432 of the entry 410 may include an indication of the range of actions indicated by the action field 430 that are to be taken to resolve the page fault and the corresponding faulting transaction 214A. In some embodiments, the actions taken to resolve the faulting transaction 214A are taken for the DMA operation 216A that caused or otherwise resulted in the corresponding page fault. However, one or more additional operations 216 (e.g., additional DMA operations 216A, non-DMA operations 216B) and / or one or more additional transactions 214 (e.g., transactions 214B-N) may be affected by the faulting transaction 214A. In some embodiments, the information indicated by the range field 432 of the entry 410 may indicate whether the action indicated by the action field 430 (and / or additional or alternative actions) is to be performed for the one or more additional operations 216 and / or one or more additional transactions 214 at the transaction queue 212.

[0082] As described above, a transaction 214 may involve multiple DMA operations 216A. In some embodiments, one or more DMA operations 216A of a transaction 214 may succeed (e.g., no page fault occurs during the execution of the DMA operation 216A), while other DMA operations 216A of the transaction 214 may fail (e.g., a page fault occurs during the execution of the DMA operation 216A). For example, a failed transaction 214A may correspond to an inbound network packet (e.g., an Ethernet jumbo frame packet) received by a device 210 (e.g., a network device). A transaction 214A may include three DMA operations 216A, each associated with a different DMA memory address. The range field 432 of an entry 410 with a corresponding match criterion 412 may indicate whether an action is to be taken for a failed DMA operation 216A (e.g., a DMA operation 216A that causes a page fault and a corresponding transaction fault), a failed DMA operation 216A and a subsequent DMA operation 216A, or each DMA operation 216A of a transaction 214A (indicated by the action field 430 of the entry 410). If termination actions are to be taken for one or more DMA operations 216A, the scope field 432 and / or the action field 430 of the corresponding entry 410 may indicate whether notifications regarding successful and / or failed DMA operations 216A are to be sent to the transaction requester and / or the transaction target, as described above. If reassociation actions are to be taken for one or more DMA operations 216A, the scope field 432 and / or the action field 430 of the corresponding entry 410 may indicate whether the failed DMA operation 216A is to be reassociated with a backup or alternate DMA memory address, or whether one or more additional DMA operations 216A are to be reassociated with a backup or alternate DMA memory address, as described above. The scope field 432 and / or the action field 430 of the corresponding entry 410 may additionally or alternatively indicate whether notifications indicating the reassociated DMA memory address are to be transmitted to the transaction requester and / or the transaction target.

[0083] In some cases, the failed transaction 214A may affect one or more subsequent transactions (e.g., transactions 214B-214N). The scope field 432 of the entry 410 may indicate whether to take action (indicated by the action field 430 of the entry 410) for one or more operations 216 of all transactions 214B-N after the failed transaction 214A and / or a specific number of transactions 214B-N after the failed transaction 214A. In some embodiments, the scope field 432 may additionally or alternatively indicate whether to take action for the operations 216 of all transactions 214B-214N after the failed transaction 214A until a specific matching criterion (e.g., indicated by the matching criterion field 412 or other matching criterion) is met. In one illustrative example, the scope field 432 of the entry 410 with the specific matching criterion 412 may indicate that a specific number of subsequent transactions 214B-214N of the failed transaction 214A are to be copied to a backup memory buffer (e.g., backup buffer 356A, backup buffer 356B, etc., as described herein). In another illustrative example, the action field 430 of the entry 410 may indicate that for a failed transaction 214A with a particular matching criterion 412, a termination action is to be performed for the failed transaction 214A. The scope field 432 of the entry 410 may also indicate that the termination action is to be performed for each subsequent transaction 214B-214N in the transaction queue 212 after the failed transaction 214A. In some embodiments, the scope field 432 may also indicate that a notification about the terminated subsequent transaction 214B-214N is to be sent to the transaction requester and / or the transaction target. In yet another illustrative example, the action field 430 of the entry 410 may indicate that for a failed transaction 214A with a particular matching criterion 412 (e.g., the device is an RDMA network device, a packet with a packet sequence number (PSN) encounters a page fault, a receiver not ready negative acknowledgement (RNR NAK) transaction is sent due to a page fault, and a retransmitted packet with the same PSN is received, etc.), a termination action is to be performed for the failed transaction 214A. The range field 432 may also indicate that a termination action is to be performed on each subsequent transaction 214B-N until a transaction 214 associated with a packet sequence number corresponding to the packet sequence number of the failed transaction 214A is added to the transaction queue 212 .

[0084] like Figure 4As shown, the fault handling protocol field 418 may include a recovery field 434. The recovery field 434 of the entry 410 may include an indication of one or more entities involved in the recovery or handling of the page fault (e.g., according to the action indicated by the action field 430). If the entity performs one or more operations associated with the transaction fault handling protocol to resolve the page fault, or if the entity is notified of the initiation or completion of the page fault and / or operations associated with the transaction fault handling protocol, the entity may participate in the recovery or handling of the page fault. For an entry 410 indicating that a rescheduling action is to be taken, in some embodiments, the recovery field 434 may indicate that one or more components of the device 210 (e.g., the transaction processing engine 224, the page processing engine 222, etc.) are to perform operations associated with the rescheduling action to handle the faulted transaction 214. In other or similar embodiments, an entry 410 indicating that a termination action is to be taken may have a recovery field 434 that indicates that one or more components of the device 210 and / or the transaction requester are to perform operations associated with the termination action. For example, an entry 410 with a match criterion 412 may indicate that a termination action is taken in response to a detected page fault, the match criterion 412 indicating that the type of device 210 is an RDMA network device and / or the type of transaction 214 corresponds to a network packet (e.g., having a PSN). The recovery field 434 of the entry 410 may indicate that after detecting a page fault, one or more components of the RDMA network device are to notify the transaction requester of the page fault (e.g., by sending an RNR NAK packet). Each subsequent transaction corresponding to a network packet with a subsequent PSN may be discarded (e.g., until the transaction requester retransmits the packet (e.g., according to one or more protocols of the transaction requester)). The recovery field 430 may additionally or alternatively indicate that if one or more operations of the transaction 214A are terminated (e.g., the packet is discarded), the transaction requester is to start a timeout sequence before retransmitting the packet. In some embodiments, the length of time that the transaction requester is to wait before retransmitting the packet may depend on the severity of the transaction fault. For example, a minor transaction fault may trigger a delay of 10 microseconds, while a severe transaction fault may trigger a delay of 1 millisecond. In another example, the resume field 434 may indicate that the transaction requester is to resend the packet at another transport level. The RDMA network device may re-initiate the transaction according to the indication of the resume field 434.

[0085] In some embodiments, an entry 410 indicating that a reassociation action is to be taken may have a resume field 434 indicating that one or more entities (e.g., device 210, transaction requester, transaction target, etc.) are to perform operations associated with the reassociation action. For example, the resume field 434 of an entry 410 having a particular match criterion 412 may indicate that one or more components of the device 210 are to perform operations associated with the rescheduling action. In some embodiments, the resume field 434 may also indicate that the device 210 is to send a notification of the rescheduling action to the computing system 102 and / or the transaction target. In another example, the resume field 434 of an entry 410 having a particular match criterion 412 may indicate that one or more components of the computing system 102 (e.g., virtualization manager 108) are to perform operations associated with the rescheduling action. The resume field 434 may also indicate that a connection is to be established between the device 210 and one or more components of the computing system 102 (e.g., virtualization manager 108, client 120, etc.) in order to reschedule the transaction. For example, the rescheduling action may involve copying data from a backup memory location to a memory buffer of the client (e.g., rather than copying the data to the memory location originally indicated by the transaction 214). In some embodiments, the restore field 434 may indicate that the virtualization manager 108 is to enable copying from the backup memory location to the client memory space 230. In yet another example, the restore field 434 of the entry 410 having a particular matching criteria 412 may indicate that one or more components associated with the reassociation action (e.g., a component of the device 210, a component of the computing system 102, etc.) are to send a notification to the transaction target indicating that the data of the transaction 214 is written to an alternate region of the memory 106 that is different from the memory region indicated by the transaction 214. In some embodiments, the transaction target may access the data according to the address associated with the alternate region of the memory 106. In additional or alternative embodiments, the transaction target may not copy the data to the memory region indicated by the transaction 214.

[0086] As described above, in some embodiments, the resume field 434 of the entry 410 may indicate that the device 210 is to perform one or more operations of the fault handling protocol. In other or similar embodiments, the resume field 434 of the entry 410 may indicate that another entity (e.g., the computing system 102, the transaction requester, the transaction target, etc.) is to perform one or more operations of the fault handling protocol and / or is to be notified of the execution of one or more operations. In some embodiments, the entity that is to perform one or more operations may access the fault handling data structure 352 according to the embodiments described herein and may determine which operations of the fault handling protocol are to be performed in view of the information contained in the one or more fault handling protocol fields 418. In other or similar embodiments, the device 210 may send a notification and / or one or more instructions to the entity indicating that the entity is to perform one or more operations and / or that the execution of one or more operations has been initiated and / or completed.

[0087] It should be noted that the description and / or Figure 4 The embodiments shown in are for illustrative purposes only and are not intended to be limiting. In some embodiments, the data of one or more fields and / or entries 410 of the fault handling data structure 352 may be distributed over one or more entities (e.g., one or more entities of the system architecture 100 and / or other system architectures). In additional or alternative embodiments, multiple matching criteria 412 and / or state criteria may correspond to a single fault handling protocol 418. In yet other additional or alternative embodiments, the matching criteria 412 and / or state criteria may correspond to multiple different state types, each of which corresponds to a different fault handling protocol 418. It should also be noted that, according to the examples provided above, in some embodiments, information indicated by a particular field of the fault handling data structure 352 may be included in other fields of the fault handling data structure. For example, information related to the state of one or more buffers associated with a backup and / or alternative DMA memory address may be indicated in the state criteria field 416 and / or determined based on information in the state lookup field 428 rather than in the action field 430.

[0088] review Figure 3, the fault protocol lookup component 306 can use the fault handling data structure 352 to select a transaction fault handling protocol to be initiated to resolve the page fault and the corresponding faulting transaction 214A. In the illustrative example, the fault protocol lookup component 306 can identify data associated with the device 210, the client 120, the transaction 214A, and / or the transaction 214B-214N. The identified data can correspond to characteristic data associated with the device 210 and / or the client 120, state data associated with the device 210, the client 120, and / or another entity (system architecture 100 and / or another entity of another system architecture), and / or information associated with the transaction 214A and / or the transaction 214B-N (e.g., as indicated by data of the transaction 214 and / or metadata associated with the transaction 214). The identified data can correspond to one or more matching criteria 412 indicated by one or more entries 410 of the fault handling data structure 352. In some embodiments, the fault protocol lookup component 306 can identify the data by accessing an area of ​​the memory 228 storing the data (e.g., one or more registers, etc.). In other or similar embodiments, the fault protocol lookup component 306 can query the virtualization manager 108 or another component of the computing system 102 to obtain the data.

[0089] In response to identifying the data, the fault protocol lookup component 306 may identify an entry 410 of the fault handling data structure 352 that includes a match criterion 412 and / or a state criterion 416 corresponding to the identified data. In an illustrative example, the identified data may indicate that the device 210 is an RDMA network device. The fault protocol lookup component 306 may identify an entry 410 of the data structure 352 that includes a match criterion 412 corresponding to the RDMA network device. In another illustrative example, the identified data may indicate that the transaction 214A is a network packet and a certain number of network packets received before the packet of transaction 214A have been terminated (e.g., according to a fault handling protocol selected using the data structure 352). The fault protocol lookup component 306 may identify an entry 410 of the data structure 352 that includes a match criterion 412 corresponding to the network packet and a state criterion corresponding to the number of previous network packets that have been terminated before the device 210 received the network packet of transaction 214A.

[0090] The fault protocol lookup component 306 may determine a fault handling protocol 418 to be initiated to resolve the page fault and the corresponding faulting transaction 214A based on the identified entry 410, the identified entry 410 including the match criteria 412 and / or the state criteria 416 corresponding to the identified data. For example, in response to identifying the entry 410, the fault protocol lookup component 306 may determine from the identified entry 410 an action to be taken to resolve the page fault and the corresponding faulting transaction 214A (e.g., from the action field 430), a scope of the action to be taken (e.g., from the scope field 432), and / or one or more entities to participate in recovering from or otherwise handling the page fault (e.g., from the recovery field 434). In some embodiments, the determined action, scope, and recovery entity may correspond to the fault handling protocol to be initiated to resolve the page fault and the corresponding faulting transaction 214A.

[0091] It should be noted that although some embodiments of the present disclosure provide that the fault protocol lookup component 306 selects a transaction fault handling protocol to be used to resolve the page fault and the corresponding fault transaction 214A, in additional or alternative embodiments, the fault protocol lookup component 306 may select a transaction fault handling protocol based on other techniques. For example, the fault protocol lookup component 306 may provide the identified data associated with the device 210, the client 120, the transaction 214A, and / or the transaction 214B-214N as an input to a function. The function may be configured to provide as an output an indication of a fault handling protocol to be initiated based on the data given as input. In another example, the fault protocol lookup component 306 may use the identified data associated with the device 210, the client 120, the transaction 214A, and / or the transaction 214B-214N as an input to a machine learning model. The machine learning model may be trained to predict a fault handling protocol that satisfies one or more performance criteria associated with the device 210 and / or the system architecture 100 based on given characteristics or state data associated with one or more entities of the system architecture 100 and / or data or metadata associated with the transaction 214. In some embodiments, the machine learning model can be trained using historical and / or experimental data associated with the system architecture 100 and / or another system architecture. The fault protocol lookup component 306 can select a transaction fault handling protocol to be used to resolve the page fault and the corresponding faulting transaction 214A from one or more outputs of the machine learning model.

[0092] In another example, the fault protocol lookup component 306 (or another component of the transaction processing engine 224) can identify the transaction fault handling protocol based on the engine (e.g., at the device 210) that is to process one or more operations of the transaction 214. In an illustrative example, the device 210 may include an RX transaction engine configured to process operations associated with RX type operations and a TX transaction engine configured to process operations associated with TX type operations. The device 210 can issue different interrupts based on whether a page fault is detected during or after performing an RX type operation (e.g., by the RX transaction engine) or a TX type operation (e.g., by the TX transaction engine). The fault protocol lookup component 306 can determine the transaction fault handling protocol to be implemented based on the interrupt issued by the device 210. It should be noted that such an example is for illustrative purposes only. The fault protocol lookup component 306 can determine the transaction fault handling protocol based on the embodiments described herein and / or other criteria associated with the transaction as additional considerations of the embodiments described herein.

[0093] review Figure 5 , at block 516, processing logic causes the selected transaction fault handling protocol to be executed to resolve the detected page fault. In some embodiments, the fault transaction handling component 308 may initiate one or more operations associated with the selected transaction fault handling protocol to resolve the page fault and the corresponding fault transaction 214A. As described above, components of one or more other entities of the system architecture 100 may be involved in the transaction fault handling protocol. In some embodiments, the fault transaction recovery component 310 may send notifications and / or instructions associated with the protocol to those entities. For example, as described above, the recovery field 434 of the entry 410 indicating the selected transaction fault handling protocol may indicate that one or more components of the computing system 102 (e.g., the virtualization manager 108) will perform one or more operations associated with the selected transaction fault handling protocol. The fault transaction recovery component 310 may send a notification to the fault transaction recovery component 320 of the transaction processing engine 242 to cause the fault transaction recovery component 320 to initiate the execution of the one or more operations. In another example, the recovery field 434 may indicate that the transaction requester will be notified of the initiation of one or more operations of the selected transaction fault handling protocol. In some embodiments, the failed transaction recovery component 310 may send a notification to the transaction requester.

[0094] As described above, the action (e.g., rescheduling action) of the selected transaction fault handling protocol may involve requesting the virtualization manager 108 to make one or more client memory pages referenced by the faulting transaction 214A (or another transaction 214B-N) available in a region of the client memory space 230 corresponding to the DMA memory address of the faulting DMA operation 216A. In response to the transaction fault handling component 308 selecting such a protocol, the page request component 302 may send a request to the virtualization manager 108 to make the client memory page available. The page request component 318 of the page processing engine 240 may receive the request from the page request component 302. In some embodiments, in response to receiving the request, the page request component 318 may identify a storage location associated with the client memory page, and may copy the data of the client memory page from the identified storage location to the client memory space 230. In some embodiments, the page request component 318 may identify the storage location using an MMU and / or in some embodiments at a data structure managed or otherwise accessible by the manager 108. In response to detecting that the data of the client memory page has been copied to the client memory space 230, the page synchronization component 316 can generate a mapping between the DMA memory address of the failed DMA operation 216A and the physical memory address of the memory 106 region storing the client memory page data. According to the previously described embodiments, the page synchronization component 316 can update the IOMMU 112 to include the mapping. In response to updating the IOMMU 112 to include the mapping, the page synchronization component 316 and / or the page request component 318 can send a notification to the page processing engine 222 indicating that the client memory page is available at the client memory space 230. In some embodiments, the page processing engine 222 and / or one or more components of the transaction processing engine 224 can reschedule the execution of the DMA operation 216A of the failed transaction 214A (or another transaction 214B-214N) at the device 210 in response to receiving the notification.

[0095] In some cases, the virtualization manager 108 (or another component of the computing system 102) may cause the client memory page to be evicted from the memory 106 according to a memory page eviction policy, etc. (e.g., if the client memory page is not pinned to the client memory space 230, as described below). In response to detecting that the client memory page is evicted from the memory 106, the page synchronization component 316 may update the IOMMU 112 to remove the mapping between the DMA memory address and the physical memory address of the region of 106 storing the evicted client memory page and / or may notify the page fault detection component 304. The page request component 318 may re-copy the data of the client memory page from the storage location to the client memory page in response to another request to access such data (e.g., in response to another faulty DMA operation 216A at the device 210).

[0096] The actions of the selected transaction failure handling protocol (e.g., rescheduling actions) may additionally or alternatively involve requesting the virtualization manager 108 to pin one or more client memory pages at the client address space 230. As described above, pinning the client memory pages at the client address space 230 may involve the virtualization manager 108 (or another component of the computing system 102) updating metadata associated with the client memory pages to indicate that the data of the client memory pages will not be removed from the client address space 230 of the memory 106. The client memory pages pinned at the client address space 230 may not be evicted from the memory 106, even if such client memory pages would otherwise be eligible for eviction according to the memory page eviction policy implemented by the computing system 102. In some embodiments, the updated metadata may be stored in a data structure managed or otherwise accessible by the IOMMU, MMU, and / or virtualization manager 108. Unpinning the client memory pages may involve the virtualization manager 108 (or another component of the computing system 102) updating metadata associated with the client memory pages to indicate that the data of the client memory pages may be removed from the client address space 230. Therefore, such unpinned guest memory pages may be evicted from memory 106 according to the memory page eviction policy.

[0097] In some embodiments, in response to the transaction fault handling component 308 selecting a transaction fault handling protocol involving pinning of a client memory page, the page request component 302 may transmit a request to the virtualization manager 108 to pin the client memory page to the client address space 230. In some embodiments, the page request component 302 may send the request while sending a request to make the client memory page (or other client memory pages) available in the client memory space 230. In other or similar embodiments, the page request component 302 may send the request before or after sending the request to make the client memory page (or other client memory pages) available in the client memory space 230. In other or similar embodiments, the page request component 302 may send the request to pin the client memory page without sending the request to make the client memory page available. The page request component 318 of the page processing engine 240 may receive the request from the page request component 302. In response to receiving the request, the page request component 318 may update metadata associated with the client memory page(s) to indicate that the client memory page(s) will not be evicted from the memory 106, as described above. The page request component 318 may send a notification to the page processing engine 222 indicating that the client memory page has been pinned at the client memory space 230. The page processing engine 222 and / or one or more components of the transaction processing engine 224 may reschedule execution of the DMA operation 216A of the faulting transaction 214A (or another transaction 214B-N) at the device 210 in response to receiving the notification, as described above.

[0098] In some embodiments, a client memory page pinned at the client memory space 230 may remain pinned until the page processing engine 240 receives a request to unpin the client memory page. In other or similar embodiments, the request transmitted by the page request component 302 to the page request component 318 may indicate one or more conditions associated with pinning the client memory page. For example, the request may indicate that the client memory page will be pinned at the client memory space 230 until a threshold amount of time has passed (e.g., after the memory page was initially pinned). In such an example, the page request component 318 (or another component of the page processing engine 240) may unpin the client memory page in response to detecting that the threshold amount of time has passed. In another example, the request may indicate that the client memory page will be pinned at the client memory space 230 until one or more indications are received from the device 210, a threshold number of client memory pages are pinned at the client memory space 230, and the like.

[0099] In some embodiments, the request to make a client memory page available and / or pin a client memory page at the client memory space 230 may indicate a priority associated with the client memory page. The priority may indicate to the virtualization manager 108 whether operations associated with the client memory page should be performed in preference to other operations at the computing system 102. Fig. 6A , Figure 6B and Figure 7 Flowcharts of example methods 600, 650, 700 related to priority-based paging requests according to embodiments of the present disclosure are shown. Methods 600, 650, and / or 700 may be performed by processing logic, which may include hardware (circuitry, dedicated logic, etc.), software (e.g., instructions running on a processing device), or a combination thereof. In one implementation, some or all of the operations of methods 600 and / or 650 may be performed by device 210. For example, some or all of the operations of methods 600 and / or 650 may be performed by one or more components of page processing engine 222 and / or transaction processing engine 224 (e.g., resident at device 210), as described herein. In additional or alternative implementations, some or all of the operations of method 700 may be performed by computing system 102. For example, all or some of the operations of method 700 may be performed by one or more components of page processing engine 240 and / or transaction processing engine 242 (e.g., virtualization manager 108).

[0100] Reference now Fig. 6A At block 610, processing logic detects a first page fault associated with a first DMA operation for accessing a first memory page associated with a first client hosted by the computing system. The first page fault may be detected by the page fault detection component 304, as described above. According to the previously described embodiments, the fault protocol lookup component 306 may select a transaction fault handling protocol to handle the first page fault (and corresponding fault transaction 214A). In some embodiments, according to the previously described embodiments, the action of the selected transaction fault handling protocol may involve transmitting a request to make the first client memory page available at the client memory space 230.

[0101] At block 612, processing logic assigns a first priority rating to the first memory page. The first priority rating may indicate to the virtualization manager 108 whether to prioritize operations associated with the first memory page over other operations associated with other memory pages (e.g., operations associated with other clients 120 hosted by the computing system 102 (or another computing system or another system architecture of the system architecture 100)). In some embodiments, processing logic may assign a priority rating based on characteristics associated with the device, characteristics associated with the client, attributes of the fault transaction 214A, and / or attributes of other transactions 214B-214N. As described above, the device 210 may be a device with emulation functionality that is configured to expose multiple emulated devices to the computing system 102, each emulated device having a different interface type. The processing logic may assign a priority rating taking into account the interface type of the emulated device corresponding to the DMA operation 216A of the fault transaction 214A or another transaction 214B-N.

[0102] At block 614, processing logic transmits a first request to resolve the first page fault. The first request may correspond to a request sent by page request component 302 to make the first memory page available at client memory space 230 and / or to pin the first memory page to client memory space 230. The first request may indicate a first priority level associated with the first memory page. Figure 7 In the described embodiments, the first request may cause the virtualization manager 108 to resolve the first page fault according to the first priority rating. In one illustrative example, the first request may cause the virtualization manager 108 to perform operations associated with resolving the first page fault before performing operations associated with other processes at the computing system 102. In another illustrative example, in some embodiments, the virtualization manager 108 may select a memory page (e.g., an IO accessible page or other memory page) to be swapped out from the memory 106 taking into account the first priority associated with the first memory page (e.g., according to a memory eviction protocol). For example, the virtualization manager 108 may select the first memory page for eviction in response to determining that the first priority is lower than other priorities of other memory pages at the memory 106. In another instance, the virtualization manager 108 may select one or more other memory pages for eviction in response to determining that the first priority is higher than other priorities of other memory pages at the memory 106.

[0103] As described above, in some embodiments, the connection 250 may correspond to a PCIe interface (or may be exposed to the client 120 as a PCIe / CXL interface). The page request component 302 may send a first request to resolve the first page fault to the virtualization manager 108 by sending a signal indicating information associated with the first request. In some embodiments, one or more portions of the signal may indicate a first priority associated with the first memory page, as described above.

[0104] As mentioned above, Figure 6B A flow chart of another example method 650 related to priority-based paging requests according to an embodiment of the present disclosure is shown. At block 652, processing logic detects a first page fault associated with a first DMA operation for accessing a first memory page associated with a first client hosted by a computing system. At block 654, processing logic detects a second page fault associated with a second DMA operation for accessing a second memory page associated with a second client hosted by the computing system. The processing logic may detect the first page fault and the second page fault according to the previously described embodiments. For example, the page fault detection component 304 may detect the first page fault in response to the initiation of the first transaction 214A associated with the first client 120A, and detect the second page fault in response to the initiation of the second transaction 214B associated with the second client 120B.

[0105] At block 656, processing logic identifies first information associated with the first page fault and second information associated with the second page fault. The first information associated with the first page fault may include, but is not limited to, characteristics associated with device 210, characteristics associated with client 120A, attributes of transaction 214A, and / or attributes of one or more additional transactions (e.g., transaction 214B, transactions 214C-214N, etc.) initiated at device 210. The second information associated with the second page fault may include, but is not limited to, characteristics associated with device 210, characteristics associated with client 120B, attributes of transaction 214B, and / or attributes of one or more additional transactions (e.g., transaction 214A, transactions 214C-214N, etc.) initiated at device 210. Processing logic may identify the first information and the second information according to previously described embodiments.

[0106] At block 658, the processing logic assigns a priority rating to the first memory page and a second priority rating to the second memory page, taking into account the first information associated with the first page fault and the second information associated with the second page fault. At block 660, the processing logic transmits a first request to resolve the first page fault, wherein the first request indicates the first priority rating associated with the first memory page. At block 662, the processing logic transmits a second request to resolve the second page fault, wherein the second request indicates the second priority rating associated with the second memory page. In one embodiment, the first priority rating assigned to the first memory page may be higher than the second priority rating assigned to the second memory page. In such an embodiment, the first request and the second request may cause the virtualization manager 108 to perform operations associated with resolving the first page fault before performing operations associated with resolving the second page fault. In another embodiment, the first priority rating assigned to the first memory page may be lower than the second priority rating assigned to the second memory page. In such an embodiment, the first request and the second request may cause the virtualization manager 108 to perform operations associated with resolving the second page fault before performing operations associated with resolving the first page fault. In some embodiments, the page request component 302 can send the first request and the second request to the virtualization manager 108 by sending one or more signals indicating information associated with the first request and / or the second request, as described above. One or more portions of each signal can indicate a first priority associated with the first memory page and / or a second priority associated with the second memory page, as described above.

[0107] As mentioned above, Figure 7 A flow chart of another example method 700 related to priority-based paging requests is shown. At block 710, processing logic receives a request to perform one or more first operations to resolve a page fault associated with a DMA operation initiated to access a memory page associated with a first client hosted on a computing system. As described above, the request can be a request sent by a page request component 302 to make a memory page available at a client memory space 230 and / or to pin a memory page to the client memory space 230. The request can indicate a priority rating associated with the memory page. As described above, the request can be received by one or more components of a virtualization manager 108.

[0108] At block 712, processing logic identifies one or more second operations to be performed at the computing system. In some embodiments, the one or more second operations may correspond to resolving another page fault associated with another DMA that was initiated (e.g., by device 210 or another device of system architecture 100 or another system architecture) to access another memory page associated with the first client or one or another client hosted on the computing system. In other or similar embodiments, the one or more second operations may be associated with other processes associated with other components running on computing system 102. In an illustrative example, the one or more second operations may be operations scheduled to be performed by one or more components running on computing system 102 via processing device 104.

[0109] At block 714, processing logic performs one or more first operations and one or more second operations according to the first priority rating associated with the memory page. In some embodiments, processing logic (e.g., virtualization manager 108 or another component at computing system 102) may determine the first priority rating associated with the memory page based on the received request. For example, virtualization manager 108 may parse a signal of the received request and may extract the priority rating of the memory page from the signal. In some embodiments, virtualization manager 108 may associate the extracted priority rating of the memory page with the one or more first operations.

[0110] The virtualization manager 108 may schedule the execution of one or more first operations and one or more second operations taking into account the priority rating of the memory page. In some embodiments, the one or more second operations may not be associated with a priority rating, or may be associated with a priority rating lower than the priority rating of the memory page. In such an embodiment, the virtualization manager 108 may schedule the one or more first operations to be executed before executing the one or more second operations (e.g., even if the virtualization manager 108 receives a request to execute the second operation before receiving the request to execute the first operation). In additional or alternative embodiments, at least one of the one or more second operations may be associated with a priority rating higher than the priority rating of the memory page. In such an embodiment, the virtualization manager 108 may schedule the one or more first operations to be executed after at least one of the one or more second operations but before other operations associated with lower priority ratings. In some embodiments, the one or more first operations and the one or more second operations may be executed according to a schedule (e.g., by the processing device 104 and / or the client processor 124).

[0111] It should be noted that the virtualization manager 108 may associate one or more operations with a particular priority rating without receiving an indication of the priority rating in the request. In an illustrative example, the virtualization manager 108 may receive a request from the page request component 302 to make a memory page available at the client memory space 230 and / or to pin a memory page to the client memory space 230. In some embodiments, the request may not include an indication of the priority rating associated with the memory page. The virtualization manager 108 may determine whether to assign a priority rating to the memory page and / or one or more operations associated with the request based on at least one of a characteristic associated with the device 210, a characteristic associated with the client 120, an attribute of a transaction initiated at the device 210 by the request, an attribute of one or more previous transactions initiated at the device 210, and / or an attribute of one or more operations scheduled to be executed by the processing device 104 and / or the client processor 124. The virtualization manager 108 may assign a priority rating to the memory page and / or one or more operations associated with the request based on the determination, and may schedule the one or more operations for execution according to the assigned priority rating, as described above.

[0112] It should be noted that the device 210 may send a request to the virtualization manager 108 (or other component of the computing system 102) without initially detecting a page fault. For example, the asynchronous request engine 226 may send a request to the virtualization manager 108 to make data of a client memory page available at the client memory space 230 and / or to asynchronously pin a client memory page at the client memory space 230 (e.g., without the page processing engine 222 detecting a page fault). As described above, the device 210 (or another entity) may add a transaction 214 to the transaction queue 212 (e.g., in response to receiving a request to initiate a transaction 214 at the device 210). In some embodiments, the transaction 214 may be added to the transaction queue 212 before the transaction 214 is to be initiated. For example, one or more portions of the transaction queue 212 may correspond to an RX buffer of a network device (e.g., a NIC). The transaction 214 associated with one or more network packets may be added to the transaction queue 212 before the network device receives the network packets. The client memory page identifier component 312 may evaluate data and / or metadata associated with a transaction 214 at the transaction queue 212 and may determine whether one or more client memory pages are to be accessed during execution of an operation 216 of the transaction 214 .

[0113] In response to determining that a client memory page is to be accessed during an operation 216 (e.g., DMA operation 216A, etc.) of performing a transaction, the client memory page identifier component 312 may determine whether the client memory page is available at the client memory space 230. In some embodiments, the client memory page identifier component 312 may determine whether the client memory page is available at the client memory space 230 by sending a query to the virtualization manager 108 (e.g., via connection 250). The virtualization manager 108 may determine whether the client memory page is available at the client memory space 230 using the IOMMU 112 and may respond to the query by sending a notification to the client memory page identifier component 312 indicating whether the client memory page is available at the client memory space 230. In additional or alternative embodiments, the client memory page identifier component 312 (or another component of the device 210) may manage or otherwise access a data structure (e.g., a list) that includes entries that each correspond to one or more client memory pages available at the client memory space 230 at any given time. In other or similar embodiments, the data structure may include an entry corresponding to each client memory page associated with one or more clients 120, wherein each entry indicates whether data of the client memory page is stored in a region of memory 106 or another storage location. In some embodiments, the client memory page identifier component 312 may evaluate one or more entries of the data structure to determine whether the client memory page is available at the client memory space 230. In additional or alternative embodiments, the client memory page identifier component 312 may determine whether the client memory page is available at the client memory space 230 according to other techniques.

[0114] In response to the client memory page identifier component 312 determining that the client memory page is not available at the client memory space 230, the asynchronous request component 314 can determine whether to send an asynchronous request to make the client memory page available at the client memory space 230 and / or to pin the client memory page at the client memory space 230. In some embodiments, the asynchronous request component 314 can determine whether to send the asynchronous request based on at least one of a characteristic of the device 210, a characteristic of the client 120, an attribute of the transaction 214 including the operation 216 to access the client memory page, and / or an attribute of other transactions 214 at the transaction queue 212. In other or similar embodiments, the asynchronous request component 314 can determine whether to send the asynchronous request based on other techniques. In one illustrative example, the asynchronous request component 314 can determine to send the asynchronous request in response to determining that the device 210 is a network device, and that a page fault caused by attempting to access a client memory page at the client memory space 230 can significantly affect the latency and throughput of the system architecture 100. In another illustrative example, asynchronous request component 314 may determine to send an asynchronous request in response to determining that a client memory page is to be accessed during execution of operations 216 associated with plurality of transactions 214 .

[0115] The asynchronous request component 314 may send an asynchronous request to the virtualization manager 108 (or another component of the computing system 102), as described above. In some embodiments, the asynchronous request component 314 may send the asynchronous request in response to the client memory page identifier component 312 determining that the client memory page is not available at the client memory space 230. In other or similar embodiments, the asynchronous request component 314 may send the asynchronous request in response to receiving a request to register a DMA buffer at the device 210. In some embodiments, the asynchronous request may include an indication of a priority associated with the client memory page, as described above. The virtualization manager 108 (or other component of the computing system 102) may perform operations associated with the request according to the above embodiments. In some embodiments, if the asynchronous request includes an indication of a priority associated with the client memory page, the virtualization manager 108 may schedule the operation associated with the request for execution according to the indicated priority rating.

[0116] As described above, in some embodiments, the asynchronous request may be a request to pin a client memory page at the client memory space 230. In some embodiments, the asynchronous request component 314 may send additional asynchronous requests to unpin the client memory page from the client memory space 230. For example, the client memory page identifier component 312 and / or the asynchronous request component 314 may determine that the client memory page will be pinned in the client memory space 230 for a specific amount of time and / or until a specific number of transactions 214 have been completed. In response to determining that the specific amount of time has passed and / or the specific number of transactions 214 have been completed, the asynchronous request component 314 may send additional asynchronous requests to unpin the client memory page from the client memory space 230. The virtualization manager 108 (or another component of the computing system 102) may update metadata associated with the client memory page (e.g., at the IOMMU 112) to indicate that the client memory page may be removed from the client memory space 230 (e.g., according to a memory page eviction protocol). In another example, the asynchronous request component 314 may send additional asynchronous requests in response to receiving a request to unregister a DMA buffer at the device 210.

[0117] In other or similar embodiments, the asynchronous request component 314 can send information associated with unpinning a client memory page from the client memory space 230 and a request to pin the client memory page. For example, the asynchronous request component 314 can include instructions or information indicating that after a threshold amount of time has passed (e.g., from receiving the request, from pinning the memory page, etc.), the client memory page is to be unpinned from the client memory space 230 and a request to pin the client memory page to the client memory space 230. After detecting that the threshold amount of time has passed (e.g., from receiving the request, from pinning the memory page, etc.), the virtualization manager 108 can update metadata associated with the client memory page to indicate that the client memory page can be removed from the client memory space 230 (e.g., without receiving an additional asynchronous request from the device 210).

[0118] In some embodiments, the virtualization manager 108 may limit the number of asynchronous requests that the device 210 may send. For example, to reduce the number of devices 210 (and / or clients 120) that pin client memory pages to the client address space 230, the virtualization manager 108 may limit the number of asynchronous pin requests that the device 210 may send. In some embodiments, once the device 210 sends the number of asynchronous pin requests that satisfies the limit, the virtualization manager 108 may ignore (e.g., discard) subsequent asynchronous pin requests from the device 210. In other or similar embodiments, the device 210 may send a notification to the device 210 indicating that the limit of asynchronous pin requests assigned to the device 210 has been reached. In some embodiments, in response to receiving the notification, the asynchronous request component 314 may send one or more requests to unpin the client memory page and pin a replacement or additional client memory page at the client memory space 230. In other or similar embodiments, the asynchronous request component 314 may delay the transmission of the asynchronous pin request in response to receiving the notification (e.g., until a threshold amount of time associated with a previous asynchronous pin request has passed, etc.). In other or similar embodiments, the virtualization manager 108 can transmit a notification of a limit assigned to asynchronous pinned requests of the device 210 (e.g., during initialization of the device 210). In response to detecting that the limit has been reached, the asynchronous request component 314 can delay transmission of the asynchronous pinned request, as described above.

[0119] In an illustrative example, a transaction 214 may include one or more DMA operations 216A for accessing metadata associated with other operations of a transaction 214 and / or an operation 216 of another transaction 214. For example, an operation 216 of a transaction 214 may involve accessing metadata associated with a network packet received from a transaction requester and / or to be transmitted to a transaction requester. The metadata accessed may correspond to a work request or a completion request associated with the network packet. As described above, the asynchronous request component 214 and / or the page request component 302 may transmit a request to pin a memory page associated with a work request or a completion request at a client memory space 230. In some embodiments, the asynchronous request component 214 and / or the page request component 302 may maintain one or more data structures including an indication of one or more client memory pages corresponding to such metadata. In some embodiments, the asynchronous request component 214 and / or the page request component 302 may access a data structure to determine which client memory pages correspond to such metadata, and may issue a single pinning request to pin such client memory pages at a client memory space 230.

[0120] like Figure 3As shown, the memory 228 may include at least one transaction execution buffer 354 and / or one or more backup buffers 356. The transaction execution buffer 254 may be configured to store data associated with one or more operations 216 (e.g., DMA operation 216A, non-DMA operation 216B, etc.) performed for a transaction 214 initiated at the device 210. In the illustrative example, one or more components of the device 210 (e.g., components of the page processing engine 222, components of the transaction processing engine 224, etc.) may copy data to a region of the transaction execution buffer 354 (e.g., in response to detecting that a transaction 214 is initiated at the device 210). In some embodiments, the processor 220 (processor 220 of the computing system 102) or one or more of the processing devices 104 may access the data copied to the transaction execution buffer 354 before or during the execution of the operation 216. In some embodiments, the transaction execution buffer 354 may be managed by a transaction requester, a transaction target, the device 210, and / or one or more components of the computing system 102 (e.g., virtualization manager 108, etc.).

[0121] As described above, the page fault detection component 304 can detect a page fault during the execution of the operation 216 (e.g., during the execution of the DMA operation 216A, etc.), and the fault protocol lookup component 306 can select a transaction fault handling protocol to handle the page fault and the corresponding fault transaction 214A. As described above, one or more transaction fault handling protocols can involve the use of one or more backup memory buffers 356. For example, as described above, the reassociation action can involve determining one or more other client memory pages associated with other DMA memory addresses and writing the data of the operation 216A that caused the page fault to the other client memory pages through one or more DMA memory operations 216A. The DMA memory addresses of the other client memory pages can be associated with the backup memory buffers. In another example, data associated with the transaction 214 being rescheduled (e.g., according to the rescheduling action of the selected transaction fault handling protocol) can be temporarily stored in the one or more backup memory buffers 356. In some embodiments, the data can be stored in the backup memory buffers 356 until the device 210 detects that the data of the client memory page is available and / or fixed at the client memory space 230. It should be noted that in some embodiments, the backup memory buffer 356 may be used or otherwise accessed when implementing other transaction failure handling protocols.

[0122] In some embodiments, each backup memory buffer 356 (also referred to herein simply as a backup buffer 356) may be managed by a transaction requester, a transaction target, a device 210, and / or one or more components of the computing system 102 (e.g., a virtualization manager 108, etc.). In some embodiments, the backup buffer 356 may be a global backup buffer that is allocated to store data (or metadata) associated with each client 120 hosted by the computing system 102. In other or similar embodiments, one or more backup buffers 356 may be allocated to store data and / or metadata associated with a specific client 120 hosted by the computing system 102. For example, a first backup buffer 356A may be allocated to store data and / or metadata associated with the client 120A, while a second backup buffer 356B may be allocated to store data and / or metadata associated with the client 120B. In some embodiments, such a configuration of the backup buffers 356 may provide data isolation between the clients 120. For example, when one or more backup buffers 356 are allocated to particular clients 120, those clients 120 may not consume all buffer space available on the memory 230 (e.g., buffer space allocated to other clients 120). In yet other or similar embodiments, each backup buffer 356 may be allocated to store data and / or metadata associated with a transaction 214 at a particular transaction queue 212. For example, the device 210 may maintain multiple transaction queues 212, as described above. A first backup buffer 356A may be allocated to store data and / or metadata associated with a first transaction queue 212, and a second backup buffer 254B may be allocated to store data and / or metadata associated with a second transaction queue 212. In some embodiments, such a configuration of the backup buffers 356 may provide data isolation between the transaction queues 212.

[0123] It should be noted that although Figure 3 230, but one or more backup buffers 356 may reside elsewhere in the system architecture 100. For example, one or more backup buffers 356 may reside in a portion of the memory 106 allocated to the virtualization manager 108. In another example, one or more backup buffers 356 may reside in the client memory space 230. In yet another example, one or more backup buffers 356 may reside in a peer client memory space.

[0124] In some embodiments, the backup memory buffer 356 may include one or more circular buffers (also referred to as circular buffers, circular queues, circular buffers, etc.). According to embodiments of the present disclosure, the backup memory buffer 356 may include any other type of buffer. In some embodiments, the backup buffer 356 may include a continuous virtual and / or physical memory space. In additional or alternative embodiments, the backup buffer 356 may include other types of memory space. In some embodiments, a buffer context (e.g., maintained or otherwise accessible by the device 210) may define the type of buffer to be used to store data and may indicate one or more buffer descriptors for the buffer. In other or similar embodiments, the buffer context may include an indication of a data structure (e.g., a work queue, a linked list, a flat database, etc.) indicating one or more buffer descriptors for the buffer.

[0125] The backup buffer 356 may include one or more entries configured to store data, as described herein. Each entry may correspond to one or more buffer descriptors. The buffer context may further define how each entry is consumed to store data. For example, the buffer context may indicate that each entry will be consumed by data of a single transaction 214 (e.g., corresponding to one packet), will be consumed by data of multiple transactions 214 (e.g., multiple packets), and so on. For example, the data of each packet received by the device 210 may consume a single buffer entry. In another example, the data of each packet may consume multiple buffer entries. In yet another example, the data of multiple packets may consume a single buffer entry. In yet another example, the data of the packet may partially consume the buffer entry. Since the buffer entry is partially consumed, the consecutive packets may consume the same buffer starting from the last byte of the previous packet, or starting from the byte rounded up to the offset (e.g., stride) indicated by the buffer context.

[0126] As described above, the backup buffer 356 may include one or more circular buffers. In such embodiments, the data stored in the backup buffer 356 may be accessed in the order in which the data was added to the backup buffer 356. In some embodiments, the metadata associated with the data stored in the backup buffer 356 may include an indication of the order in which the data was added to the backup buffer 356. The head register and / or tail register of each buffer entry may indicate which data in the backup buffer 356 is valid. In additional or alternative embodiments, the backup buffer 356 may include one or more linked lists, as described above. In such embodiments, one or more components of the device 210 (e.g., components of the page processing engine 222, components of the transaction processing engine 224, etc.) may add data to the backup buffer 356 as a linked list. Therefore, in some embodiments, the metadata of the data at the backup buffer 356 may not include an indication of the order associated with the data. In some embodiments, the head register and / or tail register of each buffer entry may indicate which data at the backup buffer 356 is valid, as described above. In other or similar embodiments, the head register and / or tail register of the last element of the linked list may indicate which data at the backup buffer 356 is valid. In additional or alternative embodiments, the backup buffer 356 may include a flat database, as described above. In such embodiments, the metadata for the data stored at the backup buffer 356 may include a bitmap indicating which data at the backup buffer 356 is valid.

[0127] In some embodiments, one or more components of the device 210 and / or one or more components of the computing system 102 may maintain a data structure (e.g., a database, etc.) indicating the availability of the backup buffer 356. In some embodiments, the components of the device 210 and / or the components of the computing system 102 may access the data structure to determine the availability of the backup buffer 356. In an illustrative example, the data structure may reside in the memory 106 of the computing system 102. The data structure may include an indication of a pointer to the location of the available backup buffer 356. The pointer may be added to the data structure by one or more components of the computing system 102 (e.g., the virtualization manager 108) and / or one or more components of the device 210. In another illustrative example, the data structure may reside in the memory 228 of the device 210. In some embodiments, the data structure may be exposed (e.g., exposed to the client 120) as a memory mapped input / output (MMIO) accessible register space on the device 210.

[0128] As described above, the transaction queue 212 may include multiple transactions 214. In some embodiments, each transaction 214 in the transaction queue 212 may be associated with an ordering condition. For example, two or more transactions 214 may be associated with a common transaction target and / or a common transaction requester. In such an example, metadata associated with two or more transactions 214 may indicate an order associated with the execution of the operation of the transaction 214. In some embodiments, the order may be specified by the transaction requester and / or the transaction target or otherwise specific to the transaction requester and / or the transaction target. In other or similar embodiments, the order may be determined according to one or more transaction protocols of the device 210. For example, the transaction protocol of the device 210 may specify that the transaction 214 will be initiated in the order in which the request to initiate the transaction 214 is received. In another example, the transaction protocol of the device 210 may specify that the transaction 214 requested by a specific transaction requester will be initiated before the transaction requested by other transaction requesters. In other or similar embodiments, one or more transactions 214 in the transaction queue 212 may not be associated with an ordering condition. In such an embodiment, transactions 214 may be initiated according to any ordering or according to a default ordering of device 210 .

[0129] According to the above-described embodiments, one or more transactions 214 in the transaction queue 212 may be a failed transaction 214A. Data associated with the failed transaction 214A and / or the non-faulty transactions 214B-N may be stored in one or more transaction execution buffers 354 and / or backup buffers 356, depending on the ordering condition (or lack of ordering condition) of the transactions 214 in the transaction queue 212. FIG. 8A to FIG. 8B 2 shows an example of completion processing of one or more fault transactions 214A at device 210 according to an embodiment of the present disclosure. Fig. 8A As shown, the transaction queue 212 may include one or more transactions 214, as described above. In some embodiments, the transactions 214 in the transaction queue 212 may not be associated with an ordering condition. The page request component 302 may perform the operation 216 of the transaction 214, as described above. In an illustrative example, the page fault detection component 304 may detect a page fault associated with the execution of the DMA operation 216A of the transaction 214A, as described herein. According to the embodiments described herein, in response to the page fault detection component 304 detecting the page fault, the fault protocol lookup component 306 may select a transaction fault handling protocol. According to the previously described embodiments, the page fault detection component 304 (or the page processing engine 222 and / or another component of the transaction processing engine 224) may store data associated with the DMA operation 216A of the transaction 214A in the backup buffer 356A (and / or the backup buffer 356B). As Fig. 8AAs shown, data associated with DMA operation 216A of transaction 214A may be stored at an entry of backup buffer 365A (eg, depicted as transaction data 810A).

[0130] Because transactions 214 at the transaction queue 212 are not associated with an ordering condition, the page request component 302 may execute operations 216 of transactions 214B and 214C before processing the page fault of transaction 214A (e.g., in accordance with a selected transaction fault handling protocol). In some embodiments, the page fault detection component 302 may not detect a page fault during execution of operations 216 of transactions 214B and 214C. As a result, transactions 214B and 214C are successfully completed at the device 210 (e.g., data of client memory pages referenced by operations 216 of transactions 214B and 214C are accessed at the client memory space 230). According to previously described embodiments, the page request component 302 (or another component of the page processing engine 222 and / or the transaction processing engine 224) may store data associated with operations 216 of transactions 214B and 214C in the transaction execution buffer 354. As shown in FIG. Fig. 8A As shown, data associated with operations 216 of transactions 214B and 214C may be stored in one or more entries of transaction execution buffer 354 (eg, depicted as transaction data 810B and transaction data 810C, respectively).

[0131] In some embodiments, the fault transaction handling component 308 (or another component of the page processing engine 222 and / or the transaction processing engine 224) may detect that the client memory page that caused the page fault of the DMA operation 216A of the faulting transaction 214A is available and / or pinned in the client memory space 230. In response to detecting that the client memory page is available and / or pinned in the client memory space 230, the page request component 302 (or another component of the page processing engine 222 and / or the transaction processing engine 224) may execute the DMA operation 216A of the faulting transaction 214A to handle the transaction fault (e.g., according to a selected transaction fault handling protocol). The page request component 302 may store data associated with the operation 216 of the transaction 214A in the transaction execution buffer 354. Figure 8B As shown, data associated with operation 216 of transaction 214A (including fault DMA operation 216A) may be stored in one or more entries of transaction execution buffer 354. It should be noted that the order in which transaction data 810A, 810B, and 810C are added to the entries of transaction execution buffer 354 is for illustration purposes only. In other or similar embodiments, transaction data 810A, 810B, and / or 810C may be added to the entries of transaction execution buffer 354 in other orders.

[0132] FIG. 9A to FIG. 9BFIG. 2 shows another example of completing processing of one or more failed transactions 214A at device 210 according to an embodiment of the present disclosure. Fig. 8A As shown, the transaction queue 212 may include one or more transactions 214, as described above. In some embodiments, the transactions 214 at the transaction queue 212 may be associated with an ordering condition. For example, the device 210 may be associated with a transaction protocol that provides that the transactions 214 will be initiated according to the order in which the requests for the transactions 214 are received. In another example, the transactions 214 may be associated with an ordering condition that takes into account the common transaction requester and / or transaction target associated with the transactions 214, as described above.

[0133] The page request component 302 can perform the operation 216 of the transaction 214A, as described above. In some embodiments, the page fault detection component 304 may not detect a page fault during the execution of the operation 216, and the transaction 214A can be successfully completed. The page request component 302 (or another component of the page processing engine 222 and / or the transaction processing engine 224) can store data associated with the operation 216 of the transaction 214A at the transaction execution buffer 354, as described above. Fig.9A As shown, data associated with operation 216 of transaction 214A may be stored at one or more entries of transaction execution buffer 354 (eg, depicted as transaction data 910A).

[0134] The page request component 302 can perform the operation 216 of the transaction 214B, as described above. The page fault detection component 304 can detect a page fault during the execution of the operation 216 of the transaction 214B, and the fault protocol lookup component 306 can select a transaction fault handling protocol, which is consistent with the embodiments described above. The page request component 302 (or another component of the page processing engine 222 and / or the transaction processing engine 224) can store data associated with the operation 216 of the transaction 214B in the backup buffer 356 until the page fault of the operation 216 is processed (e.g., according to the selected transaction fault handling protocol). Fig.9A As shown, data associated with operation 216 of transaction 214B may be stored in one or more entries of backup buffer 356 (e.g., depicted as transaction data 910B). Page request component 302 (or another component of page processing engine 222 and / or transaction processing engine 224) may determine based on the ordering conditions of transactions 214 in transaction queue 212 that transaction 214C cannot be initiated until transaction 214B is completed. Therefore, page request component 302 may store data associated with operation 216 of transaction 214C in backup buffer 356. Fig. 9BAs shown, data associated with operation 216 of transaction 214C may be stored in one or more entries of backup buffer 356 (eg, illustrated as transaction data 910C).

[0135] In some embodiments, the fault transaction handling component 308 (or another component of the page processing engine 222 and / or the transaction processing engine 224) can detect that the client memory page that caused the page fault of the fault transaction 214B is available and / or pinned in the client memory space 230. In response to detecting that the client memory page is available and / or pinned in the client memory space 230, the page request component 302 (or another component of the page processing engine 222 and / or the transaction processing engine 224) can perform the operation 216 of the fault transaction 214B to handle the transaction fault (e.g., according to the selected transaction fault handling protocol). The page request component 302 can store data associated with the operation 216 of the transaction 214B in the transaction execution buffer 354. Fig. 9B As shown, data associated with operation 216 of transaction 214B may be stored in one or more entries of transaction execution buffer 354. In response to detecting that transaction 214B has completed, page request component 302 may initiate operation 216 of transaction 214C. Page request component 302 may store data associated with operation 216 of transaction 214C in transaction execution buffer 354 (e.g., as long as page fault detection component 302 has not detected a page fault). In some embodiments, page request component 302 (or another component of device 210 and / or computing system 102) may wait to send metadata associated with transaction 214C (e.g., transaction completion metadata, etc.) to the transaction requester and / or transaction target until transaction 214B (and transaction 214C) is successfully completed. Fig. 9B As shown, data associated with operation 216 of transaction 214B may be stored in one or more entries of transaction execution buffer 354. It should be noted that the order in which transaction data 910A, 910B, and 910C are added to the entries of transaction execution buffer 354 is for illustration purposes only. In other or similar embodiments, transaction data 910A, 910B, and / or 910C may be added to the entries of transaction execution buffer 354 in other orders.

[0136] In some embodiments, the data of the transactions 214 at the transaction execution buffer 354 may not be consistent with the initial ordering at the transaction queue 212 (e.g., responsive to the ordering in which the data is stored in the backup buffer 356). In some embodiments, metadata associated with the transaction data 810, 910 may include an indication of the initial ordering of the transactions 214 at the transaction queue 212. For example, metadata for each entry of the transaction execution buffer 354 may include an indication of the ordering associated with the corresponding transaction 214 at the transaction queue 212. In some embodiments, one or more components running on the device 210 (e.g., a buffer manager component (not shown), components of the page processing engine 222 and / or the transaction processing engine 224, etc.) may rearrange the transaction data 810, 910 at the transaction execution buffer 354 to correspond to the ordering indicated by the metadata.

[0137] In some embodiments, one or more components of the device 210 may send a notification to an entity of the system architecture 100 (e.g., a transaction requester, a transaction target, etc.) indicating the state of data associated with the transaction 214 at the device 210. For example, one or more components of the device 210 may send a notification to the transaction target indicating that data associated with the failed transaction 214A is currently stored in one or more backup buffers 356. Once the data is moved to the transaction execution buffers 354, the one or more components may send another notification to the transaction target indicating that the data is currently stored in the transaction execution buffers 354. In yet another example, one or more components of the device 210 may maintain a data structure including entries corresponding to the transactions 214 of the transaction queue 212. Each entry may include an indication of a storage location (e.g., a transaction execution buffer 354, a backup buffer 356, etc.) where data associated with the transaction 214 in the transaction queue 212 is currently stored. In some embodiments, an entity of the system architecture 100 may access the data structure to determine the state of the data associated with the transaction 212.

[0138] The device 210 may include a completion recovery engine 254 (e.g., Figure 2 In some embodiments, completion recovery engine 254 may be configured to manage a completion queue at device 210 . Fig.10 An example completion recovery engine 254 is shown according to an embodiment of the present disclosure. Fig.10 As shown, in some embodiments, the completion recovery engine 254 may include a fault detection component 1010, a backup completion queue update component 1012, and / or a completion queue update component 1014. Fig.10As further shown, the memory 228 of the device 210 may include a completion queue 1050 and / or a backup completion queue 1052. A completion queue refers to a queue that indicates completion events for transactions (e.g., completed transactions 214 at the transaction queue 212). In some embodiments, the completion queue 1050 may indicate completion events for transactions 214 that have been successfully completed (e.g., operations 216 of the transaction 214 have been executed without a page fault and / or after a page fault has been processed, as described above). The backup completion queue 1052 may indicate completion events for transactions 214 whose completion was suspended or otherwise delayed due to a page fault caused by one or more operations 216. Once the page fault of the failed transaction 214A is processed (e.g., according to the previously described embodiments) and the transaction 214 is successfully completed, the indication of the completion event for the transaction 214 may be removed from the backup completion queue 1052 and added to the completion queue 1050. In some embodiments, one or more components of device 210 and / or computing system 102 may send a notification to a transaction requester and / or a transaction target indicating the completion of transaction 214 indicated by completion queue 1050. In other or similar embodiments, the transaction requester and / or the transaction target may access completion queue 1050 and / or backup completion queue 1052 to determine the status of transaction 214.

[0139] It should be noted that although Fig.10 While the completion queue 1050 and the backup completion queue 1052 are shown as residing in the memory 228, the completion queue 1050 and / or the backup completion queue 1052 may reside in other memory locations of the system architecture 100. For example, the completion queue 1050 and / or the backup completion queue 1052 may reside in the memory 106 of the computing system 102. In another example, the completion queue 1050 and / or the backup completion queue 1052 may reside in the memory 228 of the device 210 and may be accessed by one or more components of the computing system 102.

[0140] In some embodiments, after the data associated with operation 216 of failed transaction 214A is stored in backup buffer 356, an indication of failed transaction 214A may be added to backup completion queue 1052. As described above, data associated with operation 216 of failed transaction 214A may be added to backup completion queue 1052 even if no page fault is detected for operation 216. For example, in response to a detected page fault of transactions 214A and / or 214B, data associated with transaction 214C may be added to an entry in backup buffer 356, as described above with respect to FIG. 9A to FIG. 9B as described.

[0141] Fig.11A flow chart of an example method 1100 for completing synchronization according to at least one embodiment is shown. The method 1100 may be performed by processing logic, which may include hardware (circuitry, dedicated logic, etc.), software (e.g., instructions running on a processing device), or a combination thereof. In one implementation, some or all of the operations of the method 1100 may be performed by the device 210. For example, some or all of the operations of the method 1100 may be performed by one or more components of the completion recovery engine 254 (e.g., resident at the device 210), as described herein.

[0142] At block 1100, processing logic detects a page fault associated with a DMA operation of a transaction. In some embodiments, a DMA operation may be performed to access a client memory page associated with a client of one or more clients hosted by computing system 102. As described above, fault detection component 1010 may detect a page fault in response to page request component 302 initiating execution of DMA operation 216A of transaction 214.

[0143] At block 1112, processing logic may update the backup completion queue to include an indication of a completion event associated with the transaction. In some embodiments, the backup completion queue update component 1012 may update the backup completion queue 1052 to include an indication of a completion event associated with the transaction 214. In some embodiments, the backup completion queue update component 1012 may update the backup completion queue 1052 in response to determining that the backup completion queue criteria are met. In some embodiments, the backup completion queue update component 1012 may determine that the backup completion queue criteria are met by determining that a page fault (e.g., detected according to the operation of block 1110) has not been processed. In additional or alternative embodiments, according to embodiments described herein, the backup completion queue update component 1012 may determine that the backup completion queue criteria are met if a full synchronization between the completion queue 1050 and the backup completion queue 1052 has not been completed. In response to determining that the backup completion queue criteria are not met, the backup completion queue update component 1012 (or another component of the completion recovery engine 250, such as the completion queue update component 1014) may update the completion queue 1050 to include an indication of a completion event.

[0144] The backup completion queue update component 1012 can update the backup completion queue 1052 by adding (e.g., publishing) a completion event to the backup completion queue 1052 and / or by updating a consumer index. In some embodiments, the backup completion queue component 1012 can add a completion event to the backup completion queue 1052 by updating metadata associated with the completion event to indicate the backup completion queue 1052. In other or similar embodiments, the component 1012 can add a completion event to the backup completion queue 1052 by writing the completion event to the backup completion queue 1052. In some embodiments, the backup completion queue update component 1012 can send a signal to one or more of the page processing engine 222 and / or the transaction processing engine 224 to cause the transaction processing engine to select a transaction fault handling protocol, as described above. The transaction processing engine 224 can select a transaction fault handling protocol and can initiate one or more operations of the transaction fault handling protocol to handle page faults, which is consistent with the previously described embodiments. In some embodiments, the backup completion queue update component 1012 can send a signal for each completion event at the backup completion queue 1052 or send a signal for multiple completion events at the backup completion queue 1052.

[0145] At block 1114, processing logic determines that execution of a transaction fault handling protocol for handling a page fault associated with a DMA operation has completed. Completion of execution of the transaction fault handling protocol may indicate that the page fault for the DMA operation has been handled, and therefore the transaction has been successfully completed. Processing logic (e.g., backup completion queue update component 1012 and / or completion queue update component 1014) may determine that execution of the transaction fault handling protocol selected by the transaction processing engine 224 has completed by detecting at least one of an interrupt from the page processing engine 222 and / or the transaction processing engine 224, a poll of a consumer index, or a poll of the backup completion queue 1052 and / or the completion queue 1050.

[0146] At block 1116, processing logic (e.g., completion queue update component 1014) updates a regular completion queue (e.g., completion queue 1050) to include an indication of a completion event associated with the transaction. In some embodiments, completion queue update component 1014 updates the regular completion queue by updating metadata associated with the completion event to indicate (or otherwise correspond to) the regular completion queue, updating a producer index, or sending a command to initiate a synchronization protocol, as described herein. In some embodiments, completion queue update component 1014 can remove the indication of the completion event from backup completion queue 1052.

[0147] It should be noted that Fig.11 The described embodiments are for illustration and explanation only and should not be construed as limiting. Fig.11The described embodiments and examples may be applied to any type of event that requires a completion queue to be selected and / or a synchronization operation to be performed. These may include events that do not involve page faults.

[0148] As described above, data associated with operation 216 of transaction 214 may be added to backup completion queue 1052 even if a page fault for the operation is not detected. In such an embodiment, backup completion queue update component 1012 may update backup completion queue 1052 to include additional indications of additional completion events associated with such transaction 214. Such transaction is delayed due to the page fault associated with DMA operation 216A of failed transaction 214A. Backup completion queue update component 1012 may continue to update backup completion queue 1052 to include additional indications of additional completion events until completion queue update component 1014 (or another component of completion recovery engine 254) determines that execution of transaction fault handling protocol has been completed to handle page faults associated with DMA operations. In response to detecting that execution of transaction fault handling protocol has been completed, completion queue update component 1014 may initiate synchronization protocol to transmit one or more additional indications of additional completion events from backup completion queue 1052 to completion queue 1050. The synchronization protocol may involve completion queue update component 1014 copying indications of additional completion events from backup completion queue 1052 to completion queue 1050 and removing indications from backup completion queue 1052. Processing logic may resume posting completion events to completion queue 1050 once the synchronization protocol is complete.

[0149] In some embodiments, the backup completion queue update component 1012 can stop updating the backup completion queue 1052 until the synchronization protocol is completed. In some embodiments, the backup completion queue update component 1012 can stop updating the backup completion queue 1052 until a threshold number of completions are synchronized with the completion queue 1050. In additional or alternative embodiments, the backup completion queue update component can stop updating the backup completion queue 1052 until a threshold amount of time has passed (e.g., since the synchronization protocol was initiated).

[0150] As described above, in some embodiments, processor 220 may be a programmable extension of one or more components or modules of computing system 102. In such embodiments, processor 220 may serve as an intermediary between a transaction target (e.g., client 120) and one or more components (e.g., hardware components) of device 210. For example, processor 220 may serve as an intermediary between a transaction target and one or more hardware components of device 210, which exposes a simulated device to computing system 102, as described above. In some embodiments, one or more engines (e.g., completion recovery engine 254) running on processor 220 may detect that transaction 214 has been successfully completed on device 210 after a page fault of transaction 214 has been processed, as described above. Completion recovery engine 254 may send a completion notification to the transaction target. Because processor 220 is a programmable extension of computing system 102, processor 220 may serve as an intermediate transaction target in some embodiments. In such an embodiment, the transaction target (e.g., client 120) may not be aware of the page fault that caused the failed transaction 214A, although components running on processor 220 (e.g., intermediate transaction targets) may be aware of the page fault that caused the failed transaction 214A. In an illustrative example, the device 210 may maintain a single queue that is configured to store completion events of successfully completed transactions (e.g., completion events of completion queue 1050) and indications of completion events of failed transactions 214A and / or completion events of transactions delayed due to failed transactions 214A (e.g., completion events of backup completion queue 1052). In certain embodiments, in such an embodiment, the completion recovery engine 254 may copy data from the queue to a target completion queue that resides at the transaction target or is otherwise accessible to the transaction target. The completion recovery engine 254 (or another component or engine at the device 210) may copy data associated with the transaction 214 from the transaction execution buffer 354 and / or the backup buffer 356 to a target buffer that resides at the transaction target or is otherwise accessible to the transaction target.

[0151] As described above, the transaction 214 may include one or more DMA operations 216A for writing data to one or more regions of the client memory space 230. For example, the transaction 214 may include one or more DMA operations 216A for writing data from a network device RX packet, data from a block device IO read, etc. In some embodiments, the device 210 may first write the data to a scratch buffer (not shown) instead of writing the data directly to a client memory page at the client memory space 230. In some embodiments, the scratch buffer may reside at the device 210 (e.g., at the memory 228) or the computing system 102 (e.g., at the memory 106). In such an embodiment, the device 210 may update the completion queue 1050 and / or the backup completion queue 1052 to include an indication of a completion event associated with writing the data of the transaction 214 to the scratch buffer. The completion event may include an indication of the original DMA memory address associated with the data of the transaction 214 and an indication of the location of the scratch buffer storing the data. In some embodiments, the device 210 may copy the data from the scratch buffer to the buffer of the transaction target. If a page fault is detected for a client memory page associated with the original DMA memory address, device 210 may select a fault transaction protocol to initiate to resolve the page fault, as described above. In an illustrative example, the selected fault transaction protocol may involve rescheduling a copy operation to copy data from the scratch buffer to the transaction target buffer at a later time period.

[0152] As described above, in some embodiments, the device 210 may be an RDMA network device. In some embodiments, the device 210 may detect a page fault (as described above) and may send an RNR NAK packet to the transaction requester. In some embodiments, the data of the RNR NAK packet may include an indication of a timer. The device 210 may set the timer to correspond to the expected page fault processing time. The timer may correspond to the amount of time that the transaction requester should wait before resending the RNR NAK packet to the device 210. In one example, the device 210 may set the timer to correspond to the severity of the detected page fault (e.g., based on the amount of time that has elapsed to process a previous page fault, etc.). In another example, the device 210 may set the timer to correspond to a default amount of time associated with processing a page fault. If the device 210 detects that the amount of retransmissions received from the transaction requester within the amount of time set by the timer reaches or exceeds a threshold, the device 210 may increase the amount of time of the timer accordingly.

[0153] In additional or alternative embodiments, the transaction 214 at the transaction queue 212 of the RDMA network device may correspond to a packet of a wired local area network (e.g., Ethernet, etc.). In some embodiments, the transaction target may encapsulate data associated with the network traffic (e.g., in an RDMA request or any other RNR-enabled protocol) and include the data with the packet transmitted to the device 210. In some embodiments, the device 210 may transmit the data associated with the network traffic as an Ethernet packet to the transaction target. If a page fault is detected during the initiation of the transaction 214, the device 210 may send an RNRNAK packet to the transaction requester, which in turn may retransmit the request to initiate the transaction 214, as described above.

[0154] Fig.12 A block diagram of an exemplary computer device 1200 according to an embodiment of the present disclosure is shown. The computer device 1200 may correspond to one or more components of a computing system 102 and / or one or more components of a device 210, as described above. The example computer device 1200 may be connected to other computer devices in a LAN, an intranet, an extranet, and / or the Internet. The computer device 1200 may be run as a server in a client-server network environment. The computer device 1200 may be a personal computer (PC), a set-top box (STB), a server, a network router, a switch or a bridge, or any device capable of executing a set of instructions (sequential or otherwise) that specify the actions to be taken by the device. In addition, although only a single example computer device is shown, the term "computer" shall also include any computer collection that individually or jointly executes a set (or multiple sets) of instructions to perform any one or more methods discussed herein.

[0155] The example computer device 1200 may include a processing device 1202 (also referred to as a processor, CPU, or GPU), a main memory 1204 (e.g., read-only memory (ROM), flash memory, dynamic random access memory (DRAM), such as synchronous DRAM (SDRAM), etc.), a static memory 1206 (e.g., flash memory, static random access memory (SRAM), etc.), and an auxiliary memory (e.g., a data storage device 1018), which may communicate with each other via a bus 1230.

[0156] The processing device 1202 (which may include processing logic 1203) represents one or more general-purpose processing devices, such as a microprocessor, a central processing unit, etc. More specifically, the processing device 1202 may be a complex instruction set computing (CISC) microprocessor, a reduced instruction set computing (RISC) microprocessor, a very long instruction word (VLIW) microprocessor, a processor that implements other instruction sets, or a processor that implements a combination of instruction sets. The processing device 1202 may also be one or more special-purpose processing devices, such as an ASIC, an FPGA, a digital signal processor (DSP), a network processor, etc. According to one or more aspects of the present disclosure, the processing device 1202 may be configured to execute instructions implementing the method 500 for handling page faults at a fault-resilient transaction processing device, the methods 600, 650, and / or 700 for priority-based paging requests, and / or the method 1100 for completing synchronization.

[0157] The example computer device 1200 may also include a network interface device 1208, which may be communicatively coupled to a network 1220. The example computer device 1200 may also include a video display 1210 (e.g., a liquid crystal display (LCD), a touch screen, or a cathode ray tube (CRT)), an alphanumeric input device 1212 (e.g., a keyboard), a cursor control device 1214 (e.g., a mouse), and an acoustic signal generating device 1216 (e.g., a speaker).

[0158] The data storage device 1218 may include a computer-readable storage medium (or more specifically, a non-transitory computer-readable storage medium) 1228 having stored thereon one or more sets of executable instructions 1222. According to one or more aspects of the present disclosure, the executable instructions 1222 may include executable instructions for implementing the method 500 for handling page faults on a fault-resilient transactional device, the methods 600, 650, and / or 700 for priority-based paging requests, and / or the method 1100 for completing synchronization.

[0159] The executable instructions 1222 may also reside completely or at least partially within the main memory 1204 and / or within the processing device 1202 during execution by the example computer device 1200, the main memory 1204 and the processing device 1202 also constituting computer-readable storage media. The executable instructions 1222 may also be transmitted or received over a network via the network interface device 1208.

[0160] Although Fig.12The computer-readable storage medium 1228 is shown as a single medium, but the term "computer-readable storage medium" should be understood to include a single medium or multiple media (e.g., a centralized or distributed database and / or associated caches and servers) that store one or more sets of operating instructions. The term "computer-readable storage medium" should also be understood to include any medium that can store or encode a set of instructions for machine execution, which instructions cause the machine to perform any one or more of the methods described herein. The term "computer-readable storage medium" should therefore be understood to include, but is not limited to, solid-state memory, optical and magnetic media.

[0161] Some portions of the foregoing detailed description are presented in the form of algorithms and symbolic representations of operations on data bits within a computer memory. These algorithmic descriptions and representations are the means used by those skilled in the data processing arts to most effectively convey the substance of their work to others skilled in the art. An algorithm is here, and generally, considered to be a self-consistent sequence of steps leading to a desired result. These steps require physical manipulations of physical quantities. Usually, though not necessarily, these quantities take the form of electrical or magnetic signals capable of being stored, transferred, combined, compared, and otherwise manipulated. It has proven convenient at times, primarily for reasons of common usage, to refer to these signals as bits, values, elements, symbols, characters, terms, numbers, or the like.

[0162] It should be remembered, however, that all of these and similar terms are associated with the appropriate physical quantities and are merely convenient labels applied to these quantities. Unless expressly stated otherwise, as will be apparent from the following discussion, it should be understood that throughout the description, discussions using terms such as "identify," "determine," "store," "adjust," "cause," "return," "compare," "create," "stop," "load," "copy," "throw," "replace," "execute," etc. refer to actions and processes of a computer system or similar electronic computing device that manipulates data represented as physical (electronic) quantities within the computer system's registers and memories and converts data represented as physical (electronic) quantities within the computer system's registers and memories into other data also represented as physical quantities within the computer system's memories or registers or other such information storage, transmission, or display devices.

[0163] Examples of the present disclosure also relate to an apparatus for performing the methods described herein. The apparatus may be specially constructed for the desired purpose, or it may be a general-purpose computer system selectively programmed by a computer program stored in the computer system. Such a computer program may be stored in a computer-readable storage medium, such as, but not limited to, any type of disk, including optical disks, CD-ROMs and magneto-optical disks, read-only memories (ROMs), random access memories (RAMs), EPROMs, EEPROMs, magnetic disk storage media, optical storage media, flash memory devices, other types of machine-accessible storage media, or any type of medium suitable for storing electronic instructions, each of which is coupled to a computer system bus.

[0164] The methods and displays described herein are essentially independent of any particular computer or other device. Various general purpose systems may be used with the programs taught herein, or it may be convenient to construct more specialized devices to perform the required method steps. Various required structures in these systems will appear in the following description. In addition, the scope of the present disclosure is not limited to any particular programming language. It should be understood that various programming languages ​​may be used to implement the teachings of the present disclosure.

[0165] It should be understood that the above description is intended to be illustrative rather than restrictive. After reading and understanding the above description, those skilled in the art will understand many other implementation examples. Although the present disclosure describes specific examples, it should be appreciated that the systems and methods of the present disclosure are not limited to the examples described herein, but can be modified to practice within the scope of the attached claims. Therefore, the description and drawings should be regarded as illustrative rather than restrictive. Therefore, the scope of the present disclosure should be determined with reference to the attached claims and the full scope of equivalents to which such claims are entitled.

[0166] In at least one embodiment, to protect patient confidentiality (e.g., when patient data or records are to be used off-site), the computer device 1200 may include or may otherwise be connected to a cloud. The cloud may include a registry - such as a deep learning container registry. In at least one embodiment, the registry may store containers for instantiating applications that may perform pre-processing, post-processing, or other processing tasks on the patient data. In at least one embodiment, the cloud may receive data including patient data as well as sensor data in containers, perform requested processing only on the sensor data in those containers, and then forward the resulting output and / or visualization to appropriate parties and / or devices (e.g., on-site medical devices for visualization or diagnosis), all without extracting, storing, or otherwise accessing the patient data. In at least one embodiment, the confidentiality of the patient data is protected in accordance with HIPAA and / or other data regulations.

[0167] Other variations are within the spirit and scope of the present disclosure. Thus, while the disclosed technology is susceptible to various modifications and alternative constructions, certain illustrative embodiments thereof are shown in the drawings and have been described in detail above. However, it should be understood that there is no intention to limit the disclosure to the particular forms disclosed, but on the contrary, it is intended to cover all modifications, alternative constructions, and equivalents that fall within the spirit and scope of the disclosure as defined in the appended claims.

[0168] In the context of describing the disclosed embodiments (especially in the context of the following claims), the use of the terms "a", "an", and "the" and similar referents should be interpreted as covering the singular and the plural, unless otherwise specified herein or clearly contradicted by the context, and are not used as definitions of the terms. The terms "include", "have", "include", and "contain" should be interpreted as open-ended terms (meaning "including but not limited to") unless otherwise specified. "Connected" when unmodified and referring to a physical connection should be interpreted as partially or completely contained, attached to, or connected together, even if there is something in between. The recitation of ranges of values ​​herein is intended only as a shorthand method to individually reference each individual value falling within the range, unless otherwise specified herein, and each individual value is incorporated into the specification as if it were individually recited herein. In at least one embodiment, the use of the term "set" (e.g., "a set of items") or "subset" should be interpreted as a non-empty set containing one or more members, unless otherwise specified or contradicted by the context. Furthermore, unless otherwise stated or contradicted by context, the term "subset" of a corresponding set does not necessarily mean a true subset of the corresponding set, but a subset and a corresponding set may be equal.

[0169] Unless expressly stated otherwise or clearly contradicted by context, connective language (e.g., phrases of the form "at least one of A, B, and C" or "at least one of A, B, and C") should be understood together with the context as generally used to indicate that an item, term, etc., may be A or B or C, or any non-empty subset of the set of A, B, and C. For example, in the illustrative example of a set with three members, the connective phrases "at least one of A, B, and C" and "at least one of A, B, and C" refer to any of the following sets: {A}, {B}, {C}, {A, B}, {A, C}, {B, C}, {A, B, C}. Thus, such connective language is generally not intended to imply that certain embodiments require at least one of A, at least one of B, and at least one of C to be present. Furthermore, unless expressly stated otherwise or contradicted by context, the term "plurality" refers to a plural state (e.g., "a plurality of items" refers to a plurality of items). In at least one embodiment, the number of the plurality of items is at least two, but may be more when expressly or by context indicates. Further, the phrase "based on" means "based at least in part on" rather than "based solely on" unless otherwise specified or clear from context.

[0170] Unless otherwise specified herein or clearly contradictory to the context, the operations of the processes described herein may be performed in any suitable order. In at least one embodiment, a process such as the process described herein (or its variant and / or combination) is performed under the control of one or more computer systems configured with executable instructions and is implemented as code (e.g., executable instructions, one or more computer programs, or one or more applications) that is jointly executed by hardware or a combination thereof on one or more processors. In at least one embodiment, the code is stored on a computer-readable storage medium, for example, in the form of a computer program that includes multiple instructions that can be executed by one or more processors. In at least one embodiment, the computer-readable storage medium is a non-transitory computer-readable storage medium that does not include a transient signal (e.g., propagating a transient electrical or electromagnetic transmission), but includes a non-transitory data storage circuit (e.g., a buffer, a cache, and a queue) within a transient signal transceiver. In at least one embodiment, code (e.g., executable code or source code) is stored on a set of one or more non-transitory computer-readable storage media having executable instructions stored thereon (or other memory for storing executable instructions), which, when executed by one or more processors of a computer system (i.e., as a result of execution), causes the computer system to perform the operations described herein. In at least one embodiment, the set of non-transitory computer-readable storage media includes a plurality of non-transitory computer-readable storage media, and one or more individual non-transitory storage media of the plurality of non-transitory computer-readable storage media lack all code, while the plurality of non-transitory computer-readable storage media collectively store all code. In at least one embodiment, the executable instructions are executed so that different instructions are executed by different processors—for example, a non-transitory computer-readable storage medium stores instructions, and a main central processing unit ("CPU") executes some instructions, while a graphics processing unit ("GPU") executes other instructions. In at least one embodiment, different components of the computer system have separate processors, and different processors execute different subsets of instructions.

[0171] Thus, in at least one embodiment, a computer system is configured to implement one or more services that individually or collectively perform the operations of the processes described herein, and such computer system is configured with applicable hardware and / or software that allows the operations to be performed. In addition, the computer system implementing at least one embodiment of the present disclosure is a single device, and in another embodiment is a distributed computer system that includes multiple devices that operate in different ways, so that the distributed computer system performs the operations described herein, and so that a single device does not perform all operations.

[0172] The use of any and all examples or exemplary language (e.g., "such as") provided herein is intended only to better illustrate embodiments of the present disclosure and does not limit the scope of the present disclosure unless otherwise stated. No language in the specification should be construed as indicating that any non-claimed element is essential to the practice of the disclosure.

[0173] All references, including publications, patent applications, and patents, cited herein are hereby incorporated by reference to the same extent as if each reference were individually and specifically indicated to be incorporated by reference and were set forth in its entirety herein.

[0174] In the specification and claims, the terms "coupled" and "connected" and their derivatives may be used. It should be understood that these terms may not be synonymous with each other. On the contrary, in specific examples, "connected" or "coupled" may be used to indicate that two or more elements are in direct or indirect physical or electrical contact with each other. "Coupled" may also mean that two or more elements are not in direct contact with each other, but still cooperate or interact with each other.

[0175] Unless expressly stated otherwise, it is to be understood that throughout the specification, terms such as “process,” “compute,” “calculate,” “determine,” etc. refer to the actions and / or processes of a computer or computing system or similar electronic computing device that manipulates and / or transforms data represented as physical (e.g., electronic) quantities in the computing system's registers and / or memories into other data similarly represented as physical quantities in the computing system's memories, registers, or other such information storage, transmission, or display devices.

[0176] Similarly, the term "processor" may refer to any device or part of a device that processes electronic data from registers and / or memory and converts the electronic data into other electronic data that can be stored in registers and / or memory. As a non-limiting example, a "processor" may be a CPU or a GPU. A "computing platform" may include one or more processors. As used herein, a "software" process may include, for example, software and / or hardware entities that perform work over time, such as tasks, threads, and intelligent agents. In addition, each process may refer to multiple processes for executing instructions sequentially or in parallel, continuously or intermittently. In at least one embodiment, the terms "system" and "method" are used interchangeably herein, as long as a system can embody one or more methods and a method can be considered a system.

[0177] In this document, reference may be made to obtaining, acquiring, receiving or inputting analog or digital data into a subsystem, a computer system or a computer-implemented machine. In at least one embodiment, the process of obtaining, acquiring, receiving or inputting analog and digital data may be accomplished in a variety of ways, such as by receiving data as a parameter of a function call or a call to an application programming interface. In at least one embodiment, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data via a serial or parallel interface. In at least one embodiment, the process of obtaining, acquiring, receiving or inputting analog or digital data may be accomplished by transmitting data from a providing entity to an acquiring entity via a computer network. In at least one embodiment, reference may also be made to providing, outputting, transmitting, sending or presenting analog or digital data. In various examples, the process of providing, outputting, transmitting, sending or presenting analog or digital data may be accomplished by transmitting data as an input or output parameter of a function call, a parameter of an application programming interface or an interprocess communication mechanism.

[0178] Although the description herein sets forth example embodiments of the technology, other architectures may be used to implement the functionality and are intended to be within the scope of the present disclosure. In addition, although specific allocations of responsibilities may be defined above for descriptive purposes, the various functions and responsibilities may be allocated and divided in different ways depending on the circumstances.

[0179] Furthermore, although the subject matter has been described in language specific to structural features and / or methodological acts, it should be understood that the subject matter claimed in the appended claims is not necessarily limited to the specific features or acts described. Rather, the specific features and acts are disclosed as exemplary forms of implementing the claims.

[0180] Other computer system designs and configurations may be suitable for implementing the systems and methods described herein.The following examples illustrate various implementations according to one or more aspects of the present disclosure.

[0181] Example 1 is a method comprising: receiving, at a device connected to a computing system hosting a client, a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with the client; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol from a plurality of transaction fault handling protocols to be initiated to resolve the detected page fault; and causing execution of the selected transaction fault handling protocol to resolve the detected page fault.

[0182] Example 2 is the method of Example 1, wherein the transaction failure handling protocol is selected based on at least one of: characteristics associated with the device; characteristics associated with the client; attributes of the transaction initiated by the request; or attributes of one or more previous transactions initiated at the device.

[0183] Example 3 is the method of Example 2, wherein the transaction or at least one of the one or more previous transactions corresponds to one or more of: a communication flow type transaction; a queue type transaction; or a sub-device type transaction.

[0184] Example 4 is the method of Example 1, wherein the device is a device with simulation functionality, configured to expose multiple simulation devices to the computing system, each simulation device having a different interface type, and wherein the transaction failure handling protocol is selected from the multiple transaction failure handling protocols based on the interface type of the simulation device corresponding to the transaction.

[0185] Example 5 is the method of Example 1, wherein the selected transaction fault handling protocol involves one or more of: rescheduling at least one operation of the transaction, wherein the at least one operation includes the DMA operation or another operation of the transaction; terminating the at least one operation of the transaction; or updating a memory address associated with at least one of the one or more DMA operations of the transaction to correspond to another memory address.

[0186] Example 6 is the method of Example 1, wherein selecting a fault handling protocol to initiate to resolve the detected page fault comprises: accessing a transaction fault handling data structure including the plurality of transaction fault handling protocols, wherein each of the plurality of transaction fault handling protocols is associated with a characteristic associated with the client, an attribute of the transaction requested to be initiated, or an attribute of one or more previous transactions initiated at the device; identifying an entry of the transaction fault handling data structure corresponding to at least one of a characteristic associated with the client hosted by the computing system, an attribute of the transaction requested to be initiated, or an attribute of one or more previous transactions initiated at the device; and determining the transaction fault handling protocol based on the identified entry.

[0187] Example 7 is the method of Example 1, wherein causing execution of the selected transaction failure handling protocol includes: transmitting to a virtualization manager associated with the computing system one or more of a first request to fix a specific memory area of ​​the computing system or a second request to make one or more memory pages associated with the data available in the specific area of ​​the memory of the computing system.

[0188] Example 8 is the method of Example 7, wherein the second request to make the one or more memory pages associated with the data available in the specific area of ​​the memory of the computing system includes an indication of a priority associated with each of the one or more memory pages associated with the data, and wherein the second request is to cause the virtualization manager to configure the one or more memory pages in the specific area of ​​the memory according to the indicated priority associated with each of the one or more memory pages in response to receiving the second request.

[0189] Example 9 is the method of Example 1, further comprising: identifying a memory buffer residing on at least one of the device or a memory associated with the computing system, wherein the identified memory buffer is allocated to at least one of the one or more clients, the device, or the transaction; and storing the data associated with the one or more DMA operations in the identified memory buffer.

[0190] Example 10 is the method of Example 9, wherein the identified memory buffer is included in a set of memory buffers managed by: a client hosted by the computing system; a virtualization manager associated with the client; or a controller associated with the device.

[0191] Example 11 is the method of Example 1, further comprising: determining one or more additional memory pages to be referenced in the transaction or requesting one or more subsequent transactions initiated at the device; and transmitting one or more of a first request for fixing a specific memory area of ​​the computing system to accommodate the one or more additional memory pages or a second request for making the one or more additional memory pages available in a specific area of ​​the memory of the computing system.

[0192] Example 12 is the method of example 1, wherein each client corresponds to a virtual machine or a container.

[0193] Example 13 is the method of Example 1, wherein the device is connected to the computing system via a system bus, wherein the system bus corresponds to at least one of a peripheral component interconnect express (PCIe) interface, a communications express link (CXL) interface, a die-to-die (D2D) interconnect interface, a chip-to-chip (C2C) interconnect interface, a graphics processing unit (GPU) interconnect interface, or a coherent accelerator processor interface (CAPI).

[0194] Example 14 is a system comprising: a memory; and a device coupled to the memory and a computing system hosting a client, for performing operations, the operations comprising: receiving a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with the client; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol to be initiated to resolve the detected page fault from a plurality of transaction fault handling protocols; and causing execution of the selected transaction fault handling protocol to resolve the detected page fault.

[0195] Example 15 is the system of Example 14, wherein the transaction failure handling protocol is selected based on at least one of: characteristics associated with the device; characteristics associated with the client; attributes of the transaction initiated by the request; or attributes of one or more previous transactions initiated at the device.

[0196] Example 16 is the system of Example 15, wherein the transaction or at least one of the one or more previous transactions corresponds to one or more of: a communication flow type transaction; a queue type transaction; or a sub-device type transaction.

[0197] Example 17 is the system of Example 14, wherein the device is a device with simulation functionality, configured to expose a plurality of simulation devices to the computing system, each simulation device having a different interface type, and wherein the transaction failure handling protocol is selected from the plurality of transaction failure handling protocols based on an interface time of the simulation device corresponding to the transaction.

[0198] Example 18 is the system of Example 14, wherein the selected transaction fault handling protocol involves one or more of: rescheduling at least one operation of the transaction, wherein the at least one operation includes the DMA operation or another operation of the transaction; terminating the at least one operation of the transaction; or updating a memory address associated with at least one of the one or more DMA operations of the transaction to correspond to another memory address.

[0199] Example 19 is the system of Example 14, wherein selecting a fault handling protocol to initiate to resolve the detected page fault comprises: accessing a transaction fault handling data structure comprising a plurality of transaction fault handling protocols, wherein each of the plurality of transaction fault handling protocols is associated with a characteristic associated with a client, an attribute of a request-initiated transaction, or an attribute of one or more previous transactions initiated on a device; identifying an entry of the transaction fault handling data structure corresponding to at least one of a characteristic associated with a client hosted by the computing system, an attribute of a request-initiated transaction, or an attribute of one or more previous transactions initiated on a device; and determining the transaction fault handling protocol based on the identified entry.

[0200] Example 20 is a non-transitory computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing device of a computing system hosting clients, cause the processing device to perform operations comprising: receiving a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with at least one of the clients; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol from a plurality of transaction fault handling protocols to be initiated to resolve the detected page fault; and causing execution of the selected transaction fault handling protocol to resolve the detected page fault.

[0201] Example 21 is a method comprising: detecting, on a device connected to a computing system hosting one or more clients, a first page fault associated with a first DMA operation accessing a first memory page associated with a first client for use in the one or more clients; and transmitting, to a virtualization manager of the computing system, a first request to resolve the first page fault, wherein the first request indicates a first priority rating associated with the first memory page, and wherein the first request causes the virtualization manager to resolve the first page fault according to the first priority rating associated with the first memory page in response to receiving the first request.

[0202] Example 22 is the method of Example 21, wherein the first request to resolve the first page fault includes at least one of: a request to pin the first memory page to a specific region of a memory of the computing system; or a request to make the first memory page available in a specific region of a memory of the computing system.

[0203] Example 23 is the method of Example 21, further comprising: determining a priority rating associated with the first memory page based on at least one of: characteristics associated with the device; characteristics associated with the client; attributes of a transaction associated with the first DMA operation; or attributes of one or more additional transactions initiated on the device.

[0204] Example 24 is the method of Example 21, wherein the device is a device with emulation functionality, configured to expose multiple emulation devices to a computing system, each emulation device having a different interface type, and wherein a first priority rating associated with the first memory page corresponds to the interface type of the emulation device corresponding to the first DMA operation.

[0205] Example 25 is the method of Example 21, further comprising: detecting a second page fault associated with a second DMA operation for accessing a second memory page associated with a second client among the one or more clients; identifying first information associated with the first page fault and second information associated with the second page fault; and assigning a first priority rating to the first memory page taking into account the first information associated with the first page fault and the second information associated with the second page fault.

[0206] Example 26 is the method of Example 25, further comprising: assigning a second priority rating to the second memory page, taking into account first information associated with the first page fault and second information associated with the second page fault, wherein the second priority rating is lower than the first priority rating assigned to the first memory page; and transmitting a second request to a virtualization manager of the computing system to resolve the second page fault, wherein the second request indicates the second priority rating associated with the second memory page, and wherein the second request is used to cause the virtualization manager to resolve the first page fault associated with the first memory page before resolving the second page fault associated with the second memory page in response to receiving the second request.

[0207] Example 27 is the method of Example 25, further comprising: assigning a second priority rating to the second memory page, taking into account first information associated with the first page fault and second information associated with the second page fault, wherein the second priority rating is higher than the first priority rating assigned to the first memory page; and transmitting a second request to a virtualization manager of the computing system to resolve the second page fault, wherein the second request indicates the second priority rating associated with the second memory page, and wherein the second request is used to cause the virtualization manager to resolve the first page fault associated with the first memory page after resolving the second page fault associated with the second memory page in response to receiving the second request.

[0208] Example 28 is a system comprising: a memory; and a processing device coupled to the memory, wherein the processing device performs operations, the operations comprising: receiving a request from a device to perform one or more first operations for resolving a page fault associated with a DMA operation, the DMA operation being initiated to access a memory page associated with a first client hosted on a computing system, wherein the request indicates a priority rating associated with the memory page; identifying one or more second operations to be performed on the computing system; and performing the one or more first operations and the one or more second operations based on the first priority rating associated with the memory page.

[0209] Example 29 is the system of Example 28, wherein at least one of the one or more second operations corresponds to an additional page fault associated with an additional DMA operation for accessing an additional memory page associated with at least one of the first client or the second client hosted on the computing system.

[0210] Example 30 is the system of Example 28, wherein executing one or more first operations and one or more second operations based on a first priority rating associated with a memory page includes: determining whether the first priority rating associated with the memory page is higher than a second priority rating associated with the one or more second operations; and in response to determining that the first priority rating is higher than the second priority rating, arranging the one or more first operations to be performed before executing the one or more second operations.

[0211] Example 31 is the system of Example 30, further comprising: in response to determining that the first priority rating is not higher than the second priority rating, scheduling the one or more second operations to be performed before performing the one or more first operations.

[0212] Example 32 is the system of Example 28, wherein the received request comprises at least one of: a request to pin a memory page to a specific region of a memory of the computing system; or a request to make a memory page available at a specific region of a memory of the computing system.

[0213] Example 33 is the system of example 28, wherein the first client corresponds to a virtual machine or a container.

[0214] Example 34 is a non-transitory computer-readable medium storing instructions, wherein when the instructions are executed by a processing device of a computing system hosting one or more clients, cause the processing device to: detect, on a device connected to the computing system hosting the one or more clients, a first page fault associated with a first DMA operation accessing a first memory page associated with a first client for use in the one or more clients; and transmit a first request to a virtualization manager of the computing system to resolve the first page fault, wherein the first request indicates a first priority rating associated with the first memory page, and wherein the first request causes the virtualization manager to resolve the first page fault according to the first priority rating associated with the first memory page in response to receiving the first request.

[0215] Example 35 is the non-transitory computer-readable medium of Example 34, wherein the first request to resolve the first page fault includes at least one of: a request to pin the first memory page to a specific region of a memory of the computing system; or a request to make the first memory page available in a specific region of a memory of the computing system.

[0216] Example 36 is the non-transitory computer-readable medium of Example 34, wherein the operation further comprises: determining a priority rating associated with the first memory page based on at least one of: a characteristic associated with the device; a characteristic associated with the client; an attribute of a transaction associated with the first DMA operation; or an attribute of one or more additional transactions initiated on the device.

[0217] Example 37 is the non-transitory computer-readable medium of Example 34, wherein the device is a device with emulation functionality configured to expose multiple emulation devices to a computing system, each emulation device having a different interface type, and wherein a first priority rating associated with the first memory page corresponds to the interface type of the emulation device corresponding to the first DMA operation.

[0218] Example 38 is a non-transitory computer-readable medium of Example 34, wherein the operations further include: detecting a second page fault associated with a second DMA operation for accessing a second memory page associated with a second client among the one or more clients; identifying first information associated with the first page fault and second information associated with the second page fault; and assigning a first priority rating to the first memory page taking into account the first information associated with the first page fault and the second information associated with the second page fault.

[0219] Example 39 is the non-transitory computer-readable medium of Example 38, wherein the operation further includes: assigning a second priority rating to the second memory page taking into account first information associated with the first page fault and second information associated with the second page fault, wherein the second priority rating is lower than the first priority rating assigned to the memory page; and transmitting a second request to a virtualization manager of the computing system to resolve the second page fault, wherein the second request indicates the second priority rating associated with the second memory page, and wherein the second request is used to cause the virtualization manager to resolve the first page fault associated with the first memory page before resolving the second page fault associated with the second memory page in response to receiving the second request.

[0220] Example 40 is the non-transitory computer-readable medium of Example 38, wherein the operation further includes: assigning a second priority rating to the second memory page, taking into account first information associated with the first page fault and second information associated with the second page fault, wherein the second priority rating is higher than the first priority rating assigned to the first memory page; and transmitting a second request to a virtualization manager of the computing system to resolve the second page fault, wherein the second request indicates the second priority rating associated with the second memory page, and wherein the second request is used to cause the virtualization manager to resolve the first page fault associated with the first memory page after resolving the second page fault associated with the second memory page in response to receiving the second request.

[0221] Example 41 is a method comprising: detecting, on a device connected to a computing system hosting one or more clients, a page fault associated with a DMA operation of a transaction, wherein the DMA operation is performed to access a memory page associated with a client of the one or more clients; updating a backup completion queue to include an indication of a completion event associated with the transaction; determining that execution of a transaction fault handling protocol for handling the page fault associated with the DMA operation has completed; and updating a regular completion queue to include an indication of the completion event associated with the transaction.

[0222] Example 42 is the method of Example 41, wherein the backup completion queue is configured to store indications of completion events associated with failed transactions, and the regular completion queue is configured to store indications of completion events associated with successfully completed transactions.

[0223] Example 43 is the method of Example 41, further comprising: updating the backup completion queue to include one or more additional indications of additional completion events associated with additional transactions delayed due to page faults associated with the DMA operations of the transactions.

[0224] Example 44 is the method of Example 43, further comprising: in response to updating the backup completion queue to include an indication of a completion event associated with the transaction, initiating a synchronization protocol to transfer one or more additional indications of additional completion events associated with the additional transaction from the backup completion queue to the regular completion queue.

[0225] Example 45 is the method of Example 41, wherein updating the general completion queue to include an indication of a completion event associated with the transaction includes at least one of: updating metadata associated with the completion event to indicate the general completion queue; writing the completion event to the general completion queue to indicate the completion event; updating a producer index; or transmitting a command for initiating a synchronization protocol.

[0226] Example 46 is the method of Example 41, wherein determining that execution of a transaction fault handling protocol for handling a page fault associated with a DMA operation has completed comprises detecting at least one of: an interrupt; polling a consumer index; or polling a backup completion queue or a regular completion queue.

[0227] Example 47 is the method of Example 41, further comprising: removing the indication of the completion event from the backup completion queue.

[0228] Example 48 is a system comprising: a memory; and a device coupled to the memory, wherein the device performs operations including: detecting a page fault associated with a DMA operation of a transaction, wherein the DMA operation is performed to access a memory page associated with a client of one or more clients hosted by a computing system; updating a backup completion queue to include an indication of a completion event associated with the transaction; determining that execution of a transaction fault handling protocol to handle the page fault associated with the DMA operation has completed; and updating a regular completion queue to include an indication of the completion event associated with the transaction.

[0229] Example 49 is the system of example 48, wherein the backup completion queue is configured to store indications of completion events associated with failed transactions, and the regular completion queue is configured to store indications of completion events associated with successfully completed transactions.

[0230] Example 50 is the system of Example 48, wherein the operations further comprise: updating the backup completion queue to include one or more additional indications of additional completion events associated with additional transactions delayed due to page faults associated with DMA operations of the transactions.

[0231] Example 51 is the system of example 50, in response to updating the backup completion queue to include an indication of a completion event associated with the transaction, initiating a synchronization protocol to transfer one or more additional indications of additional completion events associated with the additional transaction from the backup completion queue to the regular completion queue.

[0232] Example 52 is the system of Example 48, wherein updating the general completion queue to include an indication of a completion event associated with the transaction comprises at least one of: updating metadata associated with the completion event to indicate the general completion queue; updating a producer index; or transmitting a command for initiating a synchronization protocol.

[0233] Example 53 is the system of example 48, wherein determining that execution of a transaction fault handling protocol for handling a page fault associated with a DMA operation has completed comprises detecting at least one of: an interrupt; polling a consumer index; or polling a backup completion queue or a regular completion queue.

[0234] Example 54 is a non-transitory computer-readable medium storing instructions, wherein when the instructions are executed by a processing device of a computing system hosting one or more clients, the instructions cause the processing device to perform operations including: detecting a page fault associated with a DMA operation of a transaction, wherein the DMA operation is performed to access a memory page associated with a client of the one or more clients hosted by the computing system; updating a backup completion queue to include an indication of a completion event associated with the transaction; determining that execution of a transaction fault handling protocol for handling the page fault associated with the DMA operation has completed; and updating a regular completion queue to include an indication of the completion event associated with the transaction.

[0235] Example 55 is the non-transitory computer readable medium of example 54, wherein the backup completion queue is configured to store indications of completion events associated with failed transactions, and the regular completion queue is configured to store indications of completion events associated with successfully completed transactions.

[0236] Example 56 is the non-transitory computer readable medium of example 54, wherein the operations further comprise updating the backup completion queue to include one or more additional indications of additional completion events associated with additional transactions delayed due to page faults associated with DMA operations of the transactions.

[0237] Example 57 is the non-transitory computer-readable medium of Example 56, wherein the operations further comprise: in response to updating the backup completion queue to include an indication of a completion event associated with the transaction, initiating a synchronization protocol to transfer one or more additional indications of additional completion events associated with the additional transaction from the backup completion queue to the regular completion queue.

[0238] Example 58 is the non-transitory computer-readable medium of Example 54, wherein updating the general completion queue to include an indication of a completion event associated with the transaction comprises at least one of: updating metadata associated with the completion event to indicate the general completion queue; updating a producer index; or transmitting a command for initiating a synchronization protocol.

[0239] Example 59 is the non-transitory computer readable medium of example 54, wherein determining that execution of a transaction fault handling protocol for handling a page fault associated with a DMA operation has completed comprises detecting at least one of: an interrupt; polling a consumer index; or polling a backup completion queue or a regular completion queue.

[0240] Example 60 is the non-transitory computer readable medium of example 54, wherein the operations further comprise removing the indication of the completion event from the backup completion queue.

[0241] Example 61 is the system of Example 28, wherein the operation further includes: determining that a first priority rating associated with a memory page is higher than a second priority rating associated with other memory pages; and based on the determination, evicting the other memory pages associated with the second priority rating from the region of memory.

[0242] Example 62 is the method of Example 40, further comprising determining whether to include the indication of the completion event associated with the transaction in the backup completion queue or in the regular completion queue, taking into account availability of the backup completion queue.

[0243] Example 63 is the system of example 48, wherein the operations further comprise determining whether to include the indication of the completion event associated with the transaction in a backup completion queue or in a regular completion queue, taking into account availability of the backup completion queue.

[0244] Example 64 is the non-transitory computer readable medium of example 54, wherein the operations further comprise determining whether to include the indication of the completion event associated with the transaction in a backup completion queue or in a regular completion queue, taking into account availability of the backup completion queue.

[0245] Example 65 is the method of Example 11, further comprising transmitting a third request to unpin the specific region of the memory of the computing system.

[0246] Example 66 is the method of Example 41, further comprising determining whether to include an indication of a completion event associated with the transaction in a backup completion queue or in a regular completion queue, taking into account the synchronization completion status.

Claims

1. A method comprising: receiving, at a device connected to a computing system hosting one or more clients, a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with at least one of the one or more clients; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol from a plurality of transaction fault handling protocols to initiate to resolve the detected page fault; as well as The selected transaction fault handling protocol is caused to be executed to resolve the detected page fault.

2. The method of claim 1 , wherein the transaction failure handling protocol is selected based on at least one of: characteristics associated with the device; characteristics associated with the one or more clients; the attributes of the transaction being requested to be initiated; or Attributes of one or more previous transactions initiated at the device.

3. The method of claim 2, wherein at least one of the transaction or the one or more previous transactions corresponds to one or more of: Communication flow type transaction; Queue type transactions; or Subdevice type transaction.

4. The method according to claim 1, wherein the device is a device with emulation function, which is configured to expose a plurality of emulation devices to the computing system, each emulation device having a different interface type, and wherein, The transaction failure handling protocol is selected from the plurality of transaction failure handling protocols based on an interface type of a simulation device corresponding to the transaction.

5. The method of claim 1 , wherein the selected transaction failure handling protocol relates to one or more of the following: rescheduling at least one operation of the transaction, wherein the at least one operation comprises the DMA operation or another operation of the transaction; terminating the at least one operation of the transaction; or A memory address associated with at least one of the one or more DMA operations of the transaction is updated to correspond to another memory address.

6. The method of claim 1 , wherein selecting a fault handling protocol to initiate to resolve the detected page fault comprises: accessing a transaction failure handling data structure including the plurality of transaction failure handling protocols, wherein each of the plurality of transaction failure handling protocols is associated with a characteristic associated with the one or more clients, an attribute of the transaction requested to be initiated, or an attribute of one or more previous transactions initiated at the device; identifying an entry of the transaction failure handling data structure that corresponds to at least one of a characteristic associated with the one or more clients hosted by the computing system, an attribute of the transaction initiated by a request, or an attribute of one or more previous transactions initiated at the device; as well as The transaction failure handling protocol is determined based on the identified entry.

7. The method of claim 1 , wherein causing execution of the selected transaction failure handling protocol comprises: One or more of a first request to pin a particular region of a memory of the computing system or a second request to make one or more memory pages associated with the data available in the particular region of the memory of the computing system is sent to a virtualization manager associated with the computing system.

8. The method of claim 7 , wherein the second request to make the one or more memory pages associated with the data available in the particular area of ​​the memory of the computing system comprises an indication of a priority level associated with each of the one or more memory pages associated with the data, and wherein, The second request is to cause the virtualization manager to configure the one or more memory pages in the specific region of the memory according to the indicated priority level associated with each of the one or more memory pages in response to receiving the second request.

9. The method according to claim 1, further comprising: identifying a memory buffer residing on at least one of the device or a memory associated with the computing system, wherein the identified memory buffer is allocated to at least one of the one or more clients, the device, or the transaction; as well as The data associated with the one or more DMA operations is stored in the identified memory buffer.

10. The method of claim 9, wherein the identified memory buffer is included in a set of memory buffers managed by: at least one of the one or more clients hosted by the computing system; a virtualization manager associated with the one or more clients; or A controller associated with the device.

11. The method according to claim 1, further comprising: determining one or more additional memory pages to be referenced in the transaction or requesting one or more subsequent transactions initiated at the device; as well as One or more of a first request to pin a particular region of a memory of the computing system to accommodate the one or more additional memory pages or a second request to make the one or more additional memory pages available in the particular region of the memory of the computing system is sent.

12. The method according to claim 11, further comprising: A third request is sent to unpin the particular region of the memory of the computing system.

13. The method of claim 1, wherein the client corresponds to a virtual machine, a container, or a process.

14. The method of claim 1 , wherein the device is connected to the computing system via a system bus, wherein the system bus corresponds to at least one of a peripheral component interconnect express (PCIe) interface, a communications express link (CXL) interface, a die-to-die (D2D) interconnect interface, a chip-to-chip (C2C) interconnect interface, a graphics processing unit (GPU) interconnect interface, or a coherent accelerator processor interface (CAPI).

15. A system comprising: Memory; and A device coupled to the memory and a computing system hosting one or more clients for performing operations comprising: receiving a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with at least one of the one or more clients; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol from a plurality of transaction fault handling protocols to initiate to resolve the detected page fault; and The selected transaction fault handling protocol is caused to be executed to resolve the detected page fault.

16. The system of claim 15, wherein the transaction failure handling protocol is selected based on at least one of: characteristics associated with the device; characteristics associated with the one or more clients; the attributes of the transaction being requested to be initiated; or Attributes of one or more previous transactions initiated at the device.

17. The system of claim 16, wherein at least one of the transaction or the one or more previous transactions corresponds to one or more of: Communication flow type transaction; Queue type transactions; or Subdevice type transaction.

18. The system of claim 15, wherein the device is a device with emulation functionality configured to expose a plurality of emulation devices to the computing system, each emulation device having a different interface type, and wherein, The transaction failure handling protocol is selected from the plurality of transaction failure handling protocols based on an interface time of a simulation device corresponding to the transaction.

19. The system of claim 15, wherein the transaction failure handling protocol selected relates to one or more of the following: rescheduling at least one operation of the transaction, wherein the at least one operation comprises the DMA operation or another operation of the transaction; terminating the at least one operation of the transaction; or A memory address associated with at least one of the one or more DMA operations of the transaction is updated to correspond to another memory address.

20. A non-transitory computer-readable medium having instructions stored thereon, wherein the instructions, when executed by a processing device of a computing system hosting one or more clients, cause the processing device to perform operations comprising: receiving a request to initiate a transaction involving a direct memory access (DMA) operation for accessing data associated with at least one of the one or more clients; detecting a page fault associated with execution of the DMA operation of the transaction; selecting a transaction fault handling protocol from a plurality of transaction fault handling protocols to initiate to resolve the detected page fault; as well as The selected transaction fault handling protocol is caused to be executed to resolve the detected page fault.

Images