[ovs-dev] [PATCH v4] OVN localport type support

Miguel Angel Ajo Pelayo majopela at redhat.com
Tue May 23 08:01:33 UTC 2017


If we forsee use cases with several local ports by logical switch/chassis
could one option be to allocate a bit in REG10 to mark local ports,
and then have a single rule that matches reg10 to drop output/forwarding
of packets?

Best,
Miguel Ángel Ajo



On Fri, May 19, 2017 at 4:26 PM, Daniel Alvarez Sanchez <dalvarez at redhat.com
> wrote:

> Thanks a lot Ben for your review!
>
> On Fri, May 19, 2017 at 12:16 AM, Ben Pfaff <blp at ovn.org> wrote:
>
> > On Wed, May 10, 2017 at 08:35:45AM +0000, Daniel Alvarez wrote:
> > > This patch introduces a new type of OVN ports called "localport".
> > > These ports will be present in every hypervisor and may have the
> > > same IP/MAC addresses. They are not bound to any chassis and traffic
> > > to these ports will never go through a tunnel.
> > >
> > > Its main use case is the OpenStack metadata API support which relies
> > > on a local agent running on every hypervisor and serving metadata to
> > > VM's locally. This service is described in detail at [0].
> > >
> > > An example to illustrate the purpose of this patch:
> > >
> > > - One logical switch sw0 with 2 ports (p1, p2) and 1 localport (lp)
> > > - Two hypervisors: HV1 and HV2
> > > - p1 in HV1 (OVS port with external-id:iface-id="p1")
> > > - p2 in HV2 (OVS port with external-id:iface-id="p2")
> > > - lp in both hypevisors (OVS port with external-id:iface-id="lp")
> > > - p1 should be able to reach p2 and viceversa
> > > - lp on HV1 should be able to reach p1 but not p2
> > > - lp on HV2 should be able to reach p2 but not p1
> > >
> > > Explicit drop rules are inserted in table 32 with priority 150
> > > in order to prevent traffic originated at a localport to go over
> > > a tunnel.
> > >
> > > [0] https://review.openstack.org/#/c/452811/
> > >
> > > Signed-off-by: Daniel Alvarez <dalvarez at redhat.com>
> >
> > Thanks for working on this!
> >
> > This seems reasonable, but I'm torn about one aspect of it.  I'm not
> > sure whether my concern is a kind of premature optimization or not, so
> > let me just describe it and we can discuss.
> >
> > This adds code that iterates over every local lport (suppose there are N
> > of them), which is nested inside a function that is executed for every
> > port relevant to the local hypervisor (suppose there are M of them).
> > That's O(N*M) time.  But the inner loop is only doing something useful
> > for localport logical ports, and normally there would only be 1 or so of
> > those; at any rate a constant number.  So in theory this could run in
> > O(M) time.
> >
> > I see at least two ways to fix the problem, if it's a problem, but I
> > don't know whether it's worth fixing.  Daniel?  Russell?  (Others?)
> >
> > Yes, I also thought about this but I don't know either if it's a problem
> or not.
> If we want to impose at most one logical localport per datapath then we
> would have O(M) time (mimic localnet ports) but that's something I didn't
> want to do unless you think it makes more sense.
>
>
> > Thanks,
> >
> > Ben.
> >
> _______________________________________________
> dev mailing list
> dev at openvswitch.org
> https://mail.openvswitch.org/mailman/listinfo/ovs-dev
>


More information about the dev mailing list