Please note that detd will still default to the most sensible (e.g. hardware accelerated) setup by default. This class is intended to allow to override that configuration.
This class allows the customization of the specific implementation of the traffic specification and qos provided in the configuration. Based on the hint and the device capabilities, the initialization sequence will instantiate the specific classes to implement it. E.g. it may decide to use specific mappings, taprio modes, etc.
This ticket only contains the changes to provide the info an get that to the InterfaceManager for usage.
The processing of the hint to implement the specific spec/QoS will be described in a separated ticket.
Task 1: add new class Hints
We introduce a new class Hints. This class allows to select how the traffic specifications have to be implemented. It just holds the following attributes, with the described possible values:
tx_selection: ENHANCEMENTS_FOR_SCHEDULED_TRAFFIC, STRICT_PRIORITY (mention in the docstring that EST is 802.1Qbv)
tx_selection_offload: true, false (mention in docstring that true means that a Hardware offload for the tx_selection mechanism must be used, as opposed to a software based one)
data_path: AF_PACKET, AF_XDP_ZC (mention in docstring that other options can be added for the data path, e.g. DPDK)
preemption: true, false
launch_time_control: true, false
We may add a class Hints in the scheduler module. This is a temporary location to enable the merge of the PR:
https://github.com/Avnu/detd/pull/20
Task 2: provide a default Hints class per device plugin
Each device plugin will provide a default Hints instantiation that will define how the traffic spec / QoS will be implemented if no other Hints are provided by the caller.
It should be possible to calculate the default hints based on the device capabilities, so a method could be added to device fr that. But it should also be possible to override it. Other parameters would depend on the framework as well, like the AF_XDP_ZC or other data path implementations.
Plugin
TxSelection
TxSelectionOffload
DataPath
LaunchTimeControl
Preemption
I210
Qbv
false
AF_PACKET
false
false
I225
Qbv
true
AF_PACKET
false
false
EHL
Qbv
true
AF_PACKET
false
false
Task 3: provide a default parameter flow until InterfaceManager
If the Configuration constructor contains a hint, it will be assigned to Configuration.hints
Otherwise, the default value will be None
This hints value will be directly passed through without further processing across Proxy, Service, Manager and up to InterfaceManager. E.g. no change to the hints will be made on its way to InterfaceManager.
The InterfaceManager will have an attribute hints, that will be initialized to the default hints for the device associated to the specific interface.
When a new talker or listener is added:
If hints is None, the hints associated to the InterfaceManager will be used (e.g. left unmodified)
If hints is not None and no other talker or listener has been added: the InterfaceManager hints will be updated to the user provided ones
If hints is not None and there are already talkers or listeners added, and the InterfaceManager hints is different than the one provided by the user, the operation will fail, and the user will be informed via a logging message
Related to this PR, specifically to decoupling the backend selection from the implementation: https://github.com/Avnu/detd/pull/20/files#r1582042749
Please note that detd will still default to the most sensible (e.g. hardware accelerated) setup by default. This class is intended to allow to override that configuration.
This class allows the customization of the specific implementation of the traffic specification and qos provided in the configuration. Based on the hint and the device capabilities, the initialization sequence will instantiate the specific classes to implement it. E.g. it may decide to use specific mappings, taprio modes, etc.
This ticket only contains the changes to provide the info an get that to the InterfaceManager for usage.
The processing of the hint to implement the specific spec/QoS will be described in a separated ticket.
Task 1: add new class Hints
We introduce a new class Hints. This class allows to select how the traffic specifications have to be implemented. It just holds the following attributes, with the described possible values:
We may add a class Hints in the scheduler module. This is a temporary location to enable the merge of the PR: https://github.com/Avnu/detd/pull/20
Task 2: provide a default Hints class per device plugin
Each device plugin will provide a default Hints instantiation that will define how the traffic spec / QoS will be implemented if no other Hints are provided by the caller.
It should be possible to calculate the default hints based on the device capabilities, so a method could be added to device fr that. But it should also be possible to override it. Other parameters would depend on the framework as well, like the AF_XDP_ZC or other data path implementations.
Task 3: provide a default parameter flow until InterfaceManager
If the Configuration constructor contains a hint, it will be assigned to Configuration.hints Otherwise, the default value will be None
This hints value will be directly passed through without further processing across Proxy, Service, Manager and up to InterfaceManager. E.g. no change to the hints will be made on its way to InterfaceManager.
The InterfaceManager will have an attribute hints, that will be initialized to the default hints for the device associated to the specific interface.
When a new talker or listener is added: