Patent Description:
Recent developments in USB (Universal Serial Bus, e.g., USB4 Specification, Version <NUM>, August <NUM>, USB <NUM> Promoter Group) technology may support the use of different high speed transport protocols to tunnel IO traffic through a shared USB hub (e.g., in a converged IO/CIO architecture). In such a case, a connection manager may manage the allocation of bandwidth across the various transport protocols in use. Conventional connection manager solutions, however, may result in ineffective power and performance management of tunneled IO transactions. For example, the connection manager may select a bandwidth allocation that results in a relatively low priority protocol experiencing starvation conditions (e.g., insufficient lane assignments) and/or failures.

<CIT> discloses methods and apparatus for efficiently transporting data through network tunnels, including a tunneled devices that advertises certain capabilities to peer devices of a network, and discovers capabilities of peer devices of the network, and in one embodiment each device of a tunneled network derives a network parameter from a transit protocol parameters for use in data networking. A computerized apparatus includes a processor subsystem, a memory subsystem, and a tunnel communications controller operative communication with one or more network interfaces.

<CIT> describes automatic-switching and deployment of software or firmware based USB4 connection managers (CMs). Support for continued USB4 operation during an OS upgrade or downgrade is provided, while ensuring that the best possible CM solution is used based on the advertised platform and OS capability. USB4 controllers support a pass-through mode under which the host controller FW redirects control packets sent between an SW CM and a USB4 fabric, and a FW CM mode under which control packets are communicated between the host controller FW and the USB4 fabric to configure USB4 peripheral devices and/or USB4 hubs in the USB4 fabric.

<CIT> discloses a shared physical interface, a processor coupled to the shared physical interface and a plurality of input/output, IO, drivers, each of the plurality of IO drivers configured to tunnel traffic through the shared physical interface in accordance with a corresponding protocol, wherein the corresponding protocol differs from protocols corresponding to other IO drivers of the plurality of IO drivers. A logic allocates, based on latency and performance requirements of each IO driver, bandwidth of the shared physical interface among the plurality of IO drivers.

The present invention pursued in this application is defined in the appended set of claims.

Turning now to <FIG>, a multi-level scheduling architecture <NUM> is shown in which tunneling paths (e.g., "Path m," "Path k," "Path n," "Path q," with the exception of a high priority "Path <NUM>") are organized into priority groups <NUM> (12a-<NUM>). In general, a connection manager (not shown) may set up the tunneling paths for different protocols such as, for example, display protocols (e.g., <NPL>), storage protocols (e.g., <NPL>), network protocols (e.g., <NPL>), and so forth.

In an embodiment, the tunneling paths pass through a shared physical interface such as, for example, a USB hub (not shown). In one example, each group <NUM> is assigned a priority, with the highest priority group <NUM> being scheduled first by a priority group scheduler <NUM>. Additionally, within each group <NUM>, every path may be provided a weight that is used by path schedulers <NUM> to perform round robin scheduling. Thus, a path with weight X might have X packets scheduled for the path in a given round. In the illustrated example, the path scheduling and group scheduling information is used to initiate/trigger a state change <NUM> (e.g., clock frequency, operating voltage, power state and/or performance state change) in a processor (e.g., host processor, central processing unit/CPU, not shown) coupled to the shared physical interface. As will be discussed in greater detail, the state change <NUM> may prevent starvation conditions (e.g., insufficient lane assignments) and/or failures (e.g., user-visible failures) with respect to the different protocols. The illustrated solution therefore enables enhanced performance to be achieved in a converged IO architecture.

