Adaptive prioritization of USB traffic

Traffic for USB devices that are connected to a USB-C dock can be adaptively prioritized. When the consumption of the bandwidth of a connection between a computing device and a USB-C dock exceeds a threshold, a filter driver can notify a service. The service can update device priority values for the devices that are connected to the USB-C dock based on applications that are accessing the devices. The service can relay the updated device priority values to the filter driver. The filter driver can then attempt to reduce bandwidth consumption by changing device settings of any device with a lower priority value, and then, if changing device settings is insufficient, may attempt to reduce bandwidth consumption by lowering the priority of the device's traffic.

CROSS-REFERENCE TO RELATED APPLICATIONS

BACKGROUND

The USB-C connector includes additional lanes for supporting alternate modes (or “Alt modes”) to thereby allow non-USB traffic to be transferred over a USB connection. Alt modes have commonly been used to transfer video traffic over a USB-C cable (e.g., DisplayPort Alt mode or HDMI Alt mode). With these earlier Alt modes, the extensible host controller interface (XHCI) controller did not manage the non-USB traffic. In contrast, with the introduction of Thunderbolt 3 Alt mode, any non-USB traffic supported by the Thunderbolt 3 interface is managed by the XHCI controller. The current USB4 standard also adopts this approach.

Both USB-C Thunderbolt 3 Alt mode and USB4 support two types of traffic: (1) isochronous traffic (e.g., DisplayPort, HDMI and DisplayLink video and HD audio); and (2) non-isochronous traffic (e.g., 10/40G NIC, SSD, PCIe and classic USB traffic). Typically, the isochronous traffic has a reserved bandwidth (e.g., 40%) and all other non-isochronous traffic shares the unreserved bandwidth. As an example, if a 4K monitor, Thunderbolt SSD storage and an eGPU are all connected to a single 10 Gbps USB-C hub, the 4K monitor will reserve 4 Gbps and the storage and eGPU will share the remaining 6 Gbps.

In many use cases, this sharing of bandwidth can lead to a poor user experience. For example,FIG. 1represents a scenario where a computing device200is connected to a USB-C dock100to which multiple other USB devices are also connected. These other devices include a USB keyboard110, a USB mouse120, a USB or USB-C external network adapter130, a USB or USB-C external storage drive140, a DisplayPort (USB-C) monitor150, a DisplayPort (USB-C) monitor160and a USB-C webcam170.

If USB-C dock100complies with the USB 3.2 standard, the USB-C connection101between computing device200and USB-C dock100will have a maximum bandwidth of 20 Gbps. In such cases, if monitors150and160are 4K 30 Hz 24-bit monitors, their combined bandwidth could be up to 13 Gbps, leaving only 7 Gbps for the remaining devices. With this setup, there may be many scenarios where the bandwidth available over connection101will be insufficient. For example, during a video conference, webcam170would likely consume significant bandwidth as it sends captured video data to computing device200over connection101. Computing device200may in turn consume additional bandwidth as it sends the video data to and receives other video data from external network adapter130. A data backup to external storage drive140would also consume the bandwidth of connection101. Accordingly, if a backup were performed during a video conference, the 20 Gbps bandwidth of connection101(or more specifically, whatever bandwidth is not consumed by or reserved for monitors150and160) will likely be insufficient and lead to degradation of the video conference.

A similar degradation in performance could also occur in a creativity/engineering setup. For example, if webcam170inFIG. 1were replaced with an eGPU that is used to render complex designs, the amount of bandwidth that monitors150and160do not consume may be insufficient for the eGPU and the other peripherals. A gaming setup may suffer from the same limitations. These are just examples of the many scenarios where the available bandwidth of a USB-C connection may be insufficient. Generally speaking, due to the consistently increasing resolution of the latest monitors, the USB-C connection between a computing device and its peripherals will oftentimes form a bottleneck for any non-isochronous traffic.

