Isolated switch control path using directly attached dispatch

Abstract

Embodiments herein describe techniques for separating data transmitted between an I / O function in an embedded component and a host into separate data paths. In one embodiment, data packets are transmitted using a direct data path that bypasses the embedded component's switch. In contrast, configuration packets (e.g., hot-swap, hot-add, hot-remove data, some types of descriptors, etc.) are transmitted to the switch, which then forwards the configuration packets to their destination. The direct path for data packets does not rely on switch connectivity (and its attendant latency) to transport bandwidth-sensitive traffic between the host and the I / O function, but instead avoids (e.g., bypasses) the bandwidth, resource, store / forward, and latency characteristics of the switch. Meanwhile, software compatibility attributes, such as hot-plug attributes (which are not latency- or bandwidth-sensitive), are still supported by using the switch to provide the configuration data path.

Description

Technical Field

[0001] Examples of the present disclosure generally relate to the establishment of separate data paths for data packets and configuration packets transmitted between a host and I / O functions on an embedded component.

Background Art

[0002] Server Host-Accelerator systems such as those enabled by Peripheral Component Interconnect Express (PCIe), or cache coherence protocols such as Compute Express Link (CXL) and Cache Coherent Interconnect for Accelerators (CCIX), achieve increased fanout to multiple devices through protocol-aware switch components. Thus, a single physical host port can perform different I / O functions such as network functions, memory functions, accelerator functions, Direct Memory Access (DMA) functions, etc., even when both the host and I / O devices are communicating via a two-point connection established by CXL, CCIX, and PCIe, and communicate with multiple I / O devices including field-programmable gate arrays (FPGAs), graphics processing units (GPUs), network interface cards (NICs), etc., that implement different I / O functions.

[0003] In addition, the Server Host-Accelerator system provides a hot-plug mechanism via the same protocol recognition switch component for multiple device card slots in the system. These hot-plug mechanisms, including hot-add and hot-remove capabilities, result in a system where a particular server is not restricted to a certain combination of functions based on static plug-in protocol cards in these slots. Instead, at runtime, any combination of I / O functions can be dynamically hot-added, hot-removed, or hot-swapped to result in a system with the desired configuration.

[0004] However, PCIe and CXL topologies are tree topologies. The drawback of a tree topology is that traffic from the host must traverse from the source root node to the branches of the tree via ports on the upstream side of the switch. Reverse traffic is also subject to the same tree traversal path. Additionally, cache coherence protocols are more sensitive to latency due to the unbalanced impact of latency on overall system performance. In the case of caching agents, in prior art, the latency increases when servicing coherence actions for multiple cache agent endpoints connected via a switch bottleneck. In addition to coherence protocols, in prior art, when transmitting data between the host and I / O devices, the resources of the switch need to be arbitrated and transported via the switch, resulting in increased latency between the host and individual devices. Furthermore, due to simultaneous protocol messages between the host and all devices, bandwidth is shared via the switch, resulting in reduced bandwidth between the host and individual I / O devices. Finally, the switch stores requests and responses and then has to transfer all of those requests and responses among all I / O devices for a single upstream connection to the host, resulting in reduced efficiency of switch resources. Summary of the Invention

[0005] One embodiment described herein is a computing system comprising a host with a first port and an embedded component including a second port, wherein the first port and the second port form a physical connection between the host and the embedded component, and the embedded component includes a plurality of I / O functions and a passthrough interface configured to receive packets from the host via the second port, identify the type of the packets, and route the packets directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using an embedded switch based on the type of the packets.

[0006] One embodiment described herein is a device comprising a first port configured to form a physical connection with a second port on a host, a plurality of I / O functions, an embedded switch, and a passthrough interface configured to receive packets from the host via the first port, identify the type of the packets, and route the packets directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using the embedded switch based on the type of the packets.

[0007] One embodiment described herein is receiving a first packet from a host at a pass-through interface of an embedded component, where the embedded component comprises a plurality of I / O functions and an embedded switch communicatively coupled to the pass-through interface, receiving the first packet, determining that the first packet is a data packet, where a first I / O function among the plurality of I / O functions is the destination of the data packet, directly routing the data packet from the pass-through interface to the first I / O function using a direct data path that bypasses the embedded switch, receiving a second packet from the host at the pass-through interface, determining that the second packet is a configuration packet, where the first I / O function is the destination of the configuration packet, and routing the data packet from the pass-through interface to the first I / O function via the embedded switch.

[0008] Accordingly, in order to understand the features shown above in a way that can be understood in detail, reference is made to exemplary embodiments for a more specific description than the brief summary above, and some of those exemplary embodiments are shown in the accompanying drawings. However, it should be noted that the accompanying drawings only show typical exemplary embodiments and should not be regarded as limiting the scope of the present disclosure.

Brief Description of the Drawings

[0009]

Figure 1

Figure 2

Figure 3

Figure 4

Figure 5

Figure 6

Figure 7

DETAILED DESCRIPTION OF THE INVENTION

[0010] For ease of understanding, the same reference numerals are used to denote, where possible, exactly the same elements common to the drawings. It is contemplated that the elements of one example can be advantageously incorporated into other examples.

[0011] Hereinafter, various features will be described with reference to the drawings. Note that the drawings may or may not be drawn to scale, and throughout all the drawings, elements of similar structure or function are denoted by similar reference numerals. Note that the intention of the drawings is merely to facilitate the description of the features. The drawings are not intended to be an exhaustive description of the claims or a limitation on the claims. Further, the illustrated examples do not necessarily have all of the aspects or advantages shown. The aspects or advantages described in connection with a particular example are not necessarily limited to that example and can be practiced in any other example, even if not so illustrated or explicitly described as such.

