Open Stack

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'.
>
>
Cool!


> 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 [1]
>
> @Kyle: I wonder if I can start this project directly under the big tent
> (in the openstack namespace)? The initial idea was stackforge (request
> [2]),
> 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
> github.
> 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.

Thanks!
Kyle


> Thanks!
>
>
>
> 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
>
>
>
>
> [1]
> https://github.com/scheuran/networking-macvtap/blob/bp/initial-macvtap-support/specs/liberty/macvtap-ml2.rst
> [2] https://review.openstack.org/#/c/189644/
>
> --
> Andreas
> (IRC: scheuran)
>
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.openstack.org/pipermail/openstack-dev/attachments/20150625/2bb30136/attachment.html>