[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 :)
Charlie
_______________________________________________
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
More information about the openwrt-devel
mailing list