<FIG> shows a converged IO architecture <NUM> in which a computing system <NUM> uses a shared physical interface to tunnel traffic (e.g., data, instructions) to a high resolution display <NUM> in accordance with a display protocol (e.g., DP), a high bandwidth storage device <NUM> (e.g., storage device that complies with <NPL>) in accordance with a storage protocol (e.g., PCIe), a cloud computing infrastructure <NUM> in accordance with a network protocol (e.g., Ethernet over USB <NUM>/USB3), and so forth. In an embodiment, the display protocol tunnels carry periodic information such as, for example, isochronous information and interrupts. The storage protocol and network protocol tunnels, by contrast, may carry aperiodic information (e.g., control information, bulk information) in addition to periodic information. In one example, the periodic transfers are provided with a definite service opportunity (e.g., Path <NUM> in <FIG>), whereas the aperiodic transfers are scheduled using round robin scheduling within a priority group <NUM> (<FIG>, e.g., the fastest transfer on an otherwise idle bus). Therefore, the connection manager may prioritize the display protocol over the storage protocol and prioritize the storage protocol over the network protocol in terms of bandwidth.

If the computing system <NUM> is conducting an active user activity such as, for example, playing a game served by the cloud computing infrastructure <NUM> and presenting the game on the display <NUM>, while syncing data into the storage device <NUM>, such a scenario may involve all three tunnel protocols being in peak usage (e.g., leading to a high bandwidth requirement). In such a case, the priority given to isochronous (e.g., display and/or audio activity) might lead to starvation of the storage or other USB activities. To prevent starvation conditions and other failures, knowledge of the USB4 tunneled protocol bandwidth requirements (e.g., and potential performance bottlenecks) are communicated from the connection manager to processor governors, which change the operating state of the processor. The result is more effective management of processor capabilities for better performance and power conservation.

Turning now to <FIG>, a feedback loop <NUM> is shown between a connection manager daemon <NUM> and a USB4 governor <NUM> (e.g., in a Linux architecture). In the illustrated example, the connection manager daemon <NUM> uses a connection manager <NUM> (e.g., device driver) to communicate with a PCIe bus driver <NUM>. The PCIe bus driver <NUM> may communicate with a software stack <NUM> that includes a protocol adapter <NUM> (e.g., implemented at a protocol adapter layer and a transport layer), a control adapter <NUM> (e.g., implemented at a configuration layer and the transport layer), and a lane adapter <NUM> (e.g., implemented at the transport layer, a logical layer, and an electrical layer).

In an embodiment, the USB4 governor <NUM> is coupled to user space governors <NUM> such as, for example, a dynamic voltage and frequency scaling (DVFS) governor and/or an active state power management (ASPM) governor. The user space governors <NUM> change the operating state of a CPU <NUM> via CPU governor drivers <NUM> and a CPU driver <NUM>. In the illustrated example, the feedback loop <NUM> includes connection manager feedback such as, for example, the bandwidth/power needs of the IO protocols in use. Accordingly, the state changes conducted by the user space governors <NUM> is initiated and/or triggered by the connection manager <NUM> through the feedback loop <NUM> to prevent starvation conditions, failures, and so forth.

<FIG> shows a method <NUM> of operating a performance-enhanced computing system. The method <NUM> may generally be implemented in a connection manager such as, for example, the connection manager <NUM> (<FIG>), already discussed. More particularly, the method <NUM> may be implemented in one or more modules as a set of logic instructions stored in a machine- or computer-readable storage medium such as random access memory (RAM), read only memory (ROM), programmable ROM (PROM), firmware, flash memory, etc., in configurable logic such as, for example, programmable logic arrays (PLAs), field programmable gate arrays (FPGAs), complex programmable logic devices (CPLDs), in fixed-functionality logic hardware using circuit technology such as, for example, application specific integrated circuit (ASIC), complementary metal oxide semiconductor (CMOS) or transistor-transistor logic (TTL) technology, or any combination thereof.

For example, computer program code to carry out operations shown in the method <NUM> may be written in any combination of one or more programming languages, including an object oriented programming language such as JAVA, SMALLTALK, C++ or the like and conventional procedural programming languages, such as the "C" programming language or similar programming languages. Additionally, logic instructions might include assembler instructions, instruction set architecture (ISA) instructions, machine instructions, machine dependent instructions, microcode, state-setting data, configuration data for integrated circuitry, state information that personalizes electronic circuitry and/or other structural components that are native to hardware (e.g., host processor, central processing unit/CPU, microcontroller, etc.).

