CAKE(8)

💖 CAKE(8) 💖 — the Linux manual but make it group chat

okay so this is CAKE(8) from the Linux manual set, and bestie, I need you to know immediately that CAKE here does not mean the dessert. It's Common Applications Kept Enhanced. The name is a lie but the vibes are immaculate. Let's go. 🍰✨

---

✨ NAME ✨

CAKE — Common Applications Kept Enhanced (CAKE)

---

🦋 SYNOPSIS 🦋

tc qdisc ... { cake | cake_mq }
[ bandwidth RATE | unlimited* | autorate-ingress ]
[ rtt TIME | datacentre | lan | metro | regional | internet* | oceanic |
satellite | interplanetary ]
[ besteffort | diffserv8 | diffserv4 | diffserv3* ]
[ flowblind | srchost | dsthost | hosts | flows | dual-srchost | dual-
dsthost | triple-isolate* ]
[ nat | nonat* ]
[ wash | nowash* ]
[ split-gso* | no-split-gso ]
[ ack-filter | ack-filter-aggressive | no-ack-filter* ]
[ memlimit LIMIT ]
[ fwmark MASK ]
[ ptm | atm | noatm* ]
[ overhead N | conservative | raw* ]
[ mpu N ]
[ ingress | egress* ]
(* marks defaults)

the little * star next to a thing means that's the default, bestie. no stars, no default. 💫

---

🌈 DESCRIPTION 🌈

okay so CAKE (Common Applications Kept Enhanced) is a shaping-capable queue discipline that uses both AQM and FQ. It's giving overachiever, and honestly? It ate. 💅

Here's what it's built out of:

• COBALT, which is an AQM algorithm combining Codel and BLUE
• a shaper that operates in deficit mode
• a variant of DRR++ for flow isolation

And then, because it wasn't done flexing, it also uses 8-way set-associative hashing to virtually eliminate hash collisions. Priority queuing is available through a simplified diffserv implementation, and overhead compensation for various encapsulation schemes is tightly integrated. It's giving "I do everything and I do it well" energy. 👑

A multi-queue aware version of CAKE is available as a separate qdisc called cake_mq. This variant lets the CAKE shaper scale across multiple CPUs on hardware that has multiple transmit queues. It's mostly a drop-in replacement for CAKE (and takes the same parameters, slay), but it has a few differences in how it treats traffic. See the section below for more details on these differences. 👀

All settings are optional. The default settings are chosen to be sensible in most common deployments, which is so thoughtful of them. Most people will only need to set the bandwidth parameter to get useful results — but reading the Overhead Compensation and Round Trip Time sections is strongly encouraged. fr fr, go read them. 📖

---

🎀 SHAPER PARAMETERS 🎀

CAKE uses a deficit-mode shaper, which does not exhibit the initial burst typical of token-bucket shapers. It will automatically burst precisely as much as required to maintain the configured throughput. As such, it is very straightforward to configure. no drama, no mystery, just vibes and math. ✨

• unlimited (default) — No limit on the bandwidth. Go wild, bestie, it's feral out here. 🦋
• bandwidth RATE — Set the shaper bandwidth. See tc(8) or examples below for details of the RATE value.
• autorate-ingress — Automatic capacity estimation based on traffic arriving at this qdisc. This is most likely to be useful with cellular links, which tend to change quality randomly (relatable, honestly). A bandwidth parameter can be used in conjunction to specify an initial estimate. The shaper will periodically be set to a bandwidth slightly below the estimated rate. This estimator cannot estimate the bandwidth of links downstream of itself. 🚫

🚨 this parameter cannot be used with the cake_mq variant. periodt.

---

🧚 OVERHEAD COMPENSATION PARAMETERS 🧚

The size of each packet on the wire may differ from that seen by Linux. The following parameters allow CAKE to compensate for this difference by internally considering each packet to be bigger than Linux informs it. To assist users who are not expert network engineers, keywords have been provided to represent a number of common link technologies. we love an accessible king 💜

🌸 Manual Overhead Specification 🌸

