Minki/linux
1
0
Fork 1
mirror of https://github.com/torvalds/linux.git synced 2024-11-22 12:11:40 +00:00
Code Issues Packages Projects Releases Wiki Activity

ice: Document tx_scheduling_layers parameter

Browse Source 
New driver specific parameter 'tx_scheduling_layers' was introduced.
Describe parameter in the documentation.

Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.com>
Acked-by: Jakub Kicinski <kuba@kernel.org>
Reviewed-by: Jiri Pirko <jiri@nvidia.com>
Reviewed-by: Przemek Kitszel <przemyslaw.kitszel@intel.com>
Co-developed-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
Signed-off-by: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
Signed-off-by: Tony Nguyen <anthony.l.nguyen@intel.com>
This commit is contained in:
Michal Wilczynski 2024-04-19 04:08:54 -04:00 committed by Tony Nguyen
parent 109eb29172
commit 9afff0de30
1 changed files with 47 additions and 0 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

47
Documentation/networking/devlink/ice.rst
View File

@ -21,6 +21,53 @@ Parameters
* - ``enable_iwarp``
- runtime
- mutually exclusive with ``enable_roce``
* - ``tx_scheduling_layers``
- permanent
- The ice hardware uses hierarchical scheduling for Tx with a fixed
number of layers in the scheduling tree. Each of them are decision
points. Root node represents a port, while all the leaves represent
the queues. This way of configuring the Tx scheduler allows features
like DCB or devlink-rate (documented below) to configure how much
bandwidth is given to any given queue or group of queues, enabling
fine-grained control because scheduling parameters can be configured
at any given layer of the tree.
The default 9-layer tree topology was deemed best for most workloads,
as it gives an optimal ratio of performance to configurability. However,
for some specific cases, this 9-layer topology might not be desired.
One example would be sending traffic to queues that are not a multiple
of 8. Because the maximum radix is limited to 8 in 9-layer topology,
the 9th queue has a different parent than the rest, and it's given
more bandwidth credits. This causes a problem when the system is
sending traffic to 9 queues:
| tx_queue_0_packets: 24163396
| tx_queue_1_packets: 24164623
| tx_queue_2_packets: 24163188
| tx_queue_3_packets: 24163701
| tx_queue_4_packets: 24163683
| tx_queue_5_packets: 24164668
| tx_queue_6_packets: 23327200
| tx_queue_7_packets: 24163853
| tx_queue_8_packets: 91101417 < Too much traffic is sent from 9th
To address this need, you can switch to a 5-layer topology, which
changes the maximum topology radix to 512. With this enhancement,
the performance characteristic is equal as all queues can be assigned
to the same parent in the tree. The obvious drawback of this solution
is a lower configuration depth of the tree.
Use the ``tx_scheduling_layer`` parameter with the devlink command
to change the transmit scheduler topology. To use 5-layer topology,
use a value of 5. For example:
$ devlink dev param set pci/0000:16:00.0 name tx_scheduling_layers
value 5 cmode permanent
Use a value of 9 to set it back to the default value.
You must do PCI slot powercycle for the selected topology to take effect.
To verify that value has been set:
$ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers
Info versions
=============