JP7446167B2 - Lightweight bridge, article including it, and method using the same - Google Patents

Description

The technical idea of the present invention generally relates to storage devices, and more specifically to emulating a PCIe (Peripheral Component Interconnect Express) virtual function (VF) as a PCIe physical function (PF). Regarding.

Devices such as Peripheral Component Interconnect Express (PCIe) devices expose a variety of functionality that can be accessed by other components in a computer system. For example, a host processor can use such functionality exposed by a solid state drive (SSD) to perform various operations within the solid state drive. Such functionality can operate with data stored on the SSD or with data provided by the host. Generally, the functionality exposed by a device is relevant to the normal operation of the device, but such limitations are not required. For example, SSDs are traditionally used to store data, but if the SSD includes a processor, it can be used to offload processing from the host processor.

The functionality exposed by a device may be discovered by the host machine while enumerating the device at startup (or during installation if hot installation of the device is supported). can. As part of discovery, the host machine can query the device for any exposed capabilities, which can then be added to the list of capabilities available for the device.

Functions are classified into two categories: physical and virtual. Physical functions (PF) can be implemented using hardware within a device. A PF's resources can be managed and configured independently of any other PFs provided by the device. A virtual function (VF) is a lightweight function that can be considered a virtualized function. Unlike PFs, VFs are generally associated with a particular PF and generally share resources with their associated PF (and possibly other VFs associated with that PF).

It is preferred that the device exposes the PF since the PFs are independent of each other and the VF may require the use of SR-IOV (Single Root Input/Output Virtualization) for the host to access the VF. However, since the PF is independent, it requires additional hardware and can increase the space required within the device and the power consumed by the device. The SR-IOV protocol can add complexity to the host system software stack, especially for virtualization use cases.

There is a need to provide PF to devices without imposing the cost requirements of PF so that system software complexity can be reduced.

The problem to be solved by the present invention is to provide a device with physical functions (PF) without imposing cost requirements so that the complexity of system software can be reduced.

To solve the above problems, a WBL (lightweight bridge) circuit according to an embodiment of the present invention includes an end point that is connected to a host and exposes a plurality of physical functions (PFs), and a root port that is connected to a device. A root port in which the device exposes at least one PF and at least one virtual function (VF) to the root port, and a plurality of PFs exposed to the host and exposed by the device. an APP-EP (Application Layer-End Point) and an APP-RP (Application Layer-Root Port) for conversion between the at least one PF and the at least one VF; APP-RP implements a mapping between the plurality of PFs exposed by the endpoint and the at least one PF and the at least one VF exposed by the device.

A method according to an embodiment of the present invention for solving the above problem includes the steps of enumerating at least one physical function (PF) exposed by a device using a root port of a light weight bridge (LWB). enumerating at least one virtual function (VF) exposed by the device using the root port of the LWB; generating a plurality of PFs at the endpoint of the LWB for exposure to a host; , and using an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) of the LWB, the plurality of PFs at the end points of the LWB are exposed by the device. The method includes mapping to the at least one PF and the at least one VF.

An article according to an embodiment of the present invention for solving the above problem includes the non-transitory storage medium storing instructions, and when the instructions are executed by a machine, the instructions are stored on a light bridge (LWB). enumerating at least one physical function (PF) exposed by the device using the root port; at least one virtual function (PF) exposed by the device using the root port of the LWB; generating a plurality of PFs at the end point of the LWB for exposure to a host; Root Port) to map the plurality of PFs at endpoints of the LWB to the at least one PF and the at least one VF exposed by the device.

According to one embodiment of the invention, a device can reduce system software complexity without imposing physical functions (PF) cost requirements.

1 illustrates a machine including an LWB that can emulate physical functions (PF) exposed by a light bridge (LWB) using a VF of an SSD according to an embodiment of the technical idea of the present invention; 2 shows additional details of the machine of FIG. 1; Details of the SSD in FIG. 1 are shown. 4a-4c illustrate the LWB of FIG. 1 according to various embodiments of the inventive idea. 4a-4c illustrate the LWB of FIG. 1 according to various embodiments of the inventive idea. 4a-4c illustrate the LWB of FIG. 1 according to various embodiments of the inventive idea. Figures 4a to 4c show details of the configuration administrator. 2 shows a mapping between the PF exposed by the LWB of FIG. 1 and the PF/VF exposed by the SSD of FIG. 1. FIG. 2 illustrates the LWB of FIG. 1 processing a configuration record request from the host of FIG. 1; 2 illustrates the LWB of FIG. 1 processing a configuration reading request from the host of FIG. 1; 4A to 4C illustrate an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) that handle address translation within the LWB; 7 shows the mapping of FIG. 6 modified within the LWB of FIG. 1; FIG. 2 shows a PF exposed by the LWB of FIG. 1 with an associated quality of service (QoS) policy; FIG. 12a and 12b illustrate the LWB of FIG. 1 with bandwidth throttling. 12a and 12b illustrate the LWB of FIG. 1 with bandwidth throttling. 2 illustrates the LWB of FIG. 1 issuing credits to the SSD of FIG. 1; 14a and 14b show that the LWB of FIG. 1 identifies the PF/VF exposed by the SSD of FIG. 1, exposes the PF from the LWB, and the LWB of FIG. 2 shows a flowchart of an example process of generating a mapping between a PF exposed by a PF and a PF/VF exposed by an SSD of FIG. 1 . 14a and 14b show that the LWB of FIG. 1 identifies the PF/VF exposed by the SSD of FIG. 1, exposes the PF from the LWB, and the LWB of FIG. 2 shows a flowchart of an example process of generating a mapping between a PF exposed by a PF and a PF/VF exposed by an SSD of FIG. 1 . 15a and 15b show a flowchart of an exemplary process for the LWB of FIG. 1 to receive a processing request from the host of FIG. 1. 15a and 15b show a flowchart of an exemplary process for the LWB of FIG. 1 to receive a processing request from the host of FIG. 1. 4 shows a flowchart of an exemplary process for the APP-EP and APP-RP of FIGS. 4a-4c to translate addresses between the host of FIG. 1 and the SSD of FIG. 1; FIG. 2 shows a flowchart of an exemplary process for the LWB of FIG. 1 to issue credits to the SSD of FIG. 1; 2 illustrates a flowchart of an example process by which the LWB of FIG. 1 processes a configuration record request. 2 illustrates a flowchart of an exemplary process by which the LWB of FIG. 1 processes a configuration read request. 2 shows a flowchart of an example process by which the LWB of FIG. 1 associates QoS policies with PFs exposed by the LWB of FIG. 1; 2 shows a flowchart of an example process in which the LWB of FIG. 1 dynamically changes the mapping of the PF exposed by the LWB of FIG. 1 and the PF/VF exposed by the SSD of FIG. 1. 22a and 22b show a flowchart of an exemplary process by which the LWB of FIG. 1 performs bandwidth throttling. 22a and 22b show a flowchart of an exemplary process by which the LWB of FIG. 1 performs bandwidth throttling.

Reference will now be made in detail to embodiments of the invention, examples of which are illustrated in the accompanying drawings. In the following detailed description of the disclosure, numerous specific details are set forth in order to provide a thorough understanding of the invention. However, it is to be understood that one of ordinary skill in the art may practice the invention without these specific details. In other instances, well-known methods, processes, components, circuits, and networks have not been described in detail so as not to unnecessarily obscure aspects of the embodiments.

Although terms such as first, second, etc. may be used herein to describe various components, it is to be understood that these components are not limited by these terms. These terms are used to distinguish one component from another component. For example, a first module may be referred to as a second module, and likewise a second module may be referred to as a first module without departing from the scope of the invention.

The terminology used herein to describe the invention is merely for the purpose of describing particular embodiments and is not intended to limit the invention. As used in the description of the invention and the appended claims, references to the singular form include the plural form as well, unless the context clearly dictates otherwise. Additionally, as used herein, the term "and/or" is understood to refer to and include any and all possible combinations of one or more of the associated listed items. As used herein, the terms "comprise" and/or "comprising" identify the presence of the referenced feature, integer, step, act, element, and/or component, but include one or more does not exclude the presence or addition of other features, integers, steps, acts, elements, components and/or groups thereof. The components and features in the drawings are not necessarily drawn to scale.

Embodiments of the inventive concept include methods and systems for emulating multiple physical functions in a device, such as a solid state drive (SSD), using virtual functions supported by the device. The SSD can have multiple NVMe controllers represented by multiple PCIe physical functions (PFs) or PCIe virtual functions (VFs). Each PF or VF provides an NVMe controller that can be used by the host NVMe driver to essentially perform data storage functions. Although the PF has real physical resources, virtual functions share resources with the PF. According to an embodiment of the technical idea of the present invention, a large number of PFs can be exposed to a host using a VF set in an SSD controller. That is, multiple PFs can be emulated by the device and VFs can be used internally. From the host's perspective, the host system software stack references multiple PCIe PFs and the NVMe controllers behind those PFs. Internally, embodiments of the inventive concept can map and convert all host accesses to PFs to VFs.

PCIe PF is independent from any other functionality (physical or virtual). That is, PFs have their own dedicated physical resources, such as memory buffers. Supporting a large number of PFs for a device increases the logic area, power consumption, and complexity of the underlying device. Therefore, to reduce cost and complexity on the device side, the PCIe specification supports virtual functions (VFs). VF shares physical resources with PF and depends on PF for all physical aspects. Such physical aspects include PCIe link control, device control, power management, etc.

Although VF reduces cost and complexity on the device side, VF increases complexity on the system software side. The system software needs to support the SR-IOV (Single Root Input/Output Virtualization) protocol so that it can communicate with the VF. This additional functionality sometimes degrades I/O performance in terms of additional delay. Therefore, from the viewpoint of system software, it is preferable to have a PF.

Embodiments of the technical idea of the present invention enable a device to emulate a PF using a VF in an SSD controller. That is, from the host's perspective, the storage device SSD appears to have a large number of PFs. However, on the device side, such a PF can be emulated using a VF set. To reduce cost, a Lightweight Bridge (LWB) can be used to expose the functionality of a device such as an SSD without the need to implement various functions as a PF in the SSD controller ASIC.

In an exemplary implementation of LWB, a total of 16 functions are implemented by LWB as if they were physical functions, even if the underlying device could implement some or most of the functions in VF rather than PF. Can be exposed. LWB accomplishes the role of a bridge between the host machine and the SSD controller itself. The LWB can be implemented as part of the overall SSD device or as a separate component. The device may be an SSD, and the functionality (1 PF and 15 VFs) is implemented as part of the endpoint of the SSD controller. (SSDs may also generally include a host interface layer (HIL), a flash translation layer (FTL), and a flash controller (FC) for accessing flash memory. ).

The LWB can communicate with the host machine using four lanes of the 3rd generation PCIe bus, while LWB internal communication can be implemented using 16 lanes of the 3rd generation PCIe bus. However, embodiments of the inventive concept may support the use of any particular version of the PCIe bus (or other bus type), all with and internally with the host machine, without limitation, any desired speeds or lanes or bandwidths. It can be understood that the PCIe lane widths and speeds in this description are merely exemplary, and any combination can be implemented using the same concept.

Instead of the SSD controller communicating with the host machine's root port or root complex, the SSD controller can communicate with the LWB's root port. The SSD controller does not need to be aware of this change and can process communications from the root port of the LWB as if they were communications from the host machine. Similarly, a host machine can communicate with an LWB endpoint without knowing that the endpoint is not an SSD controller (implementing exposed functionality). As far as the SSD controller or the host machine is concerned, the party with which they communicate (LWB in the embodiment of the technical idea of the present invention) can be considered as a black box.

