Methods and systems for resource isolation in computing storage devices

Abstract

Methods and systems for resource isolation in compute storage devices are provided. The method includes receiving a request at a controller of the compute storage (CS) device to allocate compute storage to an application on a host device. The request includes a resource set identifier (ID) associated with the application. The method also includes identifying a memory range within a memory region of the CS device. The method further includes storing an association between the memory range ID, the memory region, and an offset within the memory region of the memory range in a data structure associated with the resource set ID. The method also includes sending the memory range ID to the host device.

Description

Technical Field

[0001] This disclosure generally relates to systems and methods for resource isolation in computing storage devices. Background Technology

[0002] Compute storage devices provide computing capabilities and data storage. Therefore, host devices can store data on compute storage devices and offload computation to them. However, one application on a host device can modify resources on a compute storage device used by another application. This can lead to unpredictable execution results for the application.

[0003] The information disclosed in the Background section is only intended to enhance the understanding of the background of this disclosure, and therefore may contain information that does not constitute prior art. Summary of the Invention

[0004] In various embodiments, the systems, methods, and apparatus described herein include those relating to resource isolation in computing storage devices.

[0005] A method includes receiving a request at a controller of a computational storage (CS) device to allocate computational storage to an application on a host device. The request includes a resource set identifier (ID) associated with the application. The method also includes identifying a memory range within a memory region of the CS device. Furthermore, the method includes storing an association between the memory range ID, the memory region, and an offset within the memory region in a data structure associated with the resource set ID. The method further includes sending the memory range ID to the host device.

[0006] A compute storage (CS) device includes a memory and a controller. The controller is configured to receive a request to allocate compute storage to an application on a host device. The request includes a resource set ID associated with the application. The controller is also configured to identify a memory range within a memory region of the memory. The controller is further configured to store an association between a memory range ID, a memory region, and an offset within the memory region in a data structure associated with the resource set ID. The controller is also configured to send the memory range ID to the host device.

[0007] A system includes a host device configured to store a session context associated with an application executing on the host device. The session context is associated with a resource set ID. The host device is also configured to insert the resource set ID into a request for allocating compute storage received from the application. The system also includes a compute storage device including memory and a controller. The controller is configured to receive the request for allocating compute storage. The controller is also configured to identify a memory range within a memory region of the memory. The controller is further configured to store an association between a memory range ID, a memory region, and an offset within the memory region in a data structure associated with the resource set ID. The controller is also configured to send the memory range ID to the host device. Attached Figure Description

[0008] The foregoing and other aspects of this technology will be better understood when this application is read with reference to the following figures, in which the same numerals denote similar or identical elements:

[0009] Figure 1 It is a block diagram of a system used to provide resource isolation in computing storage devices.

[0010] Figure 2A This is the first part of a diagram of another system used to provide resource isolation in computing storage devices.

[0011] Figure 2B This is the second part of a diagram for another system used to provide resource isolation in computing storage devices.

[0012] Figure 3A This is the first part of a diagram depicting modifications to compute storage commands, where such modifications can occur in the host system used to provide resource isolation in compute storage devices.

[0013] Figure 3B This is the second part of a diagram depicting modifications to compute storage commands, where such modifications can occur in the host system used to provide resource isolation in compute storage devices.

[0014] Figure 4 It is a diagram depicting the relationship between memory ranges and memory regions in a system used to provide resource isolation in computing storage devices.

[0015] Figure 5 This is a flowchart of a method for providing resource isolation in computing storage devices.

[0016] Figure 6 This is a flowchart of a method for allocating memory ranges in a system that provides resource isolation in computing storage devices.

[0017] Figure 7 This is a diagram illustrating computing resource management in an alternative system that provides resource isolation in computing storage devices.

[0018] While this technology is susceptible to various modifications and alternatives, specific embodiments thereof are illustrated by way of example in the accompanying drawings and will be described herein. The drawings may not be drawn to scale. However, it should be understood that the drawings and their detailed description are not intended to limit the technology to the specific forms disclosed; rather, the invention is intended to cover all modifications, equivalents, and alternatives falling within the spirit and scope of the technology as defined by the appended claims. Detailed Implementation

[0019] Details of one or more embodiments of the subject matter described herein are set forth in the accompanying drawings and the following description. Further features, aspects, and advantages of this subject matter will become apparent from the specification, drawings, and claims.

[0020] Various embodiments of this disclosure will now be described more fully below with reference to the accompanying drawings, which illustrate some, but not all, of the embodiments. In fact, this disclosure may be embodied in many different forms and should not be construed as limited to the embodiments set forth herein; rather, these embodiments are provided to enable this disclosure to meet applicable legal requirements. Unless otherwise stated, the term “or” is used herein in both interchangeable and combined senses. The terms “illustrative” and “example” are used as examples without indication of magnitude. The same reference numerals always refer to the same elements. Arrows in each figure depict bidirectional data flow and / or bidirectional data flow capabilities. The terms “path,” “path,” and “route” are used interchangeably herein.

[0021] Embodiments of this disclosure can be implemented in various ways, including as an article of manufacture of a computer program. A computer program product may include a non-transitory computer-readable storage medium storing applications, programs, program components, scripts, source code, program code, object code, bytecode, compiled code, interpreted code, machine code, executable instructions, etc. (also referred to herein as executable instructions, instructions for execution, computer program product, program code, and / or similar terms used interchangeably herein). Such non-transitory computer-readable storage medium includes all computer-readable media (including volatile and non-volatile media).

[0022] In one embodiment, a non-volatile computer-readable storage medium may include a floppy disk, a hard disk, solid-state storage (SSS) (e.g., a solid-state drive (SSD)), a solid-state card (SSC), a solid-state component (SSM), an enterprise flash drive, magnetic tape, or any other non-transitory magnetic medium. Non-volatile computer-readable storage media may also include punched cards, paper tape, optical marking sheets (or any other physical medium having a perforated pattern or other optically identifiable markings), compact disc read-only memory (CD-ROM), compact disc-rewritable optical disc (CD-RW), digital versatile disc (DVD), Blu-ray disc (BD), or any other non-transitory optical medium. Such non-volatile computer-readable storage media may also include read-only memory (ROM), programmable read-only memory (PROM), erasable programmable read-only memory (EPROM), electrically erasable programmable read-only memory (EEPROM), flash memory (e.g., serial, NAND, NOR), multimedia memory card (MMC), secure digital (SD) memory card, smart media card, compact flash (CF) card, memory stick, etc.In addition, non-volatile computer-readable storage media may also include conductive-bridging random access memory (CBRAM), phase-change random access memory (PRAM), ferroelectric random-access memory (FeRAM), non-volatile random-access memory (NVRAM), magnetoresistive random-access memory (MRAM), resistive random-access memory (RRAM), silicon-oxide-nitride-oxide-silicon memory (SONOS), floating junction gate random access memory (FJG RAM), Millipede memory, racetrack memory, etc.

[0023] In one embodiment, the volatile computer-readable storage medium may include random access memory (RAM), dynamic random access memory (DRAM), static random access memory (SRAM), fast page mode dynamic random access memory (FPM DRAM), extended data-out dynamic random access memory (EDO DRAM), synchronous dynamic random access memory (SDRAM), double data rate synchronous dynamic random access memory (DDR SDRAM), double data rate type two synchronous dynamic random access memory (DDR2 SDRAM), double data rate type three synchronous dynamic random access memory (DDR3 SDRAM), Rambus dynamic random access memory (RDRAM), twin transistor RAM (TTRAM), and thyristor RAM. RAM (T-RAM), Zero-capacitor (Z-RAM), Rambus in-line memory component (RIMM), Dual in-line memory component (DIMM), Single in-line memory component (SIMM), Video random access memory (VRAM), Cache memory (including various levels), Flash memory, Register memory, etc.It should be understood that, in the case where the embodiments are described as using computer-readable storage media, other types of computer-readable storage media may be used instead of the computer-readable storage media described above, or other types of computer-readable storage media may be used in addition to the computer-readable storage media described above.

