Pairing system and pairing method of multi-device

Matching identification mechanism of field programmable gate array and solid state hard disk in a multi-component environment

MECHANISM TO IDENTIFY FPGA AND SSD PAIRING IN A MULTI-DEVICE ENVIRONMENT

The inventive concept generally relates to computer systems, and more specifically, to systems including storage devices and auxiliary processors.<br></br><br></br>[Cross reference of related applications]

This application is a partial continuation application of U.S. Patent Application No. 16/260,087 filed on January 28, 2019. The application is a partial continuation application of U.S. Patent Application No. 16/226,629 filed on December 19, 2018. The above application is a continuation of the U.S. Patent Application No. 16/207,080 filed on November 30, 2018. The application requires the rights and interests of U.S. Provisional Patent Application No. 62/745,261 filed on October 12, 2018. All of the above applications It is incorporated herein by reference for all purposes.

This application claims the benefits of U.S. Provisional Patent Application No. 62/733,077 filed on September 18, 2018 and U.S. Provisional Patent Application No. 62/818,096 filed on March 13, 2019, both of which are for all purposes Incorporated into this article by reference

For appearance size, power, density, and performance benefits, Field Programmable Gate Array (FPGA) and Solid State Drive (SSD) sub-devices are usually (but not always) packaged in a device housing middle. FPGA and SSD appear as independent physical functions (PF) in the Peripheral Component Interconnect (PCI) view of the host. FPGA and SSD sub-devices are also clustered on independent input/output (Input/Output; I/O) stacks (specifically, storage devices and OpenCL) that do not have a mutual relationship.

The appearance and size of both FPGA and SSD devices will show three physical functions (PF): data PF (also called user space PF), management PF, and non-volatile memory express (Non-Volatile Memory Express; NVMe) PF . The first two PFs are used for FPGA; the third PF is used for SSD.

In the case where the machine contains only one FPGA/SSD pair, independent PF is not a problem for pair recognition (for example, in an x86 host server). But when (again, for example in a densely populated x86 host server) there is more than one device, there is no indication of which FPGA is paired with which SSD. When PCIe pass-through is enabled and multi-function devices appear as multiple single-function devices, the problem in a virtualized environment becomes more serious.

Peer-to-peer (P2P) computing requires pairing to run correctly. In the case of mismatching, p2p will fail, because the data can be loaded into the wrong FPGA device environment, resulting in the hardware core not having the correct data. The problem becomes serious when the host user cannot identify the application in the pairing requirement.

It is still necessary to establish a pairing between FPGA and other auxiliary processors and storage devices (such as SSD).

The system according to the disclosed embodiment of the present invention includes a solid-state drive including a first storage device for data, a second storage device for a unique solid-state drive identifier, and a third storage device for a unique auxiliary processor identifier Auxiliary processor, including a fourth storage device for the unique auxiliary processor identifier and a fifth storage device for the unique solid-state drive identifier; and a hardware interface located between the solid-state drive and the Between auxiliary processors.

Reference will now be made in detail to embodiments of the inventive concept, and examples of the embodiments are illustrated in the accompanying drawings. In the following detailed description, numerous specific details are set forth to achieve a thorough understanding of the concept of the present invention. However, it should be understood that those of ordinary skill in the art can practice the inventive concept without these specific details. In other cases, well-known methods, procedures, components, circuits, and networks are not described in detail, so as not to unnecessarily obscure aspects of the embodiments.

It should be understood that although the terms "first", "second", etc. may be used herein to describe various elements, these elements should not be limited by these terms. These terms are only used to distinguish one element from another element. For example, without departing from the concept of the present invention, the first module may be referred to as the second module, and similarly, the second module may be referred to as the first module.

The terms used in the description of the concept of the present invention herein are only for the purpose of describing specific embodiments and are not intended to limit the concept of the present invention. Unless the context clearly indicates otherwise, as used in the description of the concept of the present invention and the scope of the appended invention application, the singular forms "a/an" and "the" are intended to also include plural forms. It will also be understood that the term "and/or" as used herein refers to and encompasses any and all possible combinations of one or more of the associated listed items. It should be further understood that when used in this specification, the term "comprises/comprising" designates the presence of the stated features, integers, steps, operations, elements and/or components, but does not exclude the presence or addition of one or more Other features, integers, steps, operations, elements, components, and/or groups thereof. The elements and features in the drawings are not necessarily drawn to scale.

When more than one solid-state drive (SSD)/field programmable gate array (FPGA) device pair is available on the same server, there is a host application user can choose between the peer buffer and the SSD on two separate such pairs possibility. This choice will cause data corruption and incorrect acceleration results. SSD/FPGA pairing shows three physical functions (PF): data PF (also called user space) (for FPGA), management PF (for FPGA), and non-volatile storage fast (NVMe) PF (for SSD) ). If all three PFs are based on the same device, this problem can be alleviated. However, using the Xilinx 3-port switch design approach, FPGA and SSD can be displayed as independent devices that do not have details about their physical associations. (Xilinx is a registered trademark of Xilinx Corporation). The problem becomes more complicated due to the OpenCL software interface that Xilinx displays to its applications. The software interface virtualizes the bus/device/function (BDF) details and uses logical numbers (such as 0, 1, 2, etc.) to represent each FPGA device. This additional indirection at the software level completely obfuscates the pairing associations that can be deduced previously at the peripheral component connection (PCI) BDF level. Application or user must understand PCI Multi-function device association at BDF level, Xilinx drive internal and file system level mapping complexity.

This arrangement is error-prone and itself shows different problems based on the environment used. For the user, since the peer-to-peer request can still be successful, the debugging of this arrangement can also be cumbersome.

Densely clustered system

In the above situation, it is desirable that all devices are located under the same root complex. However, systems with densely clustered SSD/FPGA devices may need to use more than one PCI Express (PCI Express; PCIe) switch configured according to each root complex connected to each CPU socket. Utilizing the different support of Access Control Service (ACS) and CPU/chipsets that can be used in virtualized environments, peer-to-peer is not uniformly supported, which increases the burden for application users to understand these nuances in the topology.

The p2p transmission from SSD to P2P dial on demand routing (DDR) may fail because it may not be supported. This result is caused by the fact that there is no need for the PCI root complex to support packet forwarding between root ports. In practice, this design choice is beneficial to the p2p usage rate in the storage acceleration environment, but it is not good for the user experience.

Dense SSD/FPGA deployment can have any Intel/AMD solution built in by various system vendors, and there may be limited or no control over how the system will interact. This fact can create complexity for what works and what does not work.

PCI pass-through in a virtualized environment

In some Linux virtualization environments, multi-function devices (such as SSD/FPGA devices) can appear as independent single-function devices for each physical function when they are mapped to virtual machines (Virtual Machine; VM) with pass-through attributes. Therefore, the three PFs displayed between the SSD and FPGA can be mapped to three single-function devices that do not have an association between them.

Users without PCI knowledge

In addition to the above, application users may not understand the BDF association. This fact may be due to the fact that the user is an advanced application user who does not need to be educated with this level of system details. This kind of problem exposure may require high-level abstractions to resolve this knowledge gap.

Proposed solution

By providing near storage acceleration and distinguishing itself from other standalone SSDs and FPGAs, SSD/FPGA devices can be regarded as a new category of SSD devices. The new device may need a clear way to identify itself, that is, is it an FPGA with near storage or an NVMe SSD with near acceleration? Solutions can include:

Low-level device interface changes, including: the private hardware interface category between FPGA and SSD, System Management Bus (SMBus), used for shared features; minor updates of NVMe SSD firmware, used to adapt to acceleration properties ; And the update to the FPGA firmware, used to query the SSD and notify the SSD to identify the pairing attributes.

Advanced software interface changes include: FPGA interface, which can query low-level matching details, display new features of NVMe recognition controller to existing software paths, and enhance the manageability of software modules to query FPGA and SSD for matching.

The API is enabled for the adoption of the ecosystem, including application interface calls that can be matched by device name, file name, etc.

These changes should be small enough to keep the NVMe SSD as generic as needed. For example, the existing NVMe SSD can be reprogrammed to adapt it as an SSD to SSD/FPGA devices.

Change NVMe SSD to pair with FPGA

Minor hardware changes allow FPGA and SSD to talk to each other.

The SSD controller can support two SMBus main interfaces (see Figure 7 to Figure 8 and the accompanying text below for illustration and discussion). An SMBus main interface can be connected to an external SMBus (out-of-band (OOB)) through a connector from a board management controller (Board Management Controller; BMC) or such a management entity. The second SMBus master port on the SSD can be connected to the slave SMBus port or the master SMBus port on the FPGA device. Out-of-band (OOB) SMBus interface can be used to implement management protocols, such as NVMe Management Interface (NMVe-MI). The internal SMBus interface between the SSD controller and FPGA can be used exclusively for communication between these two devices. The SSD controller firmware can query the FPGA device for its unique identification information. This interface can also be used for the configuration and status of the FPGA device, and the SSD controller monitors the FPGA device according to the guidance of the BMC or the host. When the host or BMC uses a management protocol (such as NVMe-MI of the SSD controller) to query the FPGA identification information, the SSD controller can extract the required information from the FPGA and return the information to the host or BMC.

The SSD controller can use a message-based protocol to communicate with the FPGA device. The SSD controller can write various command messages to the slave SMBus port of the FPGA, and then poll for response availability. When the FPGA response message is ready, the SSD controller reads the response message. When the FPGA needs the attention of the SSD controller, the FPGA can set a flag to be polled periodically by the SSD controller.

The minor changes to the SSD firmware can support the above hardware settings. The completion of the PCIe device initialization first occurs in the embedded operating system (O/S) environment in the multi-function device. Later, the multifunction device is initialized again in the x86 host environment.

As part of the PCIe init phase, the software component (firmware in the SSD device) can query and discover the local device and attached device of the multi-function device. After the initialization of the NVMe SSD and FPGA components is completed, the software component can query the FPGA for its device details, which provide a unique serial number and product part number. These details can be written to the SSD register at a private offset in the NVMe base address register (BAR) space of its memory mapping. After resetting but before adapting PCI configuration access to this update, the write window can be made available by the SSD firmware. This keeps the update internal and within the control of the embedded O/S.

The NVMe specification limits the ability to identify controllers and namespace commands to discover NVMe SSDs. As part of these capabilities, the controller can define the following to announce its acceleration capabilities.

Table 1: Identify the controller data structure<br></br><tables><table border="1" bordercolor="#000000" width="85%"><tbody><tr><td><b>Byte</b><br></br></td><td><b>Optional</b><b>/</b><b>required</b><br></br></td><td><b>describe</b><br></br></td></tr><tr><td>4095:4031<br></br></td><td>O (vendor-specific)<br></br></td><td>Acceleration<br></br></td></tr></tbody></table></tables>

Table 2: Extended characteristics<br></br><tables><table border="1" bordercolor="#000000" width="85%"><tbody><tr><td><b>Byte</b><br></br></td><td><b>Types of</b><br></br></td><td><b>Reset</b><br></br></td><td><b>describe</b><br></br></td></tr><tr><td>3:0<br></br></td><td>RO<br></br></td><td>0h<br></br></td><td>Supplier signature<br></br></td></tr><tr><td>4<br></br></td><td>RO<br></br></td><td>1h<br></br></td><td>Existing extended features<br></br></td></tr><tr><td>6:5<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Calculation type: FPGA<br></br></td></tr><tr><td>10:7<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Device count, dedicated/shared, enabled<br></br></td></tr><tr><td>12:11<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Calculation type: cpu-ARM<br></br></td></tr><tr><td>16:13<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Device count, dedicated/shared, enabled<br></br></td></tr></tbody></table></tables>

