usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
/*
|
2021-02-23 08:05:13 +00:00
|
|
|
Copyright 2020-2021 The Kubernetes Authors.
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
|
|
|
|
Licensed under the Apache License, Version 2.0 (the "License");
|
|
|
|
you may not use this file except in compliance with the License.
|
|
|
|
You may obtain a copy of the License at
|
|
|
|
|
|
|
|
http://www.apache.org/licenses/LICENSE-2.0
|
|
|
|
|
|
|
|
Unless required by applicable law or agreed to in writing, software
|
|
|
|
distributed under the License is distributed on an "AS IS" BASIS,
|
|
|
|
WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied.
|
|
|
|
See the License for the specific language governing permissions and
|
|
|
|
limitations under the License.
|
|
|
|
*/
|
|
|
|
|
|
|
|
package usb
|
|
|
|
|
|
|
|
import (
|
|
|
|
"fmt"
|
|
|
|
"strings"
|
|
|
|
|
2023-12-13 09:38:06 +00:00
|
|
|
"golang.org/x/exp/maps"
|
2021-02-23 08:05:13 +00:00
|
|
|
"k8s.io/klog/v2"
|
|
|
|
|
2024-02-27 13:42:23 +00:00
|
|
|
nfdv1alpha1 "sigs.k8s.io/node-feature-discovery/api/nfd/v1alpha1"
|
2021-03-03 15:36:43 +00:00
|
|
|
"sigs.k8s.io/node-feature-discovery/pkg/utils"
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
"sigs.k8s.io/node-feature-discovery/source"
|
|
|
|
)
|
|
|
|
|
2022-01-19 07:12:06 +00:00
|
|
|
// Name of this feature source
|
2021-05-12 13:27:29 +00:00
|
|
|
const Name = "usb"
|
|
|
|
|
2021-03-03 15:36:43 +00:00
|
|
|
const DeviceFeature = "device"
|
|
|
|
|
2020-04-21 19:03:37 +00:00
|
|
|
type Config struct {
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
DeviceClassWhitelist []string `json:"deviceClassWhitelist,omitempty"`
|
|
|
|
DeviceLabelFields []string `json:"deviceLabelFields,omitempty"`
|
|
|
|
}
|
|
|
|
|
2020-04-21 19:03:37 +00:00
|
|
|
// newDefaultConfig returns a new config with pre-populated defaults
|
|
|
|
func newDefaultConfig() *Config {
|
|
|
|
return &Config{
|
|
|
|
// Whitelist specific USB classes: https://www.usb.org/defined-class-codes
|
|
|
|
// By default these include classes where different accelerators are typically mapped:
|
|
|
|
// Video (0e), Miscellaneous (ef), Application Specific (fe), and Vendor Specific (ff).
|
|
|
|
DeviceClassWhitelist: []string{"0e", "ef", "fe", "ff"},
|
2021-12-09 16:26:08 +00:00
|
|
|
DeviceLabelFields: defaultDeviceLabelFields(),
|
2020-04-21 19:03:37 +00:00
|
|
|
}
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
|
|
|
|
2021-12-09 16:26:08 +00:00
|
|
|
func defaultDeviceLabelFields() []string { return []string{"class", "vendor", "device"} }
|
|
|
|
|
2021-03-01 07:02:22 +00:00
|
|
|
// usbSource implements the LabelSource and ConfigurableSource interfaces.
|
|
|
|
type usbSource struct {
|
2021-03-03 15:36:43 +00:00
|
|
|
config *Config
|
2022-07-04 11:05:58 +00:00
|
|
|
features *nfdv1alpha1.Features
|
2020-04-21 19:03:37 +00:00
|
|
|
}
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
|
2021-03-01 07:02:22 +00:00
|
|
|
// Singleton source instance
|
|
|
|
var (
|
2021-03-03 15:36:43 +00:00
|
|
|
src = usbSource{config: newDefaultConfig()}
|
|
|
|
_ source.FeatureSource = &src
|
2021-03-01 07:02:22 +00:00
|
|
|
_ source.LabelSource = &src
|
|
|
|
_ source.ConfigurableSource = &src
|
|
|
|
)
|
|
|
|
|
2021-06-06 21:25:08 +00:00
|
|
|
// Name returns the name of the feature source
|
2021-03-01 07:02:22 +00:00
|
|
|
func (s *usbSource) Name() string { return Name }
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
|
2021-03-01 05:45:32 +00:00
|
|
|
// NewConfig method of the LabelSource interface
|
2021-03-01 07:02:22 +00:00
|
|
|
func (s *usbSource) NewConfig() source.Config { return newDefaultConfig() }
|
2020-04-21 19:03:37 +00:00
|
|
|
|
2021-03-01 05:45:32 +00:00
|
|
|
// GetConfig method of the LabelSource interface
|
2021-03-01 07:02:22 +00:00
|
|
|
func (s *usbSource) GetConfig() source.Config { return s.config }
|
2020-04-21 19:03:37 +00:00
|
|
|
|
2021-03-01 05:45:32 +00:00
|
|
|
// SetConfig method of the LabelSource interface
|
2021-03-01 07:02:22 +00:00
|
|
|
func (s *usbSource) SetConfig(conf source.Config) {
|
2020-04-21 19:03:37 +00:00
|
|
|
switch v := conf.(type) {
|
|
|
|
case *Config:
|
|
|
|
s.config = v
|
|
|
|
default:
|
2023-05-16 17:26:18 +00:00
|
|
|
panic(fmt.Sprintf("invalid config type: %T", conf))
|
2020-04-21 19:03:37 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
|
2021-03-01 07:02:22 +00:00
|
|
|
// Priority method of the LabelSource interface
|
|
|
|
func (s *usbSource) Priority() int { return 0 }
|
|
|
|
|
2021-03-01 16:39:49 +00:00
|
|
|
// GetLabels method of the LabelSource interface
|
|
|
|
func (s *usbSource) GetLabels() (source.FeatureLabels, error) {
|
2021-03-03 15:36:43 +00:00
|
|
|
labels := source.FeatureLabels{}
|
|
|
|
features := s.GetFeatures()
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
|
|
|
|
// Construct a device label format, a sorted list of valid attributes
|
|
|
|
deviceLabelFields := []string{}
|
|
|
|
configLabelFields := map[string]bool{}
|
2020-04-21 19:03:37 +00:00
|
|
|
for _, field := range s.config.DeviceLabelFields {
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
configLabelFields[field] = true
|
|
|
|
}
|
|
|
|
|
2021-03-03 15:36:43 +00:00
|
|
|
for _, attr := range devAttrs {
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
if _, ok := configLabelFields[attr]; ok {
|
|
|
|
deviceLabelFields = append(deviceLabelFields, attr)
|
|
|
|
delete(configLabelFields, attr)
|
|
|
|
}
|
|
|
|
}
|
|
|
|
if len(configLabelFields) > 0 {
|
2023-12-13 09:38:06 +00:00
|
|
|
klog.InfoS("ignoring invalid fields in deviceLabelFields", "invalidFieldNames", maps.Keys(configLabelFields))
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
|
|
|
if len(deviceLabelFields) == 0 {
|
2021-12-09 16:26:08 +00:00
|
|
|
deviceLabelFields = defaultDeviceLabelFields()
|
2023-05-16 17:26:18 +00:00
|
|
|
klog.InfoS("no valid fields in deviceLabelFields defined, using the defaults", "defaultFieldNames", deviceLabelFields)
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
|
|
|
|
|
|
|
// Iterate over all device classes
|
2021-03-03 15:36:43 +00:00
|
|
|
for _, dev := range features.Instances[DeviceFeature].Elements {
|
|
|
|
attrs := dev.Attributes
|
|
|
|
class := attrs["class"]
|
2020-04-21 19:03:37 +00:00
|
|
|
for _, white := range s.config.DeviceClassWhitelist {
|
2021-03-03 15:36:43 +00:00
|
|
|
if strings.HasPrefix(string(class), strings.ToLower(white)) {
|
|
|
|
devLabel := ""
|
|
|
|
for i, attr := range deviceLabelFields {
|
|
|
|
devLabel += attrs[attr]
|
|
|
|
if i < len(deviceLabelFields)-1 {
|
|
|
|
devLabel += "_"
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
|
|
|
}
|
2021-03-03 15:36:43 +00:00
|
|
|
labels[devLabel+".present"] = true
|
|
|
|
break
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
|
|
|
}
|
|
|
|
}
|
2021-03-03 15:36:43 +00:00
|
|
|
return labels, nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// Discover method of the FeatureSource interface
|
|
|
|
func (s *usbSource) Discover() error {
|
2022-07-04 11:05:58 +00:00
|
|
|
s.features = nfdv1alpha1.NewFeatures()
|
2021-03-03 15:36:43 +00:00
|
|
|
|
|
|
|
devs, err := detectUsb()
|
|
|
|
if err != nil {
|
|
|
|
return fmt.Errorf("failed to detect USB devices: %s", err.Error())
|
|
|
|
}
|
2024-04-17 13:41:12 +00:00
|
|
|
s.features.Instances[DeviceFeature] = nfdv1alpha1.NewInstanceFeatures(devs...)
|
2021-03-03 15:36:43 +00:00
|
|
|
|
2023-05-17 13:42:32 +00:00
|
|
|
klog.V(3).InfoS("discovered features", "featureSource", s.Name(), "features", utils.DelayedDumper(s.features))
|
2021-03-03 15:36:43 +00:00
|
|
|
|
|
|
|
return nil
|
|
|
|
}
|
|
|
|
|
|
|
|
// GetFeatures method of the FeatureSource Interface
|
2022-07-04 11:05:58 +00:00
|
|
|
func (s *usbSource) GetFeatures() *nfdv1alpha1.Features {
|
2021-03-03 15:36:43 +00:00
|
|
|
if s.features == nil {
|
2022-07-04 11:05:58 +00:00
|
|
|
s.features = nfdv1alpha1.NewFeatures()
|
2021-03-03 15:36:43 +00:00
|
|
|
}
|
|
|
|
return s.features
|
usb: Add support for USB device discovery
This builds on the PCI support to enable the discovery of USB devices.
This is primarily intended to be used for the discovery of Edge-based
heterogeneous accelerators that are connected via USB, such as the Coral
USB Accelerator and the Intel NCS2 - our main motivation for adding this
capability to NFD, and as part of our work in the SODALITE H2020
project.
USB devices may define their base class at either the device or
interface levels. In the case where no device class is set, the
per-device interfaces are enumerated instead. USB devices may
furthermore have multiple interfaces, which may or may not use the
identical class across each interface. We therefore report device
existence for each unique class definition to enable more fine-grained
labelling and node selection.
The default labelling format includes the class, vendor and device
(product) IDs, as follows:
feature.node.kubernetes.io/usb-fe_1a6e_089a.present=true
As with PCI, a subset of device classes are whitelisted for matching.
By default, there are only a subset of device classes under which
accelerators tend to be mapped, which is used as the basis for
the whitelist. These are:
- Video
- Miscellaneous
- Application Specific
- Vendor Specific
For those interested in matching other classes, this may be extended
by using the UsbId rule provided through the custom source. A full
list of class codes is provided by the USB-IF at:
https://www.usb.org/defined-class-codes
For the moment, owing to a lack of a demonstrable use case, neither
the subclass nor the protocol information are exposed. If this
becomes necessary, support for these attributes can be trivially
added.
Signed-off-by: Paul Mundt <paul.mundt@adaptant.io>
2020-05-14 20:32:55 +00:00
|
|
|
}
|
2021-03-01 07:02:22 +00:00
|
|
|
|
|
|
|
func init() {
|
|
|
|
source.Register(&src)
|
|
|
|
}
|