On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:
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.
yep, this is a technique to be pulled out only when needed, but it's worth
keeping in mind that you can mix this with the hardware if you don't need to do
this between every port, you can group ports into different VLANs and use the
CPU between them
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.
how much of this functionality is exposed in the currently common switch
chipsets?
I'm also wondering if the right answer for some of this could end up being a
butchered version of the kernel bridging code that maintains all the
configuration/state, but lets the hardware do the packet forwarding.
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.
I've seen references to openvswitch, but I was under the impression that it
didn't have any relationship with real hardware, it was just a way to
configure/manage logical switches for VMs
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.
I think a lot of it is that there just isn't a huge amount of overlap between
people who are experienced in dealing with complex wired environments and
OpenWRT. I've had a lot of people dismiss the though of using OpenWRT hardware
for things that they've traditionally used Cisco/HP switches for, but when
desperation has forced them to give it a try, they've been very pleased with the
results.
I'd love to see someone do a project with a small PC (Raspberry Pi or
equivalent) that could take the cheap 8 port switches and unlock the power in
the switch chipsets. I saw a post of someone who did this with an arduino, but
even that was just pipeing a canned config into it. With something able to run a
full software stack, lots of other things would become possible.
When you get your stuff working, I'd be very interested in knowing what switch
it is you are reprogramming.
David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