Table 3: Acceleration capacity<br></br><tables><table border="1" bordercolor="#000000" width="85%"><tbody><tr><td><b>Byte</b><br></br></td><td><b>Types of</b><br></br></td><td><b>Reset</b><br></br></td><td><b>describe</b><br></br></td></tr><tr><td>3:0<br></br></td><td>RO<br></br></td><td>0h<br></br></td><td>Supplier signature<br></br></td></tr><tr><td>4<br></br></td><td>RO<br></br></td><td>1h<br></br></td><td>The acceleration device is enabled and available<br></br></td></tr><tr><td>6:5<br></br></td><td>RO<br></br></td><td>100h<br></br></td><td>Major version, minor version<br></br></td></tr><tr><td>7<br></br></td><td>RO<br></br></td><td>1h<br></br></td><td>Current state<br></br></td></tr><tr><td>9:8<br></br></td><td>RO<br></br></td><td>0h<br></br></td><td>Reserve<br></br></td></tr><tr><td>25:10<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Accelerated part number as reported in FPGA VPD details<br></br></td></tr><tr><td>29:26<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Component supplier ID, device ID<br></br></td></tr><tr><td>33:30<br></br></td><td>RO<br></br></td><td>Imp. Proprietary<br></br></td><td>Acceleration feature 1 (TBD)<br></br></td></tr><tr><td>63:34<br></br></td><td>RO<br></br></td><td>0h<br></br></td><td>Reserve<br></br></td></tr></tbody></table></tables>

Change FPGA to notify SSD device pairing

Similar to NVMe SSD, FPGA can be programmed by embedded O/S components with unique SSD details. These details can be used by the x86 host software components through the interface.

Embedded O/S components for pairing

The software component (also the firmware in the SSD) can query and discover the local device and attached device of the multi-function device. After the initialization of the NVMe SSD and FPGA components is completed, the software component can query the FPGA for its device details, which provide a unique serial number and product part number. These details can be written to the SSD register at a private offset in the NVMe BAR space of its memory mapping. Similarly, software components can be programmed with unique SSD details to program the FPGA so that it can be paired with each other.

Sample enumeration for power-up/retiming on SMBus

1. FPGA sends NVMe (read recognition controller) to SSD

2. SSD responds with identification data

3. FPGA save serial number, model details

4. FPGA sends out NVMe (setting identification data-offset extension feature-vendor-specific 3072 bytes to 4095 bytes), including:

Existing extended features

Calculation type: FPGA, counting, dedicated/shared

Calculation type: cpu-ARM, counting, dedicated/shared

5. SSD confirm NVMe (set identification data)

6. FPGA sends out NVMe (Set LogPage-compute_FPGA), including:

Serial number, model

Hardware capabilities-LUT, BRAM, URAM, Reg, DSP, DRAM

7. SSD Confirm NVMe (Set LogPage-compute_FPGA)

A dedicated interface may exist between the x86 host software and such components for additional queries on pairing and other features.

Manageability software changes to adapt to the new pairing

BMC usually interfaces with SSD on SMBus. This interface can be extended to accommodate FPGA pairing, but also features and other attributes for usability and manageability.

Sample stream:

1. BMC sends NVMe to SSD (read LogPage Temp2)

2. SSD requests FPGA to read the temperature sensor

3. FPGA returns temperature data

4. SSD returns LogPage data

5. BMC sends NVMe to SSD (read LogPage FPGA utilization)

6. SSD requests FPGA to read FPGA utilization

7. FPGA returns utilization data

8. SSD returns LogPage data

X86 host software components for pairing

This software component can be used as a library and can provide pairing details between NVMe SSD and FPGA that coexist in a multi-function device. The component can act on the x86 SDAccel execution time driver and library to provide pairing details.

The OpenCL interface to date does not display the BDF level details of the device, but provides a logical abstraction with a number starting from offset 0. The interface can be changed internally by the provider to query low-level details that are only displayed in the hardware, and this can also provide matching details for the computing side. Here, the supplier can be responsible for interface changes.

Command line tool for query matching

The command line tool can provide details when run without any options, such as those shown in Table 4 below. Two I/O stacks and their programmable device references are reflected in the details. The NVMe SSD/dev/nvme2 is paired with the acceleration device at an index below zero. It should be noted that, as shown on this server, the SSD device order does not increase with the FPGA acceleration device.

Table 4: Command line tool output<br></br><tables><table><TABLE border="1" borderColor="#000000" width="85%"><TBODY><tr><td>Device pairing information:<br></br>NVMe device Acceleration device<br></br> (ClGetDeviceIDs index)<br></br>/dev/nvme2 0<br></br>/dev/nvme1 1<br></br></td></tr></TBODY></TABLE></table></tables>

The command line tool may also support a verbose option, which displays additional details that are more important to field personals such as system administrators. These additional details can include NVMe SSD attributes, which are unique on this type of device, such as serial number, model and firmware details, as well as namespace and multi-partition mapping information. The unique set of details also includes a PCIe device chain that can identify the slot in which the device is inserted. Table 5 below shows examples of such information.

Table 5: Command line tool output<br></br><tables><table><TABLE border="1" borderColor="#000000" width="85%"><TBODY><tr><td>Device pairing information:<br></br>NVMe device Acceleration device<br></br> (ClGetDeviceIDs index)<br></br>/dev/nvme0<br></br>         |...................................0<br></br>        |                                    |<br></br> \-[0000:3d:00.0] \-[0000:3e:00.0]-[0000:3e:00.1]<br></br> |---&gt; [PCIe EP][Exchange DP Slot#0][Exchange UP][RP Slot#1][Numa Node0]<br></br> +-Model:<i>NVMe</i><i>SSD</i><i>Model information</i><br></br> +-Sequence#: 0123456789ABCDEF0000<br></br> +-Firmware_rev: FPGASSD0<br></br> +-Mapping: /dev/nvme0n1p1 /dev/nvme0n1<br></br>/dev/nvme2 1<br></br>         |...................................1<br></br>        |                                    |<br></br> \-[0000:8e:00.0] \-[0000:8f:00.0]-[0000: 8f:00.1]<br></br> |---&gt; [PCIe EP][Exchange DP Slot #0][Exchange UP][RP Slot #7][Numa Node 1]<br></br> +-Model:<i>NVMe</i><i>SSD</i><i>Model information</i><br></br> +-Sequence#: 0123456789ABCDEF0000<br></br> +-Firmware_rev: FPGASSD0<br></br> +-Mapping: /dev/nvme2n1p1 /dev/nvme2n1<br></br></td></tr></TBODY></TABLE></table></tables>

For the device /dev/nvme0, insert the SSD/FPGA device into slot number 1 which is also close to the CPU of numa node 0. This information can be used for field-level analysis as well as for CPU affinity at the application level. This information can also be used to understand the device hierarchy when it is included in the deep embedded mode PCIe switch structure, and it can also isolate device problems: for example, for system administrators.

Advantage

Having a pairing solution for SSD/FPGA devices is beneficial to make such devices more usable. In the short term, this matching solution can resolve the identification gap. In the long term, this pairing solution can illustrate decisions about how to advance the acceleration device. This solution can be used for other accelerator types, such as GPU, embedded CPU (such as Advanced Reduced Instruction Set Computer (RISC) machine (Advanced Reduced Instruction Set Computer Machine; ARM), RISC-V, tensor Processing unit (Tensor Processing Unit; TPU) and accelerator based on specific hardware), NVMe specification expansion, or some other mechanism.

FIG. 1 shows a machine designed to support the pairing of a storage device and an auxiliary processor according to an embodiment of the inventive concept. In FIG. 1, a machine 105 is shown. The machine 105 may include a processor 110. The processor 110 may be any variety of processors: for example, Intel Xeon, Celeron, Itanium or Atom processor, AMD Opteron processor ), ARM processor, etc. Although FIG. 1 shows a single processor 110 in the machine 105, the machine 105 may include any number of processors, and each of the processors may be a single-core processor or a multi-core processor, and may be in any desired combination mix.

The machine 105 may also include a memory 115. The memory 115 can be any kind of memory, such as flash memory, dynamic random access memory (Dynamic Random Access Memory; DRAM), static random access memory (Static Random Access Memory; SRAM), permanent random Access memory, Ferroelectric Random Access Memory (FRAM) or Non-Volatile Random Access Memory (NVRAM), such as Magnetoresistive Random Access Memory (NVRAM) Random Access Memory; MRAM) etc. The memory 115 can also be any desired combination of different memory types. The memory 115 can be managed by the memory controller 120.

The machine 105 may also include a storage device 125-1 and a storage device 125-2, which can be controlled by a device driver (not shown). The storage device 125-1 and the storage device 125-2 may be any desired forms of storage devices. For example, the storage device 125-1 and the storage device 125-2 may be a solid state drive (SSD), such as a non-volatile storage fast (NVMe) SSD, a hard disk drive, or any other required form of storage device. In addition, the storage device 125-1 and the storage device 125-2 may have different types, manufacturers, and/or models: for example, the storage device 125-1 may be an SSD, and the storage device 125-2 may be a hard disk drive.

The machine 105 may also include an auxiliary processor 130-1 and an auxiliary processor 130-2. The auxiliary processor 130-1 and the auxiliary processor 130-2 can provide any required functions to support the storage device 125-1 and the storage device 125-2. For example, the auxiliary processor 125-1 can provide the following functions: data acceleration, data deduplication, data integrity, data encryption, data compression, and/or erasure coding. The auxiliary processor 130-1 and the auxiliary processor 130-2 may each provide only one such function, or the auxiliary processor 130-1 and the auxiliary processor 130-2 may each provide a plurality of such functions. The auxiliary processor 130-1 and the auxiliary processor 130-2 may be implemented using any required elements. Figure 2 shows some example implementations of the auxiliary processor 130-1 and the auxiliary processor 130-2, such as field programmable gate array (FPGA) 205, application-specific integrated circuit (ASIC) 210, graphics A processing unit (Graphics Processing Unit; GPU) 215, a tensor processing unit (TPU) 220, an erasure coding controller 225, and a small processor core 230, but the embodiment of the inventive concept may also include an auxiliary processor 130-1 and Other implementations of auxiliary processor 130-2.

Returning to FIG. 1, although FIG. 1 shows two storage devices, each of which has an auxiliary processor, the embodiment of the inventive concept may include any number of storage devices and any storage devices used for each storage device as needed. The number of auxiliary processors, the storage device and the auxiliary processors may be of different types. In addition, in some embodiments of the inventive concept, some storage devices may have auxiliary processors, while other storage devices may not have auxiliary processors. However, as in the case of only one storage device and one auxiliary processor, there is no need to consider the problem of pairing the storage device with the auxiliary processor. Most embodiments of the inventive concept include at least two storage devices with corresponding auxiliary processors. In the remainder of this document, the term "pairing" is intended to refer to a device in which one device in the pairing supports another device, and should not be construed as limiting the pairing to only two devices. For example, if the storage device includes both FPGA and GPU, then all three devices can be regarded as "paired." (Alternatively, FPGA and GPU can be regarded as paired with a public storage device respectively, and if necessary, the association between FPGA and GPU to be determined indirectly is retained.)

Although FIG. 1 depicts the machine 105 as a server (which may be a standalone server or a rack server), embodiments of the inventive concept may include (but are not limited to) any desired type of machine 105. For example, the machine 105 can be replaced with a desktop computer or a laptop computer or any other machine that can benefit from embodiments of the inventive concept. The machine 105 may also include dedicated portable computing machines, tablet computers, smart phones, and other computing machines.