The LWB endpoint can expose the same number of functions as the SSD controller endpoint. However, instead of exposing some of these functions in VF, the LWB endpoint can expose all functions in PF. Further, the LWB can include PAPP-EP (PCIe Application Layer for End Point) and PAPP-RP (PCIe Application Layer for Root Port). PAPP-EP and PAPP-RP can manage the mapping from PFs exposed by LWB endpoints to functions (physical or virtual) exposed by SSD controller endpoints. The PAPP-RP may include a configuration translation table that helps map the PCIe configuration space of the host-exposed PF to the PCIe configuration space of the PF and/or VF of the SSD controller EP. Additionally, this table can indicate not only which PF exposed by the LWB endpoint is mapped to which function exposed by the SSD controller endpoint, but also other information related to the mapping (e.g. which SSD (Can controller addresses store data for exposed functions?) The PCIe configuration features and capabilities provided by the LWB endpoints can (often) differ from those provided by the SSD controller endpoints, and configuration translation tables help manage these differences. can be helpful. Additionally, the PAPP-RP may process the conversion of memory base address register (BAR) addresses of PFs exposed to the host and BARs of PFs and/or VFs of the SSD controller EP. Furthermore, PAPP-EP and/or PAPP-RP can include other tables as necessary. The mapping of host exposed PF and SSD controller internal PF/VF is fundamentally flexible and can be dynamic. The mapping may be changed during runtime based on specific events and/or policy changes issued by the host and/or a management entity such as a Board Management Controller (BMC). Examples of such events include virtual machine (VM) migration, SLA, power/performance throttling, date, time changes, etc.

Although PAPP-EP and PAPP-RP may be separate components in some embodiments of the inventive idea, other embodiments of the inventive idea may include these components (and potentially LWB endpoints, root ports, and configuration managers) can be implemented in a specific manner. For example, the LWB can be implemented using a field programmable gate array (FPGA) or an application-specific integrated circuit (ASIC) (just two examples of possible implementations). PAPP-EP and PAPP-RP may communicate using any desired mechanism. For example, intermediate data formats can be defined that can be used to exchange data between PAPP-EP and PAPP-RP in order to call specific functions and return results.

The LWB may also include a configuration manager. The configuration administrator can enumerate the functions (all PFs and VFs) provided by the SSD controller's endpoints. The configuration administrator can then use that information to help "define" the functionality exposed by the LWB's endpoints and configure the configuration space translation table in PAPP-RP. Generally, configuration managers are used primarily at startup. However, the host machine can modify the PF's PCIe configuration space, such as interrupts used to communicate with (LWB) endpoints regarding various functions, or the host machine can activate or deactivate certain functions. Can be activated. A configuration administrator can be used to assist with such changes, if necessary. The LWB may also need to ensure that similar PCIe configuration space changes are properly communicated to the SSD controller. That is, the LWB performs PCIe configuration mirroring between the PF exposed to the host and the PF/VF exposed by the internal SSD controller EP. Thus, the LWB can also manage the functions exposed by the SSD controller.

Since there are two endpoints across the device (one on the LWB and one on the SSD controller), each maintains its own configuration space. These configuration spaces must be synchronized to avoid potential problems or conflicts. When the host sends a configuration record command, the LWB can update the configuration space at the LWB endpoint. Also, the configuration recording command is communicated to the SSD endpoints (via PAPP-EP, PAPP-RP, and Root Port) so that the SSD controller endpoints can also be updated. It is not necessary that all host-initiated configuration recording commands are reflected in the SSD controller. That is, some changes to the host configuration space may not be directly reflected in the backend SSD controller. For example, the host may perform power management changes to the LWB EP, but that change or similar changes may not be performed by the LWB to the SSD controller EP.

When the host sends a configuration reading command, the command can be fulfilled by the LWB's endpoint. The endpoint of the LWB conveys the configuration reading command to the PAPP-EP so that the PAPP-EP can finish the command, and since the two configuration spaces are synchronized, the data in each configuration space should be the same. (Alternatively, the LWB endpoint does not communicate the configuration reading command to the PAPP-EP, and the LWB endpoint can respond to the configuration reading command and terminate the command at that point.)

When the LWB receives a memory read or record transaction (either from the host via the LWB's endpoint or from the SSD controller via the LWB's route point), the LWB transfers the transaction to the other party (the host or SSD, if appropriate). controller). The LWB can use the BAR table in the PAPP-EP and/or PAPP-RP to perform the appropriate address translation. An example of such an address translation for a transaction received from a host is that PAPP-EP can subtract the PF BAR from the received address, and PAPP-RP can subtract its PF BAR from the received address to arrive at the correct address of the SSD controller. It is possible to add a VF BAR to an address.

Embodiments of the technical idea of the present invention may also include an optional intermediate element between PAPP-EP and PAPP-RP, which can be used for mapping, bandwidth control, etc. This optional element can also be used to variably "throttle" the bandwidth for various reasons. For example, QoS requirements or SLAs (Service Level Agreements) may be different for different functions exposed by the endpoints of the LWB. PFs with low bandwidth QoS can be throttled to ensure sufficient bandwidth for PFs with higher QoS bandwidth requirements. Other reasons for throttling bandwidth may include power or temperature. LWB can be used to perform bandwidth throttling on a per-PF basis, or for all PFs based on configuration or policy settings of management entities such as hosts and/or BMCs. Can be done. Temperature or power throttling decisions can be based on both upper and lower thresholds. If power usage or temperature exceeds the upper limit, bandwidth throttling can be applied to all PFs or selective PFs based on policy. Bandwidth throttling may be applied until power or temperature falls below the respective lower threshold.

In the above embodiment of the technical idea of the present invention, the endpoint of the SSD controller is described as providing one PF and 15 VFs, which is mapped to 16 different PFs in the endpoint of the LWB. can be done. Such number is arbitrary. The SSD controller endpoint can provide multiple PFs and VFs, which can be mapped to 16 PFs or more or fewer PFs at the LWB endpoint.

If necessary, the SSD controller's VF can be appropriately migrated within the LWB, along with any appropriate changes made within the LWB and/or the SSD controller. Thus, there is flexibility as the mapping from the PFs exposed by the LWB endpoints to the functions exposed by the SSD controller can be modified during runtime.

Communication within the LWB can be accomplished using any desired technology. For example, the information exchanged between the endpoint, PAPP-EP, PAPP-RP, and root port can use a transaction level packet (TLP) protocol.

The device itself can be of any form factor. For example, SSDs may be used in the U.S., among other possibilities. 2 or FHHL (Full Height, Half Length) form factors. Other types of devices can be similarly packaged in any desired form factor.

Other embodiments of the inventive concept may include multiple SSD controllers, each providing different functionality. For example, each SSD controller can provide a total of eight functions. A multiplexer/demultiplexer may be coupled between the LWB endpoints. This multiplexer/demultiplexer can transmit data related to a particular exposed PF to the appropriate PAPP-EP/PAPPP-RP/RP/Root Port/SSD controller for final execution. Thus, a single LWB can expose more functionality than can be provided by a single SSD controller.

Each SSD controller can communicate with a separate root port of the LWB, and each root controller has its own slice containing the PAPP-EP, PAPP-RP and configuration translation table. In this way, operations associated with one SSD controller may not affect operations associated with other SSD controllers within the LWB.

Such embodiments of the inventive concept can be used, for example, when endpoints on a single SSD controller do not meet all the requirements of a host machine. For example, if an SSD controller only supports 8 PCIe lanes and the host wants to support 16 lanes of bandwidth, multiple SSD controllers can be used to support the required bandwidth. . Alternatively, if the SSD controller only supports a total of 8 features and the host wishes to support 16 features, multiple SSD controllers can be used to provide the required feature set. That is, the LWB can be used to couple many SSD controllers to a host using an appropriate number of PAPP-EP/PAPP-RP/RP slices as a single multi-function PCIe storage device.

As with other embodiments of the inventive concept, the numbers used are illustrative and not limiting. Therefore, the LWB endpoint can use any type of bus, any version of the corresponding bus, and many lanes of the corresponding bus, and the LWB endpoint can expose many PFs, and each SSD controller The number of PFs exposed by the LWB can be changed, the internal bus type, version and speed can be changed by the connection to the SSD controller (can be changed individually), and the number of SSD controllers connected to the LWB can be changed by the connection to the SSD controller. (and can be coupled to different or the same route points of the LWB), and so on.

FIG. 1 shows a machine including an LWB that can emulate physical functions (PF) exposed by a light weight bridge (LWB) using a VF of a device according to an embodiment of the technical idea of the present invention. Also shown in FIG. 1 is a machine 105 that can be called a host. Machine 105 may include a processor 110. Processor 110 can be any of a variety of processors. For example, it may be an Intel Xeon, Celeron, Itanium, or Atom processor, an AMD Opteron processor, an ARM processor, etc. Although FIG. 1 shows a single processor 110 of machine 105, machine 105 can include multiple processors, each of which can be a single core or multi-core processor, and can be made in any desired combination.

Machine 105 may also include memory 115. The memory 115 includes flash memory, DRAM (Dynamic Random Access Memory), SRAM (Static Random Access Memory), persistent RAM, FRAM (Persistent Random Access Memory), and FRAM. RAM (Ferroelectric Random Access Memory) or MRAM (Magnetoresistive Random Access Memory) It may be any variety of memory such as NVRAM (Non-Volatile Random Access Memory). Also, memory 115 may be any desired combination of different memory types. Machine 105 can also include a memory controller 120 that can be used to manage access to memory 115.

Further, the machine 105 can include an SSD (Solid State Drive) 125. The SSD 125 can be used to store data and the physical functions (PF) and virtual functions (VF) used by the processor 110 (and the software running thereon) to operate the various capabilities of the SSD 125. can be fully exposed. Although FIG. 1 shows an SSD 125, embodiments of the inventive concept may include any type of device that provides PF and VF. For example, other types of storage devices can be used in place of the SSD 125, such as hard disk drives that provide PF and VF, such as devices that provide basic functions other than data storage. In the remainder of this document, any references to SSD 125 include references to other types of devices that can provide PF/VF. In some embodiments of the technical idea of the present invention, the SSD 125 can be connected to a PCIe (Peripheral Component Interconnect Express) bus, and can provide a PCIe PF and VF. Embodiments of can use other interfaces. Processor 110 may execute a device driver 130 that may assist in accessing SSD 125.

LWB 135 may be located between SSD 125 and the remainder of machine 105. The LWB can act as a bridge between the SSD 125 and the rest of the machine 105, exposing the functionality of the SSD 125 as a PF instead of a VF.

Although FIG. 1 depicts machine 105 as a server (which may be a stand-alone or rack server), embodiments of the inventive concept may include any desired type of machine 105 without limitation. For example, machine 105 may be replaced by a desktop or laptop computer or any other machine that would benefit from embodiments of the present invention. Machines 105 may also include specialized portable computer machines, tablet computers, smart phones, and other computer machines. Applications that can access data from the SSD 125 may also be remote from the machine 105 and access the machine 105 through network connections that traverse one or more networks of any type (wired, wireless, global, etc.). Can be located on other machines.

FIG. 2 shows additional details of the machine of FIG. In FIG. 2, machine 105 generally includes one or more processors 110, which may include a memory controller 120 and a clock 205, which may be used to orchestrate the operation of the components of device 105. Processor 110 may also be coupled to memory 115, which may include, by way of example, random access memory (RAM), read-only memory (ROM), or other state storage media. Processor 110 may also be coupled to a storage device 125 and a network connector 210, which may be, for example, an Ethernet connector or a wireless connector. Processor 110 can also be coupled to bus 215, which includes, among other components, a user interface 220 and an I/O interface that can be managed using I/O engine 225. Port can be attached.

FIG. 3 shows details of the SSD of FIG. In FIG. 3, the SSD 125 includes a HIL 305, an SSD controller 310, and various flash memory chips 315-1 through 315-8 ("flash memory storage") that can be incorporated into the various channels 320-1 through 320-4. ”) can be included. HIL 305 may manage communications between SSD 125 and other components (such as processor 110 of FIG. 1 and LWB 135 of FIG. 1). HIL 305 may also manage communications with devices that are separate from SSD 125, ie, not considered part of device 105, but that communicate with SSD 125, such as through one or more network connections. Such communications may include read requests to read data from the SSD 125, record requests to write data to the SSD 125, and delete requests to delete data from the SSD 125. HIL 305 can manage interfaces through only a single port, or can manage interfaces through multiple ports. Alternatively, SSD 125 can include multiple ports, each of which can have an individual HIL 305 to manage interfaces across its ports. Also, embodiments of the technical idea of the present invention can mix possibilities (e.g., an SSD with three ports has one HIL to manage one port and one HIL to manage the other two ports). and a second HIL for managing ports).

SSD controller 310 may manage reading and recording operations, as well as garbage collection and other operations, on flash memory chips 315-1 through 315-8 using a flash memory controller (not shown in FIG. 3). SSD controller 310 may include FTL 325, flash controller 330, and endpoints 335. FTL manages the mapping of logical block addresses (LBA) (used by host 105 in FIG. 1) to physical block addresses (PBA) where data is actually stored on SSD 310. be able to. By using FTL 325, host 105 of FIG. 1 does not need to be informed when data moves from one block to another within SSD 125.

The flash controller 330 can manage data recording to and reading from the flash chips 315-1 to 315-8. Endpoint 335 can act as an endpoint to SSD 125, which can be coupled to a root port on yet another device (such as host 105 in FIG. 1 or LWB 135 in FIG. 1).

Although FIG. 3 shows the SSD 125 as having eight flash memory chips 315-1 to 315-8 incorporated into four channels 320-1 to 320-4, the technical idea of the present invention Embodiments of can support multiple flash memory chips integrated into multiple channels. Similarly, although FIG. 3 shows the structure of an SSD, other storage devices (eg, hard disk drives) can be implemented using different structures with similar potential benefits.

4a to 4c illustrate the LWB of FIG. 1 according to various embodiments of the inventive concept. In FIG. 4a, LWB 135 is shown as including endpoint 405, APP-EP 410, APP-RP 415 and root port 420. Endpoint 405 can be used to communicate with the root port of another device, such as host 105 in FIG. In Figure 4a, endpoint 405 is shown as using a PCIe 3rd generation interface that exposes 16 PFs to upstream devices and has 4 lanes that can be used to communicate with upstream devices. . Thus, the interface to host 105 in FIG. 1 may be a PCIe 3 generation interface with four lanes, as illustrated by interface 425. Similarly, root port 420 can communicate with other device endpoints, such as SSD 125. Thus, the interface to SSD 125 may be a PCIe 3 generation interface with four lanes, as illustrated by interface 430. In FIG. 4a, root port 420 is shown as using a PCIe generation 3 interface with four lanes that can be used to communicate with downstream devices. In FIG. 4a, root port 420 is shown as having one PF and 15 VFs enumerated by SSD 125, and endpoint 405 is shown as exposing 16 PFs. One PF exposed by endpoint 405 corresponds to each function (physical or virtual) exposed by SSD 125.

