<!DOCTYPE html PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN" "http://www.w3.org/TR/REC-html40/loose.dtd">
<html><body>
<span id="mailbox-conversation"></span><br><br><span class="none"><div id="orc-email-signature" style="display: block;">
<br><div class="mailbox_signature">---<br>Raghu V. Vadapalli<br>Principal Software Architect <br>Smart Packet Solutions</div>
</div>
<span id="orc-full-body-initial-text" style="display: inline;"><br>On Monday, Sep 29, 2014 at 1:33 PM, NAPIERALAMARIA H <<a href="mailto:mn1921@att.com" target="_blank">mn1921@att.com</a>>, wrote:<br></span><blockquote class="gmail_quote"><font face="Courier New" size="2"><span style="font-size:10pt;">
<div>On 27.09.2014 06:37, Jason Kölker wrote:</div>
<div>>> On Sat, Sep 27, 2014 at 3:50 AM, Raghu Vadapalli <rvatspac...@gmail.com> </div>
<div>>> wrote:</div>
<div>>>> As per this news article listed below, Rackspace is abandoning Open vSwitch.</div>
<div>>>> Is this where everyone else going in general ?</div>
<div>>> </div>
<div>>> That conclusion is inaccurate. The entirety of the public cloud runs</div>
<div>>> openvswitch for both public/servicenet connectivity as well as</div>
<div>>> isolated tenant network features.The article is referring to the</div>
<div>>> private cloud distribution no longer choosing to use the Neutron</div>
<div>>> OpenVswitch plugin</div>
<div>>> (<a href="https://github.com/openstack/neutron/tree/master/neutron/plugins/openvswitch"><font color="blue"><u>https://github.com/openstack/neutron/tree/master/neutron/plugins/openvswitch</u></font></a>)</div>
<div>>> as it is being deprecated. The ML2 plugin replaces this and can use a</div>
<div>>> variety of mechanisms including openvswitch.</div>
<div>>> </div>
<div>>> The article's conclusion that openvswitch is not ready for production</div>
<div>>> and high-volume workloads is ludicrous. Versions 2.0+ perform very</div>
<div>>> well with multithreading in the vswitchd process and megaflows in the</div>
<div>>> datapath. However it is important to point out that datapath</div>
<div>>> performance is very much related to the flows programmed. A poorly</div>
<div>>> written flow set will result in bad performance. Tuning the flows and</div>
<div>>> optimizing the ability for megaflow'ing is the key to high throughput.</div>
<div> </div>
<div>> That's the theory though and the article seems to talk about practical</div>
<div>> problem Rackspace ran into with OVS so it would have been nice to learn</div>
<div>> what specifically was the problem.</div>
<div> </div>
<div>> What are the alternatives though? As far as I know the regular linux</div>
<div>> bridge lacks most of the features of OVS and these are the only to</div>
<div>> options I've played with so far. Is the a third alternative out there</div>
<div>> that they've switched to?</div>
<div> </div>
<div>One alternative is OpenContrail vRouter as ML3 plugin. It meets the scale and feature requirements.</div>
<div> </div>
<div>Maria</div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"> </span></font></div>
<div></div></span></font></blockquote>
<span class="mailbox-inline-edit">did you</span><span style="-webkit-tap-highlight-color: transparent;"> mean to say contrail with ML2 not ML3 ? I am not quite sure contrail integration but is ml3 available in icehouse yet ?</span><div><blockquote class="gmail_quote"><font face="Courier New" size="2"><span style="font-size:10pt;"><div><font face="Calibri" size="2"><span style="font-size:11pt;"><br></span></font></div>
<div><font face="Calibri" size="2"><span style="font-size:11pt;"> </span></font></div>
</span></font></blockquote></div></span>
</body></html>