Illustrated processing block <NUM> provides for collecting state data from a plurality of IO drivers, wherein each of the plurality of IO drivers is to tunnel traffic through a shared physical interface in accordance with a different protocol. The state data generally indicates the level of activity and/or bandwidth demand from the different protocols and/or drivers. For example, block <NUM> might include collecting state data from a first IO driver, wherein the first IO driver tunnels traffic in accordance with a display protocol (e.g., DP handling periodic information). Block <NUM> may also collect state data from a second IO driver, wherein the second IO driver tunnels traffic in accordance with a storage protocol (e.g., USB handling periodic and/or aperiodic information). In another example, block <NUM> includes collecting state data from a third IO driver, wherein the third IO driver tunnels traffic in accordance with a network protocol (e.g., PCIe handling aperiodic information).

Block <NUM> provides for determining, based on the collected state data, a bandwidth allocation of the shared physical interface among the plurality of IO drivers. In an embodiment, block <NUM> includes prioritizing the display protocol over the storage protocol. Additionally, block <NUM> may prioritize the storage protocol over the network protocol. In one example, the bandwidth allocation specifies (e.g., in terms of bits per second/bps, lanes, etc.) the amount of bandwidth allocated to the respective protocols, drivers and/or tunnels. Illustrated block <NUM> provides for automatically initiating, based on the bandwidth allocation, a state change of a processor coupled to the shared physical interface. The state change includes an increase or decrease in, for example, a clock frequency, an operating voltage, a power state (e.g., Advanced Configuration and Power Interface/ACPI power state), a performance state (e.g., ACPI performance state), etc., or any combination thereof. In an embodiment, the state change prevents one or more of a starvation condition or a failure in at least one of the plurality of IO drivers.

Thus, when block <NUM> detects high bandwidth usage, the processor governors may be influenced and/or instructed to improve the processor performance and ensure that the bandwidth allocation is effective in improving the performance of the tunneled protocols. Subsequently, when the block <NUM> detects that the tunneled protocols are less bandwidth intensive, the processor governors may be influenced/instructed to enter a power conserving mode. Alternatively, block <NUM> may also adopt a "race to halt" mode when data (e.g., storage rather than display) intensive operation is detected in a protocol. Such an approach increases the processor clock to complete the data transfers quickly, followed by a halt to save power.

In another example, if a PCIe-based network card is used in a system along with a USB3 high-resolution webcam, block <NUM> may treat the PCIe traffic as a non-isochronous transfer, which will not receive guaranteed bandwidth in the shared physical interface. By contrast, block <NUM> may treat the USB3 traffic as an isochronous transfer that receives guaranteed bandwidth in the shared physical interface. In such a case, block <NUM> might instruct the processor frequency scaling governor to switch to a higher frequency. Experimental results show an unexpected <NUM>% increase (from <NUM> Gbps to <NUM> Gbps) of TCP (Transmission Control Protocol) throughput on the PCIe network card, when switching to a "performance" governor from a "powersave" governor in such a case. The illustrated method <NUM> may also be useful in improving block read and write throughput when using, for example, an NVM EXPRESS solid state drive (SSD) as secondary storage. The method <NUM> therefore enhances performance at least in terms of fewer starvation conditions and/or failures in a converged IO architecture.