Endpoint 405 may communicate with APP-EP 410, which in turn may communicate with APP-RP 415. APP-EP 410 and APP-RP 415 can manage the translation of information between endpoint 405 and root port 420. FIG. 4a shows details of how endpoint 405 communicates with APP-EP 410, how APP-EP 410 communicates with APP-RP 415, or how APP-RP 415 communicates with root port 420. No, since any desired communication mechanism can be used. For example, endpoint 405, APP-EP 410, APP-RP 415, and root port 420 may have PCIe or other interfaces such as an AXI (Advanced eXtensible Interface) bus that has the desired version of the interface and includes the desired number of data bus widths. It is possible to communicate using the bus. Alternatively, endpoint 405, APP-EP 410, APP-RP 415, and root port 420 may communicate using a proprietary messaging scheme using any desired bus/interface. Embodiments of the inventive concept may also include other communication mechanisms between the endpoint 405, APP-EP 410, APP-RP 415, and root port 420. There may be no relationship between the internal communication methods of LWB 135 and the communication methods from LWB 135 to host 105 or SSD 125 of FIG.

APP-RP 415 may include a configuration table 435. Configuration table 435 may store configuration information about LWB 135. Examples of such configuration information include the mapping between the PF exposed by endpoint 405 and the PF/VF provided by SSD 125 (and determined by enumeration via root port 420). Can be done. Additionally, the configuration information stored in the configuration table 435 may include information about a QoS policy (also referred to as an SLA (Service Level Agreement)) that may be related to a particular PF exposed by the endpoint 405. . Configuration manager 440 can store information in configuration table 435 for use in configuring LWB 135 . The configuration manager 440 can also be used to determine information about the functionality exposed by the SSD 125, providing similar (or the same) functionality (but using only PF rather than PF and VF). Endpoint 405 can be programmed to: Although the details of what the configuration manager 440 does may depend on the specific functionality provided by the SSD 125 (the configuration manager 440 may end up providing a set of PFs that match the PFs and VFs provided by the SSD 125), The principle is generally to determine the configuration of the individual PFs/VFs exposed by the SSD 125, and set the appropriate number of PFs exposed by the endpoint 405. It can be summarized as follows: and configuring these PFs to match the configuration of the PF/VFs exposed by SSD 125.

Although FIG. 4a shows APP-EP 410 and APP-RP 415 as separate components, embodiments of the present inventive concept may combine both of these components into a single component (as previously discussed, APP-EP 410 and APP-RP 415 - responsible for handling the functionality of both the EP 410 and the APP-RP 415). In fact, the entire LWB 135 may be embodied in a single unit rather than separate components communicating with each other. LWB 135 (as well as endpoint 405, APP-EP 410, APP-RP 415, root port 420, and configuration manager 440) may be implemented using any desired scheme. Embodiments of the technical idea of the invention can be implemented on general-purpose processors, FPGAs (Field Programmable Gate Arrays), ASICs (Application-Specific Integrated Circuits), GPUs (Graphics Pros) with suitable software, among other possibilities. cessing Unit) and LWB 135 (and/or its components individually and/or collectively) may be implemented using a General Purpose GPU (GPGPU).

In FIG. 4a (and similarly in FIGS. 4b and 4c below), any specific numbers illustrated are merely exemplary; embodiments of the inventive concept may include other numbers. . For example, although root port 420 is shown as having one PF and 15 VFs enumerated from SSD 125, SSD 125 may expose any number (0 or more) of PFs and VFs. Yes (every exposed VF depends in part on the PF's hardware, but there must be at least one exposed PF that provides the hardware for any exposed VF). Similarly, although endpoint 405 is shown as exposing 16 PFs, endpoint 405 can expose any number (zero or more) of PFs to host 105 in FIG. Note that while endpoint 405 exposes the same number of total capabilities as SSD 125, there does not need to be a one-to-one correspondence between the capabilities exposed by SSD 125 and the capabilities exposed by endpoint 405. For example, some functions exposed by SSD 125 may not have a corresponding PF exposed by endpoint 405, or a single PF exposed by endpoint 405 may have multiple functions exposed by SSD 125 (physical and/or virtual). As an example of the former, a recording request can be communicated to only one SSD at a time, which leaves the ability to support recording requests to non-selected SSDs that have no corresponding PF exposed by the endpoint 405. As an example of the latter, in an embodiment of the inventive concept where the LWB 135 is coupled to multiple SSDs (as shown in FIG. Although only one PF can be exposed to the host 105 of FIG. 1 by the endpoint 405, a request by the host 105 of FIG. 1 to perform garbage collection is transmitted to all SSDs coupled to the LWB 135. Can be done.

In a similar manner, any version of the specific product shown in FIG. 4a is merely exemplary, and embodiments of the inventive concept may use other products or other versions of the product. For example, FIG. 4a shows LWB 135 communicating with host 105 (via interface 425) and SSD 125 (via interface 430) of FIG. 1 using PCIe3 generation with four lanes. Other embodiments of the inventive concept may use other generations of PCIe buses/interfaces, or other numbers of lanes, or other types of buses, such as AXI (Advanced eXtensible Interface) buses. . For example, FIG. 4b is similar to FIG. 4a except that interface 425 and interface 430 use PCIe3 generation with eight lanes instead of four.

In some embodiments of the present invention, a single SSD 125 may not provide sufficient functionality for the host 105 of FIG. For example, if the SSD 125 of FIGS. 4a and 4b provides only one PF and seven VFs, thereby not providing a particular functionality desired by the host 105 of FIG. It can be replaced by another device. Alternatively, LWB 135 can be coupled to multiple devices, as shown in Figure 4c.

In FIG. 4c, LWB 135 is shown coupled to SSDs 125-1 and 125-2 via interfaces 430-1 and 430-2, respectively. Since SSDs 125-1 and 125-2 each provide 1 PF and 7 VFs (as seen from root ports 420-1 and 420-2), neither SSD 125-1 nor 125-2 It is not possible to provide 16 functions individually. However, SSD 125-1 and SSD 125-2 together provide 16 functions. Therefore, by aggregating the resources (exposed functions, etc.) of SSDs 125-1 and 125-2, LWB 135 can provide a total of 16 PFs without a single SSD providing all functions. can do.

As can be seen in Figure 4c, the LWB 135 includes only one endpoint 405, two APP-EPs 410-1 and 410-2, APP-RPs 415-1 and 415-2 and a root port 420-1, respectively. and 420-2. In this manner, LWB 135 can aggregate the functionality provided by SSDs 125-1 and 125-2 to expose all 16 functionality from a single endpoint (endpoint 405). However, LWB 135 may also include a multiplexer/demultiplexer 445 because the various PFs exposed by endpoint 405 may be mapped to functions on SSDs 125-1 and 125-2. Multiplexer/demultiplexer 445 sends requests related to a particular exposed PF of endpoint 405 to an appropriate PF with a communication path coupled to SSD 125-1 or 125-2 providing the corresponding PF or VF. APP-EP 410-1 or 410-2. Although FIGS. 4a and 4b do not show the multiplexer/demultiplexer 445 (as there is only one SSD 125 coupled to the LWB 135), the concept of the present invention is that the LWB 135 is coupled to only one SSD 125. In embodiments, LWB 135 may still include a multiplexer/demultiplexer 445. While the multiplexer/demultiplexer 445 may not add any functionality, there is also no real cost associated with including the multiplexer/demultiplexer 445 (although the LWB 135 only connects to a single device). If it is not possible, there is no benefit to including a multiplexer/demultiplexer).

It is noted that embodiments of the technical idea of the present invention can aggregate resources in addition to just exposed functions. For example, in FIG. 4c, interfaces 430-1 and 430-2 can each include eight lanes of PCIe 3 generation bus/interface. However, since SSDs 125-1 and 125-2 can be used in parallel (i.e., SSDs 125-1 and 125-2 can all process requests at the same time), LWB 135 can The host 105 of FIG. 1 can be provided with a 16 lane PCIe third generation bus/interface. In the same manner, the bandwidth provided by each of SSD 125-1 and 125-2 is aggregated, and the LWB reports the same bandwidth as the sum of the bandwidth provided separately by SSD 125-1 and 125-2, respectively. (advertise). Embodiments of the inventive concept may also aggregate other resources of functionality, PCIe lanes or bandwidth.

As in FIGS. 4a and 4b, any number or version shown in FIG. 4c is only used as an example, and embodiments of the technical idea of the present invention may support other numbers or versions. . For example, SSDs 125-1 and 125-2 do not need to provide the same number of exposed functions (physical and/or virtual) or necessarily use the same generation or number of PCIe bus/interface lanes. do not have.

In FIGS. 4a-4c, LWB 135 is shown separately from SSD 125. However, embodiments of the inventive concept may combine these two devices into a single unit. That is, SSD 125 may include within its case LWB 135 located in front of HIL 305 in FIG. 3 (or at least in front of SSD controller 310 in FIG. 3). Embodiments of the inventive concept are not limited to including LWB 135 within a single SSD. Additionally, a single housing containing multiple SSDs may include the LWB 135 to achieve the implementation shown in FIG. 4c. For the purposes of this document, the term “connected” or similar terminology refers to the term “connected” or similar terms because it physically shares any hardware with the device, or because the LWB 135 is physically connected to the SSD 125. , refers to any device that communicates with LWB 135, regardless of which interface it is connected to.

As mentioned above, one of the problems with devices that expose VFs is that the host 105 of FIG. 1 must implement SR-IOV software in order to access the exposed VFs. This SR-IOV software adds delay to communication with the device. However, since the SR-IOV sequence used to manage access to a device's VF is previously known, the SR-IOV sequence can be implemented using a state machine, and the host 105 in FIG. The burden of having to use SR-IOV to access VFs can be reduced. Also, since the state machine can be implemented using hardware, using the state machine in the LWB 135 instead of the SR-IOV software in the host 105 of FIG. 1 can reduce the delay in request processing. . Using a state machine within the LWB 135 to implement the SR-IOV sequence essentially offloads the entire burden of the SR-IOV protocol from the host to the device. In other words, host 105 of FIG. 1 may not be able to know if any implementation of SR-IOV exists in the device with which host 105 of FIG. 1 communicates.

FIG. 5 shows details of the configuration manager 440 of FIGS. 4a-4c. The configuration manager 440 may include a single root input/output virtualization (SR-IOV) sequence 505 and a state machine 510. SR-IOV sequence 505 may be a sequence implemented in SR-IOV software within host 105 of FIG. 1 and may be performed using state machine 510. The SR-IOV sequence 505 can be stored in a ROM (Read-only memory) within the configuration manager 440. The state machine 510, together with the LWB 135 itself and its components shown in FIGS. 4a-4c, can be implemented using a general purpose processor, FPGA, ASIC, GPU or GPGPU, among other possibilities. .

FIG. 6 shows the mapping between the PF exposed by LWB 135 of FIG. 1 and the PF/VF exposed by SSD 125 of FIG. 1 (or SSD 125-1 and 125-2 of FIG. 4c). In FIG. 6, PF 605 is the PF exposed by LWB 135 of FIG. 1 (more specifically, the PF exposed by endpoint 405 of FIGS. 4a-4c). PF/VF 610, on the other hand, is the functionality (both physical and virtual) exposed by SSD 125 in FIG. Mapping 615 may then indicate the mapping between PF 605 and PF/VF 610. Although the configuration administrator 440 of FIGS. 4a-4c can use any desired mechanism to determine which PFs in PF 605 are mapped to which PFs/VFs in PF/VF 610, FIG. The mapping shown is illustrative and fundamentally arbitrary. The mapping may be implemented by considering guidance and/or policy set by the host 105 in FIG. 1 (or a BaseBoard Management Controller (BMC) in the host 105 in FIG. 1) or the SSD 125 in FIG. can.

FIG. 7 illustrates LWB 135 of FIG. 1 processing configuration record requests from host 105 of FIG. In FIG. 7, LWB 135 (more specifically, endpoint 405) of FIG. 1 may receive a configuration record request 705. The endpoint 405 can then process the configuration record request 705 locally and perform any changes included in the configuration record request 705.

Note that configuration record request 705 may not require changes to SSD 125. For example, a QoS policy set by host 105 in FIG. 1 may only affect the PF exposed by endpoint 405 and does not require any changes within SSD 125. However, in some situations, the configuration record request 705 may request modification of the SSD 125. For example, a configuration record request may change data about basic functionality of the SSD 125, rather than data that can only be managed by the LWB 135 of FIG. In that situation, endpoint 705 may communicate configuration record request 705 to SSD 125 via root port 420 (as indicated by dotted arrows 710 and 715). The configuration record request 705 is communicated to the root port 420 via the APP-EP 410 of FIGS. 4a-4c and the APP-RP 415 of FIGS. 4a-4c, or via the configuration manager 440 of FIGS. 4a-4c. can be done. The configuration table 435 of FIGS. 4a and 4b can be used to determine whether the configuration record request 705 must also be applied to the SSD 125 (if the configurations of the endpoint 405 and SSD 125 are mirrored to each other). ).