Figure 3 shows additional details of the machine of Figure 1. In FIG. 3, generally, a machine 105 includes one or more processors 110, and the one or more processors may include a memory controller 120 and a clock 305, and the memory controller and clock may be used to coordinate the device 105 Operation of the components. The processor 110 may also be connected to a memory 115. For example, the memory may include random access memory (RAM), read-only memory (ROM), or other state retention media. The processor 110 may also be connected to the storage device 125 and the network connector 310, which may be, for example, an Ethernet connector or a wireless connector. The processor 110 may also be connected to the bus 315, and the user interface 320 and input/output interface ports may be attached to the bus, and the input/output engine 325 and other components may be used to manage the input/output interface ports.

Fig. 4 is a view of the operating system of the device of Fig. 1. In a conventional system, the operating system 405 uses a virtual identifier (ID) 410, a virtual identifier 415, a virtual identifier 420, and a virtual identifier 425 to identify the SSD 125-1 and the SSD 125-2 and the auxiliary processor 130- 1 and auxiliary processor 130-2. (From here, the focus of the discussion is on SSDs as specific examples of storage devices that may include auxiliary processors, but the embodiments of the inventive concept can still be extended to types of storage devices other than SSDs.) (E.g. Peripheral Component Connection (PCI) enumerator) The virtual ID 410, virtual ID 415, virtual ID 420, and virtual ID 425 are allocated during device enumeration, or they can be allocated as the virtual "build" in the machine 105 in Figure 1 Part (or both) of the machine (VM). Either way, the operating system 405 only has the information provided as a result of the virtual ID 410, the virtual ID 415, the virtual ID 420, and the virtual ID 425. With the help of the fact that SSD 125-1 and SSD 125-2 are SSDs, operating system 405 can know that SSD 125-1 assigned virtual ID 410 can include data storage device 430, and can know that SSD 125-1 assigned virtual ID 415 125-2 may include a data storage device 435. However, the operating system 405 may not know that the auxiliary processor 130-1 assigned with the virtual ID 420 intends to support the operation of the SSD 125-1 assigned with the virtual ID 410, or may not know that the auxiliary processor 130-2 assigned with the virtual ID 425 intends to support Operation of SSD 125-2.

FIG. 5 shows the device of FIG. 1 equipped to store information about its pairing. In FIG. 5, the device 125-1, the device 125-2, the device 130-1, and the device 130-2 may include storage devices for various pieces of information related to pairing. Therefore, SSD 125-1 may include storage device 505-1 and storage device 505-2 for information about itself and its companion auxiliary processor (auxiliary processor 130-1), and SSD 125-2 may include The storage device 510-1 and storage device 510-2 for information about itself and its paired auxiliary processor (auxiliary processor 130-2). The auxiliary processor 130-1 may include an SSD ( The storage device 515-1 and storage device 515-2 of the information of the SSD 125-1), and the auxiliary processor 130-2 may include the storage device 520 for information about itself and its paired SSD (SSD 125-2) -1 and storage device 520-2. In some embodiments of the inventive concept, storage device 505-1, storage device 505-2, storage device 510-1, storage device 510-2, storage device 515-1, storage device 515-2, storage device 520- 1 and the information stored in the storage device 520-2 may include information unique to each device, such as a globally unique ID (globally unique ID). ID; GUID) serial number; in other embodiments of the inventive concept, storage device 505-1, storage device 505-2, storage device 510-1, storage device 510-2, storage device 515-1, storage device 515 -2. The storage device 520-1 and the storage device 520-2 can store information agreed between the paired devices, and the information is unique or almost certainly unique. For example, there is an algorithm that allows two parties to agree to share secrets for ensuring the security of communication between the parties through an insecure connection: SSD 125-1 and auxiliary processor 130-1 can use such algorithms to agree to be available Shared secrets for agreed information. Or the SSD 125-1 and the auxiliary processor 130-1 may be allocated a common data segment at the time of manufacturing (when they are physically paired). It should be noted that if the paired device uses some unique information that other devices will not use, then the device 125-1, device 125-2, device 130-1, and device 130-2 may only need to store the unique information at least for pairing purposes. Information instead of storing information about each device in the pair separately.

When the operating system 405 queries individual devices for information about themselves, each device can also return information about its pairing. Therefore, for example, the SSD 125-1 can store its own information in the storage device 505-1 and store information about the auxiliary processor 130-1 in the storage device 505-2; similarly, the auxiliary processor 130- 1 can store its own information in the storage device 515-2 and store information about the SSD 125-1 in the storage device 515-1. Subsequently, the operating system 405 can use the information from the storage device 505-1, the storage device 505-2, the storage device 515-1, and the storage device 515-2 to determine that the SSD 125-1 and the auxiliary processor 130-1 are paired. Such information can be, for example, the serial numbers of various devices or other information that is desired to be unique, such as GUIDs or calculated shared secrets. For example, if two (or more than two) devices each provide their own serial numbers, and their paired serial numbers correspond to the serial numbers as expected, the operating system 405 may regard the two devices as paired. Similarly, if two (or more than two) devices each provide a unique identifier (or a unique identifier may be desired), then the fact that the devices all provide the identifier can prove that these devices should be considered paired. In this way, the operating system 405 may cause the virtual ID 410, the virtual ID 415, the virtual ID 420, and the virtual ID as needed. 425 pairing.

FIG. 6 shows the operating system 405 of FIG. 5 that queries the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 and pairs the devices. In FIG. 6, the operating system 405 may send a query 605 to the SSD 125-1 asking for its device details. It should be noted that conventional operating systems can query devices to determine device characteristics and features as part of the startup; Basic Input/Output System (BIOS) can also query to discover which devices are connected. What is novel is that in response 610, the SSD 125-1 may contain information about itself and information about the auxiliary processor 130-1. Similarly, the operating system 405 may send a query 615 to the auxiliary processor 130-1 asking for its device details: the auxiliary processor 130-1 may send a response 620 containing information about itself and information about the SSD 125-1. When the operating system 405 receives the response 610 and the response 620, the operating system 405 can use the information to determine that the SSD 125-1 and the auxiliary processor 130-1 are paired, as shown in operation 625. The operating system 405 can then store this pairing information.

Once the operating system 405 perceives which storage devices are paired with which auxiliary processors, the operating system 405 can make this information available to applications and/or users. For example, the operating system 405 can provide an application programming interface (API), and the application can use the application programming interface to query the operating system 405 for pairing information. For example, the application can send a query to ask the SSD 125-1 which device(s) are paired with the device via the API. The operating system 405 can then respond with the information that the auxiliary processor 130-1 is paired with the SSD 125-1. Another application can ask for information about the paired devices associated with a particular piece of data: for example, given a particular document (or key-value target, or data that can be stored in another format on the storage device), which ones are stored The device stores the data and which other devices are paired with the storage device. The operating system 405 can then determine which storage device stores the data, and then return information about the storage device and its pairing. (Of course, the application can send two API queries: one to determine the specific storage device storing the target data, and the other to determine which device(s) are paired with that storage device. Combine these two queries into one It's just a simplification.)

Once the application knows which devices are paired via the API, the application can then use the information accordingly. For example, suppose that the auxiliary processor 130-1 and the auxiliary processor 130-2 of FIG. 1 are two FPGAs that provide data acceleration services. Once the application program knows which storage device stores the target data, the application program can direct the request to the FPGA paired with the storage device to request data acceleration services for the target data. The same principle applies to any other functions that can be provided by the auxiliary processor 130-1 and the auxiliary processor 130-2 of FIG. 1: data acceleration is only used as an example function.

At this time, one question remains the same: how to make the device aware of the information identifying the paired device? If the information is allocated as the only data shared by the paired devices at the time of manufacturing, the answer is obvious. However, if the device uses its serial number or other information unique to each device to indicate the identification of its pairing, the response will not be so simple. Figures 7-9 illustrate how the device can obtain this information.

FIG. 7 illustrates the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 in a single appearance size in an embodiment of the inventive concept. In FIG. 7, the SSD 125-1 and the auxiliary processor 130-1 can communicate using the hardware interface of the connection device. For example, such a hardware interface may be a system management bus (SMBus) connecting the SSD 125-1 and the auxiliary processor 130-1. If SMBus is used, either of the devices (SSD 125-1 or auxiliary processor 130-1) can be the master device and the other can be the slave device, or both can be the master devices on the multi-master bus. For example, in some embodiments, the SSD 125-1 may be the master device of the SMBus 705, and the auxiliary processor 130-1 may be the slave device.

As shown, the SSD 125-1 can be connected to the machine 105 of FIG. 1 via both an in-band connection 710 and an out-of-band connection 715. The in-band connection 710 may include, for example, a message sent via a PCI Express (PCIe) connection, and the out-of-band connection 715 may be, for example, another SMBus connection (on which the SSD 125-1 may be a slave device, and the baseboard management controller (BMC) ) Can be the main device, or SSD 125-1 and BMC on it can be the main device on the multi-main bus). Generally, the in-band connection 710 can be used for regular requests (for example, read requests and write requests issued to the SSD 125-1) and can be used to use the functions of the auxiliary processor 130-1, while the out-of-band connection 715 can be used for Control type request: for example, querying the current operating temperature of the SSD 125-1 and/or auxiliary processor 130-1. In the case of using the in-band connection 710 to communicate with the auxiliary processor 130-1, the SSD 125-1 may act as a pass-through device that relies on messages directed to the auxiliary processor 130-1. Alternatively, the SSD 125-1 may function in some converter capabilities to convert the request as received from the machine 105 of FIG. 1 into a different form for transmission to the auxiliary processor 130-1.

Compared with FIG. 7, FIG. 8 shows the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 in a single appearance size in another embodiment of the inventive concept. In the embodiment depicted in FIG. 8, the auxiliary processor 130-1 is directly connected to the in-band connection 710 instead of the SSD 125-1. In this embodiment of the inventive concept, when the auxiliary processor 130-1 receives a request intended for the SSD 125-1, the auxiliary processor 130-1 can act as a pass-through device that depends on the SSD 125- 1s message. Alternatively, the auxiliary processor 130-1 may function in some converter capabilities to convert the request as received from the machine 105 of FIG. 1 into a different form for transmission to the SSD 125-1. In all other respects, the SSD 125-1 and the auxiliary processor 130-1 operate similarly to the SSD 125-1 and the auxiliary processor 130-1 in FIG.

Although Figures 7 to 8 address the possibility that both the SSD 125-1 and the auxiliary processor 130-1 are sold in the same external dimensions, the SSD 125-1 and the auxiliary processor 130-1 can be sold as independent components, as long as there is permission for this A certain form of hardware interface 505 for communication between two paired devices is sufficient, so that the devices can share pairing information with the operating system 325 of FIG. 4.