<FIG> shows a more detailed converged IO architecture <NUM>. In the illustrated example, a USB4 connection manager <NUM> (e.g., including logic instructions, configurable logic, fixed-functionality hardware logic, etc., or any combination thereof) sets up a USB driver <NUM>, a PCIe bus driver <NUM>, and a display kernel mode driver <NUM> to tunnel USB4 packets into a host router <NUM>, which is coupled to a USB4 port and physical layer (Phy) <NUM>. The connection manager <NUM> collects periodic/aperiodic usage state data <NUM> from the USB driver <NUM>, high bandwidth device state data <NUM> from the PCIe bus driver <NUM>, and high resolution state data <NUM> from the display kernel mode driver <NUM>. The connection manager <NUM> then computes <NUM> overall bandwidth usage for the USB driver <NUM>, the PCIe bus driver <NUM>, and the display kernel mode driver <NUM>.

In an embodiment, the connection manager <NUM> triggers <NUM> a switch between performance and power save governors. Upon detecting the switch, a CPU frequency (e.g., DVFS) core <NUM> obtains <NUM> P-state information for a scaling governor <NUM>. In one example, the scaling governor <NUM> issues <NUM> a scale up or scale down signal to a CPU scaling driver <NUM>, which in turn sends <NUM> available P-states for a CPU group back to the scaling governor <NUM>. The CPU scaling driver <NUM> may communicate directly with one or more CPU cores <NUM>.

Thus, the connection manager <NUM> leverages knowledge of the various protocol drivers to manage the bandwidth allocation and other IO functionalities. As already noted, between the IO groups, DP may be part of the highest priority group, followed by USB3 and PCIe sharing the next lower priority group. Within the USB3 & PCIe priority group, USB3 may receive higher round-robin weightage and have bandwidth reserved for isochronous transfers.

For example, considering a bandwidth allocation out of <NUM> Gbps (e.g., in decreasing order) DP, which is all isochronous, may receive <NUM>% of the bandwidth allocation, depending on the number of DP links (e.g., up to two) and the number of lanes per link (e.g., up to four, with one DP link).

For example, for high bit rate (HBR) 3x4Lanes: Bandwidth = <NUM>. 1Gbps * <NUM> * <NUM> = <NUM> Gbps.

The remaining bandwidth for the periodic/aperiodic usage from the USB driver <NUM> may be used at a maximum 20Gbps and the high bandwidth device usage from the PCIe bus driver <NUM> may be up to sixteen lanes (e.g., NVME storage device). Accordingly, the connection manager <NUM> may determine the bandwidth remaining and the class level activities of the USB driver <NUM> and the PCIe bus driver <NUM> to determine the functionalities configured on top of these IO protocols. The connection manager <NUM> also compares this information with bandwidth health and failure information. Based on these inputs, when the activity is high, the illustrated connection manager <NUM> instructs the processor governor to switch to performance mode (e.g., "turbo" mode). The connection manager <NUM> may also directly skew the clock to a higher value to improve the bandwidth health. Finally, when the connection manager <NUM> determines that the activity on the tunneled protocols is reduced or disconnected, the connection manager <NUM> may instruct the processor governors to switch to "powersave" or instruct frameworks managing the IO framework (e.g., ASPM) to switch to low power modes.

As already noted, the connection manager <NUM> may alternatively conserve energy during operation by adopting a race to halt mode on high data transfer operations. Such a mode may be achieved by skewing the clock to higher performance, completing data intensive transfers and then entering a power saving mode.

Turning now to <FIG>, a performance-enhanced computing system <NUM> is shown. The system <NUM> may generally be part of an electronic device/platform having computing functionality (e.g., personal digital assistant/PDA, notebook computer, tablet computer, convertible tablet, server), communications functionality (e.g., smart phone), imaging functionality (e.g., camera, camcorder), media playing functionality (e.g., smart television/TV), wearable functionality (e.g., watch, eyewear, headwear, footwear, jewelry), vehicular functionality (e.g., car, truck, motorcycle), robotic functionality (e.g., autonomous robot), etc., or any combination thereof. In the illustrated example, the system <NUM> includes a host processor <NUM> (e.g., CPU) having a governor <NUM> and an integrated memory controller (IMC) <NUM> that is coupled to a system memory <NUM>.