As in FIGS. 4a-4c, the details of how endpoint 405 (and possibly SSD 125) can be configured are highly dependent on the details of configuration record request 705. However, once the details of the configuration record request 705 are known, changes to the endpoint 405 (and possibly the SSD 125) can be easily accomplished.

As mentioned above, the configurations of endpoint 405 and SSD 125 preferably mirror each other. However, as mentioned above, there may be some configurations that apply only to endpoint 405 (or are not important to SSD 125 since endpoint 405 can handle such changes). If configuration changes are not important to SSD 125, such configuration changes need not be communicated to SSD 125.

In FIG. 7, configuration record request 705 is described as originating from host 105 of FIG. However, embodiments of the inventive concept may support SSD 125 requesting configuration changes of endpoint 405 of FIGS. 4a-4c. That is, the SSD 125 of FIG. 1 can dynamically request changes to the configuration, features, or capabilities of the PF exposed by the endpoint 405 of FIGS. 4a-4c from the host 105 of FIG. 1 during runtime. . For example, SSD 125 of FIG. 1 can increase or decrease the number of interrupt vectors for the PF exposed by endpoint 405 of FIGS. 4a-4c. Such changes can be made by the host 105 of FIG. 1 (via the LWB 135 of FIG. 1) using a higher level storage communication protocol such as Non-Volatile Memory Express (NVMe). This may be due to changes in application requirements communicated to SSD 125.

FIG. 8 illustrates the LWB 135 of FIG. 1 processing configuration read requests from the host 105 of FIG. In FIG. 8, endpoint 405 may receive a read configuration request 805 from host 105 of FIG. Endpoint 405 can read the requested configuration information and return it as configuration information 810 to host 105 of FIG.

Like the configuration record request 705 of FIG. 7, the configuration reading request 805 can be communicated to the SSD 125 to be read from the SSD 125. Accordingly, the configuration read request 805 can be transmitted to the root port 420 and the SSD 125 as configuration read requests 815 and 820, respectively, and the configuration information 810 is returned as configuration information 825 and 830. However, because the configuration of the endpoint 405 should mirror the configuration of the SSD 125, it may not be necessary to communicate the read configuration request 805 to the SSD 125 to determine the requested configuration information. Also, like the configuration record request 705 of FIG. 7, the configuration reading request 805 can be sent via the APP-EP 410 of FIGS. 4a-4c and the APP-RP 415 of FIGS. 4a-4c, or configuration manager 440 to root port 420.

FIG. 9 shows the APP-EP (Application Layer-End point) 410 of FIGS. 4a-4c and the APP-RP (Application Layer-End point) of FIGS. Layer-Root Port) 415. In FIG. 9, address 905 may be an address received from host 105 of FIG. 1 (eg, an NVMe register that host 105 of FIG. 1 requests to read). The APP-EP 410 can then pull a host BAR (Base address register) 910 for the PF that is invoked by the host 105 of FIG. The APP-RP 415 may then add an SSD BAR 915 for the PF/VF to which the requested PF of the endpoint 405 of FIGS. 4a-4c is mapped, thus generating an SSD address 920. be able to. In this manner, APP-EP 410 and APP-RP 415 can translate addresses from the host's perspective into addresses that can be processed by SSD 125 of FIG.

It should be noted that such a process can be used in reverse to further convert the SSD address into an address from the host's perspective. Thus, APP-RP 415 can subtract SSD BAR 915 from SSD address 920, and APP-EP 410 can generate host address 905 by adding host BAR 910.

FIG. 10 shows the mapping of FIG. 6 modified within LWB 135 of FIG. There are various reasons why mapping 615 can be changed. For example, storage parameters 1005 can trigger changes to mapping 615. For example, when the available capacity on a particular SSD falls below a threshold amount of free space, new recording requests may be transmitted to other SSDs coupled to LWB 135 in Figure 1, such as SSD 125-2 in Figure 4c. can be done. Alternatively, the date 1010 or the time of the date 1015 can trigger a change to the mapping 615. For example, peak hours for a particular request on a particular host 105 may be between 6:30 a.m. and 8:00 a.m., and between 5:00 p.m. and 9:00 p.m. The bandwidth associated with the PF may increase during certain times and decrease at other times. The date 1010 and date time 1015 can be generalized with any date and/or time related trigger without having to be specified using existing or known date/time values. For example, even if the specific time such a request begins is not known (the duration of a sporting event is approximately known, but can be shorter or longer depending on the event itself), moving home when a sporting competition ends Fans can request directions using their smartphone's GPS application. Bandwidth usage 1020 itself may also trigger changes to mapping 615, for example, to maintain a balanced load on the SSD coupled to LWB 135 of FIG. 1. Finally, a change 1025 in the QoS policy (referred to as policy in the figure) can trigger a change in the mapping 615. For example, adding a new QoS policy may require changes to the feature mapping method. Embodiments of the inventive concept may also include other triggers for changing the mapping 615. Regardless of the trigger, as a result of the change, mapping 615 can be replaced by mapping 1030, which still represents the PF exposed by endpoint 405 in FIGS. 4a-4c as exposed by SSD 125 in FIG. It maps to PF/VF, but probably in another arrangement.

FIG. 11 shows a PF exposed by the LWB of FIG. 1 with an associated quality of service (QoS) policy. In FIG. 11, one PF (exposed by endpoint 405 of FIGS. 4a-4c) is shown with a single QoS policy 1105 associated with the exposed PF. However, embodiments of the inventive concept may include exposed PFs with any number of associated QoS policies. For example, some PFs exposed by endpoints 405 in FIGS. 4a-4c may not have associated QoS policies. Other PFs exposed by endpoint 405 in FIGS. 4a-4c may have more than one associated QoS policy.

Given the QoS policy 1105 associated with the PF exposed by the endpoint 405 of FIGS. 4a-4c, the LWB 135 of FIG. 1 can enforce that QoS policy according to its specifications. In other words, the details of how the LWB 135 of FIG. 1 enforces a particular QoS policy may not be discussed here since specifications may vary widely. However, as an example, a QoS policy 1105 may specify a maximum (and/or minimum) bandwidth for a particular PF (thus ensuring that a particular PF receives a fair share of the bandwidth). or ensure that a specific PF is allocated a specified bandwidth). 1 by preventing communications using the corresponding PF/VF on the SSD 125 of FIG. 1 from exceeding the maximum bandwidth, or the PF/VF on the SSD 125 of FIG. By ensuring that communications using the PF reserve a minimum bandwidth for exposed PFs, the LWB 135 of FIG. 1 can ensure that the QoS policy 1105 is satisfied.

Although the LWB 135 of FIG. 1 can enforce the QoS policy 1105, verifying that the policy is appropriate is not possible if the host 105 of FIG. 1 (or the SSD 125 of FIG. 1 requests enforcement of the policy). According to SSD 125) in FIG. For example, assume that the maximum bandwidth of SSD 125 in FIG. 1 is 100 Gb/s and that a total of 16 functions (PF and VF) are supported. If the host assigns a QoS policy that guarantees a minimum of 10 GB/s of bandwidth to each PF exposed by LWB 135, the total allocated bandwidth is 160 GB/s, which exceeds the capabilities of SSD 125 in Figure 1. exceed. As a result, some PFs cannot satisfy the associated QoS policy. Therefore, while the LWB 135 in FIG. 1 enforces the QoS policy 1105, the LWB 135 may combine it with other QoS policies assigned to various PFs without checking whether the QoS policies 1105 can all be enforced at the same time.

Therefore, there is a difference between enforcing a QoS policy and allowing a QoS policy to be enforced at all times. LWB 135 of FIG. 1 may do the former and not the latter. However, just because a set of QoS policies cannot be enforced simultaneously does not mean that there will come a time when no individual QoS policy will be satisfied. For example, considering again that the SSD 125 of FIG. 1 provides a total bandwidth of 10 GB/s, the host 105 of FIG. Assume that we specify a QoS policy that guarantees a minimum bandwidth of 6 GB/s to each PF. Collectively, both QoS policies cannot be satisfied because each PF is "reserved" 6 GB/s of the available 10 GB/s bandwidth of SSD 125 in FIG. However, if it is known that it is logically (or physically) impossible to call both functions at the same time (for example, one function may read data on the SSD 125 in FIG. In connection with recording data to 125 and other functions, SSD 125 of FIG. 1 performs an internal consistency check that prevents SSD 125 of FIG. 1 from responding to other functions until the consistency check is completed. host 105 of FIG. 1 can specify both QoS policies together. Even if they cumulatively exceed the bandwidth provided by SSD 125 in Figure 1, both policies will never be enforced at the same time, thus causing a logical rather than an actual (or more accurately, potential) conflict. There is only a conflict of interest.

As discussed above, the LWB 135 of FIG. 1 sometimes has a particular PF exposed by, for example, the endpoint 405 of FIGS. Bandwidth throttling may need to be performed to prevent the use of bandwidth. 12a and 12b illustrate the LWB 135 of FIG. 1 performing bandwidth throttling. In FIG. 12a, LWB 135 is shown as receiving "high" or "large" bandwidth 1205 from host 105 of FIG. If this bandwidth is too large for any reason, LWB 135 may throttle the bandwidth to SSD 125 in FIG. 1, as shown as "low" or "small" bandwidth 1210. Figure 12b shows the opposite situation. LWB 135 may have "high" or "large" bandwidth 1215 with SSD 125 of FIG. 1, but may throttle bandwidth 1220 with host 105 of FIG. Thus, if the available bandwidth of the SSD 125 of FIG. 1 is higher than the maximum bandwidth of the SLA configured for the PF, the LWB 135 may throttle the bandwidth.

Embodiments of the inventive concept may perform bandwidth throttling for various reasons. (The bandwidth associated with a particular PF exposed by the endpoint 405 of FIGS. 4a-4c can be throttled if the bandwidth for that PF is too large.) What is the QoS policy 1105 of FIG. 11? Alternatively, other reasons for bandwidth throttling may include temperature or power consumption. For example, if the temperature of LWB 135 (or SSD 125 in FIG. 1) becomes too high (ie, exceeds some threshold), LWB 135 may throttle its bandwidth to reduce the temperature. Then, if the temperature drops enough (which can mean dropping below the original threshold, or dropping below some other threshold that is lower than the original threshold), the LWB 135 may discontinue bandwidth throttling. Can be done. Power consumption is the same as temperature, except that LWB 135 (or SSD 125 in Figure 1) power consumption can trigger bandwidth throttling, and a reduced power consumption threshold releases bandwidth throttling. Bandwidth throttling can be triggered by a method. These thresholds may be stored somewhere within LWB 135. Yet another reason why the bandwidth may be throttled may be because of the priority set for the exposed PF by the endpoint 405 of FIGS. 4a-4c. If different PFs are used, the bandwidth of the lower priority PF may be throttled in favor of the bandwidth of the higher priority PF.

Yet another reason to throttle bandwidth may be to manage QoS or SLA. For example, host 105 in FIG. 1 may only be paying for a lower level of bandwidth than LWB 135 can provide. Thus, although host 105 of FIG. 1 and LWB 135 may communicate using a higher overall bandwidth, LWB 135 does not ensure that the service provided is greater than that guaranteed to host 105 of FIG. , the bandwidth to the host 105 of FIG. 1 can be limited. In other words, the LWB 135 may limit or determine a limit on the maximum storage bandwidth for the PF based on an SLA or pricing plan.

Although FIGS. 12a and 12b specifically discuss bandwidth, it is understood that other resources can be similarly monitored and throttled for communication with the host 105 of FIG. 1 or the SSD 125 of FIG. Must be kept in mind. For example, the delay can be controlled to some extent to favor a PF with a lower target delay than a PF with a higher target delay.

LWB 135 may measure and monitor the bandwidth (or other resources) consumed by each PF individually exposed by endpoint 405 of FIGS. 4a-4c. Bandwidth can be measured and monitored in both directions: from host to device (host recording operations) and from device to host (host reading operations). Also, bandwidth throttling can be performed independently in either direction. Bandwidth (or other resource) throttling can be accomplished as a result of both measured bandwidth and QoS policy settings.

FIG. 13 shows LWB 135 of FIG. 1 issuing credits to SSD 125 of FIG. Credits are one way that LWB 135 can manage the amount of bandwidth used by SSD 125. Given a particular request, LWB 135 can issue a particular number of credits 1305, each credit 1305 indicating a particular amount of data that SSD 125 is capable of transmitting. Thus, the number of credits 1305 issued by LWB 135 can control the bandwidth of SSD 125. LWB 135 may issue enough (or nearly enough or other desired number) credits 1305 to cover data transmissions. When the SSD 125 transmits data, credits 1305 are used to transmit the data. If SSD 125 does not have available credits, SSD 125 cannot transmit data until new credits are issued.

Credits 1305 can be issued in any desired manner. In some embodiments of the present invention, LWB 135 may transmit credits 1305 to SSD 125 via a message, which may be a proprietary message, for example. In other embodiments of the inventive concept, the LWB 135 may record the credit 1305 to a specific address on the SSD 125, such as a reserved address in the NVMe address space. In yet another embodiment of the inventive concept, LWB 135 may record credit 1305 to an address within LWB 135 (again, possibly a reserved address). The SSD 125 can then read the address to know which credits 1305 are available. Using credits 1305 is one way to throttle the bandwidth of SSD 125. By limiting the number of credits 1305 issued to SSD 125, SSD 125 can be prevented from downloading all the data needed for a particular transaction within a given time unit. By reducing the bandwidth of SSD 125, SSD 125 can experience reduced power consumption and/or lower temperatures. Eventually, once the power consumption and/or temperature falls to an acceptable level (which can be different than the level at which bandwidth throttling can begin, as discussed above with reference to FIG. 12), the LWB 135 Bandwidth throttling can be interrupted.

In other embodiments, LWB 135 may insert idle periods between data transmission packets to achieve bandwidth throttling. By adjusting the inter-packet spacing of data packets based on measured bandwidth (or other resources) and QoS policy settings, the LWB 135 can achieve bandwidth limits for individual PFs or for all PFs. can be achieved collectively.

14a and 14b show that the LWB of FIG. 1 identifies the PF/VF exposed by the SSD 125 of FIG. 1, exposes the PF from the LWB 135, and FIG. 2 shows a flowchart of an example process for generating a mapping between the PF exposed by LWB 135 of FIG. 1 and the PF/VF exposed by SSD 125 of FIG. At block 1405 of FIG. 14a, the LWB 135 of FIG. 1 may enumerate the PFs and VFs exposed by the SSD 125 of FIG. At block 1410, LWB 135 of FIG. 1 may generate the PF exposed by LWB 135 of FIG. 1 (more specifically, the PF exposed by endpoint 405 of FIGS. 4a-4c). Note that the number of PFs generated by LWB 135 of FIG. 1 is not necessarily the same as the number of PFs and VFs exposed by SSD 125 of FIG. A particular feature exposed by SSD 125 in FIG. 1 may not have a corresponding PF exposed by LWB 135 in FIG. 1, and a single PF exposed by LWB 135 in FIG. It can be mapped to multiple PFs/VFs of the SSD 125. At block 1415, LWB 135 of FIG. 1 may determine if there are other connected devices to enumerate (eg, SSD 125-2 of FIG. 4c). If so, the process can return to block 1405 to enumerate the PF and VF of the next device.

Assuming that all connected devices have been enumerated, at block 1420 (FIG. 14a), the LWB 135 of FIG. 1 transfers the PF exposed by the endpoint 405 of FIGS. and other connected devices) to the exposed PFs and VFs. At block 1425, LWB 135 of FIG. 1 may determine other resources, such as bandwidth, for SSD 125 of FIG. At block 1430, the LWB 135 of FIG. 1 may aggregate the resources of all connected devices. In this manner, LWB 135 of FIG. 1 is believed to provide higher overall resources than any individual device.

