<p dir="ltr">+1 we need more net testing pre deployment to recommend usable network settings the first time. Settings like mtu gro gso need to be considered too  </p>
<div class="gmail_quote">On Dec 16, 2014 8:30 AM, "Sergey Vasilenko" <<a href="mailto:svasilenko@mirantis.com">svasilenko@mirantis.com</a>> wrote:<br type="attribution"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div dir="ltr">







<p><span>Guys, it's a big and complicated architecture issue. </span></p>
<p><span>Issue, like this was carefully researched about month ago (while P***)</span></p>
<p><span>root case of issue:</span></p>
<ul>
<li><span>Now we use OVS for build virtual network topology on each node. </span></li>
<li><span>OVS has performance degradation while pass huge of small network packets.</span></li>
<li><span>We can’t abandon using OVS entirely and forever, because it's a most popular Neutron solution. </span></li>
<li><span>We can’t abandon using OVS partial now, because low-level modules don’t ready yet for this. I start blueprint (<a href="https://blueprints.launchpad.net/fuel/+spec/l23network-refactror-to-provider-based-resources" target="_blank"><span>https://blueprints.launchpad.net/fuel/+spec/l23network-refactror-to-provider-based-resources</span></a>) for aim possibility of combine using OVS for Neutron purposes and don't use it for management, storage, etc... purposes. </span></li></ul>
<p><span>We, together with L2 support team, Neutron team, and another network experts make tuning one of existing production-like env after deployment and achieve following values on bonds of two 10G cards:</span></p>
<ul>
<li><span>vm-to-vm speed (on different compute nodes): 2.56 Gbits/sec (GRE segmentation)</span></li>
<li><span>node-to-node speed: 17.6 Gbits/s</span></li>
</ul>
<p><span>This values closely near with theoretical maximum for OVS 1.xx with GRE. Some performance improvements may also achieved by upgrading open vSwitch to the latest LTS (2.3.1 at this time) branch and using "megaflow" feature (<a href="http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/" target="_blank"><span>http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/</span></a>).</span></p>
<p><span></span><br></p>
<p><span>After this research we concluded:</span></p>
<p></p><ul><li>OVS can't pass huge of small packages without network performance degradation<br></li><li>for fix this we should re-design network topology on env nodes<br></li><li>even re-designed network topology can't fix this issue at all. Some network parameters, like mtu, disabling offloading for NICs, buffers, etc... can be tuned only on real environment. <br></li></ul><p></p>


<p><span></span><br></p>
<div>My opinion — in FUEL we should add new (or extend existing network-checker) component.  This component should testing network performance on real customer’s pre-configured env by different (already defined) performance test cases and recommend better setup BEFORE main deployment cycle run. </div><div><br></div><div>/sv</div></div>
<br>_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div>