FIG. 9 illustrates the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 that establish their pairing according to an embodiment of the inventive concept. FIG. 9 can be used when the SSD 125-1 and the auxiliary processor 130-1 share a hardware interface (for example, the hardware interface 705 in FIGS. 7 to 8). In Figure 9, the SSD 125-1 is initiating a query for device information from the auxiliary processor 125-1. The SSD 125-1 may send the identification device 905 to the auxiliary processor 130-1 (this command and all other commands in FIGS. 9 to 10 may be NVMe commands, or may be commands using other protocols). The auxiliary processor 130-1 may respond with an identification response 910, which may include unique information related to the pairing of the SSD 125-1 and the auxiliary processor 130-1. Such information may include, for example, the GUID or the manufacturer model and serial number of the auxiliary processor 130-1. After receiving the identification response 910, the SSD 125-1 can store the information of the auxiliary processor 130-1: for example, store it in the storage device 505-2 of FIG. The SSD 125-1 may then send the setting pairing data 915, which may include unique information of the SSD 125-1: in addition, for example, the GUID or the manufacturer model and serial number of the SSD 125-1. The auxiliary processor 130-1 can then store the SSD Information of 125-1: In addition, it is stored in the storage device 515-1 of FIG. 5, for example. The auxiliary processor 130-1 may then send a setting response 920 to notify the SSD 125-1 that the pairing data in the setting pairing data command is received. Finally, the SSD 125-1 can send the advanced settings information 925 to inform the auxiliary processor 130-1 of any other information that the SSD 125-1 wants the auxiliary processor 130-1 to know, and the auxiliary processor 130-1 can respond 930 with the settings. Respond.

FIG. 10 illustrates the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 that establish their pairing according to another embodiment of the inventive concept. FIG. 10 is similar to FIG. 9 except that the auxiliary processor 130-1 instead of the SSD 125-1 can initiate information exchange. In FIG. 10, the auxiliary processor 130-1 may send the read identity data 1005 to the SSD 125-1. The SSD 125-1 may respond with a read response 1010, which may include unique information related to the pairing of the auxiliary processor 130-1 and the SSD 125-1. Such information may include, for example, the GUID or the manufacturer model and serial number of the SSD 125-1. After receiving the read response 1010, the auxiliary processor 130-1 can store the information of the SSD 125-1: for example, store it in the storage device 505-2 of FIG. 5. The auxiliary processor 130-1 may then send the set identity data 1015, which may include unique information of the auxiliary processor 130-1: in addition, for example, the GUID or the manufacturer model and serial number of the auxiliary processor 130-1. The SSD 125-1 can then store the information of the auxiliary processor 130-1: in addition, it can be stored in the storage device 515-1 of FIG. 5, for example. SSD 125-1 can then send a setting response 1020 to notify the auxiliary processor 130-1 that the pairing information in the setting identity information command is received. Finally, the auxiliary processor 130-1 can send the setting log page 925 to notify the SSD 125-1 of any other information that the auxiliary processor 130-1 wants the SSD 125-1 to know about, and the SSD 125-1 can respond with the setting response 1025. .

FIG. 11 illustrates a first topology including the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 according to an embodiment of the inventive concept. Figures 11 to 14 are taken from the U.S. Patent Application No. 16/260,087 filed on January 28, 2019 in the same application. The application is the U.S. Patent Application No. 16/226,629 filed on December 19, 2018. Part of the continuation application, the application is the continuation application of the U.S. Patent Application No. 16/207,080 filed on November 30, 2018, and the application requires the U.S. Provisional Patent Application No. 62/745,261 filed on October 12, 2018 Rights, all the aforementioned applications are incorporated herein by reference for all purposes. However, the U.S. Patent Application No. 16/260,087, which is in the same application, focuses on the overall combination of PCIe switches with erasure coding, while this article focuses more on the structure of SSD and its auxiliary processors.

In FIG. 11, a PCIe switch 1105 with backup erasure coding logic is shown, which can be implemented as an independent component of the machine 105 of FIG. 1. That is, the PCIe switch 1105 with backup erasure coding logic can be manufactured, and it can be sold separately from any other components (for example, the processor 110, the storage device 125-1, or the auxiliary processor 130-1 of FIG. 1).

A PCIe switch 1105 with backup erasure coding logic can be connected to the storage device 125-1. In FIG. 11, the PCIe switch 1105 with backup erasure coding logic is shown as being connected to only a single storage device, and the storage device may not support erasure coding: erasure coding requires at least two storage devices or storage devices. At least two parts are used to perform banding, block, grouping, and use of parity or code information. But even with a single storage device, the PCIe switch 1105 with backup erasure coding logic can provide some advantages. For example, a PCIe switch 1105 with backup erasure coding logic can support the use of error correction codes with the storage device 125-1, or if the storage device 125-1 itself does not provide those services, the storage device 125- The data on 1 is encrypted.

The storage device 125-1 can also be connected to the FPGA 205, the example of the auxiliary processor 130-1 in FIG. Reference to any alternative auxiliary processors depicted in 2 or more generally to auxiliary processor 130-1 of FIG. 1). FPGA 205 can support acceleration. Simply put, there may be situations where the data may need to be processed and then discarded. Loading all of the data into the processor 110 of FIG. 1 to perform the processing can be expensive and time-consuming: calculations can be performed more easily when closer to the data. FPGA 205 can support performing such calculations closer to the storage device, thereby avoiding loading data into the processor 110 of FIG. 1 to perform calculations: this concept is called "acceleration". FPGA-based acceleration is discussed in more detail in U.S. Patent Application No. 16/122,865 filed on September 5, 2018, which requires U.S. Provisional Patent Application No. 62/642,568, filed on March 13, 2018. U.S. Provisional Patent Application No. 62/641,267 filed on March 13, 2018 and U.S. Provisional Patent Application No. 62/638,904 filed on March 5, 2018, all of the above applications are hereby incorporated by reference; And it requires the U.S. Patent Application No. 16/124,179 filed on September 6, 2018, the U.S. Patent Application No. 16/124,182 filed on September 6, 2018, and the U.S. Patent Application No. 16/ filed on September 6, 2018. 124,183, all of the above applications are continuations of U.S. Patent Application No. 16/122,865 filed on September 5, 2018 and are hereby incorporated by reference. Since the goal of acceleration is to process data without transmitting the data to the processor 110 of FIG. 1, FIG. 11 shows the FPGA 205 closer to the storage device 125-1. However, it should be noted that the specific arrangement shown in Figure 11 is not required: FPGA 205 may be located between the PCIe switch 1105 with backup erasure coding logic and the storage device 125-1.

In addition to data acceleration, the FPGA 205 may provide other functions to support the storage device 125-1. For example, the FPGA 205 can implement a data deduplication function on the storage device 125-1 in an attempt to reduce the number of times the same data is stored on the storage device 125-1. FPGA 205 can determine whether to store specific data on storage device 125-1 more than once, establish associations between various logical block addresses (or other information used by the host to identify data), and store the data in the storage device. 125-1, and delete the extra copy.

Alternatively, the FPGA 205 can implement a data integrity function (such as adding an error correction code) on the storage device 125-1 to prevent the operation through the storage device 125-1 or the use of Cyclic Redundancy Correction (Cyclic Redundancy Correction; CRC) error in T10DIF (data integrity field) for end-to-end protection and data loss occurs. In this way, the FPGA 205 may be able to detect when an error in writing or reading data on the storage device 125-1 occurs or detect the data in transition and restore the original data. It should be noted that the FPGA 205 can implement the data integrity function without the host being aware that it is providing the data integrity function: the host can only refer to the data itself without any error correction codes.

Alternatively, the FPGA 205 can implement the data encryption function on the storage device 125-1 to prevent unauthorized parties from being able to access data on the storage device 125-1: without providing a suitable encryption key , The information returned from FPGA 205 is meaningless to the requester. The host can provide an encryption key to be used when writing and reading data. Or, the FPGA 205 can automatically perform data encryption and decryption: the FPGA 205 can store the encryption key (and even generate the encryption key on behalf of the host), and determine the appropriate encryption key to use based on who is requesting the data.

Alternatively, the FPGA 205 may implement a data compression function on the storage device 125-1 to reduce the amount of space required to store data on the storage device 125-1. When writing data to the storage device 125-1, the FPGA 205 can compress the data provided by the host into a smaller amount of storage and then store the compressed data (and restore the original data when the data is read from the storage device 125-1. Any information required). When reading data from the storage device 125-1, the FPGA 205 can read the compressed data (and any information needed to restore the original data from the compressed data) and remove the compression to restore the original data.

Any required implementation of data deduplication, data integrity, data encryption, and data compression can be used. The embodiments of the inventive concept are not limited to specific implementations of any of these functions.

The FPGA 205 can also implement any combination of functions on the storage device 125-1 as needed. For example, FPGA 205 can implement both data compression and data integrity (because data compression can increase the sensitivity of data to errors: for example, a single error in the data stored on the storage device 125-1 can cause a large amount of data to be unavailable) . Or FPGA 205 can implement both data encryption and data compression (to protect data when the storage device for data is used as little as possible). The FPGA 205 may also provide other combinations of two or more functions.

In terms of overall operation, the FPGA 205 can read data from a suitable source when implementing any of these functions. It should be noted that although the term "source" is a singular noun, embodiments of the inventive concept can read data from multiple sources (eg, multiple storage devices) under appropriate circumstances. The FPGA 205 can then perform appropriate operations on the data: data acceleration, data integration, data encryption, and/or data compression. The FPGA 205 can then take appropriate actions on the operation results: for example, sending the results to the machine 105 of FIG. 1 or writing data to the storage device 125-1.

Although the above functions are described with reference to FPGA 205 in FIG. 11, embodiments of the inventive concept may include these functions in any position in the system (the system includes an FPGA). In addition, the embodiment of the inventive concept allows the FPGA 205 to access data from a "remote" storage device. For example, returning to FIG. 1 for the time being, it is assumed that the storage device 125-1 includes an FPGA similar to the FPGA 205, but the storage device 125-2 does not contain such auxiliary processors. The FPGA included in the storage device 125-1 can be used to apply its functions to the storage device 125-2 by sending a request to the storage device 125-2. For example, if the FPGA in the storage device 125-1 provides data acceleration, the FPGA in the storage device 125-1 can send a request to read data from the storage device 125-2, perform appropriate acceleration, and then send the result To a suitable destination (for example, machine 105 in Figure 1).

In FIG. 11 (and in the topology depicted in FIGS. 12 to 14 below), a PCIe switch 1105 with backup erasure coding logic can be attached to a device that is not qualified for erasure coding. For example, the PCIe switch 1105 with backup erasure coding logic can be attached to other storage devices with built-in erasure coding functions or to devices that are not storage devices, such as FPGA 205 in FIG. 11 or in FIG. 2 GPU 215. All such devices can be described as devices that are not eligible for erasure coding (or at least, erasure coding through a PCIe switch 1105 with backup erasure coding logic).

When a PCIe switch 1105 with backup erasure coding logic is connected to a device that is not qualified for erasure coding, the system has various alternative methods that can be used. In one embodiment of the inventive concept, including any device that is not eligible for erasure coding can cause the backup erasure coding logic of the PCIe switch 1105 with backup erasure coding logic to be disabled. Therefore, if, for example, a PCIe switch 1105 with backup erasure coding logic is connected to FPGA 205 in FIG. 11, or GPU 215 in FIG. 2, or a storage device with local erasure coding logic, then it is connected to a storage device with backup erasure coding logic. None of the storage devices in the PCIe switch 1105 can be used with erasure coding. It should be noted that the decision to disable the backup erasure coding logic of the PCIe switch 1105 with backup erasure coding logic does not have to be transferred to other PCIe switches with backup erasure coding logic in the same chassis or other chassis. For example, referring to Figure 13 in advance, Figure 13 shows two PCIe switches 1105 with backup erasure coding logic and PCIe switch 1305 with backup erasure coding logic. One of them can have backup erasure coding logic enabled. The other one can have back-up erasure coding logic disabled.