[0024] It should be understood that the various embodiments of this disclosure can also be implemented as methods, apparatus, systems, computing devices, computing entities, etc. Therefore, embodiments of this disclosure can take the form of apparatus, systems, computing devices, computing entities, etc., that execute instructions stored on a computer-readable storage medium to perform certain steps or operations. Consequently, embodiments of this disclosure can also take the form of entirely hardware embodiments performing certain steps or operations, entirely computer program product embodiments, and / or embodiments including a combination of computer program products and hardware.

[0025] Embodiments of this disclosure are described below with reference to block diagrams and flowcharts. Therefore, it should be understood that each block of the block diagrams and flowcharts can be implemented as a computer program product, a complete hardware embodiment, a combination of hardware and computer program products, and / or an apparatus, system, computing device, computing entity, etc., which executes instructions, operations, steps, and interchangeable terms (e.g., executable instructions, instructions for execution, program code, etc.) on a computer-readable storage medium. For example, code retrieval, loading, and execution can be performed sequentially, such that one instruction is retrieved, loaded, and executed at a time. In some example embodiments, retrieval, loading, and / or execution can be performed in parallel, such that multiple instructions are retrieved, loaded, and / or executed together. Thus, such embodiments can produce machines specifically configured to perform the steps or operations specified in the block diagrams and flowcharts. Therefore, the block diagrams and flowcharts support various combinations of embodiments for performing specified instructions, operations, or steps.

[0026] As used herein, a compute storage (CS) device refers to a storage device that supports compute tasks. For example, a CS device may include storage elements (e.g., non-volatile memory, such as flash memory, hard disk drives, etc.) and compute elements (e.g., central processing unit (CPU), graphics processing unit (GPU), field-programmable gate array (FPGA), application-specific integrated circuit (ASIC) (such as tensor processing unit), processor core, etc.) and is configured to support data storage at the compute elements and the execution of compute tasks at the compute elements. Therefore, a CS device can provide storage capacity to CS clients (e.g., compute devices) and can support offloading compute tasks from CS clients to the CS device.

[0027] More than one application can execute on the host device (e.g., CS client) of a CS device. However, if the first application accesses compute memory (e.g., CS resource) being used by a second application, the first application may modify data stored in the compute memory and disrupt the execution of the second application. An application-based (tenant) compute resource (e.g., compute memory) isolation mechanism is disclosed. According to this disclosure, a system can provide methods for identifying applications (tenants), methods for managing and protecting compute resource references based on applications (tenants), and methods for protecting compute resources from malicious access such as buffer overflow attacks.

[0028] In some implementations, the CS session management core can provide a method for identifying applications (tenants). Each application can have a unique session token and resource set ID. CS requests submitted via a session (or session context) can identify the application with a unique resource set ID. Furthermore, the compute resource management core can manage memory-scoped instances based on session context (e.g., based on resource set ID).

[0029] According to some examples of this disclosure, a mechanism is also provided to monitor which memory ranges a CS command is using, to prevent more than one CS command from accessing a memory range. According to some examples of this disclosure, a method is provided to translate an address from a memory range object notation to a CS device-specific address notation.

[0030] According to some examples of this disclosure, CS command verification logic is provided, which is configured to provide memory range verification, memory range boundary checking, and memory range address translation.

[0031] According to some examples of this disclosure, an application can receive access to the computational memory of a CS device through a memory-range object (handle) instead of a direct memory address.

[0032] refer to Figure 1A diagram of a system 100 for protecting CS resources is shown. System 100 includes a host device 102 and a CS device 104. Host 102 is communicatively coupled to CS device 104. In some examples, host 102 and CS device 104 are connected via a peripheral component interconnect express (PCIe) link. In other examples, host 102 and CS device 104 are connected via an Ethernet connection. It should be noted that other types of connections between host 102 and CS device 104, including wireless connections, are possible. Furthermore, host 102 and CS device 104 can be indirectly connected to each other (e.g., via one or more networks). In some examples, host 102 and CS device 104 communicate via the non-volatile memory express (NVMe) protocol. In other examples, different protocols are used.

[0033] Host 102 includes processor 106 and memory 108. Processor 106 may include a CPU, GPU, ASIC, FPGA, another type of processor, or a combination thereof. Memory 108 may include volatile memory, non-volatile memory, or a combination thereof. It should be noted that host 102 may include additional components besides those shown. For example, host 102 may include communication interfaces, user input devices (e.g., mouse, keyboard, etc.), output devices (e.g., display, speaker, etc.), other components, or combinations thereof. Furthermore, host 102 may include more than one of the components described or shown herein. For example, host 102 may include more than one processor, more than one memory, etc. The components of host 102 may be connected via one or more buses, one or more direct connections, or a combination thereof.

[0034] CS device 104 includes a controller 114, a processing device 118, a memory 116, and a storage medium 120. The controller 114 may include an ASIC, an FPGA, a central processing unit, or other processing unit configured to handle input and output operations associated with the storage medium 120. For example, in response to a write command from host 102, the controller 114 may read data from host 102 and write data to the storage medium 120. As another example, in response to a read command from host 102, the controller 114 may read data from the storage medium 120 and write data to host 102.

[0035] Storage medium 120 may include non-volatile computer-readable storage media, volatile computer-readable storage media, or combinations thereof. In some examples, storage medium 120 includes flash memory.

[0036] Memory 116 may include volatile computer-readable storage media, non-volatile computer-readable storage media, or a combination thereof. Memory 116 is configured to operate as operational memory and store program data for a program executed at processing device 118. Program data may include program inputs, program outputs, and temporary data for program execution. In some embodiments, memory 116 and storage medium 120 are implemented on the same physical device.

[0037] Processing device 118 may include an ASIC, FPGA, CPU, GPU, other types of processor units, or combinations thereof. Processing device 118 is configured to execute an application loaded into a program slot. The program slot may be a logical unit associated with processing device 118 and may or may not correspond to a different physical device (e.g., a processing core).

[0038] Although not shown, CS device 104 may include various additional components, such as a host interface layer, a flash translation layer, etc. For example, the host interface layer may be configured to translate commands received from host 102 into commands in a form recognizable by controller 114. This translation may include translating the addressing scheme used by host 102 into the addressing scheme used by controller 114. The flash translation layer may translate commands from controller 114 into a format recognizable by storage medium 120. This translation may include translating the addressing scheme used by host 102 into the addressing scheme used by storage medium 120. Furthermore, CS device 104 may include more than one of the components shown. For example, CS device 104 may include more than one memory 116, more than one storage medium 120, more than one processing device 118, more than one controller 114, etc. Furthermore, although not shown, CS device 104 may include various connections between components. For example, components of CS device 104 may be connected via a bus, via one or more direct connections, or a combination thereof. Figure 1 Some of the components shown can be combined. For example, controller 114 and processing device 118 can be implemented as the same processing device (or multiple processing devices).

[0039] In operation, host 102 can issue one or more allocation commands to allocate one or more portions of memory 116 to one or more applications executing at host 102. Furthermore, host 102 can issue I / O commands to the CS device to write data to or retrieve data from storage medium 120 or memory 116. Additionally, host 102 can issue one or more CS commands to processing device 118. CS commands can instruct the CS device to store data / instructions in memory 116, access data in memory 116, execute a program at processing device 118, or a combination thereof. Allocation commands, I / O commands, and CS commands can be issued by one or more applications executing at processor 106. System 100 provides a mechanism to isolate the resources of the CS device so that one application executing at processor 106 does not interfere with the resources used by another application executing at processor 106. In a particular example, resources can be managed on a session basis.

