<div dir="ltr">Thanks Mathieu!<div><br></div><div>I think we should first merge Edouard's patch, which appears to be a prerequisite.</div><div>I think we could benefit a lot by applying this mechanism to process_network_ports.</div>
<div><br></div><div>However, I am not sure if there could be drawbacks arising from the fact that the agent would assign the local VLAN port (either the lvm id or the DEAD_VLAN tag) and then at the end of the iteration the flow modifications, such as the drop all rule, will be applied.</div>
<div>This will probably create a short interval of time in which we might have unexpected behaviours (such as VMs on DEAD VLAN able to communicate each other for instance).</div><div><br></div><div>I think we can generalize this discussion and use deferred application for ovs-vsctl as well.</div>
<div>Would you agree with that?</div><div><br></div><div>Thanks,</div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 7 January 2014 14:08, Mathieu Rohon <span dir="ltr"><<a href="mailto:mathieu.rohon@gmail.com" target="_blank">mathieu.rohon@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">I think that isaku is talking about a more intensive usage of<br>
defer_apply_on/off as it is done in the patch of gongysh [1].<br>
<br>
Isaku, i don't see any reason why this could not be done in<br>
precess_network_ports, if needed. Moreover the patch from edouard [2]<br>
resolves multithreading issues while precessing defer_apply_off.<br>
<br>
<br>
[1]<a href="https://review.openstack.org/#/c/61341/" target="_blank">https://review.openstack.org/#/c/61341/</a><br>
[2]<a href="https://review.openstack.org/#/c/63917/" target="_blank">https://review.openstack.org/#/c/63917/</a><br>
<div class="HOEnZb"><div class="h5"><br>
On Mon, Jan 6, 2014 at 9:24 PM, Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
> This thread is starting to get a bit confusing, at least for people with a<br>
> single-pipeline brain like me!<br>
><br>
> I am not entirely sure if I understand correctly Isaku's proposal concerning<br>
> deferring the application of flow changes.<br>
> I think it's worth discussing in a separate thread, and a supporting patch<br>
> will help as well; I think that in order to avoid unexpected behaviours,<br>
> vlan tagging on the port and flow setup should always be performed at the<br>
> same time; if we get a much better performance using a mechanism similar to<br>
> iptables' defer_apply, then we should it.<br>
><br>
> Regarding rootwrap. This 6x slowdown, while proving that rootwrap imposes a<br>
> non-negligible overhead, it should not be used as a sort of proof that<br>
> rootwrap makes things 6 times worse! What I've been seeing on the gate and<br>
> in my tests are ALRM_CLOCK errors raised by ovs commands, so rootwrap has<br>
> little to do with it.<br>
><br>
> Still, I think we can say that rootwrap adds about 50ms to each command,<br>
> becoming particularly penalising especially for 'fast' commands.<br>
> I think the best things to do, as Joe advices, a test with rootwrap disabled<br>
> on the gate - and I will take care of that.<br>
><br>
> On the other hand, I would invite community members picking up some of the<br>
> bugs we've registered for 'less frequent' failures observed during parallel<br>
> testing; especially if you're coming to Montreal next week.<br>
><br>
> Salvatore<br>
><br>
><br>
><br>
> On 6 January 2014 20:31, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>><br>
>> On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote:<br>
>> ><br>
>> ><br>
>> ><br>
>> > On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes <<a href="mailto:jaypipes@gmail.com">jaypipes@gmail.com</a>> wrote:<br>
>> >         On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote:<br>
>> ><br>
>> >         > What about it? Also those numbers are pretty old at this<br>
>> >         point. I was<br>
>> >         > thinking disable rootwrap and run full parallel tempest<br>
>> >         against it.<br>
>> ><br>
>> ><br>
>> >         I think that is a little overkill for what we're trying to do<br>
>> >         here. We<br>
>> >         are specifically talking about combining many utils.execute()<br>
>> >         calls into<br>
>> >         a single one. I think it's pretty obvious that the latter will<br>
>> >         be better<br>
>> >         performing than the first, unless you think that rootwrap has<br>
>> >         no<br>
>> >         performance overhead at all?<br>
>> ><br>
>> ><br>
>> > mocking out rootwrap with straight sudo, is a very quick way to<br>
>> > approximate the performance benefit of combining many utlils.execute()<br>
>> > calls together (at least rootwrap wise).  Also  it would tell us how<br>
>> > much of the problem is rootwrap induced and how much is other.<br>
>><br>
>> Yes, I understand that, which is what the article I linked earlier<br>
>> showed?<br>
>><br>
>> % time sudo ip link >/dev/null<br>
>> sudo ip link > /dev/null  0.00s user 0.00s system 43% cpu 0.009 total<br>
>> % sudo time quantum-rootwrap /etc/quantum/rootwrap.conf ip link<br>
>> > /dev/null<br>
>> quantum-rootwrap /etc/quantum/rootwrap.conf ip link  > /dev/null  0.04s<br>
>> user 0.02s system 87% cpu 0.059 total<br>
>><br>
>> A very tiny, non-scientific simple indication that rootwrap is around 6<br>
>> times slower than a simple sudo call.<br>
>><br>
>> Best,<br>
>> -jay<br>
>><br>
>><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>
><br>
><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>
<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>
</div></div></blockquote></div><br></div>