At block 1435, LWB 135 of FIG. 1 may receive an enumeration request from host 105 of FIG. At block 1440, the LWB 135 of FIG. 1 may respond to the enumeration request of the host 105 of FIG. 1 by exposing the PF of the endpoint 405 of FIGS. 4a-4c.

15a and 15b show a flowchart of an exemplary process for the LWB of FIG. 1 to receive a processing request from the host of FIG. 1. In FIG. 15, at block 1505, the LWB 135 of FIG. 1 may receive a request from the host 105 of FIG. 1 at any PF exposed by the endpoint 405 of FIGS. 4a-4c. Which PF the request goes to and which function the PF indicates is irrelevant to the analysis. At block 1510, the LWB 135 of FIG. 1 may map the PF to which the request is directed to a PF or VF of the SSD 125 of FIG. be able to). At block 1515, LWB 135 may select SSD 125 of FIG. 1 as the device that includes a PF or VF that maps to the PF exposed by endpoint 405 of FIGS. 4a-4c. Block 1515 can only be a problem if LWB 135 of FIG. 1 is coupled to multiple devices as shown in FIG. 4c. If there are multiple devices, multiple APP-EPs 410-1 and 410-2 in FIG. 4c can receive the request. In embodiments of the inventive concept in which only one device can be coupled to the LWB 135 of FIG. 1 (if the LWB 135 includes only one APP-EP 410 of FIGS. Since only one SSD 125 is coupled to LWB 135 in FIG. 1), block 1515 can be omitted as indicated by dotted line 1520.

Once the appropriate device and destination PF/VF are identified, at block 1525, the LWB 135 of FIG. 1 may convert the request into a request for the identified PF/VF. This may include, for example, address translation as described above with reference to FIG. 9 (and discussed below with reference to FIG. 16). At block 1530 (FIG. 15b), the LWB 135 of FIG. 1 may transmit the translated request to the identified PF/VF of the identified device.

At block 1535, LWB 135 of FIG. 1 may receive a response from the identified PF/VF of the identified device. At block 1540, the LWB 135 of FIG. 1 may map the identified device's PF/VF to the PF exposed by the endpoint 405 of FIGS. 4a-4c (e.g., the configuration of FIGS. 4a-4c). The mapping can be accomplished using table 435). At block 1545, LWB 135 of FIG. 1 may convert the response into a response for host 105 of FIG. Finally, at block 1550, the LWB 135 of FIG. 1 may further transmit the response to the host, such as from the exposed PF of the endpoint 405 of FIGS. 4a-4c.

FIG. 16 shows a flowchart of an exemplary process for the APP-EP and APP-RP of FIGS. 4a-4c to translate addresses between the host 105 of FIG. 1 and the SSD 125 of FIG. 1. 16, at block 1605, the APP-EP 410 of FIGS. 4a-4c may subtract the host BAR from the address included in the request from the host 105 of FIG. 1, and at block 1610, the APP-EP 410 of FIGS. APP-RP 415 may add the device BAR to the address determined in block 1605.

Note that the reverse address translation, ie, from the SSD 125 of FIG. 1 to the host 105 of FIG. 1, can be omitted. SSD 125 of FIG. 1, like any arbitrary device, can receive the global address used by host 105 of FIG. Thus, the address provided by SSD 125 of FIG. 1 can be used to access a particular address within host 105 of FIG. 1 without translation. However, if the SSD 125 of FIG. 1 does not have the entire address of the host 105 of FIG. 1, the APP-RP 415 of FIGS. The address translation can be accomplished in reverse by subtracting the BAR and then having the APP-EP 410 of FIGS. 4a-4c add the host BAR to that address.

FIG. 17 shows a flowchart of an exemplary process for the LWB of FIG. 1 to issue credits 1305 to the SSD 125 of FIG. In FIG. 17, at block 1705, the LWB 135 of FIG. 1 may measure or monitor the bandwidth consumed by the individual PF exposed by the endpoint 405 of FIGS. 4a-4c. At block 1710, LWB 135 of FIG. 1 may determine credits 1305 of FIG. 13 to issue to SSD 125 of FIG. Such credits may be determined by the bandwidth consumed by the PF exposed by endpoint 405 in FIGS. 4a-4c and the amount of data that SSD 125 in FIG. 1 must transmit. SSD 125 of FIG. 1 may use such credits to transmit data to or from SSD 125 of FIG. 1. In this regard, numerous options exist for conveying credits 1305 of FIG. 13 to SSD 125 of FIG. 1. At block 1715, LWB 135 of FIG. 1 may record credit 1305 of FIG. 13 to the address of SSD 125 of FIG. Alternatively, at block 1720, the LWB 135 may record the credit 1305 of FIG. 13 to the address of the LWB 135 of FIG. 1, and the SSD 125 of FIG. can be read. Alternatively, at block 1725, LWB 135 of FIG. 1 may transmit the message to SSD 125 of FIG. The message may include credits 1305 in FIG.

FIG. 18 depicts a flowchart of an exemplary process by which LWB 135 of FIG. 1 processes configuration record request 705. In FIG. 18, at block 1805, the LWB 135 of FIG. 1 may receive the configuration record request 705 of FIG. Configuration record request 705 of FIG. 7 may be received from host 105 of FIG. 1 or SSD 125 of FIG. At block 1810, the LWB 135 of FIG. 1 (more specifically, the configuration administrator 440 of FIGS. 4a-4c) sends the PF exposed by the endpoint 405 of FIGS. 4a-4c to the configuration record request 705 of FIG. It can be configured as specified by At block 1815, LWB 135 of FIG. 1 may use state machine 510 of FIG. 5 and SR-IOV sequence 505 of FIG. 5 to accomplish this configuration. Finally, at block 1820, LWB 135 of FIG. 1 determines that the configuration of the PF/VF exposed by SSD 125 of FIG. 1 mirrors the configuration of the PF exposed by endpoint 405 of FIGS. 4a-4c. can be guaranteed. This may include transmitting the configuration record request 705 of FIG. 7 to the SSD 125 of FIG. 1, as indicated by dotted arrows 710 and 715. Block 1820 is optional, as indicated by dotted line 1825, since configuration record request 705 of FIG. 7 may not need to be transmitted to SSD 125 of FIG.

FIG. 19 depicts a flowchart of an exemplary process by which LWB 135 of FIG. 1 processes configuration read request 805. FIG. 19 depicts a flowchart of an exemplary process by which LWB 135 of FIG. 1 processes configuration read request 805. 19, at block 1905, the LWB 135 of FIG. 1 may receive the configuration reading request 805 of FIG. The read configuration request 805 of FIG. 8 may be received from the host 105 of FIG. 1 or the SSD 125 of FIG. ). Here, there are some alternatives. At block 1910, the LWB 135 of FIG. 1 (more specifically, the configuration manager 440 of FIGS. 4a-4c) may determine the configuration of the PF exposed by the endpoint 405 of FIGS. 4a-4c. In an embodiment of the inventive concept in which block 1910 is used, the configuration of the PF exposed by SSD 125 in FIG. 1 mirrors the configuration of the PF exposed by endpoint 405 in FIGS. 4a-4c. It may not be necessary to interrogate the SSD 125 of FIG. 1 for the exposed PF/VF configuration since it is possible to interrogate the SSD 125 of FIG. but). Alternatively, at block 1915, the LWB 135 of FIG. 1 may communicate the configuration reading request 805 of FIG. 8 to the SSD 125 of FIG. Configuration information 810 of FIG. 8 may be received (indicated by dotted arrows 825 and 830 in FIG. 8). Either way, at block 1920, LWB 135 of FIG. 1 may return configuration information 810 of FIG. 8 to the requestor.

FIG. 20 shows a flowchart of an exemplary process by which LWB 135 of FIG. 1 associates QoS policy 1105 with a PF exposed by LWB 135 of FIG. 20, at block 2005, the LWB 135 of FIG. 1 may receive the QoS policy 1105 of FIG. 11 from a source, which may be the host 105 of FIG. 1 or the SSD 125 of FIG. Then, at block 2010, the LWB 135 of FIG. 1 may associate the policy with the identified PF exposed by the endpoint 405 of FIGS. 4a-4c and may appropriately implement the policy.

FIG. 21 is a flowchart of an exemplary process in which the LWB 135 of FIG. 1 dynamically changes the mapping between the PF exposed by the LWB 135 of FIG. 1 and the PF/VF exposed by the SSD 125 of FIG. show. 21, at block 2105, the LWB 135 of FIG. 1 selects the storage parameters 1005 of FIG. 10, the date 1010 of FIG. It can be identified whether the change 1025 has been changed. At block 2110, the LWB 135 of FIG. 1 may dynamically change the mapping 615 of FIG. 6 between the PF 605 of FIG. 6 and the PF/VF 610 of FIG. 6 in response to the sensed change. can.

22a and 22b show a flowchart of an exemplary process by which the LWB of FIG. 1 performs bandwidth throttling. In FIG. 22a, at block 2205, the LWB 135 of FIG. 1 may be determined by the QoS policy 1105 of FIG. 11, the LWB 135 of FIG. 1, or the temperature or power consumption of the SSD 125 of FIG. At block 2210, the LWB 135 of FIG. 1 stores whether bandwidth throttling is applicable, e.g., the temperature or power consumption of the LWB 135 of FIG. 1 or the SSD 125 of FIG. It can be determined by comparing with a threshold value.

If bandwidth throttling is applicable, at block 2215, LWB 135 of FIG. 1 may throttle the bandwidth of SSD 125 of FIG. This throttling may be accomplished by limiting the number of credits 1305 of FIG. 13 issued to SSD 125 of FIG. 1. Then, at block 2220 (FIG. 22b), the LWB 135 of FIG. 1 uses the same QoS policy 1105 of FIG. 11 that triggered the bandwidth throttling at block 2210 of FIG. QoS policy) or the temperature or power consumption of LWB 135 in FIG. 1 or SSD 125 in FIG. At block 2225, the LWB 135 of FIG. 1 determines that the new temperature or power consumption of the QoS policy 1105 of FIG. 11, the LWB 135 of FIG. 1, or the SSD 125 of FIG. You can decide how much you have spent. If bandwidth throttling is still applicable, control may return to block 2220 to again check if a change has occurred that may terminate bandwidth throttling. Otherwise, at block 2230, LWB 135 of FIG. 1 may discontinue bandwidth throttling.

Some embodiments of the invention are shown in Figures 14a-22b. However, one of ordinary skill in the art will appreciate that still other embodiments of the invention are possible by changing the order of the blocks, omitting blocks, or including links not shown in the drawings. It will be possible. All such variations of the flowcharts, whether explicitly described or not, are considered embodiments of the invention.

