<html><head><meta http-equiv="Content-Type" content="text/html charset=utf-8"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space;" class=""><div class=""><br class=""></div><div class="">Sharing thoughts that I was having:</div><div class=""><br class=""></div><div class="">May be during the next summit it’s worth discussing the future of the </div><div class="">reference agent(s), I feel we’ll be replicating a lot of work across </div><div class="">OVN/OVS/RYU(ofagent) and may be other plugins,</div><div class=""><br class=""></div><div class="">I guess until OVN and it’s integration are ready we can’t stop, so it makes</div><div class="">sense to keep development at our side, also having an independent plugin</div><div class="">can help us iterate faster for new features, yet I expect that OVN will be</div><div class="">more fluent at working with OVS and OpenFlow, as their designers have</div><div class="">a very deep knowledge of OVS under the hood, and it’s C. ;)</div><div class=""><br class=""></div><div class="">Best regards,</div><div class=""><br class=""></div><div><blockquote type="cite" class=""><div class="">On 26/2/2015, at 7:57, Miguel Ángel Ajo <<a href="mailto:majopela@redhat.com" class="">majopela@redhat.com</a>> wrote:</div><br class="Apple-interchange-newline"><div class="">
                <div class=""><span style="color: rgb(160, 160, 168);" class="">On Thursday, 26 de February de 2015 at 7:48, Miguel Ángel Ajo wrote:</span></div>
                <blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;" class="">
                    <span class="">
                Inline comments follow after this, but I wanted to respond to Brian questionwhich has been cut out:<br class="">We’re talking here of doing a preliminary analysis of the networking performance,before writing any real code at neutron level.<div class=""><br class=""></div>If that looks right, then we should go into a preliminary (and orthogonal to iptables/LB)implementation. At that moment we will be able to examine the scalability of the solutionin regards of switching openflow rules, which is going to be severely affectedby the way we use to handle OF rules in the bridge:<br class="">   * via OpenFlow, making the agent a “real" OF controller, with the current effort to use      the ryu framework plugin to do that.   * via cmdline (would be alleviated with the current rootwrap work, but the former one     would be preferred).<br class="">Also, ipset groups can be moved into conjunctive groups in OF (thanks Ben Pfaff for theexplanation, if you’re reading this ;-))<br class="">Best,Miguel Ángel<br class=""><br class=""><div class=""><span style="color: rgb(160, 160, 168);" class=""><br class=""></span></div><div class=""><span style="color: rgb(160, 160, 168);" class="">On Wednesday, 25 de February de 2015 at 20:34, Tapio Tallgren wrote:</span></div><blockquote type="cite" class=""><div class="">
                    <span class=""><div class=""><div class=""><div dir="ltr" class="">Hi,<div class=""><br class=""></div><div class="">The RFC2544 with near zero packet loss is a pretty standard performance benchmark. It is also used in the OPNFV project (<a href="https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases" class="">https://wiki.opnfv.org/characterize_vswitch_performance_for_telco_nfv_use_cases</a>).</div><div class=""><br class=""></div><div class="">Does this mean that OpenStack will have stateful firewalls (or security groups)? Any other ideas planned, like ebtables type filtering?</div><div class=""><br class=""></div></div></div></div></span></div></blockquote>What I am proposing is in the terms of maintaining the statefulness we have nowregards security groups (RELATED/ESTABLISHED connections are allowed back on open ports) while adding a new firewall driver working only with OVS+OF (no iptables or linux bridge).<br class=""><div class="">That will be possible (without auto-populating OF rules in oposite directions) due to</div><div class="">the new connection tracker functionality to be eventually merged into ovs.</div><div class=""> </div><blockquote type="cite" class=""><div class=""><span class=""><div class=""><div class=""><div dir="ltr" class=""><div class="">-Tapio</div></div><div class=""><br class=""><div class="">On Wed, Feb 25, 2015 at 5:07 PM, Rick Jones <span dir="ltr" class=""><<a href="mailto:rick.jones2@hp.com" target="_blank" class="">rick.jones2@hp.com</a>></span> wrote:<br class=""><blockquote type="cite" class=""><div class=""><div class=""><div class="">On 02/25/2015 05:52 AM, Miguel Ángel Ajo wrote:<br class=""><blockquote type="cite" class=""><div class="">
I’m writing a plan/script to benchmark OVS+OF(CT) vs<br class="">
OVS+LB+iptables+ipsets,<br class="">
so we can make sure there’s a real difference before jumping into any<br class="">
OpenFlow security group filters when we have connection tracking in OVS.<br class="">
<br class="">
The plan is to keep all of it in a single multicore host, and make<br class="">
all the measures within it, to make sure we just measure the<br class="">
difference due to the software layers.<br class="">
<br class="">
Suggestions or ideas on what to measure are welcome, there’s an initial<br class="">
draft here:<br class="">
<br class="">
<a href="https://github.com/mangelajo/ovs-experiments/tree/master/ovs-ct" target="_blank" class="">https://github.com/mangelajo/<u class=""></u>ovs-experiments/tree/master/<u class=""></u>ovs-ct</a><br class="">
</div></blockquote><br class=""></div></div>
Conditions to be benchmarked<br class="">
<br class="">
    Initial connection establishment time<br class="">
    Max throughput on the same CPU<br class="">
<br class="">
Large MTUs and stateless offloads can mask a multitude of path-length sins.  And there is a great deal more to performance than Mbit/s. While some of that may be covered by the first item via the likes of say netperf TCP_CRR or TCP_CC testing, I would suggest that in addition to a focus on Mbit/s (which I assume is the focus of the second item) there is something for packet per second performance.  Something like netperf TCP_RR and perhaps aggregate TCP_RR or UDP_RR testing.<br class="">
<br class="">
Doesn't have to be netperf, that is simply the hammer I wield :)<br class="">
<br class="">
What follows may be a bit of perfect being the enemy of the good, or mission creep...<br class="">
<br class="">
On the same CPU would certainly simplify things, but it will almost certainly exhibit different processor data cache behaviour than actually going through a physical network with a multi-core system.  Physical NICs will possibly (probably?) have RSS going, which may cause cache lines to be pulled around.  The way packets will be buffered will differ as well.  Etc etc.  How well the different solutions scale with cores is definitely a difference of interest between the two sofware layers.<span class=""><font color="#888888" class=""><br class="">
<br class=""></font></span></div></blockquote></div></div></div></div></span></div></blockquote></span></blockquote><div class=""><br class=""></div><div class=""><br class=""></div><div class=""><span style="font-size: 14px;" class="">Hi rick, thanks for your feedback here, I’ll take it into consideration, </span></div><div class=""><span style="font-size: 14px;" class="">specially about the small packet pps measurements, and</span></div><div class="">really using physical hosts.</div><div class=""><br class=""></div><div class="">Although I may start with an AIO setup for simplicity, we should</div><div class="">get more conclusive results from at least two hosts and decent NICs.</div><div class=""><br class=""></div><div class="">I will put all this together in the document, and loop you in for review. </div><blockquote type="cite" style="border-left-style:solid;border-width:1px;margin-left:0px;padding-left:10px;" class=""><span class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><span class=""><div class=""><div class=""><div class=""><div class=""><blockquote type="cite" class=""><div class=""><span class=""><font color="#888888" class="">
rick</font></span><div class=""><div class=""><br class="">
<br class="">
______________________________<u class=""></u>______________________________<u class=""></u>______________<br class="">
OpenStack Development Mailing List (not for usage questions)<br class="">
Unsubscribe: <a href="http://OpenStack-dev-request@lists.openstack.org/?subject:unsubscribe" target="_blank" class="">OpenStack-dev-request@lists.<u class=""></u>openstack.org?subject:<u class=""></u>unsubscribe</a><br class="">
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank" class="">http://lists.openstack.org/<u class=""></u>cgi-bin/mailman/listinfo/<u class=""></u>openstack-dev</a><br class="">
</div></div></div></blockquote></div><br class=""><br clear="all" class=""><div class=""><br class=""></div>-- <br class=""><div class="">-Tapio</div>
</div>
</div><div class=""><div class="">__________________________________________________________________________</div><div class="">OpenStack Development Mailing List (not for usage questions)</div><div class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
                  
                  
                  
                  
                </div></blockquote><div class="">
                    <br class="">
                </div>
            </div><div class=""><div class="">__________________________________________________________________________</div><div class="">OpenStack Development Mailing List (not for usage questions)</div><div class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org?subject:unsubscribe" class="">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a></div><div class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a></div></div></div></span>
                 
                 
                 
                 
                </blockquote>
                 
                <div class="">
                    <br class="">
                </div>
            __________________________________________________________________________<br class="">OpenStack Development Mailing List (not for usage questions)<br class="">Unsubscribe: <a href="mailto:OpenStack-dev-request@lists.openstack.org" class="">OpenStack-dev-request@lists.openstack.org</a>?subject:unsubscribe<br class=""><a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" class="">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br class=""></div></blockquote></div><br class=""><div class="">
<div class="">Miguel Angel Ajo</div><div class=""><br class=""></div><br class="Apple-interchange-newline">

</div>
<br class=""></body></html>