[openstack-dev] [neutron] new project: networking-macvtap
mestery at mestery.com
Thu Jun 25 16:55:46 UTC 2015
On Thu, Jun 25, 2015 at 7:39 AM, Andreas Scheuring <
scheuran at linux.vnet.ibm.com> wrote:
> I want to proclaim a new networking project that we plan to start:
> It's called 'networking-macvtap'.
> This project will contain a neutron ml2 driver and an corresponding
> neutron l2 agent. It's aim is to allow instance network attachments via
> macvtap in bridge mode independent of the physical network adapter used.
> I posted a detailed spec on github. See 
> @Kyle: I wonder if I can start this project directly under the big tent
> (in the openstack namespace)? The initial idea was stackforge (request
> but Andreas Jaeger from the infra team convinced me not to
> do this, as moving projects from stackforge to openstack is a huge
> effort. Either put it directly into the openstack namespace or start it on
> What's your recommendation?
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.
> A brief summary of what we want to achieve:
> There is already some support for macvtap in the sriovnic driver/agent.
> But this support is totally integrated into PCI, using PCI addresses and
> programming vlans into the PCI VF. So it relies on hardware support.
> It's also using passthrough mode (1:1 relationship between macvtap and
> PCI VF).
> The approach we're heading to is to offer macvtap attachments independent
> of the underlying adapter. It's more like a vswitch, where multiple
> guests share the backing interface (1:n relationship).
> Why using macvtap agent?
> + Performance: Compared to ovs default vswitch, it offers a much higher
> throughput and lower latency to instances (measurements indicated up to
> 50% both)
> + CPU consumption: Compared to ovs default vswitch the cpu consumption
> in the hyperviros per throughput is much lower (measurements indicated
> up to 50% both)
> + Built into kernel: No additional software packages required, comes
> with every linux
> + Manageability: Very less configuration needed (in fact only 1)
> + Hardware independent: No special network adapters required
> + No promisc mode required on host adaptors
> To mention in addition:
> - In the first stage only compute attachments are supported (extensions
> to support also dhcp, routing and so on will follow later on)
> - Security Groups: NoopFirewallDriver in first Stage only
>  https://review.openstack.org/#/c/189644/
> (IRC: scheuran)
-------------- next part --------------
An HTML attachment was scrubbed...
More information about the OpenStack-dev