One embodiment of the technical idea of the present invention includes technical advantages over existing implementations. LWB can expose the PF to the host machine. This eliminates the need for the host machine to run SR-LOV (Single Root Input/Output Virtualization) software to access the VF of a device such as an SSD. The device also does not necessarily require hardware modification, since the LWB may be a separate device and the device does not require specific hardware to support multiple PFs. In effect, the inclusion of the LWB makes no hardware changes to the device, even if a single housing contains both the LWB and the device, and even if the LWB and device are implemented on a shared PCB. Existing SSDs (and other devices) can be integrated into LWB and future SSDs ( and other devices) (such devices may require firmware updates, e.g. to support the use of credits to manage data transmission, but such updates may (This can be easily accomplished in the device domain as well.) Additionally, because the LWB can aggregate the resources of multiple devices, the LWB can provide better overall performance than any individual device provides.

The following discussion is intended to provide a brief, general description of a suitable machine or machines capable of embodying certain aspects of the disclosure. The machine or machines can receive input from traditional input devices such as a keyboard, mouse, etc., as well as commands received from other machines, interaction with a virtual reality (VR) environment, biometric feedback, or other input. It can be controlled at least in part by a signal. As used herein, the term "machine" encompasses a single machine, a virtual machine, or a system of communicatively coupled machines, virtual machines, or devices operating together. Exemplary machines include PCs, workstations, servers, portable computers, handheld devices, telephones, tablets, etc., as well as personal or mass transportation vehicles such as cars, trains, taxis, etc. Including devices.

The machines or machines may include programmable or non-programmable logic devices or arrays, application specific integrated circuits (ASICs), embedded computers, embedded controllers such as smart cards. The machine or machines may utilize one or more connections as a plurality of remote machines, for example via a network interface, modem, or other communicative coupling. Machines may be coupled together in the form of physical and/or logical networks such as intranets, the Internet, local area networks, wide area networks, and the like. Those of ordinary skill in the art will appreciate that network communications can be implemented in a variety of wired formats, including radio frequency, satellite, microwave, IEEE 802.11, Bluetooth, visible light, infrared, cable, laser, etc. It will be appreciated that and/or wireless short-range or long-range carriers and protocols may be utilized.

Embodiments of the invention describe functions, procedures, data structures, application programs, etc. that, when accessed by a machine, result in machine-performed work or machine-defined abstract data types or low-level hardware contexts. You can refer to or explain related data that it contains. For example, the relevant data can be stored in volatile and/or non-volatile memories such as RAM, ROM, or hard drives, floppy disks, optical recording devices, tapes, flash memory, memory sticks, digital video discs, biological It may be stored in other storage devices and associated storage media, including measurement storage and the like. The relevant data can be introduced into transmission environments, including physical and/or local networks, in the form of packets, serial data, parallel data, radio signals, etc., and can be used in compressed or encrypted formats. can. Related data can be used in a distributed environment and can be stored close to machine access and/or remotely.

Embodiments of the invention may include non-transitory machine-readable media of the type that include instructions executable by one or more processors. The instruction words include instructions for performing the elements described herein.

Although the principles of the disclosure have been described with reference to embodiments that illustrate the principles of the disclosure, the embodiments described are susceptible to modifications in arrangement and detail without departing from such principles and may be combined in any desired manner. be able to recognize what is possible. And, although the foregoing discussion has focused on particular embodiments, other configurations may also be considered. In particular, even if phrases such as "in accordance with embodiments of the invention" are used herein, such phrases are meant to refer generally to possible embodiments, and are not intended to limit disclosure to specific embodiments. It is not intended to limit the configuration. As used herein, such terms can refer to other embodiments, the same or different, which can be combined with other embodiments.

The embodiments described above should not be construed as limiting the disclosure. Although several embodiments have been described, those of ordinary skill in the art will recognize that many modifications of such embodiments may be made without departing materially from the novel teachings and advantages of the present invention. This can be easily recognized. Accordingly, all such modifications are intended to be included within the scope of the invention as defined in the claims.

The disclosed embodiments can be extended without limitation to the following statements.

Statement 1. One embodiment of the technical idea of the present invention includes a Lightweight Bridge (LWB) circuit, and the LWB circuit includes:
an endpoint that is connected to a host and exposes multiple physical functions (PFs);
a root port coupled to a device, the root port exposing at least one PF and at least one virtual function (VF) to the root port; and a plurality of PFs exposed to the host. and an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) for converting between the at least one PF and the at least one VF exposed by the device;
The APP-EP and APP-RP implement mapping between the plurality of PFs exposed by the endpoint and at least one PF and at least one VF exposed by the device.

Statement 2. One embodiment of the technical idea of the present invention includes an LWB circuit according to Statement 1, where the device includes an SSD (Solid State Drive).

Statement 3. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, where the device includes an LWB circuit.

Statement 4. One embodiment of the inventive concept includes an LWB circuit according to statement 1, where the LWB circuit is coupled to the device.

Statement 5. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, where the APP-EP and APP-RP can be implemented in a single component.

Statement 6. One embodiment of the technical idea of the present invention includes an LWB circuit according to Statement 1, where the LWB circuit includes an FPGA (Field Programmable Gate Array), an ASIC (Application-Specific Integrated Circuit), a general-purpose processor, a GPU (Graphic csProcessing unit) and a general-purpose GPU (GPGPU).

Statement 7. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, where:
The plurality of PFs include a plurality of Peripheral Component Interconnect Express (PCIe) PFs,
the at least one PF includes at least one PCIe PF;
At least one virtual function (VF) includes at least one PCIe VF.

Statement 8. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 7, where:
The APP-EP includes a PCIe APP-EP (PAPP-EP),
The APP-RP includes a PCIe APP-RP (PAPP-RP).

Statement 9. One embodiment of the technical idea of the present invention includes an LWB circuit according to Statement 1, and further includes a configuration manager for configuring APP-EP and APP-RP.

Statement 10. An embodiment of the technical idea of the present invention includes an LWB circuit according to statement 9, where the APP-RP has a configuration table that includes a plurality of PFs exposed to the endpoint and at least one PF exposed by the device. and at least one virtual function (VF).

Statement 11. An embodiment of the technical idea of the present invention includes an LWB circuit according to statement 9, where the configuration manager can enumerate at least one PF and at least one VF exposed by the device, and the device A plurality of PFs exposed by the endpoint can be generated based at least in part on at least one PF and at least one VF exposed by the endpoint.

Statement 12. One embodiment of the inventive concept includes an LWB circuit according to statement 9, where the configuration manager can configure a device.

Statement 13. One embodiment of the inventive concept includes an LWB circuit according to statement 12, wherein the configuration manager performs a configuration write request based at least in part on a configuration write request received from the endpoint host. The device can be configured using the following methods.

Statement 14. An embodiment of the technical idea of the present invention includes an LWB circuit according to statement 9, where the APP-EP intercepts a configuration read request from a host and returns configuration information to the host. can do.

Statement 15. One embodiment of the inventive concept includes an LWB circuit according to statement 9, where the configuration manager can ensure that a first configuration of a device mirrors a second configuration of an endpoint.

Statement 16. An embodiment of the technical idea of the present invention includes an LWB circuit according to Statement 9, where a configuration manager configures a ROM (Read Only Memory) and a ROM (Read Only Memory) for implementing an SR-IOV (Single Root Input/Output Virtualization) sequence. Contains a state machine.

Statement 17. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, where:
The APP-EP can derive the BAR (Base address register) of the PF exposed by the endpoint from the address received at the request of the host;
The APP-RP can add the BAR of the VF exposed by the device to the address received from the APP-EP.

Statement 18. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1,
a second APP-EP and a second APP-RP,
a second device exposing at least one second PF and at least one second VF; and a multiplexer/demultiplexer arranged/coupled to the endpoint and coupled to each of the APP-EP and the second APP-EP. In addition, it includes
The second APP-EP and the second APP-RP provide a second mapping between a plurality of PFs exposed by the endpoint and at least one second PF and at least one second VF exposed by the second device. Realize.

Statement 19. One embodiment of the inventive concept includes an LWB circuit according to statement 18, where the LWB circuit provides collective resources of the device and the second device.

Statement 20. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, wherein a plurality of PFs exposed by the endpoint, at least one PF and at least one VF exposed by the device. The mapping between can be changed dynamically.

Statement 21. One embodiment of the inventive concept includes an LWB circuit according to statement 20, wherein a plurality of PFs exposed by the endpoint and at least one PF and at least one VF exposed by the device. The mapping between changes based at least in part on storage parameters, date, time of date, bandwidth usage, or quality of service (QoS) policy changes for at least one of the plurality of PFs exposed by the endpoint. be able to.

Statement 22. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 1, where the LWB circuit can implement bandwidth throttling.

Statement 23. One embodiment of the inventive concept includes an LWB circuit according to statement 22, where the LWB circuit is capable of measuring the bandwidth used by at least one of the plurality of PFs exposed by the endpoint. .

Statement 24. An embodiment of the technical idea of the present invention includes an LWB circuit according to statement 22, where the LWB circuit has a policy set on the host, a policy set by the device, a temperature of the LWB circuit, and the LWB circuit according to statement 22. Bandwidth throttling may be implemented based at least in part on power consumption of the SSD, a temperature of the SSD, or a power consumption of the SSD.

Statement 25. One embodiment of the inventive concept includes an LWB circuit according to statement 24, where the LWB circuit further includes a storage for a threshold that triggers bandwidth throttling.

Statement 26. One embodiment of the inventive concept includes an LWB circuit according to Statement 25, where the LWB circuit further includes a storage for a second threshold that triggers termination of bandwidth throttling.

Statement 27. One embodiment of the inventive concept includes an LWB circuit according to statement 22, where the LWB circuit can issue credits to devices for data transmission.

Statement 28. One embodiment of the inventive concept includes an LWB circuit according to statement 27, where the LWB circuit can record the credit to the address of the device.

Statement 29. One embodiment of the inventive concept includes an LWB circuit according to statement 27, where a device can read the credit from the LWB circuit address.

Statement 30. One embodiment of the inventive concept includes an LWB circuit according to statement 27, where the LWB circuit can transmit the credit to a device in a message.

Statement 31. One embodiment of the technical idea of the present invention includes an LWB circuit according to statement 22, where the LWB circuit is configured to provide a Bandwidth throttling can be implemented.

Statement 32. One embodiment of the technical idea of the present invention includes an LWB circuit according to Statement 1, where the LWB circuit can implement a QoS policy on a PF of a plurality of PFs exposed by a device.

Statement 33. One embodiment of the inventive concept includes an LWB circuit according to statement 32, where the policy can be set by one of the host, BMC, or device.

Statement 34. One embodiment of the inventive concept includes an LWB circuit according to Statement 1, wherein the LWB circuit configures multiple PFs exposed by an endpoint based at least in part on a configuration record request received from a device. At least one capability can be configured.

Statement 35. One embodiment of the technical idea of the present invention includes a method. The method includes:
enumerating at least one physical function (PF) exposed by the device using a root port of a lightweight bridge (LWB);
enumerating at least one virtual function (VF) exposed by the device using the root port of the LWB;
generating a plurality of PFs at end points of the LWB for exposure to a host; mapping the plurality of PFs at an endpoint of an LWB to the at least one PF and at least one VF exposed by the device.

Statement 36. One embodiment of the inventive concept includes a method according to statement 35, where:
The step of enumerating at least one PF exposed by a device using the root port of the LWB includes enumerating at least one PF exposed by the device using the root port of the LWB at startup of the LWB. Including a step of listing PFs,
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes the step of enumerating at least one VF exposed by the device using the root port of the LWB at startup of the LWB. The method includes the step of listing at least one VF.

Statement 37. One embodiment of the inventive concept includes a method according to statement 35, where:
The step of enumerating at least one PF exposed by the device using the root port of the LWB includes listing at least one PF exposed by the device using the root port of the LWB when the device is connected to the LWB. including the step of listing the
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes enumerating at least one VF exposed by the device using the root port of the LWB when the device is coupled to the LWB. This includes a step of listing one VF.

Statement 38. One embodiment of the technical idea of the present invention includes a method according to statement 35, where the device includes a solid state drive (SSD).

Statement 39. One embodiment of the inventive concept includes a method according to statement 35, where:
The plurality of PFs include a plurality of Peripheral Component Interconnect Express (PCIe) PFs,
the at least one PF includes at least one PCIe PF;
The at least one VF includes at least one PCIe VF.

Statement 40. One embodiment of the technical idea of the present invention includes a method according to statement 39, where:
The APP-EP includes a PCIe APP-EP (PAPP-EP),
The APP-RP includes a PCIe APP-RP (PAPP-RP).

Statement 41. One embodiment of the technical idea of the present invention includes a method according to statement 35,
The method further includes receiving an enumeration from the host, and exposing a plurality of PFs at endpoints of the LWB to the host.

Statement 42. One embodiment of the technical idea of the present invention includes a method according to statement 35,
The step of enumerating at least one PF exposed by the device using the root port of the LWB includes the step of enumerating at least one second PF exposed by the second device using a second root port of the LWB. including;
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes enumerating at least one second VF exposed by the second device using the second root port of the LWB. including the step of
The step of mapping the plurality of PFs to the at least one PF and at least one VF includes mapping the plurality of PFs to the at least one PF, at least one VF, at least one second PF, and at least one second VF. including the step of mapping.

