Open Stack

At Fri, 8 Apr 2016 12:21:21 +0200,
Miguel Angel Ajo Pelayo wrote:
> 
> Hi, good that you're looking at this,
> 
> 
> You could create a lot of ports with this method [1] and a bit of extra
> bash, without the extra expense of instance RAM.
> 
> 
> [1]
> http://www.ajo.es/post/89207996034/creating-a-network-interface-to-tenant-network-in
> 
> 
> 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.

Bad news is that ovs-firewall isn't currently using the native
of_interface much.  I can add install_xxx methods to
OpenFlowSwitchMixin classes so that ovs-firewall can use the native
interface.
Do you have a plan for implementing flow bundling or using conjunction?

> On Thu, Apr 7, 2016 at 10:00 AM, IWAMOTO Toshihiro <iwamoto at valinux.co.jp>
> wrote:
> 
> > At Thu, 07 Apr 2016 16:33:02 +0900,
> > IWAMOTO Toshihiro wrote:
> > >
> > > At Mon, 18 Jan 2016 12:12:28 +0900,
> > > IWAMOTO Toshihiro wrote:
> > > >
> > > > I'm sending out this mail to share the finding and discuss how to
> > > > improve with those interested in neutron ovs performance.
> > > >
> > > > TL;DR: The native of_interface code, which has been merged recently
> > > > and isn't default, seems to consume less CPU time but gives a mixed
> > > > result.  I'm looking into this for improvement.
> > >
> > > I went on to look at implementation details of eventlet etc, but it
> > > turned out to be fairly simple.  The OVS agent in the
> > > of_interface=native mode waits for a openflow connection from
> > > ovs-vswitchd, which can take up to 5 seconds.
> > >
> > > Please look at the attached graph.
> > > The x-axis is time from agent restarts, the y-axis is numbers of ports
> > > processed (in treat_devices and bind_devices).  Each port is counted
> > > twice; the first slope is treat_devices and the second is
> > > bind_devices.  The native of_interface needs some more time on
> > > start-up, but bind_devices is about 2x faster.
> > >
> > > The data was collected with 160 VMs with the devstack default settings.
> >
> > And if you wonder how other services are doing meanwhile, here is a
> > bonus chart.
> >
> > The ovs agent was restarted 3 times with of_interface=native, then 3
> > times with of_interface=ovs-ofctl.
> >
> > As the test machine has 16 CPUs, 6.25% CPU usage can mean a single
> > threaded process is CPU bound.
> >
> > Frankly, the OVS agent would have little rooms for improvement than
> > other services.  Also, it might be fun to draw similar charts for
> > other types of workloads.
> >
> >
> > __________________________________________________________________________
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-request at lists.openstack.org?subject:unsubscribe
> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
> >
> >