[0040] Memory 108 stores CS management core instructions 110 executable by processor 106 to provide a CS management core. The CS management core is configured to verify commands, prevent replay attacks, or a combination thereof. Memory 108 also stores library 112. Library 112 may include one or more application programming interfaces (APIs) usable by processor 106 to handle allocation commands, input / output commands, CS commands, or combinations thereof for processing by the CS management core.

[0041] For example, library 112 may include an API configured to generate session information (e.g., session token, session identifier (ID), random number, etc.) in response to a request from an application to create a session and / or session context. Each application executed by processor 106 may be associated with a unique session context. To begin delivering CS commands to CS device 104, an application may send a request to the API in library 112 to generate a new session context. In response to this request, the API may generate and store session information, such as a session token corresponding to the application's new session context. A session context may include more than one session. The API may be configured to generate and store a new session ID for each session request from an application. In some examples, the API may store an initial random number for each new session. As further described herein, such a random number can be used to prevent replay attacks. The API may also generate a resource set ID in response to a request to create a session and / or session context. In some examples, each session context has its own unique resource set ID. In other examples, each session has its own unique resource set ID. In some implementations, the resource set ID is inserted by the CS management core into the command sent to CS device 104, as further described below.

[0042] Library 112 may also include an API configured to initiate the transmission of a request for allocated memory to CS device 104 in response to an allocation request from an application executing at processor 106. In some implementations, the API may insert a resource set ID into the request for allocated memory transmitted to CS device 104. The resource set ID may identify the session context (e.g., an application) or session (e.g., a stream within an application) requesting the allocation. The API may return a memory range object to the application in response to the memory allocation request. The memory range object is an abstraction of a portion of memory 116. In some implementations, the memory range object includes a memory range ID and a size (e.g., in bytes, kilobytes, etc.).

[0043] Library 112 may also include an API configured to modify CS requests before they are transmitted to CS device 104. For example, the API may insert stored session information (e.g., session token, session ID, random number) into the computation request.

[0044] Furthermore, library 112 may include an API configured to receive memory allocation requests from applications and return corresponding memory objects. The memory object is an abstraction of memory 116 of CS device 104, and is described further herein. Library 112 may also include an API configured to add session information (e.g., session token, session identifier (ID), random number, other information, or combinations thereof) to input / output commands and CS commands issued from applications on host 102. The CS management core can validate commands based on the added session information. Valid commands can be passed to CS device 104, while invalid commands can be prevented from being issued to CS device 104.

[0045] The CS session management core is configured to determine whether a CS command (e.g., modified by library 112) is valid. For example, the CS session management core can compare a received random number associated with a command to a stored random number associated with the session. In response to determining a random number match, the CS session management core can determine that the command is valid. A valid command can then be forwarded to controller 114. Furthermore, the CS management core can update the session's stored random number with a new random number to prevent replay attacks.

[0046] Controller 114 is configured to execute compute resource manager instructions 126 to provide a compute resource manager core and execute CS command verification instructions 124 to provide a CS command verification core. The compute resource manager core is configured to allocate memory to a resource set ID in response to an allocation request. For example, memory 116 may include one or more memory regions (e.g., physical or logical regions), and the compute resource manager core may allocate one or more memory ranges from one or more memory regions to each resource set ID. The compute resource manager core may maintain a mapping data structure (e.g., a hash table) that identifies each memory range associated with a resource set ID. Each memory range may be identified by a memory range ID, a memory region ID that includes the memory region, an offset to the memory region, and a size of the memory region. In response to an allocation request from host 102, the compute resource manager core may identify a memory range within a memory region that satisfies the request, update the resource set ID indicated by the request to include the identified memory range, and return a memory range object identifying the memory range to host 102. The memory range object may include a memory range ID and a memory range size.

[0047] In addition to allocating memory ranges, the compute resource manager core can also provide translation of one or more addresses in a valid CS command to another address space (e.g., another virtual address space or the address space of memory 116) based on a memory mapping data structure of resource set IDs indicated by CS commands.

[0048] The CS command verification core can be configured to determine whether a received CS command is valid. For example, in response to receiving a CS command, the CS command verification core can extract the resource set ID, memory range ID, and offset from the compute command. The CS command can then determine whether the compute resource manager core has a mapping data structure for the resource set ID, wherein the mapping data structure includes a mapping to the memory range ID. Furthermore, the CS command verification core can determine whether the offset is within the memory range. Additionally, the CS verification core can determine whether the memory range is being used by another CS command. The CS command verification core can use one or more of these factors to determine whether a CS command is valid. A more detailed description of CS verification is given below. It should be noted that the CS command verification instruction 124 and the compute resource manager instruction 126 can be executed by different components than the controller 114. In some examples, the CS command verification instruction and the compute resource manager instruction 126 are executed by the processor 106 of the host 102.

[0049] Therefore, CS commands from applications originating from host 102 can be associated with a session / session context. CS device 104 can manage access to resources (e.g., memory 116) on a per-session / session context basis to prevent one application from accessing the resources of another application.

[0050] refer to Figure 2A and Figure 2B A diagram illustrates another system 200 for providing resource isolation in a CS device. In some embodiments, system 200 may correspond to system 100. System 200 includes a host 202 and a CS device 204. Host 202 may correspond to host 102, and CS device 204 may correspond to... Figure 1 The CS device 104. The host 202 executes application A 210, application B 212, and application C 214 on a processor (e.g., processor 106). In other examples, the host 102 may execute a different number of applications.

[0051] CS device 204 also provides a first program slot 250, a second program slot 252, a third program slot 254, and an Nth program slot 256. CS device 204 can provide different numbers of program slots. Each program slot corresponds to a computing engine configured to execute an application loaded into the corresponding program slot. CS device 204 includes a first computing engine 258 corresponding to the first program slot 250, a second computing engine 260 corresponding to the second program slot 252, a third computing engine 262 corresponding to the third program slot 254, and an Mth computing engine 264 corresponding to the Nth program slot 256. It should be noted that there may not be a one-to-one correspondence between program slots and computing engines. Each computing engine is configured to execute an application(s) in a corresponding program slot(s). Computing engines 258, 260, 262, and 264 can be provided by one or more processors (e.g., processing device 118) of CS device 204. Computing engines 258, 260, 262, and 264 correspond to abstractions of one or more processors.

[0052] CS device 204 also includes a first memory region 266, a second memory region 268, and an Lth memory region 270. In other examples, CS device 204 may include a different number of memory regions. Memory regions 266, 268, and 270 may correspond to physical or virtual regions of the memory (e.g., memory 116) of CS device 204.

[0053] CS device 204 also includes namespace 272. The namespace may correspond to an addressable region of a storage medium (e.g., storage medium 120) (such as an SSD). CS device 204 may support different numbers of namespaces as shown.

[0054] The CS device 204 also includes a direct memory access (DMA) engine 240, which is configured to retrieve data from the host 202 and write the data to memory regions 266, 268, 270 and namespace 272 (e.g., in response to CS commands from applications 210, 212, 214).

[0055] CS device 204 can load applications into program slots 250, 252, 254, and 256 in response to CS commands from applications 210, 212, and 214. Furthermore, computing engines 258, 260, 262, and 264 can execute applications in program slots 250, 252, 254, and 256 using parameters defined by the CS commands from applications 210, 212, and 214. Such parameters may include the memory address targeted by the CS command. The disclosed system 200 provides a mechanism to prevent CS commands from different applications (e.g., different tenants of system 200) from accessing the same resources.