Statement 43. One embodiment of the technical idea of the present invention includes a method according to statement 42,
The method further includes: determining resources of the device and the second device; and aggregating resources of the device and the second device.

Statement 44. One embodiment of the technical idea of the present invention includes a method according to statement 35,
receiving a request from a host at one PF of the plurality of PFs exposed by the endpoint;
mapping the PF of the plurality of PFs exposed by the endpoint of the LWB to the one of the at least one VF exposed by the device;
converting a request from the PF of the plurality of PFs exposed by the endpoint into the VF of the at least one VF exposed by the device; The method further includes the step of transmitting data to the VFs of the two VFs.

Statement 45. One embodiment of the technical idea of the present invention includes a method according to statement 44,
receiving a response to the request from the VF of at least one VF exposed by the device;
mapping the VF of at least one VF exposed by the device to the PF of the plurality of PFs exposed by the endpoint of the LWB;
converting a response from the VF of the at least one VF exposed by the device to the PF of the plurality of PFs exposed by the endpoint; The method further includes transmitting data to the host via the PFs of the plurality of PFs.

Statement 46. One embodiment of the inventive concept includes a method according to statement 45, wherein a response from the at least one VF exposed by the device is transmitted to the plurality of PFs exposed by the endpoint. The step of converting the PF to the PF of the plurality of PFs exposed by the endpoint is based on a first BAR (Base address register) of the PF of the plurality of PFs exposed by the endpoint and a second BAR of the VF of at least one VF exposed by the device. and modifying the address of the response.

Statement 47. One embodiment of the inventive concept includes a method according to statement 45, wherein the VFs of at least one VF exposed by the device are replaced by the plurality of PFs exposed by the endpoints of the LWB. The step of mapping the VFs of at least one VF exposed by the device to the PFs of the plurality of PFs exposed by the endpoint of the LWB using a configuration table of an APP-RP of the LWB. It includes the step of mapping to PF.

Statement 48. An embodiment of the technical idea of the present invention includes a method according to statement 44, wherein a request from the PF of the plurality of PFs exposed by the endpoint is transmitted to the at least one VF exposed by the device. The step of converting into the VF of the plurality of PFs exposed by the endpoint is based on a first base address register (BAR) of the PF of the plurality of PFs exposed by the endpoint and a second BAR of the VF of at least one VF exposed by the device. and modifying the address of the request.

Statement 49. An embodiment of the inventive concept includes a method according to statement 44, wherein the PF of the plurality of PFs exposed by the endpoint of the LWB is connected to the at least one VF exposed by the device. mapping the PF of the plurality of PFs exposed by the endpoint of the LWB to the at least one VF exposed by the device using a configuration table of an APP-RP of the LWB. mapping the two VFs to one VF.

Statement 50. An embodiment of the inventive concept includes a method according to statement 44, wherein transmitting the request to the VF of the at least one VF exposed by the device comprises:
selecting between the device and a second device, wherein the second device is selected from at least one VF exposed by the device of the PF of the plurality of PFs exposed by the endpoint of the LWB; exposing at least one second PF and at least one second VF based in part on the mapping of to the VF; and transmitting the request to an APP-EP associated with the device.
including.

Statement 51. One embodiment of the technical idea of the present invention includes a method according to statement 44,
determining credits for data transmission involving the device; and issuing the credits to the device;
further including.

Statement 52. One embodiment of the inventive concept includes a method according to statement 51, where issuing the credit to the device includes recording the credit to an address of the device.

Statement 53. An embodiment of the inventive concept includes a method according to statement 51, where issuing the credit to the device includes resolving the credit from an address of an LWB.

Statement 54. An embodiment of the inventive concept includes a method according to statement 51, where issuing the credit to the device includes transmitting a message including the credit from an LWB to the device.

Statement 55. One embodiment of the technical idea of the present invention includes a method according to statement 35,
receiving a configuration record request; and configuring a plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request;
further including.

Statement 56. An embodiment of the technical idea of the present invention includes a method according to statement 55, based at least in part on the configuration record request to mirror the configuration of the plurality of PFs exposed by the endpoint of the LWB. The method further includes configuring at least one PF and at least one VF exposed by the device.

Statement 57. One embodiment of the inventive concept includes a method according to statement 55, where the step of receiving the configuration record request includes receiving a configuration record request from the host.

Statement 58. One embodiment of the inventive concept includes a method according to statement 55, where the step of receiving a configuration recording request includes receiving a configuration recording request from the device.

Statement 59. One embodiment of the inventive concept includes a method according to statement 58, wherein configuring the plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request. configuring a capability of at least one of the plurality of PFs exposed by the endpoint based at least in part on a configuration record request received from the device.

Statement 60. One embodiment of the inventive concept includes a method according to statement 55, wherein configuring the plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request. The method includes executing a Single Root Input/Output Virtualization (SR-IOV) sequence using a state machine.

Statement 61. One embodiment of the technical idea of the present invention includes a method according to statement 35,
receiving a configuration reading request;
determining a configuration of at least one PF and at least one VF of the device; and responding to a configuration reading request with a configuration of at least one PF and at least one VF of the device;
further including.

Statement 62. An embodiment of the technical idea of the present invention includes a method according to statement 61, wherein determining a configuration of at least one PF and at least one VF of the device includes the step of determining the configuration of the endpoint of the device. determining a configuration of the plurality of PFs exposed by the method.

Statement 63. An embodiment of the technical idea of the present invention includes a method according to statement 61, wherein determining a configuration of at least one PF and at least one VF of the device includes determining the configuration of at least one PF and at least one VF of the device. The method includes querying the device regarding the configuration of the PF and at least one VF.

Statement 64. An embodiment of the technical idea of the present invention includes a method according to statement 61, wherein determining a configuration of at least one PF and at least one VF of the device includes the step of determining the configuration of the at least one PF and at least one VF of the device. Includes a step of not communicating to the device.

Statement 65. An embodiment of the technical idea of the present invention includes a method according to statement 35, using APP-EP and APP-RP of the LWB to expose by the device of a plurality of PFs at the end points of the LWB. The method further includes dynamically changing mapping for at least one PF and at least one VF.

Statement 66. One embodiment of the technical idea of the present invention includes a method according to statement 65, wherein APP-EP and APP-RP of the LWB are used to expose by the device of a plurality of PFs at the endpoints of the LWB. Dynamically changing the mapping for the at least one PF and the at least one VF includes storage parameters, date, time of date, and bandwidth usage for at least one of the plurality of PFs exposed by the endpoint of the LWB. or at least one of the devices exposed by the device of a plurality of PFs at the endpoint of the LWB using the APP-EP and APP-RP of the LWB, based at least in part on a quality of service (QoS) policy change. The method includes dynamically changing mappings for one PF and at least one VF.

Statement 67. One embodiment of the inventive concept includes a method according to statement 35, further including throttling bandwidth for the device.

Statement 68. One embodiment of the inventive concept includes a method according to statement 67, further comprising measuring a bandwidth used by at least one of a plurality of PFs exposed by the endpoint.

Statement 69. One embodiment of the inventive concept includes a method according to statement 67, wherein throttling bandwidth for the device comprises an interval between a first data packet and a second data packet. -packetgap).

Statement 70. An embodiment of the technical idea of the present invention includes a method according to statement 67, wherein throttling bandwidth for the device comprises a QoS policy set by the host, a QoS policy set by the device. , throttling bandwidth for a device based at least in part on a temperature of the LWB circuit, a power consumption of the LWB, a temperature of the SSD, or a power consumption of the SSD.

Statement 71. An embodiment of the technical idea of the present invention includes a method according to statement 70, wherein a QoS policy set by the host, a QoS policy set by the device, a temperature of the LWB, a power consumption of the LWB, Throttling bandwidth for the device based at least in part on the temperature of the SSD, or the power consumption of the SSD, may be based on the temperature of the LWB, the power consumption of the LWB, the temperature of the SSD, or the power consumption of the SSD. Throttling bandwidth for the device based at least in part on power consumption exceeding a threshold.

Statement 72. An embodiment of the technical idea of the present invention includes a method according to statement 71, wherein the temperature of the LWB, the power consumption of the LWB, the temperature of the SSD, or the power consumption of the SSD is a second threshold. terminating bandwidth throttling for the device based at least in part on the device becoming less than .

Statement 73. One embodiment of the technical idea of the present invention includes a method according to statement 35,
receiving a QoS policy for the plurality of PFs exposed by the endpoint of the LWB; and implementing a QoS policy for the plurality of PFs exposed by the endpoint of the LWB.
further including.

Statement 74. An embodiment of the technical idea of the present invention includes a method according to statement 73, wherein receiving a QoS policy for a PF of the plurality of PFs exposed by an endpoint of the LWB comprises receiving a QoS policy for the PF of the plurality of PFs exposed by the endpoint of the LWB from one of the PFs.

Statement 75. An embodiment of the technical idea of the present invention includes an article including a non-transitory storage medium, and when the non-transitory storage medium is executed by a machine:
enumerating at least one physical function (PF) exposed by the device using a root port of a lightweight bridge (LWB);
enumerating at least one virtual function (VF) exposed by the device using the root port of the LWB;
generating a plurality of PFs at the end points of the LWB for exposure to a host; and using an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) to mapping the plurality of PFs at an endpoint to the at least one PF and at least one VF exposed by the device;
remembers the command word that causes

Statement 76. One embodiment of the inventive concept includes an article according to statement 75, where:
The step of enumerating at least one PF exposed by a device using the root port of the LWB includes enumerating at least one PF exposed by the device using the root port of the LWB at startup of the LWB. Including a step of listing PFs,
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes the step of enumerating at least one VF exposed by the device using the root port of the LWB at startup of the LWB. Statement 77. One embodiment of the inventive concept includes an article according to statement 75, where:
The step of enumerating at least one PF exposed by the device using the root port of the LWB includes enumerating at least one PF exposed by the device using the root port of the LWB when the device is coupled to the LWB. including a step of listing three PFs,
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes enumerating at least one VF exposed by the device using the root port of the LWB when the device is coupled to the LWB. The method includes the step of listing at least one VF.

Statement 78. One embodiment of the inventive concept includes an article according to statement 75, where the device includes a solid state drive (SSD).

Statement 79. One embodiment of the inventive concept includes an article according to statement 75, where:
The plurality of PFs include a plurality of Peripheral Component Interconnect Express (PCIe) PFs,
the at least one PF includes at least one PCIe PF;
The at least one VF includes at least one PCIe VF.

Statement 80. One embodiment of the inventive concept includes an article according to statement 79, where:
The APP-EP includes a PCIe APP-EP (PAPP-EP),
The APP-RP includes a PCIe APP-RP (PAPP-RP).

Statement 81. An embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, comprises:
receiving an enumeration from the host; and exposing a plurality of PFs at the endpoint of the LWB to the host.
remembers the command word that causes

Statement 82. One embodiment of the inventive concept includes an article according to statement 75, where:
Enumerating at least one PF exposed by the device using a root port of the LWB includes enumerating at least one second PF exposed by the second device using a second root port of the LWB. including,
The step of enumerating at least one VF exposed by the device using the root port of the LWB includes enumerating at least one second VF exposed by the second device using the second root port of the LWB. including the step of
The step of mapping the plurality of PFs to the at least one PF and the at least one VF includes mapping the plurality of PFs to the at least one PF, the at least one VF, the at least one second PF, and the at least one second PF. and mapping to a second VF.

Statement 83. One embodiment of the inventive concept includes an article according to statement 82, wherein the non-transitory storage medium, when executed by a machine, includes:
determining resources of the device and the second device; and aggregating resources of the device and the second device.
remembers the command word that causes

Statement 84. One embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, includes:
receiving a request from the host at one PF of the plurality of PFs exposed by the endpoint;
mapping the PF of the plurality of PFs exposed by the endpoint of the LWB to one VF of the at least one VF exposed by the device;
converting a request from the PF of the plurality of PFs exposed by the endpoint into the VF of the at least one VF exposed by the device; transmitting to the VF of the two VFs;
remembers the command word that causes

Statement 85. One embodiment of the inventive concept includes an article according to statement 84, wherein the non-transitory storage medium, when executed by a machine:
receiving a response to the request from the VF of at least one VF exposed by the device;
mapping the VF of at least one VF exposed by the device to the PF of the plurality of PFs exposed by the endpoint of the LWB;
converting a response from the VF of the at least one VF exposed by the device to the PF of the plurality of PFs exposed by the endpoint; transmitting the information to the host via the PFs of the plurality of PFs;
remembers the command word that causes

Statement 86. One embodiment of the inventive concept includes an article according to statement 85, wherein a response from the at least one VF exposed by the device is transmitted to the multiple PFs exposed by the endpoint. The step of converting the PF to the PF of the plurality of PFs exposed by the endpoint is based on a first BAR (Base address register) of the PF of the plurality of PFs exposed by the endpoint and a second BAR of the VF of at least one VF exposed by the device. and modifying the address of the response.

Statement 87. One embodiment of the inventive concept includes an article according to statement 85, wherein the VF of at least one VF exposed by the device is combined with the VF of the plurality of PFs exposed by the endpoint of the LWB. The step of mapping the VFs of at least one VF exposed by the device to the plurality of PFs exposed by the endpoint of the LWB using a configuration table of the APP-RP of the LWB. The method further includes mapping to the PF.

Statement 88. One embodiment of the inventive concept includes an article according to statement 84, wherein a request from the PF of the plurality of PFs exposed by the endpoint is transmitted to the at least one VF exposed by the device. The step of converting into the VF of the plurality of PFs exposed by the endpoint is based on a first base address register (BAR) of the PF of the plurality of PFs exposed by the endpoint and a second BAR of the VF of at least one VF exposed by the device. and modifying the address of the request.

Statement 89. One embodiment of the inventive concept includes an article according to statement 84, wherein the PF of the plurality of PFs exposed by the endpoint of the LWB is connected to the at least one VF exposed by the device. mapping the PF of the plurality of PFs exposed by the endpoint of the LWB to the at least one VF exposed by the device using a configuration table of the APP-RP of the LWB. mapping the two VFs to one VF.

Statement 90. One embodiment of the inventive concept includes an article according to statement 84, wherein transmitting the request to the VF of the at least one VF exposed by the device comprises:
selecting between the device and a second device, wherein the second device is selected from at least one VF exposed by the device of the PF of the plurality of PFs exposed by the endpoint of the LWB; exposing at least one second PF and at least one second VF based in part on the mapping of to the VF; and transmitting the request to an APP-EP associated with the device.
including.

Statement 91. One embodiment of the inventive concept includes an article according to statement 84, wherein the non-transitory storage medium, when executed by a machine:
determining credits for data transmissions involving the device; and issuing the credits to the device;
remembers the command word that causes

Statement 92. One embodiment of the inventive concept includes an article according to statement 91, where issuing the credit to the device includes recording the credit to an address of the device.

Statement 93. One embodiment of the inventive concept includes an article according to statement 91, where issuing the credit to the device includes decoding the credit from the address of the LWB.

Statement 94. An embodiment of the inventive concept includes an article according to statement 91, where issuing the credit to the device includes transmitting a message including the credit from the LWB to the device.

Statement 95. An embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, comprises:
receiving a configuration record request; and configuring a plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request;
remembers the command word that causes

Statement 96. An embodiment of the inventive concept includes an article according to statement 95, wherein the non-transitory storage medium is configured to be used by the endpoint of the LWB when executed by a machine. Instruction words that cause configuring at least one PF and at least one VF exposed by the device based at least in part on the configuration record request to mirror the configuration of the plurality of exposed PFs. I remember.

Statement 97. One embodiment of the inventive concept includes an article according to statement 95, where the step of receiving a configuration record request includes receiving a configuration record request from the host.

Statement 98. One embodiment of the inventive concept includes an article according to statement 95, where the step of receiving a configuration recording request includes receiving a configuration recording request from the device.

Statement 99. One embodiment of the inventive concept includes an article according to statement 98, wherein configuring the plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request. configuring a capability of at least one of the plurality of PFs exposed by the endpoint based at least in part on a configuration record request received from the device.

Statement 100. One embodiment of the inventive concept includes an article according to statement 95, wherein configuring the plurality of PFs exposed by the endpoint of the LWB based at least in part on the configuration record request. The method includes executing a Single Root Input/Output Virtualization (SR-IOV) sequence using a state machine.

Statement 101. An embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, comprises:
receiving a configuration reading request;
determining a configuration of at least one PF and at least one VF of the device; and responding to a configuration reading request with a configuration of at least one PF and at least one VF of the device;
It also remembers command words that cause

Statement 102. An embodiment of the technical idea of the present invention includes an article according to statement 101, wherein determining a configuration of at least one PF and at least one VF of the device includes the step of determining the configuration of the at least one PF and at least one VF of the device. determining a configuration of the plurality of PFs exposed by the method.

Statement 103. One embodiment of the technical idea of the present invention includes an article according to statement 101, wherein determining a configuration of at least one PF and at least one VF of the device includes a configuration of at least one PF and at least one VF of the device. The method includes querying the device regarding the configuration of the PF and at least one VF.

Statement 104. An embodiment of the technical idea of the present invention includes an article according to statement 101, where the step of determining a configuration of at least one PF and at least one VF of the device includes the step of determining the configuration of at least one PF and at least one VF of the device. Includes a step of not communicating to the device.

Statement 105. An embodiment of the technical idea of the present invention includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, APP-EP and APP-EP of the LWB. further storing instruction words that cause dynamically changing a mapping of a plurality of PFs at an endpoint of the LWB to at least one PF and at least one VF exposed by the device using an APP-RP; are doing.

Statement 106. One embodiment of the inventive concept includes an article according to statement 105, wherein the devices of a plurality of PFs at endpoints of the LWB are exposed by the device using APP-EP and APP-RP of the LWB. Dynamically changing the mapping for the at least one PF and the at least one VF includes storage parameters, date, time of date, and bandwidth usage for at least one of the plurality of PFs exposed by the endpoint of the LWB. , or based at least in part on a quality of service (QoS) policy change, using APP-EP and APP-RP of the LWB to at least The method includes dynamically changing mapping for one PF and at least one VF.

Statement 107. One embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, slots bandwidth to the device. It also remembers the command word that causes the ringing step.

Statement 108. One embodiment of the inventive concept includes an article according to statement 107, further comprising measuring a bandwidth used by at least one of a plurality of PFs exposed by the endpoint.

Statement 109. One embodiment of the inventive concept includes an article according to statement 107, wherein throttling bandwidth for the device comprises an interval between a first data packet and a second data packet. -packetgap).

Statement 110. One embodiment of the inventive concept includes an article according to statement 107, wherein throttling bandwidth for the device comprises a QoS policy set by the host, a QoS policy set by the device. , throttling bandwidth for the device based at least in part on a temperature of the LWB circuit, a power consumption of the LWB, a temperature of the SSD, or a power consumption of the SSD.

Statement 111. An embodiment of the technical idea of the present invention includes an article according to statement 110, wherein a QoS policy set by the host, a QoS policy set by the device, a temperature of the LWB, a power consumption of the LWB, Throttling bandwidth for the device based at least in part on the temperature of the SSD, or the power consumption of the SSD, may be based on the temperature of the LWB, the power consumption of the LWB, the temperature of the SSD, or the power consumption of the SSD. Throttling bandwidth for the device based at least in part on power consumption exceeding a threshold.

Statement 112. An embodiment of the technical idea of the present invention includes an article according to statement 111, wherein the non-transitory storage medium, when executed by a machine, changes the temperature of the LWB, the temperature of the LWB, further storing instructions that cause terminating bandwidth throttling for the device based at least in part on the power consumption of the SSD, the temperature of the SSD, or the power consumption of the SSD being below a second threshold. are doing.

Statement 113. An embodiment of the inventive concept includes an article according to statement 75, wherein the non-transitory storage medium, when executed by a machine, comprises:
receiving a QoS policy for the plurality of PFs exposed by the endpoint of the LWB; and implementing a QoS policy for the plurality of PFs exposed by the endpoint of the LWB.
It also remembers command words that cause

Statement 114. An embodiment of the technical idea of the present invention includes an article according to statement 75, wherein receiving a QoS policy for a PF of the plurality of PFs exposed by an endpoint of the LWB comprises: receiving a QoS policy for the PF of the plurality of PFs exposed by the endpoint of the LWB from one of the PFs.

As a result, in view of the wide range of permutations to the embodiments described herein, this detailed description and accompanying material are exemplary only and should not be construed as limiting the scope of the disclosure. should not. Accordingly, the claimed invention is susceptible to all modifications that come within the scope and spirit of the following claims and equivalents.

105 host 110 processor 115 memory 120 memory controller 125 storage device (e.g. SSD)
130 Device Driver 135 Lightweight Bridge (LWB)
405 Endpoint 410 APP-EP
415 APP-RP
420 Root Port 425, 430 Interface 435 Configuration Table 440 Configuration Manager 445 Multiplexer/Demultiplexer 505 SR-IOV Sequence 510 State Machine

Claims (20)

an endpoint coupled to the host and exposing a first physical function (PF) and a second physical function;
a root port coupled to a device, wherein the device exposes a third PF and a virtual function (VF) to the root port; and the first PF and the second PF exposed to the host. an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) for conversion between the third PF and the VF exposed by the device;
including;
The APP-EP and the APP-RP implement a mapping between the first PF and the second PF exposed by the endpoint and the third PF and the VF exposed by the device.
bridge circuit. The bridge circuit of claim 1, further comprising a configuration manager for configuring the APP-EP and the APP-RP. The APP-RP includes a storage unit for a configuration table that stores a mapping between the first PF and the second PF exposed by the endpoint and the third PF and the VF exposed by the device. , The bridge circuit according to claim 2. The configuration manager enumerates the third PF and the VF exposed by the device, and enumerates the third PF and the VF exposed by the endpoint based at least in part on the third PF and the VF exposed by the device. The bridge circuit according to claim 2, wherein the bridge circuit generates the first PF and the second PF. 3. The bridge circuit of claim 2, wherein the configuration manager ensures that a first configuration of the device mirrors a second configuration of the endpoint. The bridge circuit of claim 2, wherein the configuration manager includes a ROM (Read Only Memory) and a state machine for implementing an SR-IOV (Single Root Input/Output Virtualization) sequence. a second APP-EP and a second APP-RP,
a second device exposing a fourth PF and a second VF, and a multiplexer/demultiplexer coupled to the endpoint and arranged to be coupled to each of the APP-EP and the second APP-EP;
further including;
The second APP-EP and the second APP-RP implement a second mapping between the fifth PF and sixth PF exposed by the endpoint and the fourth PF and second VF exposed by the second device. The bridge circuit according to claim 1. 8. The bridge circuit according to claim 7, wherein the bridge circuit aggregates resources of the device and the second device. The bridge circuit of claim 1, wherein the bridge circuit implements bandwidth throttling. The bridge circuit is at least partially responsive to a policy set on the host, a policy set by the device, a temperature of the bridge circuit, a power consumption of the bridge circuit, a temperature of the device, or a power consumption of the device. 10. The bridge circuit of claim 9, implementing bandwidth throttling based on. The bridge circuit of claim 1, wherein the bridge circuit implements a QoS policy on the first PF exposed by the endpoint . A method performed by a processor embodying a bridge, the method comprising:
listing first physical functions (PF) exposed by the device using the root port of the bridge;
enumerating virtual functions (VFs) exposed by the device using the root port of the bridge;
generating a second PF and a third PF at an end point of the bridge for exposure to a host, and using an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) of the bridge; mapping the second PF and the third PF at the endpoint of the bridge to the first PF and the VF exposed by the device;
including;
the mapping between the second PF and the third PF at the endpoint of the bridge and the first PF and the VF exposed by the device is a mapping stored in the bridge ;
Method. The step of enumerating the first PF exposed by the device using the root port of the bridge includes enumerating the fourth PF exposed by the second device using the second root port of the bridge,
Enumerating the VFs exposed by the devices using the root port of the bridge includes enumerating second VFs exposed by the second device using the second root port of the bridge. ,
The step of mapping the second and third PFs to the first PF and the VF includes mapping the second PF, the third PF, the fifth PF, and the sixth PF to the first PF, the VF, the fourth PF, and the fourth PF. including mapping to 2VF,
13. The method according to claim 12. determining resources of the device and the second device; and aggregating the resources of the device and the second device.
14. The method of claim 13, further comprising: receiving a request from the host at the second PF exposed by the endpoint;
mapping the second PF exposed by the endpoint of the bridge to the VF exposed by the device;
converting the request from the second PF exposed by the endpoint to the VF exposed by the device; and transmitting the request to the VF exposed by the device.
13. The method of claim 12, further comprising: determining credits for data transmissions involving the device; and issuing the credits to the device;
16. The method of claim 15, further comprising: 13. The method of claim 12, further comprising bandwidth throttling to the device. Throttling bandwidth for the device may be based on a QoS policy set by the host, a QoS policy set by the device, a temperature of the bridge, power consumption of the bridge, a temperature of the device, or a QoS policy set by the device. 18. The method of claim 17, comprising throttling bandwidth to the device based at least in part on one of the following: power consumption of the device. An article comprising a non-transitory storage medium having instructions stored thereon, the article comprising:
When the instructions are executed by a processor embodying a bridge ,
listing first physical functions (PF) exposed by the device using the root port of the bridge;
enumerating virtual functions (VFs) exposed by the device using the root port of the bridge;
generating a second PF and a third PF at an end point of the bridge for exposure to a host, and using an APP-EP (Application Layer-End point) and an APP-RP (Application Layer-Root Port) of the bridge; mapping the second PF and the third PF at the endpoint of the bridge to the first PF and the VF exposed by the device;
cause
the mapping between the second PF and the third PF at the endpoint of the bridge and the first PF and the VF exposed by the device is a mapping stored in the bridge ;
Goods. The step of enumerating the first PF exposed by the device using the root port of the bridge includes enumerating the fourth PF exposed by the second device using the second root port of the bridge,
Enumerating the VFs exposed by the devices using the root port of the bridge includes enumerating second VFs exposed by the second device using the second root port of the bridge. ,
The step of mapping the second PF and the third PF to the first PF and the VF includes mapping the second PF, the third PF, the fifth PF, and the sixth PF to the first PF, the VF, the fourth PF, and the fourth PF. including mapping to 2VF,
20. Article according to claim 19.

Images