Documentation/networking/devlink/ice.rst

Source file repositories/reference/linux-study-clean/Documentation/networking/devlink/ice.rst

File Facts

System
Linux kernel
Corpus path
Documentation/networking/devlink/ice.rst
Extension
.rst
Size
21201 bytes
Lines
488
Domain
Support Tooling And Documentation
Bucket
Documentation
Inferred role
Support Tooling And Documentation: documentation
Status
atlas-only

Why This File Exists

Repository support layer: documentation, build tooling, samples, user-space helper tools, generated initramfs support, licenses, and validation utilities.

Dependency Surface

Detected Declarations

Annotated Snippet

.. SPDX-License-Identifier: GPL-2.0

===================
ice devlink support
===================

This document describes the devlink features implemented by the ``ice``
device driver.

Parameters
==========

.. list-table:: Generic parameters implemented
   :widths: 5 5 90

   * - Name
     - Mode
     - Notes
   * - ``enable_roce``
     - runtime
     - mutually exclusive with ``enable_iwarp``
   * - ``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:

Annotation

Implementation Notes