<div dir="ltr">On Thu, Jun 25, 2015 at 7:39 AM, Andreas Scheuring <span dir="ltr"><<a href="mailto:scheuran@linux.vnet.ibm.com" target="_blank">scheuran@linux.vnet.ibm.com</a>></span> wrote:<br><div class="gmail_extra"><div class="gmail_quote"><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><br>
I want to proclaim a new networking project that we plan to start:<br>
It's called 'networking-macvtap'.<br>
<br></blockquote><div><br></div><div>Cool!<br> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
This project will contain a neutron ml2 driver and an corresponding<br>
neutron l2 agent. It's aim is to allow instance network attachments via<br>
macvtap in bridge mode independent of the physical network adapter used.<br>
<br>
I posted a detailed spec on github. See [1]<br>
<br>
@Kyle: I wonder if I can start this project directly under the big tent<br>
(in the openstack namespace)? The initial idea was stackforge (request [2]),<br>
but Andreas Jaeger from the infra team convinced me not to<br>
do this, as moving projects from stackforge to openstack is a huge<br>
effort. Either put it directly into the openstack namespace or start it on github.<br>
What's your recommendation?<br>
<br></blockquote><div><br></div><div>Yes, this is fine to start directly in Neutron under the Neutron stadium. I would recommend proposing a governance patch to add the repo, and make that dependent on your project-config patch to create the repository. Add me as a reviewer on both and they should be created in no time.<br><br></div><div>Thanks!<br></div><div>Kyle<br></div><div> <br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
Thanks!<br>
<br>
<br>
<br>
A brief summary of what we want to achieve:<br>
<br>
There is already some support for macvtap in the sriovnic driver/agent.<br>
But this support is totally integrated into PCI, using PCI addresses and<br>
programming vlans into the PCI VF. So it relies on hardware support.<br>
It's also using passthrough mode (1:1 relationship between macvtap and<br>
PCI VF).<br>
<br>
The approach we're heading to is to offer macvtap attachments independent<br>
of the underlying adapter. It's more like a vswitch, where multiple<br>
guests share the backing interface (1:n relationship).<br>
<br>
Why using macvtap agent?<br>
+ Performance: Compared to ovs default vswitch, it offers a much higher<br>
  throughput and lower latency to instances (measurements indicated up to<br>
  50% both)<br>
+ CPU consumption: Compared to ovs default vswitch the cpu consumption<br>
  in the hyperviros per throughput is much lower (measurements indicated<br>
  up to 50% both)<br>
+ Built into kernel: No additional software packages required, comes<br>
  with every linux<br>
+ Manageability: Very less configuration needed (in fact only 1)<br>
+ Hardware independent: No special network adapters required<br>
+ No promisc mode required on host adaptors<br>
<br>
<br>
To mention in addition:<br>
- In the first stage only compute attachments are supported (extensions<br>
  to support also dhcp, routing and so on will follow later on)<br>
- Security Groups: NoopFirewallDriver in first Stage only<br>
<br>
<br>
<br>
<br>
[1] <a href="https://github.com/scheuran/networking-macvtap/blob/bp/initial-macvtap-support/specs/liberty/macvtap-ml2.rst" rel="noreferrer" target="_blank">https://github.com/scheuran/networking-macvtap/blob/bp/initial-macvtap-support/specs/liberty/macvtap-ml2.rst</a><br>
[2] <a href="https://review.openstack.org/#/c/189644/" rel="noreferrer" target="_blank">https://review.openstack.org/#/c/189644/</a><br>
<span class="HOEnZb"><font color="#888888"><br>
--<br>
Andreas<br>
(IRC: scheuran)<br>
<br>
<br>
</font></span></blockquote></div><br></div></div>