On Mon, 16 Feb 2015, Charlie Smurthwaite wrote:
I'm writing a driver for a family of 24 port gigabit switches, with a
wide array of interesting hardware features. Creating basic VLAN
membership and tagging functionality under the swconfig framework has
been quite easy, and this framework has been excellent for this.
However, I would like to support a lot more of the functionality of this
hardware, and see other devices with advanced layer2 and layer3
switching supported in the future, so I wanted some opinion on the
direction things are taking.
Specifically I am looking for opinion on whether the swconfig framework
is suitable for more advanced functionality, or whether there was likely
to be a move to any other upstream framework for switch devices,
particularly those with more advanced functionality. The types of
functionality I am currently interested in supporting are:
* VLAN membership an tagging
* Packet and byte counters
* Security settings and filtering rules
* STP
* Layer 3 functionality (hardware IPv4 and IPv6 routing tables)
* Hardware NAT / firewall
Some of this functionality may simply require configuration, where other
functions require the active involvement of the CPU.
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?
I am curious as to what other switch device frameworks are out there.
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)
David Lang
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel