[openstack-dev] [Neutron][qa] Parallel testing update

Salvatore Orlando sorlando at nicira.com
Tue Jan 7 13:34:24 UTC 2014


Thanks Mathieu!

I think we should first merge Edouard's patch, which appears to be a
prerequisite.
I think we could benefit a lot by applying this mechanism to
process_network_ports.

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.
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).

I think we can generalize this discussion and use deferred application for
ovs-vsctl as well.
Would you agree with that?

Thanks,
Salvatore


On 7 January 2014 14:08, Mathieu Rohon <mathieu.rohon at gmail.com> wrote:

> I think that isaku is talking about a more intensive usage of
> defer_apply_on/off as it is done in the patch of gongysh [1].
>
> Isaku, i don't see any reason why this could not be done in
> precess_network_ports, if needed. Moreover the patch from edouard [2]
> resolves multithreading issues while precessing defer_apply_off.
>
>
> [1]https://review.openstack.org/#/c/61341/
> [2]https://review.openstack.org/#/c/63917/
>
> On Mon, Jan 6, 2014 at 9:24 PM, Salvatore Orlando <sorlando at nicira.com>
> wrote:
> > This thread is starting to get a bit confusing, at least for people with
> a
> > single-pipeline brain like me!
> >
> > I am not entirely sure if I understand correctly Isaku's proposal
> concerning
> > deferring the application of flow changes.
> > I think it's worth discussing in a separate thread, and a supporting
> patch
> > will help as well; I think that in order to avoid unexpected behaviours,
> > vlan tagging on the port and flow setup should always be performed at the
> > same time; if we get a much better performance using a mechanism similar
> to
> > iptables' defer_apply, then we should it.
> >
> > Regarding rootwrap. This 6x slowdown, while proving that rootwrap
> imposes a
> > non-negligible overhead, it should not be used as a sort of proof that
> > rootwrap makes things 6 times worse! What I've been seeing on the gate
> and
> > in my tests are ALRM_CLOCK errors raised by ovs commands, so rootwrap has
> > little to do with it.
> >
> > Still, I think we can say that rootwrap adds about 50ms to each command,
> > becoming particularly penalising especially for 'fast' commands.
> > I think the best things to do, as Joe advices, a test with rootwrap
> disabled
> > on the gate - and I will take care of that.
> >
> > On the other hand, I would invite community members picking up some of
> the
> > bugs we've registered for 'less frequent' failures observed during
> parallel
> > testing; especially if you're coming to Montreal next week.
> >
> > Salvatore
> >
> >
> >
> > On 6 January 2014 20:31, Jay Pipes <jaypipes at gmail.com> wrote:
> >>
> >> On Mon, 2014-01-06 at 11:17 -0800, Joe Gordon wrote:
> >> >
> >> >
> >> >
> >> > On Mon, Jan 6, 2014 at 10:35 AM, Jay Pipes <jaypipes at gmail.com>
> wrote:
> >> >         On Mon, 2014-01-06 at 09:56 -0800, Joe Gordon wrote:
> >> >
> >> >         > What about it? Also those numbers are pretty old at this
> >> >         point. I was
> >> >         > thinking disable rootwrap and run full parallel tempest
> >> >         against it.
> >> >
> >> >
> >> >         I think that is a little overkill for what we're trying to do
> >> >         here. We
> >> >         are specifically talking about combining many utils.execute()
> >> >         calls into
> >> >         a single one. I think it's pretty obvious that the latter will
> >> >         be better
> >> >         performing than the first, unless you think that rootwrap has
> >> >         no
> >> >         performance overhead at all?
> >> >
> >> >
> >> > mocking out rootwrap with straight sudo, is a very quick way to
> >> > approximate the performance benefit of combining many utlils.execute()
> >> > calls together (at least rootwrap wise).  Also  it would tell us how
> >> > much of the problem is rootwrap induced and how much is other.
> >>
> >> Yes, I understand that, which is what the article I linked earlier
> >> showed?
> >>
> >> % time sudo ip link >/dev/null
> >> sudo ip link > /dev/null  0.00s user 0.00s system 43% cpu 0.009 total
> >> % sudo time quantum-rootwrap /etc/quantum/rootwrap.conf ip link
> >> > /dev/null
> >> quantum-rootwrap /etc/quantum/rootwrap.conf ip link  > /dev/null  0.04s
> >> user 0.02s system 87% cpu 0.059 total
> >>
> >> A very tiny, non-scientific simple indication that rootwrap is around 6
> >> times slower than a simple sudo call.
> >>
> >> Best,
> >> -jay
> >>
> >>
> >> _______________________________________________
> >> OpenStack-dev mailing list
> >> OpenStack-dev at lists.openstack.org
> >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >
> >
> > _______________________________________________
> > OpenStack-dev mailing list
> > OpenStack-dev at lists.openstack.org
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140107/ad631c4d/attachment.html>


More information about the OpenStack-dev mailing list