[0012] Embodiments herein describe techniques for separating data transmitted between the I / O function in an embedded component and a host onto separate data paths. In one embodiment, data packets (e.g., DMA payloads and descriptors, CXL snoops or CCIX messages) are transmitted using a direct data path that bypasses the switch of the embedded component. In contrast, configuration packets (e.g., hot-swap, hot-add, hot-remove data, configuration control writes, or configuration status reads, etc.) are transmitted to the switch, which then forwards those configuration packets to their destinations. By this method, the switch control path is separated into two paths, namely, a path for data packets and a separate path for configuration packets. The direct path for data packets transports bandwidth- or latency-sensitive traffic between the host and the I / O function without relying on switch connectivity, instead avoiding (e.g., bypassing) the bandwidth, resources, memory / transfer, and latency characteristics of the switch. On the other hand, software compatibility attributes such as hot-plug attributes or programming of configuration registers (which are not sensitive to latency or bandwidth) are continuously supported by using the switch to provide a configuration data path.

[0013] In one embodiment, the embedded component includes a pass-through interface for mediating between an I / O function and a switch when routing data received from a host to the I / O function and the switch and further transmitting the data to the host. However, unlike a switch that buffers data in a queue (thus adding latency and affecting bandwidth), the routing and mediation functions of the pass-through interface do not store packets and immediately forward the received packets to their destinations. As described above, the pass-through interface can establish a direct path between the host and the I / O function that bypasses the switch for time-sensitive data, while configuration data (latency and not time-sensitive) is routed between the host and the I / O function using the switch. In this way, packets that are not sensitive to latency or bandwidth do not cause interference with the same data path used by latency- and bandwidth-sensitive data.

[0014] FIG. 1 shows an example computing system 100 having different data paths for an I / O function 140. Specifically, the computing system 100 provides a direct data path 170 for transmitting data packets between a host 105 and the I / O function 140, and an indirect configuration data path 180 for transmitting configuration packets between the host 105 and the I / O function 140. Thus, unlike conventional solutions where time-sensitive and non-time-sensitive data share the same physical connection, in the computing system 100, among the embedded components 160, time-sensitive data can be transmitted on a different path from non-time-sensitive data.

[0015] As shown, computing system 100 includes host 105 and embedded component 160 that includes I / O function 140. In this example, host 105 includes one or more processors 110 and memory 115. Processor 110 represents any number of processing elements, and each of any number of processing elements can include any number of processing cores. Memory 115 can include volatile memory elements, non-volatile memory elements, or a combination of both. In this example, memory 115 hosts one or more virtual machines (VMs) 120 or tenants. These VMs 120 can implement a function of requesting the execution of tasks from embedded component 160. The I / O function 140 of embedded component 160 can then perform these tasks.

[0016] Host 105 includes port 125 that is coupled to port 130 of embedded component 160. That is, host 105 and the I / O function 140 of embedded component 160 exchange data using the same pair of ports 125, 130. In one embodiment, host 105 and embedded component 160 exchange data on ports 125, 130 using the PCIe protocol. Further, the same physical connection between ports 125 and 130 is shared by the I / O function 140 of embedded component 160. In one embodiment, only one of the plurality of I / O functions 140 can use the physical connection between ports 125 and 130 at any given time. Time multiplexing can be used so that each of the plurality of I / O functions 140 has an opportunity to exchange data with host 105 using the physical connection. In this way, the bandwidth of the physical connection between ports 125 and 130 (which is typically the widest bandwidth connection) is shared among the I / O functions 140.

[0017] The embedded component 160 may be any physical device that can integrate a plurality of I / O functions 140 and the embedded switch 150. In one embodiment, the embedded component 160 may include a printed circuit board (PCB) (e.g., a substrate), and the I / O functions 140 and the embedded switch 150 are individual integrated circuits (e.g., semiconductor chips) mounted on the PCB. The PCB may include sockets into which these integrated circuits are plugged. In this way, the integrated circuits can be hot-swapped (e.g., one integrated circuit implementing the first I / O function is removed from the socket and replaced with a second integrated circuit implementing the second I / O function). In another embodiment, the embedded component 160 may be a system-in-package (SiP) in which the integrated circuit for the I / O function 140 and the embedded switch 150 are sealed in one or more chip carrier packages. In the case of SiP, it may not be possible to hot-swap the I / O function, but it is still possible to selectively activate and deactivate the I / O function 140 (e.g., hot-add and hot-remove).

[0018] In yet another embodiment, the embedded component 160 is a system-on-chip (SoC) in which all components of the component 160 are included within the same integrated circuit or chip. The SoC may include hard logic for implementing the I / O function 140 that can activate or deactivate the function 140 (e.g., hot added or hot removed). Alternatively, the SoC may also include programmable logic for implementing the I / O function 140 such that the I / O function 140 can be hot-swapped, and the programmable logic for one I / O function is reconfigured such that the programmable logic implements a second I / O function. In other embodiments, the embedded component 160 may be an FPGA in which the illustrated circuitry of the embedded component 160 is implemented in programmable logic, or an ASIC in which the circuitry is implemented using hard logic.

[0019] Regardless of the specific embodiment of the embedded component 160, while the computing system 100 is operating, the I / O function 140 can be activated or deactivated by physically removing an integrated circuit, powering off / on the hardened logic, or reprogramming the programmable logic (e.g., it can be hot-added or hot-removed). In some embodiments, the I / O function 140 can be hot-swapped by replacing a first integrated circuit with another on a substrate (e.g., a PCB), or by reconfiguring the programmable logic that has been performing the first I / O function to perform a second I / O function. Other I / O functions 140 of the embedded component 160 that are not affected by hot-swap / adding / removing can continue to operate in parallel.

[0020] The embedded component 160 includes a pass-through interface 135 coupled to the port 130, the I / O function 140, and the embedded switch 150. The pass-through interface 135 implements a routing function and an arbitration function for transmitting packets between the I / O function 140, the switch 150, and the host 105 using the port 130. For example, when receiving a packet from the host 105, the pass-through interface 135 determines the type of the packet indicating whether the packet should cross one of the plurality of direct data paths 170 to the I / O function 140 or be routed instead to the embedded switch 150. When transmitting a packet from the embedded component 160 to the host 105, the pass-through interface 135 can use arbitration logic to determine a source (e.g., one of the I / O function 140 or the embedded switch 150) that can use the port 130 to transmit the packet to the host 105.