The illustrated system <NUM> also includes an input output (IO) module <NUM> implemented together with the host processor <NUM> and a graphics processor <NUM> (e.g., graphics processing unit/GPU) on a semiconductor die <NUM> as a system on chip (SoC). The illustrated IO module <NUM> communicates with, for example, a display <NUM> (e.g., touch screen, liquid crystal display/LCD, light emitting diode/LED display), a network controller <NUM> (e.g., wired and/or wireless), and mass storage <NUM> (e.g., hard disk drive/HDD, optical disk, solid state drive/SSD, flash memory). The IO module <NUM> also includes a shared physical interface <NUM> (e.g., USB hub).

In an embodiment, the host processor <NUM>, the graphics processor <NUM> and/or the IO module <NUM> execute connection manager program instructions <NUM> retrieved from the system memory <NUM> and/or the mass storage <NUM> to perform one or more aspects of the method <NUM> (<FIG>), already discussed. Thus, execution of the illustrated instructions <NUM> causes the computing system <NUM> to collect state data from a plurality of IO drivers wherein each of the IO drivers is to tunnel traffic through the shared physical interface <NUM> in accordance with a different protocol. For example, a first IO driver may tunnel traffic to the display <NUM> in accordance with a display protocol, a second IO driver may tunnel traffic to the mass storage <NUM> in accordance with a storage protocol, a third IO driver may tunnel traffic to the network controller <NUM> in accordance with a network protocol, and so forth. The computing system <NUM> may also support THUNDERBOLT interfaces and the daisy-chaining of devices (e.g., in a host-to-host configuration).

Execution of the instructions <NUM> also causes the computing system <NUM> to determine, based on the state data, a bandwidth allocation of the shared physical interface <NUM> among the plurality of IO drivers. In an embodiment, the bandwidth allocation prioritizes the display protocol over the storage protocol. The bandwidth allocation may also prioritize the storage protocol over the network protocol. Execution of the instructions <NUM> causes the computing system <NUM> to initiate a state change (e.g., clock frequency change, operating voltage change, power state change, performance state change, etc.) of the host processor <NUM> based on the bandwidth allocation. The state change, which may be triggered via one or more instructions to the governor <NUM>, prevents a starvation condition and/or a failure in at least one of the plurality of IO drivers. The computing system <NUM> is therefore considered performance-enhanced at least to the extent that it encounters fewer starvation conditions and/or failures in a converged IO architecture.

<FIG> shows a semiconductor package apparatus <NUM>. The illustrated apparatus <NUM> includes one or more substrates <NUM> (e.g., silicon, sapphire, gallium arsenide) and logic <NUM> (e.g., transistor array and other integrated circuit/IC components) coupled to the substrate(s) <NUM>. The logic <NUM> is implemented at least partly in configurable logic or fixed-functionality logic hardware. In one example, the logic <NUM> implements one or more aspects of the method <NUM> (<FIG>), already discussed. Thus, the logic <NUM> collects state data from a plurality of IO drivers, wherein each of the IO drivers is to tunnel traffic through a shared physical interface in accordance with a different protocol. For example, a first IO driver may tunnel traffic to a display in accordance with a display protocol, a second IO driver may tunnel traffic to a mass storage in accordance with a storage protocol, a third IO driver may tunnel traffic to a network controller in accordance with a network protocol, and so forth.

The logic <NUM> also determines based on the state data, a bandwidth allocation of the shared physical interface among the plurality of IO drivers. In an embodiment, the bandwidth allocation prioritizes the display protocol over the storage protocol. The bandwidth allocation may also prioritize the storage protocol over the network protocol. In one example, the logic <NUM> initiates a state change (e.g., clock frequency change, operating voltage change, power state change, performance state change, etc.) of a processor (e.g., host processor, graphics processor) based on the bandwidth allocation. The state change, which may be triggered via one or more instructions to a governor, prevents a starvation condition and/or a failure in at least one of the plurality of IO drivers. The apparatus <NUM> is therefore considered performance-enhanced at least to the extent that it encounters fewer starvation conditions and/or failures in a converged IO architecture.