[0056] In the illustrative example, host 202 stores a CS library 216 (e.g., library 112) in memory (e.g., memory 108). The CS library 216 includes a session management API 218, a wrapper API 220, and a memory API 222. In some implementations, APIs 218, 220, and 222 may be combined into fewer APIs. The session management API 218 may be configured to create a session / session context and generate associated session information (e.g., session token, session ID, random number, resource set ID, other information, or a combination thereof) in response to a request from an application executing at host 202. For example, in response to a request from applications 210, 212, and 214, the session management API 218 may generate a session context for each of applications 210, 212, and 214 and store the session context data (e.g., in memory 108). Each session context may include a session token that identifies the session context (e.g., and the associated application). Furthermore, in some implementations, each session context can support more than one session (e.g., an application can open more than one communication session within a session context). For each session in a session context, the session management API can create a session ID, a next random number, and a random number generator (e.g., a seed value).

[0057] The wrapper API 220 can be configured to add session information to incoming CS requests from applications 210, 212, and 214. This session information may have been previously generated by the session management API 218 and stored (e.g., in memory 108) in response to a session creation request from an application. For example, the wrapper API 220 can be configured to add a session token corresponding to the application making the request. Furthermore, the wrapper API 220 can be configured to add the session ID and the next random number.

[0058] Memory API 222 can be configured to receive requests from applications 210, 212, and 214 to allocate memory for CS device 204, forward the requests to CS device 204, and return a memory range object to applications 210, 212, and 214. Applications 210, 212, and 214 can use the memory range object and offset in CS commands to address the memory of CS device 204. The memory range object may include the memory range ID of the memory range and the size of the memory range (e.g., in bytes, kilobytes, pages, etc.). Figure 2A Example memory-range object 246 is shown. In some implementations, the request to allocate memory is processed by wrapper API 220 before being received at memory API 222.

[0059] Host 202 also provides (e.g., by executing CS management core instructions 110 at processor 106) a CS session management core 208. In some embodiments, the CS session management core 208 includes an FPGA core, processor-executable software, or a combination thereof. The CS session management core 208 is configured to determine whether to authorize a CS request based on session information included in the CS request and stored session information. In the example shown, the CS session management core 208 stores (e.g., in memory 108) data associated with a first session context 226 associated with application A 210, a second session context 228 associated with application B 212, and a third session context 230 associated with application C 214.

[0060] The first session context 226 includes a session token 232 and information associated with several sessions. A first session ID 234 for the first session is associated with a first next random number 236 and a first random number generator 238. For a CS request (or memory allocation request) received from an application, the CS session management core 208 can be configured to determine whether the session token matches a stored session token for that application. For example, in response to a CS request from application A 210, the CS session management core can determine whether the session token in the CS request matches the session token 232 in the first session context 226 associated with application A 210. In response to determining a mismatch between tokens, the CS session management core can determine that the CS command can be determined as unauthorized. Furthermore, the CS session management core 208 can determine whether the session ID included in the CS command is included in the first session context 226. If not, the CS command can be determined as unauthorized. In response to determining that the session ID is included in the first session context 226, the CS session management core 208 can determine whether the random number included in the CS command matches the expected next random number for the session ID. In response to a mismatch between random numbers, a CS command can be determined to be unauthorized. In response to determining that the CS device's session token, session ID, random number, or a combination thereof matches a stored value, the CS session management core 208 can determine that the CS command is authorized. In response to determining that the CS command is authorized, the CS session management core 208 can add a resource set ID to the CS command and send the CS command to the CS device 204. The resource set ID can correspond to a session or session context. The CS device 204 can use the resource set ID to determine which resources are valid for the CS command. Because each session context / session is associated with an application, selectively adding a resource set ID to authorized commands based on the session context / session can prevent applications from accessing resources of another application at the CS device.

[0061] In some implementations, the CS session management core 208 is also configured to update the next random number for the session ID based on a stored random number generator in response to receiving an authorized command from the session ID. For example, in response to determining that a command for the first session ID 234 in the first session context 226 has been authorized, the CS session management core 208 can use the first random number generator 238 to generate a new next random number to replace the first next random number 236 used for the first session ID 234. Updating the random number for the session ID in this way can prevent successful “replay” attacks (where a malicious application attempts to repeat session information from a previously authorized CS command).

[0062] Referring back to CS device 204, CS device 204 provides a CS command verification core 242 and a compute resource manager core 244 (e.g., by executing CS command verification instructions 124 and compute resource manager instructions 126 at controller 114). In some embodiments, the CS command verification core 242, the compute resource manager core 244, or a combination thereof includes an FPGA core, processor-executable software, or a combination thereof. The compute resource manager core 244 is configured to respond to memory allocation requests from host 202 (e.g., sent via wrapper API 220 and memory API 222) and maintain a data structure that maps memory-scoped objects to memory-scoped objects for each resource ID. In the example shown, the compute resource manager core 244 maintains a data structure 296 (e.g., a hash table) corresponding to the resource IDs associated with application A 210 and the first session context 226. It should be noted that in alternative examples, the resource IDs may correspond to sessions rather than session contexts (e.g., an application may have more than one associated resource ID). Data structure 296 maps memory range objects (e.g., those of the first session context 226) of application A 210 to memory ranges. In the example shown, memory range 248 is mapped to memory range object 246. A memory range (MR) can be defined as a memory range ID, a memory region ID that includes the memory region of the memory range, an offset within the memory region, and a size. In the example shown, the first memory region 266 includes a first memory range 276 assigned to application C 214 (e.g., a resource set ID assigned to the session context corresponding to application C), a fifth memory range 278 and a sixth memory range 280 assigned to application B 212, and an eighth memory range 282 assigned to application A 210. The second memory region 268 includes a second memory range 284 and a third memory range 286 assigned to application C 214, and a ninth memory range 288 assigned to application A 210. The Lth memory region 270 includes a tenth memory range 290 allocated to application A 210, a fourth memory range 292 allocated to application C 214, and a seventh memory range 294 allocated to application B 212. Therefore, data structure 296 may include entries mapped as follows: memory range ID to eighth memory range 282, memory range ID to ninth memory range 288, and memory range ID to tenth memory range 290.

[0063] A memory region can be defined as {memory region ID, size}. A memory region ID can be defined as memory type | memory region number. Memory types can include controller memory buffers, permanent memory regions, device local memory (DLM), etc. A memory range can be defined as {memory region ID, page offset within the memory region, page count}. In some implementations, the memory range ID is a 16-bit ID, but other implementations can have memory range IDs of different sizes. A memory range object can be {memory range ID, size}.

[0064] In response to a request to allocate memory, compute resource manager core 244 can identify an available range in one of memory regions 266, 268, and 270, generate a corresponding memory range object, and store the mapping from memory range object to range in a data structure of the resource ID indicated by the memory allocation request. Compute resource manager core 244 is configured to return a memory range object (e.g., memory range object 246) to host 202. Host 202's memory API 222 is configured to report the memory range object back to the requesting application, which can then use the memory range object in CS commands to address memory in CS device 204.

[0065] CS command verification core 242 is configured to determine whether a received CS command is valid. CS command verification core 242 can determine the validity of a CS command based on a resource set ID (e.g., added to the CS command by CS session management core 208), a data structure maintained by compute resource management core 244, a memory range object indicated by the CS command, a memory size indicated by the CS command, an offset indicated by the CS command, or a combination thereof. For example, a received CS command may indicate a resource set ID and an operation to be performed based on a portion of memory at an offset within a memory range associated with a memory range object ID and having a specific size. CS command verification core 242 can retrieve a data structure associated with the resource set ID from compute resource manager 244 to determine whether the data structure includes the memory range object ID. CS command verification core 242 can be configured to determine that a CS command is invalid in response to a data structure not including a reference to the memory range object ID, or in response to determining (e.g., based on an offset and a specific size) that the portion of memory indicated by the CS command falls outside the memory range indicated by the memory range object ID. The CS command verification core 242 can determine that a CS command is valid in response to determining that a memory range object ID is listed in a data structure associated with a resource set ID associated with the CS command and that the portion of memory is within the memory range associated with the memory range object ID. In some embodiments, the CS command verification core 242 is also configured to determine whether another CS command is using a memory range identified by the memory range object ID in the CS command. The CS command verification core 242 can be configured to determine that a CS command is invalid in response to determining that another command is accessing a memory range, or to determine that a CS command is valid in response to determining that a command is not in use. The CS command verification core 242 can maintain a data structure identifying memory ranges in use.