[0021] In one embodiment, the pass-through interface 135 does not buffer or queue packets received from the host 105, the I / O function 140, or the switch 150. Instead, the interface 135 "passes" the packets without adding latency. For example, when the pass-through interface 135 receives a packet, the pass-through interface 135 immediately forwards the packet to its destination, so the received packet does not need to wait for previously received packets to be forwarded by the pass-through interface 135. The pass-through interface 135 is discussed in more detail with reference to FIG. 2.

[0022] The I / O function 140 may be any function that may be offloaded by the host 105 and implemented by the embedded component 160. For example, the I / O function 140 may be an accelerator (e.g., a graphics accelerator, an artificial intelligence of a machine learning accelerator, a cryptographic accelerator, a compression accelerator, etc.). In other examples, the I / O function 140 may be a network communication function (e.g., a NIC function), a DMA engine, a network storage function, etc.

[0023] The I / O function 140 can be regarded as individual I / O devices or functions that can operate independently of each other. For example, the I / O function 140A may be a DMA engine that implements network storage, while the I / O function 140B may be an artificial intelligence accelerator. The I / O functions 140A and 140B may be individual integrated circuits, or different circuit mechanisms (e.g., different hardened logics or different programmable logics) in the same integrated circuit. In any case, as discussed below, the I / O function 140 can be hot-removed (deactivated) or hot-added (activated) while the computing system 100 is operating. For example, the host 105 can communicate with the I / O function 140A at the same time that the embedded component 160 adds a new I / O function 140 (e.g., activates the I / O function 140B that was previously deactivated, or adds a fifth I / O function (not shown)), or removes an I / O function (e.g., deactivates the I / O function 140C that was previously activated).

[0024] The embedded switch 150 may be a PCIe switch that routes packets between the I / O function 140 and the host 105. Also, the switch 150 can receive packets from the host 105 that are not transferred to the I / O function 140. As mentioned above, the switch 150 can be used to route data that is not sensitive to latency and bandwidth, such as configuration packets used to hot-swap, hot-add, or hot-remove the I / O function 140. The configuration packets can also include other information such as descriptors used in the cache coherence protocol to initiate send and receive actions.

[0025] In FIG. 1, the configuration packet intended for one of the plurality of I / O functions 140 transmitted by host 105 is routed through switch 150 along one of the plurality of indirect configuration data paths 180. Thus, the configuration packet is stored in queue 155 in switch 150. This queue 155 can also be called a host-switch buffer. Switch 150 can perform an arbitration function to determine when the configuration packet stored in queue 155 is transmitted or processed.

[0026] It should be noted that in FIG. 1, the direct data path 170 bypasses the embedded switch 150, and more particularly, queue 155. Thus, the direct data path 170 can also be called a bypass path that avoids the latency introduced by queue 155. Thus, computing system 100 reduces latency compared to the prior art where all data passes through switch 150 when servicing coherence actions for a plurality of cache-agent endpoints (i.e., I / O functions 140). Further, the embodiments herein avoid the need for switch resource arbitration when transmitting latency- and bandwidth-sensitive data between host 105 and I / O function 140. That is, sensitive data can use the direct data path 170 to avoid the arbitration function performed by switch 150 (arbitration is still performed at the pass-through interface 135 as described below, but the pass-through interface 135 does not use a queue).

[0027] Also, since the simultaneous protocol messages between the host 105 and all I / O functions 140 can use the direct data path 170, the host 105 and the individual I / O functions 140 do not need to share bandwidth through a switch for these messages. Further, the computing system 100 relies on the switch 150 to store requests and responses for the single upstream connection to the host 105 formed by ports 125 and 130, and then avoid transferring them among all I / O functions 140. Thus, the computing system 100 can utilize improved performance compared to the prior art where all traffic is routed through the switch 150, and multiple endpoints (e.g., I / O functions 140) are connected to the host 105 in a fan-out manner using a single connection (e.g., the physical connection between ports 125 and 130).

[0028] FIG. 2 shows, by way of example, a pass-through interface 135 having different data paths. That is, FIG. 2 shows an example of the circuitry in the pass-through interface 135 where the computing system 200 can have the direct data path and the indirect configuration data path shown in FIG. 1.

[0029] For simplicity, the integrated components 260 in FIG. 2 include only two I / O functions 140A and 140B, but can include any number of I / O functions or I / O devices. To route data from the host 105 to the I / O functions 140 or the embedded switch 150, the pass-through interface 135 includes routing logic 205 and a de-multiplexer (de-mux) 215. Typically, the routing logic 205 determines the destination of the packets received from port 125 of the host 105 (referred to as downstream traffic). Based on the destination, the routing logic 205 controls a select line of the de-mux 215, i.e., one of the I / O functions 140 or the embedded switch 150, so that the packets are routed to the correct destination.

[0030] In this example, the routing logic 205 includes a decoder 210 that decrypts the data contained in the packet received from the host 105 and determines the destination of the packet. In one embodiment, the decoder 210 identifies the type of the packet as well as the destination ID of the packet. The type of the packet determines whether the packet should be routed directly across a data path to one of the plurality of I / O functions 140 or whether it should be routed indirectly across a configured data path to the embedded switch 150. That is, data packets can be sent directly to the I / O function 140, while configuration packets are transmitted to the embedded switch 150. When the decoder 210 determines that the packet is a data packet, the decoder 210 can also determine the I / O function 140 that is the destination of the packet among the plurality of I / O functions 140. When adding an I / O function 140 to the embedded component 260, the host 105 can assign an ID that the host 105 provides to the decoder 210 to that I / O function 140. By embedding this ID in the data packet transmitted by the host 105, the decoder 210 can identify the correct destination of the data packet, and thus the routing logic 205 routes the data packet on the direct data path corresponding to the selected I / O function 140.

[0031] To transfer upstream traffic from the component 260 incorporating it to the host 105, the pass-through interface 135 includes arbitration logic 220 that determines the circuit components of the component 260 incorporating it that can use port 130. As shown, the mux 225 connects each of the plurality of I / O functions 140 and the embedded switch 150 to port 130. A selection signal for the mux 225 is provided by the arbitration logic 220. In one embodiment, the arbitration logic 220 determines the circuit components among these that can transmit packets to port 130 (for example, the arbitration logic 220 time controls the selection lines of the mux 225). In this example, the arbitration logic 220 allows access to port 130 only to one of the I / O functions 140 or the embedded switch 150, and thus there is no data collision. The details of the arbitration logic 220 will be considered in more detail below.

[0032] As shown in FIG. 2, regardless of whether the component 260 incorporating it receives downstream data from the host 105 or transmits upstream data to the host 105, the data can pass through the interface 135 without being added to a queue. Thus, the traffic transmitted along the direct data path between the I / O function 140 and the host 105 has a shorter latency compared to a system where the I / O function 140 relies on the embedded switch 150 as an intermediary between them and the host 105.

[0033] Similar to the pass-through interface 135, the embedded switch 150 also includes arbitration logic 230. That is, since the queue 155 can store multiple packets from multiple sources (e.g., packets received from the I / O function 140, or packets generated by the internal circuit mechanism in the switch 150), the arbitration logic 230 can determine which of these packets should have priority in the queue 155 (not a simple first-in-first-out model). For example, both the arbitration logic 220 and the arbitration logic 230 can assign a higher priority to traffic generated by the I / O function than to traffic generated by the internal circuit mechanism in the switch, or can assign a higher priority to traffic received from the I / O function 140A than to traffic received from the I / O function 140B. This will be considered in more detail below.

[0034] Figure 3 is a flowchart of a method 300 for transmitting data packets and configuration packets from a host to an I / O function using different data paths, by way of example. At block 305, an embedded component receives a packet from the host at a pass-through interface. In one embodiment, the embedded component comprises a plurality of I / O functions (or I / O devices) that rely on a shared physical connection between the embedded component and the host.

[0035] At block 310, a pass-through interface decoder determines whether the received packet is a data packet or a configuration packet. For example, the packet header can include data indicating the type of the packet. This information can be placed in the packet by the host, or this information can be part of the physical transport protocol (e.g., PCIe) used to transmit the packet. In either case, the decoder can decode the information in the packet to determine whether it is a data packet, or more generally, whether it is a packet with time-sensitive data or a configuration packet, e.g., a packet with data that is not time-sensitive.

[0036] The distinction between data packets and configuration packets can vary depending on the particular implementation of the computing system. For example, data packets can be DMA payloads, CXL snoops, CCIX messages, etc., while configuration packets can include descriptors or commands for performing hot-swap, hot-add, or hot-remove (e.g., host-to-I / O device control messages). The embodiments herein can be used with any system that can branch data according to packet type.

[0037] If the packet is a data packet, method 300 proceeds to block 315, where the pass-through interface directly routes the data packet to the corresponding I / O function. In other words, the routing logic of the pass-through interface transfers the data packet on a direct data path that bypasses the embedded switch of the embedded component. In one embodiment, the decoder of the routing logic decodes the received data packet to identify the destination of the packet (e.g., identify the destination ID in the data packet). For example, when configuring a computing system (e.g., adding an I / O function or establishing communication between an I / O function and a host), the host can assign a destination ID known to the routing logic to the I / O function. When transmitting a packet to an embedded component, the host can embed the destination ID in the packet. The decoder can then identify these IDs, and the routing logic can ensure that the received packet is transferred to the appropriate I / O function, for example, using a de-mux.

[0038] However, if the packet is a configuration packet, method 300 proceeds to block 320 instead of block 315, and the pass-through interface transfers the configuration packet to the embedded switch. At block 325, the embedded switch determines whether the destination of the configuration packet is the switch itself or one of the multiple I / O functions. That is, in method 300, the host can transmit a configuration packet that configures the switch to perform a specific task addressed to the switch. The host can also send the configuration packet to an I / O function.

[0039] If the configuration packet is addressed to the switch, method 300 proceeds to block 330, where the embedded switch processes the packet in the switch's config space (not shown in FIG. 2). The configuration packet can change the operation of the switch's configuration by changing the config space.

[0040] When a configuration packet is addressed to one of a plurality of I / O functions, method 300 proceeds to block 335 instead of block 330, and the embedded switch transfers the packet to the corresponding I / O function. That is, the switch identifies the I / O function to which the configuration packet is addressed and transfers the packet to that I / O function using the indirect configuration data path.

[0041] Figure 4 is a flowchart of a method 400 for transmitting data packets and configuration packets from an I / O function to a host using different data paths according to an example. That is, method 300 describes a technique for transmitting data from a host to various circuit components of an embedded component using two data paths, while method 400 describes the transmission of data from an embedded component to a host using two data paths.

[0042] At block 405, the embedded switch receives a first configuration packet (e.g., a configuration response message) from one of a plurality of I / O functions. For example, the first configuration packet may be a response to a configuration packet already transmitted to the I / O function by the host.

[0043] In parallel, or substantially simultaneously, at block 410, the embedded switch receives a second configuration packet from the config space in the switch. Alternatively, in another embodiment, the embedded switch may receive two (or three or more) configuration packets substantially simultaneously from two of the plurality of I / O functions.

[0044] At block 415, the arbitration logic of the embedded switch arbitrates between a first configuration packet and a second configuration packet of the embedded switch. That is, it can store the first packet and the second packet in a queue, wait for arbitration to complete until it can transmit the packets to a pass-through interface and then to the host. This arbitration logic can be based on a quality of service (QoS) policy that may prefer I / O functions over the config space in the switch or may prefer one of a plurality of I / O functions over one or more of the other I / O functions.

[0045] Even if the arbitration logic of the switch determines the packet to send first out of the first packet and the second packet, the switch can still wait until it transmits the packet to the pass-through interface. As shown in FIG. 2, the pass-through interface 135 has its own arbitration logic 220 that determines a circuit (e.g., a switch or one of a plurality of I / O functions) that is allowed to transmit data to the host, for example using mux 225.

[0046] At block 420, the arbitration logic of the pass-through interface (e.g., arbitration logic 220) receives an indication that the switch has configuration packets (e.g., the first configuration packet and the second configuration packet) that it can transmit to the host at any time and that at least one I / O function has data packets for the host. That is, method 400 assumes that at least two devices of the embedded components (e.g., a switch and one of a plurality of I / O functions, or a plurality of I / O functions of a plurality of I / O functions) have data that they can send to the host at any time. If only one component wishes to transmit data to the host at the current time, the arbitration logic can simply allow that component to use a physical connection (e.g., a physical connection between the host and the integrated circuit) without performing any arbitration.

[0047] However, assuming that multiple components wish to transmit data to the host, at block 425, the arbitration logic of the pass-through interface arbitrates between the configuration packet and the data packet. In one embodiment, the arbitration logic can use a QoS policy that assigns a higher priority to the data packet than to the configuration packet. In other words, the QoS policy can prefer packets transmitted directly from the I / O function over packets transmitted by the switch. In another example, the QoS policy can prioritize I / O functions with respect to each other. For example, VMs (or tenants) of the host can have different priorities. One or more I / O functions of the embedded components used by a higher-priority VM of the host can be given a higher priority in the QoS policy used by the arbitration logic of the pass-through interface than the I / O functions used by a lower-priority VM of the host.

[0048] At block 430, the arbitration logic of the pass-through interface permits the transmission of the selected packets (determined by arbitration) to the host. In one embodiment, the arbitration logic has weighted arbitration and notifies one of the multiple I / O functions or the switch that the arbitration logic can access the shared bus (or send a particular amount or number of data) for a particular period of time. In this way, the arbitration logic can control the components of the embedded components that can use the shared physical connection between the embedded components and the host.

[0049] FIG. 5 is a flowchart of a method 500 for hot swapping a new I / O function, by way of example. For ease of explanation, method 500 is considered in conjunction with FIG. 6, which shows, by way of example, a computing system in which a new I / O function has been added.

[0050] At block 505, the embedded component receives a request from the host to add a new I / O function. In one embodiment, a software driver (executed within the host) for the embedded component determines to hot-add the new I / O function to the embedded component. For example, a VM or tenant running on the host may send a request for a new I / O function, or the hypervisor may determine that the VM or tenant is requesting a new I / O function.

[0051] In FIG. 6, computing system 600 includes an embedded component 660 that is in the process of adding an I / O function. That is, as shown by the dashed lines, Accelerator Function 0 (AF0) and CXL.Cache X are added into the embedded component 660, while AF1 and CXL.Cache Y are already operating within the embedded component 660. In FIG. 6, the I / O functions, namely AF0, AF1, CXL.Cache X, and CXL.Cache Y, are implemented in programmable logic, while it is assumed that AF0 Config Space, ID-X Config Space, ID-Y Config Space, AF1 Config Space, and the embedded CXL isolation switch 615 are implemented in a hardened circuit mechanism. That is, by reconfiguring the programmable logic, the embedded component 660 can hot-swap (i.e., hot-add or hot-remove) the I / O functions, namely AF0, AF1, CXL.Cache X, and CXL.Cache Y. However, in another embodiment, the I / O functions can also be implemented in hardened logic. In that example, instead of adding or removing the I / O functions, host 105 can hot-add or hot-remove the I / O functions by selectively activating or deactivating the I / O functions.

[0052] In another embodiment, the I / O functions, namely AF0, AF1, CXL.Cache X, and CXL.Cache Y, and the AF0 Config Space, ID-X Config Space, ID-Y Config Space, and AF1 Config Space are realized in programmable logic such that when the components 660 incorporating AF0 and CXL.Cache X are added, a partially reconfigured programmable logic bitstream is added to AF0 and CXL.Cache X prior to the start of the hot-add event. In this embodiment, both AF0 and CXL.Cache X may be hot-pluggable devices having functionality that is loaded earlier as a programmable logic bitstream.

[0053] At block 510, the incorporated component receives configuration information and binding for the new I / O function from the host. In one embodiment, the configuration information can include data for adding an I / O function to the incorporated component or activating the I / O function of the incorporated component. Further, the host transmits identification data that informs the path-through interface (more specifically, the path-specifying logic of the path-through interface), which is used as a binding for the I / O function, of the identification data assigned to the new I / O function by the host. The path-specifying logic of the path-through interface can then use this identification data when decrypting the received data packet and determining whether the packet should be routed to the new I / O function as described in method 300 above.

[0054] Block 510 includes a sub-block 515 in which the integrated circuit receives a bitstream including structures for new I / O functions, data path bindings, and configuration data bindings. In one embodiment, sub-block 515 is implemented when the I / O function is realized by programmable logic. For example, the embedded component 660 can use the bitstream to configure the programmable logic to include AF0 and CXL.Cache X. Also, the bitstream can also include structures for the registers of AF0 and ID-X Config Spaces.

[0055] The data path binding can provide routing information used by the pass-through interface to directly route data packets to the new I / O function. On the other hand, the configuration data binding includes routing information used by the embedded switch and the pass-through interface 135 to route configuration data packets to the new I / O function using an indirect configuration data path. That is, with the data path binding, data can reach CXL.Cache X directly from the pass-through interface 135, while with the configuration data binding, data can reach AF0 and ID-X Config Spaces via the embedded CXL switch 615.

[0056] At block 520, the embedded component activates the new I / O function and its binding. That is, the embedded component configures the programmable logic to include the new I / O function or activates the I / O function in the hardened circuit mechanism that has been deactivated until now using the information obtained at block 510.

[0057] At block 525, the embedded component transmits a virtual Hot-Plug Event to the host. In FIG. 6, switch 615 generates a virtual Hot Plug Event and transfers the event to the Host Hot-Plug software driver that executes on the host. Although the new I / O function is directly attached to the upstream port, the virtual Hot Plug Event indicates to the host that a new I / O function (e.g., a new I / O device) is plugged in (or communicatively coupled) to the virtual downstream port connected to the virtual endpoint connection between the AF0 Config Space and switch 615.

