<div dir="ltr">On 23 January 2014 17:42, Calum Loudon <span dir="ltr"><<a href="mailto:Calum.Loudon@metaswitch.com" target="_blank">Calum.Loudon@metaswitch.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote">
<blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">That sounds fantastic.  As an NFV application developer I'm very pleased<br>

to see this contribution which looks to eliminate the key bottleneck<br>
hitting the performance of very high packet throughput apps on<br>
OpenStack.<br></blockquote><div><br></div><div>Thanks for the kind words!</div><div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">
A couple of questions on features and implementation:<br>
<br>
1.  If I create a VM with say neutron and Open vSwitch then I get a TAP<br>
device + Linux bridge + veth device between the VM and the vSwitch, with<br>
the Linux bridge needed for implementing anti-spoofing iptables rules/<br>
security group support.  What will the stack look like with your NFV<br>
driver in place?  Will your stack implement equivalent security functions,<br>
or will those functions not be available?<br></blockquote><div><br></div><div>Snabb NFV will implement equivalent security functions, and these will be configured via the standard Neutron APIs for Ports and Security Groups.</div>
<div><br></div><div>Our goal is to offload most of these functions to the NIC using hardware features like Intel's Flow Director. Standard NICs actually have hardware sitting idle that can do most of the work that iptables/ebtables/ovs/bridge is doing for OpenStack -- we hope to put this hardware to work and free up the CPU for running VMs.</div>
<div><br></div><div>The Snabb Switch traffic plane is internally structured as a network of "apps" that each implement one networking function and are connected by virtual Ethernet links (shared memory rings). This is a fairly accurate illustration of the internal components of Snabb NFV: <a href="https://github.com/SnabbCo/snabbswitch/blob/snabbnfv-readme/src/designs/nfv/README.md#snabb-switch-operation">https://github.com/SnabbCo/snabbswitch/blob/snabbnfv-readme/src/designs/nfv/README.md#snabb-switch-operation</a></div>
<div><br></div><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">2. Are you planning to support live migration?<br>
</blockquote><div><br></div><div>Good question!</div><div><br></div><div>This is a priority if-and-only-if KVM's basic live migration mechanism is adequate for NFV applications.</div><div><br></div><div>Do you know? (are some operators evaluating KVM for live migration and concluding that it is practical?)</div>
<div><br></div><div><br></div></div></div></div>