On Thu, Dec 20, 2018 at 5:34 AM Numan Siddique <[email protected]> wrote: > > > > On Wed, Dec 19, 2018 at 4:23 PM Miguel Angel Ajo Pelayo < [email protected]> wrote: >> >> Oh, if requested chassis matches the chasis of the SRIOV instance, then we don't need HA. Ignore my comments regarding multiple chassis. >> >> And yes it's my understanding that the traffic will bounce to the host interface probably through the internal switch embedded in the SRIOV card, or, if the host uses a separate interface then via de Tor switch. >> >> >> On Wed, Dec 19, 2018, 1:54 AM Han Zhou <[email protected] wrote: >>> >>> Hi Numan, I haven't finished reviewing the whole patch yet, but I have some >>> questions inlined. >>> >>> >>> > + >>> > + <ul> >>> > + <li> >>> > + <p> >>> > + For each router port IP address <code>A</code> which belongs >>> to the >>> > + logical switch, A priority-100 flow is added which matches >>> > + <code>REGBIT_EXT_PORT_NOT_RESIDENT && arp.tpa == >>> <var>A</var> >>> > + && arp.op == 1</code> (ARP request to the router >>> > + IP) with the action to <code>drop</code> the packet. >>> > + </p> >>> > + >>> > + <p> >>> > + These flows guarantees that the ARP/NS request to the router IP >>> > + address from the external ports is responded by only the >>> chassis >>> > + which has claimed these external ports. All the other chassis, >>> > + drops these packets. >>> > + </p> >>> >>> Could you explain more about how this solves >>> https://bugzilla.redhat.com/show_bug.cgi?id=1613384 >>> For my understanding, the logical router port MAC would still flap on the >>> physical switch ports, if there are multiple external ports and their >>> "requested-chassis" are set to different chassis. Or does this suggest >>> specifying a single chassis as "requested-chassis" for all external-ports? >>> > > You are right. If there are multiple external ports and their "requested-chassis" are set to > different chassis you would still see MAC flap issue. I would say CMS should handle > this situation and set the same "requested-chassis" for all external ports. >
OK. So would it be better to document this consideration? > >>> >>> > diff --git a/ovn/ovn-architecture.7.xml b/ovn/ovn-architecture.7.xml >>> > index 3936e6016..37b97a0d9 100644 >>> > --- a/ovn/ovn-architecture.7.xml >>> > +++ b/ovn/ovn-architecture.7.xml >>> > @@ -1678,6 +1678,72 @@ >>> > </li> >>> > </ol> >>> > >>> > + <h2>Native OVN services for external logical ports</h2> >>> > + >>> > + <p> >>> > + To support OVN native services (like DHCP/IPv6 RA/DNS lookup) to the >>> > + cloud resources which are external, OVN supports >>> <code>external</code> >>> > + logical ports. >>> > + </p> >>> > + >>> > + <p> >>> > + Below are some of the use cases where <code>external</code> ports >>> can be >>> > + used. >>> > + </p> >>> > + >>> > + <ul> >>> > + <li> >>> > + VMs connected to SR-IOV nics - Traffic from these VMs by passes the >>> > + kernel stack and local <code>ovn-controller</code> do not bind >>> these >>> > + ports and cannot serve the native services. >>> > + </li> >>> >>> Would the broadcast traffic (e.g. DHCP discover) sent out from SR-IOV come >>> back to the local host? Is it free to select either the local host or any >>> other hosts as the "requested-chassis"? Or does this suggest that we have >>> to use a different chassis other than the local host as the >>> "requested-chassis"? >>> > > As Miguel mentioned the traffic may be received by the compute host where the SR-IOV VM > is present if the host NIC is connected to the same switch. > > It is free to select any chassis as long as that chassis can receive the broadcast packet. > > > >>> >>> I will review in more detail later. > > > Thanks > Numan > >>> >>> >>> Thanks, >>> Han >>> _______________________________________________ >>> 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