[0058] At block 530, the host discovers the new I / O function using the configuration packet sent on the configuration data path. For example, the Host Hot-Plug Software Driver can respond to the virtual Hot-Plug Event and can proceed to discover the new endpoint I / O functions AF0 and CXL.Cache X using the configuration read message routed from the CSL root port (RP) 605 to the CXL upstream port (USP) 610 and then to switch 615 via the pass-through interface 135. Switch 615 can then transfer the configuration read message to the virtual endpoint registers in the AF0 and ID-X Config Spaces.

[0059] At block 535, the host enumerates the new I / O function by programming the corresponding registers. In one embodiment, host 105 enumerates AF0 and CXL.Cache X by programming the AF0 and ID-X Config Spaces registers using the device IDs of CXL.Cache X and AF0. Host 105 can then communicate data traffic to the new I / O function at any time using the direct data path and the indirect configuration data path.

[0060] In one embodiment, upon completion of the above blocks, at block 540, the host and the embedded components route data packets to the new I / O function using a direct data path. At block 545, the host and the embedded components route configuration packets to the new I / O function using an indirect configuration data path. According to this method, the host and the embedded components can hot-add a new I / O device.

[0061] FIG. 7 shows a computing system 700 in which, by way of example, a host is communicating with a converged NIC implemented using an embedded component 760. Similar to the computing system described above, computing system 700 includes a host 105 communicatively coupled to an embedded component 760 using a single physical connection between a PCIe RP 705 and a PCIe USP 710. Further, the embedded component 760 includes a direct data path between the host 105 and I / O functions (i.e., DMA Engines 0-3), and a pass-through interface 135 for establishing an indirect configuration data path including an embedded PCIe split switch 715.

[0062] FIG. 7 shows a PCIe component (e.g., the embedded component 760) connected to a PCIe-connected Server (e.g., host 105). The embedded component 760 includes PCI DMA Engines 0-3 having an interface with short latency and wide bandwidth to the host 105, and corresponding services, and the corresponding services are separate from their control and status structures or configuration spaces. In this example, the individual DMA Engines 0-3 correspond to different network functions of a converged NIC (also called a SmartNIC). For example, DMA Engine 0 corresponds to network services, DMA Engine 1 corresponds to Remote Direct Memory Access (RDMA) services, DMA Engine 2 corresponds to Non-Volatile Memory Express Over Fiber (NVMEoF) services, and DMA Engine 3 corresponds to storage services. High Bandwidth Device-to-Host DMA traffic for Network, RDMA, NVMEoF, and Storage Services follows a direct data path. Further, Host-to-I / O Function Job Descriptors with short latency destined for these Network, RDMA, NVMEoF, and Storage Services can also follow the same direct data path. In contrast, the PCIe switch 715 can route Host-to-I / O Function low-performance control path traffic for DMA Engines 0-3 and the corresponding Network, RDMA, NVMEoF, and Storage Configuration Spaces along an indirect configuration data path.

[0063] DMA Engines 0-3 can be implemented using programmable logic or hardwired circuitry. Further, using the hot-add and removal techniques discussed above, DMA Engines 0-3 and the corresponding services can be added and removed (e.g., powered on and powered off).

[0064] By creating a direct data path distinct from the indirect path that includes the embedded switch, embodiments herein provide a low-latency, high-bandwidth data path interface to the host that includes the ability to hot-plug, add / remove endpoints (e.g., I / O functions). By using a direct data path instead of mediating through a switch, excellent performance is obtained for many embodiments, such as low-latency snooping responses for CXL.Cache and CCIX Cache embodiments, low-latency and high-bandwidth memory traffic for CXL.mem and CCIX Home Agent and Slave Agent embodiments, and low-latency descriptor communication and high-bandwidth DMA Reads / Writes for PCIe Endpoint embodiments.

[0065] The above description refers to embodiments presented in the present disclosure. However, the scope of the present disclosure is not limited to the specific embodiments described. Instead, any combination of the features and elements described, whether related to different embodiments or not, is intended to be realized, and it is intended to practice the contemplated embodiments. Further, the embodiments disclosed herein can achieve advantages over other possible solutions or over the prior art, but whether a particular advantage is achieved by a given embodiment or not does not limit the scope of the present disclosure. Accordingly, the above aspects, features, embodiments, and advantages are merely illustrative and are not considered to be elements or limitations of the appended claims unless explicitly recited in the claims.

[0066] As will be appreciated by those skilled in the art, the embodiments disclosed herein can be embodied as a system, method, or computer program product. Accordingly, aspects may take the form of an entirely hardware embodiment, an entirely software embodiment (including firmware, resident software, micro-code, etc.), or an embodiment combining software and hardware aspects, all of which may be collectively referred to herein as a "circuit," "module," or "system." Further, aspects may take the form of a computer program product embodied in one or more computer-readable media having computer-readable program code embodied thereon.

[0067] Any combination of one or more computer-readable media may be utilized. The computer-readable media may be a computer-readable signal medium or a computer-readable storage medium. A computer-readable storage medium may be, for example but not limited to, an electronic, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any suitable combination thereof. More specific examples (a non-exhaustive list) of the computer-readable storage medium would include the following: an electrical connection having one or more wires, a portable computer diskette, a hard disk, a random access memory (RAM), a read-only memory (ROM), an erasable programmable read-only memory (EPROM or Flash memory), an optical fiber, a portable compact disc read-only memory (CD-ROM), an optical storage device, a magnetic storage device, or any suitable combination thereof. In the context of this document, a computer-readable storage medium may be any tangible medium that can contain, or store a program for use by or in connection with an instruction execution system, apparatus, or device.

[0068] A computer-readable signal medium can include a propagated data signal in which a computer-readable program code is embodied, for example, in baseband or as part of a carrier wave. Such propagated signals can take any of a variety of forms, including, but not limited to, electromagnetic, optical, or any suitable combination thereof. A computer-readable signal medium may be any computer-readable medium that is not a computer-readable storage medium and that can communicate, propagate, or transport a program for use by or in connection with an instruction execution system, apparatus, or device.

