On Tue, May 23, 2017 at 10:01 AM, Miguel Angel Ajo Pelayo < [email protected]> wrote:
> 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? > > I like the idea... let's see what others say about this, I don't know how strict we want to be consuming bits from registers. Thanks Miguel for the suggestion :) > Best, > Miguel Ángel Ajo > > > > On Fri, May 19, 2017 at 4:26 PM, Daniel Alvarez Sanchez < > [email protected]> wrote: > >> Thanks a lot Ben for your review! >> >> On Fri, May 19, 2017 at 12:16 AM, Ben Pfaff <[email protected]> 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 <[email protected]> >> > >> > 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 >> [email protected] >> https://mail.openvswitch.org/mailman/listinfo/ovs-dev >> > > _______________________________________________ dev mailing list [email protected] https://mail.openvswitch.org/mailman/listinfo/ovs-dev
