you probably should consider using the future extension manager in ML2 :

https://review.openstack.org/#/c/89211/

On Mon, Aug 25, 2014 at 12:54 PM, Irena Berezovsky <ire...@mellanox.com> wrote:
> Hi Andreas,
> We can definitely set some time to discuss this.
> I am usually available from 5 to 14:00 UTC.
> Let's follow up on IRC (irenab).
>
> BR,
> Irena
>
> -----Original Message-----
> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
> Sent: Monday, August 25, 2014 11:00 AM
> To: Irena Berezovsky
> Cc: OpenStack Development Mailing List (not for usage questions)
> Subject: RE: [openstack-dev] [neutron][ml2] Openvswitch agent support for non 
> promic mode adapters
>
> Hi Irena,
> thanks for your reply. Yes sure, collaboration would be great.
> Do you already have a blueprint out there? Maybe wen can synchup this week to 
> discuss more details? Cause I would like to understand what exactly you're 
> looking for. Normally I'm available form 7 UTC to 16 utc (today only until 13 
> utc). My irc name is scheuran. Maybe we can get in contact this week!
>
> You also where talking about sriov. I saw some blueprint mentioning sriov & 
> macvtap. Do you have any insights into this one, too? What we also would like 
> to do is to introduce macvtap as network virtualization option. Macvtap also 
> registers mac addresses to network adapters...
>
>
> Thanks,
> Andreas
>
>
> On Sun, 2014-08-24 at 08:51 +0000, Irena Berezovsky wrote:
>> Hi Andreas,
>> Thank you for this initiative.
>> We were looking on similar problem for mixing OVS and SR-IOV on same network 
>> adapter, which also requires mac addresses registration of OVS ports.
>> Please let me know if you would like to collaborate on this effort.
>>
>> BR,
>> Irena
>>
>> -----Original Message-----
>> From: Andreas Scheuring [mailto:scheu...@linux.vnet.ibm.com]
>> Sent: Friday, August 22, 2014 11:16 AM
>> To: openstack-dev@lists.openstack.org
>> Subject: Re: [openstack-dev] [neutron][ml2] Openvswitch agent support
>> for non promic mode adapters
>>
>> Thanks for your feedback.
>>
>> No, I do not yet have code for it. Just wanted to get a feeling if such a 
>> feature would get acceptance in the community.
>> But if that helps I can sit down and start some prototyping while I'm 
>> preparing a blueprint spec in parallel.
>>
>> The main part of the implementation I wanted to do on my own to get more 
>> familiar with the code base and to get more in touch with the community.
>> But of course advice and feedback of experienced neutron developers is 
>> essential!
>>
>> So I will proceed like this
>> - Create a blueprint
>> - Commit first pieces of code to get early feedback (e.g. ask via the
>> mailing list or irc)
>> - Upload a spec (as soon as the repo is available for K)
>>
>> Does that make sense for you?
>>
>> Thanks,
>> Andreas
>>
>>
>>
>> On Thu, 2014-08-21 at 13:44 -0700, Kevin Benton wrote:
>> > I think this sounds reasonable. Do you have code for this already,
>> > or are you looking for a developer to help implement it?
>> >
>> >
>> > On Thu, Aug 21, 2014 at 8:45 AM, Andreas Scheuring
>> > <scheu...@linux.vnet.ibm.com> wrote:
>> >         Hi,
>> >         last week I started discussing an extension to the existing
>> >         neutron
>> >         openvswitch agent to support network adapters that are not in
>> >         promiscuous mode. Now I would like to enhance the round to get
>> >         feedback
>> >         from a broader audience via the mailing list.
>> >
>> >
>> >         The Problem
>> >         When driving vlan or flat networking, openvswitch requires an
>> >         network
>> >         adapter in promiscuous mode.
>> >
>> >
>> >         Why not having promiscuous mode in your adapter?
>> >         - Admins like to have full control over their environment and
>> >         which
>> >         network packets enter the system.
>> >         - The network adapter just does not have support for it.
>> >
>> >
>> >         What to do?
>> >         Linux net-dev driver offer an interface to manually register
>> >         additional
>> >         mac addresses (also called secondary unicast addresses).
>> >         Exploiting this
>> >         one can register additional mac addresses to the network
>> >         adapter. This
>> >         also works via a well known ip user space tool.
>> >
>> >         `bridge fdb add aa:aa:aa:aa:aa:aa dev eth0`
>> >
>> >
>> >         What to do in openstack?
>> >         As neutron is aware of all the mac addresses that are in use
>> >         it's the
>> >         perfect candidate for doing the mac registrations. The idea is
>> >         to modify
>> >         the neutron openvswitch agent that it does the registration on
>> >         "port
>> >         add" and "port remove" via the bridge command.
>> >         There would be a new optional configuration parameter,
>> >         something like
>> >         'non-promisc-mode' that is by default set to false. Only when
>> >         set to
>> >         true, macs get manually registered. Otherwise the agent
>> >         behaves like it
>> >         does today. So I guess only very little changes to the agent
>> >         code are
>> >         required. From my current point of view we do not need any
>> >         changes to
>> >         the ml2 plug-in.
>> >
>> >
>> >         Blueprint or a bug?
>> >         I guess it's a blueprint.
>> >
>> >         What's the timeframe?
>> >         K would be great.
>> >
>> >
>> >
>> >         I would be thankful for any feedback on this! Feel free to
>> >         contact me
>> >         anytime. Thanks in advance!
>> >
>> >         Regards,
>> >         Andreas
>> >
>> >         (irc: scheuran)
>> >
>> >
>> >         _______________________________________________
>> >         OpenStack-dev mailing list
>> >         OpenStack-dev@lists.openstack.org
>> >
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>> >
>> >
>> >
>> >
>> > --
>> > Kevin Benton
>> > _______________________________________________
>> > OpenStack-dev mailing list
>> > OpenStack-dev@lists.openstack.org
>> > http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>>
>>
>> _______________________________________________
>> OpenStack-dev mailing list
>> OpenStack-dev@lists.openstack.org
>> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev
>>
>
>
> _______________________________________________
> OpenStack-dev mailing list
> OpenStack-dev@lists.openstack.org
> http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

_______________________________________________
OpenStack-dev mailing list
OpenStack-dev@lists.openstack.org
http://lists.openstack.org/cgi-bin/mailman/listinfo/openstack-dev

Reply via email to