On Tue, Sep 18, 2018 at 1:49 PM Ben Pfaff <b...@ovn.org> wrote: > On Mon, Sep 10, 2018 at 11:49:06PM +0530, nusid...@redhat.com wrote: > > From: Numan Siddique <nusid...@redhat.com> > > > > In the case of OpenStack + OVN, when the VMs are booted on > > hypervisors supporting SR-IOV nics, there are no OVS ports > > for these VMs. When these VMs sends DHCPv4, DHPCv6 or IPv6 > > Router Solicitation requests, the local ovn-controller cannot > > reply to these packets. OpenStack Neutron dhcp agent service > > needs to be run to serve these requests. > > > > With the new logical port type - 'external', OVN itself can > > handle these requests avoiding the need to deploy any external > > services like neutron dhcp agent. > > > > To make use of this feature, CMS has to > > - create a logical port for such VMs > > - set the type to 'external' > > - set requested-chassis="<chassis-name>" in the options column. > > - create a localnet port for the logical switch > > - configure the ovn-bridge-mappings option in the OVS db. > > > > When the ovn-controller running in that 'chassis', detects the > > Port_Binding row, it adds the necessary DHCPv4/v6 OF flows. Since > > the packet enters the logical switch pipeline via the localnet port, > > the inport register (reg14) is set to the tunnel key of localnet > > port in the match conditions. > > > > In case the chassis goes down for some reason, it is the responsibility > > of CMS to change the 'requested-chassis' option to some other active > > chassis, so that it can serve these requests. > > > > Signed-off-by: Numan Siddique <nusid...@redhat.com> > > Thank you for working on OVN. > > This is a specialized use case, so documentation is important. The > commit message above gives a lot of context for the feature. The > explanation that it's related to SR-IOV and the list of steps are both > valuable. I think that it would be helpful to put that information into > the OVN documentation, too. It might be appropriate to put something > about SR-IOV into ovn-architecture. > > Thanks for the review . Sure. I will update the documentation.
I don't yet understand the connection to localnet. Can you explain how > traffic between the SR-IOV NIC gets to and from the localnet port? > > Lets say we have two hosts chassis C1 and C2 and C1 and C2 are connected to the same switch. Suppose C1 has SRIOV configured. When a VM (booted on this chassis), sends a DHCP packet, it doesn't go via the host kernel stack. Instead it is handled by the SRIOV nic directly. So the packet doesn't go out of localnet port on C1. DHCP packet will be received on C2. If C2 is configured with ovn-bridge-mappings properly (lets say public:br-ex and br-ex has the physical nic added to it), the DHCP packet will come from br-ex to br-int via the localnet patch port. With this propose solution, the ovn-controller will respond to this DHCP request and replies to back via the same localnet port. And the packet will reach the C1's SRIOV nic and it will deliver the response packet to the VM. Since the SRIOV VM traffic is not handled by host, it is expected that provider networks (vlan or flat) are used. In the case of OpenStack + OVN, networking-ovn creates a localnet port for the provider networks. In the case of OpenStack with neutron reference implementation, neutron dhcp agent will be running on controller nodes which handles these DHCP requests. So with Openstack + OVN, most likely the ovn-controller's running on these controller nodes will be handling these DHCP requests. Along with SRIOV, there is another usecase. In the case of OpenStack, there is an ironic service which is used to provision a baremetal server for tenants (instead of VMs). When a baremetal server sends a DHCP request we want to handle these requests by one of the ovn-controller. I will document both these use cases. Thanks Numan > Thanks, > > Ben. > _______________________________________________ dev mailing list d...@openvswitch.org https://mail.openvswitch.org/mailman/listinfo/ovs-dev
