<div dir="ltr">I have already discussed the matter with Jay on IRC, even if for a different issue.<div>In this specific case 'batching' will have the benefit of reducing the rootwrap overhead.</div><div><br></div><div>
However, it seems the benefit from batching is not resolutive. I admit I have not run tests in the gate with batching; I've just tested in an environment without significant load, obtaining a performance increase of less than 10%.</div>
<div><br></div><div>From what I gathered even if commands are 'batched' to ovs-vsctl, operations are still individually performed on the kernel module. I did not investigate whether the cli commands sends a single or multiple commands on the ovsdb interface.</div>
<div>Nevertheless, another thing to note is that it's not just ovs-vsctl that becomes very slow, but also, and more often than that, ovs-ofctl, for which there is no batching.</div><div><br></div><div>Summarising, I'm not opposed to batching for ovs-vsctl, and I would definitely welcome it; I just don't think it will be the ultimate solution.</div>
<div><br></div><div>Salvatore</div></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 6 January 2014 11:40, Isaku Yamahata <span dir="ltr"><<a href="mailto:isaku.yamahata@gmail.com" target="_blank">isaku.yamahata@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">On Fri, Dec 27, 2013 at 11:09:02AM +0100,<br>
<div class="im">Salvatore Orlando <<a href="mailto:sorlando@nicira.com">sorlando@nicira.com</a>> wrote:<br>
<br>
> Hi,<br>
><br>
</div><div><div class="h5">> We now have several patches under review which improve a lot how neutron<br>
> handles parallel testing.<br>
> In a nutshell, these patches try to ensure the ovs agent processes new,<br>
> removed, and updated interfaces as soon as possible,<br>
><br>
> These patches are:<br>
> <a href="https://review.openstack.org/#/c/61105/" target="_blank">https://review.openstack.org/#/c/61105/</a><br>
> <a href="https://review.openstack.org/#/c/61964/" target="_blank">https://review.openstack.org/#/c/61964/</a><br>
> <a href="https://review.openstack.org/#/c/63100/" target="_blank">https://review.openstack.org/#/c/63100/</a><br>
> <a href="https://review.openstack.org/#/c/63558/" target="_blank">https://review.openstack.org/#/c/63558/</a><br>
><br>
> There is still room for improvement. For instance the calls from the agent<br>
> into the plugins might be consistently reduced.<br>
> However, even if the above patches shrink a lot the time required for<br>
> processing a device, we are still hitting a hard limit with the execution<br>
> ovs commands for setting local vlan tags and clearing flows (or adding the<br>
> flow rule for dropping all the traffic).<br>
> In some instances this commands slow down a lot, requiring almost 10<br>
> seconds to complete. This adds a delay in interface processing which in<br>
> some cases leads to the hideous SSH timeout error (the same we see with bug<br>
> 1253896 in normal testing).<br>
> It is also worth noting that when this happens sysstat reveal CPU usage is<br>
> very close to 100%<br>
><br>
> From the neutron side there is little we can do. Introducing parallel<br>
> processing for interface, as we do for the l3 agent, is not actually a<br>
> solution, since ovs-vswitchd v1.4.x, the one executed on gate tests, is not<br>
> multithreaded. If you think the situation might be improved by changing the<br>
> logic for handling local vlan tags and putting ports on the dead vlan, I<br>
> would be happy to talk about that.<br>
<br>
</div></div>How about batching those ovsdb operations?<br>
Instead of issueing many ovs-vsctl command,<br>
ovs-vsctl -- command0 [args] -- command1 [args] -- ...<br>
<br>
Then, the number of ovs-vsctl will be reduced and ovs-vsctl issues<br>
only single ovsdb transaction.<br>
<span class="HOEnZb"><font color="#888888">--<br>
Isaku Yamahata <<a href="mailto:isaku.yamahata@gmail.com">isaku.yamahata@gmail.com</a>><br>
</font></span><div class="HOEnZb"><div class="h5"><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>