[0066] In response to determining that the CS command is valid, the CS command verification core 242 is configured to translate the memory range ID-based address of the portion of memory indicated by the CS command into a memory region address, and forward the CS command with the translation to one of the computing engines 258, 260, 262, and 264 for execution.

[0067] Therefore, the CS command verification core 242 can prevent CS commands issued by an application from accessing resources (e.g., portions of memory) allocated to other applications (or not allocated).

[0068] In the first example use case, at point 1, application A 210 issues a session management request to session management API 218. In response to the session management request, session management API 218 creates (e.g., in memory 108) a first session context 226. Session management API 218 generates a session token 232 to uniquely identify the first session context 226. Furthermore, session management API 218 generates a first random number generator 238 (e.g., a seed value) and uses the first random number generator 238 to generate a first next random number 236. The first next random number 236 and the first random number generator 238 are stored in the first session context 226.

[0069] At point 2, application A 210 can issue a memory allocation request. In response to the memory allocation request, at point 3, wrapper API 220 can add session token 232, first session ID 234, and first next random number 236 to the memory allocation request and send the memory allocation request to memory API 222. At point 4, memory API 222 can send the memory allocation request to CS session management core 208 for authorization. CS session management core 208 can determine that the memory allocation request is authorized by comparing the session token 232, first session ID 234, first next random number 236, or a combination thereof indicated by the memory allocation request, with values ​​stored in first session context 226. CS session management core can update the first next random number 236 stored in first session context 226 based on first random number generator 238, and in response to determining that the memory allocation request is authorized, send the memory allocation request to CS device 204 having a resource set ID corresponding to first session context 226.

[0070] In response to a memory allocation request, at point 5, compute resource manager core 244 can allocate a tenth memory range 290. The memory allocation request can allocate the tenth memory range 290 based on the size requested in the allocation request, the memory region type requested in the allocation request, or a combination thereof. For example, in response to the Lth memory region 270 corresponding to the memory type requested in the memory allocation request, the tenth memory range 290 can be selected from the Lth memory region 270. Compute resource manager core 244 can store a mapping between memory range IDs of the tenth memory range 290 in data structure 296 and return a memory range object indicating the memory range ID and size of the tenth memory range 290 to memory API 222. Memory API 222 can return the memory range object to application A 210.

[0071] At point 2, application A 210 can issue a CS command to wrapper API 220 targeting a portion of tenth memory range 290. The wrapper API can add a session token 232, a first session ID 234, and an updated random number to the CS command based on the first session context 226. A portion of tenth memory range 290 can be identified by the memory range ID of tenth memory range 290, the offset within the memory range, and the size.

[0072] The CS session management core can determine whether a CS command is authorized by comparing session token 232, first session ID 234, an updated random number, or a combination thereof with data stored in first session context 226. In response to determining that the CS command is authorized, the CS session management core 208 can update the updated random number stored in first session context 226 based on first random number generator 238, add a resource set ID corresponding to first session context 226, and send the CS command to CS device 204. In alternative examples where no matching session context is found for session token 232, first session ID 234 is not found in first session context 226, or the updated random number does not match first session ID 234, the CS session management core 208 can determine that the CS command is not authorized.

[0073] At point 6, the CS command verification core 242 can receive a CS command and determine whether the CS command is valid based on the resource set ID and the memory region ID. For example, the CS command verification core 242 can retrieve a data structure 296 corresponding to the resource set ID indicated in the CS command and determine that the data structure 296 includes the memory region ID of the tenth memory range 290 indicated by the CS command. Furthermore, the CS command verification core 242 can determine that the portion is within the tenth memory range 290 based on the size of the tenth memory range 290 indicated by the data structure 296, the offset indicated by the CS command, and the size indicated by the CS command. Additionally, the CS command verification core 242 can determine that an additional data structure indicates that the tenth memory range 290 is not being used by another CS command. Therefore, the CS command verification core 242 can determine that the CS command is valid. In alternative examples where the tenth memory range 290 is not listed in the data structure 296, the portion falls outside the tenth memory range 290, or the tenth memory range is being used by another CS command, the CS command verification core 242 can determine that the CS command is invalid. In response to determining that the CS command is valid, at point 7, the CS command verification core 242 can translate the address of that portion of the tenth memory range 290 into an address (e.g., offset and size) within the Lth memory region 270, and forward the CS command with the translated address to the first program slot 250 for execution by the first computing engine 258.

[0074] Therefore, system 200 can provide access to the resources of CS device 204. Furthermore, access to resources is managed on a per-session-context basis, thereby preventing applications from accessing the resources of other applications or unallocated resources.

[0075] Figure 3A and Figure 3B Figure 300 depicts a CS command modification occurring within a host (such as host 102 or host 202). As shown, the host maintains the session context 308 of application 302. For example, the session context may be... Figure 2A The session management API 218 is used for creation. In the example shown, session context 308 includes first session 316, second session 318, and Nth session 320. Session management library 304 (e.g., Figure 2A The wrapper API 220 is configured to receive CS requests and add session information (e.g., session token information, session ID information 312, and next random number information 314) to each request. In the example shown, the first request 322 is received as part of the first session 316. Therefore, the session management library 304 inserts the message session token 324, the message session ID 326 associated with the first session 316, and the message current random number 328 associated with the first session 316 into the session context 308.

[0076] The CS session management core 306 (e.g., CS session management core 208) is configured to determine whether the first request 322 is authorized by comparing the actual session token 350 of the session context 308 with the message session token 324, comparing the actual session ID 332 of the first session 316 with the message session ID 326, and comparing the actual current random number 334 associated with the first session 316 with the message current random number 328.

[0077] In response to determining that the first request 322 is authorized, the CS session management core 306 can use the random number generator 336 (e.g., seed value) of the first session 316 to update the next random number information for the first session 316. Furthermore, the CS session management core 306 can encapsulate the first request 322 in a CS command 340 and send the CS command 340, which has a computed resource set ID 342, as part of a message 338 to the CS device. Therefore, the authorized request can be sent along with a resource set ID associated with the application that issued the authorized request. The CS device can use the resource set ID to verify the CS command 340. It should be noted that in some embodiments, each of sessions 316, 318, and 320 may have a unique resource set ID.

[0078] Figure 4Figure 400 illustrates the relationship between memory ranges and memory regions. Figure 400 shows a first memory region 424, a second memory region 426, and a third memory region 428 of the memory of a CS device (e.g., memory 116). Memory regions include memory ranges allocated to one of a first session context 410, a second session context 412, and a third session context 414. The CS device (e.g., compute resource manager core 244) may maintain a data structure (e.g., a hash table) that links associated memory range IDs to memory ranges for each session context. Figure 4 As shown, the association between a memory range ID and a first memory range 422 located in the first memory region 424 is stored in a hash table of the first session context 410. Similarly, the association between a memory range ID and a fourth memory range 430 located in the Lth memory region 428 is stored in a hash table of the first session context. Furthermore, the first session context includes information related to the second and third memory ranges located in the second memory region. The second session context 412 includes information related to the fifth and sixth memory ranges in the first memory region 424 and the seventh memory range in the Lth memory region 428. The third session context 414 includes information related to the eighth memory range in the first memory region 424, the ninth memory range in the second memory region 426, and the tenth memory range in the Lth memory region 428.

[0079] Information stored in the hash table of the session context may include a memory range ID, an associated memory region ID, an offset of the memory range within the memory region, and the size of the memory range. For example, the first session context 410 associated with the first memory range 422 may include first information 408. The first information 408 includes a memory range ID, a memory region ID of the first memory region 424, an offset within the first memory region 424, and the size of the first memory range 422. However, a memory range object 404 representing the first memory range 422 (instead of all the first information 408) may be returned to the host device for addressing the first memory range 422. The memory range object 404 includes the memory range ID of the first memory range 422 and the size of the first memory range 422. Therefore, direct addressing of the memory region by the application can be prevented. Similarly, the hash table of the first session context 410 may store second information 406 related to the fourth memory range 430 (e.g., memory range ID, memory region ID, offset within the memory region, size of the memory range), but returns a memory range object 402 (memory range ID and size) to the host device for addressing the fourth memory range 430.

[0080] Figure 5 This is a flowchart illustrating a method 500 for providing resource isolation in a CS device. In some implementations, method 500 is performed by system 100, system 200, or a combination thereof. Method 500 includes receiving a CS request from an application at 504. For example, CS session management core 208 may receive a CS command (e.g., modified by wrapper API 220) from application A 210.

[0081] Method 500 further includes determining at 506 whether the request is authorized. For example, CS session management core 208 may extract a session token (e.g., message session token), a session ID (e.g., message session ID), and a next random number (e.g., message next random number) from the CS request and compare these values ​​with values ​​stored in the first session context 226 to determine whether the CS request is authorized. CS session management core 208 may determine that the CS request is not authorized in response to determining that the message session token does not match session token 232 of the first session context 226, that the message session ID does not exist in the first session context 226, or that the stored random number associated with the message session ID in the first session context 226 does not match the message next random number. Alternatively, CS session management core 208 may determine that the CS request is authorized in response to determining that the message session token matches session token 232, that the message session ID is located in the first session context 226, and that the next random number identified for the message session ID in the first session context 226 matches the message next random number.

[0082] In response to determining that the CS request was not authorized, method 500 includes outputting an error report at 502. For example, in response to the determination that the CS request was not authorized, the CS session management core 208 can trigger the output of an error report.

[0083] In response to determining that the CS request is authorized, method 500 includes adding a resource set ID to the CS request at 508 and sending the CS request to the CS device, wherein a memory range object is extracted from the CS request. For example, the CS command verification core 242 may extract the memory range object (e.g., memory range ID and size), the offset within the CS range, and the size of the memory access within the memory range from the CS request.

[0084] Method 500 further includes, at 510, determining whether a CS request requests valid access to a memory range based on a per-session context memory range set 512. For example, the CS command verification core 242 can determine whether the memory range ID indicated by the memory range object extracted from the CS request exists in a data structure 296 (e.g., a hash table) of the first session context 226. Data structure 296 can be identified based on a resource ID in the CS request. If the memory range ID is not in data structure 296, the CS request can be determined to be invalid. Furthermore, the CS command verification core 242 can determine whether a requested access to a memory range falls outside the memory range based on the size of the memory range, the offset to the memory range, and the size of the requested access. If the requested access falls outside the memory range, the CS request can be determined to be invalid. For example, a requested access of 8KB starting at offset 0KB within a 4KB memory range could be invalid because the requested access would exceed the boundary of the memory range.

[0085] Method 500 includes, at 522, outputting an error report in response to determining that the CS request is invalid. For example, CS command verification core 242 can return an error message to host 202.

[0086] In response to determining that a CS request requests valid access to a memory range, method 500 includes determining at 514 whether the memory range is being used by another CS command. For example, CS command verification core 242 may maintain a data structure indicating which memory ranges are being used by CS commands. CS command verification core 242 may determine based on this data structure whether the memory range requested by the CS request is in use.

[0087] In response to determining that a memory range is in use, method 500 includes rescheduling the CS request at 520. For example, the CS command verification core 242 can store the CS request in a buffer and re-examine the data structure in use later.

[0088] In response to determining that a memory range is not being used by another CS request, method 500 includes determining at 516 whether the end of the list of memory objects identified by the CS request has been reached. For example, CS command verification core 242 can determine whether the CS request includes a reference to an additional memory object.

[0089] In response to determining that the CS request has not yet reached the end of the list, method 500 returns to 508 and fetches the next memory range object.

[0090] In response to determining that the end of the list has been reached, method 500 includes converting a reference to a memory range into a device-specific memory tag at 518. For example, CS command verification core 242 can convert a reference to a memory range into a reference to a memory region based on information stored in data structure 296. An example of address translation logic includes the following pseudocode: New address tag = {Get-Start-Address Memory-Region(Memory Region ID) + Page Offset * Page Size + Offset, Size}.

[0091] Therefore, method 500 can be used to provide access to CS resources based on session context. Thus, resources can be isolated, and unauthorized access can be prevented.

[0092] refer to Figure 6 The diagram illustrates a method 600 for responding to a memory allocation request. Method 600 can be performed by a CS device such as CS device 104 or CS device 204, or by a host device such as host 102 or host 202.

[0093] Method 600 includes receiving at 602 a request to allocate compute storage to an application on a host device, wherein the request includes a resource set ID associated with the application. For example, compute resource manager core 244 may receive a request to allocate compute storage of CS device 204 to application A 210. The request may include a resource set ID associated with application A 210 (and first session context 226).

[0094] Method 600 also includes identifying a memory range within a memory region of the CS device at 604. For example, compute resource manager core 244 can identify a tenth memory range 290 within the Lth memory region 270. Compute resource manager core 244 can select the Lth compute region 270 to allocate the tenth memory range 290 based on a comparison of the size of available memory in the Lth memory region 270 with the size requested by the request, based on whether the type of the Lth memory region 270 matches the type of memory requested by the request, or a combination thereof.

[0095] Method 600 also includes, at 606, storing in a data structure associated with the resource set ID the association between the memory range ID, the memory region, and the offset within the memory region for the memory range. For example, compute resource manager core 244 may store in data structure 296 the association between the memory range ID of the tenth memory range 290, the size of the tenth memory range 290, and the offset (e.g., position) of the tenth memory range 290 within the Lth memory region 270. Data structure 296 is associated with the resource set ID (e.g., compute resource manager core 244 may maintain a separate data structure for each unique resource set ID).

[0096] Method 600 also includes sending a memory range ID to the host device at 608. For example, Compute Explorer core 244 can return a memory range object to host 202 that identifies a tenth memory range 290 and the size of the tenth memory range 290.

[0097] Therefore, method 600 can be used to manage the allocation of memory ranges on a per-resource-set (e.g., session context) basis. Thus, each application on the host can be allocated its own memory range(s).

[0098] Some CS devices can support a controller memory buffer-style memory model, where memory regions are exposed to the host via PCI configuration register base address registers. In such implementations, the host can manage memory range allocation. In some implementations, the host can simply implement a computing resource management core as described above. Figure 7 In the depicted alternative example, the computational resource management core of system 700 displays physical address descriptors in memory-range objects. In such an example, the CS library (e.g., Figure 1 The library (112) can be modified to map the memory-range address space to the application's virtual address space via the posix mmap() API.

[0099] In some examples, X corresponds to Y based on X matching Y. For example, it can be determined that a first ID corresponds to a second ID that matches the first ID (e.g., has the same value). In other examples, X corresponds to Y based on X being associated with Y (e.g., linked to Y). For example, X can be associated with Y through a mapping data structure.

[0100] Specific embodiments may be implemented as hardware, firmware, and software, or a combination thereof. Other embodiments may also be implemented as instructions stored on a computer-readable storage device that can be read and executed by at least one processor to perform the operations described herein. A computer-readable storage device may include any non-transitory storage mechanism for storing information in a machine-readable (e.g., computer) form. For example, a computer-readable storage device may include read-only memory (ROM), random access memory (RAM), disk storage media, optical storage media, flash memory devices, and other storage devices and media.

[0101] The word "exemplary" is used herein to mean "serving as an example, instance, or illustration." Any embodiment described herein as "exemplary" is not necessarily to be construed as being more preferred or advantageous than other embodiments. As used herein, the terms "computing device," "user equipment," "communication station," "station," "handheld device," "mobile device," "wireless device," and "user equipment" (UE) refer to wireless communication devices such as cellular phones, smartphones, tablets, netbooks, wireless terminals, laptops, femtocells, high data rate (HDR) subscriber stations, access points, printers, point-of-sale equipment, access terminals, or other personal communication system (PCS) devices. Devices can be mobile or fixed.

[0102] As used herein, the term "communication" is intended to include sending, or receiving, or both. This may be particularly useful in the claims when describing an organization of data sent by one device and received by another device, but requiring only the functionality of one of these devices would infringe the claim. Similarly, a bidirectional data exchange between two devices (during which both devices send and receive) can be described as "communication," in which case only the functionality of one of these devices is required. The term "communication" as used herein with respect to wireless communication signals includes sending and / or receiving wireless communication signals. For example, a wireless communication unit capable of communicating wireless communication signals may include a wireless transmitter that sends wireless communication signals to at least one other wireless communication unit, and / or a wireless communication receiver that receives wireless communication signals from at least one other wireless communication unit.

[0103] Some embodiments can be used with a variety of devices and systems, such as personal computers (PCs), desktop computers, mobile computers, laptop computers, notebook computers, tablet computers, server computers, handheld computers, handheld devices, personal digital assistant (PDA) devices, handheld PDA devices, in-vehicle devices, non-in-vehicle devices, hybrid devices, vehicle devices, non-vehicle devices, mobile or portable devices, consumer devices, non-mobile or non-portable devices, wireless communication stations, wireless communication devices, wireless access points (APs), wired or wireless routers, wired or wireless modems, video devices, audio devices, audio-video (A / V) devices, wired or wireless networks, wireless local area networks, wireless video local area networks (WVANs), local area networks (LANs), wireless LANs (WLANs), personal area networks (PANs), wireless PANs (WPANs), etc.

[0104] Some embodiments may be compatible with one-way and / or two-way radio communication systems, cellular wireless telephone communication systems, mobile phones, cell phones, wireless phones, personal communication system (PCS) devices, PDA devices that include wireless communication devices, mobile or portable global positioning system (GPS) devices, devices that include GPS receivers or transceivers or chips, devices that include radio frequency identification (RFID) elements or chips, multiple-input multiple-output (MIMO) transceivers or devices, single-input multiple-output (SIMO) transceivers or devices, multiple-input single-output (MISO) transceivers or devices, devices with one or more internal antennas and / or external antennas, digital video broadcasting (DVB) devices or systems, multi-standard wireless devices or systems, wired or wireless handheld devices such as smartphones, Wireless Application Protocol (WAP) devices, etc.

[0105] Some embodiments can be used in conjunction with one or more types of wireless communication signals and / or systems that comply with one or more wireless communication protocols, such as radio frequency (RF), infrared (IR), frequency division multiplexing (FDM), orthogonal FDM (OFDM), time division multiplexing (TDM), time division multiple access (TDMA), extended TDMA (E-TDMA), General Packet Radio Service (GPRS), extended GPRS, code division multiple access (CDMA), wideband CDMA (WCDMA), CDMA 2000, single-carrier CDMA, multi-carrier CDMA, multi-carrier modulation (MDM), discrete multi-tone (DMT), Bluetooth™, Global Positioning System (GPS), Wi-Fi, Wi-Max, ZigBee™, ultra-wideband (UWB), Global System for Mobile Communications (GSM), 2G, 2.5G, 3G, 3.5G, 4G, fifth-generation (5G) mobile networks, 3GPP, Long Term Evolution (LTE), LTE Advanced, Enhanced Data Rate GSM Evolution (EDGE), etc. Other embodiments can be used in a variety of other devices, systems, and / or networks.

[0106] Although an example processing system has been described above, embodiments of the subject matter and functional operation described herein may be implemented in other types of digital electronic circuits, or in computer software, firmware, or hardware (including the structures disclosed in this specification and their structural equivalents), or in a combination of one or more of them.

[0107] The embodiments of the subject matter and operation described herein can be implemented in digital electronic circuits, or in computer software, firmware, or hardware (including the structures disclosed herein and their equivalents), or in a combination of one or more of these. Embodiments of the subject matter described herein can be implemented as one or more computer programs, i.e., one or more components of computer program instructions encoded on a computer storage medium for execution by or control of an information / data processing apparatus. Alternatively or additionally, program instructions can be encoded on artificially generated propagating signals, such as machine-generated electrical, optical, or electromagnetic signals, generated to encode information / data for transmission to a suitable receiver device for execution by the information / data processing apparatus. The computer storage medium can be or is included in a computer-readable storage device, a computer-readable storage substrate, a random or serial access memory array or device, or a combination of one or more of these. Furthermore, while the computer storage medium is not a propagating signal, it can be a source or destination of computer program instructions encoded in artificially generated propagating signals. The computer storage medium can also be or be included in one or more separate physical components or media (e.g., multiple CDs, discs, or other storage devices).

[0108] The operations described herein can be implemented as operations performed by an information / data processing device on information / data stored on one or more computer-readable storage devices or received from other sources.

[0109] The term "data processing apparatus" encompasses all kinds of devices, apparatuses, and machines used for processing data, including, for example, programmable processors, computers, systems-on-a-chip, or a combination thereof. Apparatus may include special-purpose logic circuitry, such as FPGAs (Field-Programmable Gate Arrays) or ASICs (Application-Specific Integrated Circuits). In addition to hardware, apparatus may also include code that creates an execution environment for the computer program in question, such as code constituting processor firmware, protocol stacks, database management systems, operating systems, cross-platform runtime environments, virtual machines, or combinations thereof. Apparatus and execution environments can implement a variety of different computing model infrastructures, such as web services, distributed computing, and grid computing infrastructures.

[0110] Computer programs (also known as programs, software, software applications, scripts, or code) can be written in any programming language, including compiled or interpreted languages, declarative or procedural languages, and can be deployed in any form, including as standalone programs or as components, parts, subroutines, objects, or other units suited to a computing environment. A computer program may, but does not need to, correspond to a file in a file system. A program may be stored in a portion of a file that holds other programs or information / data (e.g., one or more scripts stored in a markup language document), in a single file dedicated to the program in question, or in multiple collaborative files (e.g., a file storing one or more components, subroutines, or code portions). A computer program can be deployed to execute on a single computer or on multiple computers located in one place or distributed across multiple locations and interconnected through a communication network.

[0111] The processes and logical flows described herein can be executed by one or more programmable processors, which execute one or more computer programs to perform actions by manipulating input information / data and generating output. For example, processors suitable for executing computer programs include general-purpose and special-purpose microprocessors, as well as any one or more processors of any kind of digital computer. Typically, the processor receives instructions and information / data from read-only memory or random access memory, or both. The basic components of a computer are a processor for performing actions according to instructions and one or more memory devices for storing instructions and data. Typically, a computer will also include, or be operatively coupled to, one or more mass storage devices for storing data, such as magnetic disks, magneto-optical disks, or optical disks, to receive information / data from or to which information / data is transferred, or both. However, a computer does not need to have such devices. Devices suitable for storing computer program instructions and information / data include all forms of non-volatile memory, media, and memory devices, including, for example, semiconductor memory devices such as EPROM, EEPROM, and flash memory devices; magnetic disks, such as internal hard disks or removable disks; magneto-optical disks; and CD-ROM and DVD-ROM discs. The processor and memory can be supplemented or incorporated therein by dedicated logic circuitry.

[0112] To provide interaction with the user, embodiments of the subject matter described herein can be implemented on a computer having a display device for displaying information / data to the user, such as a CRT (cathode ray tube) or LCD (liquid crystal display) monitor, and a keyboard and pointing device, such as a mouse or trackball, that the user can use to provide input to the computer. Other types of devices can also be used to provide interaction with the user; for example, feedback provided to the user can be any form of sensory feedback, such as visual, auditory, or tactile feedback; and input from the user can be received in any form, including sound, speech, or tactile input. Furthermore, the computer can interact with the user by sending documents to and receiving documents from the device used by the user; for example, by sending a web page to a web browser on the user's client device in response to a request received from a web browser.

[0113] Embodiments of the subject matter described herein can be implemented in a computing system that includes backend components (e.g., as an information / data server), or middleware components (e.g., an application server), or frontend components (e.g., a client computer with a graphical user interface or web browser through which a user can interact with embodiments of the subject matter described herein), or any combination of one or more such backend, middleware, or frontend components. The components of the system can be interconnected via digital information / data communication (e.g., a communication network) of any form or medium. Examples of communication networks include local area networks (“LANs”) and wide area networks (“WANs”), the Internet (e.g., the Internet), and peer-to-peer networks (e.g., self-organizing peer-to-peer networks).

[0114] A computing system may include clients and servers. Clients and servers are typically geographically separated and usually interact via a communication network. The client-server relationship arises from computer programs running on their respective computers and having a client-server relationship with each other. In some embodiments, the server transmits information / data (e.g., HTML pages) to the client device (e.g., to display information / data to a user interacting with the client device and to receive user input from that user). Information / data generated at the client device (e.g., the result of user interaction) can be received from the client device at the server.

[0115] While this specification contains numerous details of specific embodiments, these details should not be construed as limiting the scope of any embodiment or the scope that may be claimed, but rather as descriptions of features specific to particular embodiments. Specific features described in the context of a single embodiment may also be implemented in combination in that single embodiment. Conversely, various features described in the context of a single embodiment may also be implemented individually or in any suitable sub-combination in multiple embodiments. Furthermore, although features may be described above as functioning in a particular combination, and even initially claimed in this way, one or more features from a claimed combination may be removed from the combination in some cases, and the claimed combination may be for sub-combinations or variations thereof.

[0116] Similarly, although the operations are depicted in a specific order in the accompanying drawings, this should not be construed as requiring these operations to be performed in the specific or sequential order shown, or requiring all shown operations to be performed to obtain the desired result. In certain situations, multitasking and parallel processing may be advantageous. Furthermore, the separation of various system components in the above embodiments should not be construed as requiring such separation in all embodiments, and it should be understood that the described program components and systems can generally be integrated together in a single software product or packaged into multiple software products.

[0117] Therefore, specific embodiments of the subject matter have been described. Other embodiments are within the scope of the appended claims. In some cases, the actions described in the claims can be performed in a different order and the desired result can still be obtained. Furthermore, the processes depicted in the drawings do not necessarily require the specific or sequential order shown to obtain the desired result. In certain embodiments, multitasking and parallel processing may be advantageous.

[0118] Benefiting from the teachings presented in the foregoing description and the accompanying drawings, those skilled in the art will conceive of many modifications and other embodiments of the present disclosure set forth herein. Therefore, it should be understood that the embodiments are not limited to the specific embodiments disclosed, and that modifications and other embodiments are intended to be included within the scope of the appended claims. Although specific terminology is used herein, it is used only in a general and descriptive sense and not for limiting purposes.

Claims

1. A method for resource isolation, comprising: The controller of the compute storage CS device receives a request to allocate compute storage to an application on the host device, wherein the request includes a resource set identifier ID associated with the application; Identify the memory range within the memory region of the CS device; The association between the memory range ID, the memory region, and the offset within the memory region is stored in a data structure associated with the resource set ID; The memory range ID is sent to the host device, wherein the application is also associated with a second resource set ID, which is associated with the second memory range ID. Receive a CS command including the resource set ID and the requested memory range ID; and The validity of the CS command is partly determined based on whether the data structure associated with the resource set ID includes the requested memory range ID.

2. The method according to claim 1, wherein, Determining whether the CS command is valid further includes, in response to determining that the requested memory range ID corresponds to a memory range ID of the memory range, determining whether a second offset relative to the memory range and the access size of the CS command exceeds the boundary of the memory range.

3. The method of claim 2, further comprising, in response to determining that the CS command is valid, converting the second offset into a third offset within the memory region of the CS device based on the data structure.

4. The method of claim 1, further comprising returning an error report to the host device in response to determining that the CS command is invalid.

5. The method of claim 1, further comprising determining whether the requested memory range corresponding to the requested memory range ID is being used by another CS command.

6. The method of claim 5, further comprising rescheduling the execution of the CS command in response to determining that the requested memory range is in use.

7. The method of claim 1, further comprising selecting the memory range from the memory region based on the memory region corresponding to the memory type indicated by the request for allocating computational storage.

8. A computing storage (CS) device, comprising: Memory; and The controller is configured as follows: Receive a request to allocate compute storage to an application on a host device, wherein the request includes a resource set identifier ID associated with the application; Identify the memory range within the memory region of the memory; The association between the memory range ID, the memory region, and the offset within the memory region is stored in a data structure associated with the resource set ID; The memory range ID is sent to the host device, wherein the application is also associated with a second resource set ID, which is associated with the second memory range ID. Receive a CS command including the resource set ID and the requested memory range ID; and The validity of the CS command is partly determined based on whether the data structure associated with the resource set ID includes the requested memory range ID.

9. The CS device according to claim 8, wherein, Determining whether the CS command is valid further includes: in response to determining that the requested memory range ID corresponds to a memory range ID of the memory range, determining whether a second offset relative to the memory range and the access size of the CS command exceeds the boundary of the memory range.

10. The CS device according to claim 9, wherein, The controller is also configured to, in response to determining that the CS command is valid, convert the second offset into a third offset within the memory region of the CS device based on the data structure.

11. The CS device according to claim 8, wherein, The controller is also configured to return an error report to the host device in response to determining that the CS command is invalid.

12. The CS device according to claim 8, wherein, The controller is also configured to determine whether the requested memory range corresponding to the requested memory range ID is being used by another CS command.

13. The CS device according to claim 12, wherein, The controller is also configured to reschedule the execution of the CS command in response to determining that the requested memory range is in use.

14. The CS device according to claim 8, wherein, The data structure includes a hash table.

15. The CS device according to claim 8, wherein, The controller is also configured to send the size of the memory range to the host device.

16. A system for resource isolation, comprising: The host device is configured as follows: The storage identifies the session context of the application executing on the host device, and the session context is associated with a resource set identifier ID; In response to receiving a request from the application to allocate computing storage, the resource set ID is inserted into the request; and Computational storage devices, including: Memory; and The controller is configured as follows: Receive the request to allocate computing storage; Identify the memory range within the memory region of the memory; The memory range ID, the memory region, and the offset within the memory region are stored in a data structure associated with the resource set ID; the memory range ID is sent to the host device; wherein the application is also associated with a second resource set ID, which is associated with a second memory range ID; Receive a CS command including the resource set ID and the requested memory range ID; and The validity of the CS command is partly determined based on whether the data structure associated with the resource set ID includes the requested memory range ID.

17. The system according to claim 16, wherein, The request to allocate computational storage is associated with a session ID and a random number, and the host device is further configured to determine whether the session ID and the random number match an expected session ID and an expected random number associated with the session context.

18. The system according to claim 17, wherein, The host device is also configured to store an updated expected random number associated with the session ID.

Images