[OpenWrt-Devel] General questions about the direction of switch drivers
david at lang.hm
Mon Feb 16 17:10:31 EST 2015
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
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
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
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.
openwrt-devel mailing list
openwrt-devel at lists.openwrt.org
More information about the openwrt-devel