tc (short for traffic control) is a command-line utility in Linux, part of the iproute2 package, used to configure and manipulate the kernel's traffic control subsystem. It is documented in section 8 of the Linux manual pages (tc(8)).
Overview
According to the Linux manual page, "tc is used to configure Traffic Control in the Linux kernel." Traffic control, as implemented in the Linux kernel networking stack, encompasses four principal functions:
- Shaping — controlling the rate of transmission. Shaping occurs on egress and can also be used to smooth out bursts in traffic.
- Scheduling — reordering (prioritizing) the transmission of packets to improve interactivity while still guaranteeing bandwidth to bulk transfers; this also occurs on egress.
- Policing — regulating traffic that is arriving, thus occurring on ingress.
- Dropping — discarding traffic that exceeds a set bandwidth, which may occur on both ingress and egress.
Processing of traffic is controlled through three kinds of objects: qdiscs, classes, and filters.
Core concepts
Qdiscs (queueing disciplines)
A qdisc is short for "queueing discipline." Whenever the kernel needs to send a packet to an interface, the packet is enqueued to the qdisc configured for that interface; the kernel then retrieves packets from the qdisc for the network adapter driver. The simplest qdisc is pfifo, a pure First In, First Out queue. In the absence of a configured qdisc, pfifo_fast is the default.
Qdiscs are divided into:
- Classless qdiscs — such as
pfifo,bfifo,fq,fq_codel,fq_pie,codel,sfq,tbf,red,choke,gred,hhf,pie,sfb,netem,ingress,multiq,mqprio, andpfifo_fast. Classless qdiscs can only be attached at the root of a device. - Classful qdiscs — such as
HTB,HFSC,PRIO,DRR,ETS,QFQ, andATM. These can contain classes with further qdiscs nested inside.
Classes
Some qdiscs contain classes, which may themselves contain further qdiscs. Traffic can be enqueued into any of these inner qdiscs. Classes form a tree structure, where each class has a single parent but may have multiple children.
Filters
A filter is used by a classful qdisc to determine into which class a packet will be enqueued. Available filter types include basic, bpf, cgroup, flow, flower, fw, route, u32, and matchall. Filters reside within qdiscs.
Naming conventions
All qdiscs, classes, and filters have identifiers consisting of a major and minor number separated by a colon (major:minor), both expressed as hexadecimal and limited to 16 bits. A qdisc handle is expressed such as 10:, while a class's minor number is called a classid.
Common usage
Typical invocation forms follow the pattern:
tc [ OPTIONS ] qdisc [ add | change | replace | link | delete ] dev DEV ...
tc [ OPTIONS ] class [ add | change | replace | delete | show ] dev DEV ...
tc [ OPTIONS ] filter [ add | change | replace | delete | get ] dev DEV ...
For example, to add a qdisc to a device's root and to remove it:
tc qdisc add dev DEV root QDISC QDISC-PARAMETERS
tc qdisc del dev DEV root
The utility supports options such as -s (statistics), -d (details), -j (JSON output), -g (ASCII graph of classes), -batch (read commands from a file), and -netns (operate within a network namespace). It also provides a monitor subcommand for observing kernel-generated traffic control events.
History and distribution
The manual page states that tc was written by Alexey N. Kuznetsov and added in Linux 2.2. The utility is distributed as part of the iproute2 project, the collection of utilities for controlling TCP/IP networking. The iproute2 tc utility serves as the user-space interface to the kernel's traffic control subsystem.
See also
Related manual pages include tc-bfifo(8), tc-codel(8), tc-fq_codel(8), tc-htb(8), tc-netem(8), tc-red(8), tc-sfq(8), tc-tbf(8), and tc-u32(8). The Linux Advanced Routing & Traffic Control (LARTC) HOWTO is referenced as user documentation.
Note on sourcing: The information above is drawn from the official Linux manual pages for tc(8) (man7.org and the Debian/iproute2 man pages), which are authoritative primary documentation. The term "tc" in this Linux context is a well-established, standard command and is not ambiguous; no unverified or speculative claims have been introduced.