[ovs-discuss] OpenStack profiling with networking-ovn - port creation is slow

Ben Pfaff blp at ovn.org
Thu Feb 15 00:03:34 UTC 2018


On Wed, Feb 14, 2018 at 03:45:21PM -0800, Han Zhou wrote:
> On Wed, Feb 14, 2018 at 3:39 PM, Ben Pfaff <blp at ovn.org> wrote:
> >
> > On Wed, Feb 14, 2018 at 03:29:34PM -0800, Han Zhou wrote:
> > > On Wed, Feb 14, 2018 at 3:08 PM, Ben Pfaff <blp at ovn.org> wrote:
> > > >
> > > > On Wed, Feb 14, 2018 at 02:25:56PM -0800, Han Zhou wrote:
> > > > > On Wed, Feb 14, 2018 at 1:40 PM, Ben Pfaff <blp at ovn.org> wrote:
> > > > > >
> > > > > > On Wed, Feb 14, 2018 at 12:34:19PM -0800, Han Zhou wrote:
> > > > > > > I remember there was a patch for ACL group in OVN, so that
> instead
> > > of
> > > > > R*P
> > > > > > > rows we will have only R + P rows, but didn't see it went
> through.
> > > > > >
> > > > > > I don't remember that.  Any chance you could point me to it?
> > > > >
> > > > > Yes, I found it:
> > > > >
> > > > >
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/077118.html
> > > > >
> https://mail.openvswitch.org/pipermail/ovs-dev/2016-August/321165.html
> > > > >
> > > > > And I made a mistake in my previous text. It is about port group,
> which
> > > is
> > > > > what we need here, rather than ACL group.
> > > >
> > > > I guess what I'd like to see is an example of the problem that we're
> > > > trying to solve here: what does a typical ACL row for a security group
> > > > look like, and what parts of the row differ between its instance for
> one
> > > > port and another port?
> > >
> > > An ACL for a Neutron SG rule: ingress tcp dport=22, is something like:
> > > to-lport 1000 "outport==\"<neutron port uuid>\" && ip4 && tcp &&
> > > tcp.dst==22" allow-related
> > >
> > > All ports bound to the same SG will have an ACL like this, and the only
> > > difference between one port and another is the <neutron port uuid> part.
> >
> > Well, then it's really easy to merge all of them if we accept Zong's
> > patches above or something similar.  I had no idea!
> >
> > Is anyone willing to rebase those patches against current master?  I had
> > some feedback on them that wasn't ever addressed (and I'd probably have
> > a little more), which is the only reason that they weren't committed as
> > far as I can tell.
> 
> Cool. I'd be happy to rebase them, probably next week.

Thanks.

I think that we shouldn't change the name of the table, by the way.
Address_Set is somewhat of a misnomer once we allow sets of ports, but
it's good enough and changing table names is a pain.


More information about the discuss mailing list