summaryrefslogtreecommitdiff
path: root/scripts/basic
diff options
context:
space:
mode:
authorCarolina Jubran <cjubran@nvidia.com>2026-09-02 22:32:24 +0300
committerJakub Kicinski <kuba@kernel.org>2026-09-05 13:18:47 -0700
commite7ee89740800a1cf253713e9249c3ee9203ebe91 (patch)
tree3404a43b2d77a64bad03c15a69139081631701be /scripts/basic
parentb3c79dee5038c5e8460c59d7d01cb1450bdf5ecb (diff)
downloadlinux-e7ee89740800a1cf253713e9249c3ee9203ebe91.tar.gz
linux-e7ee89740800a1cf253713e9249c3ee9203ebe91.zip
net/mlx5e: Fix ETS zero BW reporting when one TC holds 100%
When ETS TCs with zero bandwidth are configured, the driver programs the firmware using an alternate representation. On get, it needs to recognize that representation so those TCs can be translated back and reported as 0% bandwidth. The existing detection relied on the programmed bandwidth because it was enough to identify this representation. However, when a single ETS TC owns 100% of the bandwidth, its firmware representation becomes the same as a strict-priority TC, causing zero-bandwidth ETS TCs to be reported with non-zero bandwidth values. Use the cached TSA instead to distinguish the ETS and strict-priority cases. Fixes: be0f161ef141 ("net/mlx5e: DCBNL, Implement tc with ets type and zero bandwidth") Signed-off-by: Carolina Jubran <cjubran@nvidia.com> Reviewed-by: Alex Lazar <alazar@nvidia.com> Signed-off-by: Tariq Toukan <tariqt@nvidia.com> Link: https://patch.msgid.link/20260902193224.3668743-1-tariqt@nvidia.com Signed-off-by: Jakub Kicinski <kuba@kernel.org>
Diffstat (limited to 'scripts/basic')
0 files changed, 0 insertions, 0 deletions