In one example, the logic <NUM> includes transistor channel regions that are positioned (e.g., embedded) within the substrate(s) <NUM>. Thus, the interface between the logic <NUM> and the substrate(s) <NUM> may not be an abrupt junction. The logic <NUM> may also be considered to include an epitaxial layer that is grown on an initial wafer of the substrate(s) <NUM>.

<FIG> illustrates a processor core <NUM> according to one embodiment. The processor core <NUM> may be the core for any type of processor, such as a micro-processor, an embedded processor, a digital signal processor (DSP), a network processor, or other device to execute code. Although only one processor core <NUM> is illustrated in <FIG>, a processing element may alternatively include more than one of the processor core <NUM> illustrated in <FIG>. The processor core <NUM> may be a single-threaded core or, for at least one embodiment, the processor core <NUM> may be multithreaded in that it may include more than one hardware thread context (or "logical processor") per core.

<FIG> also illustrates a memory <NUM> coupled to the processor core <NUM>. The memory <NUM> may be any of a wide variety of memories (including various layers of memory hierarchy) as are known or otherwise available to those of skill in the art. The memory <NUM> may include one or more code <NUM> instruction(s) to be executed by the processor core <NUM>, wherein the code <NUM> implements the method <NUM> (<FIG>), already discussed. The processor core <NUM> follows a program sequence of instructions indicated by the code <NUM>. Each instruction may enter a front end portion <NUM> and be processed by one or more decoders <NUM>. The decoder <NUM> may generate as its output a micro operation such as a fixed width micro operation in a predefined format, or may generate other instructions, microinstructions, or control signals which reflect the original code instruction. The illustrated front end portion <NUM> also includes register renaming logic <NUM> and scheduling logic <NUM>, which generally allocate resources and queue the operation corresponding to the convert instruction for execution.

The processor core <NUM> is shown including execution logic <NUM> having a set of execution units <NUM>-<NUM> through <NUM>-N. Some embodiments may include a number of execution units dedicated to specific functions or sets of functions. Other embodiments may include only one execution unit or one execution unit that can perform a particular function. The illustrated execution logic <NUM> performs the operations specified by code instructions.

After completion of execution of the operations specified by the code instructions, back end logic <NUM> retires the instructions of the code <NUM>. In one embodiment, the processor core <NUM> allows out of order execution but requires in order retirement of instructions. Retirement logic <NUM> may take a variety of forms as known to those of skill in the art (e.g., re-order buffers or the like). In this manner, the processor core <NUM> is transformed during execution of the code <NUM>, at least in terms of the output generated by the decoder, the hardware registers and tables utilized by the register renaming logic <NUM>, and any registers (not shown) modified by the execution logic <NUM>.

Although not illustrated in <FIG>, a processing element may include other elements on chip with the processor core <NUM>. For example, a processing element may include memory control logic along with the processor core <NUM>. The processing element may include I/O control logic and/or may include I/O control logic integrated with memory control logic. The processing element may also include one or more caches.

Referring now to <FIG>, shown is a block diagram of a computing system <NUM> embodiment in accordance with an embodiment. Shown in <FIG> is a multiprocessor system <NUM> that includes a first processing element <NUM> and a second processing element <NUM>. While two processing elements <NUM> and <NUM> are shown, it is to be understood that an embodiment of the system <NUM> may also include only one such processing element.

The system <NUM> is illustrated as a point-to-point interconnect system, wherein the first processing element <NUM> and the second processing element <NUM> are coupled via a point-to-point interconnect <NUM>. It should be understood that any or all of the interconnects illustrated in <FIG> may be implemented as a multi-drop bus rather than point-to-point interconnect.

