Patent ID: 12189966

DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENT

Referring now toFIG.1, an electronic computer10may provide for one or more processors12operating in conjunction with a main computer memory14to execute one or more programs16including generally a kernel or operating system18and various application programs20and data storage19. The main memory14will normally include volatile solid-state memory, for example, DRAM.

The processor12may communicate with the main memory14using a memory bus15communicating, under the control of a memory management unit (MMU)22with a memory controller24. As is generally understood in the art, the MMU22provides a mechanism for translating virtual memory addresses to physical memory addresses for virtualization of the main memory14and to set read and write permissions for particular physical memory addresses thereby controlling access to those addresses. In this regard, the MMU22may communicate with the main memory14for access to a page table23linking physical and virtual memory addresses and providing other permission and status bits as is generally understood in the art. The memory controller24operates to provide memory control features such as address decoding and refreshing of DRAM.

The processor12may also communicate over an I/O bus structure28, separate from the memory bus15, with various I/O devices30, including but not limited, for example, to human interface elements such as graphic displays, as well as network interface cards, audio interface cards and the like. Importantly, the I/O devices30will include at least one and sometimes several solid-state drives32aand32bfunctionally operating like a magnetic disk drive and typically employing a nonvolatile architecture, for example, having an average read latency of less than 20 μs at 0.5 GB per second and a capacity in excess of 100 GB. Example solid-state drives32include not only transistor based architectures such as NAND memory but also phase change memories, spin-torque MRAMs, and memristor memories. An example solid-state drive32suitable for use with the present invention are commercially available under the trade name of Optane NVMe from Intel Corporation.

These I/O devices30and/or the SIOMMU26may also communicate with the memory controller24to implement direct memory access of the main memory14.

The SIOMMU26also communicates with the main memory14for access to a second page table34operating similarly to page table23with differences in content as will be discussed in greater detail below. Each of the page tables23and34may have multiple levels as is understood in the art.

The data of the page tables34is created and then loaded by the operating system18during a file open process, in many but not all cases, concluding the involvement of the operating system18in the transfer of data of that file, typically until the file closes. The operating system18allocates a virtual space in the computer memory14(virtual) equal to or exceeding the file size. The data of the page table34is then loaded such as to map an application identifier (PASID) of the application20opening the file and solid-state drive block address (starting virtual block addresses converted from a file path name) to the allocated virtual space in the computer memory14and to set read/write permissions as will be discussed below and to set a device ID that will be discussed below, in this case identifying a particular solid-state drive32. In this regard, the PASID may serve as an index to the page table34and thus exists logically but is not a table entry. More generally, the operating system18handles file metadata operation such as open( ) close( ) and appends while the SIOMMU26will handle data operation such as read( ) and write( ) without operating system involvement.

Referring now also toFIG.2, the SIOMMU26may provide for control logic circuitry36executing an implicit program38, implemented in integrated circuitry, to receive an access requests40from the SSDs32(initiated by the processor12executing the libraries or drivers21). Generally, then, data transfer to or from the solid-state drives32using the SIOMMU26will be implemented by a combination of the SIOMMU26and driver and library programs21in the main memory14. The SIOMMU26may provide a first translation lookaside buffer50aserving as a cache for a page table34afor evaluating I/O device addresses, that is, internal addresses of I/O devices30describing stored data in those devices. The SIOMMU26may further communicate with a second translation lookaside buffer50bserving as a cache for a page table34bfor evaluating memory addresses, that is addresses of the main memory14

The access request40may be one of two types designated by an FT bit42in the request40. The first type, for example, indicated by an FT bit of one is intended to evaluate (determine permissions and translate between physical and virtual I/O device addresses) a request of an I/O device30, for example a block address of an SSD device32. The second type, for example, indicated by an FT bit of zero, is intended to evaluate (determine permissions and translations) a request for a memory address of the main memory14. Typically, a direct memory transfer between an SSD device32and main memory14may require both an evaluation of I/O device addresses and memory addresses to establish the endpoints of the data transfer.

The access request40may also include a process address space identifier (PASID) analogous to the ASID used in conventional MMUs and uniquely identifying a process of a particular application program20. In addition, the access request40may provide a device ID46distinguishing between the particular solid-state drives32aand32b. Further, as noted above, the access request40may provide an address, for example, a virtual block address that will be mapped into a physical block of the solid-state drive32identified by the device ID46(when the FT bit42is set) or a virtual memory address that will be made to a physical memory address of the main memory14(when the FT bit42is reset). Finally, the request40may include a read/write indication43of whether this request is for a reading or writing of data with respect to the requester.

Referring now also toFIG.4, upon receipt of the request40as indicated by process block48, the FT bit42is evaluated to determine the type of address being received in the access request40. If the FT bit is set or one, the program38proceeds to decision block50and the logic circuitry36of the SIOMMU26consults a translate look aside buffer50a(shown inFIG.2) holding a cached portion of the page table34aof I/O device addresses to attempt to find a matching of an entry with the PASID44, and the device ID46of the request40. The TLB50a, by providing a local caching of page table information in the circuitry of the SIOMMU26, helps reduce the latency or delay in obtaining information from the page table34which would otherwise require accessing main memory14outside of the integrated circuit of the SIOMMU26.

