Bug 2216062

I can't say for sure how often we would use this command but I see it as being along the same lines as `ethtool`, `ip` etc.

The command has a few uses but the one I'm referencing is checking the qdisc statistics like `tc -s qdisc show dev eth1`

Some more details here (Internal Red Hat comment): https://bugzilla.redhat.com/show_bug.cgi?id=2209774#c30

Some details on the package:

[root@compute-0 heat-admin]# dnf info iproute-tc
Updating Subscription Management repositories.
Last metadata expiration check: 0:01:49 ago on Tue 20 Jun 2023 00:37:01 UTC.
Available Packages
Name         : iproute-tc
Version      : 5.18.0
Release      : 1.el8
Architecture : x86_64
Size         : 466 k
Source       : iproute-5.18.0-1.el8.src.rpm
Repository   : rhel-8-for-x86_64-baseos-rpms
Summary      : Linux Traffic Control utility
URL          : https://kernel.org/pub/linux/utils/net/iproute2/
License      : GPLv2+
Description  : The Traffic Control utility manages queueing disciplines, their classes and
             : attached filters and actions. It is the standard tool to configure QoS in
             : Linux.

Here is the package that provides the tool.

Available Packages
Name         : iproute-tc
Version      : 5.18.0
Release      : 1.el8
Architecture : x86_64
Size         : 466 k
Source       : iproute-5.18.0-1.el8.src.rpm
Repository   : rhel-8-for-x86_64-baseos-rpms
Summary      : Linux Traffic Control utility
URL          : https://kernel.org/pub/linux/utils/net/iproute2/
License      : GPLv2+
Description  : The Traffic Control utility manages queueing disciplines, their classes and
             : attached filters and actions. It is the standard tool to configure QoS in
             : Linux.

The dependencies are very lean:

[ihrachys@hardprov-fx2-6 ~]$ rpm -qR iproute-tc
iproute(x86-64) = 5.15.0-4.el8_6.1
libbpf.so.0()(64bit)
libbpf.so.0(LIBBPF_0.0.1)(64bit)
libbpf.so.0(LIBBPF_0.0.6)(64bit)
libbpf.so.0(LIBBPF_0.1.0)(64bit)
libbpf.so.0(LIBBPF_0.2.0)(64bit)
libc.so.6()(64bit)
libc.so.6(GLIBC_2.11)(64bit)
libc.so.6(GLIBC_2.14)(64bit)
libc.so.6(GLIBC_2.2.5)(64bit)
libc.so.6(GLIBC_2.28)(64bit)
libc.so.6(GLIBC_2.3)(64bit)
libc.so.6(GLIBC_2.3.4)(64bit)
libc.so.6(GLIBC_2.4)(64bit)
libc.so.6(GLIBC_2.7)(64bit)
libc.so.6(GLIBC_2.8)(64bit)
libcap.so.2()(64bit)
libdl.so.2()(64bit)
libdl.so.2(GLIBC_2.2.5)(64bit)
libelf.so.1()(64bit)
libelf.so.1(ELFUTILS_1.0)(64bit)
libm.so.6()(64bit)
libm.so.6(GLIBC_2.2.5)(64bit)
libmnl.so.0()(64bit)
libmnl.so.0(LIBMNL_1.0)(64bit)
libselinux.so.1()(64bit)
libxtables.so.12()(64bit)
rpmlib(CompressedFileNames) <= 3.0.4-1
rpmlib(FileDigests) <= 4.6.0-1
rpmlib(PayloadFilesHavePrefix) <= 4.0-1
rpmlib(PayloadIsXz) <= 5.2-1
rtld(GNU_HASH)

We discussed the matter today during Networking Bug Triage call, and we believe that while this may not help in the majority cases, it will help with the tiny number of very peculiar low-level issues for which we may especially benefit from tc logs collected. And yes, we would like to see this on all supported releases, incl. 16.x. Thanks.

Based on the endorsement from networking side, I'll work on adding the package.
I'll cover 17.1 and 16.2 while I won't cover 17.0 and 16.1, because this is not a critical functional problem.

iproute-tc package is seen on overcloud nodes:

[tripleo-admin@ceph-0 ~]$ sudo yum list installed | grep iproute-tc
iproute-tc.x86_64                               6.1.0-1.el9                              @anaconda 

[tripleo-admin@compute-0 ~]$ sudo yum list installed | grep iproute-tc
iproute-tc.x86_64                               6.1.0-1.el9                              @anaconda 

[tripleo-admin@controller-0 ~]$ sudo yum list installed | grep iproute-tc
iproute-tc.x86_64                               6.1.0-1.el9                              @anaconda

Example of command working:

[tripleo-admin@controller-0 ~]$ sudo tc -s qdisc show dev enp1s0
qdisc fq_codel 0: root refcnt 2 limit 10240p flows 1024 quantum 1514 target 5ms interval 100ms memory_limit 32Mb ecn drop_batch 64 
 Sent 112325491 bytes 194897 pkt (dropped 0, overlimits 0 requeues 0) 
 backlog 0b 0p requeues 0
  maxpacket 17373 drop_overlimit 0 new_flow_count 176 ecn_mark 0
  new_flows_len 0 old_flows_len 0

Since the problem described in this bug report should be
resolved in a recent advisory, it has been closed with a
resolution of ERRATA.

For information on the advisory (Release of components for Red Hat OpenStack Platform 17.1.1 (Wallaby)), and where to find the updated
files, follow the link below.

If the solution does not work for you, open a new bug report.

https://access.redhat.com/errata/RHBA-2023:5138