The USB4 standard provides techniques for prioritizing some traffic. In particular, USB4 allows priority queues to be implemented to prioritize traffic according to its “priority group.” However, even with the use of priority queues, there is still no way to differentiate between the various types of non-isochronous traffic. More particularly, the USB4 standard does not provide a way to prioritize a particular type of non-isochronous traffic to enhance the user experience for a particular workload.

BRIEF SUMMARY

The present invention extends to methods, systems, and computer program products for adaptively prioritizing traffic for USB devices that are connected to a USB-C dock. When the consumption of the bandwidth of a connection between a computing device and a USB-C dock exceeds a threshold, a filter driver can notify a service. The service can update device priority values for the devices that are connected to the USB-C dock based on applications that are accessing the devices. The service can relay the updated device priority values to the filter driver. The filter driver can then attempt to reduce bandwidth consumption by changing device settings of any device with a lower priority value, and then, if changing device settings is insufficient, may attempt to reduce bandwidth consumption by lowering the priority of the device's traffic.

In some embodiments, the present invention may be implemented as a method for adaptively prioritizing traffic of USB devices that are connected to a USB dock. It can be detected that bandwidth consumption of a connection between a computing device and a USB dock has exceeded a threshold. In response to the detection, a different alternate mode can be selected for at least one USB device of a plurality of USB devices that are connected to the USB dock.

In some embodiments, the present invention may be implemented as computer storage media storing computer executable instructions which when executed on a computing device implement a filter driver and a service. The filter driver may be configured to register with a USB controller driver to be notified when bandwidth consumption of a connection between the computing device and the USB dock has reached one or more thresholds. The filter driver may also be configured to notify the service upon receiving a notification that the bandwidth consumption of the connection between the computing device and the USB dock has reached the one or more thresholds. The service may be configured to monitor applications that are accessing USB devices that are connected to the USB dock, set a device priority for each of the USB devices based on the applications and provide the device priority for each of the USB devices to the filter driver. The filter driver may be further configured to adaptively prioritize traffic of at least one of the USB devices based on the device priority for each of the USB devices.

In some embodiments, the present invention may be implemented as a computing device that includes one or more processors and computer storage media storing computer executable instructions which when executed implement a method for adaptively prioritizing traffic of USB devices that are connected to a USB-C dock. A filter driver may detect that bandwidth consumption of a connection between the computing device and the USB-C dock has exceeded a threshold. The filter driver may then send a notification to a service that the bandwidth consumption of the connection between the computing device and the USB-C dock has exceeded the threshold. In response to the notification and in conjunction with monitoring applications that are accessing USB devices that are connected to the USB-C dock, the service may identify a device priority for each of the USB devices. In response to receiving the device priority for each of the USB devices from the service the filter driver may change an alternate mode of at least one of the USB devices.

DETAILED DESCRIPTION

FIG. 2provides a block diagram of various components that may exist on computing device200when it is configured to implement embodiments of the present invention to adaptively prioritize traffic of USB devices that are connected to USB-C dock100. As shown, computing device200can include a USB controller driver210which is the software counterpart to the physical USB extensible host controller (not shown). USB controller driver210may typically represent any driver that is configured to implement the extensible host controller interface and is commonly provided by Intel. Of primary relevance to embodiments of the present invention, USB controller driver210manages connection101between computing device200and USB-C dock100. Although not shown, it can be assumed that multiple devices are connected to USB-C dock100including, for example, the setup shown inFIG. 1.

Computing device200is also shown as including USB device stack(s)230aand Alt mode stack(s)230bthat sit above USB controller driver210. Of relevance to embodiments of the present invention, applications240employ USB device stack(s)230aand/or Alt mode stack(s)230bto communicate with USB devices connected to USB-C dock100(and possibly with USB devices connected directly to computing device200) via USB controller driver210.

