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@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
