[OpenWrt-Devel] General questions about the direction of switch drivers

Charlie Smurthwaite charlie at atechmedia.com
Mon Feb 16 16:32:01 EST 2015

Hi David,

On 16/02/15 21:03, David Lang wrote:
> A work-around for many of the items other than the basic VLAN 
> membership and tagging is to force the traffic between the different 
> switch ports to go through the CPU by putting the different ports on 
> different VLANs and then using the kernel bridging/firewalling/etc 
> features. You can't do this between switch ports that are trunked 
> (exposeing the VLAN tags), but other than the cpu load and admin 
> confusion, it works very well to just do this in the kernel. How much 
> of the "functions that requrie active involvement of the CPU" end up 
> being a variation of this?
It can certainly be done this way. In fact with my current driver, I 
could give every port on the switch a different VLAN, tag them all on 
the CPU port, and do all the real work in the kernel. However this has 
one serious drawback: poor throughput. A hardware switch can easily do 
multiple Gbps, whereas the CPU can probably only handle a couple of 
hundred Mbps.

With regard to "functions that requrie active involvement of the CPU", 
this is where it gets interesting. There is a huge difference in 
performance between the kernel managing the switch's MAC address table 
(telling it which port to send a particular destination MAC address to), 
or having the CPU manage the STP port status, and caching that for a 
period of time vs sending all the packets in full through the CPU.

> I am curious as to what other switch device frameworks are out there.
Specifically, there is the new "switchdev" framework which I was 
recommended to look at, and looks good, but doesn't seem to be used much 
yet, and also openvswitch, which is a little different, but may be an 
option for some purposes.
> It's worth noting that the vast majority of OpenWRT devices have a 
> single switch in them, and that switch is typically not the fanciest 
> (although the march of technology mens that every year it's going to 
> be better than it used to be)
My thought is that the switch chips in devices are quickly improving, 
with many supporting a lot of functionality that currently goes unused. 
I understand this is often because it's unnecessary in a home/office 
router, or a primarily wireless device, but I think OpenWrt is a great 
platform and a great base to work on these primarily wired devices as well.
> David Lang
Thanks :)

openwrt-devel mailing list
openwrt-devel at lists.openwrt.org

More information about the openwrt-devel mailing list