In accordance with embodiments of the present invention, computing device200may also include a filter driver220that sits above USB controller driver210(e.g., a USB controller device upper filter driver) and a service250(e.g., a user-mode service that runs in the background). In some embodiments, computing device200may also include an agent260that is configured to interface with a machine learning backend300(e.g., a server). As an overview, filter driver220and service250can intercommunicate as part of an adaptive process to prioritize the traffic to and from USB devices connected to USB-C dock100. As described below, this process can be performed whether or not USB controller driver210implements prioritization techniques.

FIGS. 3A-3Frepresent how filter driver220and service250may adaptively prioritize USB traffic in some embodiments of the present invention. In step1shown inFIG. 3A, filter driver220may identify the USB controller to determine whether it supports traffic prioritization. For example, during its initialization, filter driver220could send a request to USB controller driver210for the device identifiers of the USB controller and could use the device identifiers to determine whether the USB controller complies with the USB4 standard. If filter driver220determines that the USB controller supports traffic prioritization (e.g., that USB controller driver210implements priority queues in accordance with the USB4 standard), filter driver220may leverage this traffic prioritization. In contrast, if the USB controller does not support traffic prioritization (e.g., if USB controller driver210complies with an earlier version of the USB standard), filter driver220may implement traffic prioritization techniques (e.g., by implementing priority queues).

Turning toFIG. 3B, in step2, filter driver220can register with USB controller driver210to receive notifications when the consumption of connection101's bandwidth reaches an upper threshold or a lower threshold. As one example only, as part of its initialization, filter driver200could register to be notified when the bandwidth consumption increases beyond 90% or drops below 60% of the total available bandwidth. Notably, filter driver220can register for such notifications when it leverages USB controller driver210's traffic prioritization techniques and when it provides traffic prioritization techniques itself.

Turning toFIG. 3C, in step3, which may also be performed as part of its initialization, filter driver220can retrieve a list of devices that are connected to USB-C dock100. For purposes of this example, it will be assumed that the connected devices are the same as shown inFIG. 1. Then, in step4shown inFIG. 3D, filter driver220can send the list of connected devices to service250. Filter driver220could perform steps3and4at any time to inform service250of which USB devices are currently connected to USB-C dock100.

Turning toFIG. 3E, in step5, it is assumed that filter driver220is notified that the current consumption of connection101's bandwidth has crossed the upper or lower threshold. For example, an upper threshold event may be triggered when the user of computing device200is using applications240to host a video conference while performing a backup to external storage drive140. As represented in step6inFIG. 3F, in response to either an upper threshold event or lower threshold event, filter driver220can query USB controller driver210for the current bandwidth consumption. In this example, it is assumed that 95% of connection101's bandwidth is currently being consumed. Filter driver220can then send a bandwidth event notification300to service250which specifies the current bandwidth consumption. Accordingly, filter driver220can be configured to notify service250of the current consumption of connection101's bandwidth whenever the consumption reaches an upper or lower threshold.

FIGS. 4A-4Crepresent how service250may respond to bandwidth event report300. As shown as step1inFIG. 4A, service250can maintain an application and device priority table400(hereinafter table400) that identifies applications on computing device200, the devices that each application is using, a priority for each device, a state of the application and a priority of the application. Service250can be configured to monitor applications240to populate the applications, devices used (e.g., using the list of connected devices that filter driver220provided) and application state columns of table400. Service250may do so periodically, in response to bandwidth event reports300or at any other suitable time. In some embodiments, service250may monitor all running applications on computing device200, while in other embodiments, service250may monitor only specified applications.

In some embodiments, service250may initially employ default values for the device priority and the application priority in table400. In some embodiments, service250may use a policy to set the initial or default values for the device priority and the application priority. In some embodiments, service250may set the initial values for the device priority and the application priority based on a detected workload or use case on computing device200(e.g., whether computing device200is being used for a video conference, for engineering, for gaming, etc.). In some embodiments, service250may interface with agent260to leverage machine learning backend300to determine the workload or use case. For purposes of the depicted example, the values shown inFIG. 4Acan be viewed as initial or default values.

