feat(dra): separate scheduling for USB 2.0 (High-Speed) and USB 3.0 (SuperSpeed) over USBIP

[yaroslavborbat]

Description

USB devices (including flash drives) can be passed into workloads via USBIP: a device is physically attached to one node while being used in a pod on another. The Linux USBIP vhci driver exposes two hub types: High-Speed (HS) for USB 2.0 and SuperSpeed (SS) for USB 3.0, with ports split evenly between them. Previously, scheduling required free ports on both hubs for a node to be considered available, so a node was only suitable when it had capacity on HS and SS at the same time.

This change separates scheduling by speed: some devices need only USB 2.0 (HS), others only USB 3.0 (SS). Nodes are now labeled and selected per hub type, so workloads can be scheduled based on the actual speed requirement of the device.

• Node labels

  • virtualization.deckhouse.io/usb-gateway-high-speed — node has free ports on the HS (USB 2.0) hub.
  • virtualization.deckhouse.io/usb-gateway-super-speed — node has free ports on the SS (USB 3.0) hub.

• Node annotations

  • usb.virtualization.deckhouse.io/usbip-high-speed-hub-used-ports — number of used HS hub ports.
  • usb.virtualization.deckhouse.io/usbip-super-speed-hub-used-ports — number of used SS hub ports.

• Scheduling

  • With DRAPartitionableDevices feature gate: device NodeSelector is built from device speed — SuperSpeed (and above) devices target nodes with usb-gateway-super-speed, High-Speed and below target nodes with usb-gateway-high-speed.
  • Node is considered available for USBIP if it has free ports on either hub (anyNode = hsAvailable || ssAvailable), and the appropriate HS/SS label is set.

• USBIP

  • VHCI status parsing and attach info now carry hub type (hs/ss) per port so the controller can count and expose HS vs SS usage correctly.

Why do we need it, and what problem does it solve?

• Some USB devices or use cases need USB 2.0 (HS) only, others USB 3.0 (SS) only. Forcing both hub types to have free ports limited placement and prevented scheduling when only one hub had capacity.
• Splitting by speed allows better utilization and correct placement: USB 2.0 devices go to nodes with free HS ports, USB 3.0 devices to nodes with free SS ports.

Checklist

• The code is covered by unit tests.
• e2e tests passed.
• Documentation updated according to the changes.
• Changes were tested in the Kubernetes cluster manually.

Changelog entries

section: vm
type: feature
summary: separate scheduling for USB 2.0 (High-Speed) and USB 3.0 (SuperSpeed) over USBIP

[yaroslavborbat]

deckhouse/deckhouse#18362