Open Stack

Hey Luke,

If you look at the passthrough proposals, the overview is that part of the
passthrough work is to ensure there's an PCI function available to allocate
to the VM, and part is to pass that function on to the Neutron plugin via
conventional means.  There's nothing that actually mandates that you
connect the SRIOV port using the passthrough mechanism, and we've been
working on the assumption that we would be supporting the 'macvtap' method
of attachment that Mellanox came up with some time ago.

I think what we'll probably have is a set of standard attachments
(including passthrough) added to the Nova drivers - you'll see in the
virtualisation drivers that Neutron already gets to tell Nova how to attach
the port and can pass auxiliary information - and we will pass the PCI path
and, optionally, other parameters to Neutron in the port-update that
precedes VIF plugging.  That would leave you with the option of passing the
path back and requesting an actual passthrough or coming up with some other
mechanism of your own choosing (which may not involve changing Nova at all,
if you're using your standard virtual plugging mechanism).

-- 
Ian.


On 10 January 2014 19:26, Luke Gorrie <luke at snabb.co> wrote:

> Hi Mike,
>
> On 10 January 2014 17:35, Michael Bright <mjbrightfr at gmail.com> wrote:
>
> > Very pleased to see this initiative in the OpenStack/NFV space.
>
> Glad to hear it!
>
> > A dumb question - how do you see this related to the ongoing
> >      "[openstack-dev] [nova] [neutron] PCI pass-through network support"
> >
> > discussion on this list?
> >
> > Do you see that work as one component within your proposed architecture
> for
> > example or an alternative implementation?
>
> Good question. I'd like to answer separately about the underlying
> technology on the one hand and the OpenStack API on the other.
>
> The underlying technology of SR-IOV and IOMMU hardware capabilities
> are the same in PCI pass-through and Snabb NFV. The difference is that
> we introduce a very thin layer of software over the top that preserves
> the basic zero-copy operation while adding a Virtio-net abstraction
> towards the VM, packet filtering, tunneling, and policing (to start
> off with). The design goal is to add quite a bit of functionality with
> only a modest processing cost.
>
> The OpenStack API question is more open. How should we best map our
> functionality onto Neutron APIs? This is something we need to thrash
> out together with the community. Our current best guess - which surely
> needs much revision, and is not based on the PCI pass-through
> blueprint - is here:
>
> https://github.com/SnabbCo/snabbswitch/tree/snabbnfv-readme/src/designs/nfv#neutron-configuration
>
> Cheers,
> -Luke
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev at lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20140111/8ed0bf2b/attachment.html>