Open Stack

> -----Original Message-----
> From: Moshe Levi [mailto:moshele at mellanox.com]
> Sent: Wednesday, August 9, 2017 4:47 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> VIF_Type VIFHostDevice
> 
> 
> 
> -----Original Message-----
> From: Mooney, Sean K [mailto:sean.k.mooney at intel.com]
> Sent: Wednesday, August 9, 2017 6:36 PM
> To: OpenStack Development Mailing List (not for usage questions)
> <openstack-dev at lists.openstack.org>
> Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> VIF_Type VIFHostDevice
> 
> 
> 
> > -----Original Message-----
> > From: Moshe Levi [mailto:moshele at mellanox.com]
> > Sent: Wednesday, August 9, 2017 3:25 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev at lists.openstack.org>
> > Subject: Re: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on
> > VIF_Type VIFHostDevice
> >
> > Hi,
> >
> > 1) you should use neutron port with vnic_type direct
> > 2) yes,  just use neutron port with vnic_type  direct and confighure
> > the nova compute with pci passthogth whitelist
> > 3) you can configure firewall_driver = openvswitch to work with
> > Conntrack.
> >
> > So in your case if have SR-IOV nic which doesn't support  hardware
> > offload (but has VF representors port)  you will just fallback to the
> > ovs kernel datapath.
> 
> [Mooney, Sean K] that is not what will happen with intel nics and I
> would be doubtful Based on the code I have seen in nova and neutron
> that a fallback will happen with mellanox.
> If the neutron port has vnic_type direct it will Always result in a
> sriov vf being allocated for that port.
> There is no check in nova to ensure ovs support vf configuration and
> there is no check in neutron ml2 driver Either. This is why I wanted
> the feature based scheduling to prevent this from happening as that
> would prevent Nova from allocating the vf which would cause scheduling
> to fail.
> 
> [Moshe Levi] This is not what I meant. I was talking on the
> implementation of the ovs 2.8.0 hardware offload.
> I was referring  for NIC with SR-IOV that support representor ports
> switchdev mode (maybe I miss understood the question).  If it just SR-
> IOV NIC then you are correct.
[Mooney, Sean K] ah yes if the nic and ovs both support representor ports
And tc flower then yes the datapath will auto negociate what can be offloaded
Vs what has to take the exception path via the kernel dataplane. 
> 
> 
> When nova generates the Libvirt xml for that interface it will
> configure that port to use sriov direct pass-through.
> If ovs does not support managing that nic via the representor netdev or
> the nic does not support the tc flower protocol then the port add will
> not fail as we are just adding the representor netdev as a normal port
> But it will not be able to preform any control plane actions on it.
> there is no way for a Libvirt hostdevice to gracefully fall back to the
> kernel dataplane without modifying Xml. After all we are not even
> adding the vf to ovs we are adding a representor port to ovs so the
> dataplane is entirely bypassing ovs for unsupported nics.
> 
> 
> As long as you have the host has vf available and the ovs ml2 driver is
> listed before the sriov nic Agent ml2 driver you will get into this
> broken state.
> 
> > The ovs 2.8.0 code try to offload each datapath rule to NIC hardware
> > if it failed it fails back to the ovs kernel datapath.
> > So if have NIC that can offload classification  on vlan  and action
> > output. Only datapath flows that constructed for this classification
> > and action  will be offload to hardware.
> >
> > -----Original Meyssage-----
> > From: pranab boruah [mailto:pranabjyotiboruah at gmail.com]
> > Sent: Wednesday, August 9, 2017 4:36 PM
> > To: OpenStack Development Mailing List (not for usage questions)
> > <openstack-dev at lists.openstack.org>
> > Subject: [openstack-dev] [os-vif] [vif_plug_ovs] Queries on VIF_Type
> > VIFHostDevice
> >
> > Hi,
> > I am experimenting with the os-vif library and stumbled upon this new
> > VIF type called VIFHostDevice. I have few general queries. TIA.
> >
> > 1. How do I create ports with VIF_type as VIFHostDevice? Looking for
> > the CLI command options.
> >
> >
> > 2. Say, I have OVS running completely on x86 host(no datapath or flow
> > offload to
> >  NIC) as the networking mechanism and a SRIOV capable NIC(for
> > existence of VF representors that will be added to the OVS bridge).
> > Can I still launch instances with VIF_type as VIFHostDevice?
> >
> >
> > 3. I want to use Security Groups using OVS+Conntrack as the
> mechanism.
> > Can I apply SG rules on the ports of type VIFHostDevice using the
> > above mechanism?
> >
> > PS: I am still trying to understand this. Hence, I might get my
> > premises wrong in the above questions. Will appreciate a detailed
> > explanation.
> >
> > Regards,
> > Pranab
> >
> >
> ______________________________________________________________________
> > _
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > request at lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> > s
> > .openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> >
> dev&data=02%7C01%7Cmoshele%40mellanox.com%7C0af8192c256c42f1252308d4df
> > 2
> >
> b96b4%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378825693889082&
> > s
> > data=iNi%2FLHV5LkTKs8sSpS4BgHU6lwaoywo6O%2BNcF3hqtms%3D&reserved=0
> >
> ______________________________________________________________________
> > _
> > ___
> > OpenStack Development Mailing List (not for usage questions)
> > Unsubscribe: OpenStack-dev-
> > request at lists.openstack.org?subject:unsubscribe
> >
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flist
> > s.openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev&data=02
> >
> %7C01%7Cmoshele%40mellanox.com%7C5831df04b3a0421e12b908d4df3c6927%7Ca6
> >
> 52971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378897935223859&sdata=7CYf
> > yO9SJl%2FC6wP%2BuQQUUuUX3IszviaQQW04k343RFY%3D&reserved=0
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> https://emea01.safelinks.protection.outlook.com/?url=http%3A%2F%2Flists
> .openstack.org%2Fcgi-bin%2Fmailman%2Flistinfo%2Fopenstack-
> dev&data=02%7C01%7Cmoshele%40mellanox.com%7C5831df04b3a0421e12b908d4df3
> c6927%7Ca652971c7d2e4d9ba6a4d149256f461b%7C0%7C0%7C636378897935223859&s
> data=7CYfyO9SJl%2FC6wP%2BuQQUUuUX3IszviaQQW04k343RFY%3D&reserved=0
> _______________________________________________________________________
> ___
> OpenStack Development Mailing List (not for usage questions)
> Unsubscribe: OpenStack-dev-
> request at lists.openstack.org?subject:unsubscribe
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev