<div dir="ltr">Hi, good that you're looking at this,<div><br></div><div><br></div><div>You could create a lot of ports with this method [1] and a bit of extra bash, without the extra expense of instance RAM.<br><div><br></div><div><br></div><div>[1] <a href="http://www.ajo.es/post/89207996034/creating-a-network-interface-to-tenant-network-in">http://www.ajo.es/post/89207996034/creating-a-network-interface-to-tenant-network-in</a><br></div><div><br></div><div><br></div><div>This effort is going to be still more relevant in the context of openvswitch firewall. We still need to make sure it's tested with the native interface, and eventually we will need flow bundling (like in ovs-ofctl --bundle add-flows) where the whole addition/removal/modification is sent to be executed atomically by the switch.</div><div><br></div><div><br></div><div><br></div><div><br></div><div><br></div></div></div><div class="gmail_extra"><br><div class="gmail_quote">On Thu, Apr 7, 2016 at 10:00 AM, IWAMOTO Toshihiro <span dir="ltr"><<a href="mailto:iwamoto@valinux.co.jp" target="_blank">iwamoto@valinux.co.jp</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">At Thu, 07 Apr 2016 16:33:02 +0900,<br>
<span class="">IWAMOTO Toshihiro wrote:<br>
><br>
> At Mon, 18 Jan 2016 12:12:28 +0900,<br>
> IWAMOTO Toshihiro wrote:<br>
> ><br>
> > I'm sending out this mail to share the finding and discuss how to<br>
> > improve with those interested in neutron ovs performance.<br>
> ><br>
> > TL;DR: The native of_interface code, which has been merged recently<br>
> > and isn't default, seems to consume less CPU time but gives a mixed<br>
> > result.  I'm looking into this for improvement.<br>
><br>
> I went on to look at implementation details of eventlet etc, but it<br>
> turned out to be fairly simple.  The OVS agent in the<br>
> of_interface=native mode waits for a openflow connection from<br>
> ovs-vswitchd, which can take up to 5 seconds.<br>
><br>
> Please look at the attached graph.<br>
> The x-axis is time from agent restarts, the y-axis is numbers of ports<br>
> processed (in treat_devices and bind_devices).  Each port is counted<br>
> twice; the first slope is treat_devices and the second is<br>
> bind_devices.  The native of_interface needs some more time on<br>
> start-up, but bind_devices is about 2x faster.<br>
><br>
> The data was collected with 160 VMs with the devstack default settings.<br>
<br>
</span>And if you wonder how other services are doing meanwhile, here is a<br>
bonus chart.<br>
<br>
The ovs agent was restarted 3 times with of_interface=native, then 3<br>
times with of_interface=ovs-ofctl.<br>
<br>
As the test machine has 16 CPUs, 6.25% CPU usage can mean a single<br>
threaded process is CPU bound.<br>
<br>
Frankly, the OVS agent would have little rooms for improvement than<br>
other services.  Also, it might be fun to draw similar charts for<br>
other types of workloads.<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" rel="noreferrer" target="_blank">OpenStack-dev-request@lists.openstack.org?subject:unsubscribe</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" rel="noreferrer" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
<br></blockquote></div><br></div>