Turning toFIG. 4B, in response to receiving bandwidth event report300, in step3a, service250may interface with/monitor applications240to determine which applications are currently using the devices that are connected to USB-C dock100and can populate/update table400accordingly. In this example, it is assumed that the user is running Skype in the foreground on monitor150to host a video conference and is running Windows Backup minimized while it performs a backup to drive140.

In addition to determining this information about the applications that are accessing the devices connected to USB-C dock100, in step3b, service250can also populate table400with priority values that will attempt to address the bandwidth event defined in bandwidth event report300. For example, service250could employ internal logic to calculate priority values, set the priority values based on policy, access agent260to leverage machine learning backend300to predict appropriate priority values, etc.

In the depicted example, it is assumed that service250had previously determined that the application priority for Skype is high and that the device priority for monitor150is real time, while the device priority for webcam160and external network adapter130is high. On the other hand, it is assumed that service250had previously determined that the application priority for Windows Backup is normal and the device priority for external storage drive140is normal. It is further assumed that service250has determined in step3bthat the device priority of external storage drive140and the application priority of Windows backup should be set to low to attempt to reduce bandwidth consumption. It is noted that these values for the device priority and application priority are examples only and any classification of values could be used (e.g., a binary value, a range of values, etc.).

Turning toFIG. 4C, in step4and after adjusting the priority values in table400to attempt to address the bandwidth event, service250can send table400to filter driver220. For example, service250could send an IOCTL or make a remote procedure call to pass the content of table400to filter driver220.

FIGS. 5A-5Brepresent how filter driver220can adaptively prioritize USB traffic using table400. As an overview, filter driver220can perform multiple techniques based on the device priority and application priority values defined in table400, which in conjunction with service250's updating of table400in response to bandwidth events, can reduce bandwidth consumption when the current bandwidth consumption exceeds the upper threshold and can enable increased bandwidth consumption when the current bandwidth consumption falls below the lower threshold.

Turning toFIG. 5A, in step1, filter driver220can attempt to lower the bandwidth consumption by selecting an alternate setting for an interface of any device that has a device priority of low in table400. For example, external storage drive140may have an interface with an alternate setting that defines one type of endpoint that requires more bandwidth and an alternate setting that defines a second type of endpoint that requires less bandwidth. As another example, webcam170may have an interface with a first alternate setting in which only the camera is enabled, a second alternate setting in which only the microphone is enabled and a third alternate setting in which both the camera and the microphone are enabled. Accordingly, step1may entail identifying which alternate settings are available for the device, determining whether an unselected alternate setting would likely result in lowered bandwidth consumption and, if so, selecting the alternate setting.

The example shows only one device that has a device priority of low. However, there may be multiple devices with a device priority of low. In such cases, the order in which filter driver220performs step1on such devices may be based on the application priority. For example, if table400identified a third application as having a normal application priority but was using a device with a low device priority, filter driver400may select an alternate setting for external storage drive140before selecting an alternate setting for the device that the third application is accessing.

In conjunction with performing step1, including while performing step1, in step2which is shown in bothFIGS. 5A and 5B, filter driver220can monitor for a reduction in bandwidth consumption. Stated another way, as filter driver220makes adjustments based on table400, it can monitor the bandwidth consumption to determine if the adjustments have been effective. For example, filter driver220can employ appropriate APIs to periodically query USB controller driver210for the current bandwidth consumption (e.g., in a similar manner as in step6ofFIG. 3F). Accordingly, filter driver220may stop performing step1once it determines that bandwidth consumption has been sufficiently reduced even if it has not yet selected an alternate setting for all devices with a low device priority.