If an entry is not found, as determined a decision block54, at process block56a page walk through the page table34ais conducted essentially operating to review the data of page table34for a matching PASID44and the device ID46. If a match is not obtained in the page table34a, determined by decision block58, a fault is indicated at process block60and the program38loops back to process block48.

Importantly, the fault prevents the requested data transfer from being handled by the SIOMMU26and is referred to the operating system18via the application program20or a driver library21for handling, for example, in as is done with a conventional page fault. The fault may be handled in a number of different ways including, for example, by simply faulting and preventing data transfer or by implementing the data transfer by defaulting to the operating system18using conventional methods, or causing the operating system18to add data to the page table34in a remapping operation and referring the transfer again to the SIOMMU26. The preferred handling of the fault may be signaled by a unique fault code.

In the event that a match of the request40is found in the page table34a, but not previously in the TLB50a, the TLB50amay be updated as indicated by process block62.

Importantly, the TLB50aand TLB50bmay be implemented as a single table in a combined device greatly simplifying and improving the performance of address lookups.

In both cases where a match of the request40is found either in the page table34or in the TLB50(at decision block58or decision block54), the program38proceeds to decision block66to assess whether the requested transfer will be permitted according to the permissions of the associated matched data.

Referring toFIG.3, the matching process of decision blocks54and58reviews file table entries70(either in the page table34or cached in the TLB50) which include an FT field71, a PASID field72, a device identifier field74, a virtual block address field76, a physical block address field78and read/write permission field80. It should be understood that the file table70is depicted logically and thus could be implemented with different data structures, from one or more tables, with different indexing or addressing, or in one or more steps to accomplish the same purpose. For example, the SIOMMU26may check to see if there is an entry with a matching PASID, FT bit, and address. If there is a match, it may then compare the device ID field of the entry against the device ID of the request, and fail if they don't match and succeed if they do. A match is indicated at decision block58or decision block54if the FT bit42of the request matches the FT field71of the file table entry70and the PASID44of the request40matches the PASID field72of the file table entry70, and the device ID46of the request40matches the device identification field74of the file table entry70and the address41of the request40matches the virtual block address field76of the file table entry70.

At decision block66, permission is imputed if there is a valid physical block address78in the matching file table entry70and if the read/write permission field80holds data indicating that the desired access is permitted (either reading or writing).

It will be understood that the fault condition of process block60occurs because of a lack of permission imputed from any of there being no matching file table entry70or when there is a matching table entry70but permission not being granted per read/write permission field80. The fault mechanisms allow the application program20to bypass the SIOMMU in favor of the operating system when low latency is not required, simply by setting the permissions to deny transfer, further minimizing the necessary size of the SIOMMU TLBs50.

When permission is granted as indicated by process block82, the matching physical block address78is provided to the I/O device30to initiate a physical storage access and then memory transfer via the memory controller24.

Referring still toFIG.4, if at decision block50, the FT bit42is zero, then a separate set of page table entries34bare reviewed relating to memory addresses not I/O device addresses but otherwise logically equivalent. In this process, process block51corresponds generally to process block56but relative to TLB50band process blocks52and53correspond to process blocks56and58but relative to page table34b. The remaining process decision blocks55,57,59and61correspond generally to process box6260,66and82as discussed above with the differences just noted. At process block61a memory address is output.

As noted above, the SIOMMU26will generally comprise a single integrated circuit with on-chip memory for the TLB50in order to provide a substantial speed advantage over implementing these functions with the operating system18. The SIOMMU26may be separate from or incorporated into the processors12. It will be generally understood that the present invention is not limited to solid-state drives but can apply generally to I/O devices addressed as such and having internal addressed sources of data, for example, a network card having addressed ports.

Certain terminology is used herein for purposes of reference only, and thus is not intended to be limiting. For example, terms such as “upper”, “lower”, “above”, and “below” refer to directions in the drawings to which reference is made. Terms such as “front”, “back”, “rear”, “bottom”, and “side”, describe the orientation of portions of the component within a consistent but arbitrary frame of reference which is made clear by reference to the text and the associated drawings describing the component under discussion. Such terminology may include the words specifically mentioned above, derivatives thereof, and words of similar import. Similarly, the terms “first”, “second” and other such numerical terms referring to structures do not imply a sequence or order unless clearly indicated by the context.

When introducing elements or features of the present disclosure and the exemplary embodiments, the articles “a”, “an”, “the” and “said” are intended to mean that there are one or more of such elements or features. The terms “comprising”, “including”, and “having” are intended to be inclusive and mean that there may be additional elements or features other than those specifically noted. It is further to be understood that the method steps, processes, and operations described herein are not to be construed as necessarily requiring their performance in the particular order discussed or illustrated, unless specifically identified as an order of performance. It is also to be understood that additional or alternative steps may be employed.

It is specifically intended that the present invention not be limited to the embodiments and illustrations contained herein and the claims should be understood to include modified forms of those embodiments including portions of the embodiments and combinations of elements of different embodiments as come within the scope of the following claims. All of the publications described herein, including patents and non-patent publications, are hereby incorporated herein by reference in their entireties.

To aid the Patent Office and any readers of any patent issued on this application in interpreting the claims appended hereto, applicants wish to note that they do not intend any of the appended claims or claim elements to invoke 35 U.S.C. 112(f) unless the words “means for” or “step for” are explicitly used in the particular claim.