Another embodiment of the inventive concept can deactivate devices that are not eligible for erasure coding as if they are not connected to the PCIe switch 1105 with backup erasure coding logic at all to handle these devices. In this embodiment of the inventive concept, the PCIe switch 1105 with backup erasure coding logic can enable the backup erasure coding logic for the storage device 125-1, and can disable any other storage that is not eligible for erasure coding. Devices as if they were not connected to a PCIe switch 1105 with backup erasure coding logic.

In another embodiment of the inventive concept, the PCIe switch 1105 with backup erasure coding logic can enable backup erasure coding logic for storage devices that can be covered by the backup erasure coding logic, but still enables access without erasure coding. Other devices for encoding qualifications. This embodiment of the inventive concept is the most complex implementation: a PCIe switch 1105 with backup erasure coding logic needs to determine which devices are eligible for erasure coding and which devices are not qualified for erasure coding, and then analyze the traffic to Determine whether the traffic is designated for the virtual storage device (in this case, the traffic is truncated by the back-up erasure coding logic) or not designated for the virtual storage device (in this case, the traffic is delivered to its original destination.)

In the embodiment of the inventive concept in which the machine 105 of FIG. 1 ultimately does not provide the full functionality of the installed device, that is, in which erasure coding is disabled due to the existence of devices that are not qualified for erasure coding or such devices are changed by In an embodiment of the inventive concept where the PCIe switch 1105 with backup erasure coding logic is disabled, the machine 105 of FIG. 1 can notify the user of this fact. Such notification may be provided by the processor 110 of FIG. 1, the BMC, or the PCIe switch 1105 with backup erasure coding logic. In addition to notifying the user that some functions have been disabled, the notification may also inform the user how to reconfigure the machine 105 of FIG. 1 to permit added functions. For example, the notification may suggest that devices that are not eligible for erasure coding connect to specific slots in the mid-plane (maybe those slots connected to PCIe machines 1305 with backup erasure coding logic), and suggest Storage devices that are indeed eligible for erasure coding are connected to other slots, such as those connected to the PCIe switch 1105 with backup erasure coding logic. In this way, at least some storage devices qualified for erasure coding can benefit from the erasure coding scheme, but access to other devices that are not qualified for erasure coding is not blocked.

FIG. 12 illustrates a second topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to another embodiment of the inventive concept. In FIG. 12, the PCIe switch 1105 with backup erasure coding logic can be located in the FPGA 205: that is, the FPGA 205 can also implement the PCIe switch 1105 with backup erasure coding logic. FPGA 205 and PCIe switch 1105 with backup erasure coding logic can then be connected to storage device 125-1 to storage device 125-4. Although FIG. 12 shows the FPGA 205 and the PCIe switch 1105 with backup erasure coding logic connected to the four storage devices 125-1 to 125-4, the embodiment of the inventive concept may include any number of storage devices 125 -1 to storage device 125-4.

Generally, the topology shown in Figure 12 can be in a single shell or case containing all the components shown (SSD 125-1 to SSD 125-4 can be independent flash memory instead of self-contained SSD) accomplish. In other words, it is not sold as an independent component, but the entire structure shown in FIG. 12 can be sold as a single unit. However, the embodiment of the concept of the present invention may also include a riser card, one end of which is connected to the machine 105 of FIG. 1 (possibly connected to the midplane), and a connector on the other end (for example, U.2, M.3 or SFF-TA-1008 connector) connect to storage device 125-1 to storage device 125-4. And although FIG. 12 shows the PCIe switch 1105 with backup erasure coding logic as a component of FPGA 205, the PCIe switch 1105 with backup erasure coding logic can also be implemented as a component of a smart SSD.

FIG. 13 illustrates a third topology for using the PCIe switch 1105 with backup erasure coding logic of FIG. 1 according to another embodiment of the inventive concept. In FIG. 13, two PCIe switches 1105 with backup erasure coding logic and PCIe switches 1305 with backup erasure coding logic are shown, between which at most 24 storage devices 125-1 and 125-6 are connected. Each PCIe switch 1105 with backup erasure coding logic and PCIe switch 1305 with backup erasure coding logic can contain 96 PCIe lanes, using four PCIe lanes in each direction to communicate with storage device 125-1 to storage device One communication in 125-6: Each PCIe switch 1105 with backup erasure coding logic and PCIe switch 1305 with backup erasure coding logic can then support up to 12 storage devices. In order to support erasure coding on storage devices supported by multiple PCIe switches 1105 with backup erasure coding logic and PCIe switches 1305 with backup erasure coding logic, a PCIe switch with backup erasure coding logic can be specified It is responsible for erasure coding on all devices and can have back-up erasure coding logic enabled. Another PCIe switch 1305 with backup erasure coding logic can only operate as a PCIe switch when the backup erasure coding logic is disabled. The selection of which PCIe switch should be selected to handle erasure coding can be done in any desired way: for example, two PCIe switches can negotiate this separately, or the PCIe switch enumerated first can be designated to handle erasure coding. The PCIe switch selected to handle erasure coding can then report to the virtual storage device (across two PCIe switches), while the PCIe switch that does not handle erasure coding may not have a downstream device to report (to prevent the processor 110 of Figure 1 from attempting Access storage devices that are part of an erasure coding scheme).

It should be noted that although the PCIe switch 1105 with backup erasure coding logic and the PCIe switch 1305 with backup erasure coding logic may both be located in the same chassis, the PCIe switch 1105 with backup erasure coding logic and the PCIe switch 1105 with backup erasure coding logic The PCIe switch 1305 can be located in different chassis. In other words, the erasure coding scheme can span storage devices in multiple chassis. The only requirement is that the PCIe switches in the various chassis can negotiate with each other the location of the storage devices that will be part of the erasure coding scheme. The embodiments of the inventive concept are not limited to two PCIe switches with backup erasure coding logic 1105 and PCIe switches with backup erasure coding logic 1305: the storage devices included in the erasure coding scheme can be connected to any number of The PCIe switch 1105 with backup erasure coding logic and the PCIe switch 1305 with backup erasure coding logic.

The host logical block address (Host Logical Block Address; LBA) can be split across the PCIe switch 1105 with backup erasure coding logic and the PCIe switch 1305 with backup erasure coding logic in any desired manner. For example, the least significant bit (LBA) in the host can be used to identify which of the PCIe switch 1105 with backup erasure coding logic or the PCIe switch 1305 with backup erasure coding logic contains storage The storage device of the host LBA data. With more than two PCIe switches with backup erasure coding logic, multiple bits can be used to determine which PCIe switch with backup erasure coding logic manages the storage device storing the data. Once a suitable PCIe switch with backup erasure coding logic has been identified, the transmission can be routed to a suitable PCIe switch with backup erasure coding logic (assuming that the transmission is not designated for storage devices that are connected to the enabled PCIe switch with backup erasure coding logic).

In another embodiment of the concept of the present invention, instead of making a single PCIe switch with backup erasure coding logic be responsible for virtualizing all storage devices connected to two PCIe switches with backup erasure coding logic, each has backup The PCIe switch of erasure coding logic can generate independent virtual storage device (with independent erasure coding domain). In this way, different erasure coding domains can be generated for different clients, but these coding domains have a smaller capacity.

Although FIG. 13 means that only storage device 125-1 to storage device 125-6 are connected to PCIe switch 1105 with backup erasure coding logic and PCIe switch 1305 with backup erasure coding logic, and it means all storage devices 125-1 The storage device 125-6 can be used with an erasure coding scheme, but as discussed above, embodiments of the inventive concept are not limited to this: PCIe switch 1105 with backup erasure coding logic and PCIe with backup erasure coding logic The switch 1305 can connect devices that are not qualified for erasure coding. Such devices can be grouped according to a single PCIe switch with backup erasure coding logic, wherein storage devices qualified for erasure coding are grouped according to different PCIe switches 1105 with backup erasure coding logic. In this way, the best function of the machine 105 of FIG. 1 can be achieved, where one (or some) PCIe switches with backup erasure coding logic are enabled with backup erasure coding logic, and one (or some) is enabled with backup erasure coding logic. The PCIe switch with encoding logic disables the backup erasure encoding logic.

FIG. 14 shows a fourth topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to another embodiment of the inventive concept. In FIG. 14, compared with FIG. 13, the PCIe switch 1105 with backup erasure coding logic, the PCIe switch 1305 with backup erasure coding logic, and the PCIe switch 1405 with backup erasure coding logic can be constructed in a hierarchical structure. The PCIe switch 1105 with backup erasure coding logic can manage the erasure coding for all storage devices under the PCIe switch 1105 with backup erasure coding logic in the hierarchy at the top of the hierarchy, and therefore backup erasure can be enabled Except for coding logic. On the other hand, PCIe switch 1305 with backup erasure coding logic and PCIe switch 1405 with backup erasure coding logic can disable its backup erasure coding logic (because its storage device is controlled by PCIe switch with backup erasure coding logic 1105 backup erasure coding logic management).

Although FIG. 14 shows three PCIe switches 1105 with backup erasure coding logic, a PCIe switch 1305 with backup erasure coding logic, and a PCIe switch 1405 with backup erasure coding logic constructed in a two-layer hierarchical structure, the present invention The embodiment of the concept is not limited to the number of PCIe switches involved or to a hierarchical arrangement. Therefore, embodiments of the inventive concept can support any number of PCIe switches with backup erasure coding logic deployed in any desired hierarchical structure.

The focus of the embodiment of the inventive concept described above with reference to FIGS. 1 to 14 is the single-port storage device. However, the embodiments of the inventive concept can be extended to dual-port storage devices, where one (or more than one) storage device communicates with multiple PCIe switches with backup erasure coding logic. In these embodiments of the inventive concept, if the PCIe switch 1105 with backup erasure coding logic of FIG. 11 cannot communicate with the dual-port storage device, then the PCIe switch 1105 with backup erasure coding logic can send the transmission to The PCIe switch 1305 backing up erasure coding logic attempts to communicate with the storage device. The PCIe switch 1305 with backup erasure coding logic effectively acts as a bridge to enable the PCIe switch 1105 with backup erasure coding logic to communicate with the storage device.

15 is a flowchart of an example process for the SSD 125-1 of FIG. 1 (or the auxiliary processor 130-1 of FIG. 1) to query its partners for pairing information according to an embodiment of the inventive concept. In FIG. 15, at block 1505, the SSD 125-1 of FIG. 1 may send the identification device 905 of FIG. 9 to its partner (or the auxiliary processor 130-1 of FIG. 1 may send the reading of FIG. 10 to its partner). Get identity information 1005). At block 1510, the SSD 125-1 of FIG. 1 may receive the identification response 910 of FIG. 9 (or the auxiliary processor 130-1 of FIG. 1 may receive the read response 1010 of FIG. 10). At block 1515, the SSD 125-1 of FIG. 1 may store the received pairing information in the storage device 505-2 of FIG. 5 (or the auxiliary processor 130-1 of FIG. 1 may store the received pairing information in In the storage device 515-1 of FIG. 5). At block 1520, the SSD 125-1 of FIG. 1 may access its own pairing information from the storage device 505-1 of FIG. 5 (or the auxiliary processor 130-1 of FIG. 1 may access the storage device 515-2 of FIG. 5). Access its pairing information). Finally, at block 1525, the SSD 125-1 of FIG. 1 may send the setting pairing information 915 of FIG. 9 to its partner (or the auxiliary processor 130-1 of FIG. 1 may send the setting identity information of FIG. 10 to its partner 1015), so that its partners can store their matching information.

