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 <dalva...@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?) Thanks, Ben. _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
