<div dir="ltr"><div>Understood. You should be able to make that work but the issue is allocating your VM to some machine that has spare hardware - which is really what the patches are about, Nova manages allocations and Neutron manages using the hardware when appropriate. From past experience with the patch that was around back in the Essex timeframe, you can get this to work temporarily by rejecting the schedule in nova-compute when the machine is short of hardware and using a high schedule retry count, which will get you somewhere but is obviously a bit sucky in the long run.<br>
-- <br></div>Ian.<br></div><div class="gmail_extra"><br><br><div class="gmail_quote">On 13 January 2014 18:44, Luke Gorrie <span dir="ltr"><<a href="mailto:luke@snabb.co" target="_blank">luke@snabb.co</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">Howdy Ian!<br>
<br>
Thanks for the background on the Passthrough work.<br>
<br>
I reckon the best choice for us now is to use the traditional Neutron<br>
APIs instead of Passthrough. I think they cover all of our use cases<br>
as it stands now (many thanks to you for your earlier help with<br>
working this out :)). The idea is to put the SR-IOV hardware to work<br>
behind-the-scenes of a normal software switch.<br>
<br>
We will definitely check out the Passthrough when it's ready and see<br>
if we should also support that somehow.<br>
<div class="HOEnZb"><div class="h5"><br>
<br>
On 11 January 2014 01:04, Ian Wells <<a href="mailto:ijw.ubuntu@cack.org.uk">ijw.ubuntu@cack.org.uk</a>> wrote:<br>
> Hey Luke,<br>
><br>
> If you look at the passthrough proposals, the overview is that part of the<br>
> passthrough work is to ensure there's an PCI function available to allocate<br>
> to the VM, and part is to pass that function on to the Neutron plugin via<br>
> conventional means. There's nothing that actually mandates that you connect<br>
> the SRIOV port using the passthrough mechanism, and we've been working on<br>
> the assumption that we would be supporting the 'macvtap' method of<br>
> attachment that Mellanox came up with some time ago.<br>
><br>
> I think what we'll probably have is a set of standard attachments (including<br>
> passthrough) added to the Nova drivers - you'll see in the virtualisation<br>
> drivers that Neutron already gets to tell Nova how to attach the port and<br>
> can pass auxiliary information - and we will pass the PCI path and,<br>
> optionally, other parameters to Neutron in the port-update that precedes VIF<br>
> plugging. That would leave you with the option of passing the path back and<br>
> requesting an actual passthrough or coming up with some other mechanism of<br>
> your own choosing (which may not involve changing Nova at all, if you're<br>
> using your standard virtual plugging mechanism).<br>
><br>
> --<br>
> Ian.<br>
><br>
><br>
> On 10 January 2014 19:26, Luke Gorrie <<a href="mailto:luke@snabb.co">luke@snabb.co</a>> wrote:<br>
>><br>
>> Hi Mike,<br>
>><br>
>> On 10 January 2014 17:35, Michael Bright <<a href="mailto:mjbrightfr@gmail.com">mjbrightfr@gmail.com</a>> wrote:<br>
>><br>
>> > Very pleased to see this initiative in the OpenStack/NFV space.<br>
>><br>
>> Glad to hear it!<br>
>><br>
>> > A dumb question - how do you see this related to the ongoing<br>
>> > "[openstack-dev] [nova] [neutron] PCI pass-through network support"<br>
>> ><br>
>> > discussion on this list?<br>
>> ><br>
>> > Do you see that work as one component within your proposed architecture<br>
>> > for<br>
>> > example or an alternative implementation?<br>
>><br>
>> Good question. I'd like to answer separately about the underlying<br>
>> technology on the one hand and the OpenStack API on the other.<br>
>><br>
>> The underlying technology of SR-IOV and IOMMU hardware capabilities<br>
>> are the same in PCI pass-through and Snabb NFV. The difference is that<br>
>> we introduce a very thin layer of software over the top that preserves<br>
>> the basic zero-copy operation while adding a Virtio-net abstraction<br>
>> towards the VM, packet filtering, tunneling, and policing (to start<br>
>> off with). The design goal is to add quite a bit of functionality with<br>
>> only a modest processing cost.<br>
>><br>
>> The OpenStack API question is more open. How should we best map our<br>
>> functionality onto Neutron APIs? This is something we need to thrash<br>
>> out together with the community. Our current best guess - which surely<br>
>> needs much revision, and is not based on the PCI pass-through<br>
>> blueprint - is here:<br>
>><br>
>> <a href="https://github.com/SnabbCo/snabbswitch/tree/snabbnfv-readme/src/designs/nfv#neutron-configuration" target="_blank">https://github.com/SnabbCo/snabbswitch/tree/snabbnfv-readme/src/designs/nfv#neutron-configuration</a><br>
>><br>
>> Cheers,<br>
>> -Luke<br>
>><br>
>> _______________________________________________<br>
>> OpenStack-dev mailing list<br>
>> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
>> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
><br>
> _______________________________________________<br>
> OpenStack-dev mailing list<br>
> <a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
> <a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
><br>
<br>
_______________________________________________<br>
OpenStack-dev mailing list<br>
<a href="mailto:OpenStack-dev@lists.openstack.org">OpenStack-dev@lists.openstack.org</a><br>
<a href="http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev" target="_blank">http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev</a><br>
</div></div></blockquote></div><br></div>