As shown in <FIG>, each of processing elements <NUM> and <NUM> may be multicore processors, including first and second processor cores (i.e., processor cores 1074a and 1074b and processor cores 1084a and 1084b). Such cores 1074a, 1074b, 1084a, 1084b may be configured to execute instruction code in a manner similar to that discussed above in connection with <FIG>.

Each processing element <NUM>, <NUM> may include at least one shared cache 1896a, 1896b. The shared cache 1896a, 1896b may store data (e.g., instructions) that are utilized by one or more components of the processor, such as the cores 1074a, 1074b and 1084a, 1084b, respectively. For example, the shared cache 1896a, 1896b may locally cache data stored in a memory <NUM>, <NUM> for faster access by components of the processor. In one or more embodiments, the shared cache 1896a, 1896b may include one or more mid-level caches, such as level <NUM> (L2), level <NUM> (L3), level <NUM> (L4), or other levels of cache, a last level cache (LLC), and/or combinations thereof.

While shown with only two processing elements <NUM>, <NUM>, it is to be understood that the scope of the embodiments are not so limited. In other embodiments, one or more additional processing elements may be present in a given processor. Alternatively, one or more of processing elements <NUM>, <NUM> may be an element other than a processor, such as an accelerator or a field programmable gate array. For example, additional processing element(s) may include additional processors(s) that are the same as a first processor <NUM>, additional processor(s) that are heterogeneous or asymmetric to processor a first processor <NUM>, accelerators (such as, e.g., graphics accelerators or digital signal processing (DSP) units), field programmable gate arrays, or any other processing element. There can be a variety of differences between the processing elements <NUM>, <NUM> in terms of a spectrum of metrics of merit including architectural, micro architectural, thermal, power consumption characteristics, and the like. These differences may effectively manifest themselves as asymmetry and heterogeneity amongst the processing elements <NUM>, <NUM>. For at least one embodiment, the various processing elements <NUM>, <NUM> may reside in the same die package.

The first processing element <NUM> may further include memory controller logic (MC) <NUM> and point-to-point (P-P) interfaces <NUM> and <NUM>. Similarly, the second processing element <NUM> may include a MC <NUM> and P-P interfaces <NUM> and <NUM>. As shown in <FIG>, MC's <NUM> and <NUM> couple the processors to respective memories, namely a memory <NUM> and a memory <NUM>, which may be portions of main memory locally attached to the respective processors. While the MC <NUM> and <NUM> is illustrated as integrated into the processing elements <NUM>, <NUM>, for alternative embodiments the MC logic may be discrete logic outside the processing elements <NUM>, <NUM> rather than integrated therein.

The first processing element <NUM> and the second processing element <NUM> may be coupled to an I/O subsystem <NUM> via P-P interconnects <NUM><NUM>, respectively. As shown in <FIG>, the I/O subsystem <NUM> includes P-P interfaces <NUM> and <NUM>. Furthermore, I/O subsystem <NUM> includes an interface <NUM> to couple I/O subsystem <NUM> with a high performance graphics engine <NUM>. In one embodiment, bus <NUM> may be used to couple the graphics engine <NUM> to the I/O subsystem <NUM>. Alternately, a point-to-point interconnect may couple these components.

In turn, I/O subsystem <NUM> may be coupled to a first bus <NUM> via an interface <NUM>. In one embodiment, the first bus <NUM> may be a Peripheral Component Interconnect (PCI) bus, or a bus such as a PCI Express bus or another third generation I/O interconnect bus, although the scope of the embodiments are not so limited.

As shown in <FIG>, various I/O devices <NUM> (e.g., biometric scanners, speakers, cameras, sensors) may be coupled to the first bus <NUM>, along with a bus bridge <NUM> which may couple the first bus <NUM> to a second bus <NUM>. In one embodiment, the second bus <NUM> may be a low pin count (LPC) bus. Various devices may be coupled to the second bus <NUM> including, for example, a keyboard/mouse <NUM>, communication device(s) <NUM>, and a data storage unit <NUM> such as a disk drive or other mass storage device which may include code <NUM>, in one embodiment. The illustrated code <NUM> implements the method <NUM> (<FIG>), already discussed. Further, an audio I/O <NUM> may be coupled to second bus <NUM> and a battery <NUM> may supply power to the computing system <NUM>.

