Howdy Ian! Thanks for the background on the Passthrough work.
I reckon the best choice for us now is to use the traditional Neutron APIs instead of Passthrough. I think they cover all of our use cases as it stands now (many thanks to you for your earlier help with working this out :)). The idea is to put the SR-IOV hardware to work behind-the-scenes of a normal software switch. We will definitely check out the Passthrough when it's ready and see if we should also support that somehow. On 11 January 2014 01:04, Ian Wells <ijw.ubu...@cack.org.uk> wrote: > 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 <l...@snabb.co> wrote: >> >> Hi Mike, >> >> On 10 January 2014 17:35, Michael Bright <mjbrigh...@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@lists.openstack.org >> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > > > _______________________________________________ > OpenStack-dev mailing list > OpenStack-dev@lists.openstack.org > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev > _______________________________________________ OpenStack-dev mailing list OpenStack-dev@lists.openstack.org http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev