Having a more abstract way of managing this available is a nice option to have,
but I would hate to loose the ability to set things explicitly.
Keeping in mind that we are primarily dealing with low-end devices, anything
that requires more advanced chipsets just isn't going to happen. The chipsets
will progress, but what gets put into the APs is going to be the cheapest swtich
chipset that will do the job of a dumb switch. The fact that this cheapest
chipset also happens to be able to do a lot more is a very nice bonus for us.
Remember that the vendors want to also offer the "Enterprise" APs with the
advanced capabilities.
David Lang
On Mon, 16 Feb 2015, Joel Wirāmu Pauling wrote:
I for one would love to see brctl and vconfig disappear completely in
favour of ovs-* based standard toolchain for all switch interaction.
Certainly in the Bigger iron area, and things like core and cumulus coupled
with SDN approaches and Openstack this is fast becoming defacto. I don't
see why with a bit of additional abstraction that ovs couldn't become the
default stack for mainline and certainly for OpenWRT it offers a lot more
versatility than the current brctl and vconfig tools.
I guess the biggest issue is getting ovs- offload to switch chipsets rather
than CPU bound softswitch. Maybe some sort of flag where unsupported
operations/modes which would end up being done on the CPU are
flagged/masked?
_______________________________________________
openwrt-devel mailing list
openwrt-devel@lists.openwrt.org
https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel
