<div dir="ltr"><div class="gmail_default" style="font-family:verdana,sans-serif">I for one would love to see brctl and vconfig disappear completely in favour of ovs-* based standard toolchain for all switch interaction.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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.</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">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?</div><div class="gmail_default" style="font-family:verdana,sans-serif"><br></div><div class="gmail_default" style="font-family:verdana,sans-serif">-Joel</div></div><div class="gmail_extra"><br><div class="gmail_quote">On 16 February 2015 at 16:04, Michael Richardson <span dir="ltr"><<a href="mailto:mcr@sandelman.ca" target="_blank">mcr@sandelman.ca</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
First, there are a lot of discussions and papers at <a href="http://netdev01.org" target="_blank">netdev01.org</a> about the<br>
various hardware switch management systems. I point specifically to a talk<br>
this morning:<br>
<a href="https://www.netdev01.org/sessions/19" target="_blank">https://www.netdev01.org/sessions/19</a><br>
<br>
I have stumbed my toe on 3800 with trying to build tagged switch ports where<br>
I have a few ports with explicit VLAN tagging, joined together in the switch,<br>
and also exposed to the host. I think it should work, but I mostly just wound<br>
up screwing up my CPU port. I have some 3800 with serial consoles now so I<br>
should try this out.<br>
<br>
What would be ideal, and my impression is that this is where the industry<br>
wants to go, is that one would use brctl and vconfig to build the switch<br>
configuration that you want, and the drivers below would realize that the<br>
switch can do that work, and would program things correctly.<br>
<br>
openvswitch is about creating a virtual switch fabric in the CPU, which can<br>
spread elsewhere --- the trend is though, that this too would be subject to<br>
hardware offload.<br>
<br>
--<br>
] Never tell me the odds! | ipv6 mesh networks [<br>
] Michael Richardson, Sandelman Software Works | network architect [<br>
] <a href="mailto:mcr@sandelman.ca">mcr@sandelman.ca</a> <a href="http://www.sandelman.ca/" target="_blank">http://www.sandelman.ca/</a> | ruby on rails [<br>
<div class="HOEnZb"><div class="h5">_______________________________________________<br>
openwrt-devel mailing list<br>
<a href="mailto:openwrt-devel@lists.openwrt.org">openwrt-devel@lists.openwrt.org</a><br>
<a href="https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel" target="_blank">https://lists.openwrt.org/cgi-bin/mailman/listinfo/openwrt-devel</a><br>
</div></div></blockquote></div><br></div>