[0069] The program code embodied on the computer-readable medium can be transmitted using any appropriate medium, including, but not limited to, wireless, wired, fiber optic cable, RF, etc., or any suitable combination thereof.

[0070] The computer program code for carrying out operations for aspects of this disclosure can be written in any combination of one or more programming languages, including object-oriented programming languages such as Java, Smalltalk, C++, etc., and conventional procedural programming languages such as the "C" programming language or similar programming languages. The program code can execute entirely on the user's computer, execute partly on the user's computer as a stand-alone software package, execute partly on the user's computer and partly on a remote computer, or execute entirely on the remote computer or server. In the latter scenario, the remote computer can be connected to the user's computer through any type of network, including a local area network (LAN) or a wide area network (WAN), or the connection can be made to an external computer (e.g., through the Internet using an Internet service provider).

[0071] Aspects of the present disclosure will be described below with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments presented in the disclosure. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general purpose computer, special purpose computer, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, create means for realizing the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0072] These computer program instructions can also be stored in a computer-readable medium that can direct a computer, other programmable data processing apparatus, or other devices to function in a particular manner, such that the instructions stored in the computer-readable medium produce an article of manufacture including instructions which realize the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0073] The computer program instructions can also be loaded onto a computer, other programmable data processing apparatus, or other devices to cause a series of operational steps to be performed on the computer, other programmable apparatus, or other devices to produce a computer-implemented process, such that the instructions which execute on the computer, other programmable apparatus, or other devices provide a process for realizing the functions / acts specified in one or more blocks of the flowchart and / or block diagram.

[0074] The flowcharts and block diagrams in the figures illustrate the architecture, functionality, and operation of possible embodiments of systems, methods, and computer program products according to various examples of the present invention. In this regard, each block in the flowchart or block diagram can represent a module, segment, or portion of instructions that includes one or more executable instructions for implementing the specified logical function. In some alternative embodiments, the functions recited in the blocks may occur out of the order recited in the figures. For example, two blocks shown in succession may in fact be executed substantially concurrently, or the blocks may sometimes be executed in the reverse order depending on the functionality involved. It should also be noted that each block of the block diagrams and / or flowchart illustrations, and combinations of blocks in the block diagrams and / or flowchart illustrations, can be implemented by a dedicated hardware-based system that performs the specified functions or acts, or combinations of dedicated hardware and computer instructions.

[0075] The present disclosure can also be illustrated by one or more of the following non-limiting examples.

[0076] Example 1. A computing system including a host including a first port and an embedded component. The embedded component includes a second port, where the first port and the second port form a physical connection between the host and the embedded component, a plurality of I / O functions, an embedded switch, and a pass-through interface configured to receive a packet from the host via the second port, identify the type of the packet, and route the packet directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using the embedded switch based on the type of the packet.

[0077] Example 2. The computing system of Example 1, wherein the plurality of I / O functions operate independently of each other and perform different I / O functions.

[0078] Example 3. A computing system according to Example 1, wherein the packet type indicates whether the packet is a time-sensitive data packet, and routing the packet directly to the destination I / O function bypasses the embedded switch.

[0079] Example 4. A computing system according to Example 1, wherein the pass-through interface receives an indication that both the first I / O function among a plurality of I / O functions and the embedded switch have data that can be transmitted to the host at any time, and mediates to determine which of the first I / O function and the embedded switch to permit the use of the second port to transmit the data to the first port of the host.

[0080] Example 5. A computing system according to Example 1, wherein the pass-through interface includes routing logic for identifying the packet type and identifying the destination ID in the packet corresponding to the destination I / O function.

[0081] Example 6. A computing system according to Example 1, wherein the host is configured to hot-add a new I / O function into the integrated components while the plurality of I / O functions are operating in parallel.

[0082] Example 7. A computing system according to Example 6, wherein hot-adding a new I / O function includes configuring the programmable logic of the integrated component to include the new I / O function.

[0083] Example 8. A computing system according to Example 6, wherein hot-adding a new I / O function includes activating the new I / O function that has been deactivated until then, and the new I / O function is implemented by hardened logic.

[0084] Example 9. A first port configured to form a physical connection with a second port on a host, a plurality of I / O functions, an embedded switch, receiving a packet from the host via the first port, identifying the type of the packet, and routing the packet directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using the embedded switch based on the type of the packet. A pass-through interface configured as such.

[0085] Example 10. The apparatus of Example 9, wherein the plurality of I / O functions are independent I / O devices, and each of the independent I / O devices is at least partially realized by programmable logic.

[0086] Example 11. The apparatus of Example 10, wherein the independent I / O devices are formed within the same integrated circuit.

[0087] Example 12. The apparatus of Example 9, wherein the plurality of I / O functions are independent I / O devices, and each of the independent I / O devices is realized using hard logic.

[0088] Example 13. The apparatus of Example 12, wherein the independent I / O devices are formed within the same integrated circuit.

[0089] Example 14. The apparatus of Example 9, further including a substrate, each of the plurality of I / O functions being realized by a different integrated circuit, and the different integrated circuits and the embedded switch being mounted on the substrate.

[0090] Example 15. The apparatus of Example 9, wherein the apparatus is configured to hot-add a new I / O function while the plurality of I / O functions are operating in parallel.

[0091] Example 16. The apparatus of Example 15, wherein hot-adding a new I / O function includes configuring the programmable logic of the apparatus to include the new I / O function.

[0092] Example 17. The apparatus of Example 15, wherein hot-adding a new I / O function includes activating the new I / O function that had been deactivated until then, and the new I / O function is implemented in the device's hard logic.

[0093] Example 18. Receiving a first packet from a host at an embedded component's pass-through interface, where the embedded component includes a plurality of I / O functions and an embedded switch communicatively coupled to the pass-through interface, receiving the first packet, and determining that the first packet is a data packet, where a first I / O function among the plurality of I / O functions is the destination of the data packet, routing the data packet directly from the pass-through interface to the first I / O function using a direct data path that bypasses the embedded switch, receiving a second packet from the host at the pass-through interface, and determining that the second packet is a configuration packet, where the first I / O function is the destination of the configuration packet, and routing the data packet from the pass-through interface to the first I / O function via the embedded switch.

[0094] Example 19. Routing a data packet from a pass-through interface to a first I / O function via an embedded switch further includes routing a configuration packet from the pass-through interface to the embedded switch, determining at the embedded switch that the first I / O function is the destination of the configuration packet, and transferring the configuration packet from the embedded switch to the first I / O function. The method further includes receiving a third packet from the host at the pass-through interface, determining that the third packet is a different configuration packet, routing the different configuration packet to the embedded switch, and determining at the embedded switch that the embedded switch is the destination of the different configuration packet.

[0095] Example 20. The method of Example 19, further comprising determining, with a pass-through interface, that at least two of the embedded switch and the plurality of I / O functions have packets that can be transmitted to the host at any time, and adjusting between the embedded switch and at least two of the plurality of I / O functions based on a quality of service (QoS) policy to determine which shared port of the components incorporated therein to permit use of to transmit data to the host.

[0096] While specific examples have been targeted above, it is also possible to devise other examples and further examples without departing from their basic scope, which is determined by the appended claims.

Claims

**Claim 1** An embedded component, comprising: A first port configured to form a physical connection between a host and the embedded component; A plurality of I / O functions; An embedded switch; A pass-through interface configured to receive a packet from the host via the first port, identify a type of the packet, and route the packet directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using the embedded switch based on the type of the packet; The embedded component. **Claim 2** The component according to claim 1, wherein the plurality of I / O functions operate independently of each other and perform different I / O functions. **Claim 3** The component according to claim 1, wherein the type of the packet indicates whether the packet is a time-sensitive data packet, and routing the packet directly to the destination I / O function bypasses the embedded switch. **Claim 4** The component according to claim 1, wherein the pass-through interface receives an indication that both a first I / O function among the plurality of I / O functions and the embedded switch have data that can be transmitted to the host at any time, and comprises arbitration logic configured to arbitrate to determine which of the first I / O function and the embedded switch to permit use of the first port for transmitting data to the host. **Claim 5** The component according to claim 1, wherein the pass-through interface comprises routing logic configured to identify the type of the packet and identify a destination ID in the packet corresponding to the destination I / O function. **Claim 6** The component according to claim 1, wherein the host is configured to hot-add a new I / O function into the embedded component while the plurality of I / O functions are operating in parallel. **Claim 7** Hot-adding the new I / O function comprises: Configuring programmable logic of the embedded component to include the new I / O function, according to claim 6. **Claim 8** Activating the new I / O function that has been deactivated until then, the component according to claim 6, wherein the new I / O function is implemented in hard logic.

9. An apparatus, comprising: A first port configured to form a physical connection with a second port on a host; A plurality of I / O functions; An embedded switch; Receiving a packet from a host via the first port, identifying the type of the packet, and routing the packet directly to a destination I / O function among the plurality of I / O functions or indirectly to the destination I / O function using the embedded switch based on the type of the packet. A pass-through interface configured to route the packet; An apparatus comprising the same.

10. The apparatus according to claim 9, wherein the plurality of I / O functions are independent I / O devices, and each of the independent I / O devices is implemented at least partially in programmable logic.

11. The apparatus according to claim 10, wherein the independent I / O devices are formed in the same integrated circuit.

12. The apparatus according to claim 9, wherein the plurality of I / O functions are independent I / O devices, and each of the independent I / O devices is implemented using hard logic.

13. The apparatus according to claim 12, wherein the independent I / O devices are formed in the same integrated circuit.

14. A substrate Further comprising, wherein each of the plurality of I / O functions is implemented in a different integrated circuit, and the different integrated circuits and the embedded switch are mounted on the substrate, the apparatus according to claim 9.

15. The apparatus according to claim 9, wherein the apparatus is configured to hot-add a new I / O function while the plurality of I / O functions are operating in parallel.

16. Hot-adding the new I / O function includes Configuring the programmable logic of the apparatus to include the new I / O function, the apparatus according to claim 15.

17. Hot-adding the new I / O function includes Activating the new I / O function that has been deactivated until then, the apparatus according to claim 15, wherein the new I / O function is implemented in the hard logic of the apparatus.

18. A method, comprising: Receiving a first packet from a host through a pass-through interface of an embedded component, wherein the embedded component includes a plurality of I / O functions and an embedded switch communicatively coupled to the pass-through interface, receiving the first packet Determining that the first packet is a data packet, wherein a first I / O function among the plurality of I / O functions is a destination of the data packet, determining that the first packet is a data packet Directing the data packet directly from the pass-through interface to the first I / O function using a direct data path that bypasses the embedded switch Receiving a second packet from the host at the pass-through interface Determining that the second packet is a configuration packet, wherein the first I / O function is a destination of the configuration packet, determining that the second packet is a configuration packet Routing the configuration packet from the pass-through interface to the first I / O function via the embedded switch A method comprising

19. Routing the configuration packet from the pass-through interface to the first I / O function via the embedded switch includes Routing the configuration packet from the pass-through interface to the embedded switch Determining at the embedded switch that the first I / O function is a destination of the configuration packet Further including transferring the configuration packet from the embedded switch to the first I / O function, and the method Receiving a third packet from the host at the pass-through interface Determining that the third packet is a different configuration packet Routing the different configuration packet to the embedded switch The method according to claim 18, further comprising determining at the embedded switch that the embedded switch is a destination of the different configuration packet

20. Determining at the pass-through interface that at least two of the embedded switch and the plurality of I / O functions have packets that can be transmitted to the host at any time ​ To determine which of the shared ports of the embedded components to permit for transmitting data to the host, mediate between the embedded switch and at least two of the plurality of I / O functions based on a quality of service (QoS) policy, the method according to claim 19.

Images