If the selection of different alternate settings for devices with a low device priority has not sufficiently lowered bandwidth consumption (e.g., below the upper threshold), in step3shown inFIG. 5B, filter driver220can reduce the priority of such devices' traffic. The manner in which filter driver220reduces the priority of a device's traffic will depend on whether filter driver220is implementing traffic prioritization techniques or is leveraging traffic prioritization techniques that USB controller driver210provides (e.g., whether USB controller driver210complies with the USB4 standard). For example, if filter driver220implements traffic prioritization techniques, it may reduce the priority of a device's traffic by routing the device's traffic through a lower priority queue. In contrast, if filter driver220leverages USB controller driver210's traffic prioritization techniques, filter driver220may reduce the priority of a device's traffic by adjusting a scheduling priority value associated with the device's traffic which in turn may cause USB controller driver210to route the device's traffic through a lower priority queue.

In some embodiments, filter driver220can ensure that changes in the priority of a device's traffic are atomic across a transaction. For example, if filter driver220determines that the priority of external storage drive140's traffic should be reduced, it can ensure that any pending read or write to external storage driver140is completed before the change is made. This can ensure that transactions will not fail in spite of the dynamic adjustments to traffic priority.

As described above, filter driver220can continue to perform step2while performing step3. Accordingly, if filter driver220determines that the bandwidth consumption has been sufficiently reduced, it can forego reducing the priority of a device's traffic that has not yet been adjusted. In some embodiments, filter driver220may perform step3in an iterative fashion. For example, there may be range of possible priority values for a device's traffic. In such cases, filter driver220may initially reduce the priority of a device's traffic by one level. If bandwidth consumption remains too high after reducing the priority of the traffic of all devices having a low device priority in table400, filter driver220could proceed to reduce the priority of each device's traffic by another level. Filter driver220could continue this iterative reduction in priority until bandwidth consumption has been sufficiently reduced.

Although not depicted in the figures, a similar process can be followed when the bandwidth consumption reaches the lower threshold. For example, if another bandwidth event notification300indicates that the bandwidth is below the lower threshold, service250may update/recreate table400to increase a device priority and/or an application priority that it had previously reduced and/or to otherwise set a device priority or application priority to a higher value (e.g., higher than a default value). Using the same example, if Skype is closed when the video conference ends, filter driver220may send an appropriate bandwidth event notification300. Service250may then respond by removing Skype from table400and setting Windows Backup's application priority back to normal and external storage drive140's device priority back to normal. When filter driver220receives the updated table400, it can in turn select an alternate setting of external storage drive140's interface that provides higher bandwidth and increase the priority of external storage drive140's traffic.

In addition to updating table400in response to bandwidth consumption notifications300(e.g., in response to the bandwidth consumption reaching the upper or lower threshold), service250may also be configured to update table400when a device is connected to or disconnected from USB-C dock100(e.g., in response to a corresponding notification from filter driver220), in response to an application being launched or closed, in response to a change in policy, in response to input from agent260, etc.

To summarize, the adaptive prioritization process that filter driver220performs can first attempt to reduce bandwidth consumption by changing device settings, and then, if changing device settings is insufficient, may then attempt to reduce bandwidth consumption by lowering the priority of a device's traffic. This adaptive prioritization process can account for the state of the applications that are using the devices and can account for a particular workload or use case.

FIG. 6provides a flow diagram that summarizes how filter driver220and service250may adaptively prioritize USB traffic of devices that are connected to a USB-C dock. As shown, filter driver220can obtain the controller's capabilities and register for events. Filter driver220can also obtain information about the devices connected to the USB-C dock and relay the information to service250. At this stage, applications240may send and receive USB traffic that will be handled in accordance with default alternate settings and priority.

Whenever a bandwidth event occurs, filter driver220can notify service250. Service250can then update the application and device priority table and send the updated table to filter driver220. When the bandwidth event represents excessive bandwidth consumption, filter driver220can employ the updated table to select the lowest bandwidth alternate settings for any device identified as having a low device priority. If selecting the lowest bandwidth alternate setting does not reduce the bandwidth consumption, filter driver220can reduce the device's traffic priority. At this stage, applications240may send and receive USB traffic that will be handled in accordance with the modified alternate settings and priority.