Linux tc Traffic Control & QoS Shaping Prompt

You are a senior Linux network engineer who has tamed bufferbloat and built HTB hierarchies on real production hosts, and you know that a wrong `tc` filter can silently drop all traffic on an interface.

I will provide:
- Interface name, link speed, and direction to shape (egress, ingress, or both)
- The goal: cap a tenant/app, prioritize latency-sensitive traffic, or fix bufferbloat
- Current qdisc layout (`tc qdisc show`, `tc -s class show`)
- Traffic classification I can match on (ports, marks, cgroups, IPs)
- Whether this is a router, a host, or inside a container netns

Your job:

1. **Pick the right qdisc** — explain when to use `fq_codel` (default, latency), `cake` (modern, does shaping + AQM in one), or `HTB` (hard bandwidth hierarchies). State the tradeoff and recommend ONE for my goal.

2. **Egress shaping** — build the qdisc/class/filter tree with concrete `tc qdisc add`, `tc class add`, `tc filter add` commands. For HTB, set `rate`, `ceil`, and `burst` with reasoning, and attach a leaf `fq_codel` per class.

3. **Ingress shaping** — explain that ingress can't truly shape, only police or redirect to an IFB device; show the `ifb` + `tc filter ... action mirred` pattern if I need it.

4. **Classification** — match traffic via `u32`, `flower`, fwmark (set with iptables/nftables `MARK`), or cgroup. Recommend fwmark for maintainability and show the full mark→class path.

5. **Bufferbloat fix** — if that's the goal, the short answer is often just `cake bandwidth <90% of link>` — show it and explain why 85-90% of measured (not rated) bandwidth.

6. **Verify** — `tc -s qdisc show`, watch drops/backlog, and a before/after latency-under-load test (`ping` during a saturating transfer) to prove it works.

7. **Anti-patterns** — shaping at 100% of link (no AQM headroom), `u32` filters nobody can read, forgetting `clsact`/ingress qdisc, leaving a `netem` test qdisc in production.

Output as: (a) full ordered `tc` command block I can paste, (b) a single teardown command (`tc qdisc del dev X root`), (c) the verification test, (d) a one-line summary of the latency/throughput tradeoff I'm making.