16 is a flowchart of an example process for the SSD 125-1 of FIG. 1 (or the auxiliary processor 130-1 of FIG. 1) to receive a query for matching data from its partners according to an embodiment of the inventive concept. In FIG. 12, at block 1605, the SSD 125-1 of FIG. 1 may receive the read identity data 1005 of FIG. 10 from the auxiliary processor 130-1 of FIG. 1 (or the auxiliary processor 130-1 of FIG. The SSD 125-1 of FIG. 1 receives the identification device 905 of FIG. 9). At block 1610, the SSD 125-1 of FIG. 1 may access its pairing information from the storage device 505-1 of FIG. 5 (or the auxiliary processor 130-1 may access its pairing information from the storage device 515-2 of FIG. 5 ). At block 1615, the SSD 125-1 of FIG. 1 may send the pairing information in the read response 1010 of FIG. 10 to the auxiliary processor 130-1 of FIG. 1 (or the auxiliary processor 130-1 of FIG. 1 may send the pairing information in FIG. 9 The identification response to the pairing information in 910). At block 1620, the SSD 125-1 of FIG. 1 may receive the setting identity information 1015 of FIG. 10 from the auxiliary processor 130-1 of FIG. 1 (or the auxiliary processor 130-1 of FIG. 1 Receive the setting pairing data 915 of FIG. 9). Finally, at box 1625, the SSD of Figure 1 125-1 may store the pairing information of the auxiliary processor 130-1 of FIG. 1 in the storage device 505-2 of FIG. 5 (or the auxiliary processor 130-1 of FIG. 1 may pair the SSD 125-1 of FIG. 1 The information is stored in the storage device 515-1 in Figure 5).

FIG. 17 shows the SSD 125-1 of FIG. 1 and/or the auxiliary processor 130-1 of FIG. The flow chart of the example process of responding to the query. In FIG. 17, at block 1705, the SSD 125-1 and/or auxiliary processor 130-1 of FIG. 1 may receive the query 605 and/or query 610 of FIG. 6 from the operating system 405 of FIG. 5. At block 1710, the SSD 125-1 and/or auxiliary processor 130-1 of FIG. 1 may access the SSD 125-1 and/or the SSD 125-1 and/or the storage device 515-2 of FIG. 5 from the storage device 505-1 and/or storage device 515-2 of FIG. /Or the matching information of the auxiliary processor 130-1, such as a unique ID or manufacturer model and/or serial number. At block 1715, the SSD 125-1 and/or auxiliary processor 130-1 of FIG. 1 may access the pairing information for the partner device from the storage device 505-2 and/or storage device 515-1 of FIG. 5, For example, a unique ID or manufacturer model and/or serial number. Finally, at block 1720, the SSD 125-1 and/or the auxiliary processor 130-1 of FIG. 1 may send pairing information about the paired device to the operating system 405 of FIG. 5.

FIG. 18 is a flowchart of an example process for the operating system 405 of FIG. 5 to query the SSD 125-1 of FIG. 1 and the auxiliary processor 130-1 of FIG. 1 and pair them according to an embodiment of the inventive concept. In FIG. 18, at block 1805, the operating system 405 of FIG. 5 may send a query (to the operating system 405 of FIG. 5) to the device represented by the virtual ID, such as query 605 and/or query 615 of FIG. At block 1810, the operating system 405 of FIG. 5 may receive its pairing information from the device. At block 1815, operating system 405 of FIG. 5 may send another query, such as query 605 and/or query 615 of FIG. 6, to another device represented by another virtual ID (to operating system 405 of FIG. 5). At block 1820, the operating system 405 of FIG. 5 may receive its pairing information from the device. At block 1825, the operating system 405 of FIG. 5 may determine that the two devices have provided the same pairing information, and the devices are paired in some manner in the operating system 405 of FIG. 5. Finally, at block 1830, the operating system 405 of FIG. 5 may provide APIs to applications that support queries regarding device pairing.

FIG. 19 is a flowchart of an example process of making the operating system 405 of FIG. 5 respond to a query about device pairing information from an application according to an embodiment of the inventive concept. In FIG. 19, at block 1905, the operating system 405 of FIG. 5 may receive a pairing request for a specific device from an application program. At block 1910, the operating system 405 of FIG. 5 may find the requested device in the table storing the pairing information. At block 1915, the operating system 405 of FIG. 5 may determine a pairing for the devices in the table. At block 1920, the operating system 405 of FIG. 5 may return information about the pairing of the device to the application.

Alternatively, at block 1925, the operating system 405 of FIG. 5 may receive a request for pairing information about data identifiers (eg, documents, objects, keys, etc.) from the application. At block 1930, the operating system 405 of FIG. 5 may determine the device that stores the data identified by the data identifier. At this time, as illustrated by the arrow 1935, the operating system 405 of FIG. 5 may execute block 1910 and block 1915 as described above. Subsequently, as shown by the arrow 1940, the operating system 405 of FIG. 5 may return information about both the device storing the data and its pairing to the application.

In FIGS. 15 to 19, some embodiments of the inventive concept are shown. However, those skilled in the art will recognize that other embodiments of the inventive concept are also possible by changing the order of the blocks, by omitting the blocks, or by including links not shown in the drawings. Regardless of whether it is explicitly described, all such changes of the flowchart are regarded as embodiments of the inventive concept.

The embodiments of the inventive concept provide technical advantages over the prior art. The embodiment of the inventive concept allows the SSD 125-1 and the SSD 125-2 and the auxiliary processor 130-1 and the auxiliary processor 130-2 of FIG. 1 to determine the pairing information about their pairing partners. Subsequently, the SSD 125-1 and SSD 125-2 of FIG. 1 as well as the auxiliary processor 130-1 and the auxiliary processor 130-2 can provide such pairing information to the operating system 405 of FIG. 5, so that the operating system 405 of FIG. 5 can Store information about which devices are paired with which other devices. Once the operating system 405 of FIG. 5 has properly paired devices, the operating system 405 of FIG. 5 can provide this information to the application via the API, so that the application can request the auxiliary processor 130-1 and auxiliary processing from FIG. 1 The auxiliary processor is paired with the SSD 125-1 and the SSD 125-2 of FIG. 1 that store data, and the service is to be executed after the pairing.

The following discussion is intended to provide a brief general description of one or more suitable machines in which certain aspects of the inventive concept may be implemented. One or more machines can be at least partially through input from conventional input devices such as keyboards and mice, as well as through instructions received from another machine, interaction with virtual reality (VR) environments, and biometric feedback Or other input signals for control. The term "machine" as used herein is intended to broadly cover a single machine, a virtual machine, or a system of communicatively connected machines, virtual machines, or devices that operate together. Exemplary machines include computing devices, such as personal computers, workstations, servers, portable computers, palm-sized devices, phones, tablets, etc.; and transportation devices, such as private or public transportation, such as cars, trains, taxis, and the like.

One or more machines may include embedded controllers, such as programmable or non-programmable logic devices or arrays, application-specific integrated circuits (ASICs), embedded computers, smart cards, etc. One or more machines may utilize one or more connections with one or more remote machines, for example, through a network interface, modem, or other communication connection. Machines can be interconnected by means of physical networks and/or logical networks (such as corporate intranet, Internet, local area network, wide area network, etc.). Those skilled in the art should understand that network communication can utilize various wired and/or wireless short-range or remote carriers and protocols, including radio frequency (RF), satellite, microwave, and Institute of Electrical and Electronics Engineers (Institute of Electrical and Electronics Engineers). Engineer; IEEE) 802.11, Bluetooth®, optical, infrared, cable, laser, etc.

The embodiments of the inventive concept can be described with reference to or in combination with associated data including functions, processes, data structures, applications, etc., which cause the machine to perform tasks or limit abstract data types or low-level data when accessed by the machine. The hardware environment. The associated data can be stored in, for example, volatile and/or non-volatile memory (such as RAM, ROM, etc.) or in other storage devices and their associated storage media. The storage media includes hard drives, floppy disks , Optical storage devices, tapes, flash memory, storage sticks, digital video discs, biological storage devices, etc. The associated data can be transmitted in the form of packets, serial data, parallel data, propagated signals, etc., on a transmission environment including physical and/or logical networks, and can be used in compressed or encrypted formats. The associated data can be used in a distributed environment and stored locally and/or remotely for machine access.

Embodiments of the inventive concept may include a tangible non-transitory machine-readable medium including instructions executable by one or more processors, the instructions including instructions for executing as described herein The instruction of the elements of the inventive concept.

The various operations of the methods described above can be performed by any suitable device capable of performing the operations, such as various hardware and/or software components, circuits, and/or modules. Software may include an ordered list of executable instructions for implementing logical functions, and may be implemented in any "processor readable medium" used by or in combination with an instruction execution system, device, or device The instruction execution system, device or device is, for example, a single-core processor or a multi-core processor or a system containing a processor.

The blocks or steps of methods or algorithms and functions described in conjunction with the embodiments disclosed herein can be directly implemented by hardware, a software module executed by a processor, or a combination of the two. If implemented in software, the function can be stored as one or more instructions or codes on a tangible non-transitory computer-readable medium or transmitted through the tangible non-transitory computer-readable medium. Software modules can reside in random access memory (RAM), flash memory, read-only memory (ROM), electrically programmable ROM (Electrically Programmable ROM; EPROM), electrically erasable programmable ROM (Electrically Erasable Programmable ROM; EEPROM), register, hard disk, removable disk, CD ROM or any other form of storage medium known in the art.

After describing and explaining the principles of the inventive concept with reference to the illustrated embodiments, it should be recognized that the arrangement and details of the illustrated embodiments can be modified without departing from such principles, and can be combined in any desired manner. Moreover, although the foregoing discussion has focused on specific embodiments, other configurations are conceivable. In particular, even if expressions such as "an embodiment according to the concept of the invention" are used herein, these words generally indicate the possibility of a reference embodiment, and are not intended to limit the concept of the invention to a specific embodiment configuration. As used herein, these terms may refer to the same or different embodiments that can be combined into other embodiments.

The foregoing illustrative embodiments should not be construed as limiting the inventive concept thereof. Although several embodiments have been described, those skilled in the art will readily understand that many modifications to those embodiments are possible without materially departing from the novel teachings and advantages of the present disclosure. Therefore, all such modifications are intended to be included within the scope of this inventive concept as defined in the appended claims.

The embodiments of the inventive concept can be extended to (but not limited to) the following statements:

Statement 1. The embodiment of the inventive concept includes a system including:<br></br>Solid state drives (SSD), including:<br></br>The first storage device for data;<br></br>A second storage device for a unique SSD identifier (ID); and<br></br>A third storage device for the unique auxiliary processor ID;<br></br>Auxiliary processor, including:<br></br>A fourth storage device for the unique auxiliary processor ID;<br></br>The fifth storage device for the unique SSD ID; and<br></br>The hardware interface is located between the SSD and the auxiliary processor.

Statement 2. An embodiment of the inventive concept includes the system according to Statement 1, wherein the auxiliary processor includes a field programmable gate array (FPGA), a dedicated integrated circuit, a graphics processing unit (GPU), a tensor processing unit, a wiper In addition to the code controller and one of the small processor cores.

Statement 3. An embodiment of the inventive concept includes the system according to Statement 1, wherein the hardware interface includes one of a system management bus (SMBus) and an Inter-Integrated Circuit (I2C) bus.

Statement 4. An embodiment of the inventive concept includes the system according to Statement 1, wherein the fourth storage device includes one-time programmable (OTP) memory, and programmable read-only memory (Programmable Read-Only). Memory; PROM), Eraseable Programmable Read-Only Memory (Eraseable Programmable Read-Only Memory; EPROM) and Erasable Programmable Read-Only Memory (EEPROM).