• overhead BYTES — Adds BYTES to the size of each packet. BYTES may be negative; values between -64 and 256 (inclusive) are accepted.
• mpu BYTES — Rounds each packet (including overhead) up to a minimum length BYTES. BYTES may not be negative; values between 0 and 256 (inclusive) are accepted.
• atm — Compensates for ATM cell framing, which is normally found on ADSL links. This is performed after the overhead parameter above. ATM uses fixed 53-byte cells, each of which can carry 48 bytes payload.
• ptm — Compensates for PTM encoding, which is normally found on VDSL2 links and uses a 64b/65b encoding scheme. It is even more efficient to simply derate the specified shaper bandwidth by a factor of 64/65 or 0.984. See ITU G.992.3 Annex N and IEEE 802.3 Section 61.3 for details. 📚
• noatm — Disables ATM and PTM compensation.

🌷 Failsafe Overhead Keywords 🌷

These two keywords are provided for quick-and-dirty setup. Use them if you can't be bothered to read the rest of this section. (valid. we've all been there. 🙈)

• raw (default) — Turns off all overhead compensation in CAKE. The packet size reported by Linux will be used directly.

Other overhead keywords may be added after "raw". The effect of this is to make the overhead compensation operate relative to the reported packet size, not the underlying IP packet size.

• conservative — Compensates for more overhead than is likely to occur on any widely-deployed link technology. Equivalent to overhead 48 atm.

🍓 ADSL Overhead Keywords 🍓

Most ADSL modems have a way to check which framing scheme is in use. Often this is also specified in the settings document provided by the ISP. The keywords in this section are intended to correspond with these sources of information. All of them implicitly set the atm flag. ⚠️

• pppoa-vcmux — Equivalent to overhead 10 atm
• pppoa-llc — Equivalent to overhead 14 atm
• pppoe-vcmux — Equivalent to overhead 32 atm
• pppoe-llcsnap — Equivalent to overhead 40 atm
• bridged-vcmux — Equivalent to overhead 24 atm
• bridged-llcsnap — Equivalent to overhead 32 atm
• ipoa-vcmux — Equivalent to overhead 8 atm
• ipoa-llcsnap — Equivalent to overhead 16 atm

See also the Ethernet Correction Factors section below. 👇

🦋 VDSL2 Overhead Keywords 🦋

ATM was dropped from VDSL2 in favour of PTM, which is a much more straightforward framing scheme. Some ISPs retained PPPoE for compatibility with their existing back-end systems. legacy behaviour, we respect it 🫶

• pppoe-ptm — Equivalent to overhead 30 ptm

PPPoE: 2B PPP + 6B PPPoE +
ETHERNET: 6B dest MAC + 6B src MAC + 2B ethertype + 4B Frame
Check Sequence +
PTM: 1B Start of Frame (S) + 1B End of Frame (Ck) + 2B TC-CRC
(PTM-FCS)

• bridged-ptm — Equivalent to overhead 22 ptm

ETHERNET: 6B dest MAC + 6B src MAC + 2B ethertype + 4B Frame
Check Sequence +
PTM: 1B Start of Frame (S) + 1B End of Frame (Ck) + 2B TC-CRC
(PTM-FCS)

See also the Ethernet Correction Factors section below. 👇

💜 DOCSIS Cable Overhead Keyword 💜

DOCSIS is the universal standard for providing Internet service over cable-TV infrastructure.

In this case, the actual on-wire overhead is less important than the packet size the head-end equipment uses for shaping and metering. This is specified to be an Ethernet frame including the CRC (aka FCS).

• docsis — Equivalent to overhead 18 mpu 64 noatm

🌈 Ethernet Overhead Keywords 🌈

• ethernet — Accounts for Ethernet's preamble, inter-frame gap, and Frame Check Sequence. Use this keyword when the bottleneck being shaped for is an actual Ethernet cable. Equivalent to overhead 38 mpu 84 noatm
• ether-vlan — Adds 4 bytes to the overhead compensation, accounting for an IEEE 802.1Q VLAN header appended to the Ethernet frame header. NB: Some ISPs use one or even two of these within PPPoE; this keyword may be repeated as necessary to express this. 🔁

---

⭐ ROUND TRIP TIME PARAMETERS ⭐

Active Queue Management (AQM) consists of embedding congestion signals in the packet flow, which receivers use to instruct senders to slow down when the queue is persistently occupied. CAKE uses ECN signalling when available, and packet drops otherwise, according to a combination of the Codel and BLUE AQM algorithms called COBALT. it's giving "please chill" but make it networking 💌

Very short latencies require a very rapid AQM response to adequately control latency. However, such a rapid response tends to impair throughput when the actual RTT is relatively long. CAKE allows specifying the RTT it assumes for tuning various parameters. Actual RTTs within an order of magnitude of this will generally work well for both throughput and latency management. 📏

🚨 at the 'lan' setting and below, the time constants are similar in magnitude to the jitter in the Linux kernel itself, so congestion might be signalled prematurely. The flows will then become sparse and total throughput reduced, leaving little or no back-pressure for the fairness logic to work against. Use the "metro" setting for local lans unless you have a custom kernel. lowkey important, don't skip this one 😭

• rtt TIME — Manually specify an RTT.
• datacentre — For extremely high-performance 10GigE+ networks only. Equivalent to rtt 100us.
• lan — For pure Ethernet (not Wi-Fi) networks, at home or in the office. Don't use this when shaping for an Internet access link. Equivalent to rtt 1ms.
• metro — For traffic mostly within a single city. Equivalent to rtt 10ms.
• regional — For traffic mostly within a European-sized country. Equivalent to rtt 30ms.
• internet (default) — This is suitable for most Internet traffic. Equivalent to rtt 100ms.
• oceanic — For Internet traffic with generally above-average latency, such as that suffered by Australasian residents. Equivalent to rtt 300ms.
• satellite — For traffic via geostationary satellites. Equivalent to rtt 1000ms.
• interplanetary — So named because Jupiter is about 1 light-hour from Earth. Use this to (almost) completely disable AQM actions. Equivalent to rtt 3600s. 🪐✨

💖 FLOW ISOLATION PARAMETERS 💖

okay bestie so when flow isolation is on, CAKE literally takes packets from different flows and drops them into different queues, and each one of those queues has its own lil AQM state, like each flow got its own bedroom 🛏️. Then packets from every queue get delivered fairly, using a DRR++ algorithm that lowkey minimizes latency for the "sparse" flows (the quiet ones, the shy ones 🥺). And to keep flows from crashing into each other, CAKE uses a set-associative hashing algorithm to minimize flow collisions. no cap.

These keywords decide what "fairness" even means for you — whether it's based on source address, destination address, individual flows, or any combo of those. pick your fighter 💅

• flowblind — turns flow isolation ALL the way off. every packet just goes through a single queue for each tin. one queue, no drama, no separation 🫶
• srchost — flows are defined only by source address. could be useful on the egress path of an ISP backhaul 👀
• dsthost — flows are defined only by destination address. could be useful on the ingress path of an ISP backhaul 👀
• hosts — flows are defined by source-destination host pairs. so this is host isolation, not flow isolation, iykyk.
• flows — flows are defined by the entire 5-tuple: source address, destination address, transport protocol, source port and destination port. this is the same type of flow isolation that SFQ and fq_codel do.
• dual-srchost — flows are defined by the 5-tuple, and fairness gets applied first over source addresses, then over individual flows. perfect for egress traffic from a LAN to the internet 🌐, where it'll stop any one LAN host from monopolising the uplink, no matter how many flows they're trying to spam.
• dual-dsthost — flows are defined by the 5-tuple, and fairness gets applied first over destination addresses, then over individual flows. perfect for ingress traffic to a LAN from the internet 🌐, where it'll stop any one LAN host from monopolising the downlink, regardless of how many flows they use.
• triple-isolate (default) — flows are defined by the 5-tuple, and fairness gets applied over source and destination addresses intelligently (ie. not merely by host-pairs), plus over individual flows. use this if you're not sure whether to pick dual-srchost or dual-dsthost — it does both jobs at once and stops any one host on either side of the link from monopolising it with a huge pile of flows. the moment ✨
• nat — tells Cake to do a NAT lookup before applying flow-isolation rules, so it can figure out the true addresses and port numbers of the packet and be fairer between hosts "inside" the NAT. heads up tho: this has no practical effect in flowblind or flows modes, or if NAT is happening on a different host.
• nonat (default) — Cake does NOT do a NAT lookup. flow isolation just uses the addresses and port numbers directly visible to the interface Cake is attached to. simple as that.

---

👑 PRIORITY QUEUE PARAMETERS 👑

CAKE can split your traffic into "tins" based on the Diffserv field 🫙. every tin has its own independent set of flow-isolation queues, and gets serviced based on a WRR algorithm. and to avoid perverse Diffserv marking incentives (we don't do that here 💀), tin weights have a "priority sharing" value when the bandwidth used by that tin is below a threshold, and a lower "bandwidth sharing" value when it's above. bandwidth gets compared against the threshold using the same algorithm as the deficit-mode shaper. slay.

detailed customisation of tin parameters is NOT provided, bestie. the presets below do all the necessary tuning for you, relative to the current shaper bandwidth and RTT settings. you're welcome 💅

• besteffort — disables priority queuing entirely by putting all traffic in one tin. one tin to rule them all 🎀
• precedence — enables legacy interpretation of the TOS "Precedence" field. using this preset on the modern Internet is firmly discouraged 🚫 (like, we're begging you, don't).
• diffserv4 — gives you a general-purpose Diffserv implementation with four tins:
  • Bulk (CS1, LE in kernel v5.9+), 6.25% threshold, generally low priority.
  • Best Effort (general), 100% threshold.
  • Video (AF4x, AF3x, CS3, AF2x, CS2, TOS4, TOS1), 50% threshold.
  • Voice (CS7, CS6, EF, VA, CS5, CS4), 25% threshold.
• diffserv3 (default) — gives you a simple, general-purpose Diffserv implementation with three tins:
  • Bulk (CS1, LE in kernel v5.9+), 6.25% threshold, generally low priority.
  • Best Effort (general), 100% threshold.
  • Voice (CS7, CS6, EF, VA, TOS4), 25% threshold, reduced Codel interval.
• fwmark MASK — this option turns on fwmark-based overriding of CAKE's tin selection. if set, the option specifies a bitmask that gets applied to the fwmark associated with each packet. if the result of this masking is non-zero, that result gets right-shifted by the number of least-significant unset bits in the mask value, and then that result is used as the tin number for that packet. this is how you set policies in a firewall script that override CAKE's built-in tin selection 🔥.

---

🌈 OTHER PARAMETERS 🌈

• ingress — says that CAKE is running in ingress mode (i.e. running on the downlink of a connection 📥). this changes the shaper so it also counts dropped packets as data transferred, because those packets will have already traversed the link before CAKE could even decide what to do with them. brutal but true 💀.

on top of that, the AQM gets tuned to always keep at least two packets queued per flow. why? because retransmits are more expensive in ingress mode, since dropped packets have to traverse the link again. so keeping a minimum number of packets queued improves throughput in cases where there are so many active flows that they saturate the link even at their minimum window size.

• memlimit LIMIT — caps the memory that Cake consumes to LIMIT bytes. ngl, this does NOT translate directly to queue size (so do not size this based on bandwidth delay product considerations — size it on worst case acceptable memory consumption instead), because there's some overhead in the data structures holding the packets, especially for small packets.

by default, the limit is calculated based on the bandwidth and RTT settings.

• wash — traffic entering your diffserv domain is frequently mis-marked in transit from the perspective of your network, and traffic exiting yours may be mis-marked from the perspective of the transiting provider. messy 😭

applying the wash option clears all extra diffserv (but not ECN bits), after priority queuing has taken place.

if you're shaping inbound, and you cannot trust the diffserv markings (as is the case for Comcast Cable, among others), it's best to use a single queue "besteffort" mode with wash. periodt.

• split-gso — this option controls whether CAKE will split General Segmentation Offload (GSO) super-packets into their on-the-wire components and dequeue them individually.

super-packets are created by the networking stack to improve efficiency. but because they're larger, they take longer to dequeue, which translates to higher latency for competing flows, especially at lower bandwidths. CAKE defaults to splitting GSO packets to achieve the lowest possible latency. at link speeds higher than 10 Gbps, setting the no-split-gso parameter can increase the maximum achievable throughput by retaining the full GSO packets. speed AND vibes, pick your moment 🦋

---

🧚 OVERRIDING CLASSIFICATION WITH TC FILTERS 🧚

CAKE supports overriding its internal classification of packets through the tc filter mechanism. packets can be assigned to different priority tins by setting the priority field on the skb, and the flow hashing can be overridden by setting the classid parameter. it's giving main character energy ✨

🎀 Tin override 🎀

to assign a priority tin, the major number of the priority field needs to match the qdisc handle of the cake instance. if it does, the minor number gets interpreted as the tin index. for example, to classify all ICMP packets as 'bulk', you'd use this filter:

# tc qdisc replace dev eth0 handle 1: root cake diffserv3
# tc filter add dev eth0 parent 1: protocol ip prio 1 \
  u32 match icmp type 0 0 action skbedit priority 1:1

🎀 Flow hash override 🎀

to override flow hashing, you can set the classid. CAKE will interpret the major number of the classid as the host hash used in host isolation mode, and the minor number as the flow hash used for flow-based queueing. you can set one or both of those, and they'll be used if the relevant flow isolation parameter is set (i.e., the major number gets ignored if CAKE isn't configured in hosts mode, and the minor number gets ignored if CAKE isn't configured in flows mode).

this example will assign all ICMP packets to the first queue:

# tc qdisc replace dev eth0 handle 1: root cake
# tc filter add dev eth0 parent 1: protocol ip prio 1 \
  u32 match icmp type 0 0 classid 0:1

if only one of the host and flow overrides is set, CAKE will compute the other hash from the packet as normal. note, however, that the host isolation mode works by assigning a host ID to the flow queue — so if you're overriding both host and flow, the same flow cannot have more than one host assigned. also, it's not possible to assign different source and destination host IDs through the override mechanism; if a host ID is assigned, it will be used as both source and destination host. so plan accordingly bestie 🙈

💫 DIFFERENCES BETWEEN SINGLE-QUEUE CAKE AND THE CAKE_MQ MULTI-QUEUE VARIANT 💫

okay so here's the tea bestie 🍵 the regular CAKE qdisc is, like basically every other qdisc out there, subject to the global qdisc lock, which means it does not scale across multiple CPUs. which lowkey caps the max bandwidth the shaper can handle at whatever a single CPU can push. one core, one struggle, fr fr 😭

to dodge that central locking situation, the cake_mq qdisc can be used as a drop-in replacement for cake on devices that have more than one TX queue, like this:

# tc qdisc replace dev eth0 handle 1: root cake_mq bandwidth 1Gbit
# tc qdisc show dev eth0
qdisc cake_mq 8001: root bandwidth 1Gbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0
qdisc cake 0: parent 8001:2 bandwidth 1Gbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0
qdisc cake 0: parent 8001:1 bandwidth 1Gbit diffserv3 triple-isolate nonat nowash no-ack-filter split-gso rtt 100ms raw overhead 0

the way that output is giving "look at me I installed a whole squad" 👑 — this will install separate cake instances on each hardware queue. these instances share configuration, and can only be configured through the root cake_mq instance. they also share the bandwidth shaper state, but otherwise they run independently of one another, which is exactly what lets the CAKE shaper scale across multiple CPUs. main character energy per core 💅

so like, while the cake_mq qdisc is designed to serve as a drop-in replacement for single-queue CAKE, it does have some differences in how it treats traffic, and that's caused by each sub-qdisc executing independently. specifically: the flow classification and the fairness enforcement between flows (including the prioritisation between tins) only happens within each qdisc instance. which means global flow and host fairness cannot be enforced by cake_mq. approximate fairness should still be achievable assuming flows are evenly distributed between queues, but that's ultimately outside the control of CAKE itself, bestie — it's not CAKE's hands, it's the queue distribution's hands 🙈

users requiring exact fairness between flows are encouraged to stick to the regular cake qdisc. no cap.

for details on how the shaper state sharing algorithm actually works, and its scaling properties, see the publication: Köppeler et al, 2025: "Have your CAKE and eat it too: Scaling software rate limiting across CPU cores", published in the IEEE LANMAN 2025 conference proceedings, and also available at https://schmiste.github.io/lanman25.pdf. 🎀

---

✨ EXAMPLES ✨

okay demo time, watch this 🦋

# tc qdisc delete root dev eth0
# tc qdisc add root dev eth0 cake bandwidth 100Mbit ethernet
# tc -s qdisc show dev eth0

qdisc cake 1: root refcnt 2 bandwidth 100Mbit diffserv3 triple-isolate rtt 100.0ms noatm overhead 38 mpu 84
 Sent 0 bytes 0 pkt (dropped 0, overlimits 0 requeues 0)
 backlog 0b 0p requeues 0
 memory used: 0b of 5000000b
 capacity estimate: 100Mbit
 min/max network layer size:        65535 /       0
 min/max overhead-adjusted size:    65535 /       0
 average network hdr offset:            0

                   Bulk  Best Effort        Voice
  thresh       6250Kbit      100Mbit       25Mbit
  target          5.0ms        5.0ms        5.0ms
  interval      100.0ms      100.0ms      100.0ms
  pk_delay          0us          0us          0us
  av_delay          0us          0us          0us
  sp_delay          0us          0us          0us
  pkts                0            0            0
  bytes               0            0            0
  way_inds            0            0            0
  way_miss            0            0            0
  way_cols            0            0            0
  drops               0            0            0
  marks               0            0            0
  ack_drop            0            0            0
  sp_flows            0            0            0
  bk_flows            0            0            0
  un_flows            0            0            0
  max_len             0            0            0
  quantum           300         1514          762

fresh install, zero packets, everything sitting at 0 — it's giving blank canvas, pristine, untouched ✨

🕐 after some use:

# tc -s qdisc show dev eth0

qdisc cake 1: root refcnt 2 bandwidth 100Mbit diffserv3 triple-isolate rtt 100.0ms noatm overhead 38 mpu 84
 Sent 44709231 bytes 31931 pkt (dropped 45, overlimits 93782 requeues 0)
 backlog 33308b 22p requeues 0
 memory used: 292352b of 5000000b
 capacity estimate: 100Mbit
 min/max network layer size:           28 /    1500
 min/max overhead-adjusted size:       84 /    1538
 average network hdr offset:           14

                   Bulk  Best Effort        Voice
  thresh       6250Kbit      100Mbit       25Mbit
  target          5.0ms        5.0ms        5.0ms
  interval      100.0ms      100.0ms      100.0ms
  pk_delay        8.7ms        6.9ms        5.0ms
  av_delay        4.9ms        5.3ms        3.8ms
  sp_delay        727us        1.4ms        511us
  pkts             2590        21271         8137
  bytes         3081804     30302659     11426206
  way_inds            0           46            0
  way_miss            3           17            4
  way_cols            0            0            0
  drops              20           15           10
  marks               0            0            0
  ack_drop            0            0            0
  sp_flows            2            4            1
  bk_flows            1            2            1
  un_flows            0            0            0
  max_len          1514         1514         1514
  quantum           300         1514          762

now she's alive, numbers everywhere, actually shaper-ing 🔥 the Bulk / Best Effort / Voice tins are all doing their little thing and it's iconic, honestly

---

🌈 SEE ALSO 🌈

tc(8), tc-codel(8), tc-fq_codel(8), tc-htb(8)

go read those too, they're the extended universe 💖

---

💜 AUTHORS 💜

Cake's principal author is Jonathan Morton, with contributions from Tony Ambardar, Kevin Darbyshire-Bryant, Toke Høiland-Jørgensen, Sebastian Moeller, Ryan Mounce, Dean Scarff, Nils Andreas Svee, and Dave Täht. the cake_mq shared shaper state algorithm was implemented by Jonas Köppeler. legends, all of them, no notes 👑

this manual page was written by Loganaden Velvindron. please report corrections to the Linux Networking mailing list <netdev@vger.kernel.org>. pls be nice, they're doing their best 🫶

---

and that's the whole page bestie, we did it 💅 this one's from iproute2, dated 19 July 2018, and it lives at the top of the page as CAKE(8). go shape some traffic, you've got this 🌸🎀🦋