From: Simon Horman <horms@kernel.org>
To: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
Cc: netdev@vger.kernel.org, intel-wired-lan@lists.osuosl.org,
Michal Wilczynski <michal.wilczynski@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 5/5] ice: Document tx_scheduling_layers parameter
Date: Sat, 7 Oct 2023 17:35:58 +0200 [thread overview]
Message-ID: <20231007153558.GE831234@kernel.org> (raw)
In-Reply-To: <20231006110212.96305-6-mateusz.polchlopek@intel.com>
On Fri, Oct 06, 2023 at 07:02:12AM -0400, Mateusz Polchlopek wrote:
> From: Michal Wilczynski <michal.wilczynski@intel.com>
>
> New driver specific parameter 'tx_scheduling_layers' was introduced.
> Describe parameter in the documentation.
>
> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.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>
Hi,
I'm not expert here,
but this seems to cause a splat when building documentation.
.../ice.rst:70: WARNING: Unexpected indentation.
.../ice.rst:25: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 2 does not contain the same number of items as row 1 (3 vs 4).
.. list-table:: Driver-specific parameters implemented
:widths: 5 5 5 85
* - Name
- Type
- Mode
- Description
* - ``tx_scheduling_layers``
- u8
- permanent
The ice hardware uses hierarchical scheduling for Tx with a fixed
number of layers in the scheduling tree. Root node is representing a
port, while all the leaves represents the queues. This way of
configuring Tx scheduler allows features like DCB or devlink-rate
(documented below) for fine-grained configuration how much BW is given
to any given queue or group of queues, as scheduling parameters can be
configured at any given layer of the tree. By default 9-layer tree
topology was deemed best for most workloads, as it gives optimal
performance to configurability ratio. However for some specific cases,
this might not be the case. A great example would be sending traffic to
queues that is not a multiple of 8. Since in 9-layer topology maximum
number of children is limited to 8, the 9th queue has a different parent
than the rest, and it's given more BW 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 to 9th
Sometimes this might be a big concern, so the idea is to empower the
user to switch to 5-layer topology, enabling performance gains but
sacrificing configurability for features like DCB and devlink-rate.
This parameter gives user flexibility to choose the 5-layer transmit
scheduler topology. After switching parameter reboot is required for
the feature to start working.
User could choose 9 (the default) or 5 as a value of parameter, e.g.:
$ devlink dev param set pci/0000:16:00.0 name tx_scheduling_layers
value 5 cmode permanent
And verify that value has been set:
$ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers
_______________________________________________
Intel-wired-lan mailing list
Intel-wired-lan@osuosl.org
https://lists.osuosl.org/mailman/listinfo/intel-wired-lan
WARNING: multiple messages have this Message-ID (diff)
From: Simon Horman <horms@kernel.org>
To: Mateusz Polchlopek <mateusz.polchlopek@intel.com>
Cc: intel-wired-lan@lists.osuosl.org, netdev@vger.kernel.org,
Michal Wilczynski <michal.wilczynski@intel.com>,
Przemek Kitszel <przemyslaw.kitszel@intel.com>
Subject: Re: [Intel-wired-lan] [PATCH iwl-net v2 5/5] ice: Document tx_scheduling_layers parameter
Date: Sat, 7 Oct 2023 17:35:58 +0200 [thread overview]
Message-ID: <20231007153558.GE831234@kernel.org> (raw)
In-Reply-To: <20231006110212.96305-6-mateusz.polchlopek@intel.com>
On Fri, Oct 06, 2023 at 07:02:12AM -0400, Mateusz Polchlopek wrote:
> From: Michal Wilczynski <michal.wilczynski@intel.com>
>
> New driver specific parameter 'tx_scheduling_layers' was introduced.
> Describe parameter in the documentation.
>
> Signed-off-by: Michal Wilczynski <michal.wilczynski@intel.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>
Hi,
I'm not expert here,
but this seems to cause a splat when building documentation.
.../ice.rst:70: WARNING: Unexpected indentation.
.../ice.rst:25: WARNING: Error parsing content block for the "list-table" directive: uniform two-level bullet list expected, but row 2 does not contain the same number of items as row 1 (3 vs 4).
.. list-table:: Driver-specific parameters implemented
:widths: 5 5 5 85
* - Name
- Type
- Mode
- Description
* - ``tx_scheduling_layers``
- u8
- permanent
The ice hardware uses hierarchical scheduling for Tx with a fixed
number of layers in the scheduling tree. Root node is representing a
port, while all the leaves represents the queues. This way of
configuring Tx scheduler allows features like DCB or devlink-rate
(documented below) for fine-grained configuration how much BW is given
to any given queue or group of queues, as scheduling parameters can be
configured at any given layer of the tree. By default 9-layer tree
topology was deemed best for most workloads, as it gives optimal
performance to configurability ratio. However for some specific cases,
this might not be the case. A great example would be sending traffic to
queues that is not a multiple of 8. Since in 9-layer topology maximum
number of children is limited to 8, the 9th queue has a different parent
than the rest, and it's given more BW 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 to 9th
Sometimes this might be a big concern, so the idea is to empower the
user to switch to 5-layer topology, enabling performance gains but
sacrificing configurability for features like DCB and devlink-rate.
This parameter gives user flexibility to choose the 5-layer transmit
scheduler topology. After switching parameter reboot is required for
the feature to start working.
User could choose 9 (the default) or 5 as a value of parameter, e.g.:
$ devlink dev param set pci/0000:16:00.0 name tx_scheduling_layers
value 5 cmode permanent
And verify that value has been set:
$ devlink dev param show pci/0000:16:00.0 name tx_scheduling_layers
next prev parent reply other threads:[~2023-10-07 15:36 UTC|newest]
Thread overview: 14+ messages / expand[flat|nested] mbox.gz Atom feed top
2023-10-06 11:02 [Intel-wired-lan] [PATCH iwl-next v2 0/5] ice: Support 5 layer Tx scheduler topology Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-06 11:02 ` [Intel-wired-lan] [PATCH iwl-net v2 1/5] ice: Support 5 layer topology Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-06 11:02 ` [Intel-wired-lan] [PATCH iwl-net v2 2/5] ice: Adjust the VSI/Aggregator layers Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-06 11:02 ` [Intel-wired-lan] [PATCH iwl-net v2 3/5] ice: Enable switching default Tx scheduler topology Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-06 11:02 ` [Intel-wired-lan] [PATCH iwl-net v2 4/5] ice: Add tx_scheduling_layers devlink param Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-06 11:02 ` [Intel-wired-lan] [PATCH iwl-net v2 5/5] ice: Document tx_scheduling_layers parameter Mateusz Polchlopek
2023-10-06 11:02 ` Mateusz Polchlopek
2023-10-07 15:35 ` Simon Horman [this message]
2023-10-07 15:35 ` Simon Horman
Reply instructions:
You may reply publicly to this message via plain-text email
using any one of the following methods:
* Save the following mbox file, import it into your mail client,
and reply-to-all from there: mbox
Avoid top-posting and favor interleaved quoting:
https://en.wikipedia.org/wiki/Posting_style#Interleaved_style
* Reply using the --to, --cc, and --in-reply-to
switches of git-send-email(1):
git send-email \
--in-reply-to=20231007153558.GE831234@kernel.org \
--to=horms@kernel.org \
--cc=intel-wired-lan@lists.osuosl.org \
--cc=mateusz.polchlopek@intel.com \
--cc=michal.wilczynski@intel.com \
--cc=netdev@vger.kernel.org \
--cc=przemyslaw.kitszel@intel.com \
/path/to/YOUR_REPLY
https://kernel.org/pub/software/scm/git/docs/git-send-email.html
* If your mail client supports setting the In-Reply-To header
via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line
before the message body.
This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.