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