Modern Linux Router Architecture (Without the Myths)

Linux networking is often described using clean, simple concepts:

• a switch forwards packets
• a bridge connects interfaces
• a router moves traffic between networks

That model is technically correct.

And completely misleading once you work with real hardware.

Modern Linux routers are not built from clean layers. They are built from interacting subsystems — and the performance depends on how well those subsystems align.

This article explains that system without the usual myths.

The Two Planes: Control vs Dataplane

The most important distinction is this:

• Control plane → Linux (bridge, routing, policy)
• Dataplane → hardware (switch, NIC, Wi-Fi)

Linux decides what should happen.

The hardware decides how fast it happens.

If those two don’t align, performance collapses.

DSA Changed the Model — Not the Hardware

With DSA, Linux moved to a cleaner abstraction:

[NIC] ⇄ [CPU port] ⇄ [Switch]

The bridge now describes topology.

The switch executes forwarding.

This looks simple.

But it introduces a critical detail:

The CPU port becomes the bottleneck.

The CPU Port Is the Real Critical Path

All traffic that cannot be switched in hardware passes through the CPU:

• routing
• Wi-Fi bridging
• firewalling
• policy decisions

If this path is inefficient:

• latency increases
• throughput drops
• QoS becomes unstable

This is why NIC design suddenly matters in a DSA world.

Why Multi-Queue Alone Is Not Enough

A common assumption is that more queues solve performance problems.

They don’t.

If all traffic is mixed together, you still get:

head-of-line blocking.

The solution is structural:

• separate traffic by topology
• then distribute by flow

This mirrors how hardware switches operate.

QoS Only Works If Everything Agrees

QoS in Linux spans multiple systems:

• DSCP (IP layer)
• switch CoS queues
• Wi-Fi WMM
• NIC queues

If these are not aligned, QoS becomes unpredictable.

The only model that works consistently is:

map everything into the same 4 traffic classes.

Once aligned:

• hardware queues behave correctly
• Wi-Fi prioritization matches wired
• offload paths preserve intent

Why Wi-Fi Breaks the Model

Ethernet switching is deterministic.

Wi-Fi is not.

It introduces:

• shared medium (airtime)
• contention
• different QoS model (WMM)

This is why Wi-Fi historically forced traffic through the CPU.

Newer technologies like WED reduce this cost — but do not eliminate the difference.

Flow Offload: Speed vs Control

Flow offload exists to reduce CPU load.

It works by bypassing parts of the networking stack.

This improves throughput.

But it also means:

software QoS is bypassed.

What remains is hardware QoS.

This reinforces a key idea:

classification must survive offload.

Why SQM Doesn’t Scale

Software queue management (CAKE, fq_codel) is powerful.

But it relies on:

• per-flow state
• per-packet decisions

At high speeds — or on weak CPUs — this becomes too expensive.

Datacenters solve this differently:

• simple classification
• hardware queues
• predictable scheduling

Less flexible.

But scalable.

The Real Design Principle

All of this leads to a simple rule:

Don’t fight the hardware. Align with it.

That means:

• use the bridge as control plane
• let the switch forward packets
• structure CPU traffic carefully
• align QoS across all layers
• avoid unnecessary software work

Conclusion

Modern Linux router architecture is not about adding features.

It is about removing friction between layers.

The system works best when:

• hardware does the forwarding
• software defines the policy
• both agree on how traffic is classified

Once that alignment is achieved, performance is no longer a mystery.

It becomes predictable.

And that is what good router design is really about.