Statement 5. An embodiment of the inventive concept includes the system according to Statement 1, wherein the auxiliary processor is operable to query the SSD for a unique SSD ID and store the unique SSD ID in the fifth storage device.

Statement 6. An embodiment of the inventive concept includes the system according to Statement 1, wherein the auxiliary processor is operable to provide a unique auxiliary processor ID for the SSD.

Statement 7. An embodiment of the inventive concept includes the system according to Statement 1, wherein the SSD is operable to query the auxiliary processor for a unique auxiliary processor ID and store the unique auxiliary processor ID in the third storage device.

Statement 8. An embodiment of the inventive concept includes the system according to Statement 1, wherein the SSD is operable to provide a unique SSD ID for the auxiliary processor.

Statement 9. An embodiment of the inventive concept includes the system according to Statement 1, wherein the SSD can operate out-of-band to receive queries about the SSD and auxiliary processors.

Statement 10. An embodiment of the inventive concept includes the system according to Statement 9, wherein the SSD includes an SMBus connection for receiving queries out-of-band.

Statement 11. An embodiment of the inventive concept includes the system according to Statement 9, wherein the SSD is operable to respond to queries with both a unique SSD ID and a unique auxiliary processor ID.

Statement 12. An embodiment of the inventive concept includes the system according to Statement 9, wherein the query includes a non-volatile memory express (NVMe) management interface (MI) command.

Statement 13. An embodiment of the inventive concept includes the system according to Statement 1, wherein the auxiliary processor is operable to receive out-of-band queries about the SSD and the auxiliary processor.

Statement 14. An embodiment of the inventive concept includes the system according to Statement 13, wherein the auxiliary processor is operable to respond to queries with both a unique SSD ID and a unique auxiliary processor ID.

Statement 15. An embodiment of the inventive concept includes the system according to Statement 13, wherein the query includes a non-volatile memory express (NVMe) management interface (MI) command.

Statement 16. An embodiment of the inventive concept includes the system according to Statement 1, wherein the SSD is operable to receive in-band queries about the SSD and the auxiliary processor.

Statement 17. An embodiment of the inventive concept includes the system according to Statement 16, wherein the SSD includes a Peripheral Component Connection Express (PCIe) connection for receiving queries in-band.

Statement 18. An embodiment of the inventive concept includes the system according to Statement 16, wherein the SSD is operable to respond to queries with both a unique SSD ID and a unique auxiliary processor ID.

Statement 19. An embodiment of the inventive concept includes the system according to Statement 16, wherein the query includes a non-volatile memory express (NVMe) management interface (MI) command.

Statement 20. An embodiment of the inventive concept includes a method including:<br></br>Send the query from the first device to the second device;<br></br>Receiving a response from the first device from the second device, the response including the first pairing data;<br></br>Storing the first pairing data in a second storage device in the first device;<br></br>Accessing the second pairing data from the first storage device in the first device; and<br></br>Send the second pairing data from the first device to the second device.

Statement 21. An embodiment of the inventive concept includes the method according to Statement 20, wherein the first device and the second device respectively include a field programmable gate array (FPGA), a dedicated integrated circuit, a graphics processing unit (GPU), and a graphics processing unit (GPU). One of the volume processing unit, erasure coding controller, and small processor core.

Statement 22. An embodiment of the inventive concept includes the method according to Statement 20, wherein:<br></br>Sending the query from the first device to the second device includes sending the query from the first device to the second device through the hardware interface between the first device and the second device;<br></br>Receiving the response from the first device from the second device includes receiving the response from the first device from the second device through the hardware interface between the first device and the second device; and<br></br>Sending the second pairing data from the first device to the second device includes sending the second pairing data from the first device to the second device through a hardware interface between the first device and the second device.

Statement 23. An embodiment of the inventive concept includes the method according to Statement 20, wherein the second storage device includes one-time programmable (OTP) memory, programmable read-only memory (PROM), and erasable programmable read-only One of EPROM and EEPROM.

Statement 24. An embodiment of the inventive concept includes a method including:<br></br>Receiving the query at the first device from the second device;<br></br>Accessing the first pairing data from the first storage device in the first device;<br></br>Sending a response from the first device to the second device, the response including the first pairing data;<br></br>Receiving the second pairing data from the first device from the second device; and<br></br>The second pairing data is stored in the second storage device in the first device.

Statement 25. An embodiment of the inventive concept includes the method according to Statement 24, wherein the first device and the second device respectively include a field programmable gate array (FPGA), a dedicated integrated circuit, a graphics processing unit (GPU), and Zhang One of the volume processing unit, erasure coding controller, and small processor core.

Statement 26. An embodiment of the inventive concept includes the method according to Statement 24, wherein:<br></br>Receiving the query from the first device from the second device includes receiving the query from the first device from the second device through a hardware interface between the first device and the second device;<br></br>Sending the response from the first device to the second device includes sending the response from the first device to the second device through the hardware interface between the first device and the second device; and<br></br>Receiving the second pairing data at the first device from the second device includes receiving the second pairing data at the first device from the second device through a hardware interface between the first device and the second device.

Statement 27. An embodiment of the inventive concept includes the method according to Statement 24, wherein the second storage device includes one-time programmable (OTP) memory, programmable read-only memory (PROM), and erasable programmable read-only One of EPROM and EEPROM.

Statement 28. An embodiment of the inventive concept includes a method including:<br></br>Receive the query from the first device;<br></br>Accessing a first unique identifier (ID) for the first device from the first storage device in the first device;<br></br>Accessing a second unique ID for the second device from a second storage device in the first device, which is paired with the first device; and<br></br>Send a response to the query from the first device, the response including both the first unique ID and the second unique ID.

Statement 29. An embodiment of the inventive concept includes the method according to Statement 28, wherein:<br></br>Receiving the query at the first device includes receiving the query at the first device out-of-band; and<br></br>Sending a response to the query from the first device includes sending a response to the query from the first device out-of-band.

Statement 30. An embodiment of the inventive concept includes the method according to Statement 29, wherein:<br></br>Receiving the query at the first device out-of-band includes receiving the query at the first device through a system management bus (SMBus) connection; and<br></br>Sending a response to the query from the first device out-of-band includes sending a response to the query from the first device through an SMBus connection.

Statement 31. An embodiment of the inventive concept includes the method according to Statement 28, wherein:<br></br>Receiving the query at the first device includes receiving the query at the first device in-band; and<br></br>Sending a response to the query from the first device includes sending a response to the query from the first device in-band.

Statement 32. An embodiment of the inventive concept includes the method according to Statement 31, wherein:<br></br>Receiving the query at the first device in-band includes receiving the query at the first device through a peripheral component connection express (PCIe) connection; and<br></br>Sending a response to the query from the first device in-band includes sending a response to the query from the first device through a PCIe connection.

Statement 33. An embodiment of the inventive concept includes the method according to Statement 28, wherein the query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 34. An embodiment of the inventive concept includes a method including:<br></br>Send the first query to the solid state drive (SSD) indicated by the first virtual identifier (ID);<br></br>Receive a unique SSD ID and a unique auxiliary processor ID from the SSD in response to the first query;<br></br>Sending the second query to the auxiliary processor represented by the second virtual ID;<br></br>Receiving the unique SSD ID and the unique auxiliary processor ID from the auxiliary processor in response to the second query; and<br></br>Pair the first virtual ID with the second virtual ID.

Statement 35. An embodiment of the inventive concept includes the method according to Statement 34, wherein sending the first query to a solid state drive (SSD) includes sending the first query to the SSD out-of-band.

Statement 36. An embodiment of the inventive concept includes the method according to Statement 35, wherein sending the first query to the SSD out-of-band includes sending the first query to the SSD through a system management bus (SMBus) connection.

Statement 37. An embodiment of the inventive concept includes the method according to Statement 34, wherein sending the first query to a solid state drive (SSD) includes sending the first query in-band to the SSD.

Statement 38. An embodiment of the inventive concept includes the method according to Statement 37, wherein sending the first query to the SSD in-band includes sending the first query to the SSD through a Peripheral Element Connection Express (PCIe) connection.

Statement 39. An embodiment of the inventive concept includes the method according to Statement 34, wherein the first query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 40. An embodiment of the inventive concept includes the method according to Statement 34, wherein sending the second query to the auxiliary processor includes sending the second query to the auxiliary processor out-of-band.

Statement 41. An embodiment of the inventive concept includes the method according to Statement 40, wherein sending the second query out-of-band to the auxiliary processor includes sending the second query to the auxiliary processor via an SMBus connection.

Statement 42. An embodiment of the inventive concept includes the method according to Statement 34, wherein the second query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 43. An embodiment of the inventive concept includes the method according to Statement 34, wherein pairing the first virtual ID with the second virtual ID includes responding to the SSD and the auxiliary processor returning a unique SSD ID and a unique auxiliary processor ID. Otherwise, the first virtual ID is paired with the second virtual ID.

44. A forth embodiment of the concept of the present invention comprising the Chen method of claim 34 above, said method further comprising providing an application programming interface (the API), the application programming interface is operable to respect to the first and the second virtual ID Respond to the paired query of the virtual ID.

Statement 45. An embodiment of the inventive concept includes the method according to Statement 44, the method further comprising:<br></br>Receiving a pairing query for the pairing of the first virtual ID; and<br></br>In response to the pairing of the first virtual ID and the second virtual ID, the second virtual ID is returned.

Statement 46. An embodiment of the inventive concept includes the method according to Statement 45, wherein:<br></br>Receiving the pairing query for the first virtual ID includes receiving the pairing query for the first virtual ID from the application via an API; and<br></br>Returning the second virtual ID in response to the pairing of the first virtual ID and the second virtual ID includes returning the second virtual ID to the application in response to the pairing of the first virtual ID and the second virtual ID.

Statement 47. An embodiment of the inventive concept includes the method according to Statement 44, the method further comprising:<br></br>Receive a query on a paired file associated with the file;<br></br>Identify the SSD as storing the file; and<br></br>In response to the file query, the first virtual ID and the second virtual ID are returned.

Statement 48. An embodiment of the inventive concept includes the method according to Statement 47, wherein:<br></br>Receiving a paired document query associated with the document includes receiving a paired document query associated with the document from an application via an API;<br></br>Returning the first virtual ID and the second virtual ID in response to the document query includes returning the first virtual ID and the second virtual ID to the application in response to the document query.

Statement 49. An embodiment of the inventive concept includes an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations:<br></br>Send the query from the first device to the second device;<br></br>Receiving a response from the first device from the second device, the response including the first pairing data;<br></br>Storing the first pairing data in a second storage device in the first device;<br></br>Accessing the second pairing data from the first storage device in the first device; and<br></br>Send the second pairing data from the first device to the second device.

Statement 50. An embodiment of the inventive concept includes the article according to Statement 49, wherein the first device and the second device respectively include a field programmable gate array (FPGA), a dedicated integrated circuit, a graphics processing unit (GPU), and Zhang One of the volume processing unit, erasure coding controller, and small processor core.

Statement 51. An embodiment of the inventive concept includes the article according to Statement 49, wherein:<br></br>Sending the query from the first device to the second device includes sending the query from the first device to the second device through the hardware interface between the first device and the second device;<br></br>Receiving the response from the first device from the second device includes receiving the response from the first device from the second device through the hardware interface between the first device and the second device; and<br></br>Sending the second pairing data from the first device to the second device includes sending the second pairing data from the first device to the second device through a hardware interface between the first device and the second device.

