<div dir="ltr">







<p class=""><span class="">Guys, it's a big and complicated architecture issue. </span></p>
<p class=""><span class="">Issue, like this was carefully researched about month ago (while P***)</span></p>
<p class=""><span class="">root case of issue:</span></p>
<ul class="">
<li class=""><span class="">Now we use OVS for build virtual network topology on each node. </span></li>
<li class=""><span class="">OVS has performance degradation while pass huge of small network packets.</span></li>
<li class=""><span class="">We can’t abandon using OVS entirely and forever, because it's a most popular Neutron solution. </span></li>
<li class=""><span class="">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"><span class="">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 class=""><span class="">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 class="">
<li class=""><span class="">vm-to-vm speed (on different compute nodes): 2.56 Gbits/sec (GRE segmentation)</span></li>
<li class=""><span class="">node-to-node speed: 17.6 Gbits/s</span></li>
</ul>
<p class=""><span class="">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/"><span class="">http://networkheresy.com/2014/11/13/accelerating-open-vswitch-to-ludicrous-speed/</span></a>).</span></p>
<p class=""><span class=""></span><br></p>
<p class=""><span class="">After this research we concluded:</span></p>
<p class=""></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 class=""><span class=""></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>