Why Wi-Fi Bridging Breaks the Switch Model (And How WED Changes It)

By now, you might be comfortable with the idea that in Linux:

The bridge is the control plane. The switch is the dataplane.

And when everything is configured correctly, traffic flows in hardware and the CPU stays mostly idle.

Then Wi-Fi enters the picture — and everything falls apart.

Suddenly:

• CPU usage spikes
• latency increases
• throughput becomes inconsistent

So what happened?

Wi-Fi is not a switch.

And historically, it never behaved like one.

Why Wi-Fi Was Always Different

Ethernet switching is simple:

• full-duplex
• dedicated links
• predictable forwarding

Wi-Fi is none of that.

• shared medium (airtime, not bandwidth)
• contention-based access (CSMA/CA)
• frame aggregation and reordering

Even before Linux enters the picture, Wi-Fi already behaves differently at a fundamental level.

Trying to treat it like a switch port is where things start to go wrong.

The Classic Bottleneck: CPU in the Middle

In traditional designs, bridging Wi-Fi to Ethernet looks like this:

Wi-Fi → CPU → switch

The Linux bridge connects both worlds, but:

• the switch can offload Ethernet forwarding
• Wi-Fi traffic still needs CPU handling

This creates an imbalance:

LAN traffic flies. Wi-Fi traffic stalls.

And this is exactly what users experience.

Why The Bridge Cannot Fully Offload Wi-Fi

Even with DSA, the bridge cannot simply push Wi-Fi traffic into the switch fabric.

Because Wi-Fi:

• does not expose a standard Ethernet dataplane
• uses its own QoS system (WMM)
• requires per-station handling

So the CPU remains involved.

Not because Linux is inefficient — but because the hardware model is fundamentally different.

Enter WED: Changing the Datapath

This is where things get interesting.

Modern SoCs, especially from MediaTek, introduced mechanisms like WED (Wireless Ethernet Dispatch).

Instead of forcing all traffic through the CPU, WED allows:

• DMA-based packet forwarding
• direct interaction between Wi-Fi and Ethernet datapaths
• reduced CPU involvement

The datapath starts to look more like this:

Wi-Fi → DMA → switch / PPE

This is not full hardware switching — but it is a massive improvement.

So Is Wi-Fi Now “Just Another Switch Port”?

Not quite.

Even with WED:

• MAC learning is still different
• control paths still involve the CPU
• feature support is limited compared to switches

WED accelerates the datapath.

It does not turn Wi-Fi into a true Layer 2 switch.

Why This Matters For Real Networks

This explains a lot of real-world behavior:

• why Wi-Fi bridging used to saturate CPUs
• why newer devices perform much better
• why some configurations still break performance

It also explains why blindly applying “switch logic” to Wi-Fi often fails.

RouterWRT’s Approach

RouterWRT does not assume all interfaces behave the same.

Instead:

• Ethernet is treated as switch fabric
• Wi-Fi is treated as a separate domain
• offload is used where it actually exists

The goal is not to pretend everything is identical.

It is to make different technologies work together efficiently.

Conclusion

Wi-Fi bridging has always been the weak point in the “bridge equals switch” mental model.

Historically, it forced traffic through the CPU and limited performance.

New technologies like WED are changing that by moving parts of the datapath back into hardware.

But the fundamental difference remains:

Wi-Fi is not a switch — even if it’s getting closer.

Understanding that difference is key to building fast, predictable networks on modern Linux-based routers.