Statement 52. An embodiment of the inventive concept includes the article according to Statement 49, wherein the second storage device includes one-time programmable (OTP) memory, programmable read-only memory (PROM), and erasable programmable read-only One of EPROM and EEPROM.

Statement 53. An embodiment of the inventive concept includes an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations:<br></br>Receiving the query at the first device from the second device;<br></br>Accessing the first pairing data from the first storage device in the first device;<br></br>Sending a response from the first device to the second device, the response including the first pairing data;<br></br>Receiving the second pairing data from the first device from the second device; and<br></br>The second pairing data is stored in the second storage device in the first device.

Statement 54. An embodiment of the inventive concept includes the article according to Statement 53, wherein the first device and the second device respectively include a field programmable gate array (FPGA), a dedicated integrated circuit, a graphics processing unit (GPU), and Zhang One of the volume processing unit, erasure coding controller, and small processor core.

Statement 55. An embodiment of the inventive concept includes the article according to Statement 53, wherein:<br></br>Receiving the query from the first device from the second device includes receiving the query from the first device from the second device through a hardware interface between the first device and the second device;<br></br>Sending the response from the first device to the second device includes sending the response from the first device to the second device through the hardware interface between the first device and the second device; and<br></br>Receiving the second pairing data at the first device from the second device includes receiving the second pairing data at the first device from the second device through a hardware interface between the first device and the second device.

Statement 56. An embodiment of the inventive concept includes the article according to Statement 53, wherein the second storage device includes one-time programmable (OTP) memory, programmable read-only memory (PROM), erasable and programmable read-only One of EPROM and EEPROM.

Statement 57. An embodiment of the inventive concept includes an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations:<br></br>Receive the query from the first device;<br></br>Accessing a first unique identifier (ID) for the first device from the first storage device in the first device;<br></br>Accessing a second unique ID for the second device from a second storage device in the first device, which is paired with the first device; and<br></br>Send a response to the query from the first device, the response including both the first unique ID and the second unique ID.

Statement 58. An embodiment of the inventive concept includes the article according to Statement 57, wherein:<br></br>Receiving the query at the first device includes receiving the query at the first device out-of-band; and<br></br>Sending a response to the query from the first device includes sending a response to the query from the first device out-of-band.

Statement 59. An embodiment of the inventive concept includes the article according to Statement 58, wherein:<br></br>Receiving the query at the first device out-of-band includes receiving the query at the first device through a system management bus (SMBus) connection; and<br></br>Sending a response to the query from the first device out-of-band includes sending a response to the query from the first device through an SMBus connection.

Statement 60. An embodiment of the inventive concept includes the article according to Statement 57, wherein:<br></br>Receiving the query at the first device includes receiving the query at the first device in-band; and<br></br>Sending a response to the query from the first device includes sending a response to the query from the first device in-band.

Statement 61. An embodiment of the inventive concept includes the article according to Statement 60, wherein:<br></br>Receiving the query at the first device in-band includes receiving the query at the first device through a peripheral component connection express (PCIe) connection; and<br></br>Sending a response to the query from the first device in-band includes sending a response to the query from the first device through a PCIe connection.

Statement 62. An embodiment of the inventive concept includes the article according to Statement 57, wherein the query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 63. An embodiment of the inventive concept includes an article including a non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations:<br></br>Send the first query to the solid state drive (SSD) indicated by the first virtual identifier (ID);<br></br>Receive a unique SSD ID and a unique auxiliary processor ID from the SSD in response to the first query;<br></br>Sending the second query to the auxiliary processor represented by the second virtual ID;<br></br>Receiving the unique SSD ID and the unique auxiliary processor ID from the auxiliary processor in response to the second query; and<br></br>Pair the first virtual ID with the second virtual ID.

Statement 64. An embodiment of the inventive concept includes the article according to Statement 63, wherein sending the first query to a solid state drive (SSD) includes sending the first query out-of-band to the SSD.

Statement 65. An embodiment of the inventive concept includes the article according to Statement 64, wherein sending the first query out-of-band to the SSD includes sending the first query to the SSD through a system management bus (SMBus) connection.

Statement 66. An embodiment of the inventive concept includes the article according to Statement 63, wherein sending the first query to a solid state drive (SSD) includes sending the first query in-band to the SSD.

Statement 67. An embodiment of the inventive concept includes the article according to Statement 66, wherein sending the first query in-band to the SSD includes sending the first query to the SSD through a Peripheral Element Connection Express (PCIe) connection.

Statement 68. An embodiment of the inventive concept includes the article according to Statement 63, wherein the first query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 69. An embodiment of the inventive concept includes the article according to Statement 63, wherein sending the second query to the auxiliary processor includes sending the second query to the auxiliary processor out-of-band.

Statement 70. An embodiment of the inventive concept includes the article according to Statement 69, wherein sending the second query out-of-band to the S auxiliary processor SD includes sending the second query to the auxiliary processor via an SMBus connection.

Statement 71. An embodiment of the inventive concept includes the article according to Statement 63, wherein the second query includes a non-volatile management express (NVMe) management interface (MI) command.

Statement 72. An embodiment of the inventive concept includes the article according to Statement 63, wherein pairing the first virtual ID with the second virtual ID includes responding to the SSD and the auxiliary processor returning a unique SSD ID and a unique auxiliary processor ID. Otherwise, the first virtual ID is paired with the second virtual ID.

Statement 73. An embodiment of the inventive concept includes the article according to Statement 63, the non-transitory storage medium having stored thereon instructions that, when executed by a machine, cause the following operations: Provide an application programming interface (API) , The application programming interface is operable to respond to queries regarding the pairing of the first virtual ID and the second virtual ID.

Statement 74. An embodiment of the inventive concept includes the article according to Statement 73, the non-transitory storage medium having stored thereon other instructions that, when executed by a machine, cause the following operations:<br></br>Receiving a pairing query for the pairing of the first virtual ID; and<br></br>In response to the pairing of the first virtual ID and the second virtual ID, the second virtual ID is returned.

Statement 75. An embodiment of the inventive concept includes an article according to Statement 74, wherein:<br></br>Receiving the pairing query for the first virtual ID includes receiving the pairing query for the first virtual ID from the application via an API; and<br></br>Returning the second virtual ID in response to the pairing of the first virtual ID and the second virtual ID includes returning the second virtual ID to the application in response to the pairing of the first virtual ID and the second virtual ID.

Statement 76. An embodiment of the inventive concept includes the article according to Statement 73, the non-transitory storage medium having stored thereon other instructions that, when executed by a machine, cause the following operations:<br></br>Receive a query on a paired file associated with the file;<br></br>Identify the SSD as storing the file; and<br></br>In response to the file query, the first virtual ID and the second virtual ID are returned.

Statement 77. An embodiment of the inventive concept includes an article according to Statement 76, in which:<br></br>Receiving a paired document query associated with the document includes receiving a paired document query associated with the document from an application via an API;<br></br>Returning the first virtual ID and the second virtual ID in response to the document query includes returning the first virtual ID and the second virtual ID to the application in response to the document query.

Therefore, in consideration of various permutations of the embodiments described herein, this detailed description and accompanying materials are intended to be illustrative only, and should not be regarded as limiting the scope of the inventive concept. Therefore, what is claimed by the concept of the present invention is all such modifications that fall within the scope and spirit of the attached patent application and its equivalents.

<p>105: machine/device</p><p>110: processor</p><p>115: memory</p><p>120: Memory Controller</p><p>125, 125-1, 125-2, 125-3, 125-4, 125-5, 125-6: storage device/device/SSD</p><p>130-1, 130-2: auxiliary processor/device</p><p>205: Field programmable gate array</p><p>210: dedicated integrated circuit</p><p>215: Graphics Processing Unit</p><p>220: tensor processing unit</p><p>225: erasure coding controller</p><p>230: small processor core</p><p>305: Clock</p><p>310: Network connector</p><p>315: Bus</p><p>320: User Interface</p><p>325: input/output engine</p><p>405: Operating System</p><p>410, 415, 420, 425: virtual identifier</p><p>430, 435: Data storage device</p><p>505-1, 505-2, 510-1, 510-2, 515-1, 515-2, 520-1, 520-2: storage device</p><p>605, 615: Inquiry</p><p>610, 620: Response</p><p>625: operation</p><p>705: System Management Bus/Hardware Interface</p><p>710: In-band connection</p><p>715: Out-of-band connection</p><p>905: identification device</p><p>910: identification response</p><p>915: set pairing information</p><p>920, 930, 1020, 1025: set response</p><p>925: Set advanced information/set log page</p><p>1005: read identity data</p><p>1010: Read response</p><p>1015: Set up identity information</p><p>1105, 1305, 1405: PCIe switches with backup erasure coding logic;</p><p>1505, 1510, 1515, 1520, 1525, 1605, 1610, 1615, 1620, 1625, 1705, 1710, 1715, 1720, 1805, 1810, 1815, 1820, 1825, 1830, 1905, 1910, 1915, 1920, 1925, 1930: box</p><p>1935, 1940: arrows</p>

FIG. 1 shows a machine designed to support the pairing of a storage device and an auxiliary processor according to an embodiment of the inventive concept.

FIG. 2 shows different forms of the auxiliary processor of FIG. 1.

Figure 3 shows additional details of the machine of Figure 1.

Fig. 4 is a view of the operating system of the device of Fig. 1.

FIG. 5 shows the device of FIG. 1 equipped to store information about its pairing.

FIG. 6 shows an operating system for querying the SSD of FIG. 1 and the auxiliary processor of FIG. 1 and pairing the devices.

FIG. 7 illustrates the SSD of FIG. 1 and the auxiliary processor of FIG. 1 in a single appearance size in an embodiment of the inventive concept.

FIG. 8 shows the SSD of FIG. 1 and the auxiliary processor of FIG. 1 in a single external size in another embodiment of the inventive concept.

FIG. 9 illustrates the SSD of FIG. 1 and the auxiliary processor of FIG. 1 with their pairing established according to an embodiment of the inventive concept.

FIG. 10 illustrates the SSD of FIG. 1 and the auxiliary processor of FIG. 1 with their pairing established according to another embodiment of the inventive concept.

FIG. 11 illustrates a first topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to an embodiment of the inventive concept.

FIG. 12 illustrates a second topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to another embodiment of the inventive concept.

FIG. 13 shows a third topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to another embodiment of the inventive concept.

FIG. 14 shows a fourth topology including the SSD of FIG. 1 and the auxiliary processor of FIG. 1 according to another embodiment of the inventive concept.

15 is a flowchart of an example process for the SSD of FIG. 1 (or the auxiliary processor of FIG. 1) to query its partners for pairing information according to an embodiment of the inventive concept.

16 is a flowchart of an example process for the SSD of FIG. 1 (or the auxiliary processor of FIG. 1) to receive matching data from its partners according to an embodiment of the inventive concept.

FIG. 17 illustrates an example process flow for the SSD of FIG. 1 and/or the auxiliary processor of FIG. 1 to respond to queries from the operating system about it and its partner partners according to an embodiment of the inventive concept picture.

18 is a flowchart of an example process for querying the SSD of FIG. 1 and the auxiliary processor of FIG. 1 and pairing them with the operating system of FIG. 5 according to an embodiment of the inventive concept.

19 is a flowchart of an example process used in the operating system of FIG. 5 to respond to a query about device pairing information from an application according to an embodiment of the inventive concept.

<bio-deposit></bio-deposit>

<sequence-list-text></sequence-list-text>