Note that other embodiments are contemplated. For example, instead of the point-to-point architecture of <FIG>, a system may implement a multi-drop bus or another such communication topology. Also, the elements of <FIG> may alternatively be partitioned using more or fewer integrated chips than shown in <FIG>.

Thus, technology described herein may influence PCIe active-state power management (ASPM) for performance and power. The technology may also influence CPU governors for clock (e.g., performance) to improve USB class performance. As a result, the technology compensates the bandwidth needs of tunneled protocols to ensure seamless tunneling without starvation or failures. Thus, a better user experience is achieved with better performance.

Embodiments are applicable for use with all types of semiconductor integrated circuit ("IC") chips. Examples of these IC chips include but are not limited to processors, controllers, chipset components, programmable logic arrays (PLAs), memory chips, network chips, systems on chip (SoCs), SSD/NAND controller ASICs, and the like. In addition, in some of the drawings, signal conductor lines are represented with lines. Some may be different, to indicate more constituent signal paths, have a number label, to indicate a number of constituent signal paths, and/or have arrows at one or more ends, to indicate primary information flow direction. This, however, should not be construed in a limiting manner. Rather, such added detail may be used in connection with one or more exemplary embodiments to facilitate easier understanding of a circuit. Any represented signal lines, whether or not having additional information, may actually comprise one or more signals that may travel in multiple directions and may be implemented with any suitable type of signal scheme, e.g., digital or analog lines implemented with differential pairs, optical fiber lines, and/or single-ended lines.

Example sizes/models/values/ranges may have been given, although embodiments are not limited to the same. As manufacturing techniques (e.g., photolithography) mature over time, it is expected that devices of smaller size could be manufactured. In addition, well known power/ground connections to IC chips and other components may or may not be shown within the figures, for simplicity of illustration and discussion, and so as not to obscure certain aspects of the embodiments. Further, arrangements may be shown in block diagram form in order to avoid obscuring embodiments, and also in view of the fact that specifics with respect to implementation of such block diagram arrangements are highly dependent upon the computing system within which the embodiment is to be implemented, i.e., such specifics should be well within purview of one skilled in the art.

The term "coupled" may be used herein to refer to any type of relationship, direct or indirect, between the components in question, and may apply to electrical, mechanical, fluid, optical, electromagnetic, electromechanical or other connections. In addition, the terms "first", "second", etc. may be used herein only to facilitate discussion, and carry no particular temporal or chronological significance unless otherwise indicated.

Claim 1:
A computing system comprising:
a shared physical interface (<NUM>);
a processor coupled to the shared physical interface (<NUM>);
a plurality of input/output, IO, drivers, each of the plurality of IO drivers configured to tunnel traffic through the shared physical interface (<NUM>) in accordance with a corresponding protocol, wherein the corresponding protocol differs from protocols corresponding to other IO drivers of the plurality of IO drivers;
a semiconductor apparatus comprising:
one or more substrates (<NUM>); and
logic (<NUM>) coupled to the one or more substrates (<NUM>), wherein the logic (<NUM>) is implemented at least partly in one or more of configurable logic or fixed-functionality hardware logic, the logic (<NUM>) configured to:
collect state data from the plurality of IO drivers, wherein the state data indicates, for each of the plurality of IO drivers, a level of activity and/or a bandwidth demand of the respective IO driver;
determine, based on the state data, a bandwidth allocation of the shared physical interface (<NUM>) among the plurality of IO drivers; and
initiate, based on the bandwidth allocation, a state change of the processor coupled to the shared physical interface (<NUM>), wherein the state change comprises one or more of a clock frequency change, an operating voltage change, a power state change or a performance state change.